很多站点的首屏时间并不是被自己的代码拖慢的，而是被一串外部资源拖慢的：统计脚本、在线客服、埋点工具、字体库、地图组件、验证码、广告位。它们分散在不同页面、由不同的人加上去，时间一长就没人说得清哪个还在用、哪个早就下線了。
这类问题通常不会让页面直接打不开，但会持续消耗访问体验和抓取效率。做一次第三方资源自查，往往比反复调样式更划算。
一、先列清楚页面加载了哪些外部资源
打开开发者工具的 Network 面板，分别刷新首页、栏目页、内容页各一个，按域名排序，把不属于本站域名或本站 CDN 的请求挑出来，整理成一张表。
- 统计与埋点：访问统计、事件埋点、热力图、会话录制。
- 交互组件：在线客服、评论、分享、弹窗订阅、表单校验。
- 展示类资源：图标字体、第三方字体、图床、视频播放器、地图。
- 功能类脚本：验证码、支付、登录授权、A/B 测试。
- 广告与推送：广告位脚本、联盟代码、浏览器推送服务。
每一项都标注四件事：加在哪些页面、是不是全站引入、是否还能找到负责人、最近一次修改时间。
二、常见的几类问题
1. 同步加载挡住渲染
把统计或客服脚本直接写在 head 区域里同步加载，浏览器要先下载并执行它，才继续渲染后面的内容。这类脚本本身不影响页面功能，却能明显推后首屏。多数情况下改成异步或延后加载就能省下这段时间。
2. 同一功能重复引入
老版统计没删干净、新版又加了一遍；三个模板各自引入一次客服脚本；字体和图标同时从两个 CDN 拉取。单看每个请求都不大，叠加起来就是几百毫秒。
3. 已经失效的请求
被弃用的域名、过期的账号、下线的服务，脚本仍然挂在页面上，每次访问都要等一次超时。这类请求在后台不太容易发现，但会拖慢加载，也可能在控制台留下一串报错。
4. 失败后没有降级
外部脚本加载失败时，如果页面依赖它做渲染或校验，用户看到的就是空白块或者点不动的按钮。自查时要确认：脚本挂了，页面主体内容是否还能正常阅读和操作。
5. 协议与域名不一致
HTTPS 页面里引用 HTTP 资源会被浏览器拦截；引用方与被引用方域名不一致，也可能出现权限报错。改版、迁移或换 CDN 之后，尤其要复查一遍。
三、一份可以照着做的检查流程
- 固定页面样本：首页、一个栏目页、一个内容页，连续测三次取中间值。
- 用开发者工具记录请求总数、第三方域名数量、阻塞渲染的资源。
- 逐个移除可疑脚本再测一次，观察首屏和交互变化，判断是否值得保留。
- 给保留下来的脚本设置异步加载、超时控制和失败兜底。
- 把结果写进运维记录，作为下次排查的基线。
如果站点有服务器日志，也可以顺带看看这些外部请求是否频繁超时，超时的时间段是否和访问高峰重合。
四、整改与复查
整改原则可以简单概括为：能自建的尽量自建，能合并的合并，能延后的延后，确认没用的删掉。并不是所有第三方都要清空，而是要清楚每个脚本在做什么、值不值得为它付出加载时间。
不要一次删掉所有外部脚本再观察效果，那样很难判断是哪一步起了作用。每次只改一项，记录前后差异，结论才靠得住。
建议每季度复查一次，改版、换主题、加新功能之后各查一次。第三方资源是流动的，今天看着没问题的组合，过几个月可能就变成新的负担。