Risolvere il LCP con un agente AI: dai dati sul campo alla correzione del codice

Un Largest Contentful Paint lento ha quattro possibili cause. Un agente AI 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 del LCP utilizzando CWV Superpowers.

Ultima revisione a cura di Arjen Karel a marzo 2026

Le quattro fasi del LCP

Google suddivide il LCP in quattro fasi. Ognuna ha cause e correzioni diverse.

TTFB è il tempo che intercorre 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, nient'altro ha importanza finché non sistemi il server.

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

Load Time è il tempo necessario per scaricare la risorsa LCP una volta richiesta. Immagini di grandi dimensioni, compressione mancante, CDN lenta, nessun srcset responsivo.

Render Delay è l'intervallo tra la fine del download della risorsa e il momento in cui il browser la disegna 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

I dati pubblici sui Core Web Vitals non sono sufficienti per aiutarti a trovare i veri problemi con i tuoi Core Web Vitals.  Lighthouse esegue un test sintetico su un Moto G Power simulato e riporta un singolo tempo di LCP. Il CrUX aggrega 28 giorni di dati reali di Chrome in un unico valore p75 per URL. Nessuno dei due ti dice cosa correggere.

E c'è di peggio: nessuno dei due può segmentare in modo significativo. Il CrUX combina visualizzazioni di pagina in cache, visualizzazioni senza cache, nuove visite e ricaricamenti della pagina in un unico p75. Questi dovrebbero essere trattati come problemi separati. Le visualizzazioni in cache potrebbero avere un collo di bottiglia nel TTFB dovuto alla convalida di una cache obsoleta. I ricaricamenti della pagina potrebbero nascondere un problema di scoperta delle risorse in cui il browser trova l'immagine LCP in ritardo ad ogni visita. Il p75 misto maschera entrambi.

Il CrUX ha aggiunto le sotto-parti del LCP nel 2025, il che aiuta. Ma è ancora un p75 di 28 giorni senza elementi, viewport o alcun filtro. Vedi le proporzioni delle fasi per "tutti i visitatori di questo URL nell'ultimo mese". Non vedi cosa sta succedendo sul tipo di dispositivo specifico, nel paese o nel template di pagina in cui risiede il problema.

I dati RUM segmentano in base a tutte queste dimensioni. CWV Superpowers interroga quei dati segmentati e li interpreta in modo proporzionale. Il collo di bottiglia è la fase che consuma la quota maggiore del tempo totale per lo specifico segmento che presenta problemi. Non una media priva di significato o una simulazione di Lighthouse. Dati reali!

Esempio pratico. Il LCP è di 3.800 ms sulle pagine di prodotto mobile. La ripartizione da utenti reali per le prime visite su visualizzazioni di pagina in cache:

• TTFB: 600 ms (28,7%)
• Load Delay: 1.900 ms (44,6%)
• Load Time: 800 ms (19,3%)
• Render Delay: 500 ms (7,4%)

Il Load Delay è l'ovvio collo di bottiglia. La metà del tempo totale del LCP è costituita dall'attesa del browser per scoprire l'esistenza dell'immagine. Lighthouse, il CrUX o un'indagine manuale avrebbero avuto molta difficoltà a trovare questa esatta combinazione di caratteristiche dei visitatori che ha causato questo problema.

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

Perché il browser trova la tua immagine in ritardo

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

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

Apri la traccia di Chrome. Vedrai un grosso vuoto nella cascata di rete tra l'arrivo dell'HTML e l'avvio della richiesta dell'immagine. Quel divario è il tuo Load Delay. Sui siti di cui faccio l'audit, è compreso tra 1.500 e 2.500 ms sui dispositivi mobili. 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 la cascata alla ripartizione di CoreDash e ti dice esattamente perché l'immagine era in ritardo.

Come si presenta la diagnosi

Ecco come si presenta l'output:

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

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

Correzioni tipiche per fase

Load Delay: Aggiungi un suggerimento di preload nell'<head>. Imposta fetchpriority="high" sull'immagine LCP. Sposta l'immagine dal background CSS o da JavaScript all'interno dell'HTML, dove lo scanner di precaricamento può trovarla.

Load Time: Converti in WebP o AVIF. Riduci le dimensioni dell'immagine per farle corrispondere alle dimensioni di visualizzazione effettive. Aggiungi un srcset responsivo 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 rimanda gli script che bloccano il rendering e che vengono eseguiti prima che l'elemento LCP diventi visibile. Controlla font-display sui web font che influenzano l'elemento di testo LCP. Usa 103 Early Hints per distribuire il CSS prima.

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

Verificare la correzione

Dopo il deploy, interroga i dati sul campo di CoreDash per la stessa pagina e lo stesso segmento di dispositivo. I dati sul campo si aggiornano man mano che gli utenti reali caricano la pagina. In genere controllo dopo 24-48 ore di traffico. Il p75 del LCP dovrebbe scendere e la distribuzione delle fasi del collo di bottiglia dovrebbe spostarsi.

Questa è la differenza tra correggere un numero e correggere l'esperienza utente. Non devi aspettare 28 giorni per un aggiornamento del CrUX o rieseguire Lighthouse sperando che il punteggio sia salito. Puoi vedere il miglioramento nei numeri degli utenti reali, sui segmenti di dispositivo e di rete in cui si trovava il problema.

Per la diagnosi dell'INP (la metrica che non può essere misurata in laboratorio), si applica lo stesso flusso di lavoro segmentato. Per una visione più ampia di come gli agenti AI utilizzano i dati sul campo rispetto a quelli di laboratorio in tutti e tre i Core Web Vitals, vedi il debugging dei Core Web Vitals con un agente AI.