写过性能优化的人都踩过这个坑——每次想测某个组件什么时候渲染完成，只能靠感觉或者猜整页 LCP。今天 Chrome 148 把这件事精确到了每个 DOM 区块。

写过性能优化的人都踩过这个坑——每次想测某个组件什么时候渲染完成，只能靠感觉或者整个页面的 LCP 指标猜。这个组件到底卡在哪？是骨架屏还在还是内容没刷出来？说不清。Chrome 148 正在测试一个 API，把这件事精确到了每个语义化的 DOM 区块。

问题：整页 LCP 看不到组件级细节

现有性能 API 各有分工。LCP 只看整页最大内容块，适合判断「首页有没有出来」。Element Timing 能标注单个元素的渲染时间，但要测一个 product-grid 整体、或一个 checkout-form 刷完，你需要给每个子元素都加标注，工程成本高，而且动态内容场景根本追不上。

Container Timing API 的思路完全不同——给一个容器区块整体计时，区块内第一个内容绘制品出现时，就记录一次性能条目。不需要逐子元素标注，不依赖框架，打个属性就行。

怎么用：两行代码 + PerformanceObserver

给任意 HTML 元素加 containertiming 属性，再用 PerformanceObserver 订阅：

// Feature detection
if (typeof PerformanceContainerTiming === "undefined") return;

// 在 HTML 里直接打标记
<div containertiming="product-grid">...</div>
<div containertiming="checkout-form">...</div>

// JS 里订阅
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    console.log(`${entry.name}: ${entry.renderTime}ms`);
    // entry.startTime / entry.renderTime / entry.size
  });
});
observer.observe({ type: "container", buffered: true });

属性值就是你在分析工具里看到的名字，建议用语义化名称：hero-section、product-grid、checkout-form。

三个最佳实践

一、尽早打标记。 属性最好在 HTML 里直接写死，或者在元素 appendChild 之前就设好。渲染之后再加属性能会漏掉初次绘制。

二、排除不相关的内容。 广告、装饰性元素这些不应该计入组件加载时间，用 containertiming-ignore 标注它们，API 会自动跳过。

<div containertiming="product-grid">
  <header>...</header>
  <div containertiming-ignore>广告位</div>
  <main>产品列表</main>
</div>

三、只测有意义的部分。 骨架屏、背景色不会触发 contentful paint——这和 LCP 的逻辑一致。如果容器里只有骨架没有真实内容，API 不会发射条目，直到文字、图片等真实内容渲染出来。

和 LCP / Element Timing 的区别

LCP 是全页级别的，只报一个最大块。Element Timing 可以标注单个元素，但需要逐个加 elementtiming。Container Timing 给整个语义区块打一个时间点，更符合组件化开发思路——你想知道的是「这个卡片什么时候可用」，而不是「卡片里第三行文字的 img 什么时候绘制的」。

浏览器支持

Chrome 147 可以开 flag 体验（chrome://flags/#enable-experimental-web-platform-features），Chrome 148 起支持 origin trial（网站申请 token 即可在生产流量上灰度）。Edge 也同步上了微软的 origin trial。Firefox 态度积极，正在实现中。Safari 暂无表态。

下一步

如果你在搭前端性能监控体系，把 Container Timing 加进去是最低成本的一步——一个 HTML 属性 + 一个 PerformanceObserver，就能拿到以前只有定制探针才能采集的组件级渲染数据。骨架屏还在不在、某个懒加载模块到底卡了多久，现在可以开箱即得。