首屏白屏时间长主因是HTML触发的阻塞行为，非HTML本身慢；应通过DevTools Network面板查看document的Waterfall，若TTFB＞200ms则服务端慢，否则瓶颈在script同步执行、CSS未拆分、img缺尺寸等。
首屏白屏时间长，八成不是 HTML 文件本身慢，而是它触发的阻塞行为没处理好——script 同步执行、link rel="stylesheet" 未拆分关键/非关键、img 缺尺寸或未懒加载，这些才是真瓶颈。
怎么确认 HTML 是不是真慢？别猜，看 Network 水流图
打开 Chrome DevTools → Network 标签页 → 勾选 Disable cache → 刷新页面。重点看 document 请求的 Waterfall：
- 如果
document的 TTFB（Time to First Byte）超过 200ms，问题在服务端：Nginx 未启用 Gzip/Brotli、Node.js 渲染模板太重、数据库查询拖慢 HTML 生成 - 如果
document很快（main.css 或app.js横在渲染路径上，说明是资源加载顺序和属性配置问题 - 注意
index.html的Priority是否为Highest；如果不是，可能是服务器未正确设置Content-Type: text/html或响应头干扰了浏览器解析优先级
script 标签加 defer 还是 async？看它是否依赖 DOM
defer 和 async 都能避免阻塞 HTML 解析，但执行时机完全不同：
- 用
defer：脚本需操作 DOM（比如初始化 Vue/React 应用、绑定事件），且多个脚本之间有执行顺序依赖 → 浏览器会按出现顺序，在 DOM 解析完成后、DOMContentLoaded前执行 - 用
async：纯统计类、无 DOM 依赖、可随时执行的脚本（如analytics.js）→ 下载完立刻执行，不保证顺序，也不等 DOM 就绪 - 严禁写
<script src="app.js"></script>（无属性）：这是同步阻塞模式，HTML 解析直接暂停，用户看到的就是白屏 -
type="module"默认等效于defer，还支持静态导入分析，现代项目可直接用，但注意旧版 Safari 兼容性
CSS 怎么内联才不破坏可维护性？只内联「首屏必需」部分
内联全部 CSS 是反模式。真正该内联的，仅限首屏渲染立即需要的样式（比如 header、导航栏、首屏按钮、文字排版）：
立即学习“前端免费学习笔记（深入）”；
- 用工具提取 critical CSS：如
criticalnpm 包或 Webpack 插件html-critical-webpack-plugin，输入 HTML + CSS，输出内联片段 - 内联内容必须放在
<head>中的<style>标签里，不能放<body>或注释后 - 非关键 CSS 用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟加载，避免阻塞渲染 - 绝对禁用
@import引入关键样式：它强制串行请求，比<link>多一次网络往返，实测拖慢 FCP 300ms+
图片不加 width/height 为什么会导致白屏延长？
浏览器无法预知 img 尺寸时，会先占位 0×0，等图片加载完成再重排布局（layout shift）。这不仅影响 CLS（累积布局偏移）指标，还会延迟 LCP（最大内容绘制）判定：
- 所有首屏
img必须带width和height属性（非 CSS），让浏览器提前分配空间 - 响应式场景下，可用
aspect-ratio替代（如style="aspect-ratio: 16/9;"），兼容性稍差但更灵活 - 首屏大图加
loading="eager"，非首屏统一加loading="lazy"；但别对loading="lazy"的图再加preload，可能触发重复请求 - WebP/AVIF 格式替换 JPEG/PNG，体积常减少 30%~50%，配合
<picture>提供 fallback，不增加 HTML 复杂度
最容易被忽略的是：优化必须从真实指标出发。LCP 不达标，别急着压缩 HTML；先查它是被哪张图或哪个文本块拖慢的；CLS 高，就检查所有没设尺寸的媒体元素；TTFB 高，就别折腾 defer —— 服务端才是根因。
