首字节（TTFB）之后的HTML解析是流式进行的，但未闭合标签、同步脚本或巨型内联块会直接阻塞解析器，拖慢FCP；防阻塞关键在于避免解析卡顿，而非单纯提升下载速度。
首字节（TTFB）之后的 HTML 解析阶段，不是“等全部 HTML 下完再开始”，而是流式逐块解析——但一旦遇到未闭合标签、同步脚本或巨型内联块，就会卡住，直接拖慢 FCP。防阻塞的关键不在“快下载”，而在“让解析器不卡”。
Parse HTML 任务卡在哪儿？用 Performance 面板定位真实阻塞点
Chrome DevTools 的 Performance 面板里，Parse HTML 任务本身不显示哪行代码拖慢了解析，必须右键它 → “View Call Stack”，看调用栈最顶层的 HTML 行号（比如 <script src="app.js"></script> 在第 42 行）。再交叉验证：
- Network 面板中该 HTML 请求的
Content-Length：若 >15 KB，优先怀疑内联 CSS/JS 体积失控 - Elements 面板右键首屏任意节点 → “Show DOM properties” → 查
depth值：≥7 就说明嵌套过深，解析器要多走几轮父子绑定 - Performance 时间轴上
Parse HTML后紧跟着长条Evaluate Script或Parse Stylesheet：说明解析器刚读到那个标签就停了，不是下载慢，是结构卡住了
内联
内联不是“越全越好”，而是“越准越快”。浏览器解析 <style></style> 时，必须把整块文本读入内存、分词、构建 CSSOM，这个过程和 JS 执行一样阻塞解析流。
- 禁止在
<style></style>里写@import或@font-face：它们会触发额外网络请求，让内联失效 - 内联内容只保留首屏必需规则（如
.hero h1、.btn），剔除所有:hover、@media（除非首屏强依赖）、字体加载逻辑 - 用 Chrome Coverage 面板（More Tools → Coverage）刷新页面，勾选 CSS，灰色部分 = 未使用规则，可安全删除
- 内联 JS 同理：若只是初始化逻辑且依赖 DOM，必须加
defer；async对内联脚本无效，会被浏览器忽略
DOM 深度 ≥7 时，语义化标签比更省解析时间
不是 CSS 选择器慢，是 HTML 解析器本身吃力。每多一层 <div> 嵌套，解析器就要多做一次节点创建 + 父级挂载 + 层级记录。深度 ≥7 时，低端 Android 设备上解析耗时可多出 60–80ms。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<ul><li>用 <code><header></header>、<nav></nav>、<main></main>、<section></section> 替代无意义 <div class="wrapper"> 包裹
<li>避免“为 Flex/Grid 而嵌套”：能用 <code>display: contents 消掉一层容器的，就别用 <div> —— 注意 Safari 15.4+ 才支持
<li>检查方式固定：DevTools → Elements → 右键任意首屏节点 → “Show DOM properties” → 看 <code>depth 值
流式 HTML 分块输出（Streaming SSR）为什么能压低 FCP
服务端不等整个模板渲染完再吐 HTML，而是边生成边发送。浏览器拿到第一块就立刻开始解析，只要首屏 HTML 片段足够早到达，FCP 就能提前触发。
- Node.js 中用
res.write() 分多次写入，配合 res.flush() 强制推送到客户端
- Next.js 13+ App Router 默认启用流式 SSR，但需确保 layout 和 page 组件不阻塞首屏数据获取（如避免
await 在 layout 顶层）
- Vite SSR 或 Remix 中，需显式拆分
renderToPipeableStream 并设置 bootstrapScripts 位置，确保首屏脚本在对应 HTML 块后立即注入
- 关键点：流式输出 ≠ 随便拆。首屏 HTML 必须包含完整闭合标签（如
<header>...</header>），否则解析器会等待补全，反而更慢
真正难的不是知道该做什么，而是判断哪一行 HTML 正在拖慢解析器——它藏在 Performance 的 Call Stack 里，不在 Network 的瀑布图里；也不是删掉多少 CSS，而是确认那 20 行内联样式是否真被首屏节点用到了。
不是 CSS 选择器慢，是 HTML 解析器本身吃力。每多一层 <div> 嵌套，解析器就要多做一次节点创建 + 父级挂载 + 层级记录。深度 ≥7 时，低端 Android 设备上解析耗时可多出 60–80ms。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<ul><li>用 <code><header></header>、<nav></nav>、<main></main>、<section></section> 替代无意义 <div class="wrapper"> 包裹
<li>避免“为 Flex/Grid 而嵌套”：能用 <code>display: contents 消掉一层容器的，就别用 <div> —— 注意 Safari 15.4+ 才支持
<li>检查方式固定：DevTools → Elements → 右键任意首屏节点 → “Show DOM properties” → 看 <code>depth 值
流式 HTML 分块输出（Streaming SSR）为什么能压低 FCP
服务端不等整个模板渲染完再吐 HTML，而是边生成边发送。浏览器拿到第一块就立刻开始解析，只要首屏 HTML 片段足够早到达，FCP 就能提前触发。
- Node.js 中用
res.write()分多次写入，配合res.flush()强制推送到客户端 - Next.js 13+ App Router 默认启用流式 SSR，但需确保 layout 和 page 组件不阻塞首屏数据获取（如避免
await在 layout 顶层） - Vite SSR 或 Remix 中，需显式拆分
renderToPipeableStream并设置bootstrapScripts位置，确保首屏脚本在对应 HTML 块后立即注入 - 关键点：流式输出 ≠ 随便拆。首屏 HTML 必须包含完整闭合标签（如
<header>...</header>），否则解析器会等待补全，反而更慢
真正难的不是知道该做什么，而是判断哪一行 HTML 正在拖慢解析器——它藏在 Performance 的 Call Stack 里，不在 Network 的瀑布图里；也不是删掉多少 CSS，而是确认那 20 行内联样式是否真被首屏节点用到了。
