首屏白屏时间长几乎从不因html体积大，而是其触发的阻塞行为未受控——同步script、未拆分的stylesheet、缺尺寸的img、过高ttfb四类问题占线上案例90%以上。
首屏白屏时间长，几乎从不因为 HTML 文件本身体积大，而是它触发的阻塞行为没被控制住——script 同步执行、link rel="stylesheet" 未拆分、img 缺 width/height、服务端 TTFB 过高，这四类问题占了真实线上案例的 90% 以上。
怎么确认瓶颈真在 HTML 渲染路径上
别改代码，先看 DevTools：打开 Network 面板 → 勾选 Disable cache → 刷新。重点盯三处：
-
document请求的TTFB是否 > 200ms？如果是，问题在服务端（Nginx 未开 Brotli、SSR 渲染卡数据库） -
main.css或app.js的Initiator列是否为parser？说明是 HTML 解析中途同步拉取，属于关键阻塞源 -
FCP时间点前是否有明显空白？如果紧挨着某个link或script，就是它拖住了渲染树生成
script 标签加 defer 还是 async？看它是否依赖 DOM
defer 和 async 都能避免阻塞 HTML 解析，但执行时机和适用场景完全不同：
- 业务逻辑脚本（Vue 初始化、API 请求、按钮事件绑定）→ 必须用
defer：<script src="app.js" defer></script>，下载异步，执行在 DOM 解析完成后、DOMContentLoaded前，且保持书写顺序 - 统计类脚本（
analytics.js、埋点 SDK）→ 可用async，但必须自行判断document.readyState，否则可能在body还没解析完时就执行querySelector报错 - 绝对禁用无属性的
<script src="xxx"></script>：这是同步阻塞模式，HTML 解析直接暂停，用户看到的就是白屏 -
type="module"默认等效于defer，还支持静态分析，但旧版 Safari 兼容性需验证
哪些 CSS 必须内联？怎么提取才不破坏可维护性
“关键 CSS”不是整张 style.css，而是首屏 viewport 内所有元素渲染所必需的样式规则：
- 手动验证法：断网后打开页面，能显示标题、主图、按钮的部分，对应的就是关键 CSS
- 工具提取法：用
criticalnpm 包或html-critical-webpack-plugin，输入 HTML + CSS，输出内联片段，比手写靠谱得多 - 内联位置必须是
<style></style>，不能放或注释后；体积建议 gzip 后控制在 10–20KB，超了反而不如外链 - 非关键 CSS 改用
<link rel="stylesheet" media="print" onload="this.media='all'">，靠 JS 触发加载，不阻塞初始渲染 - 绝对禁用
@import引入关键样式：它强制串行请求，比link多一次网络往返，实测拖慢FCP300ms+
图片缺 width/height 为什么会让 LCP 延迟甚至白屏延长
浏览器无法预知 img 尺寸时，会先占位 0×0，等图片加载完成再重排布局（layout shift）。这不仅影响 CLS 指标，还会延迟 LCP 判定：
- 首屏大图必须带
width和height属性，或用aspect-ratiofallback（如style="aspect-ratio: 16/9;"） - 首屏图片不要加
loading="lazy"：浏览器直接跳过加载，导致关键图延迟渲染，LCP暴涨 - 非首屏图片统一加
loading="lazy"，但前提是已补全尺寸属性，否则仍会触发布局偏移 - SSR 页面中 JS 动态插入的
img，默认loading="eager"，需显式设置loading="lazy"才生效
真正难的不是知道该做什么，而是每次上线前能否快速判断出哪段内联 CSS 是“首屏必需”的、哪个 script 其实不该用 async、以及服务端返回的 HTML 是否真的在 200ms 内吐出了第一个字节——这些细节不靠工具链固化，单靠人盯很容易漏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
