你可能见过这种场景：LCP 分数很漂亮，但用户点进产品页，白屏了 2 秒才看见商品列表；或者结账按钮明明渲染了，但下面的支付表单迟迟不出来，用户以为坏了又刷新了一遍。LCP 只告诉你「最大的那个东西」什么时候出来，它从来不告诉你「这个组件」什么时候Ready。

Chrome 148 开始 Origin Trial 的 Container Timing API，就是来解决这个问题的。

## 它怎么工作的

LCP 是浏览器猜哪个元素最大；Element Timing 是你告诉浏览器「这个元素」重要。但一个产品卡片列表、一个结账表单、一个侧边栏推荐区——这些是多个元素组成的「块」，LCP 和 Element Timing 都拿它们没办法。

Container Timing 的思路很简单：给一个语义容器打标记，浏览器告诉你「这个容器里的内容什么时候painting完成」。

“`html

“`

“`javascript
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`${entry.identifier}: 渲染完成 at ${entry.renderTime}ms`);
// hero-section: 渲染完成 at 1243.5ms
// product-grid: 渲染完成 at 2871.2ms
// checkout-form: 渲染完成 at 3104.8ms
});
});

observer.observe({ type: “container”, buffered: true });
“`

entry 里有什么？identifier（你起的名字）、renderTime（实际绘制时间）、presentationTime、naturalWidth、naturalHeight，以及 element（DOM 引用）。和 Element Timing 完全一样的接口，上手零成本。

## 三个细节

**第一，只算内容ful paint。** 如果容器一开始只有背景色或骨架屏，API 不会触发；直到真实内容（图片、文字、背景图）出现才算完成。所以不用担心骨架屏阶段误报。

**第二，支持排除干扰子元素。** 广告、统计脚本这类不影响用户体验的内容，可以加上 `containertiming-ignore`，不纳入组件渲染时间统计。

“`html

“`

**第三，Feature Detection 写法。** 推荐这样写，而不是依赖 supportedEntryTypes，因为后者会freeze：

“`javascript
if (typeof PerformanceContainerTiming !== “undefined”) {
// Container Timing 支持
}
“`

## 怎么启用

从 Chrome 147 起，可以 chrome://flags 开启；Chrome 148 起可以注册 Origin Trial 令牌在实际用户身上测试。Firefox 和 Safari 暂时不支持，但 Chromium 市占率够大，生产环境可以渐进增强。

## 和已有 API 的关系

| API | 粒度 | 谁选 | 适合场景 |
|——|——|——|——|
| LCP | 单元素 | 浏览器（面积最大） | 页面级整体体验 |
| Element Timing | 单元素 | 你指定 | 某个特定关键元素 |
| Container Timing | 整个组件块 | 你指定 | 产品卡片组、结账流程、评论区 |

三者测的是同一个 paint 事件，只是「观测单元」不同。配合使用，诊断精度大幅提升。

## 下一步

如果你在做一个 RUM 系统，现在可以给每个关键业务模块挂上 `containertiming`：

1. 在 HTML 里给 hero/product-grid/checkout-form 加上 `containertiming` 属性
2. 用 PerformanceObserver 接收 entry，写入你的分析系统
3. 设定各组件的渲染预算（比如 product-grid 不超过 1500ms），超了告警

这样才真正知道用户在看页面时，「哪些部分」让他们觉得慢了。

—

*Chrome 148 Origin Trial，生产可用预计 2026 Q4。Feature Detection 写法已在生产环境中推荐。*