Container Timing oorsprongsproef

Barry Pollard

Jason Williams

José Dapena Paz

Gepubliceerd: 1 mei 2026

Chrome lanceert vanaf Chrome 148 een origin-proef voor de Container Timing-prestatie-API .

Metrics zoals Largest Contentful Paint (LCP) geven een algemeen overzicht van wanneer een pagina waarschijnlijk als "geladen" wordt beschouwd door de gebruiker, door te kijken naar de laadtijd van het grootste deel van de content. Websites kunnen echter ook geïnteresseerd zijn in wanneer specifieke delen van de pagina worden geladen, en niet alleen het "grootste" deel.

Element Timing stelt websites in staat om elementen te markeren met een elementtiming attribuut om te begrijpen wanneer ze laden, ongeacht of het een LCP-element is of niet. Net als LCP is het echter beperkt tot het meten van de weergavetijden van individuele elementen.

Container Timing breidt het Element Timing-concept uit om 'contentblokken' (of 'containers') te meten. Hiermee kunt u inzicht krijgen in wanneer een volledig component beschikbaar was voor de gebruiker, zoals widgets, kaarten, contentsecties, zijbalken, enzovoort. Het biedt aanvullende prestatie-informatie voor websites die de extra inzichten willen benutten.

Container Timing, ontwikkeld door Bloomberg en geïmplementeerd in Chrome door Igalia, is beschikbaar achter een vlag voor Chrome-gebruikers en andere op Chromium gebaseerde browsers en kan ook door websites in de praktijk worden getest via een origin trial.

Een origin trial is een van de laatste stappen bij de lancering van een API. Tijdens deze test kunnen ontwikkelaars de functionaliteit op hun sites inschakelen voordat deze standaard beschikbaar komt. Zo kunnen ze de functionaliteit testen en het team laten weten of deze naar behoren werkt en nuttig blijkt. Het stelt ontwikkelaars ook in staat om eventuele wijzigingen in het API-ontwerp voor te stellen vóór de lancering.

Hoe de Container Timing API werkt

Net als Element Timing werkt Container Timing door een attribuut ( containertiming ) toe te voegen aan verschillende HTML-elementen om de browser te laten weten dat deze elementen gemeten moeten worden:

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

Met een PerformanceObserver kunt u vervolgens de verfactiviteit binnen die container observeren op dezelfde manier als andere prestatiemetingen:

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

Naarmate er nieuwe elementen in de container worden getekend, worden er nieuwe prestatiegegevens met bijgewerkte informatie gegenereerd. Omdat er gedurende de hele levensduur van de pagina nieuwe elementen kunnen worden toegevoegd, is er geen enkel eindpunt. Dit is vergelijkbaar met LCP (Lifetime Points), dat doorgaans wordt gemeten aan het einde van de pagina, wanneer er naar een andere pagina wordt genavigeerd.

Deze prestatiegegevens kunnen vervolgens naar de analyseafdeling worden teruggestuurd voor monitoring en analyse.

Kindcontainers kunnen ook worden genegeerd met het attribuut containertiming-ignore :

<div containertiming="main-content">

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

</div>

Demo

De volgende CodePen laat de Container Timing API in actie zien:

Als uw browser de Container Timing API niet ondersteunt, kunt u dit ook in actie zien in de volgende video:

Welke updates tellen mee voor de containertiming?

Het doel van Container Timing is om vast te leggen wanneer de container volledig is geladen met alle onderliggende elementen. Het is niet de bedoeling om elke toekomstige paint te meten – veel daarvan kunnen pas veel later plaatsvinden, wanneer de gebruiker interactie heeft met de container of de pagina. Om die reden is Container Timing, net als LCP en Element Timing, afhankelijk van "contentful paints" en genereert het geen nieuwe paint-meldingen voor elementen die al zijn geteld als zijnde voorzien van een contentful paint.

Als een container bijvoorbeeld in eerste instantie alleen een achtergrondkleur heeft of alleen niet-inhoudelijke elementen bevat (zoals bijvoorbeeld een sjabloonscherm), wordt er geen container item gegenereerd totdat er inhoud aan de container wordt toegevoegd.

Een voorbeeld van een update: het bijwerken van tekst op een bestaand element in de container resulteert niet in een nieuwe container voor die update, omdat alleen de eerste weergave van de inhoud voor een element in aanmerking komt. Als er echter tekst wordt toegevoegd aan een leeg element, of als er een nieuw element wordt toegevoegd voor die tekst, dan wordt er wel een nieuwe container gegenereerd, omdat dit de eerste weergave van dat element is.

Functiedetectie Container Timing-ondersteuning

Het attribuut containertiming zal geen problemen veroorzaken voor browsers die het niet ondersteunen, dus hoeft het niet te worden gedetecteerd.

De PerformanceObserver negeert alle nieuwe vermeldingen, maar deze kunnen waarschuwingen in DevTools veroorzaken. Daarom is het raadzaam om eerst te controleren of er nieuwe vermeldingen zijn voordat u een observer toevoegt, bijvoorbeeld met code zoals:

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

Beste praktijken

Er zijn een aantal goede werkwijzen die u kunt volgen voor optimaal gebruik van Container Timing:

• Stel attributen vroegtijdig in: Voeg het containertiming attribuut toe aan het HTML-document, of voordat het element aan het document wordt toegevoegd, voor volledige tracking. Het achteraf toevoegen van het attribuut met JavaScript kan leiden tot gemiste weergavemomenten.
• Gebruik betekenisvolle identificatoren: Kies beschrijvende namen voor het attribuut containertiming om analyses te vereenvoudigen.
• Strategische plaatsing: Pas containertiming toe op semantische secties die relevant zijn voor uw statistieken, bijvoorbeeld hero-section , product-grid en checkout-form . Niet elke container hoeft te worden gemeten.
• Negeer irrelevante inhoud: Gebruik containertiming-ignore voor kindelementen die geen invloed mogen hebben op de componentstatistieken, zoals advertenties of decoratieve elementen.

Hoe schakel ik containertiming in?

De Container Timing API kan worden ingeschakeld vanuit Chrome 147 met de vlag chrome://flags/#enable-experimental-web-platform-features en via de commandoregel met de vlag --enable-blink-features=ContainerTiming .

Vanaf Chrome 148 kunnen websites zich registreren voor een Origin-proeftoken en dit aan hun pagina toevoegen om de functie automatisch in te schakelen. Hiermee kunt u de API in de praktijk testen met echte gebruikers. Container Timing-statistieken kunnen worden vastgelegd in Analytics en geanalyseerd om te controleren of de API naar behoren werkt en om inzichten te verkrijgen.

Feedback en meer details

Feedback over de Container Timing API kunt u melden als issues op GitHub .

Er is ook een specificatie die momenteel het standaardisatieproces doorloopt. Voor geïnteresseerden in de interne werking van deze API heeft Igalia een artikel gepubliceerd over de technische implementatie ervan .

Conclusie

Het is fantastisch dat deze API bijna klaar is voor release en we zijn enthousiast om hem beschikbaar te stellen aan ontwikkelaars, zodat zij nieuwe inzichten kunnen verkrijgen in prestatieproblemen. We kijken ernaar uit om feedback over de API te verzamelen en, als alles goed gaat, deze kort daarna te lanceren.