Prova dell'origine Container Timing

Barry Pollard

Jason Williams

José Dapena Paz

Pubblicato il 01 maggio 2026

A partire da Chrome 148, Chrome lancerà una prova dell'origine per l'API Container Timing.

Metriche come Largest Contentful Paint (LCP) forniscono una panoramica di alto livello di quando è probabile che una pagina venga considerata "caricata" dall'utente esaminando il tempo di visualizzazione della parte di contenuti più grande. Tuttavia, i siti potrebbero essere interessati anche a quando vengono caricate parti specifiche della pagina e non solo la parte "più grande".

Element Timing consente ai siti di contrassegnare gli elementi con un attributo elementtiming per capire quando vengono caricati, indipendentemente dal fatto che siano l'elemento LCP o meno. Tuttavia, come LCP, è limitato alla misurazione dei tempi di rendering dei singoli elementi.

Container Timing estende il concetto di Element Timing per misurare "blocchi di contenuti" (o "container"). In questo modo, puoi capire quando un intero componente è stato reso disponibile all'utente, ad esempio widget, schede, sezioni di contenuti, barre laterali e così via. Fornisce informazioni aggiuntive sul rendimento per i siti che desiderano approfondire i dati che può fornire.

Container Timing, sviluppato da Bloomberg e implementato in Chrome da Igalia, è disponibile dietro un flag per gli utenti di Chrome e altri browser basati su Chromium ed è disponibile anche per i siti da testare sul campo tramite una prova dell'origine.

Una prova dell'origine è uno degli ultimi passaggi del lancio di un'API in cui gli sviluppatori possono attivare la funzionalità sui propri siti prima del lancio per impostazione predefinita per testarla e informare il team se funziona come previsto e se è utile. Consente inoltre agli sviluppatori di suggerire eventuali modifiche alla progettazione dell'API prima del lancio.

Come funziona l'API Container Timing

Come Element Timing, Container Timing funziona aggiungendo un attributo (containertiming) a vari elementi HTML per indicare al browser che questi elementi devono essere misurati:

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

Un PerformanceObserver ti consente quindi di osservare le visualizzazioni all'interno di quel container nello stesso modo delle altre metriche sul rendimento:

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

Man mano che vengono visualizzati nuovi elementi nel container, vengono emesse nuove voci di rendimento con informazioni aggiornate. Poiché è possibile aggiungere nuovi elementi durante la durata della pagina, non esiste un singolo punto di completamento. È simile a LCP, che in genere viene misurato alla fine della pagina, quando si esce dalla pagina.

Queste metriche sul rendimento possono essere inviate ad Analytics per il monitoraggio e l'analisi.

I container secondari possono anche essere ignorati con l'attributo containertiming-ignore:

<div containertiming="main-content">

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

</div>

Demo

Il seguente CodePen mostra l'API Container Timing in azione:

Puoi anche vedere questa funzionalità in azione nel seguente video se il tuo browser non supporta l'API Container Timing:

Quali aggiornamenti contano per Container Timing?

L'obiettivo di Container Timing è acquisire il momento in cui il container viene caricato con tutti gli elementi secondari. Non è progettato per misurare ogni singola visualizzazione futura, molte delle quali potrebbero arrivare molto più tardi quando l'utente interagisce con il container o la pagina. Per questo motivo, in modo simile a LCP ed Element Timing, Container Timing dipende dalle "visualizzazioni di contenuti" e non emette nuove voci di visualizzazione per gli elementi che sono già stati conteggiati come contenenti contenuti.

Ad esempio, se un container viene inizialmente sottoposto a rendering con un solo colore di sfondo o contenente solo elementi non contenenti contenuti (ad esempio, schermate scheletriche), non verrà emessa alcuna voce container finché non vengono aggiunti contenuti al container.

Per un esempio di aggiornamento, l'aggiornamento del testo su un elemento esistente nel container non comporterà una nuova voce container per quell'aggiornamento, perché viene considerata solo la First Paint dei contenuti di un elemento. Tuttavia, se viene aggiunto testo a un elemento vuoto o viene aggiunto un nuovo elemento aggiuntivo per quel testo, verrà emessa una nuova voce container perché sarà la First Paint di quell'elemento.

Rilevare il supporto di Container Timing

L'attributo containertiming non causa problemi per i browser non supportati, quindi non è necessario rilevarlo.

Il PerformanceObserver ignorerà le nuove voci, ma può causare avvisi in DevTools, quindi è una best practice rilevare la funzionalità prima di aggiungere un observer con codice come:

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

Best practice

Esistono alcune best practice da seguire per un utilizzo ottimale di Container Timing:

• Imposta gli attributi in anticipo: aggiungi l'attributo containertiming nel documento HTML o prima che l'elemento venga aggiunto al documento per un monitoraggio completo. L'aggiunta dell'attributo in un secondo momento con JavaScript potrebbe comportare la mancata visualizzazione.
• Utilizza identificatori significativi: scegli nomi descrittivi per l'attributo containertiming per semplificare l'analisi.
• Posizionamento strategico: applica containertiming alle sezioni semantiche importanti per le tue metriche, ad esempio hero-section, product-grid, checkout-form. Non è necessario misurare tutti i container.
• Ignora i contenuti irrilevanti: utilizza containertiming-ignore sugli elementi secondari che non devono influire sulle metriche dei componenti, ad esempio annunci o elementi decorativi.

Come attivare Container Timing?

L'API Container Timing può essere attivata da Chrome 147 utilizzando il flag chrome://flags/#enable-experimental-web-platform-features e dalla riga di comando utilizzando il flag --enable-blink-features=ContainerTiming.

A partire da Chrome 148, i siti possono registrarsi per un token di prova dell'origine e aggiungerlo alla pagina per attivare automaticamente la funzionalità. In questo modo, puoi testare l'API sul campo con utenti reali. Le metriche di Container Timing possono essere registrate in Analytics e analizzate per verificare se l'API funziona come previsto e raccogliere approfondimenti.

Feedback e ulteriori dettagli

Il feedback sull'API Container Timing deve essere segnalato come problemi su GitHub.

Esiste anche una specifica in fase di standardizzazione. Per chi è interessato al funzionamento interno di questa API, Igalia ha pubblicato un post su come è stata implementata tecnicamente l'API.

Conclusione

È fantastico vedere che questa API è in fase di rilascio e non vediamo l'ora di metterla a disposizione degli sviluppatori per consentire nuove informazioni sui problemi di prestazioni. Non vediamo l'ora di raccogliere feedback sull'API e, se tutto va bene, di lanciarla a breve.