Largest Contentful Paint (LCP): cos'è, come misurarlo e ottimizzarlo

Cos'è il Largest Contentful Paint (LCP)?

Il Largest Contentful Paint è il tempo di rendering del più grande elemento di contenuto (un'immagine, un video o un blocco di testo) disegnato nella parte visibile dello schermo. Il valore LCP è il tempo in millisecondi tra la richiesta della pagina e il momento in cui quell'elemento viene visualizzato above the fold.

Alcuni lo chiamano "last contentful paint". Riguarda l'elemento più grande: un elemento più piccolo disegnato in seguito non lo cambia.

Storia del Largest Contentful Paint

Perché non misurare la velocità di caricamento come "il tempo necessario per caricare la pagina"?

Perché nella maggior parte dei siti web moderni non puoi dire quando la pagina ha finito di caricare. Il lazy loading e il caricamento progressivo fanno sì che una pagina possa continuare a caricarsi finché il visitatore vi rimane. Un singolo momento nel tempo non descrive la velocità della pagina.

Una pagina può sembrare lenta in vari momenti durante il caricamento. Il server risponde in ritardo (Time to First Byte), non appare nulla per un po' (First Contentful Paint) oppure l'immagine hero è ancora un riquadro grigio quando il resto c'è già (Largest Contentful Paint). O il primo clic non fa nulla.

Il LCP è stato scelto perché segue ciò che vede il visitatore. Quando si verifica il LCP, la maggior parte dei visitatori pensa che la pagina sia pronta, anche se ci sono ancora script in esecuzione. La metrica è stata creata per rispondere a una domanda: "Quando è visibile il contenuto di una pagina?".

LCP vs FCP: qual è la differenza?

Il Largest Contentful Paint (LCP) e il First Contentful Paint (FCP) misurano entrambi le prestazioni di caricamento, ma misurano momenti diversi. Il FCP scatta non appena il browser disegna il primo pixel di contenuto, che potrebbe essere una minuscola barra di navigazione o uno spinner di caricamento. Il LCP scatta quando l'elemento significativo più grande viene renderizzato nella viewport.

Il FCP ti dice che la pagina ha iniziato a caricarsi. Il LCP ti dice che la pagina sembra caricata, motivo per cui Google ha reso il LCP il Core Web Vital.

Per la maggior parte dei siti web, lavora prima sul LCP. Il FCP avviene sempre prima del LCP, quindi un LCP veloce di solito si accompagna a un FCP veloce. Un FCP veloce dice poco sul LCP: una pagina può disegnare il suo header a 0,8 secondi e la sua immagine hero a 4.

Perché il LCP è importante

Come Core Web Vital, il LCP è importante per la SEO. È ancora più importante per i tuoi visitatori: a nessuno piace aspettare, e la maggior parte del traffico è mobile, dove le pagine si caricano più lentamente.

• Ranking. Il LCP fa parte dei Core Web Vitals di Google e Google usa la velocità della pagina come fattore di ranking.
• Visitatori. Un visitatore che fissa uno schermo bianco o un riquadro grigio dove dovrebbe esserci l'immagine hero, se ne va. Il test di Vodafone qui sotto ha quantificato questo aspetto.
• Google Ads. L'esperienza sulla pagina di destinazione fa parte del tuo Quality Score. Una pagina di destinazione lenta rende ogni clic più costoso.

Caso di studio: Vodafone (Miglioramento del 31% del LCP, 8% in più di vendite)

Vodafone Italia ha diviso il traffico 50/50 tra la vecchia pagina di destinazione e una copia più veloce con lo stesso aspetto e funzionamento. La copia più veloce veniva renderizzata sul server invece che in widget lato client, forniva un'immagine hero ridimensionata, differiva le immagini below the fold e usava file SVG e PNG più piccoli. Il LCP è passato da 8,3 a 5,7 secondi (31% più veloce) e le vendite sono aumentate dell'8%. (Caso di studio Vodafone su web.dev)

Test: Google Voli (fetchpriority ha fatto risparmiare 700 ms)

In un test sulla pagina di Google Voli, aggiungere fetchpriority="high" all'immagine LCP ha portato il LCP da 2,6 a 1,9 secondi. Senza di esso, Chrome richiede le immagini a bassa priorità e la alza solo quando il layout mostra che l'immagine è nella viewport. Su una pagina pesante, sono centinaia di millisecondi di attesa. Scopri di più sulla prioritizzazione delle risorse per i Core Web Vitals.

Quali elementi sono considerati elementi LCP?

Non tutti gli elementi possono essere l'elemento LCP. Deve essere disegnato nella parte visibile dello schermo (la viewport) prima che l'utente interagisca con la pagina.

L'elemento deve essere:

• Un elemento <img>.
• Un elemento <image> annidato all'interno di un elemento <svg>.
• Un elemento <video> (viene utilizzata l'immagine poster o il primo frame del video, a seconda di quale avvenga prima).
• Un elemento con un'immagine di sfondo caricata tramite la funzione CSS url(). Conta, ma il preload scanner non può vederlo, quindi il browser trova l'immagine in ritardo. Maggiori dettagli su come differire le immagini di sfondo.

• Un elemento a livello di blocco contenente nodi di testo o altri elementi di testo inline (nel caso di elementi di testo inline come <span>, viene considerato l'elemento a livello di blocco più vicino, <div> o <p>).

Alcuni elementi vengono ignorati: gli elementi con opacity: 0, le immagini che coprono l'intera viewport (Chrome le tratta come sfondi) e le immagini a bassa entropia. Da Chrome 112, un'immagine con meno di 0,05 bit di dati immagine per pixel visualizzato viene ignorata in quanto considerata un placeholder. Chrome cambia queste regole di tanto in tanto.

Come viene misurata la dimensione dell'elemento LCP

Il browser calcola la dimensione di ogni candidato con queste regole:

• Solo viewport: viene considerata solo la parte visibile della pagina. Se un elemento è solo parzialmente nella viewport visibile, la dimensione considerata verrà ritagliata.
• Nessun bordo, padding o margine: per tutti gli elementi, i bordi di testo e immagini, il padding e i margini vengono completamente ignorati.
• Dimensione del testo: gli elementi di testo vengono riportati come il rettangolo più piccolo che può essere disegnato attorno al nodo o ai nodi di testo.
• Dimensione dell'immagine: per le immagini, per calcolare la dimensione dell'elemento LCP si usa la più piccola tra le dimensioni intrinseche (la larghezza e l'altezza originali) e la dimensione di visualizzazione (la dimensione sullo schermo).
• Conta la prima dimensione: quando il layout cambia o quando la dimensione di un elemento cambia, solo la prima dimensione viene considerata per il LCP.
• Gli elementi rimossi sono inclusi: quando un elemento viene rimosso dal DOM è ancora un candidato LCP.

L'elemento LCP può cambiare durante il caricamento

Una pagina viene renderizzata per fasi, quindi l'elemento LCP cambia spesso durante il caricamento della pagina. Fino alla prima interazione dell'utente, il browser segnala ogni nuovo candidato LCP. Quando viene disegnato un nuovo elemento che è visibile nella viewport ed è più grande del candidato precedente, diventa il nuovo elemento LCP.

Cosa impariamo dai field data del LCP: Su CoreDash tracciamo milioni di misurazioni LCP al giorno. Su mobile l'elemento LCP è spesso un paragrafo o un'intestazione. Su desktop la viewport più ampia ospita un'immagine più grande, quindi la stessa pagina ha spesso un elemento LCP diverso su ciascun dispositivo. Controlla entrambi prima di decidere cosa correggere.

Qual è un buon punteggio LCP?

Per superare la parte LCP dei Core Web Vitals, almeno il 75% delle visite alla tua pagina deve avere un buon LCP: inferiore a 2,5 secondi. Tra 2,5 e 4 secondi necessita di miglioramenti, sopra i 4 è scarso. Controlla prima la scheda mobile in PageSpeed Insights. I field data in alto sono il p75 degli ultimi 28 giorni.

Cosa mostrano i dati di CoreDash

LCP da immagine vs LCP da testo

Le pagine con elementi LCP basati su immagini hanno un LCP al p75 di 744 ms, quasi due volte più lento rispetto agli elementi LCP basati su testo a 388 ms. Gran parte di questo divario deriva da quanto tardi il browser trova e richiede l'immagine (vedi le quattro fasi di seguito).

L'impatto del preloading e del lazy loading

Le immagini LCP precaricate hanno un p75 di 364 ms e nessun caricamento di pagina scarso. Le immagini LCP in lazy loading si attestano a 720 ms, con il 4,3% dei caricamenti di pagina valutati come scarsi, e le immagini non precaricate a 752 ms. Non applicare mai il lazy loading all'immagine LCP e assicurati che venga richiesta in anticipo: nell'HTML con fetchpriority="high", o precaricata quando non lo è.

LCP su mobile vs desktop

Il LCP su mobile (764 ms al 75esimo percentile) è il doppio del LCP su desktop (380 ms). Le reti mobili sono più lente e i telefoni hanno meno CPU. Google valuta mobile e desktop separatamente e il mobile è dove la maggior parte dei siti fallisce, quindi inizia da lì.

Il LCP in tutto il web

Nella versione CrUX di agosto 2026, il 68,1% delle origin ha avuto un buon LCP, in aumento rispetto al 66,7% dell'anno precedente. È ancora il più basso dei tre Core Web Vitals (INP 85,3%, CLS 81,5%), quindi per la maggior parte dei siti è il LCP a decidere se vengono superati o meno.

La scansione di HTTP Archive aggiunge ciò che CrUX non raccoglie. Nel Web Almanac 2025, l'elemento LCP è un'immagine sul 76% delle pagine mobile e circa il 16% delle pagine la carica in lazy loading. Solo il 17% delle pagine mobile con un'immagine LCP usa fetchpriority="high". Circa il 2% la precarica.

Come viene misurato il LCP: le quattro fasi chiave

Secondo Google, il Largest Contentful Paint può essere scomposto in 4 sottoparti. Ogni fase richiede una correzione diversa, quindi per prima cosa scopri quale fase è lenta. Un Time to First Byte (TTFB) lento richiede un lavoro lato server, mentre un resource load delay lento richiede modifiche al tuo HTML.

Il tempo del LCP è la somma di queste quattro fasi:

• Time to First Byte (TTFB): il tempo di risposta del server. Copre tutto, dalla ricerca DNS, alla connessione TCP/TLS, fino al momento in cui il browser riceve il primo byte del documento HTML. Un TTFB lento ritarda tutto ciò che viene dopo. Il motivo tipico è un HTML non nella cache, per cui ogni visita rigenera la pagina in PHP o Node. Una CDN che non mette nella cache l'HTML rende più veloci solo le immagini.
• Resource Load Delay: il tempo tra il completamento del TTFB e il momento in cui il browser inizia effettivamente a scaricare la risorsa LCP. Un lungo ritardo qui significa che il browser ha trovato la risorsa LCP in ritardo. Di solito ciò deriva da immagini di sfondo CSS (che il preload scanner non può scoprire) o dal rendering lato client (dove l'elemento LCP appare solo dopo l'esecuzione di JavaScript). Inserisci l'elemento LCP nell'HTML iniziale e precarica l'immagine LCP solo quando ciò non è possibile.
• Resource Load Duration: quanto tempo ci vuole per scaricare la risorsa LCP (l'immagine, il font o il video). Questa fase dipende dalle dimensioni del file e dalla rete: AVIF o WebP, un srcset in modo che i telefoni ricevano un'immagine delle dimensioni del telefono. Sulla maggior parte dei siti è la più breve delle quattro.
• Element Render Delay: il tempo tra la fine del download della risorsa LCP e la sua completa renderizzazione sullo schermo. L'immagine c'è, ma il browser non può ancora disegnarla. CSS e JavaScript render blocking sul main thread sono i motivi tipici. Un classico è uno snippet di A/B testing che nasconde la pagina finché lo script del test non si è caricato.

Google ha analizzato le navigazioni reali di Chrome con un LCP da immagine e ha diviso il LCP al p75 in queste fasi. L'origin mediana in ciascun gruppo:

Sui siti con un LCP scarso, il TTFB e il load delay insieme richiedono più di 3,5 secondi. Scaricare l'immagine richiede 350 ms. La maggior parte delle origin con un LCP scarso spende meno del 10% del suo LCP a scaricare l'immagine LCP.

Per i passaggi su come trovare e correggere ogni fase, leggi Individuare e correggere i problemi di Largest Contentful Paint (LCP).

Errori comuni con il LCP

Errore 1: applicare il lazy loading all'immagine LCP

loading="lazy" dice al browser di aspettare con il download finché l'immagine non è vicina alla viewport. L'immagine LCP è già nella viewport, quindi il browser deve prima calcolare il layout per scoprirlo, e solo allora avvia il download. I temi e i page builder lo aggiungono spesso a ogni immagine, compresa la hero. Rimuovilo dall'immagine LCP. Tutto qui. Secondo il Web Almanac 2025, circa il 16% delle pagine lo fa. Leggi la guida su come correggere un'immagine LCP caricata in lazy loading.

Errore 2: l'immagine LCP viene trovata in ritardo

Uno slider o una hero renderizzata lato client inseriscono l'URL dell'immagine sulla pagina solo dopo che il CSS è stato elaborato o il JavaScript è stato eseguito. Questo costa centinaia di millisecondi prima ancora che inizi il download. La correzione migliore è un normale <img> nell'HTML. Quando non è possibile, aggiungi un suggerimento di preload nell'<head>:

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

Il browser avvia subito il download. Un preload da solo non alza la priorità, quindi mantieni fetchpriority="high" su di esso, altrimenti l'immagine aspetterà comunque dietro a fogli di stile e script. Maggiori dettagli nella guida su come precaricare l'immagine LCP.

Errore 3: un'immagine di sfondo CSS come elemento LCP

Il preload scanner non può vedere un background-image: url(...). Il browser trova l'immagine solo dopo aver scaricato l'HTML e il CSS e aver abbinato la regola a un elemento sulla pagina. Questo aggiunge resource load delay. La soluzione è usare invece un tag <img> standard, con l'attributo fetchpriority="high":

<img src="/img/hero.webp"
     alt="Testo alternativo descrittivo"
     width="1200"
     height="600"
     fetchpriority="high">

Ora il preload scanner la trova nell'HTML, e fetchpriority="high" la mette in cima alla coda. Maggiori dettagli nella guida alla prioritizzazione delle risorse.

Come misurare il Largest Contentful Paint

Misurare il Largest Contentful Paint con JavaScript

Il modo più rapido è un PerformanceObserver. Questo snippet registra nel log il tempo e l'elemento del LCP:

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

Per misurazioni più approfondite, usa la libreria Web Vitals.

Misurare il Largest Contentful Paint (LCP) in Chrome DevTools

1. Apri i Chrome DevTools premendo Ctrl+Maiusc+I (o Cmd+Opzione+I su Mac).
2. Vai al pannello Performance. Mostra subito il LCP della pagina corrente, con l'elemento LCP.
3. Fai clic sul pulsante di ricarica nel pannello per registrare una traccia. L'indicatore LCP nella traccia mostra l'elemento LCP e le sue quattro fasi.

La procedura completa, con cosa cercare nella traccia, è in diagnosticare il LCP con i Chrome DevTools.

Misurare il Largest Contentful Paint con strumenti lab e field

I lab data e i field data fanno lavori diversi. Hai bisogno di entrambi.

• I field data (RUM e CrUX) sono ciò che Google usa per decidere se superi il test. Sono ciò che ottengono i tuoi utenti reali. Inizia da qui per scoprire se hai un problema.
• I lab data (Lighthouse, ecc.) sono un test controllato. Google non li usa per il ranking, ma ti servono per il debugging: ti dicono perché hai un problema.

Gli strumenti:

Migliorare il Largest Contentful Paint

Prendi il tuo template più lento su mobile e guarda le sue quattro fasi del LCP: CoreDash le mostra per ogni pagina per i visitatori reali, i DevTools per un singolo caricamento. Nei field data visti sopra, il TTFB e il load delay sono i fattori principali su quasi tutti i siti con un LCP scarso, quindi inizia da lì.

Convertire l'immagine hero in AVIF è ciò che tutti provano per primo. Su un sito con un LCP di 4 secondi, l'intero download richiede circa 350 ms, quindi un file più piccolo fa risparmiare una frazione di questo tempo. Fallo, ma fallo per ultimo.

Fase per fase:

• TTFB: metti in cache l'HTML, sul server o sulla CDN. Leggi di più nella nostra guida all'ottimizzazione del TTFB.
• Resource Load Delay: un tag <img> nell'HTML, nessun loading="lazy", fetchpriority="high". Vedi come correggere il Resource Load Delay.
• Resource Load Duration: un file più piccolo, dimensionato per il dispositivo. Vedi come ottimizzare l'immagine LCP. Puoi anche leggere come abbiamo abbassato il LCP del 70% in un progetto reale.
• Element Render Delay: meno CSS render blocking, script differiti, nessuno snippet anti-flicker. Vedi come correggere l'Element Render Delay.

Guide correlate

Ogni parte del LCP ha la sua guida:

• Individuare e correggere i problemi di LCP: scopri quale fase è lenta, con DevTools, WebPageTest e CoreDash.
• Diagnosticare il LCP con i Chrome DevTools: l'indicatore LCP in una traccia Performance.
• Ottimizzare l'immagine LCP: formati, dimensioni e srcset.
• Resource Load Delay: far sì che l'immagine LCP venga richiesta in anticipo.
• Resource Load Duration: il download stesso.
• Element Render Delay: quando l'immagine è arrivata ma non è ancora disegnata.