Largest Contentful Paint (LCP): Cos'è, Come Misurarlo e Ottimizzarlo

Cos'è il Largest Contentful Paint (LCP)?

Il Largest Contentful Paint è una misurazione del tempo di rendering del più grande elemento di contenuto (di tipo immagine, video o testo) che è stato dipinto sulla parte visibile dello schermo. Il tempo del LCP indica il tempo in millisecondi tra la richiesta della pagina e quando quell'elemento di contenuto più grande viene visualizzato sulla parte visibile della pagina web (above the fold).

Storia del Largest Contentful Paint

Se ci pensi, il LCP potrebbe sembrare una metrica banale per rappresentare la parte di caricamento dei Core Web Vitals. Perché non misurare la velocità di caricamento come 'il tempo necessario per caricare la pagina'?

Questo perché è difficile (o addirittura impossibile) nella maggior parte dei siti web moderni definire quando la pagina si è caricata. Sempre più siti web utilizzano tecniche come il lazy loading o il caricamento progressivo dove la pagina fondamentalmente può continuare a caricare all'infinito. Questo significa che la velocità della pagina non può essere misurata con un singolo punto nel tempo.

Ci sono diversi momenti durante il caricamento della pagina che possono far percepire la pagina come veloce o lenta. Ad esempio il ritardo del server (Time to First Byte), la prima volta che il contenuto è visibile (First Contentful Paint), il momento in cui il viewport visibile può sembrare completo (Largest Contentful Paint) e quando la pagina diventa interattiva (quando cliccare su un link diventa possibile) sono tutti punti durante il processo di caricamento dove il sito può sembrare lento o veloce!

Il Largest Contentful Paint (LCP) è stato scelto perché si concentra sulla user experience del visitatore. Quando il LCP si verifica, si può presumere che un visitatore pensi che la pagina abbia terminato il caricamento (anche se i processi dietro le quinte sono ancora in esecuzione). Il LCP è stato creato per rispondere alla domanda: 'Quando è visibile il contenuto di una pagina?'. Ecco perché il LCP è riconosciuto come un indicatore fondamentale delle prestazioni orientate all'utente.

LCP vs FCP: Qual è la Differenza?

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

Pensala così: il FCP ti dice che la pagina ha iniziato a caricarsi; il LCP ti dice che la pagina sembra caricata. Google ha scelto il LCP come Core Web Vital perché riflette più accuratamente ciò che gli utenti percepiscono come "velocità".

Per la maggior parte dei siti web, ottimizzare il LCP dovrebbe essere la priorità. Se il tuo LCP è veloce, anche il tuo FCP sarà quasi sempre veloce, perché il FCP si verifica prima nella timeline di caricamento. Il contrario non è vero: un FCP veloce non garantisce un LCP veloce.

Perché il LCP è Importante per il Tuo Business

Il Largest Contentful Paint è uno dei 3 Core Web Vitals. Come Core Web Vital, il Largest Contentful Paint è importante per il SEO, ma soprattutto il LCP è critico per la UX. I visitatori non amano essere fatti aspettare, e con sempre più traffico mobile (che tende ad essere più lento del traffico desktop) ottimizzare il Largest Contentful Paint ha molto senso.

• Per il SEO. Sì, Google si concentra sul servire le migliori pagine nei suoi risultati di ricerca. Il LCP fa parte dei Core Web Vitals di Google. Google afferma chiaramente che la velocità del sito è un fattore nei risultati di ricerca.
• Per i Visitatori: Secondo una ricerca recente di Google stesso, la probabilità che un utente lasci il sito raddoppia con un tempo di caricamento di 3 secondi. Probabilmente lo riconoscerai tu stesso. Mentre navighi su internet quasi niente sembra così fastidioso come un sito web che si carica lentamente. È probabile che lascerai velocemente una pagina che si carica lentamente.
• Altre ragioni: Page Speed è un fattore nel tuo Ad Score di Google. Questo significa che puoi comprare i tuoi annunci a meno. Inoltre, superare i Core Web Vitals è uno dei prerequisiti per il box Top Story di Google.

Un LCP veloce dà al visitatore l'idea che la pagina si carichi rapidamente. Di conseguenza, un visitatore ha meno probabilità di abbandonare la pagina.

Caso Studio: Vodafone (31% di Miglioramento LCP, 8% di Vendite in Più)

Vodafone Italia ha condotto un esperimento controllato ottimizzando il loro punteggio LCP. Riducendo il LCP del 31%, hanno misurato un aumento dell'8% nelle vendite. Questa non è una correlazione; è un test A/B diretto che dimostra che un caricamento percepito più veloce si traduce in più entrate. L'ottimizzazione si è concentrata sul preloading dell'immagine LCP e sulla riduzione delle risorse che bloccano il rendering. Leggi il caso studio completo di Vodafone su web.dev.

Caso Studio: Google Flights (fetchpriority Ha Risparmiato 700ms)

Il team di Google Flights ha aggiunto fetchpriority="high" alla loro immagine hero e ha visto il LCP migliorare di 700 millisecondi. Questa singola modifica dell'attributo HTML è stata l'ottimizzazione più impattante nel loro sprint di performance. L'attributo fetchpriority dice al browser di dare priorità al download dell'immagine LCP rispetto ad altre risorse, e come dimostra l'esperimento di Google Flights, l'impatto può essere drammatico. Scopri di più sulla prioritizzazione delle risorse per i Core Web Vitals.

Quali Elementi Sono Considerati Elementi LCP?

Non tutti gli elementi sono considerati come elemento LCP. L'elemento Contentful più grande deve essere dipinto sulla parte visibile dello schermo (il viewport) prima che l'utente abbia interagito con la pagina.

L'elemento deve essere:

• Un elemento <img>.
• Un elemento <image> annidato dentro un elemento <svg>.
• Un elemento <video> (viene utilizzata l'immagine poster o il primo frame del video, a seconda di quale arriva prima).
• Un elemento con un'immagine di sfondo caricata tramite la funzione CSS url(). (Nota: questo è un anti-pattern per l'ottimizzazione LCP poiché rende l'immagine non individuabile dal preload scanner del browser. Leggi la nostra guida sul differimento delle 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>).

Attualmente, alcuni elementi sono esclusi come candidati LCP, come elementi nascosti con opacity: 0, immagini che corrispondono al 100% delle dimensioni del viewport (immagini di copertura) e placeholder (immagini a bassa entropia). Tieni presente che questo può cambiare con l'evoluzione delle specifiche!

Aspetti Tecnici: Misurazione della Dimensione dell'Elemento LCP

Il LCP identifica l'elemento di contenuto visibile più grande nel viewport e calcola la sua dimensione in base a un insieme di regole precise. Queste regole garantiscono coerenza e accuratezza, anche in layout complessi.

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

Natura Dinamica del LCP

Il Largest Contentful Paint (LCP) è una metrica dinamica. Sebbene il rendering possa essere complesso e avvenire in fasi, è normale che l'elemento LCP cambi durante il caricamento della pagina. Prima della prima interazione dell'utente, il performance observer del browser identifica tutti gli elementi che potrebbero essere considerati candidati LCP. Se viene renderizzato un nuovo elemento che è sia visibile nel viewport che più grande dell'elemento LCP precedentemente identificato, diventa il nuovo LCP.

Conclusioni dai dati di campo LCP: Su CoreDash monitoriamo milioni di voci LCP al giorno. Come risulta, per le visualizzazioni di pagina mobile l'elemento LCP è spesso un elemento basato su testo, un paragrafo o un titolo. In media (o al 75° percentile per essere precisi) i Core Web Vitals saranno superati quando l'elemento LCP è un nodo di testo o anche un'immagine normale. Quando l'elemento LCP è un'immagine di sfondo, un video o un'immagine caricata con lazy loading, i Core Web Vitals tendono a non essere superati.

Qual è un Buon Punteggio LCP?

Per superare i Core Web Vitals per il Largest Contentful Paint almeno il 75% dei tuoi visitatori deve avere un punteggio LCP 'buono'. Un punteggio LCP tra 0 e 2,5 secondi è considerato un punteggio LCP buono, un punteggio LCP tra 2,5 e 4 secondi necessita di miglioramento e un punteggio LCP superiore a 4 secondi è considerato scarso.

Cosa Mostrano i Dati LCP Reali

CoreDash monitora milioni di misurazioni LCP reali ogni giorno. Ecco cosa rivelano i dati sulle prestazioni LCP nel web.

LCP con Immagine vs LCP con Testo

Le pagine con elementi LCP basati su immagini hanno un LCP al 75° percentile di 744ms, quasi il doppio rispetto agli elementi LCP basati su testo a 388ms. Questo conferma che l'ottimizzazione delle immagini è l'area singola più impattante per migliorare i punteggi LCP. Se il tuo elemento LCP è un'immagine, devi essere particolarmente aggressivo con l'ottimizzazione.

L'Impatto del Preloading e del Lazy Loading

Le immagini LCP precaricate raggiungono il 100% di punteggi "buoni" con un 75° percentile di 364ms. Al contrario, le immagini LCP con lazy loading sono tra le più lente a 720ms, con il 4,3% dei caricamenti di pagina valutati come "scarsi". Le immagini non precaricate hanno prestazioni quasi altrettanto scarse a 752ms. La conclusione è chiara: precarica la tua immagine LCP e non applicare mai il lazy loading.

LCP Mobile vs Desktop

Il LCP mobile (764ms al 75° percentile) è 2 volte più lento del LCP desktop (380ms). Questo divario è causato dalle reti mobili più lente e dai processori mobili meno potenti. Poiché Google utilizza l'indicizzazione mobile-first, ottimizzare per il LCP mobile dovrebbe essere la priorità.

Statistiche Globali LCP

Secondo l'HTTP Archive Web Almanac 2025, il 62% delle pagine mobile a livello globale raggiunge un buon punteggio LCP (sotto i 2,5 secondi), in aumento dal 44% nel 2022. Il LCP rimane il Core Web Vital più difficile da superare ed è il principale collo di bottiglia per i punteggi CWV complessivi. Inoltre, il 73% degli elementi LCP mobile sono immagini, e il 16% dei siti mobile applica erroneamente il lazy loading alla propria immagine LCP.

Come Viene Misurato il LCP: Le Quattro Fasi Chiave

Secondo Google, il Largest Contentful Paint può essere suddiviso in 4 sotto-parti. Capire quale fase sta causando il collo di bottiglia è essenziale per un'ottimizzazione efficiente, perché ogni fase richiede una correzione completamente diversa. Un Time to First Byte (TTFB) lento necessita di lavoro lato server, mentre un resource load delay lento necessita di modifiche al tuo HTML.

Il tempo finale del LCP di una pagina non è un singolo valore monolitico. È la somma di quattro sotto-parti distinte. Comprendere questa suddivisione è la chiave per diagnosticare e risolvere i problemi LCP in modo efficiente.

Ecco una suddivisione delle quattro fasi:

• Time to First Byte (TTFB): Questo è il puro tempo di risposta del server. Copre tutto, dalla ricerca DNS, attraverso la connessione TCP/TLS, fino al momento in cui il browser riceve il primo byte del documento HTML. Un TTFB lento è un problema fondamentale che ucciderà sempre il tuo LCP. Nel web, i siti con LCP scarso impiegano in media 2,27 secondi solo per il TTFB, che è quasi l'intera soglia di 2,5 secondi. Ottimizzare il TTFB comporta caching lato server, configurazione CDN e codice backend efficiente.
• Resource Load Delay: Questo è il "gap di scoperta". Misura il tempo tra il completamento del TTFB e il momento in cui il browser inizia effettivamente a scaricare la risorsa LCP. Un ritardo lungo qui significa che il browser ha trovato la risorsa LCP tardi. Questo è il classico sintomo dell'uso di immagini di sfondo CSS (che il preload scanner non può scoprire) o del client-side rendering (dove l'elemento LCP appare solo dopo l'esecuzione del JavaScript). La soluzione è assicurarsi che il tuo elemento LCP sia nell'HTML iniziale e precaricare l'immagine LCP se il browser non riesce a scoprirla abbastanza presto.
• Resource Load Duration: Questo è quanto tempo ci vuole per scaricare effettivamente il file della risorsa LCP (l'immagine, il font o il video). Questa fase riguarda interamente la dimensione del file e le condizioni di rete. Ottimizzare significa utilizzare formati immagine moderni come AVIF o WebP, implementare immagini responsive con srcset e servire gli asset attraverso un CDN con compressione adeguata.
• Element Render Delay: Questo è il ritardo finale. Misura il tempo tra quando la risorsa LCP finisce di scaricarsi e quando l'elemento viene completamente renderizzato sullo schermo. Questo ritardo è quasi sempre causato dalla thread principale del browser bloccata da altre attività, specialmente l'elaborazione JavaScript. CSS che blocca il rendering e script sincroni sono le cause più comuni.

Ognuna di queste aree di focus può essere ottimizzata per migliorare il Largest Contentful Paint. Per capire i passi da compiere, leggi Individuare e Correggere i Problemi di Largest Contentful Paint (LCP).

Errori Comuni del LCP

Dopo aver analizzato milioni di caricamenti di pagina tramite CoreDash, tre errori LCP appaiono molto più spesso di qualsiasi altro. Evitarli porterà la maggior parte dei siti a un punteggio LCP sufficiente.

Errore 1: Lazy Loading dell'Immagine LCP

Aggiungere loading="lazy" alla tua immagine hero è l'errore LCP singolo più comune. Il lazy loading dice al browser di ritardare intenzionalmente il download dell'immagine fino a quando non scorre nel viewport. Per la tua immagine LCP (che è già nel viewport), questo crea un ritardo completamente non necessario. Secondo i dati CrUX, il 16% dei siti mobile commette questo errore. I dati CoreDash mostrano che le immagini LCP con lazy loading hanno un 75° percentile di 720ms con il 4,3% di esperienze scarse, rispetto a 364ms e 0% di esperienze scarse per le immagini precaricate. Leggi la nostra guida completa su come correggere un'immagine LCP caricata con lazy loading.

Errore 2: Non Precaricare l'Immagine LCP

Anche senza lazy loading, molti siti non comunicano al browser l'immagine LCP abbastanza presto. Se l'URL dell'immagine viene scoperto solo dopo il parsing del CSS o l'esecuzione del JavaScript, il browser spreca centinaia di millisecondi prima ancora di iniziare il download. La soluzione è aggiungere un hint di preload nel <head> del tuo documento:

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

Questo dice al browser di iniziare a scaricare l'immagine immediatamente, senza aspettare il CSS o i calcoli del layout. Combinalo con fetchpriority="high" per il massimo impatto. Scopri di più nella nostra guida al preloading dell'immagine LCP.

Errore 3: Usare un'Immagine di Sfondo CSS per il LCP

Le immagini di sfondo CSS caricate tramite background-image: url(...) sono invisibili al preload scanner del browser. Il browser non può scoprirle fino a quando non ha scaricato l'HTML, parsato il CSS e costruito l'albero di rendering. Questo aggiunge un significativo resource load delay. Secondo i dati CrUX, il 9% delle pagine mobile utilizza un'immagine di sfondo CSS come elemento LCP. La soluzione è usare un tag <img> standard, con l'attributo fetchpriority="high":

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

L'attributo fetchpriority="high" è un segnale diretto al browser che questa immagine è la risorsa con la priorità più alta sulla pagina. Come ha dimostrato il caso studio di Google Flights, questo singolo attributo può ridurre il LCP di 700ms. Per una comprensione più approfondita, consulta la nostra guida alla prioritizzazione delle risorse.

Come Misurare il Largest Contentful Paint

Il Largest Contentful Paint (LCP) può essere misurato con puro JavaScript, dati di laboratorio e strumenti di campo. Entrambi hanno i loro vantaggi e svantaggi.

Misurare il Largest Contentful Paint con JavaScript

Per misurare il Largest Contentful Paint (LCP) usando JavaScript, l'API Performance Observer offre una soluzione rapida. Il seguente frammento di codice dimostra come catturare il tempo del LCP e le informazioni sull'elemento:

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 });

Questo frammento traccia la voce LCP quando viene riportata, mostrando il suo timestamp e i dettagli dell'elemento nella console. Per analisi più approfondite, considera l'uso della Libreria Web Vitals.

Misurare il Largest Contentful Paint (LCP) in Chrome DevTools

1. Apri Chrome DevTools premendo Ctrl+Shift+I (o Cmd+Option+I su Mac).
2. Naviga al tab Performance.
3. Ricarica la pagina per visualizzare i Core Web Vitals.

Il tab Performance di DevTools ora mostra informazioni sui Core Web Vitals, inclusi il tempo e l'elemento del Largest Contentful Paint.

Misurare il Largest Contentful Paint con Strumenti di Laboratorio e di Campo

Chiariamo: i dati di laboratorio e di campo servono a due scopi diversi. Hai bisogno di entrambi.

• Dati di campo (RUM e CrUX) sono gli unici dati che contano veramente per superare i Core Web Vitals. Sono ciò che i tuoi utenti reali sperimentano. Google usa questi dati dal suo dataset CrUX. Parti da qui per scoprire se hai un problema.
• Dati di laboratorio (Lighthouse, ecc.) sono un test controllato. Non sono ciò che Google usa per il ranking, ma sono essenziali per il debug. Li usi per capire perché hai un problema.

Ecco una guida rapida agli strumenti essenziali:

Migliorare il Largest Contentful Paint

Ottimizzare il LCP richiede un approccio sistematico che affronta le quattro fasi. Qualsiasi cosa accada prima che l'elemento LCP venga dipinto, che sia legata alla rete o intensiva per la CPU, può impattare il punteggio LCP. Non inseguire solo una correzione; comprendi l'intera catena. Ecco la strategia ad alto livello:

• Ottimizzare il TTFB: Il tuo server deve essere veloce. Se il tuo TTFB è lento, nient'altro conta. Questo comporta caching lato server, uso di un CDN e codice backend efficiente. Leggi di più nella nostra guida all'ottimizzazione del TTFB.
• Eliminare la Resource Load Delay: Assicurati che l'elemento LCP sia nell' HTML iniziale così che il preload scanner del browser possa trovarlo istantaneamente. Evita le immagini di sfondo CSS per il LCP. Precarica le immagini critiche che vengono scoperte tardi. Scopri come nella nostra guida per risolvere la Resource Load Delay.
• Ridurre il Tempo di Caricamento della Risorsa: Rendi il file LCP più piccolo. Questo significa usare formati immagine moderni come AVIF, immagini responsive e compressione adeguata. Consulta la nostra guida completa su come Ottimizzare l'Immagine LCP. Puoi anche leggere di come abbiamo ridotto il LCP del 70% su un progetto reale.
• Accorciare l'Element Render Delay: Smetti di bloccare la thread principale. Differisci il JavaScript non critico, suddividi le attività lunghe e minimizza il CSS che blocca il rendering. Questo è trattato nella nostra guida per risolvere l'Element Render Delay.

Guide Correlate

Questa pagina hub copre il Largest Contentful Paint ad alto livello. Per indicazioni dettagliate e pratiche su ogni aspetto dell'ottimizzazione LCP, esplora queste guide dedicate:

• Individuare e Correggere i Problemi di LCP: Una guida diagnostica passo-passo per trovare esattamente cosa sta causando il tuo LCP lento, usando Chrome DevTools, WebPageTest e CoreDash.
• Ottimizzare l'Immagine LCP: Tutto sui formati immagine, immagini responsive, compressione e come servire l'immagine ottimale per ogni dispositivo.
• Resource Load Delay: Come assicurarsi che il browser scopra la tua risorsa LCP il prima possibile, incluso preloading, fetchpriority e come evitare le immagini di sfondo CSS.
• Resource Load Duration: Ridurre il tempo effettivo di download della risorsa LCP attraverso l'ottimizzazione della dimensione del file, la configurazione CDN e la compressione moderna.
• Element Render Delay: Eliminare il ritardo tra il download della risorsa e il rendering sullo schermo riducendo il blocco della thread principale da JavaScript e CSS.