頁面加载慢，很多人第一反應是服務器或带宽問题。但在實际排查中，经常遇到另一種情况：服務器响應很快，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 里。
收尾建议
渲染阻塞自查不需要一次做完，可以從訪問量最高的几個模板開始，先解决最明顯的大文件。改完後用工具對比首屏時間，確認没有引入新的脚本错誤或样式错乱。把這項检查寫進改版流程，比等到訪客抱怨白屏再回头找原因要省事得多。