Prueba de origen de Container Timing

Barry Pollard

Jason Williams

José Dapena Paz

Publicado el 1 de mayo de 2026

Chrome lanzará una prueba de origen desde Chrome 148 para la API de rendimiento de Container Timing.

Las métricas como Largest Contentful Paint (LCP) proporcionan una descripción general de cuándo es probable que el usuario considere que una página está "cargada" observando el tiempo de procesamiento del fragmento de contenido más grande. Sin embargo, los sitios también podrían estar interesados en saber cuándo se cargan partes específicas de la página, y no solo la parte "más grande".

Element Timing permite que los sitios marquen elementos con un atributo elementtiming para comprender cuándo se cargan, ya sea que sean el elemento LCP o no. Sin embargo, al igual que LCP, se limita a medir los tiempos de renderización de elementos individuales.

Container Timing extiende el concepto de Element Timing para medir "bloques de contenido" (o "contenedores"). Esto te permite comprender cuándo estuvo disponible para el usuario un componente completo, como widgets, tarjetas, secciones de contenido, barras laterales, etcétera. Proporciona información adicional sobre el rendimiento para los sitios que desean obtener estadísticas adicionales.

Container Timing, desarrollado por Bloomberg e implementado en Chrome por Igalia, está disponible detrás de una marca para los usuarios de Chrome y otros navegadores basados en Chromium, y también está disponible para que los sitios realicen pruebas en el campo a través de una prueba de origen.

Una prueba de origen es uno de los pasos finales del lanzamiento de una API en el que los desarrolladores pueden habilitar la función en sus sitios antes de que se lance de forma predeterminada para probarla y, luego, informar al equipo si funciona como se espera y resulta útil. También permite que los desarrolladores sugieran cambios en el diseño de la API antes del lanzamiento.

Cómo funciona la API de Container Timing

Al igual que Element Timing, Container Timing funciona agregando un atributo (containertiming) a varios elementos HTML para indicarle al navegador que se deben medir estos elementos:

<div containertiming="my-component">
  <h2>Title</h2>
  <div>...</div>
</div>

Luego, un PerformanceObserver te permite observar los procesamientos dentro de ese contenedor de la misma manera que otras métricas de rendimiento:

<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>

A medida que se procesan elementos nuevos en el contenedor, se emiten entradas de rendimiento nuevas con información actualizada. Dado que se pueden agregar elementos nuevos durante la vida útil de la página, no hay un solo punto de finalización. Esto es similar a LCP, que suele medirse al final de la página, cuando se navega fuera de ella.

Luego, estas métricas de rendimiento se pueden enviar a Analytics para su supervisión y análisis.

Los contenedores secundarios también se pueden ignorar con el atributo containertiming-ignore:

<div containertiming="main-content">

  <main>...</main>
  
  <!-- This aside and its children will be ignored -->
  <aside containertiming-ignore>...</aside>

</div>

Demostración

En el siguiente CodePen, se muestra la API de Container Timing en acción:

También puedes ver esto en acción en el siguiente video si tu navegador no admite la API de Container Timing:

¿Qué actualizaciones cuentan para Container Timing?

El objetivo de Container Timing es capturar cuándo se carga el contenedor con todos los elementos secundarios. No está diseñado para medir cada procesamiento futuro, muchos de los cuales pueden llegar mucho más tarde a medida que el usuario interactúa con el contenedor o la página. Por este motivo, al igual que LCP y Element Timing, Container Timing depende de los "procesamientos con contenido" y tampoco emite entradas de procesamiento nuevas para los elementos que ya se contaron como que tienen un procesamiento con contenido.

Por ejemplo, si un contenedor se renderiza inicialmente con solo un color de fondo o contiene solo elementos sin contenido (por ejemplo, pantallas de esqueleto), no se emitirá ninguna entrada container hasta que se agregue contenido al contenedor.

Para ver un ejemplo de actualización, la actualización de texto en un elemento existente en el contenedor no generará una entrada container nueva para esa actualización, ya que solo se considera el First Paint de contenido para un elemento. Sin embargo, si se agrega texto a un elemento vacío o se agrega un elemento nuevo adicional para ese texto, se emitirá una entrada container nueva, ya que será el First Paint de ese elemento.

Compatibilidad con Container Timing de detección de funciones

El atributo containertiming no causará problemas en los navegadores no compatibles, por lo que no es necesario detectar funciones.

PerformanceObserver ignorará las entradas nuevas, pero pueden causar advertencias en las Herramientas para desarrolladores, por lo que es una práctica recomendada detectar funciones antes de agregar un observador con código como el siguiente:

if (typeof PerformanceContainerTiming !== "undefined") {
  // Container Timing is supported
}

Prácticas recomendadas

Existen algunas prácticas recomendadas que debes seguir para un uso óptimo de Container Timing:

• Establece atributos con anticipación: Agrega el atributo containertiming en el documento HTML o antes de que se agregue el elemento al documento para realizar un seguimiento completo. Si agregas el atributo después con JavaScript, es posible que se pierdan procesamientos.
• Usa identificadores significativos: Elige nombres descriptivos para el atributo containertiming para facilitar el análisis.
• Ubicación estratégica: Aplica containertiming a las secciones semánticas que son importantes para tus métricas, por ejemplo, hero-section, product-grid, checkout-form. No es necesario medir todos los contenedores.
• Ignora el contenido irrelevante: Usa containertiming-ignore en los elementos secundarios que no deberían afectar las métricas de tus componentes, como anuncios o elementos decorativos.

¿Cómo habilitar Container Timing?

La API de Container Timing se puede habilitar desde Chrome 147 con la marca chrome://flags/#enable-experimental-web-platform-features y desde la línea de comandos con la marca --enable-blink-features=ContainerTiming.

A partir de Chrome 148, los sitios pueden registrarse para obtener un token de prueba de origen y agregarlo a su página para habilitar la función automáticamente. Esto te permite probar la API en el campo con usuarios reales. Las métricas de Container Timing se pueden registrar en Analytics y analizar para verificar si la API funciona como se espera y recopilar estadísticas.

Comentarios y más detalles

Los comentarios sobre la API de Container Timing deben plantearse como problemas en GitHub.

También hay una especificación que está pasando por el proceso de estandarización. Para aquellos interesados en cómo funciona esta API internamente, Igalia publicó una entrada sobre cómo se implementó técnicamente la API.

Conclusión

Es genial ver que esta API está a punto de lanzarse, y nos entusiasma ponerla en manos de los desarrolladores para permitir nuevas estadísticas sobre los problemas de rendimiento. Esperamos recopilar comentarios sobre la API y, si todo sale bien, lanzarla poco después.