Risolvere l'LCP con un agente IA: dai dati sul campo alla correzione del codice

Un Largest Contentful Paint lento ha quattro possibili cause. Un agente IA connesso ai dati sul campo può identificare qual è il tuo vero collo di bottiglia, tracciarlo in Chrome e generare la correzione. Questo è il flusso di lavoro completo per la diagnosi dell'LCP utilizzando CWV Superpowers.

Ultima revisione a cura di Arjen Karel nel marzo 2026

Le quattro fasi dell'LCP

Google divide l'LCP in quattro fasi. Ognuna ha cause e correzioni diverse.

Il TTFB è il tempo dall'inizio della navigazione al primo byte della risposta HTML. Server lenti, CDN mancanti, assenza di caching, query lunghe al database. Se il TTFB è il collo di bottiglia, non conta nient'altro finché non sistemi il server.

Il Load Delay è il divario tra la ricezione dell'HTML e la richiesta da parte del browser della risorsa LCP. Questo è il problema di scoperta. Se l'immagine LCP si trova in uno sfondo CSS, è caricata tramite JavaScript o sepolta dietro una catena di reindirizzamenti, il browser non può iniziare a recuperarla finché non scopre di averne bisogno.

Il Load Time è il tempo impiegato dalla risorsa LCP per essere scaricata una volta richiesta. Immagini grandi, compressione mancante, CDN lenta, assenza di srcset responsive.

Il Render Delay è il divario tra la fine del download della risorsa e il momento in cui il browser la dipinge effettivamente sullo schermo. Script che bloccano il rendering, caricamento dei web font o JavaScript che manipola il DOM prima che l'elemento LCP diventi visibile.

Trovare il collo di bottiglia con il ragionamento proporzionale

Lighthouse ti dice "LCP is 3.8 seconds". Questo è il totale. Non ti dice quale fase correggere.

CWV Superpowers ottiene la scomposizione delle fasi dai dati sul campo di CoreDash e la interpreta proporzionalmente. Il collo di bottiglia è la fase che consuma la quota maggiore del tempo totale. Non la fase che supera una qualche soglia assoluta.

Esempio concreto. L'LCP è di 3.800 ms sulle pagine prodotto mobile. La scomposizione da parte di utenti reali:

• TTFB: 600ms (16%)
• Load Delay: 1.900ms (50%)
• Load Time: 800ms (21%)
• Render Delay: 500ms (13%)

Il Load Delay è il collo di bottiglia. Metà del tempo totale dell'LCP è il browser che aspetta di scoprire che l'immagine esiste. Un audit di Lighthouse direbbe semplicemente "3.8 seconds" e suggerirebbe di comprimere le immagini. La compressione delle immagini corregge il Load Time, che rappresenta il 21% del problema. La vera correzione sta in quel 50%.

Per una spiegazione completa di questo approccio, consulta il ragionamento proporzionale per le performance web.

Perché il browser trova l'immagine in ritardo

Il Load Delay è il collo di bottiglia dell'LCP più comune che vedo. Significa che il browser ha ricevuto l'HTML ma non sapeva di aver bisogno dell'immagine hero fino a molto tempo dopo.

Tre cause comuni. L'immagine è un'immagine di sfondo CSS invisibile allo scanner di preload. L'URL dell'immagine è costruito in JavaScript. Oppure l'immagine è tecnicamente nell'HTML ma ha un attributo di lazy loading che il browser rispetta con troppo zelo.

Apri la trace di Chrome. Vedrai un grosso divario nel waterfall di rete tra l'arrivo dell'HTML e l'avvio della richiesta dell'immagine. Quel divario è il tuo Load Delay. Sui siti che verifico, va dai 1.500 ai 2.500 ms su mobile. Due secondi interi in cui il browser ha l'HTML ma non ha la minima idea di aver bisogno dell'immagine hero.

L'agente vede lo stesso divario. Abbina il waterfall alla scomposizione di CoreDash e ti dice esattamente perché l'immagine era in ritardo.

Come si presenta la diagnosi

Ecco come si presenta l'output:

Causa principale: L'immagine LCP div.hero-banner > img.product-main su /product/running-shoes-42 viene scoperta con 1.980 ms di ritardo perché manca un hint di preload e non ha fetchpriority="high". Dati di CoreDash: l'LCP è di 3.820 ms (scadente) su mobile, p75. Il Load Delay è il collo di bottiglia al 52% del totale. La trace di Chrome conferma: divario di 1.940 ms tra il primo byte dell'HTML e la richiesta dell'immagine nel waterfall di rete.

Questa è l'intera diagnosi. L'agente ha trovato il file e ha scritto il diff. Tu lo controlli e pubblichi in produzione.

Correzioni tipiche per fase

Load Delay: Aggiungi un hint di preload nella sezione <head>. Imposta fetchpriority="high" sull'immagine LCP. Sposta l'immagine dallo sfondo CSS o da JavaScript nell'HTML dove lo scanner di preload può trovarla.

Load Time: Converti in WebP o AVIF. Riduci le dimensioni dell'immagine per farle corrispondere alle reali dimensioni di visualizzazione. Aggiungi attributi srcset responsive in modo che gli utenti mobile non scarichino un'immagine con dimensioni da desktop. Vedi l'ottimizzazione delle immagini per i Core Web Vitals.

Render Delay: Rimuovi o posticipa gli script che bloccano il rendering che vengono eseguiti prima che l'elemento LCP diventi visibile. Controlla font-display sui web font che influenzano l'elemento di testo dell'LCP. Usa i 103 Early Hints per distribuire il CSS prima.

TTFB: Aggiungi una CDN. Abilita la cache lato server. Riduci il tempo di query al database. Usa i 103 Early Hints per permettere al browser di iniziare il preload delle risorse mentre il server sta ancora generating la risposta.

Verificare la correzione

Dopo la pubblicazione, interroga i dati sul campo di CoreDash per la stessa pagina e lo stesso segmento di dispositivi. I dati sul campo si aggiornano man mano che gli utenti reali caricano la pagina. In genere controllo dopo 24 o 48 ore di traffico. Il p75 dell'LCP dovrebbe calare e la distribuzione della fase che fa da collo di bottiglia dovrebbe cambiare.

Questo è il passaggio che separa le correzioni guidate dai dati sul campo dalle tirate a indovinare di Lighthouse. Non speri che la correzione abbia funzionato. Lo vedi nei numeri reali degli utenti.