Performance
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.
In sintesi
- LCP misura quando compare l'elemento più grande della prima viewport.
- Se il TTFB supera gli 800 ms, ottimizzare l'immagine non sposta la metrica.
- L'endpoint di campo dice se la pagina passa, Lighthouse dice perché.
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.
Le cinque cause, dalla più frequente
| Causa | Segnale in laboratorio | Correzione |
|---|---|---|
| TTFB alto | Il documento arriva dopo 800 ms | Cache HTML e server più vicino |
| Hero senza priorità | Immagine LCP con priorità bassa | fetchpriority=high e preload |
| CSS che blocca | Foglio di stile prima del primo paint | CSS critico inline, il resto differito |
| Font che nasconde | Testo invisibile durante lo swap | font-display swap e fallback simile |
| Contenuto lato client | LCP scoperto dopo l'idratazione | Markup dell'hero reso dal server |
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.jsonLighthouse 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.
Domande frequenti
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.