In italiano si traduce con visualizzazione elemento di maggiori dimensioni, ma è più nota l’espressione inglese, Largest Contentful Paint o LCP, ed è una metrica cruciale per la user experience perché misura il tempo che una pagina impiega a caricare l’elemento di contenuti di maggiori dimensioni nell’area visibile a seguito della richiesta di un utente. Con il conto alla rovescia verso il Google Page Experience update che prosegue, oggi ci concentriamo sul terzo cardine di questa rivoluzione nel calcolo e valutazione dell’esperienza offerta dalle pagine.

Che cos’è la metrica Largest Contentful Paint

LCP è un indicatore importante e user-centric per misurare la velocità di caricamento percepita dagli utenti, perché “segna il punto della timeline di caricamento della pagina in cui il contenuto principale della pagina si è probabilmente caricato”, dice Philip Walton nella preziosa guida su web.dev.

In concreto, il Largest Contentful Paint indica il tempo che serve a una pagina per caricare il suo contenuto più impegnativo della finestra presa in considerazione dal dispositivo; di solito, il contenuto più grande è un’immagine, un video oppure un elemento di testo di grandi dimensioni a livello di blocco.

Quindi, il LCP misura l’attesa necessaria all’utente per il rendering dell’elemento più grande e visibile, e un dato veloce “aiuta a rassicurare l’utente che la pagina sia utile”, perché è un segnale che l’URL è in fase di caricamento.

Un indicatore della reale velocità di caricamento percepita

Misurare la velocità con cui il contenuto principale di una pagina web viene caricato ed è visibile agli utenti è una delle sfide più impegnative per gli sviluppatori, che hanno tentato varie strade: come racconta Walton, metriche più vecchie “come load o DOMContentLoaded non sono buone perché non corrispondono necessariamente a ciò che l’utente vede sul proprio schermo”, e la stessa First Contentful Paint (FCP), pur essendo incentrata sull’utente, “cattura solo l’inizio dell’esperienza di caricamento” ed è quindi troppo generica, perché “se una pagina mostra una schermata iniziale o un indicatore di caricamento, questo momento non è molto rilevante per l’utente”.

È per questo che si è imposto il valore LCP che, calcolando il tempo di caricamento dell’elemento più grande e problematico in pagina, si dimostra un modo più accurato per misurare quando viene effettivamente caricato il contenuto principale di una pagina per come viene percepito dall’utente.

LCP e segnali web essenziali

Non sorprende quindi la scelta di Google di inserire il Largest Contentful Paint tra i Core Web Vitals, i segnali web essenziali che permettono di misurare concretamente l’esperienza fornita dalle pagine e che da maggio diventeranno un fattore di ranking insieme ad altri segnali tecnici, come sappiamo bene.

Accanto all’indicatore per conoscere la stabilità visiva (Cumulative Shift Layout) e a quello della interattività (First input delay), quindi, Google aggiunge la misura del caricamento come discriminante per le pagine che offrono esperienze positive e quelle che, invece, sono carenti.

Come misurare LCP: punteggi e significato

La metrica Largest Contentful Paint riporta dunque il tempo di rendering necessario per l’immagine o blocco di testo più grande visibile all’interno della finestra.

Un punteggio LCP è buono quando inferiore a 2,5 secondi, mentre è molto basso un valore maggiore di 4 secondi e “tutto ciò che sta nel mezzo deve essere migliorato”, secondo l’esperto.

La rappresentazione dei valori di LCPPer fornire una buona esperienza utente, i siti dovrebbero sforzarsi di assicurare il LCP entro i primi 2,5 secondi dall’inizio del caricamento della pagina; per essere certi di raggiungere questo obiettivo per la maggior parte dei nostri utenti, una buona soglia da misurare è il 75° percentile dei caricamenti di pagina in un certo intervallo (LCP aggregate), segmentato tra dispositivi mobili e desktop.

In termini pratici, per fornire questo valore la Google Search Console monitora i tempi di caricamento e li ordina in modo crescente, dal più piccolo al più grande, prendendo come misura il valore del tempo che corrisponde al 75esimo percentile, il primo 75% dei tempi misurati. Tale scelta si spiega con la necessità di comprendere la più ampia maggioranza dei tempi registrati così da avere un riferimento sicuro che per la maggior parte degli utenti l’esperienza di caricamento è stata positiva.

Quali elementi sono considerati

Come attualmente specificato nella Largest Contentful Paint API, i tipi di elementi considerati per Largest Contentful Paint sono pochi per scelta (per mantenere le cose semplici all’inizio, con possibilità di aggiungere altri elementi in futuro), ovvero:

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

Come si calcola la dimensione di un elemento

La dimensione dell’elemento segnalata per Largest Contentful Paint è in genere “la dimensione visibile all’utente all’interno della finestra”. Se l’elemento si estende al di fuori della viewport, o se uno qualsiasi degli elementi è tagliato o ha un overflow non visibile, quelle parti non vengono conteggiate per la dimensione dell’elemento.

Per gli elementi di immagine che sono stati ridimensionati dalla loro dimensione intrinseca (ovvero quella originale, nel linguaggio di Google), viene riportata la dimensione visibile o quella dimensione intrinseca “a seconda di quale sia la più piccola”. Ad esempio, le immagini “ridotte a una dimensione molto più piccola di quella intrinseca riporteranno solo le dimensioni in cui sono visualizzate, mentre le immagini allungate o espanse a una dimensione maggiore riporteranno solo le loro dimensioni intrinseche”.

Semplificando con un esempio: se carichiamo un’immagine di 2048 pixel di larghezza e 1152 pixel di altezza, 2048 x 1152 sono considerate dimensioni “intrinseche”. Se ridimensioniamo l’immagine a 640 x 360 pixel, 640 × 360 sarà la dimensione visibile; ai fini del calcolo della dimensione dell’immagine, Google utilizza la dimensione minore tra le immagini di dimensione intrinseca e visibile, ed è considerata una best practice fare in modo che la dimensione intrinseca dell’immagine corrisponda alla dimensione visibile, perché così la ricorsa sarà scaricata più velocemente e aumenterà il punteggio LCP.

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

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

Gli strumenti per misurare il Largest Contentful Paint

LCP è una metrica facile da capire: è sufficiente osservare la pagina web e determinare qual è il blocco di testo o l’immagine più grande e quindi ottimizzarlo, rendendolo più piccolo o rimuovendo tutto ciò che può impedire un download rapido.

Il dato di LCP può essere misurato in laboratorio o sul campo ed è disponibile in vari strumenti:

  1. Strumenti sul campo (misurazioni effettive di un sito).
  • Chrome User Experience Report
  • PageSpeed ​​Insights
  • Search Console (rapporto Segnali web essenziali)
  • Libreria JavaScript web-vitals
  1. Strumenti di laboratorio (forniscono un punteggio virtuale basato su una scansione simulata utilizzando algoritmi che approssimano le condizioni Internet che potrebbe incontrare un utente tipico su uno smartphone).
  • Chrome DevTools
  • Lighthouse
  • WebPageTest

Ottimizzare il Largest Contentful Paint

Chiariti i principali aspetti descrittivi di questa metrica, andiamo a scoprire cosa possiamo fare in concreto per migliorare le performance su LCP e quindi velocizzare il rendering sullo schermo del contenuto principale della pagina per fornire una migliore user experience.

Secondo Google, le cause più comuni di un LCP scadente sono:

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

Per ognuno di questi fronti, Houssein Djirdeh (sempre su web.dev) offre una guida dettagliata alla risoluzione del problema e all’ottimizzazione di Largest Contentful Paint.

Risolvere i problemi di lentezza del server

Maggiore è il tempo necessario a un browser per ricevere contenuti dal server, più tempo servirà per visualizzare qualsiasi cosa sullo schermo, e quindi aumentare il tempo di risposta del server “migliora direttamente ogni singola metrica di caricamento della pagina, incluso LCP”.

L’esperto consiglia di concentrarsi innanzitutto a migliorare “come e dove il tuo server gestisce i tuoi contenuti”, usando la metrica Time to First Byte (TTFB) per misurare i tempi di risposta del server e migliorando il dato in uno dei seguenti modi:

  • Ottimizzare il server, analizzando e migliorando l’efficienza del codice server-side per influenzare direttamente il tempo necessario al browser per ricevere i dati (e risolvendo eventuali problemi di server sovraccarico).
  • Indirizzare gli utenti a una rete CDN vicina (per evitare che gli utenti debbano attendere richieste di rete a server lontani).
  • Cache asset: la memorizzazione della cache è adatta a siti con codice HTML statico, che non deve essere modificato a ogni richiesta, e impedisce la sua ricreazione inutile, riducendo al minimo l’utilizzo delle risorse.
  • Servire pagine HTML cache-first: attraverso un service worker eseguito in background del browser è possibile intercettare le richieste dal server, memorizzando nella cache parte o tutto il contenuto della pagina HTML e aggiornando la cache solo quando il contenuto è cambiato.
  • Stabilire in anticipo connessioni di terze parti: anche le richieste del server originate da terze parti possono avere un impatto su LCP, soprattutto se sono necessarie per visualizzare contenuti critici sulla pagina.

Intervenire su blocchi di rendering JavaScript and CSS

Script e fogli di stile sono entrambe risorse render blocking che ritardano FCP e di conseguenza LCP; Google invita a “differire qualsiasi JavaScript e CSS non critico per accelerare il caricamento del contenuto principale della tua pagina web”.

Più precisamente, il consiglio netto è di “rimuovere completamente qualsiasi CSS inutilizzato o spostarlo in un altro foglio di stile, se utilizzato su una pagina separata del tuo sito”. Un modo per farlo è utilizzare loadCSS per caricare i file in modo asincrono per qualsiasi CSS non necessario per il rendering iniziale, sfruttando rel = “preload” e onload.

Simile deve essere il lavoro per ottimizzare JavaScript, iniziando dallo “scaricare e offrire agli utenti la quantità minima di JavaScript necessario”, perché “riducendo la quantità di blocchi JavaScript si ottiene un rendering più veloce e, di conseguenza, un LCP migliore”.

Migliorare il caricamento delle risorse lenti

Esistono alcuni modi per garantire che file critici vengano caricati il ​​più velocemente possibile, come ad esempio:

  • Ottimizzare le immagini.
  • Precaricare risorse importanti (come caratteri, immagini o video above the fold e CSS o JavaScript per percorsi critici).
  • Comprimere file di testo.
  • Fornire risorse diverse in base alla connessione di rete (Adaptive serving)
  • Cache degli asset utilizzando un service worker

Ottimizzare il rendering client-side

Molti siti utilizzano la logica JavaScript lato client per eseguire il rendering delle pagine direttamente nel browser, ma questa scelta potrebbe generare un effetto negativo su LCP quando viene utilizzato un pacchetto JavaScript di grandi dimensioni.

In particolare, se non sono in atto ottimizzazioni per impedirlo, gli utenti potrebbero non vedere o non interagire con alcun contenuto sulla pagina fino a quando tutto il JavaScript critico non avrà terminato il download e l’esecuzione.

Quando si crea un sito con rendering lato client, Djirdeh suggerisce di apportare tre tipi di ottimizzazione:

  • Ridurre al minimo JavaScript critico.
  • Usare il rendering lato server.
  • Usare il pre-rendering.