I 6 errori frontend che affossano il punteggio Lighthouse nel 2026

Un punteggio Lighthouse di 98 sul tuo portatile e di 41 su un telefono vero non è un errore di misura. È la distanza fra un test di laboratorio e il campo, e quasi nessun team vede il secondo numero finché un cliente non gli inoltra un report di PageSpeed. Lighthouse è un audit sintetico: carica la pagina una volta, su un dispositivo di fascia media simulato e una rete rallentata, e dà un voto. Google si basa su altro, i Core Web Vitals raccolti dagli utenti Chrome reali. Quando i due non concordano, è la produzione quella che i tuoi utenti sentono.

Questi sono i sei errori che vediamo più spesso quando un'app Next.js o React va bene in sviluppo e male in produzione. Ognuno corrisponde a una metrica precisa e a un peso preciso, quindi correggere per primo quello giusto è gran parte del lavoro.

Come Lighthouse calcola davvero la performance

Il punteggio è una media pesata di cinque metriche di laboratorio. In Lighthouse 12 il modello attuale assegna:

• Total Blocking Time (TBT): 30%, la metrica che pesa di più
• Largest Contentful Paint (LCP): 25%
• Cumulative Layout Shift (CLS): 25%
• First Contentful Paint (FCP): 10%
• Speed Index: 10%

TBT e LCP insieme valgono il 55% del numero. Migliorare una metrica che pesa il 30% sposta il punteggio tre volte più che migliorarne una che pesa il 10%, ed è per questo che "abbiamo tolto 200ms al First Contentful Paint" spesso non cambia nulla di visibile nel voto. Una metrica manca da quella lista di proposito. Interaction to Next Paint (INP) ha sostituito First Input Delay come Core Web Vital il 12 marzo 2024, ma INP è una metrica di campo. Nel punteggio di laboratorio di Lighthouse non compare affatto. Puoi fare 100 in laboratorio e fallire comunque l'INP per ogni utente reale.

Errore 1: leggere il punteggio di laboratorio come se fosse quello di campo

Il numero verde nel terminale è una singola esecuzione sintetica. Il segnale di ranking di Google, e la valutazione in Search Console, vengono dal Chrome User Experience Report, aggregato al 75° percentile delle visite reali. Una pagina supera i Core Web Vitals solo quando il 75% delle visite resta sotto 2,5s di LCP, sotto 200ms di INP e sotto 0,1 di CLS. Un punteggio di laboratorio di 95 con dati di campo negativi è frequente, ed è il campo a posizionare. Tratta il punteggio di laboratorio come uno strumento di debug che ti dice dove guardare, non come il risultato. Il risultato sta nei dati di campo.

Errore 2: una head che blocca il rendering

Ogni <script> sincrono e ogni foglio di stile nella head del documento impedisce al browser di disegnare. I tag di terze parti sono il sospetto abituale: analytics, banner di consenso, strumenti di A/B testing, widget di chat, tag manager, quasi tutti caricati in modo sincrono per default. Ritardano FCP e LCP, e il loro lavoro sul main thread gonfia il TBT. La correzione è meccanica. Metti defer o async su ogni script non critico, carica i tag di terze parti dopo l'interazione o fuori dal main thread, e porta inline solo il CSS critico che serve alla prima schermata. Le richieste che bloccano il rendering sono uno dei motivi più comuni per cui una pagina fallisce l'LCP anche dopo aver ottimizzato le immagini.

Errore 3: il lazy-load sull'immagine LCP

La regressione di LCP più comune che troviamo è loading="lazy" sull'immagine dell'hero. Il lazy-load è corretto per tutto ciò che sta sotto la piega e sbagliato per l'unico elemento che definisce l'LCP, perché il browser ritarda proprio la richiesta che la metrica sta cronometrando. I framework che fanno lazy-load di default lo nascondono dentro un componente, quindi è facile spedirlo senza accorgersene. Marca l'immagine LCP come eager, aggiungi fetchpriority="high" e fanne il preload. Poi verifica che sia davvero ottimizzata: un hero da 2MB servito in PNG fallirà l'LCP su una connessione lenta per quanto tu dia priorità alla richiesta.

Errore 4: idratare l'intera pagina

Il JavaScript è ciò che ammazza le metriche. Ogni kilobyte che spedisci viene letto, compilato ed eseguito sul main thread, e su un telefono di fascia media quel thread è circa quattro volte più lento del tuo portatile. Spedire una pagina interamente renderizzata lato client, o idratare contenuto statico che non aveva bisogno di interattività, fa salire il TBT (il 30% del punteggio) e peggiora l'INP di campo a ogni tocco. È qui che i Server Components, l'idratazione parziale e un audit spietato del bundle si ripagano da soli. Le librerie più pesanti le abbiamo trattate nello stack del web immersivo: gran parte di esse non ha nulla da fare su una pagina di marketing.

Errore 5: un layout che si sposta sotto l'utente

Il CLS vale il 25% del punteggio ed è il più facile da non vedere in sviluppo, perché gli spostamenti di layout compaiono solo quando gli asset caricano lenti. Tre colpevoli si ripetono: immagini e video senza width e height espliciti (o un box con aspect-ratio), web font che fanno lo swap e riflusso del testo, e contenuto iniettato sopra a contenuto già presente come banner, pubblicità ed embed tardivi. Riserva lo spazio per tutto ciò che carica in ritardo. Imposta font-display con criterio e fai il preload dei file dei font. Un contenitore vuoto con dimensioni fisse è meglio di un layout che salta dopo il primo paint.

Errore 6: testare sulla propria macchina

Lighthouse mobile simula un dispositivo di fascia media su una rete rallentata. La tua macchina di sviluppo è un portatile M-series sulla fibra dell'ufficio. I due possono distare 50 punti o più, e il campo sta più vicino alla prova rallentata. Fare l'audit nel browser di tutti i giorni, loggato, con le estensioni attive, peggiora le cose: le estensioni iniettano script che pesano sul punteggio. Testa come minimo in una finestra in incognito, oppure esegui Lighthouse in CI su un profilo di dispositivo fisso, così il numero è confrontabile fra un commit e l'altro invece che fra una macchina e l'altra.

Come evitare che le regressioni tornino

Le correzioni una tantum si degradano. Una pagina che oggi fa 95 torna in rosso man mano che escono feature, si aggiungono script e le immagini crescono. La correzione che dura è un budget imposto in CI. Esegui Lighthouse CI a ogni pull request con un budget di performance, un punteggio minimo o tetti rigidi su TBT e LCP, e fai fallire la build quando una modifica lo supera. Affianca a quel cancello di laboratorio un monitoraggio di campo dal Chrome User Experience Report o dai tuoi dati di utenti reali: il laboratorio cattura le regressioni prima del rilascio, il campo ti dice cosa ottengono davvero gli utenti. Per la versione procedurale, partire in verde fin dall'inizio, vedi come portiamo i Core Web Vitals in verde su Next.js.