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 disegnato sulla parte visibile dello schermo. Il tempo LCP indica il tempo in millisecondi tra la richiesta della pagina e quando quel più grande elemento contentful viene visualizzato sulla parte visibile della pagina web (above the fold).

Storia del Largest Contentful Paint

A pensarci bene, 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 il caricamento della pagina'?

Questo perché è difficile (o persino impossibile) nella maggior parte dei siti web moderni definire quando la pagina è stata caricata. Sempre più siti web utilizzano tecniche come il lazy loading o il caricamento progressivo in cui la pagina in pratica può continuare a caricarsi all'infinito. Ciò significa che la velocità della pagina non può essere misurata in un singolo momento.

Ci sono diversi momenti durante il caricamento della pagina che possono far percepire a un utente 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 è possibile cliccare su un link) sono tutti punti durante il processo di caricamento in cui il sito può sembrare lento o veloce!

Il Largest Contentful Paint (LCP) è stato scelto perché si concentra sull'esperienza utente di un visitatore. Quando si verifica il LCP si può presumere che un visitatore pensi che la pagina abbia finito di caricarsi (anche se i processi in background sono ancora in esecuzione). Il LCP è stato creato per rispondere alla domanda: 'Quando è visibile il contenuto di una pagina?'. Questo è il motivo per cui il LCP è riconosciuto come un indicatore chiave delle prestazioni incentrate sull'utente.

LCP vs FCP: Qual è la Differenza?

Il Largest Contentful Paint (LCP) e il First Contentful Paint (FCP) misurano entrambi le prestazioni di caricamento, ma catturano momenti fondamentalmente diversi nella sequenza temporale di caricamento della pagina. Il FCP si attiva 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 si attiva quando l'elemento significativo più grande viene renderizzato nel viewport.

Pensala in questo modo: 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 in modo più accurato ciò che gli utenti percepiscono come "velocità".

Per la maggior parte dei siti web, l'ottimizzazione del LCP dovrebbe essere la priorità. Se il tuo LCP è veloce, il tuo FCP sarà quasi sempre altrettanto veloce, perché il FCP si verifica prima nella sequenza temporale 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. Essendo un Core Web Vital, il Largest Contentful Paint è importante per la SEO, ma cosa ancora più importante, il LCP è fondamentale per la UX. Ai visitatori non piace 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 la 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 recente ricerca di Google stesso, la probabilità che un utente abbandoni il sito raddoppia con un tempo di caricamento di 3 secondi. Probabilmente lo riconoscerai tu stesso. Mentre si naviga su internet quasi nulla sembra così fastidioso come un sito web che si carica lentamente. Le probabilità sono che abbandonerai rapidamente una pagina che si carica lentamente.
• Altri motivi: La velocità della pagina è un fattore nel tuo punteggio Google Ad. Questo significa che puoi acquistare i tuoi annunci a un prezzo inferiore. Inoltre, superare i Core Web Vitals è uno dei prerequisiti per il box Top Stories di Google.

Un LCP veloce dà al visitatore l'idea che la pagina si carichi rapidamente. Di conseguenza, è meno probabile che un visitatore si allontani dalla pagina.

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

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

Caso Studio: Google Flights (fetchpriority ha risparmiato 700ms)

Il team di Google Flights ha aggiunto fetchpriority="high" alla propria immagine hero e ha visto migliorare il LCP di 700 millisecondi. Questa singola modifica all'attributo HTML è stata l'ottimizzazione di maggior impatto nel loro sprint sulle prestazioni. 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 un elemento LCP. L'elemento di contenuto più grande deve essere disegnato 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 all'interno di un elemento <svg>.
• Un elemento <video> (viene utilizzata l'immagine poster o il primo frame del video, a seconda di quale si verifica prima).
• Un elemento con un'immagine di sfondo caricata tramite la funzione CSS url(). (Nota: Questo è un anti-pattern per l'ottimizzazione del LCP in quanto rende l'immagine non rilevabile dallo scanner di preload del browser. Leggi la nostra guida su come differire le immagini di sfondo).

• Un elemento a livello di blocco contenente nodi di testo o altri elementi di testo inline (in 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 cover) e segnaposto (immagini a bassa entropia). Tieni presente che questo può cambiare man mano che la specifica si evolve!

Andare sul Tecnico: Misurare la Dimensione dell'Elemento LCP

Il LCP identifica l'elemento di contenuto visibile più grande nel viewport e ne calcola le dimensioni in base a una serie 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.
• Nessun bordo, padding o margine: Per tutti gli elementi, i bordi di testo e immagine, il padding e i margini vengono completamente ignorati.
• Dimensione del testo: Gli elementi di testo vengono segnalati come il rettangolo più piccolo che può essere disegnato attorno ai nodi di testo.
• Dimensione dell'immagine: Per le immagini, per calcolare la dimensione dell'elemento LCP viene utilizzata la più piccola tra le dimensioni intrinseche (larghezza e 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.

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, l'osservatore delle prestazioni del browser identifica tutti gli elementi che potrebbero essere considerati candidati LCP. Se viene renderizzato un nuovo elemento che è sia visibile all'interno del viewport sia più grande dell'elemento LCP precedentemente identificato, diventa il nuovo LCP.

Cosa imparare dai dati sul campo del LCP: In CoreDash tracciamo milioni di voci LCP al giorno. A quanto pare, per le visualizzazioni di pagina su dispositivi mobili l'elemento LCP è spesso un elemento basato su testo, un paragrafo o un'intestazione. In media (o al 75° percentile per la precisione) i Core Web Vitals verranno superati quando l'elemento LCP è un nodo di testo o persino un'immagine normale. Quando l'elemento LCP è un'immagine di sfondo, un video o un'immagine lazy-loaded, i Core Web Vitals tendono a fallire.

Cos'è 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 compreso tra 0 e 2,5 secondi è considerato un punteggio LCP buono, un punteggio LCP compreso tra 2,5 e 4 secondi ha bisogno di miglioramenti e un punteggio LCP superiore a 4 secondi è considerato scarso.

Cosa Mostrano i Dati LCP del Mondo Reale

CoreDash traccia milioni di misurazioni LCP di utenti reali ogni giorno. Ecco cosa rivelano i dati sulle prestazioni del LCP sul web.

LCP Immagine vs LCP Testo

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

L'Impatto del Precaricamento e del Lazy Loading

Le immagini LCP precaricate ottengono punteggi "buoni" nel 100% dei casi con un 75° percentile di 364ms. Al contrario, le immagini LCP lazy-loaded sono tra le più lente a 720ms, con il 4,3% dei caricamenti di pagina valutati come "scarsi". Le immagini non precaricate si comportano quasi altrettanto male a 752ms. La conclusione è chiara: precarica la tua immagine LCP e non caricarla mai in modalità lazy.

LCP Mobile vs Desktop

Il LCP mobile (764ms al 75° percentile) è 2 volte più lento del LCP desktop (380ms). Questo divario è guidato da reti mobili più lente e processori mobili meno potenti. Dato che Google utilizza l'indicizzazione mobile-first, l'ottimizzazione del LCP per i dispositivi mobili dovrebbe essere la priorità.

Statistiche Globali del LCP

Secondo l'HTTP Archive Web Almanac 2024, il 59% delle pagine mobili a livello globale raggiunge un buon punteggio LCP (inferiore a 2,5 secondi), in aumento rispetto al 44% del 2022. Il LCP rimane il Core Web Vital più difficile da superare ed è il collo di bottiglia principale per i punteggi CWV complessivi. Inoltre, il 73% degli elementi LCP su dispositivi mobili sono immagini e il 16% dei siti su dispositivi mobili commette l'errore di caricare in modalità lazy la 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 soluzione completamente diversa. Un Time to First Byte (TTFB) lento richiede lavoro lato server, mentre un lento ritardo di caricamento delle risorse richiede modifiche al tuo HTML.

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

Ecco una suddivisione delle quattro fasi:

• Time to First Byte (TTFB): Questo è 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. In tutto il web, i siti con LCP scarso spendono in media 2,27 secondi solo per il TTFB, che è quasi l'intera soglia di 2,5 secondi. L'ottimizzazione del TTFB prevede caching lato server, configurazione CDN e codice backend efficiente.
• Ritardo nel Caricamento della Risorsa (Resource Load Delay): Questo è il "divario di scoperta". Misura il tempo che intercorre tra il completamento del TTFB e l'inizio effettivo del download della risorsa LCP da parte del browser. Un lungo ritardo qui significa che il browser ha trovato la risorsa LCP in ritardo. Questo è il sintomo classico dell'utilizzo di immagini di sfondo CSS (che lo scanner di preload non può scoprire) o del rendering lato client (dove l'elemento LCP appare solo dopo l'esecuzione di JavaScript). La soluzione è garantire che il tuo elemento LCP sia nell'HTML iniziale e precaricare l'immagine LCP se il browser non può scoprirla abbastanza presto.
• Durata del Caricamento della Risorsa (Resource Load Duration): Indica quanto tempo ci vuole per scaricare effettivamente il file della risorsa LCP (l'immagine, il carattere o il video). Questa fase riguarda interamente la dimensione del file e le condizioni della rete. L'ottimizzazione significa utilizzare formati di immagine moderni come AVIF o WebP, implementare immagini responsive con srcset e servire asset tramite una CDN con la giusta compressione.
• Ritardo nel Rendering dell'Elemento (Element Render Delay): Questo è il ritardo finale. Misura il tempo che intercorre tra quando la risorsa LCP finisce di essere scaricata e quando l'elemento viene completamente renderizzato sullo schermo. Questo ritardo è quasi sempre causato dal fatto che il thread principale del browser è bloccato da altre attività, in particolare dall'elaborazione di JavaScript. CSS che blocca il rendering e script sincroni sono i colpevoli più comuni.

Ciascuna di queste aree di interesse può essere ottimizzata per migliorare il Largest Contentful Paint. Per comprendere i passaggi da intraprendere, leggi Identificare e Risolvere i Problemi del Largest Contentful Paint (LCP).

Errori Comuni nel LCP

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

Errore 1: Caricamento Lazy dell'Immagine LCP

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

Errore 2: Non Precaricare l'Immagine LCP

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

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

Questo dice al browser di iniziare immediatamente a scaricare l'immagine, senza aspettare i calcoli di CSS o di layout. Combinalo con fetchpriority="high" per il massimo impatto. Scopri di più nella nostra guida sul precaricamento 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 allo scanner di preload del browser. Il browser non può scoprirle fino a quando non ha scaricato l'HTML, analizzato il CSS e costruito l'albero di rendering. Questo aggiunge un ritardo significativo nel caricamento delle risorse. Secondo i dati CrUX, il 9% delle pagine su dispositivi mobili utilizza un'immagine di sfondo CSS come elemento LCP. La soluzione è utilizzare 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">

L'attributo fetchpriority="high" è un segnale diretto al browser che questa immagine è la risorsa con la massima priorità 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 Lab e strumenti Field. Entrambi hanno i loro vantaggi e svantaggi.

Misurare il Largest Contentful Paint con JavaScript

Per misurare il Largest Contentful Paint (LCP) utilizzando JavaScript, la Performance Observer API offre una soluzione rapida. Il seguente frammento di codice dimostra come acquisire la tempistica 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 tiene traccia della voce LCP man mano che viene segnalata, visualizzandone il timestamp e i dettagli dell'elemento nella console. Per approfondimenti più estesi, considera l'utilizzo della Libreria Web Vitals.

Misurare il Largest Contentful Paint (LCP) in Chrome DevTools

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

La scheda Performance di DevTools visualizza ora informazioni sui Core Web Vitals, inclusi i tempi e l'elemento del Largest Contentful Paint.

Misurare il Largest Contentful Paint con Strumenti Lab e Field

Siamo chiari: i dati Lab e Field hanno due scopi diversi. Hai bisogno di entrambi.

• I dati Field (RUM e CrUX) sono gli unici dati che contano davvero per superare i Core Web Vitals. Sono ciò che i tuoi veri utenti sperimentano. Google utilizza questi dati dal suo set di dati CrUX. Inizi da qui per scoprire se hai un problema.
• I dati Lab (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 rapida guida agli strumenti essenziali:

Migliorare il Largest Contentful Paint

L'ottimizzazione del LCP richiede un approccio sistematico che affronti le quattro fasi. Qualsiasi cosa accada prima che l'elemento LCP venga disegnato, sia legata alla rete che ad uso intensivo della CPU, può influire sul punteggio LCP. Non limitarti a inseguire una singola soluzione; comprendi l'intera catena. Ecco la strategia di alto livello:

• Ottimizza il TTFB: Il tuo server deve essere veloce. Se il tuo TTFB è lento, nient'altro conta. Ciò comporta caching lato server, utilizzo di una CDN e codice backend efficiente. Leggi di più nella nostra guida per ottimizzare il TTFB.
• Elimina il Ritardo nel Caricamento della Risorsa (Resource Load Delay): Assicurati che l'elemento LCP sia nell'HTML iniziale in modo che lo scanner di preload del browser possa trovarlo all'istante. Evita le immagini di sfondo CSS per il LCP. Precarica le immagini critiche che vengono scoperte in ritardo. Scopri come nella nostra guida per correggere il Resource Load Delay.
• Riduci il Tempo di Caricamento della Risorsa: Rendi più piccolo il file LCP. Questo significa usare formati di immagine moderni come AVIF, immagini responsive e un'adeguata compressione. Consulta la nostra guida completa su come Ottimizzare l'Immagine LCP. Puoi anche leggere come abbiamo abbassato il LCP del 70% in un progetto reale.
• Riduci il Ritardo nel Rendering dell'Elemento (Element Render Delay): Smetti di bloccare il thread principale. Differisci JavaScript non critico, spezza i task lunghi e minimizza i CSS che bloccano il rendering. Questo è trattato nella nostra guida per correggere l'Element Render Delay.

Approfondimenti Correlati

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

• Identificare e Risolvere i Problemi LCP: Una guida diagnostica passo passo per trovare esattamente cosa causa il tuo LCP lento, usando Chrome DevTools, WebPageTest e CoreDash.
• Ottimizzare l'Immagine LCP: Tutto sui formati di immagine, immagini responsive, compressione e distribuzione dell'immagine ottimale per ogni dispositivo.
• Ritardo nel Caricamento della Risorsa (Resource Load Delay): Come garantire che il browser scopra la tua risorsa LCP il prima possibile, incluso il precaricamento, fetchpriority e come evitare le immagini di sfondo CSS.
• Durata del Caricamento della Risorsa (Resource Load Duration): Ridurre il tempo di download effettivo della risorsa LCP tramite l'ottimizzazione delle dimensioni del file, la configurazione CDN e la compressione moderna.
• Ritardo nel Rendering dell'Elemento (Element Render Delay): Eliminare il ritardo tra il download della risorsa e il rendering su schermo riducendo il blocco del thread principale da parte di JavaScript e CSS.