Largest Contentful Paint (LCP): cos’è e come risolverlo quando è alto
Un sito che su smartphone o desktop impiega più di quattro secondi a mostrare qualcosa di utile ha già perso una buona parte dei suoi visitatori. E, cosa altrettanto fastidiosa, ha perso qualche posizione su Google.
Se hai fatto un test con Lighthouse o PageSpeed Insights e ti sei trovato davanti a un Largest Contentful Paint superiore ai 4 secondi, sei nel posto giusto. In questa guida vediamo cos’è davvero l’LCP, come capire quale elemento della tua pagina lo sta facendo esplodere e quali interventi concreti riducono i tempi.
Cos’è il Largest Contentful Paint
Il Largest Contentful Paint misura quanto tempo passa dall’inizio del caricamento a quando l’elemento visibile più grande compare sullo schermo. Nella maggior parte dei siti quell’elemento è l’immagine hero, il banner in cima alla pagina o un blocco di testo consistente.
È una delle tre metriche dei Core Web Vitals, insieme a INP (reattività) e CLS (stabilità visiva), ed è quella che risponde alla domanda più semplice che si fa un utente: “questa pagina si sta caricando o è rotta?”.
Google considera come candidati LCP soltanto alcuni tipi di elemento: immagini <img>, immagini dentro <svg>, video (con il loro poster), elementi con immagine di sfondo impostata via url() e blocchi di testo. Non tutta la pagina, quindi: solo il pezzo più grosso che l’utente vede senza scorrere.
I valori di riferimento
| Valutazione | Tempo LCP |
| Buono | fino a 2,5 secondi |
| Da migliorare | tra 2,5 e 4,0 secondi |
| Scarso | oltre 4,0 secondi |
Un dettaglio che sfugge spesso: Google non guarda la media, ma il 75° percentile delle visite reali, separando mobile e desktop. Tradotto: per essere “verde” devi stare sotto i 2,5 secondi per tre visitatori su quattro, compresi quelli con il telefono vecchio e la connessione ballerina in metropolitana.
Perché su mobile il punteggio è quasi sempre peggiore
Non è un difetto del tuo sito, è il contesto. Su smartphone la connessione è più lenta e instabile, la CPU è meno potente e deve elaborare lo stesso CSS e lo stesso JavaScript che sul desktop scorrono via lisci. Lighthouse, per giunta, simula di default una connessione 4G rallentata e un dispositivo di fascia media: è severo di proposito, perché rispecchia l’utente medio meglio del tuo MacBook collegato in fibra.
Come individuare l’elemento LCP della tua pagina
Prima di ottimizzare, bisogna sapere cosa ottimizzare. Tre modi, dal più rapido al più preciso:
- PageSpeed Insights: lancia il test, scorri fino alla sezione Diagnostica e apri la voce “Elemento Largest Contentful Paint”. Ti dice esattamente quale nodo HTML è stato misurato.
- Chrome DevTools: nel pannello Performance, dopo una registrazione, la traccia mostra il marker LCP e l’elemento associato.
- Direttamente in console su Chrome, se vuoi il dato grezzo:
new PerformanceObserver((list) => {
const entry = list.getEntries().at(-1);
console.log(entry.element, entry.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });
Nove volte su dieci scoprirai che il colpevole è un’immagine. Ma sapere quale immagine è solo metà del lavoro.
Il passaggio che quasi nessuno fa: scomporre l’LCP in quattro fasi
Qui sta la differenza tra ottimizzare a caso e risolvere davvero. L’LCP non è un blocco unico: è la somma di quattro fasi consecutive, e ognuna si aggiusta in modo diverso.
| Fase | Cosa succede | Peso ideale |
| Time to First Byte (TTFB) | Il server prepara e invia l’HTML | ~40% |
| Resource load delay | Tempo morto tra l’arrivo dell’HTML e l’inizio del download dell’immagine | < 10% |
| Resource load duration | Download effettivo della risorsa LCP | ~40% |
| Element render delay | Tempo tra risorsa scaricata e pixel a schermo | < 10% |
Il ragionamento è semplice: misura le quattro fasi, individua quella fuori scala e intervieni solo su quella. Se il TTFB si mangia 2 secondi, comprimere l’immagine ti farà guadagnare briciole. Se invece il load delay è enorme, il problema non è il peso dell’immagine ma il momento in cui il browser si accorge che esiste.
Le quattro cause più frequenti (e come si risolvono)
1. Immagine hero troppo pesante
Il sintomo: resource load duration alto. L’immagine principale pesa uno o due megabyte ed è servita alla stessa risoluzione sia sul monitor 27” sia sul telefono.
Cosa fare:
- Converti in formati moderni: WebP o AVIF tagliano il peso del 30–60% a parità di qualità visiva.
- Servi versioni diverse per dispositivi diversi con srcset e sizes, invece di ridimensionare via CSS un file enorme.
- Comprimi in modo aggressivo: sulle foto, una qualità all’80% è quasi sempre indistinguibile dall’originale.
2. Il browser scopre l’immagine troppo tardi
Il sintomo: resource load delay alto. Il file magari è leggero, ma il download parte tardi perché l’immagine è nascosta dentro un CSS, uno slider JavaScript o un lazy loader.
Cosa fare:
Dai al browser una priorità esplicita sull’immagine LCP:
<img src=”hero.webp” fetchpriority=”high” alt=”…”>
Se invece la risorsa è referenziata solo da un file CSS o JS esterno, il browser non può scoprirla in anticipo: in quel caso serve il preload nell’<head>.
<link rel=”preload” as=”image” href=”hero.webp” fetchpriority=”high”>
Attenzione: funziona solo se resta un’eccezione. Assegnare priorità alta a più di una o due immagini equivale a non assegnarla a nessuna.
E soprattutto: non applicare mai il lazy loading all’elemento LCP. Un loading="lazy" sull’immagine che l’utente vede appena arriva sulla pagina – quella che in gergo sta “sopra la piega” (o above the fold), cioè nel primo schermo, prima di qualsiasi scorrimento — è l’errore più comune e più costoso che si vede in giro: ritardi di proposito proprio la risorsa che dovresti caricare per prima.
3. Risposta del server lenta (TTFB elevato)
Il sintomo: il browser resta fermo ad aspettare l’HTML prima ancora di poter iniziare qualsiasi cosa.
Cosa fare:
- Attiva la cache a più livelli: cache di pagina lato server (su WordPress, un plugin di caching ben configurato), cache oggetti e header di cache del browser.
- Metti davanti una CDN, così i contenuti statici partono da un nodo geograficamente vicino all’utente.
- Verifica le query lente al database e i plugin superflui: spesso il collo di bottiglia è lì, non nell’hosting.
- Se il server è saturo o condiviso con centinaia di siti, valuta un hosting più prestante. È l’ultima leva, non la prima.
4. CSS e JavaScript che bloccano il rendering
Il sintomo: element render delay alto. La risorsa è già arrivata, ma il browser non può disegnarla perché sta ancora elaborando fogli di stile e script.
Cosa fare:
- Minifica CSS e JS ed elimina il codice inutilizzato (spesso interi framework caricati per tre righe di effetto).
- Aggiungi defer o async agli script non essenziali al primo rendering.
- Inserisci inline il CSS critico, cioè solo le regole necessarie a disegnare la parte visibile, e rimanda il resto.
- Precarica i font con font-display: swap, così il testo compare subito invece di restare invisibile.
Checklist rapida
| Problema rilevato | Azione consigliata |
| Immagine principale pesante | Converti in WebP/AVIF e usa srcset |
| Immagine scoperta tardi | Aggiungi fetchpriority=”high” o il preload |
| Lazy loading sull’elemento LCP | Rimuovi loading=”lazy” |
| Risposta del server lenta | Configura caching e CDN, ottimizza le query |
| CSS/JS bloccanti | Minifica, usa defer, inline del CSS critico |
| Non sai da dove partire | Scomponi l’LCP nelle quattro fasi e agisci sulla peggiore |
Domande frequenti Largest Contentful Paint
In sintesi
Migliorare l’LCP non richiede miracoli: richiede metodo. Prima si misura, poi si scompone il tempo nelle sue quattro fasi, infine si interviene sulla fase che pesa di più. Nella grande maggioranza dei casi bastano tre mosse per passare dal rosso al verde: immagine hero ottimizzata, priorità di caricamento corretta, caching serio.
Il tuo sito mobile è ancora lento? Richiedi un intervento strutturato, contattaci per un audit tecnico delle prestazioni.