LCP: come ottimizzare il Largest Contentful Paint

Il Largest Contentful Paint (LCP) è la metrica dei Core Web Vitals che influisce sul posizionamento Google dal 2021. Non è solo un numero tecnico — riflette la velocità con cui gli utenti percepiscono una pagina come caricata. Un LCP scadente significa che i visitatori vedono uno schermo vuoto o un'immagine hero non caricata e lasciano la pagina prima che compaia il contenuto.

zoom_in

Cos'è l'LCP e perché conta

L'LCP misura il tempo dall'inizio della navigazione al momento in cui l'elemento di contenuto più grande (testo o immagine) diventa visibile nella viewport. È la soglia che Google usa per considerare il caricamento «completato» dal punto di vista dell'esperienza utente.

A differenza dell'FCP (First Contentful Paint), che scatta al primo pixel, l'LCP traccia specificamente i contenuti significativi. Una pagina può mostrare uno spinner a 0,3 s, ma se l'immagine hero compare a 5 s — l'LCP è 5 s.

Quali elementi il browser considera candidati LCP

Il browser non traccia ogni elemento — osserva tipi specifici e seleziona il più grande per area dentro la viewport al momento del completamento del caricamento.

Elementi <img>

Immagini standard. Il candidato LCP più comune sulla maggior parte delle pagine. Tempo = momento in cui l'immagine decodificata compare nella viewport.

<image> dentro SVG

Immagini dentro elementi SVG. Trattate come le normali img ai fini dell'LCP.

CSS background-image

Immagini di sfondo via CSS. Nessola chiave: il browser non inizia a caricare una background-image finché non è costruito il CSSOM. È una delle fonti principali di ritardo LCP.

Blocchi di testo

<p>, <h1>–<h6>, <div> e altri elementi con contenuto testuale. Se un blocco di testo è più grande di qualsiasi immagine, diventa l'LCP.

<video> con poster

Il fotogramma poster di un elemento video (attributo poster). Se un video occupa la maggior parte dello schermo, il poster deve caricarsi il più in fretta possibile.

Come si scompone il tempo LCP

Google decompone l'LCP in 4 sotto-componenti. Capirli è la chiave per diagnosticare e prioritizzare correttamente le ottimizzazioni.

Regola: attacca il componente con la quota maggiore. Se il TTFB assorbe 3 dei 5 secondi di LCP — ottimizzare le immagini avrà impatto minimo. Correggi prima il tempo di risposta del server.

Cause principali di un LCP lento

Il 90% degli LCP scadenti condivide le stesse cause radice. La diagnosi richiede 15 minuti in DevTools o PageSpeed Insights.

Come ottimizzare l'LCP: piano passo per passo

L'ottimizzazione dell'LCP non è un trucco singolo — è un insieme di miglioramenti interconnessi. Lavora in sequenza, partendo dagli interventi a maggior impatto.

Passo 1: riduci il TTFB a 200–400 ms

Il TTFB è il fondamento. Se il server è lento, tutte le altre ottimizzazioni lavorano contro quel tetto.

1. Configura la cache HTTP: Cache-Control: max-age=31536000 per gli asset statici, s-maxage per i proxy CDN.
2. Abilita la compressione: Brotli (preferito) o gzip per HTML, CSS, JS. Brotli produce file più piccoli del 15–25% rispetto a gzip.
3. Collega una CDN: Cloudflare, Fastly, BunnyCDN. Per i siti statici, l'edge caching riduce il TTFB a 20–50 ms.
4. Ottimizza il database: indici sui campi interrogati di frequente, cache delle query via Redis o Memcached.
5. Usa HTTP/2 o HTTP/3: richieste multiple su una singola connessione senza head-of-line blocking.

Passo 2: ottimizza l'immagine LCP

Se l'elemento LCP è un'immagine (hero, immagine prodotto), questo è un albero di ottimizzazione ad alto ROI.

• Converti nei formati moderni: WebP (25–35% di risparmio vs JPEG) o AVIF (40–55% vs JPEG). Usa <picture> con fallback.
• Aggiungi fetchpriority="high" all'immagine LCP — il browser la caricherà con priorità massima.
• Rimuovi loading="lazy" dall'elemento LCP. Il lazy load è appropriato solo per le immagini sotto la prima viewport.
• Aggiungi <link rel="preload" as="image"> in <head> per l'immagine LCP — il browser inizia a caricarla prima del parsing del body.
• Specifica gli attributi width e height per prevenire il CLS. Il browser riserva lo spazio prima del caricamento.
• Configura srcset e sizes per il caricamento responsive: il mobile riceve un'immagine da 400 px invece che da 1600 px.

Passo 3: elimina le risorse render-blocking

Ogni risorsa render-blocking aggiunge ritardo all'LCP. Obiettivo: zero risorse bloccanti nel critical path.

Passo 4: ottimizza i font (quando l'LCP è testo)

Quando l'elemento LCP è un blocco di testo (titolo, lead), il problema è spesso il ritardo di rendering del font.

1. Aggiungi font-display: swap o optional a @font-face. Il browser mostra subito il font di sistema e sostituisce quello custom dopo il caricamento.
2. Usa <link rel="preload" as="font" type="font/woff2" crossorigin> per i font critici in <head>.
3. Limita il set di caratteri: usa il subsetting per caricare solo i glifi necessari (latino, cirillico).
4. Self-hosta i font invece di caricarli da Google Fonts — elimina un DNS lookup e una connessione in più.
5. Configura size-adjust, ascent-override, descent-override in @font-face per ridurre il CLS durante lo swap del font.

Passo 5: SSR/SSG per i framework JavaScript

Se il sito gira su React, Vue o Next.js senza SSR — l'LCP sarà alto per impostazione predefinita: il browser deve scaricare, eseguire JavaScript e solo dopo renderizzare il contenuto.

Server-Side Rendering (SSR)

L'HTML viene generato sul server a ogni richiesta. Il browser riceve HTML pronto, lo parsa e l'elemento LCP compare senza aspettare il JS. Opzione migliore per i contenuti dinamici.

Static Site Generation (SSG)

L'HTML viene generato alla build. Il server consegna un file pronto — massima velocità di TTFB e LCP. Ideale per blog, landing page e pagine non personalizzate.

Incremental Static Regeneration (ISR)

SSG con rigenerazione periodica (Next.js). Combina la velocità dei file statici con la freschezza dei dati. Ottimale per la maggior parte dei contenuti CMS.

Streaming SSR

Il server inizia a inviare HTML prima del completamento del rendering — il browser mostra i contenuti progressivamente. React 18 + Next.js 13+ lo supportano out of the box.

Passo 6: CSS background-image come LCP

Se l'elemento LCP usa una CSS background-image, il browser non può iniziare a caricarla finché non è costruito il CSSOM. È una delle cause più insidiose di LCP lento.

• Sostituisci la CSS background-image con <img fetchpriority="high"> — il browser la scopre durante il parsing HTML.
• Se la sostituzione non è possibile — usa <link rel="preload" as="image"> per avviare manualmente il caricamento.
• Per gli sfondi responsive usa imagesrcset e imagesizes nel tag preload.
• Sposta il CSS che contiene la background-image LCP in uno <style> inline — elimina una richiesta di rete.

Strumenti per misurare e diagnosticare l'LCP

La diagnosi corretta conta più dell'ottimizzazione alla cieca. Usa entrambi i tipi di strumenti: Lab (test sintetici) e Field (utenti reali).

Come diagnosticare l'LCP in Chrome DevTools

DevTools è lo strumento più preciso per capire esattamente cosa rallenta l'LCP su una pagina specifica.

1. Apri DevTools → Performance → premi Record, ricarica la pagina, ferma la registrazione.
2. In Timings trova il marker LCP — mostra il tempo esatto e l'elemento.
3. Studia il waterfall: trova la risorsa dell'elemento LCP e controlla quando è iniziato il caricamento rispetto al TTFB.
4. Cerca le barre rosse — sono le risorse render-blocking. Compaiono subito prima dell'LCP.
5. Scheda Network → filtra per tipo Immagine — trova l'immagine LCP e controlla la sua priorità (deve essere High).
6. Scheda Coverage — mostra CSS/JS inutilizzati. Grandi quantità di codice inutilizzato = ritardo LCP.

FAQ