Essai Origin Trial de Container Timing

Publié le : 1er mai 2026

Chrome lance une phase d'évaluation de l'origine à partir de Chrome 148 pour l'API Container Timing Performance.

Des métriques comme Largest Contentful Paint (LCP) fournissent un aperçu général du moment où une page est susceptible d'être considérée comme "chargée" par l'utilisateur en examinant le temps de rendu du plus grand élément de contenu. Toutefois, les sites peuvent également s'intéresser au moment où des parties spécifiques de la page sont chargées, et pas seulement la partie "la plus grande".

Element Timing permet aux sites de baliser des éléments avec un attribut elementtiming pour comprendre quand ils se chargent, qu'ils soient l'élément LCP ou non. Toutefois, comme le LCP, il se limite à mesurer les temps de rendu des éléments individuels.

Le timing des conteneurs étend le concept de timing des éléments pour mesurer les "blocs de contenu" (ou "conteneurs"). Cela vous permet de savoir quand un composant entier était disponible pour l'utilisateur (widgets, fiches, sections de contenu, barres latérales, etc.). Elle fournit des informations supplémentaires sur les performances pour les sites qui souhaitent obtenir des insights supplémentaires.

Container Timing, développé par Bloomberg et implémenté dans Chrome par Igalia, est disponible derrière un indicateur pour les utilisateurs de Chrome et d'autres navigateurs basés sur Chromium. Il est également disponible pour les sites qui souhaitent le tester sur le terrain grâce à un essai Origin Trial.

Un test d'origine est l'une des dernières étapes du lancement d'une API. Il permet aux développeurs d'activer la fonctionnalité sur leurs sites avant qu'elle ne soit lancée par défaut, afin de la tester et d'informer l'équipe si elle fonctionne comme prévu et si elle est utile. Il permet également aux développeurs de suggérer des modifications à la conception de l'API avant le lancement.

Fonctionnement de l'API Container Timing

Comme Element Timing, Container Timing fonctionne en ajoutant un attribut (containertiming) à différents éléments HTML pour indiquer au navigateur que ces éléments doivent être mesurés :

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

Un PerformanceObserver vous permet ensuite d'observer les peintures dans ce conteneur de la même manière que les autres métriques de performances :

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

À mesure que de nouveaux éléments sont peints dans le conteneur, de nouvelles entrées de performances sont émises avec des informations mises à jour. Comme de nouveaux éléments peuvent être ajoutés tout au long de la durée de vie de la page, il n'y a pas de point d'achèvement unique. Cela ressemble à la métrique LCP, qui est généralement mesurée à la fin de la page, lorsque l'utilisateur quitte la page.

Ces métriques de performances peuvent ensuite être renvoyées aux outils d'analyse pour la surveillance et l'analyse.

Les conteneurs enfants peuvent également être ignorés avec l'attribut containertiming-ignore :

<div containertiming="main-content">

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

</div>

Démo

Le CodePen suivant montre l'API Container Timing en action :

Démonstration du timing des conteneurs (source)

Vous pouvez également voir cela en action dans la vidéo suivante si votre navigateur n'est pas compatible avec l'API Container Timing :

Vidéo de démonstration de Container Timing (source)

Quelles mises à jour sont prises en compte pour le timing des conteneurs ?

L'objectif du timing du conteneur est de déterminer le moment où le conteneur est chargé avec tous les éléments enfants. Il n'est pas destiné à mesurer chaque futur affichage, dont beaucoup peuvent arriver beaucoup plus tard lorsque l'utilisateur interagit avec le conteneur ou la page. Pour cette raison, comme LCP et Element Timing, Container Timing dépend des "contentful paints" et n'émet pas non plus de nouvelles entrées de peinture pour les éléments qui ont déjà été comptabilisés comme ayant un contentful paint.

Par exemple, si un conteneur est initialement affiché avec une couleur d'arrière-plan uniquement ou ne contient que des éléments sans contenu (par exemple, des écrans squelettes), aucune entrée container ne sera émise tant qu'un contenu n'aura pas été ajouté au conteneur.

Par exemple, si vous mettez à jour le texte d'un élément existant dans le conteneur, aucune entrée container ne sera créée pour cette mise à jour, car seule la première peinture du contenu d'un élément est prise en compte. Toutefois, si du texte est ajouté à un élément vide ou si un nouvel élément supplémentaire est ajouté pour ce texte, une nouvelle entrée container sera émise, car il s'agira de la première peinture de cet élément.

Détection de la compatibilité avec Container Timing

L'attribut containertiming ne pose pas de problème pour les navigateurs non compatibles. Il n'est donc pas nécessaire de détecter les fonctionnalités.

PerformanceObserver ignorera toute nouvelle entrée, mais cela peut entraîner des avertissements dans les Outils de développement. Il est donc recommandé de détecter les fonctionnalités avant d'ajouter un observateur avec un code tel que :

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

Bonnes pratiques

Voici quelques bonnes pratiques à suivre pour utiliser de manière optimale le timing des conteneurs :

  • Définissez les attributs tôt : ajoutez l'attribut containertiming dans le document HTML ou avant que l'élément ne soit ajouté au document pour un suivi complet. Si vous ajoutez l'attribut après avec JavaScript, vous risquez de manquer des rendus.
  • Utilisez des identifiants pertinents : choisissez des noms descriptifs pour l'attribut containertiming afin de faciliter l'analyse.
  • Emplacement stratégique : appliquez containertiming aux sections sémantiques qui comptent pour vos métriques, par exemple hero-section, product-grid, checkout-form. Il n'est pas nécessaire de mesurer tous les conteneurs.
  • Ignorer le contenu non pertinent : utilisez containertiming-ignore sur les éléments enfants qui ne doivent pas affecter les métriques de votre composant, comme les annonces ou les éléments décoratifs.

Comment activer le timing des conteneurs ?

L'API Container Timing peut être activée à partir de Chrome 147 à l'aide de l'indicateur chrome://flags/#enable-experimental-web-platform-features et à partir de la ligne de commande à l'aide de l'indicateur --enable-blink-features=ContainerTiming.

À partir de Chrome 148, les sites peuvent s'enregistrer pour obtenir un jeton d'essai Origin Trial et l'ajouter à leur page pour activer automatiquement la fonctionnalité. Cela vous permet de tester l'API sur le terrain auprès d'utilisateurs réels. Les métriques de timing des conteneurs peuvent être enregistrées dans les données analytiques et analysées pour vérifier si l'API fonctionne comme prévu et recueillir des insights.

Commentaires et plus de détails

Les commentaires sur l'API Container Timing doivent être signalés en tant que problèmes sur GitHub.

Une spécification est également en cours de normalisation. Pour ceux qui souhaitent en savoir plus sur le fonctionnement interne de cette API, Igalia a publié un article sur son implémentation technique.

Conclusion

Nous sommes ravis de voir cette API bientôt disponible et nous avons hâte de la mettre à la disposition des développeurs pour leur permettre d'obtenir de nouvelles informations sur les problèmes de performances. Nous avons hâte de recueillir vos commentaires sur l'API et, si tout se passe bien, de la lancer peu de temps après.