骨架屏本身不提升FCP，因其纯CSS灰色块非文本/图片等可绘制内容，且JS动态插入会延迟出现；唯有服务端直出含内联关键样式、结构扁平、带base64图片等可绘制节点的静态HTML片段，才能避免拖慢FCP。

骨架屏本身不提升FCP，反而可能拖慢它——除非你把它写成服务端直出的、无JS依赖、结构扁平、内联关键样式的静态HTML片段。

为什么骨架屏对FCP没用甚至有害

FCP（First Contentful Paint）测量的是浏览器首次绘制**文本、图片、 或 SVG 中的 元素**的时间。纯 CSS 模拟的灰色块（比如 .skeleton-rect）不是“内容”，只是背景色+渐变动画，不会触发 FCP。

更糟的是：如果骨架屏靠 JS 动态插入（例如 Vue 的 v-if="loading" 在 mounted 后才渲染），那它出现时间晚于 DOMContentLoaded，等于白屏期没缩短，还多占内存和样式计算开销。

• 常见错误现象：Lighthouse 报告里 FCP 依然 >2s，但页面明明“有骨架”了
• 根本原因：骨架节点是空
  ，没有 content；或骨架在 JS 执行后才挂载，HTML 解析器根本没看到它
• 性能陷阱：用 background: linear-gradient + 多层嵌套
  模拟卡片，DOM depth 轻易突破 7，直接拉长 HTML 解析耗时

  怎么写骨架屏才能不拖累FCP

  目标只有一个：让浏览器在解析完前几百字节 HTML 时，就遇到一个能被识别为“内容”的节点，并且这个节点不阻塞解析。

  

  DeepBI DHTML 页面生成器

  生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

  下载

  • 必须服务端直出，不能等 JS 加载后再生成 —— 即骨架 HTML 和真实 HTML 共享同一份 DOM 结构模板
  • 骨架节点需含至少一个“可绘制内容”：最稳妥是用 ，SVG 内联且体积可控（
  • 禁用所有非必要内联样式：把 .skeleton-header 这类 class 样式抽到 块里，但整个 必须 ≤10 KB（gzip 后），否则阻塞 HTML 解析
  • 结构深度 ≤5：用
    、
    替代
    堆叠；检查 DevTools → 右键节点 → “Show DOM properties” → 确认 depth

    data-skeleton 属性是 hydration 安全的关键

    React/Vue 项目最容易在 CSR 阶段把服务端骨架节点整个干掉，造成“闪白”——这不是视觉问题，是 DOM 不一致引发的强制重绘，间接推迟 FCP。

    • 服务端输出：
      
    • 客户端只改属性：el.setAttribute('data-skeleton', 'false')，不删不替，CSS 控制显隐：[data-skeleton="true"] { opacity: 0.7; }
    • 禁止在骨架区域用 v-for 或 {% for %} 动态生成结构，会导致 SSR/CSR 渲染树 mismatch
    • 真实内容加载完成前，data-skeleton="true" 节点必须保留在 DOM 中，且与后续真实节点一一对应（同级数量、顺序、key）

    Base64 图片骨架要卡住体积红线

    用 base64 图片撑起 FCP 是目前最可行的“合法”手段，但它极易翻车：一张 2KB 的 PNG 编码后变成 3KB base64 字符串，塞进 HTML 会显著增大首屏传输体积，尤其在 3G 网络下延迟更明显。

    • 必须用极简 SVG：仅 或 ，禁用 、、注释
    • 压缩工具必选：用 svgo --precision=1 --plugins=removeTitle,removeDesc，目标输出 ≤800B
    • 不要给 base64 图片加 width/height 属性，用 CSS 控制尺寸，避免 HTML 属性膨胀
    • 验证方式：打开 DevTools → Network → 刷页面 → 查看 document 类型响应体大小，确保骨架部分（含 base64）总长

    真正影响 FCP 的从来不是“有没有骨架”，而是骨架以什么形式出现在 HTML 流中、是否增加解析负担、是否引入额外阻塞点。很多团队花两周搭骨架屏工程，却忘了先跑一次 chrome://inspect 看看首屏 HTML 解析耗时——那才是 FCP 的命门。