Correggi e identifica i problemi del Largest Contentful Paint (LCP)

Questa guida fa parte dell'hub sul Largest Contentful Paint (LCP). Il LCP misura la velocità di rendering dell'elemento visibile più grande. Google lo vuole sotto i 2,5 secondi. Quello che segue è l'esatto processo diagnostico che uso nelle consulenze sulla velocità della pagina.

La guida di un consulente per diagnosticare e correggere il LCP

Mi chiamo Arjen Karel e sono un consulente per la velocità della pagina. Negli anni ho analizzato centinaia di siti web e una delle sfide più persistenti è il Largest Contentful Paint (LCP). In questa guida condividerò la metodologia esatta che uso per diagnosticare e risolvere i problemi di LCP. Vedrai menzionare CoreDash, uno strumento RUM che ho creato per ottenere i dati precisi necessari per questo processo. I principi qui sono universali, ma credo nel mostrare esempi reali degli strumenti che creo e uso quotidianamente.

Migliorare il LCP è un processo di eliminazione. Secondo il Web Almanac 2025, solo il 66% delle origini mobile supera il LCP. Significa che un terzo del web ha un problema di caricamento. Trova la fase più lenta, correggila, misura di nuovo.

La metodologia diagnostica: prima i field data, poi i lab data

Per ottimizzare in modo efficace, devi adottare un flusso di lavoro diagnostico in due fasi. Questo assicura che tu stia risolvendo problemi che i tuoi utenti affrontano realmente, non solo inseguendo punteggi in un ambiente di laboratorio.

1. I field data (RUM e CrUX) ti mostrano COSA sta succedendo. I field data vengono raccolti da utenti reali che visitano il tuo sito. Ti dicono se hai un problema di LCP, quali pagine sono interessate e quali utenti (mobile o desktop) lo riscontrano. Devi sempre partire da qui per confermare che esiste un problema reale.
2. I lab data (Lighthouse, DevTools) ti aiutano a diagnosticare PERCHÉ sta succedendo. I lab data vengono raccolti in un ambiente controllato e simulato. Una volta che i tuoi field data hanno confermato un problema su una pagina specifica, puoi usare strumenti di laboratorio per replicare costantemente il problema e sezionare il processo di caricamento per trovare la causa principale.

Inizia con i field data in modo che i tuoi sforzi di ottimizzazione mirino a cambiamenti che hanno un impatto reale sugli utenti.

Passaggio 1: Identifica i problemi di LCP con i field data

Il tuo primo compito è usare i dati degli utenti reali per confermare quali pagine, se presenti, hanno un LCP scadente.

Un punto di partenza accessibile: Google Search Console

Un punto valido da cui partire è il report sui Core Web Vitals in Google Search Console. Accedi, naviga fino al report e analizza i grafici per mobile e desktop. Se Google segnala URL con "Problema LCP: superiore a 2,5 s", hai la conferma dal Chrome User Experience Report (CrUX) che una percentuale dei tuoi utenti sta avendo un'esperienza scadente.

Search Console conferma il problema, ma si aggiorna lentamente e raggruppa gli URL. Per avere dettagli a livello di pagina in tempo reale, ti serve uno strumento RUM.

Real User Monitoring (RUM): Dettagli a livello di pagina

Puoi costruire la tua configurazione RUM usando la libreria web-vitals per inviare i dati al tuo backend di analisi, ma è uno sforzo ingegneristico notevole.

Ho creato CoreDash appositamente per questo. Aggiungi un tag script e inizia a raccogliere i dati del LCP da ogni visitatore reale, suddivisi per pagina, dispositivo e elemento.

Un buon strumento RUM ti permette di vedere:

• Il tuo punteggio LCP preciso per qualsiasi URL specifico.
• Una scomposizione di ogni elemento LCP (es. un'immagine, un titolo) e quali sono associati più frequentemente a un LCP lento.
• Le tempistiche esatte per ciascuna delle quattro fasi del LCP per ogni visualizzazione di pagina, individuando il collo di bottiglia.

Guardare oltre l'elemento LCP in sé è importante. In un caso di studio ben documentato, Vodafone ha migliorato il proprio LCP del 31%, il che ha contribuito direttamente a un aumento dell'8% delle vendite. La loro ottimizzazione si è concentrata sull'identificazione e la risoluzione del collo di bottiglia specifico del LCP sulle landing page chiave, usando una combinazione di analisi dei field data e correzioni mirate. L'ottimizzazione del LCP non riguarda solo l'immagine. Devi capire l'intera pipeline di caricamento: risposta del server, scoperta delle risorse, download e paint.

Ad esempio, in CoreDash, puoi navigare alla pagina del LCP e visualizzare una tabella dati che mostra i tuoi elementi LCP più lenti. Cliccando su un elemento specifico (come una particolare classe CSS per una hero image), puoi filtrare tutte le metriche per vedere i dati sulle prestazioni solo per le pagine in cui quell'elemento era il LCP.

L'obiettivo: usa i field data per trovare la tua pagina più lenta e il suo elemento LCP più comune. Quello è il tuo bersaglio.

Misurare il LCP con l'API Performance Observer

L'API Performance Observer ti dà accesso diretto alle voci del LCP in JavaScript. Questa è la stessa API che gli strumenti RUM usano dietro le quinte per raccogliere i field data. Il seguente snippet registra ogni candidato LCP identificato dal browser, inclusi l'elemento, le sue dimensioni e il tempo di render.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Questo è utile per una rapida convalida durante lo sviluppo, ma per la misurazione in produzione dovresti usare la libreria web-vitals, che gestisce casi limite come i cambiamenti di visibilità della scheda e i ripristini della cache back/forward.

Passaggio 2: Diagnostica il collo di bottiglia con gli strumenti di laboratorio

Sai quale pagina correggere. Ora scopri perché è lenta. Esegui un test con PageSpeed Insights o il pannello Lighthouse nei Chrome DevTools.

Nel report, scorri verso il basso fino alla sezione "Diagnostica" e trova l'audit "Elemento Largest Contentful Paint". Questo grafico a cascata suddivide il tuo tempo di LCP nelle sue quattro sottoparti. Il tuo strumento RUM dovrebbe mostrare una suddivisione simile basata sui tuoi field data.

Il tuo obiettivo è trovare la fase più lunga in questa suddivisione. Quello è il tuo collo di bottiglia principale ed è lì che dovresti concentrare per prima cosa i tuoi sforzi di ottimizzazione.

Guida passo passo: preferisci lavorare nei DevTools? Diagnosticare il LCP con il pannello Prestazioni dei Chrome DevTools mostra come registrare una traccia limitata e leggere le stesse quattro sottoparti dall'insight di suddivisione del LCP.

Passaggio 3: Comprendere le quattro fasi del LCP

Ogni punteggio LCP è la somma di quattro fasi sequenziali. Ogni fase ha una guida dedicata su questo sito che copre tecniche di ottimizzazione specifiche.

• Time to First Byte (TTFB): Questa è la base inevitabile. Una risposta lenta del server è un'aggiunta diretta, millisecondo per millisecondo, al tuo LCP. Prima di ottimizzare una singola immagine, devi assicurarti che il tuo server risponda rapidamente. Scopri di più sull'ottimizzazione del TTFB.
• Ritardo di caricamento della risorsa: Questo è il "problema di scoperta" e uno dei problemi più comuni. Il browser non può scaricare una risorsa che non conosce. Se la tua immagine LCP è nascosta in un file CSS o JavaScript, o anche se è nell'HTML ma vengono prima richieste altre risorse, il browser la trova troppo tardi, sprecando tempo prezioso. Leggi la guida completa sul ritardo di caricamento della risorsa.
• Durata di caricamento della risorsa: Questo è il tempo di download per la risorsa LCP in sé. Immagini grandi e non compresse o condizioni di rete lente possono rendere questa fase un collo di bottiglia. Leggi la guida completa sulla durata di caricamento della risorsa.
• Ritardo di render dell'elemento: Questo è il problema "troppo occupato per il paint". Il file dell'immagine LCP potrebbe essere completamente scaricato, ma se il main thread del browser è bloccato dall'esecuzione pesante di JavaScript, semplicemente non riesce a dipingere l'immagine sullo schermo. Leggi la guida completa sul ritardo di render dell'elemento.

Inizia sempre assicurandoti che il tuo TTFB sia veloce e che la tua risorsa LCP sia rintracciabile prima di passare alle dimensioni dei file e alle ottimizzazioni del render.

Passaggio 4: Esegui la correzione

Con il collo di bottiglia identificato, applica la correzione. L'implementazione dipende dal tuo stack. Ogni fase qui sotto copre prima i principi universali, poi i dettagli specifici per WordPress e i framework JS.

1. Ottimizzare il Time to First Byte (TTFB)

Se il tuo TTFB è lento (un buon obiettivo è sotto gli 800 ms), stabilisce una soglia alta per il tuo LCP. Migliorare il TTFB migliorerà ogni altra metrica di caricamento.

Soluzioni universali per il TTFB

• Abilita la cache: Questo è uno dei modi più efficaci per migliorare il TTFB. La cache genera e archivia una copia della pagina in modo che possa essere servita istantaneamente senza aspettare che il server la costruisca da zero a ogni visita.
• Usa una CDN: Una Content Delivery Network serve i tuoi contenuti da un server fisicamente vicino al tuo utente, il che riduce la latenza di rete. Mettere in cache le tue intere pagine HTML all'edge della CDN è una potente strategia per un TTFB globale veloce. Per suggerimenti dettagliati sulla configurazione della CDN, vedi la nostra guida su come configurare Cloudflare per prestazioni ottimali.
• Usa la compressione Brotli o Gzip: Assicurati che il tuo server stia comprimendo le risorse basate su testo come HTML, CSS e JavaScript. Brotli offre una compressione migliore rispetto a Gzip e dovrebbe essere preferito.
• Usa HTTP/3 con 0-RTT: Assicurati che il tuo server sia configurato per usare HTTP/3. Offre notevoli vantaggi in termini di prestazioni, incluso un migliore multiplexing. Supporta 0-RTT (Zero Round Trip Time Resumption), che elimina il tempo di configurazione della connessione per i visitatori abituali, fornendo un boost istantaneo al TTFB.
• Usa le 103 Early Hints: Per un boost avanzato, usa il codice di stato 103 Early Hints. Questo permette al tuo server o CDN di inviare indizi sui file CSS e JS critici al browser mentre sta ancora preparando il documento HTML completo, consentendo ai download di iniziare ancora prima. Per una guida all'implementazione completa, vedi il nostro articolo sulle 103 Early Hints.

Correzioni del TTFB specifiche per piattaforma

Su WordPress:

• Investi in un hosting di qualità: Su WordPress, un TTFB lento è spesso correlato all'ambiente di hosting. Un hosting condiviso ed economico può essere un collo di bottiglia. Prendi in considerazione un host WordPress gestito che sia ottimizzato per le prestazioni.
• Usa un plugin di cache: Un plugin di cache di alta qualità (es. WP Rocket, W3 Total Cache) non è negoziabile. Gestisce la generazione di file HTML statici per te, che è il fulcro di una cache efficace su questa piattaforma.

Su un framework JS:

• Scegli la piattaforma di hosting giusta: Per le applicazioni Node.js, piattaforme come Vercel o Netlify sono altamente ottimizzate per i framework SSR/SSG e offrono cache intelligente ed esecuzione di funzioni serverless out of the box.
• Implementa la cache SSR: Se stai usando il Server-Side Rendering, metti in cache le pagine renderizzate sul server (es. usando Redis o una cache in-memory) per evitare di renderizzarle di nuovo a ogni richiesta.
• Fai attenzione ai cold start serverless: Se usi funzioni serverless per il rendering, tieni presente che un "cold start" (la prima richiesta dopo un periodo di inattività) può avere un TTFB alto. Usa la concurrency provisionata o strategie di keep-alive per mitigarlo.

2. Ridurre il ritardo di caricamento della risorsa

Questo è spesso il collo di bottiglia più grande. Significa che il browser era pronto a lavorare, ma non è riuscito a trovare subito la tua immagine principale o il file del font. Questo ritardo è tipicamente causato da uno di due problemi: la risorsa viene scoperta tardi, oppure le viene assegnata una bassa priorità di download. Per la guida completa su questo argomento, leggi la nostra guida dedicata sul ritardo di caricamento della risorsa.

Soluzioni universali per il ritardo di caricamento

La soluzione universale al ritardo di caricamento della risorsa è assicurarti che la tua risorsa LCP sia rintracciabile nel markup HTML iniziale e che le venga assegnata un'alta priorità dal browser. Ecco come ottenerlo:

• Rendi la risorsa LCP rintracciabile: Il passaggio più importante è assicurarti che il tuo elemento LCP sia presente nell'HTML inviato dal server. I browser usano un "preload scanner" ad alta velocità per guardare avanti nell'HTML grezzo alla ricerca di risorse come immagini e script da scaricare. Se la tua immagine LCP viene caricata tramite una background-image CSS o iniettata con JavaScript, è invisibile a questo scanner, causando un forte ritardo. La soluzione più solida è usare sempre un tag <img> standard con un attributo src nel tuo HTML renderizzato dal server.
• Controlla l'ordine di caricamento con preload: Se non puoi rendere la risorsa LCP direttamente rintracciabile (un problema comune con i font o le immagini di sfondo CSS), la successiva soluzione migliore è usare <link rel="preload">. Questo tag agisce come un'istruzione esplicita nel tuo <head> HTML, dicendo al browser di iniziare a scaricare una risorsa critica molto prima di quanto l'avrebbe trovata naturalmente. Per i dettagli di implementazione e gli esempi, vedi la nostra guida su come precaricare l'immagine LCP.
• Assicurati un'alta priorità con fetchpriority: Anche quando una risorsa è rintracciabile, il browser potrebbe non darle la massima priorità di download. Aggiungere fetchpriority="high" al tuo tag <img> o al tuo tag <link rel="preload"> è un suggerimento potente per il browser che questa risorsa specifica è la più importante per l'esperienza utente, aiutandola a vincere la gara per la larghezza di banda contro altre risorse.

Correzioni del ritardo di caricamento specifiche per piattaforma

Su WordPress:

• Evita le immagini di sfondo dei page builder: Molti page builder rendono facile impostare una hero image come background-image CSS su un div. Questo la rende invisibile al preload scanner del browser. Se possibile, usa invece un blocco <img> standard. In caso contrario, potresti aver bisogno di un plugin o di codice personalizzato per precaricare quell'immagine specifica.
• Disabilita il lazy loading per l'immagine LCP: Molti plugin di ottimizzazione applicheranno automaticamente il lazy loading a tutte le immagini. Devi trovare l'impostazione nel tuo plugin per escludere l'immagine LCP (e spesso le prime immagini sulla pagina) dal lazy loading. Questo è un errore così comune che abbiamo un articolo dedicato alla correzione delle immagini LCP con lazy loading.

Su un framework JS:

• Usa il Server-Side Rendering (SSR): Questa è spesso la correzione di maggiore impatto. Un'app React predefinita con Client-Side Rendering (CSR) invia un HTML minimo e l'elemento LCP esiste solo dopo che un grande bundle JS viene scaricato ed eseguito. I framework SSR come Next.js o Remix distribuiscono l'HTML completo, incluso il tag <img>, così il browser può scoprirlo immediatamente.
• Usa componenti immagine specifici del framework: Framework come Next.js offrono un componente immagine con una prop priority. Usare la prop priority applica automaticamente fetchpriority="high" e altre ottimizzazioni alla tua immagine LCP.

3. Ridurre la durata di caricamento della risorsa

Assicurarsi che la tua risorsa LCP sia il più piccola possibile è ancora una parte essenziale del processo. Questa fase riguarda quanto tempo ci vuole per scaricare il file della risorsa LCP tramite la rete. Per una guida completa sulle tecniche di ottimizzazione delle immagini, vedi il nostro articolo sull'ottimizzazione dell'immagine LCP e per saperne di più sulla durata di caricamento della risorsa nello specifico.

Soluzioni universali per il tempo di caricamento

• Riduci le dimensioni dei file con formati moderni e immagini responsive: Il modo più diretto per accorciare i tempi di download è rendere il file più piccolo. Per le immagini, questo significa usare formati moderni e altamente efficienti come AVIF o WebP. Devi anche servire immagini responsive usando l'elemento <picture> o gli attributi srcset e sizes. Questo assicura che un utente su un dispositivo mobile riceva un'immagine dimensionata in modo appropriato per il suo schermo più piccolo, piuttosto che essere costretto a scaricare un'enorme immagine per desktop. Uno schermo mobile largo 400 pixel semplicemente non ha bisogno di un file immagine largo 2000 pixel. Per LCP basati su testo, assicurati che i tuoi font siano nell'efficiente formato WOFF2 e siano suddivisi in sottoinsiemi per rimuovere i caratteri inutilizzati.
• Riduci la contesa di rete: La risorsa LCP deve competere per la larghezza di banda limitata dell'utente. Rinviare risorse non critiche, come gli script di analisi o il CSS per i contenuti below-the-fold, libera larghezza di banda così il browser può concentrarsi sul scaricare la risorsa LCP più velocemente.
• Ospita le risorse critiche sul tuo dominio principale: Evita di caricare la tua risorsa LCP da un dominio diverso, se possibile. Stabilire una nuova connessione a un altro server aggiunge lunghe ricerche DNS e handshake.

Correzioni del tempo di caricamento specifiche per piattaforma

Su WordPress:

• Usa un plugin di ottimizzazione delle immagini: Strumenti come ShortPixel o Smush possono comprimere automaticamente le immagini al caricamento, convertirle in formati moderni come WebP/AVIF e generare dimensioni responsive per srcset.
• Ridimensiona manualmente le immagini: Prima di caricarle, ridimensiona le tue immagini affinché non siano più grandi del necessario. Non caricare un'immagine larga 4000px per uno spazio largo solo 1200px sugli schermi più grandi.

Su un framework JS:

• Usa una CDN per le immagini: Questa è una soluzione potente. Servizi come Cloudinary, Imgix o l'Image & Video Manager di Akamai possono automatizzare l'intero processo di ottimizzazione. Tu carichi un'immagine di alta qualità e loro distribuiscono una versione perfettamente dimensionata, compressa e formattata a ogni utente tramite una CDN veloce.
• Sfrutta i tool di build: Quando importi un'immagine in un componente in un framework moderno, il tool di build (come Webpack o Vite) può automaticamente applicare l'hash e ottimizzare il file come parte del processo di build.

4. Accorciare il ritardo di render dell'elemento

La risorsa ha finito di scaricarsi, ma non è ancora sullo schermo. Significa che il main thread del browser è occupato con altre attività e non può dipingere l'elemento. Questo è un altro collo di bottiglia molto comune e significativo. Per la guida completa, leggi la nostra guida sul ritardo di render dell'elemento.

Soluzioni universali per il ritardo di render

• Rinvia o rimuovi il JavaScript inutilizzato: Qualsiasi JS non essenziale per renderizzare la parte iniziale e visibile della pagina dovrebbe essere rinviato usando gli attributi defer o async.
• Usa il CSS critico: Un grande foglio di stile render blocking può ritardare il rendering. La tecnica del CSS critico consiste nell'estrarre il CSS minimo necessario per stilizzare i contenuti above-the-fold, incorporarlo nell'<head> e caricare il resto degli stili in modo asincrono.
• Suddividi i long task: Uno script a lunga esecuzione può bloccare il main thread per un periodo prolungato, impedendo il rendering. Questa è anche una causa primaria di un Interaction to Next Paint (INP) scadente. Suddividi il tuo codice in chunk asincroni più piccoli che fanno yield al main thread.

Correzioni del ritardo di render specifiche per piattaforma

Su WordPress:

• Controlla i tuoi plugin: Troppi plugin, specialmente quelli pesanti come gli slider o i page builder complessi, possono aggiungere CSS e JS significativi che bloccano il main thread. Disattiva i plugin uno alla volta per identificare chi divora le prestazioni.
• Usa un tema leggero: Un tema gonfio con dozzine di funzionalità che non usi può essere un'importante fonte di codice render blocking. Scegli un tema incentrato sulle prestazioni.
• Usa i gestori di asset dei plugin: Strumenti come Asset CleanUp o Perfmatters ti permettono di disabilitare in modo condizionale CSS e JS di plugin specifici su pagine in cui non sono necessari.

Su un framework JS:

• Il code splitting è fondamentale: Non spedire tutto il JavaScript della tua app in un singolo, gigantesco bundle. Dividi il tuo codice per rotta (così gli utenti scaricano solo il codice per la pagina che stanno visitando) e per componente.
• Applica il lazy loading ai componenti: Usa React.lazy e Suspense per applicare il lazy loading ai componenti che non sono immediatamente visibili (es. componenti below-the-fold o nei modali). Questo li tiene fuori dal bundle iniziale.

Avanzato: Ottimizzare il LCP per le navigazioni successive

Correggere il LCP iniziale è importante, ma puoi far sembrare la navigazione del tuo sito istantanea ottimizzando i caricamenti di pagina successivi.

Assicurati che le pagine siano idonee per la back/forward cache (bfcache)

La bfcache è un'ottimizzazione del browser che archivia in memoria un'istantanea completa di una pagina quando un utente si sposta altrove. Se clicca sul pulsante indietro, la pagina può essere ripristinata all'istante, ottenendo un LCP quasi a zero. Molte pagine non sono idonee per questa cache a causa di cose come i listener degli eventi unload. Usa l'audit "bfcache" di Lighthouse per testare le tue pagine e rimuovere eventuali funzionalità bloccanti.

Usa l'API Speculation Rules per il prerendering

L'API Speculation Rules ti permette di dire in modo dichiarativo al browser quali pagine un utente probabilmente visiterà dopo. Il browser può quindi recuperare e pre-renderizzare queste pagine in background. Quando l'utente clicca un link verso una pagina pre-renderizzata, la navigazione è istantanea, portando a un LCP quasi a zero. Puoi definire queste regole in un tag <script type="speculationrules"> nel tuo HTML.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Questo esempio dice al browser di cercare i link sulla pagina corrente che vanno alle pagine dei prodotti e di iniziare a pre-renderizzarle quando un utente passa il mouse sopra il link.

Elabora le quattro fasi in ordine. Correggi prima il collo di bottiglia più grande, misura di nuovo, ripeti.

Prossimi passi: Ogni fase del LCP in dettaglio

Ogni fase del LCP ha la sua guida:

• Ottimizzare l'immagine LCP: Una guida completa alla selezione del formato dell'immagine, alle immagini responsive, al preload e agli errori comuni di ottimizzazione delle immagini.
• Ritardo di caricamento della risorsa: Come assicurarsi che il browser scopra la tua risorsa LCP il prima possibile usando preload, fetchpriority e la struttura HTML corretta.
• Durata di caricamento della risorsa: Come ridurre i tempi di download per la tua risorsa LCP tramite compressione dei file, formati moderni, configurazione della CDN e ottimizzazione di rete.
• Ritardo di render dell'elemento: Come liberare il main thread del browser in modo che possa dipingere l'elemento LCP immediatamente dopo il download, coprendo il CSS critico, il rinvio del JavaScript e la content-visibility.