fcp卡在html解析阶段主因是阻塞渲染的脚本、过大的内联css及非流式html输出。需将script移出head或加async/defer，精简关键css至10–15kb，启用流式ssr并避免同步操作。
FCP 为什么卡在 HTML 解析阶段
FCP（First Contentful Paint）不是等整个页面加载完才触发，而是浏览器首次渲染出任何文本、图片、<svg></svg>、非空白 <canvas></canvas> 或 CSS 生成内容（如 ::before）的时刻。但如果你的 FCP 延迟严重，且 Lighthouse 报告显示 “Render-blocking resources” 或 “Slow HTML parsing”，大概率是 HTML 本身拖慢了初始渲染——比如过早引入大 JS、内联了巨型 CSS、或 DOM 树深度/宽度爆炸。
关键：把 <script></script> 移出 async/defer
浏览器解析 HTML 是流式进行的，遇到 <script></script> 默认会暂停解析、下载并执行脚本，再继续。哪怕只是几 KB 的分析脚本，也会阻塞首屏文本/标题渲染。
- 所有非必需的第三方脚本（统计、广告、A/B 测试）必须用
async，且放在底部或开头 - 首屏无关的业务 JS（如表单校验、懒加载逻辑）用
defer，可放，但确保不依赖 DOM 就执行 -
绝对不要 在
写<script>console.log(...)</script>这类同步内联脚本——它没有网络延迟，但解析+执行仍阻塞渲染
内联 CSS 必须「刚好够用」，别塞整套 Tailwind
内联关键 CSS（Critical CSS）能避免一次 RTT，但很多人误以为“越多越快”。实际上，过大的 <style></style> 会显著延长 HTML 解析时间，尤其在低端设备上。Chrome DevTools 的 “Coverage” 面板能精准标出哪些 CSS 规则在首屏根本没用到。
- 只提取首屏可见区域（above-the-fold）真正用到的样式，通常不超过 10–15 KB（gzip 后）
- 避免内联
@import、@font-face或 Web Font 加载逻辑——它们会触发额外请求并阻塞渲染 - 字体加载用
font-display: optional或swap，并配合<link rel="preload" as="font">提前抓取
服务端要输出「可流式解析」的 HTML
Node.js 模板引擎（如 EJS、Nunjucks）或 SSR 框架（Next.js、Nuxt）默认可能等全部数据就绪才吐出完整 HTML，这会让浏览器空等。FCP 优化的核心之一，是让浏览器尽早拿到开头的 <title></title> 和首屏 DOM 片段。
- 启用流式 SSR（Streaming SSR）：例如 Next.js 13+ 的
renderToPipeableStream，或 Express 中用res.write()分块输出 - 首屏静态内容（如页眉、主标题）优先 flush，动态部分（如用户昵称、商品列表）用占位符 + 客户端 hydration 补全
- 禁用模板中耗时的同步操作（如读文件、正则全局匹配），这些会延迟首字节（TTFB），间接拉长 FCP
FCP 不是前端单点优化问题——它卡在 HTML 字节到达浏览器、被解析成 DOM、再触发绘制的整个链路里。最容易被忽略的是：你以为“HTML 很小所以没问题”，却没测过解析耗时；或者以为“内联 CSS 能提速”，结果塞了 200KB 的未裁剪样式表。真要压低 FCP，得盯着 Network → Timing 里的 “Parse HTML” 时间，而不是只看资源大小。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
