Quando apriamo una pagina, la domanda che ci facciamo non è “quando ha finito di caricare tutto?”, ma “quando vedo quello che cercavo?”. Il Largest Contentful Paint, LCP, è la metrica dei Core Web Vitals che risponde proprio a questa domanda: misura quando compare sullo schermo il contenuto principale della pagina. È la metrica più legata alla percezione di velocità, e anche quella che più spesso separa un sito “verde” da uno che non supera la valutazione di Google.
Che cosa misura l’LCP
L’LCP indica il tempo che passa dall’inizio della navigazione al momento in cui viene disegnato l’elemento più grande visibile nella viewport. Non si basa su un evento tecnico come il caricamento completo del documento, ma su ciò che l’utente vede: nella maggior parte delle pagine l’elemento più grande è l’immagine principale, il titolo dell’articolo, la foto del prodotto o un blocco di testo in evidenza.
Le soglie, valutate al 75° percentile delle visite reali, sono queste: entro 2,5 secondi il risultato è buono, tra 2,5 e 4 secondi è da migliorare, oltre 4 secondi è scarso. Come per le altre metriche, conta che almeno tre visite su quattro rientrino nella soglia, non la media.
Come il browser sceglie l’elemento LCP
L’elemento LCP non è deciso in anticipo. Durante il caricamento il browser registra, fotogramma dopo fotogramma, qual è l’elemento più grande disegnato fino a quel momento: prima può essere un titolo, poi un’immagine più grande che arriva dopo. Ogni volta che compare un candidato più grande, il valore si aggiorna. La registrazione si ferma alla prima interazione dell’utente, come un tocco, un clic, la pressione di un tasto o lo scorrimento.
Possono essere candidati le immagini, anche quelle usate come sfondo tramite CSS, le copertine dei video e i blocchi di testo. Per le immagini conta l’area effettivamente visibile nella viewport, e il browser esclude gli elementi invisibili e i segnaposto a bassissimo contenuto informativo, come le immagini sfocate usate durante il caricamento. Una conseguenza pratica: l’elemento LCP può essere diverso su smartphone e su desktop, perché cambia che cosa è visibile e quanto spazio occupa. Va quindi individuato separatamente per i due tipi di dispositivo.
Perché l’LCP è una questione di business
Finché il contenuto principale non compare, l’utente non può fare nulla: non legge il titolo, non vede il prodotto, non capisce se è nel posto giusto. È il momento in cui avviene la maggior parte degli abbandoni, soprattutto per chi arriva da una campagna o da un risultato di ricerca e ha alternative a un tocco di distanza. Un LCP lento si traduce in meno pagine viste, meno aggiunte al carrello e budget pubblicitario speso per visite che non arrivano mai al contenuto. E, come parte dei Core Web Vitals, incide sulla valutazione dell’esperienza della pagina da parte di Google.
Le quattro fasi dell’LCP
Il modo più utile per ragionare sull’LCP è scomporlo nelle sue quattro fasi, perché ognuna ha cause e rimedi diversi:
- TTFB: il tempo prima che arrivi il primo byte del documento HTML.
- Ritardo di caricamento della risorsa: il tempo tra il primo byte e l’inizio del download dell’immagine LCP. È alto quando il browser scopre l’immagine tardi.
- Durata del caricamento della risorsa: il tempo necessario a scaricare l’immagine.
- Ritardo di rendering dell’elemento: il tempo tra la fine del download e il momento in cui l’elemento viene effettivamente disegnato, per esempio perché il browser attende fogli di stile o script.
Come riferimento, in una pagina ben ottimizzata TTFB e download dell’immagine occupano ciascuno circa il 40% del tempo totale, mentre i due ritardi restano sotto il 10%. Se una delle fasi è molto più grande di quanto dovrebbe, è lì che si trova il problema. Nell’esempio della figura il ritardo di caricamento vale da solo 1,4 secondi: l’immagine c’era, ma il browser l’ha trovata troppo tardi.
Le cause più comuni
- Un server lento. Senza una cache delle pagine, ogni visita attende che l’applicazione generi l’HTML: tutto il resto parte in ritardo. Ne abbiamo parlato nell’articolo su TTFB e cache di pagina.
- Immagine scoperta tardi. Se l’immagine principale è uno sfondo definito nel CSS, viene inserita da uno slider in JavaScript o ha l’attributo
loading="lazy", il browser la richiede solo dopo aver scaricato ed eseguito altre risorse. - Immagini troppo pesanti. Una foto da diversi megabyte, nello stesso formato per desktop e smartphone, richiede un tempo di download che nessuna ottimizzazione del server può compensare.
- Risorse che bloccano il rendering. Fogli di stile e script sincroni nell’
<head>impediscono al browser di disegnare la pagina, anche quando l’immagine è già arrivata. - Rendering lato client. Se il contenuto principale viene costruito dal JavaScript, l’elemento LCP esiste solo dopo il download, l’analisi e l’esecuzione degli script.
Come si migliora
La regola più efficace è far trovare subito al browser l’immagine principale, e dirgli che è importante. Basta che sia presente nell’HTML come elemento <img>, senza caricamento differito, con priorità alta e in un formato e una dimensione adatti al dispositivo:
<img
src="hero-1200.avif"
srcset="hero-800.avif 800w, hero-1200.avif 1200w, hero-1920.avif 1920w"
sizes="100vw"
width="1920" height="1008"
fetchpriority="high"
alt="…">
<!-- se l’immagine è uno sfondo CSS, la si annuncia in anticipo -->
<link rel="preload" as="image" href="hero-1200.avif" fetchpriority="high">
- Ridurre il TTFB con una cache delle pagine all’origine, eventualmente combinata con una CDN, e un’applicazione rapida anche quando la cache non può intervenire.
- Alleggerire l’immagine con formati moderni come AVIF e WebP, dimensioni adatte a ogni schermo tramite
srcsete una compressione calibrata. - Liberare il rendering caricando in modo non bloccante gli script non essenziali e mantenendo contenuti i fogli di stile critici.
- Curare i font quando l’elemento LCP è un testo, precaricando il font principale e usando un font di ripiego immediato.
- Evitare i caroselli nella parte alta della pagina: un’immagine statica ben ottimizzata è quasi sempre più veloce di una slide inizializzata dal JavaScript.
Attenzione, infine, alle scorciatoie: tecniche che ritardano tutto il JavaScript o che rimuovono il CSS in automatico possono migliorare l’LCP in laboratorio e peggiorare altre metriche, come abbiamo visto parlando del delay al primo clic.
Come si misura
PageSpeed Insights mostra l’LCP reale al 75° percentile dai dati di CrUX e, nella sezione di laboratorio, indica quale elemento è stato considerato LCP. Nel pannello Performance dei DevTools di Chrome l’analisi dell’LCP scomposto per fasi mostra subito quale delle quattro pesa di più. Sul campo, la libreria open source web-vitals restituisce le stesse fasi per le visite reali:
import { onLCP } from 'web-vitals/attribution';
onLCP( ( { value, attribution } ) => {
console.log( 'LCP', Math.round( value ), 'ms', {
elemento: attribution.target,
ttfb: attribution.timeToFirstByte,
ritardoCaricamento: attribution.resourceLoadDelay,
durataCaricamento: attribution.resourceLoadDuration,
ritardoRendering: attribution.elementRenderDelay,
} );
} );Laboratorio e campo possono dare valori diversi: il test di laboratorio parte sempre con la cache vuota e con una sola dimensione di schermo, mentre gli utenti reali hanno risorse già in cache, dispositivi diversi e connessioni variabili. Per questo il laboratorio serve a capire le cause, e i dati reali a verificarne l’effetto, tenendo conto della finestra di 28 giorni di CrUX.
In sintesi
L’LCP misura quando compare il contenuto principale della pagina: l’elemento più grande visibile, scelto dal browser mentre la pagina si disegna. Buono entro 2,5 secondi al 75° percentile, si scompone in quattro fasi, TTFB, ritardo di caricamento, durata del caricamento e ritardo di rendering, che indicano con precisione dove intervenire.
Nella nostra esperienza i problemi più frequenti sono sempre gli stessi: un server senza cache delle pagine e un’immagine principale scoperta tardi o troppo pesante. Sono anche quelli con il ritorno più rapido: un TTFB basso e un’immagine annunciata subito, leggera e con priorità alta bastano spesso a portare l’LCP sotto la soglia, con un effetto immediato su ciò che gli utenti vedono e su quanti di loro restano.
