Metriche

Pubblicato il 23 giugno 2022, ultimo aggiornamento il 13 ottobre 2026

Le metriche di CrUX sono basate sulle API della piattaforma web standard esposte dai browser. Nel set di dati BigQuery, in particolare, questi dati vengono aggregati alla risoluzione dell'origine. I proprietari di siti che richiedono un'analisi e insight più dettagliati (ad es. risoluzione a livello di URL) sul rendimento del proprio sito possono utilizzare le stesse API per raccogliere dati di misurazione utente reale (RUM) dettagliati per le proprie origini. Tieni presente che, sebbene tutte le API siano disponibili in Chrome, altri browser potrebbero non supportare l'insieme completo di metriche.

La maggior parte delle metriche è rappresentata come un'aggregazione di istogrammi, che consente la visualizzazione della distribuzione e l'approssimazione dei valori percentili.

Cumulative Layout Shift

Cumulative Layout Shift (CLS) è un'importante metrica incentrata sull'utente per misurare la stabilità visiva, perché aiuta a quantificare la frequenza con cui gli utenti riscontrano spostamenti imprevisti del layout. Una CLS bassa contribuisce a garantire che la pagina sia piacevole.

web.dev/articles/cls

DOM Content Loaded

"DOMContentLoaded indica il momento in cui il documento HTML iniziale è stato completamente caricato e analizzato, senza attendere il completamento del caricamento di fogli di stile, immagini e frame secondari."

MDN

Prima pittura

"Prima pittura indica il momento in cui il browser ha eseguito il primo rendering dopo la navigazione. Esclude la pittura dello sfondo predefinita, ma include la pittura dello sfondo non predefinita. Questo è il primo momento chiave a cui gli sviluppatori prestano attenzione durante il caricamento pagina, ovvero quando il browser ha iniziato a eseguire il rendering della pagina.

Paint Timing API

First Contentful Paint

"First Contentful Paint (FCP) indica il momento in cui il browser ha eseguito il primo rendering di testo, immagini (incluse le immagini di sfondo), canvas non bianco o SVG. Include il testo con webfont in attesa. Questa è la prima volta che gli utenti possono iniziare a utilizzare i contenuti della pagina."

Paint Timing API

Interaction to Next Paint

"Interaction to Next Paint (INP) è una metrica sul campo che valuta l'adattabilità. INP registra la latenza di tutte le interazioni durante l'intero ciclo di vita della pagina. Il valore più alto di queste interazioni, o un valore vicino al più alto per le pagine con molte interazioni, viene registrato come INP della pagina. Un INP basso garantisce che la pagina sia sempre adattabile in modo affidabile."

web.dev/articles/inp

Interaction to Next Paint (INP) è stato aggiunto al set di dati CrUX a febbraio 2022. Questa nuova metrica acquisisce la latenza end-to-end dei singoli eventi e offre un quadro più olistico dell'adattabilità complessiva di una pagina durante il suo ciclo di vita.

Largest Contentful Paint

"Largest Contentful Paint (LCP) è un'importante metrica incentrata sull'utente per misurare la velocità di caricamento percepita, perché indica il punto nella sequenza temporale di caricamento della pagina in cui è probabile che siano stati caricati i contenuti principali della pagina. Un LCP veloce rassicura l'utente sull'utilità della pagina."

web.dev/articles/lcp

Tipo di risorsa Largest Contentful Paint

"LCP indica il tempo di rendering dell'immagine, del blocco di testo o del video più grande visibile nell'area visibile rispetto a quando l'utente ha navigato per la prima volta alla pagina."

web.dev/articles/lcp - What elements are considered for LCP

Il testo e le immagini (inclusa l'immagine del primo fotogramma del video) hanno spesso caratteristiche di caricamento e tecniche di ottimizzazione molto diverse. Comprendere il rapporto tra i tipi di risorse LCP ti consente di comprendere meglio le metriche LCP e i percorsi di ottimizzazione.

Per ulteriori informazioni, consulta il post del blog sul lancio dei tipi di risorse LCP.

Sottoparti dell'immagine Largest Contentful Paint

"L'ottimizzazione per LCP può essere un'attività più complessa quando PageSpeed Insights non ti fornisce la risposta su come migliorare questa metrica. Con le attività complesse è generalmente meglio suddividerle in attività più piccole e gestibili e affrontarle separatamente."

web.dev/articles/optimize-lcp - LCP breakdown into subparts

Suddividere gli LCP delle immagini nelle relative sottoparti più importanti consente di utilizzare consigli e best practice specifici per l'ottimizzazione di ogni parte.

Le sottoparti delle immagini LCP sono fornite in quattro metriche separate:

  • largest_contentful_paint_image_time_to_first_byte
  • largest_contentful_paint_image_resource_load_delay
  • largest_contentful_paint_image_resource_load_duration
  • largest_contentful_paint_image_element_render_delay

Le sottoparti sono incluse solo per le immagini e non includono le immagini del primo fotogramma del video, in quanto sono un po' più complicate perché non possiamo misurare il tempo di download completo (tieni presente che i primi fotogrammi del video sono inclusi nella metrica del tipo di risorsa LCP, dove questa complicazione non è pertinente).

Anche le sottoparti del testo non sono incluse perché sono meno utili e distorcerebbero i numeri LCP delle immagini. Per i siti composti principalmente da LCP di testo, le metriche TTFB complessive e FCP complessive sono suddivisioni utili, anche se si applicano a tutti gli LCP e non solo agli LCP di testo.

Per ulteriori informazioni, consulta il post del blog sul lancio delle sottoparti delle immagini LCP.

La metrica tipi di navigazione fornisce una suddivisione della percentuale di visualizzazioni di pagina delle seguenti navigazioni:

Tipo Descrizione
navigate Un caricamento pagina che non rientra in nessuna delle altre categorie.
navigate_cache Un caricamento pagina per cui la risorsa principale (il documento HTML principale) è stata pubblicata dalla cache HTTP. I siti utilizzano spesso la memorizzazione nella cache per le risorse secondarie, ma il documento HTML principale viene spesso memorizzato nella cache in misura notevolmente inferiore e, quando è possibile, può comportare miglioramenti significativi delle prestazioni grazie alla possibilità di memorizzarlo nella cache localmente e in una CDN.
reload L'utente ha ricaricato la pagina premendo il pulsante di ricaricamento, premendo Invio nella barra degli indirizzi o annullando la chiusura di una scheda. I ricaricamenti delle pagine spesso comportano una nuova convalida sul server per verificare se la pagina principale è cambiata. Una percentuale elevata di ricaricamenti delle pagine può indicare frustrazioni dell'esperienza utente.
restore La pagina è stata ricaricata dopo il riavvio del browser o una scheda rimossa per motivi di memoria. Per Chrome su Android, questi vengono segnalati come "ricaricamento".
back_forward Una navigazione nella cronologia, il che significa che la pagina è stata visualizzata e visitata di recente. Con la memorizzazione nella cache corretta, queste dovrebbero essere esperienze ragionevolmente veloci, ma richiedono comunque l'elaborazione della pagina e l'esecuzione di JavaScript, entrambe le operazioni che la cache back-forward evita.
back_forward_cache Una navigazione nella cronologia pubblicata dalla cache back-forward. L'ottimizzazione delle pagine per sfruttare la cache back-forward, rimuovendo i blocchi, dovrebbe comportare esperienze più veloci, quindi i siti dovrebbero
prerender La pagina è stata sottoposta a prerendering, il che, in modo simile alla cache back-forward, può comportare caricamenti di pagina quasi istantanei.

In alcuni casi, un caricamento pagina può essere una combinazione di più tipi di navigazione. In questo caso, CrUX segnala la prima corrispondenza in ordine inverso della tabella (dal basso verso l'alto).

Per ulteriori informazioni, consulta il post dell'annuncio sui tipi di navigazione.

Onload

"L'evento di caricamento viene attivato quando la pagina e le relative risorse dipendenti hanno terminato il caricamento."

MDN

Tempo di round trip

Fornisce una stima del tempo di round trip HTTP (livello di applicazione) all'inizio della navigazione, in base alle connessioni di rete recenti. Questa metrica si basa sulla rtt proprietà dell'API Network Information, la stessa API responsabile della precedente dimensione Tipo di connessione efficace (ECT).

Per ulteriori informazioni, consulta il post del blog sul lancio dei tipi di risorse LCP.

Metriche sperimentali

Le metriche sperimentali sono disponibili sia nel set di dati CrUX utilizzando BigQuery sia nell'API CrUX, anche se non tutte le metriche sono disponibili in entrambi. Queste metriche sono soggette a modifiche in base al feedback degli utenti. Consulta le note di rilascio per rimanere aggiornato sulle ultime modifiche.

Metriche sperimentali di Core Web Vitals per la navigazione soft

La release di ottobre 2026 ha introdotto versioni sperimentali delle metriche di Core Web Vitals, inclusa la navigazione soft:

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

Queste metriche includono sia i caricamenti completi delle pagine sia le navigazioni soft.

Per ulteriori dettagli, consulta l'articolo Introducing experimental Core Web Vitals metrics to the Chrome UX Report.

Time to First Byte

TTFB in CrUX viene raccolto solo durante i caricamenti completi delle pagine, a differenza di altri timer (come LCP) che vengono raccolti anche durante le navigazioni nella cache back-forward e le pagine con prerendering. Di conseguenza, le dimensioni del campione di TTFB possono essere inferiori rispetto ad altre metriche e potrebbero non essere necessariamente confrontate direttamente con queste. TTFB in CrUX includerà i caricamenti di pagine a freddo, i caricamenti di pagine memorizzate nella cache e i caricamenti di pagine da una connessione stabilita (ad esempio, i caricamenti di pagine all'interno del sito).

TTFB non è una misura diretta del tempo di risposta del server, in quanto include misure precedenti, tra cui il tempo di reindirizzamento, e dipende dal fatto che una risposta venga pubblicata dalla cache, dalla CDN o dal server. Questo è particolarmente evidente nei dati sul campo come CrUX, mentre i test di laboratorio in genere sono meno influenzati da questi fattori, poiché l'URL finale viene testato e spesso nega ripetutamente le modifiche alla memorizzazione nella cache.

Popolarità

La metrica del ranking di popolarità è una misura relativa della popolarità del sito all'interno del set di dati CrUX, misurata in base al numero totale di navigazioni sull'origine. Il ranking è su una scala log10 con passaggi di metà (ad es. primi 1000, primi 5000, primi 10.000, primi 50.000, primi 100.000, primi 500.000, primi 1 milione e così via) e ogni ranking esclude il precedente (ad es. i primi 5000 sono in realtà 4000 URL, esclusi i primi 1000). Il limite superiore è dinamico man mano che il set di dati cresce.

La popolarità viene fornita come guida per l'analisi generale, ad esempio per determinare il rendimento per paese per le prime 1000 origini.

Autorizzazioni alle notifiche

Per i siti web che richiedono l'autorizzazione a mostrare le notifiche agli utenti, questa metrica rappresenta la frequenza relativa delle risposte degli utenti ai prompt: accetta, rifiuta, ignora o chiudi.

Metriche degli annunci

Chrome fornisce metriche e strumenti pubblici per i siti e altri, come gli inserzionisti, per comprendere meglio le esperienze pubblicitarie degli utenti reali e il loro impatto.

  • Numero di annunci: questa metrica descrive il numero di annunci che un utente tipico vede contemporaneamente sul sito.
  • Densità degli annunci: questa metrica descrive l'equilibrio tra i contenuti e la visibilità della pubblicità di un utente tipico.
  • Peso dell'annuncio: CPU: questa metrica descrive il consumo di CPU da parte degli annunci, che può influire sul rendimento.
  • Peso dell'annuncio: rete: questa metrica descrive il consumo di risorse di rete da parte degli annunci.

Prevediamo che queste metriche saranno particolarmente utili per gli inserzionisti web e i servizi che utilizzano per pubblicare annunci. Abbiamo ricevuto feedback da un'ampia gamma di stakeholder dell'ecosistema pubblicitario che indicano che queste metriche potrebbero migliorare il modo in cui valutano le opportunità pubblicitarie e prendono decisioni sui prodotti pubblicitari.

Per ulteriori informazioni, consulta il blog post sul lancio delle metriche degli annunci e la documentazione sulle misurazioni degli annunci.