Storicamente, per gli sviluppatori web era sempre difficile misurare la velocità con cui i contenuti principali di una pagina web si caricano e sono visibili agli utenti. Le metriche meno recenti come load o DOMContentLoaded non funzionano bene perché non corrispondono necessariamente a ciò che l'utente vede sullo schermo. Inoltre, le metriche sul rendimento più recenti incentrate sugli utenti, come First Contentful Paint (FCP), registrano solo l'inizio dell'esperienza di caricamento. Se una pagina mostra una schermata iniziale o un indicatore di caricamento, questo momento non è molto pertinente per l'utente.
In passato, abbiamo consigliato metriche sul rendimento come First Meaningful Paint (FMP) e Speed Index (SI) (entrambi disponibili in Lighthouse) per acquisire una maggiore quantità di esperienza di caricamento dopo la visualizzazione iniziale. Tuttavia, si tratta di metriche complesse, difficili da spiegare e spesso errate, che non consentono ancora di identificare il momento in cui sono stati caricati i contenuti principali della pagina.
Dalle discussioni all'interno del W3C Web Performance Working Group e da una ricerca svolta da Google, abbiamo scoperto che un modo più preciso per misurare il caricamento dei contenuti principali di una pagina consiste nell'osservare quando viene visualizzato l'elemento più grande.
Che cos'è LCP?
La metrica LCP indica il tempo di rendering del blocco di immagini o di testo più grande visibile nell'area visibile, in relazione al momento in cui l'utente ha raggiunto per la prima volta la pagina.
Cos'è un buon punteggio LCP?
Per offrire una buona esperienza utente, i siti devono cercare di ottenere Largest Contentful Paint di 2,5 secondi o meno. Per assicurarti di raggiungere questo target per la maggior parte degli utenti, una buona soglia da misurare è il 75° percentile dei caricamenti delle pagine, segmentato tra dispositivi mobili e computer.
Quali elementi vengono presi in considerazione?
Come attualmente specificato nella sezione Largest Contentful Paint API, i tipi di elementi considerati per il Largest Contentful Paint sono:
- Elementi
<img>
(la tempo di presentazione del primo frame viene utilizzata per i contenuti animati come GIF o PNG animati) <image>
elementi all'interno di un elemento<svg>
- Elementi
<video>
(per i video viene utilizzato il tempo di caricamento dell'immagine poster o il tempo di presentazione del primo frame, a seconda di quale delle due situazioni si verifica per primo) - Un elemento con un'immagine di sfondo caricata tramite la funzione
url()
(al contrario di un gradiente CSS) - Elementi a livello di blocco che contengono nodi di testo o altri elementi di testo secondari a livello incorporato.
Tieni presente che la limitazione degli elementi a questo insieme limitato era intenzionale per semplificare le cose all'inizio. In futuro potrebbero essere aggiunti altri elementi (come il supporto completo di <svg>
) man mano che verranno condotte ulteriori ricerche.
Oltre a prendere in considerazione solo alcuni elementi, le misurazioni LCP utilizzano euristiche per escludere determinati elementi che gli utenti potrebbero vedere come "senza contenuti". Per i browser basati su Chromium, sono inclusi:
- Elementi con un'opacità pari a 0, che non sono visibili all'utente.
- Elementi che coprono l'intera area visibile, che sono probabilmente considerati come sfondo anziché come contenuti.
- Immagini segnaposto o altre immagini con bassa entropia, che probabilmente non riflettono i contenuti effettivi della pagina
È probabile che i browser continuino a migliorare queste euristiche per assicurarci di soddisfare le aspettative degli utenti in merito all'elemento contenuto più grande.
Questi contenuti "contenenti" euristiche possono essere diverse da quelle utilizzate dalla prima visualizzazione con contenuti (FCP), che potrebbe prendere in considerazione alcuni di questi elementi, come immagini segnaposto o immagini visibili a schermo intero, anche se non sono idonee a essere candidati LCP. Nonostante entrambi usino contenuti "contenti" nel loro nome, lo scopo di queste metriche è diverso. Il valore FCP misura quando qualsiasi contenuto viene visualizzato sullo schermo e LCP quando i contenuti principali vengono visualizzati in modo che l'LCP sia più selettivo.
Come vengono determinate le dimensioni di un elemento?
Le dimensioni dell'elemento riportate per LCP sono in genere quelle visibili all'utente all'interno dell'area visibile. Se l'elemento si estende all'esterno dell'area visibile o se uno o più elementi sono ritagliati o presentano overflow non visibile, queste parti non vengono conteggiate ai fini delle dimensioni dell'elemento.
Per gli elementi immagine che sono stati ridimensionati rispetto alle dimensioni intrinseche, la dimensione segnalata è la dimensione visibile o la dimensione intrinseca, a seconda di quale sia la più piccola.
Per gli elementi di testo, LCP prende in considerazione solo il rettangolo più piccolo che può contenere tutti i nodi di testo.
Per tutti gli elementi, LCP non prende in considerazione margini, spaziature interne o bordi applicati utilizzando CSS.
Quando viene segnalato l'LCP?
Le pagine web vengono spesso caricate in fasi e, di conseguenza, è possibile che l'elemento più grande della pagina cambi.
Per gestire questo potenziale cambiamento, il browser invia un elemento PerformanceEntry
di tipo largest-contentful-paint
che identifica l'elemento con contenuti più grande non appena il browser ha dipinto il primo frame. Poi, dopo aver eseguito il rendering dei frame successivi, invierà un altro PerformanceEntry
ogni volta che l'elemento con contenuti più grande viene modificato.
Ad esempio, in una pagina con testo e un'immagine hero, il browser potrebbe inizialmente visualizzare solo il testo e a quel punto il browser invierà una voce largest-contentful-paint
la cui proprietà element
probabilmente farà riferimento a <p>
o <h1>
. In seguito, al termine del caricamento dell'immagine hero, viene inviata una seconda voce largest-contentful-paint
e la relativa proprietà element
farà riferimento a <img>
.
Un elemento può essere considerato l'elemento con contenuti più grande solo dopo essere stato visualizzato ed è visibile all'utente. Le immagini che non sono ancora state caricate non vengono considerate "sottoposte a rendering". Neanche i nodi di testo che utilizzano caratteri web durante il periodo di blocco dei caratteri. In questi casi, un elemento più piccolo potrebbe essere indicato come l'elemento con contenuti più grande, ma non appena termina il rendering dell'elemento più grande, viene creato un altro PerformanceEntry
.
Oltre al caricamento tardivo di immagini e caratteri, una pagina potrebbe aggiungere nuovi elementi al DOM quando diventano disponibili nuovi contenuti. Se uno di questi nuovi elementi è più grande del precedente elemento con contenuti più grande, verrà registrato anche un nuovo PerformanceEntry
.
Se l'elemento con contenuti più grande viene rimosso dall'area visibile o anche dal DOM, rimane l'elemento con contenuti più grande, a meno che non venga visualizzato un elemento più grande.
Il browser smetterà di segnalare le nuove voci non appena l'utente interagisce con la pagina (tramite un tocco, uno scorrimento o la pressione di un tasto), poiché l'interazione dell'utente spesso cambia ciò che è visibile all'utente (in particolare quando l'utente scorre la pagina).
A scopo di analisi, devi segnalare al tuo servizio di analisi solo l'elemento PerformanceEntry
inviato più di recente.
Tempo di caricamento e tempo di rendering
Per motivi di sicurezza, il timestamp di rendering delle immagini non viene esposto per le immagini multiorigine senza l'intestazione Timing-Allow-Origin
. Viene invece esposto solo il tempo di caricamento (poiché questo è già esposto da molte altre API web).
Ciò può portare a una situazione apparentemente impossibile in cui le API web segnalano LCP prima di FCP. Questo non è il caso, ma appare solo a causa di questa limitazione di sicurezza.
Quando possibile, consigliamo sempre di impostare l'intestazione Timing-Allow-Origin
in modo che le metriche siano più accurate.
Come vengono gestite le modifiche al layout e alle dimensioni degli elementi?
Per mantenere basso l'overhead delle prestazioni legato al calcolo e all'invio di nuove voci relative al rendimento, le modifiche alla dimensione o alla posizione di un elemento non generano nuovi candidati LCP. Vengono prese in considerazione solo le dimensioni e la posizione iniziali dell'elemento nell'area visibile.
Ciò significa che le immagini che inizialmente vengono visualizzate al di fuori dello schermo e poi passano sullo schermo potrebbero non essere segnalate. Ciò significa anche che gli elementi inizialmente visualizzati nell'area visibile e poi spostati verso il basso fuori dalla visualizzazione continueranno a indicare le dimensioni iniziali dell'area visibile.
Esempi
Ecco alcuni esempi di quando la visualizzazione Largest Contentful Paint viene eseguita su alcuni siti web noti:
![Sequenza temporale di Largest Contentful Paint da cnn.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-fc43128e011aa.png?authuser=5&hl=it)
![Sequenza temporale di Largest Contentful Paint da techcrunch.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-3713e2f14970a.png?authuser=5&hl=it)
In entrambe le sequenze temporali riportate sopra, l'elemento più grande cambia man mano che vengono caricati i contenuti. Nel primo esempio, vengono aggiunti nuovi contenuti al DOM, cambiando così l'elemento più grande. Nel secondo esempio, il layout cambia e i contenuti che in precedenza erano i più grandi vengono rimossi dall'area visibile.
Sebbene capita spesso che i contenuti caricati in ritardo siano maggiori di quelli già presenti nella pagina, non è necessariamente così. I due esempi successivi mostrano l'evento LCP che si verifica prima del caricamento completo della pagina.
![Sequenza temporale di Largest Contentful Paint da instagram.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-9bc403e812154.png?authuser=5&hl=it)
![Sequenza temporale di Largest Contentful Paint da google.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-6c5554de0eac7.png?authuser=5&hl=it)
Nel primo esempio, il logo di Instagram viene caricato relativamente presto e rimane l'elemento più grande anche se gli altri contenuti vengono progressivamente mostrati. Nell'esempio della pagina dei risultati della Ricerca Google, l'elemento più grande è un paragrafo di testo che viene visualizzato prima del caricamento di qualsiasi immagine o logo. Poiché tutte le singole immagini sono più piccole di questo paragrafo, rimane l'elemento più grande durante l'intero processo di caricamento.
Come misurare l'LCP
La metrica LCP può essere misurata in laboratorio o sul campo ed è disponibile nei seguenti strumenti:
Strumenti sul campo
- Report sull'esperienza utente di Chrome
- PageSpeed Insights
- Search Console (report Core Web Vitals)
- Libreria JavaScript di
web-vitals
Strumenti del lab
Misurare l'LCP in JavaScript
Per misurare l'LCP in JavaScript, puoi utilizzare l'API Largest Contentful Paint. L'esempio seguente mostra come creare un elemento PerformanceObserver
che ascolti le voci largest-contentful-paint
e le registri nella console.
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('LCP candidate:', entry.startTime, entry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
Nell'esempio precedente, ogni voce largest-contentful-paint
registrata rappresenta l'attuale candidato LCP. In generale, il valore startTime
dell'ultima voce emessa è il valore LCP, ma non è sempre così. Non tutte le voci di largest-contentful-paint
sono valide per la misurazione dell'LCP.
La seguente sezione elenca le differenze tra i report dell'API e il modo in cui viene calcolata la metrica.
Differenze tra la metrica e l'API
- L'API invierà le voci
largest-contentful-paint
per le pagine caricate in una scheda in background, ma queste pagine dovrebbero essere ignorate durante il calcolo del valore LCP. - L'API continuerà a inviare
largest-contentful-paint
voci dopo che una pagina è stata creata in background, ma queste voci dovrebbero essere ignorate durante il calcolo dell'LCP (gli elementi possono essere presi in considerazione solo se la pagina è rimasta in primo piano per tutto il tempo). - L'API non segnala le voci
largest-contentful-paint
quando la pagina viene ripristinata dalla cache back/forward, ma in questi casi l'LCP deve essere misurato perché gli utenti le visualizzano come visite di pagine distinte. - L'API non prende in considerazione gli elementi all'interno degli iframe, ma la metrica lo fa in quanto fanno parte dell'esperienza utente della pagina. Nelle pagine con una LCP all'interno di un iframe, ad esempio un'immagine poster in un video incorporato, questo mostrerà una differenza tra CrUX e RUM. Per misurare correttamente l'LCP, devi prendere in considerazione queste metriche. I frame secondari possono utilizzare l'API per segnalare le proprie voci
largest-contentful-paint
al frame principale per l'aggregazione. - L'API misura l'LCP dall'inizio della navigazione, ma per le pagine sottoposte a prerendering l'LCP deve essere misurato da
activationStart
poiché corrisponde al tempo LCP sperimentato dall'utente.
Anziché memorizzare tutte queste piccole differenze, gli sviluppatori possono utilizzare la libreria JavaScript di web-vitals
per misurare l'LCP, che gestisce queste differenze per te (ove possibile, tieni presente che il problema dell'iframe non è coperto):
import {onLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
onLCP(console.log);
Fai riferimento al codice sorgente per onLCP()
per un esempio completo di come misurare LCP in JavaScript.
Cosa succede se l'elemento più grande non è il più importante?
In alcuni casi, l'elemento (o gli elementi) più importanti della pagina non corrisponde a quello più grande e gli sviluppatori potrebbero essere più interessati a misurare i tempi di rendering di questi altri elementi. Ciò è possibile utilizzando l'API Element Timing, come descritto nell'articolo sulle metriche personalizzate.
Come migliorare LCP
È disponibile una guida completa all'ottimizzazione della metrica LCP che ti guiderà nel processo di identificazione dei tempi LCP sul campo e nell'utilizzo dei dati di laboratorio per visualizzarli in dettaglio e ottimizzarli.
Risorse aggiuntive
- Lezioni apprese dal monitoraggio delle prestazioni in Chrome di Annie Sullivan in performance.now() (2019)
Log delle modifiche
A volte vengono scoperti bug nelle API utilizzate per misurare le metriche e talvolta nelle definizioni delle metriche stesse. Di conseguenza, a volte devono essere apportate delle modifiche che possono apparire come miglioramenti o regressioni nei report e nelle dashboard interni.
Per aiutarti a gestire questa situazione, tutte le modifiche all'implementazione o alla definizione di queste metriche verranno riportate in questo Log delle modifiche.
Se hai un feedback per queste metriche, puoi fornirlo nel gruppo Google web-vitals-feedback.