首屏白屏时间长的核心是HTML渲染阻塞，关键在于服务端直出轻量、内联、结构扁平的静态骨架HTML片段，而非JS动态插入；需同构标记（如data-skeleton）、内联Critical CSS、禁用阻塞资源，并按客户端能力精准降级。
首屏白屏时间长，核心是 HTML 渲染阻塞
服务端返回的 HTML 如果体积大、依赖多、结构深，浏览器就得等很久才画出第一帧。关键不是“加骨架屏”，而是让浏览器在 DOMContentLoaded 之前就能渲染出可感知的视觉占位——这要求 HTML 本身轻量、内联、结构扁平。
常见错误：把骨架屏做成 JS 动态插入的 div 块，等 JS 下载执行完才出现，反而延长首屏感知时间。
- 骨架屏必须是服务端直出的静态 HTML 片段，不依赖 JS
- 只保留最简语义结构：比如列表页用 3 个
<div class="skeleton-item"></div>，不用 SVG 或伪元素动画 - 所有样式必须内联（
<style>标签），避免额外 CSS 请求阻塞渲染 - 禁用
font-display: optional或未声明字体的文本节点，防止文字闪动掩盖骨架
HTML 骨架屏结构怎么写才不被移除或重绘
很多团队用 JS 框架生成骨架屏，但 SSR 输出时若没控制好 hydration 逻辑，React/Vue 可能直接替换掉服务端的骨架节点，导致“闪一下空白再出来内容”。根源在于客户端和服务器的 DOM 结构不一致。
真正可靠的写法是：骨架结构与真实结构保持同构，且用属性标记区分状态。
立即学习“前端免费学习笔记（深入）”；
- 用
data-skeleton属性标识骨架节点，例如：<div data-skeleton="true" class="card"></div> - 真实内容加载后，JS 只修改
data-skeleton值为false，再通过 CSS 控制显隐（[data-skeleton="true"] { background: #f0f0f0; }） - 避免在骨架节点里写
v-if或{% if %}条件，会导致 SSR 和 CSR 渲染树不匹配 - 图片占位统一用
<img src="data:image/svg+xml,%3Csvg...">内联 base64，不触发 HTTP 请求
内联样式怎么压缩又不影响可维护性
全量 CSS 内联会增大 HTML 体积，但抽离成外链又增加 RTT。折中方案是只内联“首屏必需样式”（Critical CSS），其他延迟加载。
手动提取容易漏，推荐构建时自动化：
- 用
critters（Vite/webpack 插件）自动提取<link rel="stylesheet">中首屏用到的选择器，注入<style> - 禁止在内联
<style>中使用@import、@media（部分老浏览器不支持） - 慎用 CSS 变量：若变量定义在外链 CSS 中，内联样式里引用会失效；必须保证变量也在内联块中声明
- 检查最终 HTML 中
<style>是否含注释或空行——某些 CDN 会 strip 掉，导致样式错乱
服务端如何判断该返回骨架还是真实 HTML
不能靠 User-Agent 或 UA 字符串做降级，移动端也需骨架；也不能对所有请求都返回骨架，影响 SEO 和爬虫。合理策略是按资源优先级 + 客户端能力决策。
- 用
Sec-CH-UA-Mobile或Save-Data请求头判断弱网/移动设备，返回精简骨架 - 对首次访问用户（无 Cookie）、或
navigationTiming.type === 'navigate'的请求，优先返回骨架 - 对搜索引擎爬虫（
User-Agent含Googlebot/Baiduspider），跳过骨架，直出真实结构+语义化标签 - 注意 Vary 响应头：若根据请求头做差异化输出，必须设置
Vary: Sec-CH-UA-Mobile, Save-Data, User-Agent，否则 CDN 可能缓存错版本
骨架屏不是视觉装饰，它是 HTML 渲染流水线里的一环。最容易被忽略的是：当服务端开启 Gzip/Brotli 时，内联样式里的重复类名（如多次出现的 skeleton-item）会极大影响压缩率——建议用短类名（sk-it）并统一构建时处理，否则白屏时间省了 200ms，传输却多花 300ms。
