Cos’è l’LCP e come funziona

LCP in sintesi

• Cosa misura: il tempo di rendering dell’elemento visibile più grande nella parte di pagina che si vede senza scorrere.
• Elementi candidati: immagini, video con poster, sfondi impostati con url(), blocchi di testo a livello di blocco.
• Soglie: buono entro 2,5 secondi, da migliorare fino a 4, scarso oltre 4, calcolati al 75° percentile delle visite.
• Perché conta: incide sulla percezione di affidabilità del sito e rientra nei segnali di Page Experience usati nel posizionamento.
• Cause frequenti del ritardo: server lento, CSS o JavaScript bloccanti, immagini pesanti, lazy loading sull’elemento sbagliato.
• Dove si verifica: Google Search Console, PageSpeed Insights, Chrome DevTools.

Cosa misura l’LCP e quali elementi considera

L’LCP registra il tempo che passa dalla richiesta della pagina al momento in cui il browser disegna a schermo l’elemento con la superficie più grande dentro l’area visibile. Nella maggior parte dei siti quell’elemento è un’immagine hero o un blocco di testo consistente; più raramente è un video, misurato sul fotogramma del poster. Il concetto è diverso da come funziona l’FCP, che registra solo il primo contenuto qualsiasi, non quello principale.

Il browser considera candidati solo alcuni tipi di nodo: elementi <img>, immagini dentro un <svg>, video con poster, elementi con sfondo impostato tramite url() e blocchi di testo a livello di blocco. Una sfumatura CSS al posto di un’immagine di sfondo non entra nel calcolo, e nemmeno un contenitore vuoto usato solo per il layout.

Dentro questo insieme, i browser basati su Chromium escludono gli elementi che un utente non considererebbe contenuto reale: un elemento con opacità pari a zero, uno sfondo che copre l’intera pagina, un’immagine segnaposto a bassa entropia visiva. La dimensione registrata è quella visibile nell’area visibile, non quella intrinseca del file: un’immagine tagliata dall’overflow conta solo per la parte che resta a schermo, senza margini, padding o bordi applicati via CSS.

Il valore non si fissa al primo elemento disegnato. Il browser invia una misurazione ogni volta che un elemento più grande prende il posto del precedente, finché l’utente non interagisce con la pagina con un tocco, uno scroll o la pressione di un tasto: da quel momento la misurazione si ferma. È il motivo per cui una pagina che carica prima un titolo e poi un’immagine hero più grande registra due misurazioni, e solo l’ultima conta come LCP finale. Lavorare su questo valore fa parte del lavoro più ampio di ottimizzazione dei Core Web Vitals di un sito.

Soglie di valutazione dell’LCP

Un LCP è buono quando resta entro 2,5 secondi, da migliorare tra 2,5 e 4 secondi, scarso oltre i 4 secondi. Queste soglie restano identiche anche nelle guide di settore più recenti che ho controllato, aggiornate a fine 2026.

Conta il 75° percentile delle visite reali, non la media dei caricamenti: Google ordina i tempi registrati dal più basso al più alto e guarda il punto sotto cui si trova il 75% delle visite, calcolato separatamente per mobile e per desktop. Una pagina passa la soglia solo se tre visite su quattro restano entro i 2,5 secondi, comprese quelle con una connessione scarsa o un telefono datato.

Perché su mobile il punteggio è quasi sempre più basso

Su smartphone la CPU elabora lo stesso CSS e lo stesso JavaScript con meno potenza, e la connessione è più instabile di una rete fissa. Lighthouse, lo strumento di laboratorio che gira dentro PageSpeed Insights e Chrome DevTools, simula di proposito una connessione 4G rallentata e un dispositivo di fascia media: il punteggio più severo riflette l’utente reale meglio di un computer collegato in fibra.

Perché l’LCP conta per UX e SEO

Un LCP veloce comunica all’utente che la pagina si sta caricando e che contiene qualcosa di utile, prima ancora che il resto della pagina sia pronto: le pagine con LCP alto perdono visitatori già nei primi secondi, con un effetto diretto sulla frequenza di rimbalzo. In una guida di marketing che ho consultato, a un LCP scarso viene collegato anche un calo del tasso di conversione, oltre che del traffico organico.

LCP è una delle tre metriche che compongono il funzionamento dei Core Web Vitals, insieme a INP per la reattività e CLS per la stabilità del layout. Questi tre segnali rientrano nei criteri di Page Experience usati dai sistemi di posizionamento di Google, come fattore di rinforzo a parità di pertinenza dei contenuti. Il lato più tecnico di questi segnali appartiene al controllo tecnico del sito, non a questa pagina.

Nel mio lavoro tratto l’LCP come un indicatore di affidabilità percepita prima che come un fattore di ranking: un sito che carica in fretta trattiene il visitatore abbastanza a lungo da fargli leggere la pagina, e solo dopo arriva l’eventuale beneficio in SERP.

Le quattro fasi che compongono l’LCP

Scomporre l’LCP in quattro fasi è il modo più preciso per capire dove intervenire, perché una correzione su una fase che pesa poco non sposta il risultato finale.

Se il TTFB da solo occupa due secondi, comprimere l’immagine hero porta un guadagno marginale: il problema è a monte, nel server. Se invece il ritardo è nel resource load delay, il file magari è leggero ma il browser lo scopre troppo tardi, in genere perché è referenziato solo da un foglio di stile o da uno script invece che nell’HTML iniziale.

Cause comuni di un LCP lento

Dietro un LCP sopra i 4 secondi c’è quasi sempre una di queste cinque cause, spesso in combinazione.

Tempo di risposta del server alto

Un TTFB alto nasce da query al database non ottimizzate, da un’infrastruttura di backend sottodimensionata o da troppi reindirizzamenti prima di arrivare alla pagina finale: finché il server non risponde, nessuna ottimizzazione lato immagine ha effetto.

Risorse bloccanti il rendering

CSS e JavaScript caricati nell’intestazione della pagina costringono il browser ad attendere il download e l’elaborazione di quei file prima di disegnare qualunque cosa: più framework e plugin sono impilati nell’head, più l’elemento principale resta invisibile.

Immagini pesanti o non ottimizzate

Un file da uno o due megabyte servito alla stessa risoluzione sia su un monitor che su un telefono allunga la fase di download della risorsa. Formati datati come JPG o PNG non compressi aggravano il problema, insieme alla mancanza di attributi di larghezza e altezza che permettano al browser di riservare lo spazio in anticipo.

Lazy loading applicato all’elemento sbagliato

Il caricamento ritardato serve per le immagini sotto la piega, quelle che l’utente raggiunge solo scorrendo. Applicato per errore all’elemento che compare nel primo schermo, rimanda il download proprio della risorsa che andrebbe caricata per prima: è uno degli errori più costosi perché sembra un’ottimizzazione e produce l’effetto opposto.

Se il sito si affida al rendering lato client

Se la pagina costruisce il contenuto principale con JavaScript dopo il caricamento iniziale dell’HTML, invece di riceverlo già pronto nel markup, il browser deve prima scaricare ed eseguire lo script prima di poter disegnare l’elemento LCP. In questo caso conviene verificare, con gli strumenti per sviluppatori del browser, quanto contenuto arriva già nell’HTML e quanto dipende da uno script eseguito dopo.

Come ottimizzare l’LCP

L’ordine giusto è lavorare sulla fase che pesa di più nel caso specifico, non applicare tutta la lista alla cieca.

1. Verifica il tempo di risposta del server: una cache lato server ben configurata e una CDN che serve i file statici da un nodo vicino all’utente riducono il TTFB prima di qualunque altro intervento.
2. Dai priorità alla risorsa LCP: l’attributo fetchpriority="high" sull’immagine principale, oppure un <link rel="preload"> nell’head se la risorsa è referenziata solo da CSS o JavaScript esterno, anticipano la scoperta del file da parte del browser. Funziona solo se resta un’eccezione: assegnarla a più di una o due risorse equivale a non assegnarla a nessuna.
3. Riduci il peso dei file: converti le immagini in WebP o AVIF, servi versioni diverse per dispositivi diversi con srcset e sizes invece di ridimensionare via CSS un file unico e pesante.
4. Rimuovi i blocchi al rendering: minifica CSS e JavaScript, rinvia con defer o async gli script non necessari al primo disegno della pagina, incolla in linea solo il CSS critico per il primo schermo.
5. Controlla i web font: un font personalizzato non ancora caricato può ritardare il testo che fa parte dell’elemento LCP; font-display: swap evita che il testo resti invisibile in attesa del file.

La correzione giusta dipende da quale delle quattro fasi risulta fuori scala per quella pagina.

Come misurare l’LCP

La misura che conta è quella sugli utenti reali, non quella di un singolo test in laboratorio: i due tipi di dato rispondono a domande diverse e vanno letti insieme.

Se Lighthouse e i dati di campo non sono d’accordo, prevale il dato di campo: riflette l’esperienza reale, mentre Lighthouse simula una condizione di rete e un dispositivo fissati a priori. Uno strumento come PageSpeed Insights combina entrambi i tipi di dato nella stessa schermata, con i dati di campo in alto e la diagnostica di laboratorio più in basso; ho spiegato funzionamento di PageSpeed Insights in un articolo a parte.

In Google Search Console, il report Core Web Vitals raggruppa le pagine del dominio per stato (scarso, da migliorare, buono) e per metrica, LCP compreso, usando i dati di campo aggregati nel tempo: utile per capire se un problema riguarda una pagina sola o un intero template. Chrome DevTools, nel pannello Performance, mostra invece l’elemento LCP locale accanto al dato di campo della stessa pagina, con la suddivisione nelle quattro fasi.

Errori frequenti quando si lavora sull’LCP

Alcuni errori ricorrono più di altri quando chi gestisce il sito prova a correggere l’LCP da solo, prima ancora di chiamare qualcuno.

• Assegnare priorità alta a troppe immagini insieme: il browser non riesce più a distinguere quale caricare per prima, e l’effetto utile sparisce.
• Guardare solo il punteggio di Lighthouse e ignorare i dati di campo: un sito può avere un buon voto in laboratorio e un LCP scarso per gli utenti reali con connessioni più lente.
• Correggere le immagini quando il collo di bottiglia è il server: se il TTFB occupa già due secondi, ogni intervento sul resto produce un guadagno minimo.
• Applicare lo stesso plugin di ottimizzazione immagini a tutte le pagine senza controllare l’elemento LCP specifico di ciascuna: non tutte le pagine di un sito caricano lo stesso elemento come più grande.

Capita spesso che l’errore più costoso sia proprio il primo della lista: si imposta fetchpriority="high" su ogni immagine del carosello in testata, convinti che più priorità corrisponda a più velocità, e si ottiene l’effetto contrario.

Domande frequenti sull’LCP

Qual è un buon valore di LCP?

Un buon valore di LCP resta entro 2,5 secondi, calcolato sul 75° percentile delle visite reali e misurato separatamente per mobile e desktop. Tra 2,5 e 4 secondi la pagina è da migliorare, oltre i 4 secondi è considerata scarsa secondo le soglie che Google applica ai Core Web Vitals.

L’LCP influisce sul posizionamento?

Sì: fa parte dei segnali di Page Experience che i sistemi di ranking di Google usano insieme alla pertinenza dei contenuti. Pesa come fattore di rinforzo, a parità degli altri elementi della pagina.

Perché su mobile il punteggio LCP è spesso peggiore?

Perché la CPU degli smartphone elabora lo stesso CSS e lo stesso JavaScript con meno potenza, e la connessione è più instabile di una rete fissa. Lighthouse, inoltre, simula di proposito una rete 4G rallentata e un dispositivo di fascia media.

Cosa succede se l’elemento LCP cambia durante il caricamento?

Il browser registra una nuova misurazione ogni volta che un elemento più grande prende il posto del precedente, finché l’utente non interagisce con la pagina con un tocco, uno scroll o un tasto. Solo l’ultima misurazione prima dell’interazione conta come LCP finale.

Il lazy loading va applicato all’immagine LCP?

No, l’elemento che compare nel primo schermo va caricato subito, non in differita: il lazy loading serve per le immagini sotto la piega, raggiunte solo scorrendo la pagina. Applicarlo all’elemento LCP ne ritarda il download invece di anticiparlo.

Meglio Lighthouse o Search Console per misurare l’LCP?

Servono a domande diverse: Lighthouse, in laboratorio, aiuta a capire quale elemento e quale fase causano il rallentamento. Search Console mostra lo stato aggregato delle pagine del dominio nel tempo, con dati di campo reali. Si usano insieme.