发布时间：2026 年 5 月 1 日
Chrome 将从 Chrome 148 开始针对 Container Timing 性能 API 启动 源试用。
Largest Contentful Paint (LCP) 等指标通过查看最大内容块的绘制时间，大致了解用户何时可能会将网页视为“已加载”。不过，网站可能还想了解网页的特定部分何时加载，而不仅仅是“最大”部分。
借助 Element Timing，网站可以使用 elementtiming 属性标记元素，以了解这些元素何时加载，无论它们是否为 LCP 元素。不过，与 LCP 类似，它只能衡量各个元素的渲染时间。
Container Timing 将 Element Timing 概念扩展为衡量“内容块”（或“容器”）。这样，您就可以了解整个组件何时可供用户使用，例如微件、卡片、内容部分、边栏等。它为想要获得额外洞察信息的网站提供了额外的性能信息。
Container Timing 由 Bloomberg 开发，由 Igalia 在 Chrome 中实现，Chrome 用户和其他基于 Chromium 的浏览器可以通过标志使用此功能，网站也可以通过源试用在实际环境中进行测试。
源试用是发布 API 的最后几个步骤之一，开发者可以在默认发布之前在其网站上启用该功能以进行测试，并告知团队该功能是否按预期运行且证明有用。它还允许开发者在发布之前建议对 API 设计进行任何更改。
Container Timing API 的工作原理
与 Element Timing 类似，Container Timing 的工作原理是将属性 (containertiming) 添加到各种 HTML 元素，以向浏览器指明应衡量这些元素：
<div containertiming="my-component">
<h2>Title</h2>
<div>...</div>
</div>
然后，PerformanceObserver 可让您以与其他性能指标相同的方式观察该容器内的绘制：
<script>
const observer = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log("Container painted:", entry.identifier);
console.log("First render:", entry.firstRenderTime);
console.log("Latest paint:", entry.startTime);
console.log("Painted area:", entry.size);
console.log("Last painted element:", entry.lastPaintedElement);
}
});
observer.observe({ type: "container", buffered: true });
</script>
随着容器中绘制新元素，系统会发出包含更新信息的新性能条目。由于可以在网页的整个生命周期内添加新元素，因此没有单一的完成点。这与 LCP 类似，LCP 通常在网页结束时（即导航离开时）进行衡量。
然后，这些性能指标可以发送回分析系统进行监控和分析。
您还可以使用 containertiming-ignore 属性忽略子容器：
<div containertiming="main-content">
<main>...</main>
<!-- This aside and its children will be ignored -->
<aside containertiming-ignore>...</aside>
</div>
演示
以下 CodePen 展示了 Container Timing API 的实际应用：
如果您的浏览器不支持 Container Timing API，您还可以在以下视频中看到它的实际应用：
哪些更新计入 Container Timing？
Container Timing 的目的是捕获容器何时加载所有子元素。它并非旨在衡量未来的每一次绘制，其中许多绘制可能会在用户与容器或网页互动时稍后到达。因此，与 LCP 和 Element Timing 类似，Container Timing 依赖于“内容绘制”，并且不会为已被计为具有内容绘制的元素发出新的绘制条目。
例如，如果容器最初仅使用背景颜色进行渲染，或者仅包含非内容元素（例如骨架屏幕），则在向容器添加一些内容之前，不会发出任何 container 条目。
对于更新示例，更新容器中现有元素上的文本不会导致该更新出现新的 container 条目，因为系统只会考虑元素的首次渲染。不过，如果向空元素添加文本，或者为该文本添加其他新元素，则会发出新的 container 条目，因为这将是该元素的首次绘制。
检测 Container Timing 支持
containertiming 属性不会导致不支持的浏览器出现问题，因此无需进行功能检测。
PerformanceObserver 会忽略任何新条目，但它们可能会在开发者工具中导致警告，因此最佳实践是在添加观察器之前进行功能检测，例如使用以下代码：
if (typeof PerformanceContainerTiming !== "undefined") {
// Container Timing is supported
}
最佳实践
为了充分利用 Container Timing，请遵循以下最佳实践：
- 尽早设置属性 ：在 HTML 文档中添加
containertiming属性，或在将元素添加到文档之前添加该属性，以进行完整跟踪。之后使用 JavaScript 添加该属性可能会导致绘制遗漏。 - 使用有意义的标识符 ：为
containertiming属性选择描述性名称，以便更轻松地进行分析。 - 策略性放置 ：将
containertiming应用于对指标很重要的语义部分，例如hero-section、product-grid、checkout-form。并非每个容器都需要衡量。 - 忽略不相关的内容 ：对不应影响组件指标的子元素（例如广告或装饰性元素）使用
containertiming-ignore。
如何启用 Container Timing？
从 Chrome 147 开始，可以使用 chrome://flags/#enable-experimental-web-platform-features 标志启用 Container Timing API，也可以从命令行使用 --enable-blink-features=ContainerTiming 标志启用。
从 Chrome 148 开始，网站可以注册源试用令牌并将其添加到网页中，以自动启用该功能。这样，您就可以在实际用户身上测试 API。Container Timing 指标可以记录在分析系统中并进行分析，以验证 API 是否按预期运行并收集洞察信息。
反馈和更多详情
有关 Container Timing API 的反馈应在 GitHub 上以 问题形式提出。
此外，还有一项规范正在标准化过程中。对于那些对该 API 的内部工作原理感兴趣的人，Igalia 发布了一篇关于该 API 在技术上是如何实现的博文。
总结
很高兴看到此 API 即将发布，我们也很期待让开发者使用它，以便深入了解性能问题。我们期待收集有关该 API 的反馈，如果一切顺利，我们将很快发布该 API。