文章页引了三个分享 SDK，都写在 head 里同步加载，Lighthouse 首屏 TTI 从 1.9 秒涨到 3.3 秒，分享按钮要等 1.4 秒才可点。日志里能对上时间点，这种反而好排。
share.js 和两个平台 SDK 没有 defer，浏览器要下载并执行完才继续解析正文。三个脚本合计 210KB，其中一个还带了整套图标字体，和首屏图片抢带宽。这一点先确认清楚，后面就不用反复试。
<script src='/js/share.js' defer></script> <script src='/js/weibo-sdk.js' defer></script> <!-- 首屏只保留静态分享图标 -->
围绕「分享脚本阻塞首屏」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：把分享 SDK 改成 defer 或挪到 body 末尾；按钮先用静态图标占位 脚本就绪后再绑定事件；用 performance.getEntriesByType 核对三个脚本各自耗时。
结果对不对很好判断，Lighthouse 首屏 TTI 回到 2 秒附近，分享按钮在 200ms 内就能点开面板。