# LCP: le cinque cause peggiori

LCP è il tempo dell'elemento più grande visibile: buono sotto 2,5 s. Le cinque cause che lo peggiorano di più, nell'ordine in cui conviene correggerle.

> Pagina: https://ui.eneawork.it/blog/lcp-cosa-lo-peggiora
> Markdown: https://ui.eneawork.it/blog/lcp-cosa-lo-peggiora.md

*2026-11-01*

LCP è il tempo in cui compare l'elemento più grande della prima viewport: sotto 2,5 s è buono. Le cinque cause che lo peggiorano di più sono TTFB alto, immagine hero senza priorità, CSS che blocca il render, font che nasconde il testo e markup costruito dal client.

Il beacon del sito ha registrato 219 letture LCP tra il 25 ottobre e il 1 novembre 2026: p75 1.672,7 ms, con 28 letture sopra i 2,5 s. Le 262 letture TTFB hanno p75 509,8 ms e 46 sopra gli 800 ms, quindi parte del ritardo non è nell'immagine. Numeri misurati sul registro locale del beacon e riletti da GET /api/rum/summary. Il catalogo EneUI misura 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, letti da /api/stats il 1 novembre 2026. Soglie: web.dev, CC BY 4.0.

## Le cinque cause, dalla più frequente

L'ordine conta: con un TTFB sopra 800 ms ottimizzare l'immagine non sposta nulla, perché il browser non sa ancora che l'immagine esiste. Nel nostro registro il TTFB p75 è 509,8 ms su 262 letture, quindi la prima correzione riguarda il documento.

## Trovare l'elemento che conta

new PerformanceObserver((list) => { const entries = list.getEntries(); const last = entries[entries.length - 1]; console.log(Math.round(last.startTime), last.element, last.url); }).observe({ type: "largest-contentful-paint", buffered: true });

L'ultima entry è quella che vale: LCP cambia ogni volta che un elemento più grande entra nella viewport. Se element è vuoto il candidato è un'immagine di sfondo, che il browser non nomina, e va cercato a mano nel pannello Performance.

## Il comando che rifà la misura

npx lighthouse https://example.com --preset=desktop --only-categories=performance --output=json --output-path=./lcp.json

Lighthouse misura un solo run con throttling simulato: serve a confrontare due build, non a decidere se la pagina passa. Il verdetto resta quello del campo, in /api/rum/summary o nel Chrome UX Report.

## La limitazione da dichiarare

Il nostro campione è il registro locale del beacon: un solo sito, con sessioni automatiche dentro. Un p75 di 1.672,7 ms qui non dice nulla sul sito del lettore, e la soglia vera si legge solo dal Chrome UX Report al 75° percentile, separato per mobile e desktop.

## Dove continuare

Nel catalogo: componenti hero, image stream hero e blocchi hero. Le guide: srcset e sizes e cosa sono i Core Web Vitals; l'articolo gemello su CLS e il confronto Next.js o Vite.

## FAQ

### LCP misura il caricamento completo della pagina?

No. Misura quando compare l'elemento più grande della prima viewport, che di solito è un'immagine hero o un titolo. Il resto della pagina può caricare dopo.

### Qual è la soglia di LCP?

2,5 s al 75° percentile delle visite, separate per mobile e desktop. Sopra 4 s la pagina è da correggere.

### Perché il preload dell'immagine hero aiuta?

Perché il browser scopre il file prima di aver letto il CSS e il JavaScript che lo nascondono. Con fetchpriority=high l'immagine sale nella coda delle richieste.

### Il TTFB fa parte di LCP?

Sì. LCP parte dalla navigazione, quindi ogni millisecondo di TTFB si somma. Con un TTFB di 800 ms metà del budget di 2,5 s è già speso.

### Posso misurare LCP senza dati di campo?

Solo in laboratorio, con Lighthouse o WebPageTest. Il laboratorio spiega la causa ma non dice se gli utenti reali passano: per quello serve il Chrome UX Report.