HTML首屏加载慢的根源在于阻塞行为而非文件体积，关键包括：未设宽高的图片引发重排、@import增加网络往返、script未用defer/async导致解析中断、内联CSS超1KB拖慢TTFB、缺失Content-Type降级解析优先级。
HTML 代码质量不是“写得整不整洁”的风格问题，而是直接影响首屏能否在 1 秒内出内容的硬性约束。差的 HTML 结构会让浏览器反复重排、卡住解析、错判资源优先级——哪怕 CSS 和 JS 都压缩到极致，首屏照样白屏 2 秒以上。
为什么 DOMContentLoaded 快但页面还是白屏
常见现象是 DOMContentLoaded 在 800ms 触发，但 FCP 却拖到 2.5s+。这说明 DOM 树建好了，但渲染树（Render Tree）卡住了：要么关键 CSS 没加载完，要么 JS 执行阻塞了样式计算或布局。
- 检查 Network 面板里所有
.css和.js请求的Initiator列：显示parser的就是 HTML 解析中途同步拉取的，属于高危阻塞点 -
@import在 CSS 文件里出现一次，就会额外增加一次网络往返，实测拖慢FCP超 300ms，必须替换成<link rel="stylesheet"> - 服务端返回的
Content-Type: text/html缺失或被中间件覆盖，会导致浏览器降级为低优先级解析，document请求的 Priority 显示为Medium或更低
script 标签放哪儿、加什么属性才不打断解析
默认的 <script src="app.js"></script> 是同步阻塞模式：HTML 解析停 → 下载 JS → 执行 JS → 继续解析。这不是“慢”，是“卡死”。
- 依赖 DOM 且有执行顺序要求（如 Vue mount、React hydrate）：用
defer，脚本并行下载，按顺序在DOMContentLoaded前执行 - 完全无 DOM 依赖、可随时执行（如
analytics.js）：用async，下载完立刻执行，不保序也不等 DOM - 现代项目优先用
<script type="module" defer>：天然支持defer行为，还能静态分析 import 依赖，但注意旧版 Safari 兼容性 - 绝对不要手动把 script 拖到
</body>底部——这是兼容性兜底方案，不是性能最优解；构建工具生成的代码中，defer更可控
内联 CSS 的体积和范围怎么控制才有效
内联不是“把 main.css 复制进 <style>”，而是只提取首屏结构必需的规则。超 1KB 的内联 CSS 反而会拖慢 TTFB，尤其在弱网下。
立即学习“前端免费学习笔记（深入）”；
- 用
critters（Webpack）或purgecss + html-webpack-plugin自动提取，别手写——手写极易漏掉媒体查询或动态 class（比如.is-loaded） - 只内联影响首屏像素绘制的规则：
.hero-text字体大小颜色、.primary-btn尺寸和背景色、骨架屏容器的display: flex等；动画、主题切换、断点逻辑全扔外部文件 - 内联后必须压缩：删空格、去注释、合并重复声明；否则内联本身就成了性能负担
-
<style media="(max-width: 768px)">这类条件样式，大屏设备不会解析，能进一步减少 CSSOM 构建压力
图片没写 width/height 怎么影响首屏渲染
没设宽高的 <img> 会让浏览器初始占位 0×0，等图片加载完成再重排布局。这不仅推后 LCP，还会触发 CLS，导致用户看到内容“跳一下”。
- 首屏图片严禁加
loading="lazy"：浏览器直接跳过加载，LCP 暴涨 - 所有
<img>必须带width和height属性，哪怕是用aspect-ratio: 16/9+object-fitfallback - SSR 页面中 JS 动态插入的图片，默认
loading="eager"，若想懒加载，得显式设置loading="lazy" - 首图建议加
fetchpriority="high"，在资源竞争时抢到更高带宽配额
真正卡首屏的从来不是 HTML 文件体积，而是它触发的阻塞行为。一个没写 width/height 的 <img>、一行 @import、一个没加 defer 的 <script>，都可能让 FCP 推迟 300ms 以上——这些细节不修，工具链再先进也救不了白屏。
