Immagine LCP – Largest Contentful Paint – Il contenuto visivo più grande stampato

Largest Contentful Paint (LCP) è una metrica importante e incentrata sull’utente per misurare la velocità di caricamento percepita perché segna il punto nella sequenza temporale di caricamento della pagina in cui è probabile che il contenuto principale della pagina sia stato caricato:

Un LCP veloce aiuta a rassicurare l’utente sull’utilità della pagina.

Storicamente, è stata una sfida per gli sviluppatori Web misurare la velocità con cui il contenuto principale di una pagina Web viene caricato ed è visibile agli utenti.

Le metriche precedenti come load o DOMContentLoaded non sono buone perché non corrispondono necessariamente a ciò che l’utente vede sul proprio schermo. E le metriche delle prestazioni più recenti e incentrate sull’utente come First Contentful Paint (FCP) catturano solo l’inizio dell’esperienza di caricamento. Se una pagina mostra una schermata iniziale o mostra un indicatore di caricamento, questo momento non è molto rilevante per l’utente.

In passato abbiamo consigliato metriche delle prestazioni come First Meaningful Paint (FMP) e Speed ​​Index (SI) (entrambi disponibili in Lighthouse) per aiutare a catturare più esperienza di caricamento dopo la pittura iniziale, ma queste metriche sono complesse e difficili da spiegare e spesso sbagliati, nel senso che non si identificano ancora quando il contenuto principale della pagina è stato caricato.

A volte più semplice è meglio. Sulla base delle discussioni del W3C Web Performance Working Group e della ricerca condotta presso Google, abbiamo scoperto che un modo più accurato per misurare quando viene caricato il contenuto principale di una pagina è guardare quando è stato visualizzato l’elemento più grande.

Cos’è l’LCP?

La metrica Largest Contentful Paint (LCP) riporta il tempo di rendering dell’immagine o del blocco di testo più grande visibile all’interno del viewport, rispetto a quando è iniziato il caricamento della pagina .

Che cos’è un buon punteggio LCP?

Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di avere il contenuto più grande di 2,5 secondi o meno. Per assicurarti di raggiungere questo obiettivo per la maggior parte dei tuoi utenti, una buona soglia da misurare è il 75° percentile dei caricamenti di pagina, segmentato tra dispositivi mobili e desktop.

Per ulteriori informazioni sulla ricerca e la metodologia alla base di questa raccomandazione, vedere: Definizione delle soglie delle metriche di Core Web Vitals

Quali elementi vengono presi in considerazione?

Come attualmente specificato nella Largest Contentful Paint API , i tipi di elementi presi in considerazione per Largest Contentful Paint sono:

  • <img>elementi
  • <image>elementi all’interno di un <svg>elemento
  • <video>elementi (viene utilizzata l’immagine del poster)
  • Un elemento con un’immagine di sfondo caricata tramite la url()funzione (al contrario di un gradiente CSS )
  • Elementi a livello di blocco contenenti nodi di testo o altri elementi di testo a livello di inline figli.

Nota, limitare gli elementi a questo set limitato era intenzionale per mantenere le cose semplici all’inizio. Ulteriori elementi (ad es <svg>. , <video>) possono essere aggiunti in futuro man mano che vengono condotte ulteriori ricerche.

Come viene determinata la dimensione di un elemento?

La dimensione dell’elemento riportato per Largest Contentful Paint è in genere la dimensione visibile all’utente all’interno della finestra. Se l’elemento si estende al di fuori della finestra, o se uno qualsiasi degli elementi è ritagliato o ha un overflow non visibile , quelle porzioni non contano ai fini della dimensione dell’elemento.

Per gli elementi dell’immagine che sono stati ridimensionati dalla loro dimensione intrinseca , la dimensione che viene segnalata è la dimensione visibile o la dimensione intrinseca, a seconda di quale sia la più piccola. Ad esempio, le immagini che vengono ridotte a una dimensione molto più piccola della loro dimensione intrinseca riporteranno solo la dimensione in cui sono visualizzate, mentre le immagini che vengono allungate o espanse a una dimensione maggiore riporteranno solo le loro dimensioni intrinseche.

Per gli elementi di testo, viene considerata solo la dimensione dei relativi nodi di testo (il rettangolo più piccolo che racchiude tutti i nodi di testo).

Per tutti gli elementi non viene considerato alcun margine, riempimento o bordo applicato tramite CSS.

Determinare quali nodi di testo appartengono a quali elementi a volte può essere complicato, specialmente per elementi i cui figli includono elementi inline e nodi di testo normale ma anche elementi a livello di blocco. Il punto chiave è che ogni nodo di testo appartiene (e solo a) il suo elemento antenato a livello di blocco più vicino. In termini di specifica : ogni nodo di testo appartiene all’elemento che genera il blocco che lo contiene .

Quando viene segnalata la vernice più ricca di contenuti?

Le pagine Web spesso vengono caricate in più fasi e, di conseguenza, è possibile che l’elemento più grande della pagina cambi.

Per gestire questo potenziale cambiamento, il browser invia un messaggio PerformanceEntrydi tipo largest-contentful-paintche identifica l’elemento di contenuto più grande non appena il browser ha dipinto il primo frame. Ma poi, dopo aver eseguito il rendering dei frame successivi, ne invierà un altro PerformanceEntryogni volta che l’elemento di contenuto più grande cambia.

Ad esempio, in una pagina con testo e un’immagine eroe il browser potrebbe inizialmente eseguire il rendering del testo, a quel punto il browser invierebbe una largest-contentful-paintvoce la cui elementproprietà probabilmente farebbe riferimento a <p>o <h1>. Successivamente, una volta terminato il caricamento dell’immagine dell’eroe, largest-contentful-paintverrà inviata una seconda voce e la sua elementproprietà farà riferimento a <img>.

È importante notare che un elemento può essere considerato l’elemento di contenuto più grande solo dopo che è stato eseguito il rendering ed è visibile all’utente. Le immagini non ancora caricate non sono considerate “renderizzate”. Né i nodi di testo utilizzano i caratteri Web durante il periodo di blocco dei caratteri . In questi casi un elemento più piccolo può essere segnalato come l’elemento di contenuto più grande, ma non appena l’elemento più grande termina il rendering, verrà segnalato tramite un altro PerformanceEntryoggetto.

Oltre al caricamento tardivo di immagini e caratteri, una pagina può aggiungere nuovi elementi al DOM man mano che nuovi contenuti diventano disponibili. Se uno di questi nuovi elementi è più grande del precedente elemento di contenuto più grande, PerformanceEntryne verrà segnalato anche uno nuovo.

Se un elemento che è attualmente l’elemento di contenuto più grande viene rimosso dal viewport (o addirittura rimosso dal DOM), rimarrà l’elemento di contenuto più grande a meno che non venga visualizzato un elemento più grande.

Prima di Chrome 88, gli elementi rimossi non erano considerati elementi di contenuto più grandi e la rimozione dell’attuale candidato attiverebbe l’ largest-contentful-paintinvio di una nuova voce. Tuttavia, a causa dei modelli dell’interfaccia utente popolari come i caroselli di immagini che spesso rimuovevano elementi DOM, la metrica è stata aggiornata per riflettere in modo più accurato ciò che gli utenti sperimentano. Vedere il CHANGELOG per maggiori dettagli.

Il browser interromperà la segnalazione di nuove voci non appena l’utente interagisce con la pagina (tramite tocco, scorrimento o pressione di un tasto), poiché l’interazione dell’utente spesso cambia ciò che è visibile all’utente (il che è particolarmente vero con lo scorrimento).

A scopo di analisi, dovresti segnalare solo l’ultimo inviato PerformanceEntryal tuo servizio di analisi.

Attenzione

Poiché gli utenti possono aprire le pagine in una scheda in background, è possibile che la pittura più ricca di contenuti non si verifichi fino a quando l’utente non mette a fuoco la scheda, il che può essere molto più tardi rispetto a quando l’hanno caricata per la prima volta.

Tempo di caricamento e tempo di rendering

Per motivi di sicurezza, il timestamp di rendering delle immagini non viene esposto per le immagini multiorigine prive Timing-Allow-Origindell’intestazione. Invece, viene esposto solo il loro tempo di caricamento (poiché questo è già esposto tramite molte altre API Web).

L’ esempio di utilizzo seguente mostra come gestire gli elementi il ​​cui tempo di rendering non è disponibile. Ma, quando possibile, è sempre consigliabile impostare l’ Timing-Allow-Originintestazione, in modo che le tue metriche siano più accurate.

Come vengono gestite le modifiche al layout e alle dimensioni degli elementi?

Per mantenere basso il sovraccarico di prestazioni del calcolo e dell’invio di nuove voci di prestazioni, le modifiche alle dimensioni o alla posizione di un elemento non generano nuovi candidati LCP. Vengono considerate solo la dimensione e la posizione iniziali dell’elemento nella finestra.

Ciò significa che le immagini che inizialmente vengono visualizzate fuori dallo schermo e poi passano allo schermo potrebbero non essere riportate. Significa anche che gli elementi inizialmente renderizzati nella finestra che poi vengono spinti verso il basso, fuori dalla vista riporteranno comunque la loro dimensione iniziale nella finestra.

Esempi

Ecco alcuni esempi di quando il più grande contenuto pittorico si verifica su alcuni siti Web popolari:

In entrambe le linee temporali sopra, l’elemento più grande cambia durante il caricamento del contenuto. Nel primo esempio, il nuovo contenuto viene aggiunto al DOM e questo cambia l’elemento più grande. Nel secondo esempio, le modifiche al layout e il contenuto che in precedenza era il più grande viene rimosso dalla finestra.

Anche se spesso accade che i contenuti caricati in ritardo siano più grandi dei contenuti già presenti nella pagina, non è necessariamente così. I prossimi due esempi mostrano il disegno di contenuto più grande che si verifica prima del caricamento completo della pagina.

Nel primo esempio, il logo di Instagram viene caricato relativamente presto e rimane l’elemento più grande anche se vengono mostrati progressivamente altri contenuti. Nell’esempio della pagina dei risultati di ricerca di Google, l’elemento più grande è un paragrafo di testo che viene visualizzato prima del completamento del caricamento di qualsiasi immagine o logo. Poiché tutte le singole immagini sono più piccole di questo paragrafo, rimane l’elemento più grande durante tutto il processo di caricamento.

Nel primo fotogramma della timeline di Instagram, potresti notare che il logo della fotocamera non ha un riquadro verde attorno. Questo perché è un <svg>elemento e <svg>gli elementi non sono attualmente considerati candidati LCP. Il primo candidato LCP è il testo nel secondo frame.

Come misurare LCP

L’ LCP può essere misurato in laboratorio o sul campo ed è disponibile nei seguenti strumenti:

Strumenti sul campo

  • Rapporto sull’esperienza utente di Chrome
  • Approfondimenti sulla velocità della pagina
  • Search Console (rapporto Core Web Vitals)
  • web-vitalsLibreria JavaScript

Strumenti di laboratorio

  • Strumenti di sviluppo di Chrome
  • Faro
  • Pagina WebTest

E se l’elemento più grande non fosse il più importante?

In alcuni casi l’elemento (o gli elementi) più importanti della pagina non è lo stesso dell’elemento 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

L’LCP è principalmente influenzato da quattro fattori:

  • Tempi di risposta del server lenti
  • JavaScript e CSS che bloccano il rendering
  • Tempi di caricamento delle risorse
  • Rendering lato client

Per un approfondimento su come migliorare l’LCP, vedere Ottimizza LCP . Per ulteriori indicazioni sulle tecniche di performance individuali che possono anche migliorare l’LCP, vedere:

  • Applicare il caricamento istantaneo con il pattern PRPL
  • Ottimizzazione del percorso di rendering critico
  • Ottimizza il tuo CSS
  • Ottimizza le tue immagini
  • Ottimizza i caratteri web
  • Ottimizza il tuo JavaScript (per i siti con rendering client)
  • Fonte: https://web.dev/lcp/
pattern-lines

Prova Gratis Hosting corewebvitals Veloce, Ottimizzato, Sicuro

Passa a Bhoost con 30 giorni gratis e migrazione inclusa

Prova gratis 30 giorni
macbook