LCP: cos’è il Largest Contentful Paint e come ottimizzarlo

Uno degli scenari più consueti della navigazione online vede l’utente interfacciarsi con una pagina di un determinato sito internet, non considerando tutti i passaggi intermedi che riguardano il server e i suoi tempi di risposta, nonché i frame necessari al browser per caricare tutti i file che compongono quella determinata pagina. Per misurare queste dinamiche che in qualche modo influiscono sull’esperienza dell’utente, è stato introdotto il Largest Contentful Paint (LCP), una delle tre metriche dei Core Web Vitals di Google, insieme a Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP).

L'LCP misura il tempo di rendering dell'elemento di contenuto più grande presente nell'area visibile (il cosiddetto viewport, quello che si vede senza scrollare) rispetto al momento in cui l'utente ha iniziato a caricare la pagina. In altre parole: quanto ci mette il contenuto principale a diventare visibile.

Le metriche più vecchie non bastavano. Eventi come load o DOMContentLoaded non corrispondono a quello che l'utente vede davvero sullo schermo, mentre il First Contentful Paint (FCP) cattura solo l'apparire del primo contenuto qualsiasi: se una pagina mostra uno spinner o una schermata iniziale, quel momento dice poco all'utente. L'LCP, invece, è pensato per essere più selettivo e segnalare quando arriva il contenuto che conta.

Il motivo per cui un'agenzia o un proprietario di sito dovrebbe preoccuparsene è duplice.

• Da un lato c'è l'esperienza utente: una pagina che si fa attendere genera abbandoni, frequenze di rimbalzo più alte e, per chi vende, tassi di conversione più bassi.
• Dall'altro c'è la SEO: con l'introduzione dei Core Web Vitals tra i segnali di ranking, un LCP scadente può penalizzare il posizionamento organico. Velocità percepita e posizionamento, in questo caso, vanno nella stessa direzione.

Un dettaglio tecnico che spiega molte differenze tra strumenti

L'LCP non parte dal rendering ma dal click dell'utente. Include quindi anche il tempo di scaricamento della pagina precedente, l'eventuale tempo di redirect e i ritardi del tempo di risposta del server (TTFB). Sono fattori che, misurati sul campo, possono pesare parecchio.

Non tutto quello che è presente in una pagina HTML può essere l'elemento LCP. L'API Largest Contentful Paint considera un insieme volutamente ristretto di elementi, scelto per ridurre la complessità della metrica:

• gli elementi <img> (per i contenuti animati come GIF o PNG animati si usa il tempo di presentazione del primo fotogramma).

• gli elementi <image> all'interno di un <svg>.

• gli elementi <video> (si considera il caricamento dell'immagine poster o il primo frame, a seconda dei casi).

• gli elementi con un'immagine di sfondo caricata via funzione CSS url() — attenzione, non i gradienti CSS.

• gli elementi a livello di blocco che contengono testo.

Oltre a limitare i tipi di elemento, il browser applica delle euristiche per escludere ciò che gli utenti percepirebbero come “vuoto”: elementi con opacità 0 (invisibili), elementi che coprono l'intero viewport e che vengono trattati come sfondo più che come contenuto, e immagini segnaposto o a bassa entropia che difficilmente rappresentano il contenuto reale.

Sulle dimensioni vale la pena ricordare due cose:

• l'LCP considera la dimensione visibile nel viewport: le parti che escono fuori schermo o in overflow non contano;

• per margini, padding e bordi applicati via CSS vengono ignorati. Per le immagini ridimensionate si prende il valore più piccolo tra dimensione visibile e dimensione intrinseca; per il testo, il rettangolo minimo che contiene tutti i nodi di testo.

Una cosa importante da tenere a mente in fase di diagnosi

L'elemento LCP può cambiare durante il caricamento. Il browser segnala un candidato non appena disegna il primo frame, poi ne segnala di nuovi ogni volta che compare un elemento più grande. Ad esempio, su una pagina con testo e una hero image, all'inizio il candidato può essere un <h1>, poi diventa l'immagine quando questa finisce di caricarsi. La registrazione si ferma alla prima interazione dell'utente (tap, scroll, tasto), perché da quel momento quello che è visibile cambia.

La soglia di riferimento di Google è chiara: per offrire una buona esperienza, l'LCP dovrebbe essere pari o inferiore a 2,5 secondi. Tra 2,5 e 4 secondi siamo nella fascia “da migliorare”; oltre i 4 secondi il punteggio è considerato scarso.

C'è però una precisazione che spesso viene ignorata e che fa la differenza: la soglia va valutata al 75° percentile dei caricamenti di pagina, segmentando tra mobile e desktop. Significa che non basta che la pagina sia veloce “in media” o sul tuo computer: deve esserlo per almeno tre utenti su quattro, considerando anche chi naviga da dispositivi modesti e reti lente. Per questo i test fatti solo dalla propria macchina, in ufficio con buona connessione, sono quasi sempre sbagliati, perché considerano solo lo scenario migliore.

Va inoltre ricordato che l'LCP riguarda il contenuto principale above the fold, cioè ciò che l'utente vede senza scorrere. È lì che bisogna concentrare l'attenzione quando si annotano le aree problematiche.

L'LCP si può misurare in due modi, e capire la differenza è fondamentale per non prendere decisioni sbagliate:

• i dati sul campo (field data) raccontano l'esperienza di utenti reali;
• i dati di laboratorio (lab data) la simulano in condizioni controllate.

Per i dati sul campo gli strumenti principali sono il Chrome User Experience Report (CrUX), che raccoglie dati anonimi da utenti reali di Chrome su milioni di siti, PageSpeed Insights (che mostra proprio i dati CrUX nella sezione superiore), il report Core Web Vitals di Google Search Console e la libreria JavaScript web-vitals per il monitoraggio in tempo reale (RUM). Per i dati di laboratorio si usano Chrome DevTools, Lighthouse, PageSpeed Insights nella sezione diagnostica e WebPageTest.

La regola operativa è semplice

Quando hai dati CrUX disponibili per la pagina, parti sempre da quelli. Gli strumenti di laboratorio come Lighthouse danno moltissime informazioni utili per capire perché l'LCP è alto, ma da soli non sono pienamente rappresentativi dell'esperienza degli utenti reali. Se Lighthouse e CrUX non concordano, è CrUX a dare il quadro più realistico (verificando però che i dati si riferiscano alla pagina specifica e non all'intera origine del sito).

In Search Console la scheda Segnali Web essenziali nella barra laterale è il punto di partenza più rapido per individuare gli URL problematici. In PageSpeed Insights, sotto le metriche principali, conviene guardare anche FCP e TTFB: sono ottime metriche diagnostiche. Un delta elevato tra TTFB e FCP suggerisce molte risorse che bloccano il rendering o un sito troppo dipendente dal rendering lato client; un delta elevato tra FCP e LCP indica che la risorsa LCP non è immediatamente disponibile per il browser.

Qui sta il salto di qualità rispetto al “ottimizziamo le immagini e speriamo”. Google scompone l'LCP in quattro sotto-fasi consecutive, senza sovrapposizioni né buchi: la loro somma è esattamente il tempo LCP totale. Ragionare per sotto-fasi è il modo più efficace per capire dove sta davvero il collo di bottiglia.

Le quattro fasi sono:

• Time to First Byte (TTFB): il tempo tra l'inizio della navigazione e la ricezione del primo byte dell'HTML;

• Ritardo di caricamento della risorsa (resource load delay): il tempo tra il TTFB e l'istante in cui il browser inizia a scaricare la risorsa LCP;

• Durata di caricamento della risorsa (resource load duration): quanto ci mette materialmente a scaricarsi;

• Ritardo di rendering dell'elemento (element render delay): il tempo tra la fine del caricamento della risorsa e la sua effettiva comparsa a schermo;

Se l'elemento LCP è un nodo di testo che non richiede risorse esterne, le due fasi centrali valgono zero.

In una pagina ben ottimizzata la ripartizione ideale è indicativamente questa:

• Time to First Byte: ~40%
• Ritardo di caricamento della risorsa: <10%
• Durata di caricamento della risorsa: ~40%
• Ritardo di rendering dell'elemento: <10%

Il principio dietro questi numeri

La stragrande maggioranza del tempo dovrebbe servire a caricare l'HTML e la risorsa LCP. Le due fasi che contengono la parola “ritardo” sono, per loro natura, tempo sprecato da comprimere il più possibile. Sono linee guida, non regole rigide - se la pagina sta stabilmente sotto i 2,5 secondi, le proporzioni contano poco - ma se passi troppo tempo in una delle due fasi di “ritardo”, centrare il target diventa molto difficile.

Un avvertimento utile per non illudersi: ottimizzare una fase non sempre migliora l'LCP, a volte sposta soltanto il tempo altrove. Se comprimi un'immagine ma l'elemento resta nascosto finché un JavaScript non finisce di caricarsi, accorci la durata di caricamento ma allunghi il ritardo di rendering, e l'LCP non si muove. Per questo vanno ottimizzate tutte e quattro le fasi.

Prima di mettere mano agli interventi, conviene riconoscere i quattro grandi gruppi di problemi che generano un LCP alto.

• Tempo di risposta del server lento: un TTFB elevato penalizza ogni metrica successiva, perché finché il backend non invia il primo byte, sul frontend non può succedere nulla. Spesso dipende da infrastruttura inadeguata, query al database non ottimizzate o redirect multipli.

• Risorse che bloccano il rendering: tipicamente CSS e JavaScript pesanti caricati nel <head>. Temi sovraccarichi e troppi plugin, soprattutto above the fold, allungano i tempi.

• Rendering lato client: affidare al browser la costruzione della pagina via JavaScript comporta molti viaggi di andata e ritorno prima che il contenuto compaia.

• Caricamento lento delle risorse: immagini, GIF e media non ottimizzati above the fold richiedono tempo per scaricarsi.

La guida ufficiale di Google propone quattro interventi, presentati nell'ordine che di norma porta il beneficio maggiore. Vale la pena seguirli in quest'ordine.

1. Eliminare il ritardo di caricamento della risorsa

L'obiettivo è far partire il download della risorsa LCP il prima possibile. La regola pratica: la risorsa LCP dovrebbe iniziare a caricarsi nello stesso momento della prima risorsa caricata dalla pagina. Se parte dopo, c'è margine di miglioramento.

Due i fattori in gioco. Il primo è quando il browser scopre la risorsa. Il browser ha un “preload scanner” che analizza l'HTML iniziale: se l'immagine LCP è un <img> con src o srcset già presenti nel markup, viene trovata subito. Se invece l'immagine viene aggiunta via JavaScript, è caricata in lazy-load con src nascosto dietro un data-src, o è un'immagine di sfondo CSS, il browser deve prima eseguire script o applicare fogli di stile, e la scoperta arriva in ritardo. Nei casi in cui la risorsa è referenziata solo da CSS o JS esterni, la soluzione è il preload con priorità alta:

<link rel="stylesheet" href="/path/to/styles.css">

<link rel="preload" fetchpriority="high" as="image"

href="/path/to/hero-image.webp" type="image/webp">

Il secondo fattore è la priorità assegnata alla risorsa. Le immagini non vengono caricate con la massima priorità per impostazione predefinita, perché non bloccano il rendering. Si può suggerire al browser quali sono importanti con l'attributo fetchpriority="high" sull'<img> che si ritiene essere l'elemento LCP — senza esagerare, però: assegnare priorità alta a troppe immagini vanifica l'effetto. Si può anche abbassare la priorità delle immagini fuori vista, come le slide di un carosello non ancora visibili, con fetchpriority="low".

L'errore da non commettere mai: applicare loading="lazy" all'immagine LCP. Il lazy-load ritarda il caricamento finché il layout non conferma che l'immagine è in viewport, introducendo un ritardo sicuro e dannoso proprio sull'elemento che vorresti più veloce.

2. Eliminare il ritardo di rendering dell'elemento

Qui l'obiettivo è che l'elemento LCP compaia immediatamente dopo che la sua risorsa ha finito di caricarsi. I motivi che lo impediscono sono quasi sempre questi: fogli di stile o script sincroni nel <head> ancora in caricamento che bloccano tutto il rendering; la risorsa caricata ma l'elemento non ancora aggiunto al DOM perché si aspetta un JavaScript; l'elemento nascosto da codice di terze parti (per esempio una libreria di A/B test che sta decidendo quale variante mostrare); il thread principale occupato da attività lunghe.

Le contromisure principali:

• CSS che bloccano il rendering: rimuovere il CSS inutilizzato, posticipare quello non critico, minificare e comprimere quello critico. L'inlining del foglio di stile direttamente nell'HTML ha senso solo se è davvero piccolo, perché ciò che è inline non beneficia della cache nelle visite successive.

• JavaScript che bloccano il rendering: evitare quasi sempre gli script sincroni nel <head>; quando uno script deve girare presto, valutare l'inlining ma solo se molto piccolo.

• Rendering lato server (SSR) o generazione statica/prerendering: rende le immagini scopribili nell'HTML e non richiede JavaScript aggiuntivo per mostrare il contenuto. Il prezzo è un po' più di tempo di elaborazione lato server, di solito un compromesso accettabile perché è sotto il tuo controllo, a differenza della rete dell'utente.

• Spezzare le attività lunghe: file JavaScript enormi da analizzare ed eseguire occupano il thread principale, e poiché oggi il rendering delle immagini avviene proprio lì, possono ritardare la comparsa dell'elemento anche quando l'immagine è già scaricata.

3. Ridurre la durata di caricamento della risorsa

Sono quattro le leve a disposizione di chi deve ottimizzare questo punto:

• Ridurre il peso della risorsa: pubblicare immagini delle dimensioni corrette, usare formati moderni come WebP o AVIF, comprimere; se la risorsa LCP è un web font, ridurne il peso.
• Ridurre la distanza tra server e utente con una CDN. Le CDN per immagini sono particolarmente efficaci perché spesso ottimizzano anche peso e formato in automatico.
• Ridurre la contesa di banda: se carichi troppe risorse insieme, o troppe con priorità alta, persino la risorsa LCP rallenta.
• Eliminare del tutto la rete dove possibile, servendo le risorse con una policy di cache efficace, così che alla seconda visita arrivino dalla cache (durata di caricamento pari a zero).

Una precisazione onesta che Google stessa fa: nella maggior parte dei siti questa fase non è il collo di bottiglia principale. Per questo, prima di investire qui, conviene guardare i dati reali per capire su quale sottofase concentrarsi.

Se la risorsa LCP è un web font, oltre a ridurne il peso, conviene usare un valore di font-display diverso da auto e block (per esempio swap), così il testo resta visibile durante il caricamento del carattere e l'LCP non viene bloccato.

4. Ridurre il Time to First Byte

È elencato per ultimo perché è spesso la fase su cui si ha meno controllo, ma è anche una delle più importanti: tutto il resto dipende da quanto velocemente il backend invia il primo byte. Le cause tipiche di un TTFB lento sono i redirect multipli (frequenti quando si arriva da pubblicità o link accorciati) e l'impossibilità di servire contenuti dalla cache edge della CDN, costringendo ogni richiesta a raggiungere il server di origine; cosa che capita, per esempio, quando si usano parametri URL univoci per l'analytics anche se non generano pagine diverse. Minimizzare i redirect e impostare una buona strategia di caching sono i primi passi; per il resto, hosting adeguato e ottimizzazione del backend.

L'LCP sembra complesso, ma se lo si legge come “ottimizzazione del caricamento della risorsa LCP” si semplifica parecchio. Quattro passaggi riassumono tutto:

• Far partire il caricamento della risorsa LCP il prima possibile.

• Fare in modo che l'elemento compaia non appena la risorsa è pronta.

• Ridurre il tempo di caricamento della risorsa senza sacrificare la qualità.

• Servire l'HTML iniziale il più rapidamente possibile.

Tradotto in pratica per chi gestisce un sito: è necessario sempre misurare in primis i dati di campo (CrUX, Search Console) e non solo dal browser; bisogna poi individuare l'elemento LCP reale della pagina con DevTools o PageSpeed Insights, poi scomporre il tempo nelle quattro sottofasi per capire dove agire. È infine importante ricordare che raramente una singola correzione risolve tutto: l'LCP migliora quando si lavora sull'intero processo di caricamento. La soglia da tenere a mente resta una: 2,5 secondi, per almeno il 75% degli utenti.

Per ottimizzare le performance del tuo sito e portare l'LCP sotto la soglia ottimale, il team di Pro Web Digital Consulting può supportarti con un'analisi tecnica mirata, dalla diagnosi delle sottofasi critiche agli interventi concreti sull'infrastruttura e sulle risorse.

Contattaci per una consulenza personalizzata.