Largest Contentful Paint (LCP) e SEO

TL;DR — Il Largest Contentful Paint (LCP) misura quanto tempo impiega l’elemento più grande sullo schermo — di solito un’immagine principale o un grande blocco di testo — a comparire dopo che qualcuno fa clic sulla tua pagina. Sotto i 2,5 secondi è buono. È una delle tre Core Web Vitals di Google, ed è quella con cui la maggior parte dei siti fa più fatica.

Cos’è l’LCP

La prima impressione che le persone hanno del tuo sito è la velocità con cui sembra caricarsi. L’LCP cerca di dare un numero a questo. Misura il tempo necessario per caricare il singolo elemento visibile più grande nel viewport — la parte della pagina che puoi vedere senza scorrere.

Quel “elemento più grande” di solito è una di queste due cose:

• Una grande immagine — un banner principale, una foto di prodotto, un’immagine in evidenza.
• Un grande blocco di testo — comune nelle pagine di articoli che non iniziano con un’immagine.

L’LCP è il momento in cui quell’elemento finisce di essere renderizzato, misurato dal momento in cui la pagina ha iniziato a caricarsi. Più basso è il numero, più veloce sembra la tua pagina.

Il punteggio

Google suddivide l’LCP in tre categorie:

• Buono: 2,5 secondi o meno
• Da migliorare: da 2,5 a 4 secondi
• Scarso: più di 4 secondi

L’obiettivo è quel traguardo dei 2,5 secondi. E viene giudicato sui visitatori reali del tuo sito, non su un test eseguito una volta sola — quindi è l’esperienza che il tuo pubblico effettivo ottiene sui suoi telefoni e connessioni reali.

Perché può essere difficile

L’LCP è la Core Web Vital con cui le persone faticano di più. Questo perché ha il maggior numero di parti in movimento: il tuo server deve rispondere, il browser deve trovare e scaricare l’immagine, e poi deve effettivamente renderizzarla. Un rallentamento in uno qualsiasi di questi passaggi fa salire l’intero numero. Comprimere le immagini è un primo tentativo comune — e a volte aiuta — ma spesso non è il vero collo di bottiglia.

È anche più difficile su mobile che su desktop, perché i telefoni hanno connessioni più lente e meno potenza di elaborazione.

Cosa fare per primo

Tre vittorie rapide che risolvono gli errori più comuni:

1. Non usare il caricamento differito per l’immagine principale. Il caricamento differito dice al browser di aspettare prima di recuperare un’immagine. È ottimo per gli elementi in fondo alla pagina, ma se lo applichi all’immagine principale ritardi deliberatamente la cosa più importante sullo schermo. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. Dì al browser che l’immagine principale è importante — esiste un attributo (fetchpriority="high") che fa esattamente questo. Mettilo sull’unica immagine che è effettivamente il tuo candidato LCP; applicarlo a più immagini diluisce il segnale.
3. Accelera il tuo server. Se il tuo server è lento a rispondere, qualsiasi altra cosa fai conta poco.

Vuoi il modello mentale completo — le quattro sotto-parti dell’LCP, come trovare il tuo elemento LCP, le questioni di rendering e font, e quanto questo conta davvero per il posizionamento? Passa alla scheda Avanzate.

TL;DR — L’LCP è il tempo di rendering dell’immagine o del blocco di testo più grande visibile nel viewport, relativo al momento in cui la pagina ha iniziato a caricarsi. Buono è ≤ 2,5 s al 75° percentile degli utenti reali (suddivisi per dispositivo); 2,5–4 s richiede lavoro, oltre 4 s è scarso. È una delle tre Core Web Vitals e si suddivide in quattro sotto-parti — TTFB, ritardo del caricamento della risorsa, durata del caricamento della risorsa, ritardo del rendering dell’elemento — dove TTFB e durata del caricamento di solito dominano (linee guida, non quote fisse — diagnostica la tua pagina). Le soluzioni principali: non usare mai il caricamento differito per l’immagine LCP, aggiungi fetchpriority="high" sul candidato effettivo, precaricala quando non è nell’HTML, elimina CSS/JS che bloccano il rendering e correggi il TTFB. È una metrica sul campo — gli strumenti di laboratorio la approssimano soltanto — e l’elemento LCP può cambiare durante il caricamento. Google conferma che le Core Web Vitals alimentano i sistemi di ranking ma non pubblica un peso esatto per l’LCP né lo definisce un criterio di spareggio; la rilevanza dei contenuti domina ancora.

Cosa misura esattamente l’LCP

LCP riporta il tempo di rendering dell’elemento immagine o testo più grande visibile nel viewport, misurato rispetto al momento in cui l’utente ha navigato per la prima volta alla pagina. L’inquadramento di Google: è il proxy standardizzato più vicino a quando il contenuto principale appare all’utente. Ha sostituito metriche precedenti e più vaghe come First Meaningful Paint e Speed Index.

Alcune cose che confondono subito le persone:

• Non è il “tempo di caricamento della pagina”. Una pagina può avere tutte le risorse scaricate e avere comunque un LCP lento se il rendering dell’elemento più grande è stato bloccato. LCP riguarda quell’unico elemento, non l’intera pagina.
• Non è la stessa cosa di FCP. First Contentful Paint scatta quando qualsiasi contenuto appare per la prima volta; LCP attende l’elemento più grande. Una pagina può avere un FCP veloce (la barra di navigazione viene renderizzata) e un LCP lento (l’immagine principale viene caricata tardi).
• È una metrica dinamica. Il browser invia un nuovo candidato LCP ogni volta che un elemento più grande diventa visibile. L’ultima voce prima che l’utente interagisca (tocco, scorrimento, pressione di un tasto) o che la pagina venga scaricata è il valore che conta: l’interazione spesso cambia ciò che è visibile, quindi la segnalazione si ferma lì. Un candidato che viene successivamente rimosso dal DOM non cancella la propria voce: rimane l’elemento segnalato a meno che un elemento ancora più grande non venga renderizzato prima che la segnalazione si fermi.

Le soglie — e perché 2,5 secondi

Valutato al 75° percentile dei caricamenti di pagina reali degli utenti, segmentato per tipo di dispositivo. Quindi tre visite su quattro devono rientrare sotto i 2,5 s perché un’origine superi il test.

Perché proprio 2,5? La metodologia delle soglie di Google si è basata su due cose: ricerche sulla percezione umana che indicano circa 1–3 secondi come la fascia che sembra “immediata”, e dati di raggiungibilità di CrUX che mostrano come 2,5 s fosse costantemente raggiungibile per siti ben ottimizzati senza essere banalmente facile. Obiettivi più stringenti come 1,5 s o 2,0 s non erano costantemente raggiungibili su un numero sufficiente di origini, quindi non sono stati adottati.

Cosa conta come elemento LCP

I tipi di elemento considerati per LCP:

• Elementi <img>
• Elementi <image> all’interno di un <svg>
• Elementi <video> (il tempo di caricamento dell’immagine poster, o il primo fotogramma, a seconda di quale avviene prima)
• Un elemento con un’immagine di sfondo caricata tramite la funzione CSS url()
• Elementi a livello di blocco contenenti nodi di testo o altri figli di testo inline

La dimensione segnalata è ciò che è effettivamente visibile nel viewport: le porzioni tagliate o scorse fuori non contano, e per le immagini è la dimensione visibile o la dimensione intrinseca, a seconda di quale è minore. Margini, padding e bordi vengono ignorati. Un piccolo numero di elementi viene escluso da euristiche: qualsiasi cosa con opacity: 0, elementi che coprono l’intero viewport (trattati come sfondi) e immagini segnaposto a bassa entropia.

Circa tre quarti delle pagine hanno un’immagine come elemento LCP, quindi il lavoro sulle immagini è di solito la prima mossa giusta. Ma non sempre, e non sempre compressione (ne parleremo più avanti). La parte rimanente sono LCP testuali, dove la leva è completamente diversa: è il caricamento dei font, non il peso delle immagini.

Le quattro sotto-parti — la parte che la maggior parte degli articoli salta

Questo è lo schema con cui inizierei qualsiasi diagnosi LCP. web.dev suddivide LCP in quattro sotto-parti sequenziali:

1. Time to First Byte (TTFB) — da quando l’utente inizia a caricare la pagina a quando il browser riceve il primo byte di HTML. Quota tipica: ~40% del LCP totale.
2. Ritardo di caricamento della risorsa — il divario tra TTFB e il momento in cui il browser inizia a caricare la risorsa LCP. Questo è il tempo di scoperta. Quota tipica: sotto il 10%.
3. Durata del caricamento della risorsa — quanto tempo impiega la risorsa LCP stessa a essere scaricata. Quota tipica: ~40%.
4. Ritardo di rendering dell’elemento — da quando la risorsa finisce di caricarsi a quando l’elemento viene effettivamente renderizzato. Quota tipica: sotto il 10%.

Il principio alla base della tabella: la stragrande maggioranza del tempo LCP dovrebbe essere spesa caricando il documento HTML e la risorsa LCP. Qualsiasi tratto in cui né l’uno né l’altra è in caricamento è un’opportunità di miglioramento.

web.dev è esplicito sul fatto che queste percentuali sono linee guida, non regole rigide — non trasformarle in obiettivi di secondi assoluti e non forzare ogni pagina a rispettare la suddivisione. Hanno senso solo in relazione tra loro, e se il tuo LCP è già costantemente entro 2,5 secondi, le proporzioni relative non contano affatto. Usa la tabella per individuare quale sotto-componente sta consumando una quota sproporzionata sulla tua pagina, poi correggi quella — non per inseguire una suddivisione esatta 40/10/40/10.

Ed ecco il punto che ribalta l’assunto comune: a partire da febbraio 2025 queste quattro sotto-componenti sono disponibili nell’API CrUX per gli LCP delle immagini, e l’analisi dei dati di HTTP Archive da parte del team di Chrome ha rilevato che il tempo di download dell’immagine era spesso la parte più piccola del tempo LCP. In altre parole, “basta comprimere le mie immagini” spesso corregge la sotto-componente sbagliata. TTFB e ritardo di scoperta sono spesso le leve più efficaci.

Come trovare il tuo elemento LCP

Prima di ottimizzare qualsiasi cosa, scopri quale elemento è il tuo LCP e quale sotto-componente è il collo di bottiglia:

• PageSpeed Insights — la sezione Diagnostics segnala l’elemento LCP e la scheda dei dati sul campo mostra il punteggio dei tuoi utenti reali.
• Chrome DevTools — il pannello Performance segna il nodo LCP sulla timeline.
• La libreria JS web-vitals — registra LCP (e l’elemento) dal tuo monitoraggio degli utenti reali.

Come migliorare l’LCP

Associa ogni correzione alla sotto-componente che mira:

Correggi il ritardo di caricamento della risorsa (scoperta). Questa è quella a più alta leva e la più comunemente rotta.

• Non caricare mai in modo differito l’immagine LCP. loading="lazy" sull’elemento LCP aggiunge sempre un ritardo di caricamento inutile. Riserva il caricamento differito alle immagini fuori dalla prima schermata.
• Aggiungi fetchpriority="high" all’immagine LCP probabile così il browser la recupera presto ad alta priorità.
• Precaricala con <link rel="preload"> quando l’immagine non è scopribile nell’HTML iniziale — ad esempio, quando viene caricata tramite CSS o JavaScript. Caricare l’immagine principale tramite JS è una pratica da evitare proprio perché nasconde l’URL allo scanner di preload del browser.
• Ospita le risorse critiche sullo stesso origin così il browser non paga un extra setup di connessione.

Preload e fetchpriority risolvono problemi diversi, quindi non ricorrere a entrambi per abitudine. Preload espone una risorsa che lo scanner di preload del browser altrimenti scoprirebbe tardi (un’immagine caricata tramite JS o CSS, ad esempio); fetchpriority cambia la priorità di fetch di una risorsa che il browser ha già trovato. Se scoperta e priorità sono già corrette — l’immagine è un semplice <img> nell’HTML iniziale — aggiungere l’uno o l’altro può fare poco oltre a richieste extra. Controlla una traccia, applica quello che corrisponde al problema reale e conferma che il numero sul campo si è mosso.

Correggi il ritardo di rendering dell’elemento.

• Riduci o inline il CSS che blocca il rendering; rimanda gli stili non critici.
• Evita script sincroni nel <head>.
• Preferisci il rendering lato server o la generazione statica così il markup arriva pronto per il paint, e spezza i task lunghi sul thread principale.

Riduci la durata del caricamento della risorsa.

• Formati immagine moderni (WebP, AVIF), compressione sensata e una CDN.
• Cache-Control efficiente. E non ignorare la contesa di rete — il caricamento differito delle altre immagini sotto la piega può liberare banda così l’immagine LCP arriva prima.

Riduci il TTFB.

• Minimizza i redirect, elimina i parametri URL unici non necessari e ottimizza il tempo di risposta del server. Nota che l’LCP include qualsiasi tempo di unload dalla pagina precedente, il setup di connessione e il tempo di redirect — tutto ciò confluisce nel TTFB.

Caso speciale: LCP basato su testo. Quando l’elemento più grande è testo, il percorso critico è il caricamento dei font, non il peso delle immagini. font-display: optional o i font di sistema eliminano il ritardo di rendering indotto dai font; font-display: swap senza pre-caricare il file del font può introdurlo.

Lab vs. campo: questa distinzione conta

LCP è fondamentalmente una metrica sul campo. Google la valuta su utenti reali tramite CrUX, mostrata nella scheda campo di PageSpeed Insights e nel report Core Web Vitals di Search Console. Sono questi dati sul campo a influenzare il ranking.

Gli strumenti di laboratorio — Lighthouse, Chrome DevTools, WebPageTest — la approssimano solo in condizioni simulate, e non usano nemmeno lo stesso punteggio. Lighthouse applica soglie desktop più severe (Buono ≤ 1,2 s) rispetto allo standard sul campo (≤ 2,5 s). Quindi un punteggio Lighthouse positivo non garantisce un punteggio CrUX positivo, e viceversa. Usa gli strumenti di laboratorio per eseguire il debug e riprodurre; affidati ai dati sul campo per il verdetto effettivo.

C’è un secondo motivo per cui i numeri di laboratorio e sul campo possono divergere, utile da conoscere affinché una lettura anomala non ti faccia inseguire un bug fantasma: l’attuale API del browser LargestContentfulPaint (ancora una W3C Working Draft) è limitata a un singolo caricamento di documento. Non si azzera da sola sui ripristini della cache back/forward (bfcache) o sulle navigazioni SPA nello stesso documento, e le pagine che iniziano fuori schermo — schede in background, pagine prerenderizzate — possono riportare valori gonfiati perché il tempo parte dal caricamento piuttosto che da quando la pagina è diventata effettivamente visibile. L’algoritmo di segnalazione si ferma anche su input utente qualificanti, quindi se un utente interagisce prima che il contenuto principale venga visualizzato, LCP non lo cattura. Nulla di tutto ciò cambia la tabella delle soglie sopra; spiega perché il numero di una sessione specifica può sembrare sbagliato quando la navigazione sottostante non è un semplice primo caricamento.

LCP influisce sul ranking?

Sì, nel senso che Google conferma che le Core Web Vitals alimentano i suoi sistemi di ranking e raccomanda di ottenere buoni punteggi. La documentazione attuale di Search Central, però, non pubblica un peso esatto per LCP e non lo descrive come criterio di spareggio. Secondo la formulazione di Google, l’esperienza di pagina “can contribute to success in Search” (traduzione) «può contribuire al successo nella Ricerca» per le query in cui più pagine offrono già contenuti pertinenti e comparabili; un buon punteggio non garantisce comunque un aumento del ranking. Pertinenza e qualità dei contenuti restano predominanti. Ottimizza LCP perché una pagina percepita come più veloce è davvero migliore per gli utenti e per le conversioni, non perché il meccanismo sia documentato come criterio di spareggio.

Un paio di realtà dai dati: tra i Core Web Vitals, LCP è quello che i siti faticano di più a migliorare, ed è notevolmente più difficile su mobile che su desktop — CPU e connessioni più lente. Su 3G e più lenti, la soglia di 2,5 s può sembrare quasi impossibile da raggiungere.

Dove si colloca

LCP è uno dei tre Core Web Vitals, insieme a Interaction to Next Paint e Cumulative Layout Shift. La sua prima sotto-parte, Time to First Byte, è una metrica diagnostica a sé, e First Contentful Paint si trova subito accanto sulla timeline di caricamento. Li vedrai tutti in PageSpeed Insights, Lighthouse e Chrome User Experience Report (CrUX). Ognuno è un approfondimento a sé in questo cluster.

Riepilogo AI

Una sintesi della versione Advanced:

• LCP = tempo di rendering del più grande elemento visibile (immagine o testo), relativo all’avvio del caricamento della pagina. È il proxy standardizzato più vicino a “quando appare il contenuto principale”.
• Soglie: Buono ≤ 2,5 s, Da migliorare 2,5–4 s, Scarso > 4 s — al 75° percentile degli utenti reali, suddiviso per dispositivo. È una delle tre Core Web Vitals.
• Non è il tempo di caricamento della pagina, né FCP. FCP = primo pixel di qualsiasi contenuto; LCP = l’elemento più grande. LCP è anche dinamico — il candidato più grande può cambiare durante il caricamento; conta l’ultimo prima dell’interazione dell’utente.
• Elementi LCP: <img>, <image> in <svg>, poster di <video>, CSS background-image: url(), o un elemento di testo a livello di blocco. Circa 3 pagine su 4 hanno un’immagine come LCP; le restanti sono testo (dove i font, non il peso delle immagini, sono la leva).
• Quattro sotto-componenti: TTFB (~40%), ritardo di caricamento della risorsa (<10%), durata del caricamento della risorsa (~40%), ritardo di rendering dell’elemento (<10%) — web.dev le chiama linee guida, non quote fisse; diagnostica per pagina piuttosto che inseguire una suddivisione esatta. Dati CrUX 2025: il download dell’immagine è spesso la parte più piccola — quindi “basta comprimere le immagini” spesso risolve il problema sbagliato.
• Correzioni principali: non caricare mai in modo differito l’immagine LCP; aggiungi fetchpriority="high" sul candidato effettivo; precaricala quando non è nell’HTML (precaricamento e fetchpriority risolvono problemi diversi — non usarli entrambi per abitudine); riduci CSS/JS che bloccano il rendering; riduci TTFB.
• Campo, non laboratorio. CrUX/Search Console guidano le classifiche; Lighthouse approssima e usa soglie desktop più severe (≤ 1,2 s). L’attuale API LargestContentfulPaint è limitata ai caricamenti di documenti e non si resetta per i ripristini bfcache o le navigazioni SPA nello stesso documento.
• Classifiche: Google conferma che i sistemi di ranking CWV alimentano le classifiche ma non pubblica un peso esatto per LCP e non lo definisce un tiebreaker; la rilevanza dei contenuti domina ancora. La CWV più difficile da migliorare, e più difficile su mobile.

Documentazione ufficiale

Guida di prima mano dai team Chrome e Search di Google.

web.dev (team Chrome)

• Largest Contentful Paint (LCP) — la definizione canonica: cosa conta come elemento LCP, come viene calcolata la dimensione, quando termina la segnalazione e le API di misurazione.
• Ottimizzare Largest Contentful Paint — lo schema delle quattro sotto-componenti e la guida completa all’ottimizzazione.
• Core Web Vitals — dove si colloca LCP tra le tre Core Web Vitals.
• Come sono state definite le soglie delle metriche Core Web Vitals — la ricerca e i dati di raggiungibilità dietro la soglia di 2,5 s.

Chrome per sviluppatori

• Sotto-parti dell’immagine LCP e RTT ora disponibili in CrUX — il rilascio di dati sul campo di febbraio 2025 delle quattro sotto-componenti (solo per LCP di immagini).
• Largest Contentful Paint in Lighthouse — la metrica di laboratorio e il suo punteggio specifico per dispositivo.

Google Search Central

• Comprendere le Core Web Vitals e i risultati di Ricerca Google — come le Core Web Vitals influenzano la Ricerca.

Citazioni dalla fonte

Dichiarazioni pubbliche dalla documentazione e dal team di Google. Ogni link è un link profondo che salta al passaggio citato.

web.dev — definizione e comportamento (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (traduzione) «L’LCP riporta il tempo di rendering dell’immagine, del blocco di testo o del video più grande visibile nel viewport, misurato rispetto al momento in cui l’utente ha navigato per la prima volta alla pagina.» Vai alla citazione
• Su cosa viene misurato: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (traduzione) «L’LCP non considera margini, padding o bordi applicati tramite CSS.» Vai alla citazione
• Su quando termina la segnalazione: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (traduzione) «Il browser smetterà di segnalare nuove voci non appena l’utente interagisce con la pagina (tramite tocco, scorrimento o pressione di un tasto), poiché l’interazione dell’utente spesso modifica ciò che è visibile all’utente.» Vai alla citazione
• Su cosa è incluso nella misurazione: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (traduzione) «È importante notare che l’LCP include qualsiasi tempo di unload dalla pagina precedente, il tempo di configurazione della connessione, il tempo di reindirizzamento e altri ritardi di Time To First Byte (TTFB).» Vai alla citazione

web.dev — ottimizzazione (Philip Walton & Barry Pollard, Google)

• La regola più importante per il caricamento differito: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (traduzione) «Non caricare mai in modo differito l’immagine LCP, poiché ciò comporterà sempre un ritardo inutile nel caricamento della risorsa.» Vai alla citazione
• Il principio alla base dei sotto-obiettivi: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (traduzione) «La stragrande maggioranza del tempo LCP dovrebbe essere dedicata al caricamento del documento HTML e della sorgente LCP.» Vai alla citazione

Google Search Central — posizionamento

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (traduzione) «Raccomandiamo vivamente ai proprietari di siti di ottenere buoni Core Web Vitals per avere successo nella Ricerca e per garantire in generale un’ottima esperienza utente.» (Riportato dal documento Core Web Vitals di Search Central; verifica sulla pagina live prima di considerarlo definitivo.)

Checklist per la correzione dell’LCP

Lavoraci più o meno dall’alto verso il basso — prima discovery e TTFB, perché di solito sono le leve più grandi e più comunemente danneggiate.

• Individuato l’elemento LCP effettivo (Diagnostica PageSpeed Insights, pannello Performance di DevTools o libreria web-vitals) — non ottimizzare alla cieca.
• Controllate le quattro sotto-parti per vedere quale sia il collo di bottiglia prima di cambiare qualsiasi cosa.
• L’immagine LCP non è loading="lazy" (il caricamento differito è riservato alle immagini fuori dalla prima schermata).
• L’immagine LCP ha fetchpriority="high".
• L’immagine LCP è rilevabile nell’HTML iniziale — o precaricata (<link rel="preload">) se viene caricata tramite CSS/JS.
• L’immagine principale non viene caricata tramite JavaScript (che la nasconderebbe all’analizzatore di precaricamento).
• CSS che blocca il rendering ridotto o incorporato; stili non critici differiti.
• Nessuno script sincrono nel <head>; attività lunghe suddivise.
• Formato immagine moderno (WebP/AVIF), compressione sensata, servita tramite CDN con buon Cache-Control.
• Immagini fuori dalla prima schermata caricate in modo differito per non competere per la banda con l’immagine LCP.
• TTFB affrontato: reindirizzamenti ridotti al minimo, risposta del server ottimizzata, parametri URL inutili eliminati.
• LCP di testo? Usare font-display: optional o font di sistema e precaricare qualsiasi file di font sostituito.
• Verificato con dati sul campo (CrUX / Search Console), non solo con un test di laboratorio Lighthouse.

Scheda rapida LCP

Soglie (75° percentile degli utenti reali, per dispositivo)

Le quattro sotto-parti — cosa sono e come risolverle

Cosa può essere l’elemento LCP

• <img> · <image> dentro <svg> · poster di <video> · CSS background-image: url() · testo a livello di blocco

Esclusi per euristica: opacity: 0, elementi “sfondo” a tutto viewport, segnaposto a bassa entropia.

Fatti rapidi

• LCP è una metrica sul campo (CrUX / Search Console guidano il ranking); Lighthouse approssima solo e usa una soglia desktop Buono più severa di ≤ 1,2 s.
• L’elemento LCP può cambiare durante il caricamento; conta l’ultimo candidato prima dell’interazione dell’utente.
• Circa 3 pagine su 4 hanno un LCP immagine; le altre sono testo (i font sono la leva).
• Il tempo di download dell’immagine è spesso la sotto-parte più piccola — la compressione non è sempre la risposta.
• LCP ≠ FCP; LCP ≠ tempo totale di caricamento della pagina.

Strumenti per misurare e correggere l’LCP

Dati sul campo (quelli usati per il ranking)

• PageSpeed Insights — la scheda campo mostra il tuo CrUX LCP degli utenti reali; la Diagnostica segnala l’elemento LCP.
• Search Console — report Core Web Vitals — stato LCP su tutti i tuoi URL, raggruppati, su dati di utenti reali.
• Chrome User Experience Report (CrUX) — il dataset di campo sottostante; da febbraio 2025 include le quattro sotto-parti LCP immagine tramite l’API.
• Libreria JS web-vitals — registra LCP e l’elemento LCP dal tuo monitoraggio di utenti reali.

Dati di laboratorio (per il debug)

• Lighthouse — LCP di laboratorio rapido e un elenco di opportunità (ricorda: soglie desktop più severe rispetto al campo).
• Chrome DevTools — pannello Performance — segna il nodo LCP e la timeline completa del rendering.
• WebPageTest — diagramma della sequenza delle richieste per individuare quale sotto-parte è lenta.

Crawler SEO

• Ahrefs Site Audit — evidenzia problemi di Core Web Vitals / performance su tutto il sito su larga scala.

Come gli strumenti stessi vengono valutati

Un esempio dal vivo della metrica descritta in questa pagina — servizi noti di velocità della pagina e monitoraggio classificati in base al loro LCP mobile reale degli utenti (dati sul campo Chrome UX Report):

Correzioni LCP che mirano al problema sbagliato

Caricamento differito dell’immagine principale

loading="lazy" ritarda la scoperta di un’immagine nella prima schermata che probabilmente diventerà LCP. Caricala subito, assegna al candidato probabile fetchpriority="high" e riserva il caricamento differito alle immagini fuori dalla prima schermata.

Comprimere ogni immagine prima di trovare il collo di bottiglia

La durata del download dell’immagine è solo una delle quattro sotto-parti dell’LCP e potrebbe essere la più piccola. Identifica l’elemento LCP e ispeziona TTFB, ritardo di caricamento, durata del caricamento e ritardo di rendering prima di scegliere una soluzione.

Caricare l’immagine principale tramite JavaScript

Un’immagine iniettata tramite JS nasconde il suo URL allo scanner di preload del browser e crea ritardo nel caricamento della risorsa. Metti l’immagine nell’HTML iniziale o pre-caricala quando CSS o JS devono gestirla.

Dichiarare vittoria da una singola esecuzione di Lighthouse

Lighthouse è una diagnostica controllata, mentre il verdetto CWV di Google proviene dai dati field di CrUX. Usa le esecuzioni di laboratorio per verificare il meccanismo e attendi che i dati degli utenti reali mostrino se il risultato p75 è migliorato.

La risorsa LCP inizia in ritardo

Sintomo: appare un lungo intervallo tra TTFB e la richiesta della risorsa LCP. Causa probabile: caricamento differito, scoperta tramite JS, immagine di sfondo CSS o bassa priorità di recupero. Soluzione: rendi la risorsa scopribile nell’HTML iniziale, rimuovi il caricamento differito, applica fetchpriority="high" o pre-caricala. Conferma che la richiesta si sposti prima in una traccia.

La risorsa si carica ma l’LCP scatta comunque in ritardo

Sintomo: la durata del caricamento termina ben prima dell’evento LCP. Causa probabile: CSS che blocca il rendering, JavaScript sincrono, un’attività lunga o rendering dei font per un LCP di testo. Soluzione: riduci il lavoro bloccante e testa la strategia dei font per il testo; conferma che il ritardo di rendering dell’elemento si riduca.

LCP di laboratorio buono ma LCP sul campo scarso

Sintomo: Lighthouse supera mentre CrUX o Search Console no. Causa probabile: gli utenti reali hanno dispositivi, reti, stati di cache, posizioni geografiche o elementi LCP diversi. Soluzione: segmenta i dati sul campo, cattura i dettagli di elemento/sotto-parte RUM e riproduci il segmento lento invece di ottimizzare solo il profilo di laboratorio predefinito.

L’elemento LCP segnalato cambia tra le esecuzioni

Sintomo: DevTools identifica immagini o blocchi di testo diversi. Causa probabile: breakpoint responsive, personalizzazione, modifiche DOM tardive o candidati concorrenti. Soluzione: testa viewport e stati rappresentativi, quindi ottimizza ogni candidato ricorrente invece di assumere che una singola immagine principale desktop copra tutti gli utenti.

Scoperta dell’immagine principale: ritardata e anticipata

Un’implementazione ritardata semplificata nasconde l’immagine dietro JavaScript:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

Il browser può scoprire e dare priorità a questa versione durante l’analisi dell’HTML:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

Immagine di sfondo CSS: non divulgata vs pre-caricata

Quando l’immagine LCP deve rimanere uno sfondo CSS, divulgala prima che il foglio di stile finisca:

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

Il preload aiuta solo quando il suo URL e gli attributi della richiesta corrispondono alla risorsa effettiva.

Elenca i recenti candidati LCP in Chrome DevTools

Incolla questo nella Console di Chrome DevTools, ricarica la pagina e osserva ogni candidato che il browser segnala. L’ultimo candidato prima dell’interazione è quello rilevante.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Trova immagini nella prima schermata probabilmente caricate in modo differito

Esegui questo nella Console di DevTools. Elenca le immagini caricate in modo differito il cui bordo superiore inizia nella viewport corrente; verifica il vero candidato LCP prima di rimuovere l’attributo.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Estrai gli attributi di priorità delle immagini in un crawler

Usa questo XPath nell’estrazione personalizzata di Screaming Frog per restituire le immagini contrassegnate come ad alta priorità:

//img[@fetchpriority='high']/@src

Dimostra che una correzione LCP è stata applicata

Test dell’ordine di scoperta

Test da eseguire: registra una traccia delle prestazioni di DevTools dopo aver modificato l’immagine principale. Risultato atteso: la richiesta LCP inizia prima e non viene caricata in modo differito. Interpretazione del fallimento: la risorsa rimane nascosta, de-prioritizzata o bloccata dietro un’altra dipendenza. Finestra di monitoraggio: risultato di laboratorio immediato. Trigger di rollback: la modifica ritarda un’altra risorsa critica o rende l’LCP di laboratorio costantemente peggiore.

Test del ritardo di rendering

Test da eseguire: confrontare il completamento della risorsa LCP e l’evento LCP in tracce equivalenti prima/dopo. Risultato atteso: il ritardo di rendering dell’elemento si riduce senza una nuova regressione di layout o visiva. Interpretazione del fallimento: CSS, JavaScript o font bloccano ancora la pittura. Finestra di monitoraggio: immediata su viewport rappresentative. Trigger di rollback: rendering rotto, stili mancanti o un LCP ricorrente peggiore.

Test di esito sul campo

Test da eseguire: monitorare il LCP p75 a livello di URL tramite CrUX o RUM di prima parte dopo la distribuzione. Risultato atteso: il p75 si avvicina o rimane entro la soglia Buono senza regredire INP o CLS. Interpretazione del fallimento: il caso di laboratorio non era rappresentativo o un’altra sotto-parte domina le visite reali. Finestra di monitoraggio: il RUM può essere in anticipo; CrUX necessita che la sua finestra mobile di 28 giorni si rinnovi. Trigger di rollback: una regressione sul campo sostenuta legata al rilascio.

Metriche LCP da monitorare

LCP p75 sul campo

Metrica: LCP al 75° percentile per fattore di forma. Cosa ti dice: se gli utenti reali soddisfano la soglia di caricamento dei Core Web Vitals. Come ottenerla: CrUX, Search Console o RUM di prima parte. Riferimento / intervallo realistico: Buono è a o sotto 2,5 secondi; segmenta mobile e desktop. Cadenza: settimanale, con la finestra mobile CrUX registrata.

Distribuzione delle sotto-parti LCP

Metrica: TTFB, ritardo di caricamento della risorsa, durata del caricamento e ritardo di rendering dell’elemento per LCP. Cosa ti dice: quale fase determina l’attesa. Come ottenerla: tracce di laboratorio rappresentative e sotto-parti LCP dell’immagine da CrUX/RUM dove disponibili. Riferimento / intervallo realistico: usa la suddivisione diagnostica approssimativa 40/10/40/10 dell’articolo come guida, non una promessa di prestazioni universale. Cadenza: dopo i rilasci dei modelli di pagina e mensilmente per quelli prioritari.

Copertura URL con LCP Buono

Metrica: gruppi di URL importanti con LCP sul campo Buono. Cosa ti dice: se il miglioramento è ampio o limitato a una pagina campione. Come ottenerla: gruppi CWV di Search Console più CrUX a livello di URL per le pagine prioritarie. Riferimento / intervallo realistico: stabilisci un valore iniziale per ogni modello di pagina; gli URL a basso traffico potrebbero non avere dati sul campo individuali. Cadenza: settimanale.

Mettiti alla prova: Largest Contentful Paint

Cinque domande rapide sulla misurazione e diagnosi dell’LCP. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Che cos’è Largest Contentful Paint (LCP) e come migliorarlo — la mia guida completa all’LCP sul blog di Ahrefs.
• Che cosa sono le Core Web Vitals (CWV) e come migliorarle — come l’LCP si inserisce con INP e CLS, e perché è il più difficile da risolvere.
• Guida introduttiva alla SEO tecnica — dove la performance della pagina si colloca nel quadro più ampio.

Ufficiale (Google / Chrome)

• Largest Contentful Paint (LCP) e Ottimizzare LCP — la coppia canonica.
• Come sono state definite le soglie CWV — il perché dietro i 2,5 s.

Da altri

• Correggere Largest Contentful Paint ottimizzando il caricamento delle immagini — il punto di vista di MDN orientato agli sviluppatori, con particolare attenzione alla contesa di banda e alla pratica da evitare delle immagini inserite via JavaScript.
• Prestazioni — Web Almanac 2025 — l’approfondimento annuale di HTTP Archive; fonte per le statistiche di adozione su fetchpriority, utilizzo del precaricamento, ripartizione LCP tra immagini e testo e tassi di superamento per dispositivo.
• Largest Contentful Paint (LCP) — la documentazione di DebugBear copre l’analisi della sequenza delle richieste per individuare le sotto-parti, le avvertenze sui JPEG progressivi e i casi limite di iframe e navigazioni leggere.
• Largest Contentful Paint (LCP): che cos’è, come misurarlo e ottimizzarlo — corewebvitals.io; confronti RUM reali, uno studio di caso sull’impatto aziendale (Vodafone Italia) e il risultato di Google Flights con fetchpriority.
• Largest Contentful Paint nella documentazione web MDN — riferimento MDN per l’API LargestContentfulPaint, i tipi di elemento e la compatibilità dei browser.

Statistiche da citare

• L’LCP è la Core Web Vital più difficile da superare. Ha il maggior numero di componenti, motivo per cui i siti faticano più con essa che con INP o CLS. Fonte
• Il mobile è più difficile del desktop. CPU e connessioni più lente aumentano l’LCP, e su connessioni 3G/lente la soglia di 2,5 s è quasi impossibile da raggiungere. Fonte
• Il tempo di download dell’immagine è spesso la parte più piccola dell’LCP. L’analisi di Chrome sui dati di HTTP Archive ha rilevato che la durata del download spesso non è il collo di bottiglia — di solito lo sono TTFB e il ritardo di scoperta. Fonte
• La copertura di CrUX è scarsa. Nel nostro studio su 42 milioni di pagine, solo circa l’11,4 % aveva dati di campo CrUX associati — la maggior parte delle pagine non riceve abbastanza traffico reale per essere misurata. Fonte
• Il 62 % delle pagine mobile rispetto al 74 % delle pagine desktop raggiunge un LCP buono (Web Almanac 2025). Il divario mobile riflette CPU e connessioni di rete più lente. Fonte
• Solo il 2,1 % delle pagine mobile pre-carica la propria immagine LCP, nonostante il 76 % abbia un’immagine come elemento LCP — un’opportunità di ottimizzazione significativa mancata (Web Almanac 2025). Fonte
• L’adozione di fetchpriority="high" è cresciuta dallo 0,03 % dei siti mobile nel 2022 al 17,3 % nel 2025, in gran parte grazie all’aggiunta da parte del core di WordPress (Web Almanac 2025). Google Flights ha visto un miglioramento dell’LCP di 700 ms grazie a questo singolo attributo. Fonte

Video

• Google Search Central (YouTube) — i video esplicativi su Core Web Vitals ed esperienza di pagina, incluse le guide del team Chrome all’ottimizzazione dell’LCP. Canale

Cronologia modifiche