Identificare e risolvere i problemi di Largest Contentful Paint (LCP)

Questa guida fa parte dell'hub Largest Contentful Paint (LCP). LCP misura la velocità con cui viene renderizzato l'elemento visibile più grande. Google lo vuole sotto i 2,5 secondi. Quello che segue è l'esatto processo diagnostico che utilizzo quando fornisco consulenza sulla page speed.

Guida di un consulente per diagnosticare e risolvere l'LCP

Mi chiamo Arjen Karel e sono un consulente di page speed. Nel corso degli anni ho controllato centinaia di siti web e una delle sfide più persistenti è il Largest Contentful Paint (LCP). In questa guida condividerò l'esatta metodologia che utilizzo per diagnosticare e risolvere i problemi di LCP. Vedrete citazioni di 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 tratti dagli strumenti che costruisco e uso quotidianamente.

Migliorare l'LCP è un processo di eliminazione. Secondo il 2025 Web Almanac, solo il 66% degli origin mobile supera l'LCP. Ciò significa che un terzo del web ha un problema di caricamento. Trova la fase più lenta, risolvila, misura di nuovo.

La metodologia diagnostica: prima i dati sul campo, poi i dati di laboratorio

Per ottimizzare in modo efficace, è necessario adottare un flusso di lavoro diagnostico in due fasi. Ciò garantisce che stiate risolvendo i problemi che i vostri utenti stanno effettivamente affrontando, non solo inseguendo punteggi in un ambiente di laboratorio.

1. I dati sul campo (RUM & CrUX) mostrano COSA sta succedendo. I dati sul campo sono raccolti da utenti reali che visitano il vostro sito. Vi dicono se avete un problema di LCP, quali pagine sono interessate e quali utenti (mobile o desktop) lo stanno riscontrando. Dovete sempre iniziare da qui per confermare l'esistenza di un problema reale.
2. I dati di laboratorio (Lighthouse, DevTools) aiutano a diagnosticare PERCHÉ sta succedendo. I dati di laboratorio sono raccolti in un ambiente controllato e simulato. Una volta che i dati sul campo hanno confermato un problema su una pagina specifica, potete utilizzare gli strumenti di laboratorio per replicare in modo coerente il problema e sezionare il processo di caricamento per trovare la causa radice.

Iniziate con i dati sul campo in modo che i vostri sforzi di ottimizzazione mirino a cambiamenti che abbiano un impatto reale sugli utenti.

Passaggio 1: Identificare i problemi di LCP con i dati sul campo

Il vostro primo compito è utilizzare i dati degli utenti reali per confermare quali pagine, se presenti, hanno un LCP scarso.

Un punto di partenza accessibile: Google Search Console

Un punto di partenza valido è il report Core Web Vitals in Google Search Console. Accedete, navigate nel report e controllate i grafici mobile e desktop. Se Google segnala URL con "Problema LCP: più di 2,5 secondi", avete la conferma dal Chrome User Experience (CrUX) Report che una percentuale dei vostri utenti sta avendo una cattiva esperienza.

Search Console conferma il problema, ma si aggiorna lentamente e raggruppa le URL. Per dettagli a livello di pagina in tempo reale, è necessario uno strumento RUM.

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

Potete costruire il vostro setup RUM utilizzando la libreria web-vitals per inviare dati al vostro backend di analisi, ma si tratta di un impegno ingegneristico significativo.

Ho costruito CoreDash specificamente per questo. Aggiungete un tag script e lui inizia a raccogliere dati LCP da ogni visitatore reale, suddivisi per pagina, dispositivo ed elemento.

Un buon strumento RUM vi permette di vedere:

• Il vostro punteggio LCP preciso per qualsiasi URL specifica.
• Una suddivisione di ogni elemento LCP (ad esempio, un'immagine, un titolo) e quali sono più frequentemente associati a un LCP lento.
• Il timing esatto per ciascuna delle quattro fasi dell'LCP per ogni visualizzazione di pagina, individuando il collo di bottiglia.

Guardare oltre l'elemento LCP stesso è importante. In un case study ben documentato, Vodafone ha migliorato il proprio LCP del 31%, contribuendo direttamente a un aumento dell'8% delle vendite. La loro ottimizzazione si è concentrata sull'identificazione e la risoluzione dello specifico collo di bottiglia dell'LCP sulle landing page chiave, utilizzando una combinazione di analisi dei dati sul campo e correzioni mirate. L'ottimizzazione dell'LCP non riguarda solo l'immagine. È necessario comprendere l'intera pipeline di caricamento: risposta del server, scoperta della risorsa, download e paint.

Ad esempio, in CoreDash, potete navigare nella pagina LCP e visualizzare una tabella di dati che mostra i vostri elementi LCP più lenti. Cliccando su un elemento specifico (come una particolare classe CSS per un'immagine hero), potete filtrare tutte le metriche per vedere i dati di performance solo per le pagine in cui quell'elemento era l'LCP.

L'obiettivo: usare i dati sul campo per trovare la vostra pagina più lenta e il suo elemento LCP più comune. Quello è il vostro obiettivo.

Misurare l'LCP con la API Performance Observer

L'API Performance Observer vi dà accesso diretto alle voci LCP in JavaScript. Questa è la stessa API che gli strumenti RUM usano sotto il cofano per raccogliere dati sul campo. Il seguente snippet logga ogni candidato LCP che il browser identifica, inclusi l'elemento, la sua dimensione e il tempo di rendering.

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

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

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

Sapete quale pagina correggere. Ora scoprite perché è lenta. Eseguite un test con PageSpeed Insights o il pannello Lighthouse in Chrome DevTools.

Nel report, scorrete fino alla sezione "Diagnostica" e trovate l'audit "Elemento Largest Contentful Paint". Questo grafico a cascata suddivide il vostro tempo LCP nelle sue quattro sotto-parti. Il vostro strumento RUM dovrebbe mostrare una suddivisione simile basata sui vostri dati sul campo.

Il vostro obiettivo è trovare la fase più lunga in questa suddivisione. Quello è il vostro collo di bottiglia primario, ed è lì che dovreste concentrare i vostri sforzi di ottimizzazione per primi.

Passaggio 3: Capire le quattro fasi dell'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 imprescindibile. Una risposta lenta del server è un'aggiunta diretta, millisecondo per millisecondo, al vostro LCP. Prima di ottimizzare una singola immagine, dovete assicurarvi che il vostro server risponda velocemente. Scoprite di più su come ottimizzare il TTFB.
• Resource Load Delay: Questo è il "problema della scoperta" e uno dei problemi più comuni. Il browser non può scaricare una risorsa che non conosce. Se la vostra immagine LCP è nascosta in un file CSS o JavaScript, o anche se è nell'HTML ma altre risorse vengono richieste prima, il browser la trova troppo tardi, sprecando tempo prezioso. Leggete la guida completa su Resource Load Delay.
• Resource Load Duration: Questo è il tempo di download della risorsa LCP stessa. Immagini grandi e non compresse o condizioni di rete lente possono rendere questa fase un collo di bottiglia. Leggete la guida completa su Resource Load Duration.
• Element Render Delay: Questo è il problema del "troppo occupato per dipingere". Il file dell'immagine LCP potrebbe essere completamente scaricato, ma se il main thread del browser è bloccato da una pesante esecuzione di JavaScript, semplicemente non riesce a dipingere l'immagine sullo schermo. Leggete la guida completa su Element Render Delay.

Iniziate sempre assicurandovi che il vostro TTFB sia veloce e che la vostra risorsa LCP sia rilevabile prima di passare alle ottimizzazioni delle dimensioni del file e del rendering.

Passaggio 4: Eseguire la correzione

Identificato il collo di bottiglia, applicate la correzione. L'implementazione dipende dal vostro stack. Ogni fase seguente copre prima i principi universali, poi le specifiche di WordPress e dei framework JS.

1. Ottimizzare il Time to First Byte (TTFB)

Se il vostro TTFB è lento (un buon obiettivo è sotto gli 800ms), stabilisce un livello minimo elevato per il vostro LCP. Migliorare il TTFB migliorerà ogni altra metrica di caricamento.

Soluzioni TTFB universali

• Abilitare il Caching: Questo è uno dei modi più efficaci per migliorare il TTFB. Il caching genera e memorizza una copia della pagina in modo che possa essere servita istantaneamente senza attendere che il server la costruisca da zero ad ogni visita.
• Usare un CDN: Una Content Delivery Network serve i vostri contenuti da un server fisicamente vicino all'utente, il che riduce la latenza di rete. Memorizzare nella cache le vostre pagine HTML complete all'edge del CDN è una strategia potente per un TTFB globale veloce. Per consigli dettagliati sulla configurazione del CDN, consultate la nostra guida su come configurare Cloudflare per prestazioni ottimali.
• Usare la compressione Brotli o Gzip: Assicuratevi che il vostro server comprima gli asset testuali come HTML, CSS e JavaScript. Brotli offre una compressione migliore rispetto a Gzip e dovrebbe essere preferito.
• Usare HTTP/3 con 0-RTT: Assicuratevi che il vostro server sia configurato per usare HTTP/3. Offre vantaggi significativi in termini di prestazioni, incluso un migliore multiplexing. Supporta lo 0-RTT (Zero Round Trip Time Resumption), che elimina il tempo di configurazione della connessione per i visitatori ricorrenti, fornendo un istantaneo incremento del TTFB.
• Usare i 103 Early Hints: Per un potenziamento avanzato, usate il codice di stato 103 Early Hints. Questo consente al vostro server o CDN di inviare suggerimenti sui file CSS e JS critici al browser mentre sta ancora preparando il documento HTML completo, permettendo ai download di iniziare ancora prima. Per una guida completa all'implementazione, consultate il nostro articolo sui 103 Early Hints.

Correzioni TTFB specifiche per la piattaforma

Su WordPress:

• Investire in un Hosting di qualità: Su WordPress, un TTFB lento è spesso legato all'ambiente di hosting. Un hosting condiviso economico può essere un collo di bottiglia. Considerate un host WordPress gestito che sia ottimizzato per le prestazioni.
• Usare un Plugin di Caching: Un plugin di caching di alta qualità (ad esempio, WP Rocket, W3 Total Cache) non è negoziabile. Gestisce per voi la generazione di file HTML statici, che è il cuore di un caching efficace su questa piattaforma.

Su un framework JS:

• Scegliere la giusta piattaforma di hosting: Per le applicazioni Node.js, piattaforme come Vercel o Netlify sono altamente ottimizzate per i framework SSR/SSG e offrono caching intelligente ed esecuzione di funzioni serverless out of the box.
• Implementare il Caching SSR: Se state usando il Server-Side Rendering, memorizzate le pagine renderizzate nella cache del server (ad esempio, usando Redis o una cache in-memory) per evitare di renderizzarle di nuovo ad ogni richiesta.
• Attenzione ai "Cold Start" delle Serverless: Se usate funzioni serverless per il rendering, siate consapevoli che un "cold start" (la prima richiesta dopo un periodo di inattività) può avere un TTFB elevato. Usate la concurrency fornita o strategie di keep-alive per mitigare questo problema.

2. Ridurre il Resource Load Delay

Questo è frequentemente il collo di bottiglia più grande. Significa che il browser era pronto a lavorare, ma non è riuscito a trovare subito l'immagine principale o il file del font. Questo ritardo è tipicamente causato da uno di due problemi: la risorsa viene scoperta tardi, o le viene data una bassa priorità di download. Per la guida completa su questo argomento, leggete la nostra guida dedicata su Resource Load Delay.

Soluzioni universali per il Load Delay

La soluzione universale al Resource Load Delay è assicurarsi che la risorsa LCP sia sia rilevabile nel markup HTML iniziale, sia che riceva un'alta priorità dal browser. Ecco come ottenere questo risultato:

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

Correzioni del Load Delay specifiche per la piattaforma

Su WordPress:

• Evitare le immagini di sfondo dei Page Builder: Molti page builder rendono facile impostare un'immagine hero come background-image CSS su un div. Questo la rende invisibile al preload scanner del browser. Se possibile, usate invece un blocco <img> standard. In caso contrario, potreste aver bisogno di un plugin o di codice personalizzato per precaricare quella specifica immagine.
• Disabilitare il Lazy-Loading per l'immagine LCP: Molti plugin di ottimizzazione caricheranno automaticamente tutte le immagini in lazy-load. Dovete trovare l'impostazione nel vostro plugin per escludere l'immagine LCP (e spesso le prime immagini della pagina) dal lazy-loading. Questo è un errore così comune che abbiamo un articolo dedicato su come correggere le immagini LCP caricate in lazy load.

Su un framework JS:

• Usare il Server-Side Rendering (SSR): Questa è spesso la correzione più impattante. 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 è stato scaricato ed eseguito. I framework SSR come Next.js o Remix consegnano l'HTML completo, includendo il tag <img>, così il browser può scoprirlo immediatamente.
• Usare componenti immagine specifici del framework: Framework come Next.js offrono un componente immagine con una prop priority. L'uso della prop priority applica automaticamente fetchpriority="high" e altre ottimizzazioni alla vostra immagine LCP.

3. Diminuire la Resource Load Duration

Assicurarsi che la risorsa LCP sia la più piccola possibile è ancora una parte essenziale del processo. Questa fase riguarda il tempo necessario per scaricare il file della risorsa LCP attraverso la rete. Per una guida completa sulle tecniche di ottimizzazione delle immagini, consultate il nostro articolo su come ottimizzare l'immagine LCP, e per saperne di più specificamente su Resource Load Duration.

Soluzioni universali per il Load Time

• Ridurre le dimensioni del file con formati moderni e immagini responsive: Il modo più diretto per accorciare i tempi di download è rimpicciolire il file. Per le immagini, questo significa usare formati moderni e altamente efficienti come AVIF o WebP. Dovete 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, invece di essere costretto a scaricare un'immagine enorme di dimensioni desktop. Uno schermo mobile largo 400 pixel semplicemente non ha bisogno di un file immagine largo 2000 pixel. Per gli LCP basati su testo, assicuratevi che i vostri font siano nell'efficiente formato WOFF2 e che siano sottoposti a subsetting per rimuovere i caratteri inutilizzati.
• Ridurre la contesa di rete: La risorsa LCP deve competere per la limitata larghezza di banda di rete dell'utente. Differire le risorse non critiche, come gli script di analytics o il CSS per i contenuti below-the-fold, libera larghezza di banda in modo che il browser possa concentrarsi sul download più rapido della risorsa LCP.
• Ospitare le risorse critiche sul vostro dominio principale: Evitate di caricare la risorsa LCP da un dominio diverso, se possibile. Configurare una nuova connessione verso un altro server aggiunge ricerche DNS e handshake che richiedono tempo.

Correzioni del Load Time specifiche per la piattaforma

Su WordPress:

• Usare 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 srcset responsive.
• Ridimensionare manualmente le immagini: Prima di caricarle, ridimensionate le immagini affinché non siano più grandi del necessario. Non caricate un'immagine larga 4000px per uno spazio che è largo solo 1200px sugli schermi più grandi.

Su un framework JS:

• Usare un Image CDN: Questa è una soluzione potente. Servizi come Cloudinary, Imgix o Akamai's Image & Video Manager possono automatizzare l'intero processo di ottimizzazione. Caricate un'immagine di alta qualità e loro consegnano una versione perfettamente dimensionata, compressa e formattata a ogni utente tramite un CDN veloce.
• Sfruttare gli strumenti di build: Quando importate un'immagine in un componente in un framework moderno, lo strumento di build (come Webpack o Vite) può generare automaticamente l'hash e ottimizzare il file come parte del processo di build.

4. Accorciare l'Element Render Delay

La risorsa ha terminato il download, ma non è ancora sullo schermo. Ciò significa che il main thread del browser è occupato con altri task e non può dipingere l'elemento. Questo è un altro collo di bottiglia molto comune e significativo. Per la guida completa, leggete la nostra guida su Element Render Delay.

Soluzioni universali per il Render Delay

• Differire o rimuovere il JavaScript inutilizzato: Qualsiasi JS che non sia essenziale per il rendering della parte iniziale e visibile della pagina dovrebbe essere differito usando gli attributi defer o async.
• Usare il CSS Critico: Un foglio di stile grande che blocca il rendering può ritardarlo. La tecnica del CSS critico consiste nell'estrarre il CSS minimo necessario per stilizzare il contenuto above-the-fold, incorporarlo inline nel <head> e caricare il resto degli stili in modo asincrono.
• Spezzare i task lunghi: Uno script a lunga esecuzione può bloccare il main thread per un periodo prolungato, impedendo il rendering. Questa è anche una causa primaria di un cattivo Interaction to Next Paint (INP). Spezzate il vostro codice in blocchi più piccoli e asincroni che cedano (yield) il controllo al main thread.

Correzioni del Render Delay specifiche per la piattaforma

Su WordPress:

• Controllare i propri plugin: Troppi plugin, specialmente quelli pesanti come gli slider o i page builder complessi, possono aggiungere quantità significative di CSS e JS che bloccano il main thread. Disattivate i plugin uno ad uno per identificare quelli che consumano più risorse.
• Usare un tema leggero: Un tema gonfio con dozzine di funzionalità che non usate può essere una fonte importante di codice che blocca il rendering. Scegliete un tema focalizzato sulle prestazioni.
• Usare plugin Asset Manager: Strumenti come Asset CleanUp o Perfmatters vi permettono di disabilitare condizionalmente CSS e JS da specifici plugin sulle pagine dove non sono necessari.

Su un framework JS:

• Il Code Splitting è fondamentale: Non spedite tutto il JavaScript della vostra app in un unico bundle gigante. Dividete il codice per rotta (così gli utenti scaricano solo il codice per la pagina che stanno visitando) e per componente.
• Caricare i componenti in Lazy Load: Usate React.lazy e Suspense per caricare in lazy load i componenti che non sono immediatamente visibili (ad esempio, i componenti below-the-fold o nei modali). Questo li tiene fuori dal bundle iniziale.

Avanzato: ottimizzare l'LCP per le navigazioni successive

Risolvere l'LCP iniziale è importante, ma potete rendere la navigazione del vostro sito istantanea ottimizzando per i successivi caricamenti di pagina.

Assicurarsi che le pagine siano idonee per la Back/Forward Cache (bfcache)

La bfcache è un'ottimizzazione del browser che memorizza uno snapshot completo di una pagina in memoria quando un utente si allontana da essa. Se premono il pulsante indietro, la pagina può essere ripristinata istantaneamente, risultando in un LCP vicino allo zero. Molte pagine non sono idonee per questa cache a causa di cose come i listener di eventi unload. Usate l'audit Lighthouse "bfcache" per testare le vostre pagine e rimuovere qualsiasi funzionalità bloccante.

Usare l'API Speculation Rules per il Prerendering

L'API Speculation Rules vi consente di indicare in modo dichiarativo al browser quali pagine un utente probabilmente visiterà successivamente. Il browser può quindi recuperare e pre-renderizzare queste pagine in background. Quando l'utente clicca su un link a una pagina pre-renderizzata, la navigazione è istantanea, portando a un LCP vicino allo zero. Potete definire queste regole in un tag <script type="speculationrules"> nel vostro HTML.

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

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

Affrontate le quattro fasi in ordine. Risolvete prima il collo di bottiglia più grande, misurate di nuovo, ripetete.

Prossimi passi: ogni fase LCP nel dettaglio

Ogni fase dell'LCP ha la sua guida:

• Ottimizzare l'immagine LCP: Una guida completa alla selezione del formato dell'immagine, alle immagini responsive, al preloading e ai comuni errori di ottimizzazione delle immagini.
• Resource Load Delay: Come assicurarsi che il browser scopra la vostra risorsa LCP il prima possibile usando preload, fetchpriority e una corretta struttura HTML.
• Resource Load Duration: Come ridurre il tempo di download per la vostra risorsa LCP tramite la compressione dei file, i formati moderni, la configurazione del CDN e l'ottimizzazione della rete.
• Element Render Delay: Come liberare il main thread del browser in modo che possa dipingere l'elemento LCP immediatamente dopo il download, coprendo il CSS critico, il differimento del JavaScript e content-visibility.