Il Largest Contentful Paint (LCP) misura quanto tempo passa dall’inizio della navigazione al rendering del più grande elemento di contenuto visibile nel viewport. È uno dei tre Core Web Vitals e, per essere considerato buono, dovrebbe essere pari o inferiore a 2,5 secondi al 75° percentile, valutando separatamente mobile e desktop.
Il valore, però, dice soltanto che esiste un problema. Non dice automaticamente perché.
Se PageSpeed Insights segnala un LCP lento, comprimere tutte le immagini, installare un altro plugin di cache o precaricare risorse a caso può non cambiare nulla. La diagnosi corretta consiste nell’individuare l’elemento LCP e la fase nella quale si sta accumulando il ritardo.
È questo il metodo che useremo nella guida:
dati reali → elemento LCP → fase problematica → intervento → verifica.
Cos’è il Largest Contentful Paint e cosa misura davvero
Secondo la documentazione ufficiale di web.dev sul Largest Contentful Paint, LCP registra il momento in cui viene renderizzato il più grande elemento di contenuto visibile nell’area iniziale della pagina.
La parola importante è renderizzato.
LCP non misura quando la pagina ha terminato di scaricare ogni file e non coincide necessariamente con il momento in cui sparisce l’ultimo indicatore di caricamento. Cerca invece di rappresentare quando il contenuto principale visibile all’utente è comparso sullo schermo.
Questo spiega perché una pagina può avere ancora richieste di rete in corso dopo aver registrato il proprio LCP.
Quali elementi possono diventare l’elemento LCP
Nella pratica, il candidato LCP è spesso:
- un’immagine hero;
- una featured image;
- un grande banner visivo;
- un blocco di testo importante;
- un’immagine di background caricata tramite CSS;
- un’immagine o il fotogramma pertinente di un video.
web.dev include fra gli elementi considerati immagini, elementi <image> all’interno di SVG, video, immagini di background CSS e blocchi contenenti testo. Non qualsiasi elemento grande della pagina diventa quindi automaticamente candidato LCP.
C’è poi un’altra distinzione importante: conta ciò che si trova nel viewport iniziale.
Una grande immagine molto più in basso nella pagina non determina il Largest Contentful Paint osservato durante il caricamento iniziale. Al contrario, una hero image o un titolo molto esteso nella parte superiore può diventare il candidato principale.
L’elemento può inoltre cambiare durante il caricamento. Il browser aggiorna i candidati mentre nuovi contenuti vengono renderizzati, fino al momento in cui viene determinato l’LCP effettivo.
Qual è un buon valore LCP
Le soglie correnti sono:
| Largest Contentful Paint | Valutazione |
|---|---|
| ≤ 2,5 secondi | Buono |
| > 2,5 e ≤ 4 secondi | Da migliorare |
| > 4 secondi | Scarso |
La soglia non va letta su un singolo test isolato quando vuoi valutare l’esperienza reale. La raccomandazione ufficiale usa il 75° percentile delle visite, separando mobile e desktop.
In parole semplici, non basta che il sito sia veloce sul tuo computer, sulla tua connessione e durante un singolo test. Il riferimento real-user cerca di rappresentare l’esperienza di una parte molto più ampia degli utenti.
LCP, FCP, INP e CLS non misurano la stessa cosa
LCP viene spesso confuso con altre metriche.
First Contentful Paint (FCP) registra quando compare per la prima volta un contenuto della pagina. Potrebbe essere un piccolo testo o un elemento che non rappresenta ancora il contenuto principale.
Largest Contentful Paint (LCP) guarda invece il più grande elemento di contenuto visibile nel viewport.
Interaction to Next Paint (INP) riguarda la reattività alle interazioni.
Cumulative Layout Shift (CLS) misura la stabilità visiva e quindi gli spostamenti inattesi degli elementi.
Una pagina può avere un FCP rapido e un LCP lento. Per esempio, può mostrare quasi subito un piccolo titolo ma attendere diversi secondi prima di renderizzare la grande immagine hero.
Per il quadro completo delle tre metriche correnti puoi consultare la guida ai Core Web Vitals.
LCP e SEO: cosa Google conferma e cosa no
Il Largest Contentful Paint ha una relazione con la SEO, ma bisogna descriverla senza trasformarla in una formula causale che Google non ha mai dichiarato.
La documentazione Google sulla page experience conferma che i Core Web Vitals vengono utilizzati dai sistemi di ranking.
Questo è il dato confermato.
Non significa invece che:
- una pagina con LCP di 2,4 secondi debba superarne una con LCP di 2,7;
- migliorare LCP garantisca un aumento delle posizioni;
- un LCP scarso equivalga automaticamente a una penalizzazione;
- PageSpeed 100 sia un requisito per posizionarsi.
Google chiarisce espressamente che ottenere buoni risultati nei Core Web Vitals non garantisce le prime posizioni e che la rilevanza del contenuto continua a essere fondamentale.
La formulazione corretta è quindi questa:
GOOGLE_CONFIRMED: Core Web Vitals viene utilizzato nei ranking systems.
NON CONFERMATO: esiste una relazione lineare del tipo “X millisecondi risparmiati = Y posizioni guadagnate”.
Dal punto di vista operativo cambia molto. Conviene migliorare LCP perché stai correggendo un problema reale di caricamento e lavorando su una componente della page experience considerata da Google, non perché esista una soglia magica capace di garantire un ranking.
Perché non ha senso inseguire il punteggio perfetto
Un’altra fonte di confusione è il numero da 0 a 100 restituito da Lighthouse.
Quel valore è un Performance Score di laboratorio. Non è il valore LCP degli utenti reali, non coincide con il report Core Web Vitals e non è un punteggio SEO.
Una pagina può ottenere un ottimo Performance Score durante un test e avere dati real-user peggiori. Può succedere anche il contrario.
Se vuoi approfondire questa distinzione, nella guida a PageSpeed Insights trovi separati CrUX, Lighthouse, Performance Score e Core Web Vitals.
Il principio da ricordare qui è più semplice: non ottimizzare LCP per trasformare un 96 in 100 se non hai prima verificato quale problema reale stai cercando di risolvere.
Come misurare LCP senza confondere field data e lab data
La diagnosi diventa molto più affidabile quando separi due domande:
- gli utenti reali hanno un problema LCP?
- che cosa sta causando tecnicamente quel problema?
La prima richiede soprattutto field data. La seconda si affronta con strumenti di laboratorio e diagnostica.
Field data: cosa stanno vivendo gli utenti reali
I field data provengono da visite reali effettuate con dispositivi, reti e condizioni differenti.
PageSpeed Insights può mostrare questi dati attraverso il Chrome User Experience Report (CrUX).
Sono particolarmente utili per capire se il problema che hai visto durante un test esiste anche nella popolazione reale degli utenti.
Per LCP, CrUX utilizza il 75° percentile. I dati non cambiano immediatamente dopo una modifica: descrivono infatti una finestra di esperienze raccolte nel tempo.
Questo evita un errore frequente.
Hai ottimizzato oggi la hero image, esegui PageSpeed Insights dopo cinque minuti e il test di laboratorio migliora. Non devi aspettarti che nello stesso momento il valore real-user si trasformi completamente, perché contiene ancora esperienze precedenti all’intervento.
Lab data: come trovare la causa tecnica
I test di laboratorio eseguono invece la pagina in condizioni controllate.
Strumenti come Lighthouse e il Performance panel di Chrome DevTools sono utili perché consentono di osservare:
- quale elemento è stato identificato come LCP;
- quando è iniziato il caricamento;
- quali richieste sono partite prima;
- quanto tempo ha richiesto la risorsa;
- cosa ha impedito eventualmente il rendering immediato;
- quali script o stylesheet hanno interferito con il percorso critico.
Il laboratorio non sostituisce il dato reale: serve soprattutto a diagnosticarlo.
Un workflow utile è quindi:
CrUX rileva il problema → laboratorio cerca la causa → modifica tecnica → laboratorio verifica l’effetto → field data confermano nel tempo.
URL data e origin data in PageSpeed Insights
Prima di interpretare un dato CrUX devi anche controllare la sua granularità.
Non tutte le URL ricevono abbastanza traffico da avere un campione real-user autonomo. In questi casi PageSpeed Insights può mostrare dati relativi all’origin, cioè all’insieme del sito.
Non è una distinzione da poco.
Una homepage con hero, slider e script può comportarsi in modo completamente diverso da un articolo dello stesso dominio. Se stai guardando origin data, non puoi attribuire automaticamente quel valore LCP alla singola pagina che stai analizzando.
La guida a PageSpeed Insights e ai dati URL/origin approfondisce proprio questo passaggio.
Come trovare l’elemento LCP che sta rallentando la pagina
Una volta verificato che LCP merita attenzione, la domanda successiva non è “quale plugin devo installare?”.
È: qual è l’elemento LCP e cosa succede prima che venga renderizzato?
Identificare l’elemento in Chrome DevTools
Il Performance panel di Chrome DevTools integra gli Insights dedicati alle performance, compreso il breakdown dell’LCP.
Registrando il caricamento della pagina puoi individuare l’evento LCP e ricondurlo all’elemento coinvolto.
Se si tratta di un’immagine hero, puoi quindi capire:
- dove si trova nel DOM;
- da quale URL viene caricata;
- quando il browser la scopre;
- quale priorità riceve;
- quando parte e termina la richiesta;
- quanto tempo passa prima del rendering.
Se invece LCP è un blocco di testo, il problema può seguire un percorso differente: per esempio font, CSS, JavaScript o lavoro sul main thread.
La diagnosi parte sempre dall’elemento reale, non dalla tecnica che vorresti applicare.
Leggere il waterfall prima di modificare il sito
Per un LCP basato su una risorsa, la guida ufficiale all’ottimizzazione LCP suggerisce di concentrarsi inizialmente soprattutto su due richieste:
- documento HTML iniziale;
- risorsa necessaria all’elemento LCP.
Il waterfall ti permette di vedere la relazione temporale tra queste due richieste.
Se il documento HTML arriva tardi, la causa può essere a monte.
Se l’HTML arriva rapidamente ma la hero image viene scoperta molto dopo, il problema è diverso.
Se la risorsa parte presto ma impiega molto tempo a essere trasferita, devi intervenire ancora in un’altra direzione.
E se l’immagine è già stata scaricata ma resta invisibile per mezzo secondo perché il browser è impegnato con CSS o JavaScript, comprimere nuovamente il file potrebbe non cambiare il valore finale.
Per questo il waterfall conduce naturalmente alla parte più importante della diagnosi: scomporre LCP nelle sue fasi.
Le 4 fasi del Largest Contentful Paint: dove si perde davvero tempo
Chrome e web.dev suddividono LCP in quattro componenti:
- Time to First Byte (TTFB)
- resource load delay
- resource load duration
- element render delay
La loro somma produce il tempo LCP quando l’elemento richiede una risorsa.
Questa scomposizione è molto più utile di una checklist generica perché ogni fase corrisponde a famiglie di cause differenti.
| Fase | Cosa misura | Possibile problema |
| TTFB | attesa dell’HTML iniziale | server, rete, redirect, backend |
| Resource load delay | attesa prima dell’inizio della risorsa LCP | discovery/priorità |
| Resource load duration | trasferimento della risorsa | peso, rete, distanza |
| Element render delay | attesa fra risorsa pronta e rendering | CSS, JS, main thread |
Il punto è diagnosticare dove è concentrato il tempo evitabile, non costringere ogni fase a rispettare una percentuale artificiale.
1. Time to First Byte: il ritardo prima che inizi il caricamento
TTFB misura il tempo fra l’avvio della navigazione e l’arrivo del primo byte della risposta HTML.
È una componente strutturale del Largest Contentful Paint: se il documento iniziale arriva tardi, tutto ciò che il browser deve scoprire attraverso quel documento parte più tardi.
Un TTFB elevato può dipendere da più fattori:
- redirect prima della risposta finale;
- latenza di rete;
- elaborazione lenta lato server;
- query al database;
- assenza o inefficienza della cache;
- infrastruttura non adeguata al carico;
- distanza tra utente e server.
Questo non significa che “hosting più veloce” sia sempre la risposta. Se TTFB rappresenta una parte piccola del tuo LCP e il vero ritardo avviene dopo, cambiare server potrebbe produrre un miglioramento marginale rispetto al problema reale.
Per approfondire questa componente separatamente puoi leggere la guida al Time to First Byte.
2. Resource load delay: quando il browser scopre troppo tardi la risorsa LCP
Il resource load delay è il tempo trascorso fra TTFB e l’inizio del caricamento della risorsa necessaria all’LCP.
Qui il file potrebbe essere perfettamente ottimizzato e il server molto rapido. Il problema è che il browser inizia a scaricarlo troppo tardi.
Immagina una hero image da 80 KB che parte soltanto dopo che JavaScript ha costruito una parte della pagina. Può essere più problematica per LCP di un’immagine da 150 KB scoperta immediatamente nell’HTML.
Le cause tipiche comprendono:
- immagine inserita tardi tramite JavaScript;
- immagine definita come background CSS e scoperta dopo il foglio di stile;
- lazy loading applicato alla risorsa LCP;
- priorità non adeguata;
- risorsa dipendente da una catena di richieste precedenti.
La documentazione Chrome sull’LCP request discovery indica tre principi molto concreti per un’immagine LCP:
- renderla individuabile rapidamente dal documento;
- darle una priorità appropriata;
- non applicarle lazy loading.
Quando l’immagine è realmente il candidato LCP, può avere senso anche fetchpriority="high":
<img src="/immagini/hero.webp" alt="..." fetchpriority="high" >
L’attributo non va però applicato indiscriminatamente a tutte le immagini. Se dichiari contemporaneamente molte risorse come prioritarie, stai semplicemente spostando il problema: il browser non può considerare tutto “più importante”.
3. Resource load duration: quando la risorsa è lenta da trasferire
La resource load duration misura quanto impiega la risorsa LCP a essere trasferita.
Se questa parte domina il breakdown, allora hanno senso interventi come:
- riduzione delle dimensioni effettive dell’immagine;
- compressione appropriata;
- formato adatto al contenuto;
- responsive images;
- riduzione della distanza di rete;
- miglioramento della delivery.
Qui WebP e AVIF possono essere utili, ma non servono percentuali universali per decidere. Il risultato dipende dall’immagine, dal contenuto visivo, dall’encoder, dalla qualità scelta e dal formato originale.
La verifica corretta è pratica: confronta resa e peso del file che stai realmente servendo.
Per WordPress trovi un approfondimento separato sull’ottimizzazione delle immagini.
Una Content Delivery Network può inoltre ridurre la distanza fra risorsa e utente in determinati scenari. Non è però una soluzione automatica per qualsiasi LCP: se il problema è un render delay provocato dal JavaScript, distribuire più rapidamente l’immagine non rimuove il blocco sul main thread.
4. Element render delay: quando la risorsa è pronta ma non viene mostrata
Questa è una delle fasi più facili da trascurare.
L’element render delay è il tempo che passa tra la fine del caricamento della risorsa LCP e il momento in cui l’elemento viene effettivamente renderizzato.
In altre parole: il browser possiede già ciò che dovrebbe mostrare, ma qualcosa gli impedisce di mostrarlo subito.
Le cause possono comprendere:
- stylesheet render-blocking;
- script sincroni;
- elemento aggiunto al DOM solo dopo l’esecuzione di JavaScript;
- librerie che nascondono temporaneamente il contenuto;
- long task sul main thread;
- logica client-side necessaria per costruire la parte iniziale della pagina.
Qui emerge uno dei motivi per cui ottimizzare LCP soltanto “riducendo il peso delle immagini” può fallire.
web.dev mostra un caso didattico molto utile: comprimendo ulteriormente l’immagine si riduce il tempo di download, ma LCP rimane invariato perché il tempo risparmiato si trasforma in element render delay. La risorsa è pronta prima, ma il JavaScript continua a impedirne il rendering.
È un esempio importante perché cambia il modello mentale:
file più piccolo ≠ automaticamente LCP più basso.
La domanda corretta è sempre: che cosa sta determinando il timestamp finale dell’LCP?
Come migliorare LCP in base alla causa
A questo punto l’ottimizzazione può finalmente diventare selettiva.
Non devi applicare tutte le tecniche possibili. Devi scegliere quelle coerenti con la fase che hai identificato.
Se il problema è TTFB
Quando il ritardo è concentrato prima dell’arrivo dell’HTML, guarda soprattutto al percorso server-side e di rete.
Controlla:
- redirect iniziali evitabili;
- cache della pagina;
- tempi del backend;
- database;
- chiamate esterne necessarie alla generazione della pagina;
- capacità dell’hosting;
- posizione dell’infrastruttura rispetto agli utenti;
- eventuale CDN dove abbia realmente senso.
Su WordPress, una cache pagina ben configurata può ridurre il lavoro necessario per generare ripetutamente lo stesso HTML. Non significa però che attivare qualsiasi plugin di cache risolva automaticamente ogni problema.
La guida ai plugin di caching WordPress approfondisce configurazioni e casi d’uso. Per LCP, usala solo dopo aver verificato che la componente server rappresenti effettivamente un collo di bottiglia.
Se la risorsa LCP viene scoperta troppo tardi
Se il download comincia tardi, lavora sulla discovery.
Per una hero image:
- preferisci che il browser possa individuarla direttamente nell’HTML quando l’architettura lo consente;
- evita
loading="lazy"sull’immagine LCP; - valuta
fetchpriority="high"; - usa il preload solo quando serve davvero a rendere disponibile prima una risorsa altrimenti scoperta tardi;
- verifica il risultato nel waterfall.
Una background image CSS è un buon esempio. Il browser deve prima ottenere e analizzare il CSS prima di conoscere l’URL dell’immagine. In alcuni casi un preload può anticiparne la scoperta; in altri è più sensato rivedere la struttura del markup.
Non trasformare comunque il preload in un’abitudine. Ogni risorsa precaricata compete per banda e priorità con le altre.
Se l’immagine LCP è troppo pesante
Quando il breakdown mostra che è il trasferimento a richiedere troppo tempo, l’ottimizzazione dell’asset torna centrale.
Controlla:
Dimensioni reali.
Non servire un’immagine enorme per visualizzarla in un contenitore molto più piccolo.
Responsive images.srcset e sizes permettono al browser di scegliere una risorsa più adatta al contesto.
Compressione.
Cerca il miglior equilibrio tra peso e qualità percepita.
Formato.
WebP o AVIF possono essere vantaggiosi, ma scegli sulla base del file reale e della compatibilità necessaria, non per moda.
Delivery.
Controlla caching HTTP, rete e, quando pertinente, CDN.
Dopo ogni modifica guarda di nuovo il breakdown: se hai ridotto molto la resource load duration ma LCP è quasi identico, la fase dominante si trova altrove.
Se CSS o JavaScript ritardano il rendering
Quando la risorsa LCP è già pronta ma il contenuto appare tardi, devi guardare al critical rendering path e al main thread.
Le domande utili sono:
- esistono stylesheet che bloccano il rendering più a lungo del necessario?
- quanto CSS è realmente necessario per il contenuto iniziale?
- script sincroni stanno ritardando il primo rendering?
- un page builder deve eseguire JavaScript prima di costruire la hero?
- long task occupano il main thread?
- strumenti di A/B testing o script di terze parti stanno nascondendo/modificando la parte superiore della pagina?
Non esiste una regola moderna secondo cui sia sempre necessario “unire tutti i CSS e JavaScript in un singolo file”.
Con HTTP moderni, caching e architetture attuali, il numero di file non può essere valutato isolatamente. Quello che conta qui è come le risorse interferiscono con il percorso necessario a renderizzare l’LCP.
Quando CDN e caching aiutano davvero e quando no
Cache e CDN vengono spesso consigliate come soluzione universale perché possono effettivamente migliorare diverse parti della catena.
Ma ogni tecnologia interviene su un meccanismo specifico.
Una cache server-side può ridurre il tempo necessario a produrre l’HTML.
Una CDN può avvicinare contenuti e risorse agli utenti o ridurre il carico sull’origin.
Una image CDN può intervenire anche su dimensioni, trasformazioni e delivery delle immagini.
Nessuna di queste cose elimina automaticamente:
- un lazy loading sbagliato sulla hero;
- un elemento creato tardi da JavaScript;
- un CSS render-blocking eccessivo;
- un long task sul main thread.
La guida dedicata spiega più nel dettaglio quando una CDN produce un vantaggio reale.
Largest Contentful Paint su WordPress: cosa controllare prima dei plugin
Su WordPress il problema LCP viene spesso affrontato partendo direttamente dai plugin di performance.
È l’ordine inverso.
Prima devi sapere qual è il tuo elemento LCP e quale fase lo rallenta. Solo dopo puoi decidere se una funzione del plugin corrisponde alla causa.
Immagine hero, featured image e lazy loading
Su molti siti WordPress, soprattutto blog, landing page e siti aziendali, il candidato LCP può essere una featured image o una hero.
Apri il markup finale generato dal sito e controlla la risorsa reale, non soltanto le impostazioni presenti nell’editor.
Tema, page builder, plugin di ottimizzazione e CDN possono modificare il markup o la modalità con cui l’immagine viene servita.
Se l’immagine iniziale è l’LCP, controlla soprattutto:
- che venga scoperta presto;
- che non abbia
loading="lazy"; - che le dimensioni servite siano appropriate;
- che non dipenda inutilmente da JavaScript;
- che la priorità di caricamento sia coerente con il suo ruolo.
È più utile verificare questi cinque punti che attivare dieci opzioni “speed” senza sapere quale modifica stia agendo sul problema.
Tema, page builder e CSS/JavaScript
Un page builder può produrre una hero visivamente semplice ma tecnicamente complessa.
Per esempio, l’immagine può essere:
- caricata come background CSS;
- inserita dopo l’avvio di uno script;
- nascosta finché una classe non viene modificata;
- accompagnata da CSS e JavaScript necessari a inizializzare componenti sopra la piega.
In questi scenari il file immagine può essere già leggero. Il ritardo nasce dalla costruzione della pagina.
Il Performance panel di DevTools è particolarmente utile perché consente di mettere in relazione caricamento della risorsa, attività del main thread e rendering dell’elemento.
Cache e hosting quando il collo di bottiglia è lato server
Se il tuo breakdown mostra un TTFB molto pesante, allora cache, backend e hosting meritano priorità.
Su WordPress possono entrare in gioco:
- PHP;
- database;
- plugin;
- chiamate remote;
- generazione dinamica;
- cache pagina;
- cache oggetti;
- infrastruttura.
Ma è importante mantenere la causalità corretta.
Non stai “attivando una cache per migliorare LCP”. Stai riducendo una componente server-side che sta contribuendo al tuo LCP.
La differenza sembra sottile, ma evita molte ottimizzazioni casuali.
Perché installare un altro plugin non è una diagnosi
Un plugin di performance può fare molte cose utili: cache, minificazione, defer, delay, preload, critical CSS, ottimizzazione immagini.
Il problema è che alcune di queste funzioni possono essere corrette per una pagina e inutili, o persino controproducenti, per un’altra.
Se ritardi uno script che serviva a renderizzare l’elemento iniziale, puoi peggiorare la situazione.
Se applichi lazy loading alla hero, puoi aumentare il resource load delay.
Se precarichi troppe risorse, aumenti la competizione per la banda.
La procedura più sicura è:
diagnosi → singola modifica → test → confronto.
Non:
plugin → attiva tutto → spera che il punteggio diventi verde.
Errori comuni nell’ottimizzazione di LCP
Alcuni errori tornano frequentemente perché sembrano intuitivi.
Fare lazy loading dell’immagine LCP
Il lazy loading è utilissimo per immagini fuori dal viewport iniziale.
Sulla risorsa LCP può ottenere l’effetto opposto: il browser ne ritarda intenzionalmente l’avvio proprio quando vorresti che partisse presto.
Chrome raccomanda esplicitamente di evitare loading="lazy" quando l’immagine costituisce l’LCP.
Il lazy loading non è quindi “buono” o “cattivo” per la performance. Dipende da quale risorsa stai ritardando.
Comprimere l’immagine quando il vero problema è il render delay
Se l’immagine finisce di caricarsi a 1,6 secondi ma viene renderizzata a 3,2 secondi, ridurne ulteriormente il peso potrebbe non risolvere il problema decisivo.
Devi capire cosa succede durante quegli 1,6 secondi di attesa.
CSS? JavaScript? Main thread? Rendering condizionale?
Il breakdown serve esattamente a impedire questo tipo di diagnosi superficiale.
Precaricare troppe risorse
preload comunica al browser che una risorsa dovrà essere recuperata presto.
Se ne abusi, stai però creando una coda di risorse tutte apparentemente critiche.
Usalo quando hai identificato una risorsa importante scoperta troppo tardi, non come decorazione nel <head>.
Lo stesso principio vale per fetchpriority="high": dare priorità elevata a troppe immagini riduce il valore del segnale.
Ottimizzare Lighthouse ignorando i dati reali
Un test Lighthouse è ottimo per debugging e confronto controllato.
Non rappresenta automaticamente l’intera popolazione reale dei visitatori.
Se CrUX mostra un problema persistente mentre il tuo test locale è perfetto, non concludere che “Google sbaglia”. Indaga le differenze:
- dispositivi;
- connessioni;
- geografia;
- cache;
- template;
- campione;
- condizioni del test.
Viceversa, se un singolo test è negativo ma i dati real-user sono stabilmente buoni, evita di trasformare quella singola esecuzione in una crisi.
Correggere tutto contemporaneamente
È uno degli errori più costosi durante l’ottimizzazione.
Se contemporaneamente:
- cambi CDN;
- abiliti cache;
- modifichi immagini;
- ritardi JavaScript;
- generi critical CSS;
- cambi preload;
e LCP migliora, non sai quale intervento abbia prodotto il risultato. Se compare una regressione, la diagnosi diventa ancora più difficile.
Meglio isolare le modifiche più importanti e mantenere una baseline.
Come verificare se l’ottimizzazione LCP ha funzionato
L’ottimizzazione non termina quando hai salvato una configurazione.
Termina quando hai verificato l’effetto.
Verifica immediata in laboratorio
Ripeti il test in condizioni il più possibile confrontabili.
Controlla:
- elemento LCP;
- tempo totale;
- breakdown delle fasi;
- waterfall;
- priorità della risorsa;
- eventuali regressioni.
Non guardare soltanto se il numero finale è diminuito.
Se hai modificato la discovery dell’immagine, vuoi vedere che la richiesta inizi prima.
Se hai lavorato sul server, vuoi vedere un TTFB più basso.
Se hai rimosso un blocco JavaScript, vuoi vedere diminuire l’element render delay.
Questo collegamento tra modifica e meccanismo ti dice molto più di un punteggio complessivo.
Verifica sui dati degli utenti reali
Dopo la verifica di laboratorio devi lasciare che i nuovi caricamenti entrino nei field data.
CrUX aggrega esperienze reali su una finestra temporale, quindi il cambiamento non viene rappresentato istantaneamente.
Per questo lab e field rispondono a due momenti diversi:
lab → ho modificato correttamente il meccanismo?
field → il miglioramento emerge anche nell’esperienza reale?
Sono entrambe domande necessarie.
Controllare mobile e desktop separatamente
Non dare per scontato che il problema sia identico sui due tipi di dispositivo.
Mobile può essere più sensibile a:
- connessioni lente;
- CPU meno potente;
- JavaScript;
- dimensioni e scelta delle immagini.
Desktop può avere un viewport differente e quindi persino un candidato LCP diverso.
La soglia ufficiale viene infatti valutata al 75° percentile separatamente per mobile e desktop.
Se migliori soltanto il test desktop mentre il problema reale riguarda principalmente mobile, hai ottimizzato lo scenario sbagliato.
Conclusione
Il dato più utile da portarsi via è questo: un LCP alto è un sintomo, non una diagnosi.
Sapere che una pagina registra 3,5 secondi ti dice che il contenuto principale visibile arriva troppo tardi. Non ti dice se devi comprimere un’immagine, migliorare il server, cambiare la priorità di una risorsa o rimuovere un blocco sul main thread.
La sequenza più affidabile è quindi:
- verifica se il problema compare nei dati reali;
- identifica l’elemento LCP;
- scomponi il tempo in TTFB, resource load delay, resource load duration ed element render delay;
- intervieni sulla fase che genera il collo di bottiglia;
- misura di nuovo nello stesso scenario;
- verifica nel tempo se il risultato emerge anche sui dati real-user.
È un metodo meno spettacolare del pulsante “ottimizza tutto”, ma permette di sapere perché una modifica funziona e quando non serve applicarla.
Se PageSpeed Insights e DevTools mostrano problemi distribuiti fra server, frontend, cache, immagini e struttura, il limite non è più una singola metrica. In quel caso conviene passare da correzioni isolate a un’analisi di ottimizzazione del sito web che parta dai colli di bottiglia reali e misuri gli interventi rispetto a una baseline.