页面加载慢，很多人第一反应是服务器或带宽问题。但在实际排查中，经常遇到另一种情况：服务器响应很快，HTML 早就传完了，浏览器却迟迟不渲染——因为 CSS 和 JavaScript 把渲染流程挡住了。这类资源被称为渲染阻塞资源，它们不解决，首屏就一直是白屏或闪烁。
先弄清楚谁在阻塞渲染
浏览器解析 HTML 时，遇到外部 CSS 会暂停渲染，等样式表下载并解析完再继续；遇到没有 async 或 defer 的脚本，不仅会暂停渲染，通常还会暂停 HTML 解析。也就是说，放在 head 里的同步脚本和体积过大的样式表，是最常见的“拦路虎”。
常见阻塞来源包括：
- head 中同步加载的第三方统计、客服、广告脚本；
- 未拆分的关键 CSS，比如整个 UI 框架全量引入；
- 多个 CSS 文件串行加载，每个都要等上一个；
- 字体文件虽不直接阻塞渲染，但会触发文字不可见，影响观感。
自查步骤
1. 用工具定位首屏空白时间
打开浏览器开发者工具的“网络”面板，看 HTML 返回后到首次渲染之间的时间。也可以用 Lighthouse 或 PageSpeed Insights 跑一次，重点关注“消除阻塞渲染的资源”这一项。工具会列出具体文件和建议，比自己猜要快。
2. 检查资源加载位置
查看页面源码，确认哪些 CSS 和 JS 放在 head 中且没有 defer/async 属性。如果发现关键样式之外的文件也在这里同步加载，就有优化空间。
3. 区分关键与非关键
首屏可见区域需要的样式是“关键 CSS”，可以内联到 HTML 中；其余样式可以异步加载或延迟加载。脚本方面，不影响首屏交互的可以加 defer 或 async，让它们不挡渲染。
处理思路
- 内联关键 CSS：把首屏必需的少量样式直接写在 head 里，减少一次外部请求。
- 延迟非关键 CSS：用媒体查询或动态加载方式，让首屏之外、打印样式等后置加载。
- 脚本加 defer 或 async：defer 保持执行顺序，async 适合独立统计脚本；两者都不阻塞渲染。
- 第三方脚本延后：统计、客服、广告脚本尽量在首屏渲染完成后再加载，或使用异步方式。
- 字体设置 font-display：避免文字长时间不可见，可先用系统字体兜底。
优化渲染阻塞不是把所有资源都往后拖。关键 CSS 该内联就内联，首屏需要的脚本该早加载就早加载，目标是让首屏尽快出现，而不是让所有东西都变慢。
容易被忽略的几个坑
- 把所有 CSS 都内联，导致 HTML 体积过大，反而拖慢传输。
- 给所有脚本都加 async，依赖顺序的脚本执行错乱，功能报错。
- 只优化首页，栏目页和详情页的模板仍然同步加载大量资源。
- 上线后没有复查，后续新增的第三方脚本又悄悄回到 head 里。
收尾建议
渲染阻塞自查不需要一次做完，可以从访问量最高的几个模板开始，先解决最明显的大文件。改完后用工具对比首屏时间，确认没有引入新的脚本错误或样式错乱。把这项检查写进改版流程，比等到访客抱怨白屏再回头找原因要省事得多。