你以为页面慢只是因为资源太多？今天 Chrome 把 HTML 加载顺序彻底颠覆了

页面慢，99% 的前端第一反应是图片太大、JS 太多、没开 gzip。

但有一个隐藏了 30 年的性能杀手，很少有人注意到：HTML 只能从上往下顺序加载，整个 DOM 树必须等上一个区块的数据全部就绪才能渲染。如果你页面顶部有一个 900ms 的数据库查询，整个页面就算其他内容早就准备好了，也要干等。

这个瓶颈，Declarative Partial Updates 要从根上把它拔掉。

## 顺序加载扼杀了你的 LCP

为什么你的 LCP 分数总是卡在某个值上不去？

问题往往不在图片压缩没做好，而在于 HTML 的加载顺序。来看一个典型场景：

你写了一个产品详情页，页面结构从上到下是：Header → Hero 图片 → 产品描述 → 个性化推荐 → Footer。个性化推荐需要查数据库，耗时 900ms。

在传统模型下，服务器必须先查完推荐数据，才能开始写 HTML 字节流。浏览器收到响应时，推荐之前的所有内容都在排队等这个查询。用户看到的是一个不完整的页面，或者干脆是白屏直到所有东西都就绪。

这不是你的代码写得不好，是 HTTP 和 HTML 天生就是这样设计的——HTML 是流式文档，必须从上往下解析，遇到什么就渲染什么。你没法告诉浏览器”先放着这段，下面那块数据还在准备”。

## 用处理指令给 HTML 打补丁

Chrome 148 引入了 Declarative Partial Updates，这是一套 WHATWG 标准化的新 API。它的核心思路是：**在 HTML 里埋”占位符”，让服务器先发送骨架，空出来的位置稍后填充。**

具体用法分两步。

**第一步：埋标记。**

在 HTML 里放处理指令（Processing Instruction），作为内容空洞：

“`html

“`

“ 不会显示任何内容，浏览器看到它就当注释处理。但它是一个标记，声明”这里的内容稍后会补上”。

**第二步：服务器流式发送真实内容。**

当推荐数据查好后，服务器继续往同一个 HTTP 响应流里写：

“`html

• 推荐商品 A
• 推荐商品 B

“`

浏览器会自动找到 `for=”recommendations”` 对应的标记，把占位内容替换掉。整个过程不需要一行 JavaScript，浏览器自己的 HTML 解析器就完成了。

用户看到的变化是：Header 和 Hero 图片瞬间出现，推荐区块先显示”正在加载”，数据就绪后立即替换。整个过程没有闪烁，没有白屏，LCP 实际上是 Header 或 Hero 图片，而不是等整个页面。

## 你还可以在里面嵌套占位符

这个机制支持链式更新：

“`html

加载中…

“`

“ 和 “ 包裹的内容会先显示，直到真实内容到达。“ 则是一个持续占位符，后续还能继续往里塞内容——适合列表、评论流、动态加载等场景。

## 为什么不是用 JavaScript 解决？

你可能会问：这不就是服务端渲染 + 前端 fetch 拿数据然后塞进 DOM 吗？用 React Suspense 或者 Vue 的 async component 也能做到类似效果。

区别在于三个字：**不需要**。

框架方案本质上是：服务器先发 HTML 骨架 → 浏览器渲染 → JavaScript 下载执行 → 前端再发请求 → 数据返回后操作 DOM 更新。中间有 JS 下载和执行的等待时间，hydration 过程本身也会阻塞主线程。

Declarative Partial Updates 是直接修改了 HTML 解析器的工作方式。浏览器在流式解析 HTML 的过程中，遇到 “ 就会自动做 DOM 替换，没有额外的 JS 执行，没有 hydration，不依赖任何前端框架。

这个改法是浏览器内核级别的，零成本。

## 实战：如何用它优化 LCP

如果你的页面 LCP 元素是 Hero 图片，但图片之前有一段个性化内容的数据库查询，Declarative Partial Updates 可以让 Hero 图片先出现，用户感知到的加载速度会明显提升。

具体步骤：

1. 识别 LCP 元素所在区域以上的所有”慢”数据查询
2. 给这些区块加上 “ 占位符，显示骨架屏或加载状态
3. 服务器端确保先推送 LCP 相关 HTML，再流式发送其他内容
4. 用 `containertiming-ignore` 标注广告等不影响核心指标的区块

“`html

加载中…

这样一来，Hero 图片的渲染不再被推荐数据阻塞，LCP 时间戳会显著提前。

## 现状与兼容

Chrome 148 起，你需要打开 `chrome://flags/#enable-experimental-web-platform-features` 才能体验这个功能。Chrome 152（2026-08-25）已经进入稳定版，但 Declarative Partial Updates 仍在实验阶段。

Firefox 和 WebKit 目前未实现。如果你现在就想在生产环境用，可以考虑 Declarative Shadow DOM 方案作为降级——它的思路类似，但依赖 Shadow DOM。框架层面 Astro 已经支持类似的流式岛架构。

## 下一步

去找你的页面里耗时最长的那个服务端查询。如果它挡在了 LCP 元素之前，把那块内容用占位符处理掉，让快的先出来。

你不需要换框架，不需要等浏览器全面支持，今天就能用流式 HTML + 处理指令打补丁，把 LCP 往前推几个量级。