Lighthouse — Interpretare il Report e Prioritizzare le Fix per Velocizzare Davvero il Sito

Hai appena lanciato un audit Lighthouse. Il report ti mostra un punteggio 45 su Performance, un semaforo rosso e una lista di "Opportunities" lunga come un papiro. Ora, cosa fai? Corri a comprimere tutte le immagini? Disabiliti plugin a caso? Sei umano, è normale sentirsi persi.

Noi di Meteora Web ci siamo passati decine di volte. E abbiamo imparato a leggere il report come un termometro, non come una sentenza. In questo spoke ti portiamo dritti al punto: come interpretare ogni sezione del report Lighthouse e, soprattutto, come stabilire l'ordine di priorità degli interventi. Perché non tutte le fix sono uguali: alcune ti danno un boost immediato, altre sono decorazione.

Questa guida è parte del nostro pillar su Core Web Vitals e PageSpeed, ma qui entriamo nel dettaglio di Lighthouse — niente teoria, solo ciò che serve per agire.

Perché Lighthouse è Diverso da Altri Tool di PageSpeed?

La prima domanda che ci facciamo quando un cliente ci mostra uno screenshot di GTmetrix o PageSpeed Insights è: "Hai guardato anche Lighthouse su Chrome DevTools?" No, non è solo un vezzo tecnico.

Lighthouse è un audit locale e simulato — esegue un test dal tuo browser su una rete emulata (solitamente Fast 3G con throttling CPU 4x). Questo significa che misura l'esperienza utente percepita in condizioni medie, non con una connessione fiber da 1 Gbps. Ed è per questo che Google lo usa per i Core Web Vitals? No, ma è complementare. Lighthouse ti dice cosa non va e perché, mentre strumenti come CrUX ti dicono la realtà degli utenti reali.

Noi lo usiamo così: prima un audit Lighthouse per ottenere una baseline e una lista tecnica di problemi. Poi correggiamo. Poi rifacciamo l'audit per verificare. Semplice, ma solo se sai leggere il report senza farti travolgere dalla sindrome del foglio pieno di rosso.

Il Mito del Punteggio 100

Un punteggio 100 su Lighthouse è spesso un'illusione. Puoi avere 100 in Performance ma 40 in Accessibility — e se il tuo pubblico è composto da persone con disabilità visive, quel 40 è un problema serio. Noi di Meteora Web non inseguiamo il 100 per vanità: inseguiamo il miglioramento misurabile sui KPI reali del cliente (conversioni, bounce rate, tempo medio di sessione).

Ricordati: Lighthouse è uno strumento di diagnosi, non un obiettivo. Un sito con punteggio 80 che converte meglio di uno con 100 è più intelligente. Punto.

Quali Sono le Sezioni del Report Lighthouse e Come Si Leggono?

Apri Chrome DevTools (F12), vai su Lighthouse, seleziona "Mobile" e "Performance" (puoi includere anche le altre categorie, ma per questa guida ci concentriamo sulla velocità). Clicca "Generate report". Dopo qualche secondo, ecco il report: cinque sezioni colorate (Performance, Accessibility, Best Practices, SEO, Progressive Web App).

Noi vogliamo focalizzarci su Performance, ma teniamo d'occhio anche Best Practices perché errori lì (es. console.log in produzione, errori HTTP) influenzano negativamente l'esperienza.

Performance: la Tabella dei Metric

Sotto il punteggio complessivo, Lighthouse mostra i Metric: First Contentful Paint (FCP), Speed Index, Largest Contentful Paint (LCP), Time to Interactive (TTI), Total Blocking Time (TBT), Cumulative Layout Shift (CLS). Ogni metrica ha un colore (verde, arancione, rosso) basato sui threshold di Google.

Esempio reale: un nostro cliente e-commerce (negozio di abbigliamento, lo stesso di cui abbiamo gestito l'ERP internamente) aveva LCP a 8.2 secondi. Rosso fiammante. Il report mostrava "Elimina le risorse che bloccano il rendering" come opportunità principale. Avevano caricato Google Fonts in modo sincrono e un CSS enorme inline. Dopo aver ottimizzato (precaricamento dei font, CSS critico inline, differimento delle risorse non critiche), LCP è sceso a 2.1 secondi. Il punteggio Performance è passato da 32 a 89. E le conversioni sono aumentate del 18% — non per magia, ma perché il sito smetteva di far aspettare i clienti.

Morale: Leggi i metric, identifica il collo di bottiglia principale (spesso LCP o TBT), e vai a vedere le "Opportunities" sotto. Non guardare il punteggio complessivo e basta.

Opportunities: la Lista delle Cose da Fare (Ma non Tutte Subito)

Sotto i metric c'è la sezione "Opportunities" con stime di risparmio in secondi. Esempio: "Rimuovi le risorse che bloccano il rendering — risparmio potenziale 1.2 s". Questa è una stima, ma è preziosa perché ti dice dove agire per primo.

Noi usiamo una regola semplice: priorità alle opportunità con risparmio maggiore. Se hai una che risparmia 2 secondi e un'altra 0.1 secondi, parti dalla prima. Sembra banale, ma molti clienti iniziano a comprimere immagini (che può dare poco) mentre il vero problema è un file JavaScript enorme che blocca il rendering.

Attenzione: le stime di Lighthouse non sono esatte al millisecondo, ma sono un'ottima bussola. Dopo aver applicato una fix, rilancia l'audit e verifica se il miglioramento reale è vicino alla stima. Se no, qualcosa è andato storto (es. il server non supporta la compressione Brotli nonostante tu l'abbia abilitata nel .htaccess).

Come Prioritizzare le Fix sul Report Lighthouse?

Ecco il cuore della guida. Quando apri il report, la tentazione è di fare tutto in una volta. Sbagliato. Noi di Meteora Web seguiamo questo metodo a tre fasi, basato su impatto-rendimento:

Step 1: Fix Immediate (Alto Impatto, Bassa Complessità)

Queste sono le correzioni che un buon sviluppatore (o un tecnico esperto) può fare in meno di un'ora e che danno un boost visibile:

• Rimuovere risorse che bloccano il rendering: Spostare i CSS non critici in file asincroni o usarne il differimento tramite media="print" o rel="preload" per i CSS, e defer o async per gli script JS. Esempio pratico:

• Abilitare compressione Brotli o Gzip: Configurare il server per comprimere le risorse di testo. Su Apache, aggiungi nel .htaccess:

AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript

• Ridurre dimensione immagini: Convertire in WebP con compressione lossless al 80% — abbiamo un caso concreto di un cliente a cui abbiamo ridotto il peso del 60% senza perdita di qualità.

Dopo queste fix, rilancia il test. Spesso vedi un salto di 20-30 punti.

Step 2: Fix Strategiche (Medio Impatto, Media Complessità)

Una volta rimosse le ostruzioni maggiori, concentrati su LCP e CLS:

• Ottimizzazione LCP: Assicurati che l'elemento LCP (di solito un'immagine) sia caricato il prima possibile. Usa fetchpriority="high" sull'immagine LCP, o caricala con <img loading="eager">. Evita di caricare immagini LCP tramite JavaScript o CSS background.
• Stabilizzare layout (CLS): Definisci dimensioni esplicite per immagini e iframe. Esempio:

• Ridurre JavaScript non utilizzato: Usa strumenti come code coverage (DevTools > Coverage) per identificare script che vengono scaricati ma non eseguiti. Sposta il codice in bundle condizionali o caricalo solo quando serve.

Step 3: Fix Avanzate (Basso Impatto, Alta Complessità — Solo se Necessario)

Qui entrano in gioco tecnologie come service worker, lazy loading avanzato, preconnect a domini esterni, ecc. Noi di Meteora Web le implementiamo solo quando il margine di miglioramento delle prime due fasi è esaurito e il cliente richiede un livello di performance super (es. e-commerce con alto traffico da mobile). Esempio: precaricamento dei font con preload e crossorigin.

Un avvertimento: non usare il lazy loading su immagini LCP. Sembra un errore banale, ma lo vediamo spesso nei progetti che ci arrivano. Il lazy loading ritarda il caricamento di ciò che è più importante. Mettilo solo sulle immagini sotto la piega.

Come Verificare se le Fix Hanno Funzionato?

Non fermarti al primo audit dopo le fix. Noi eseguiamo sempre tre test consecutivi su Lighthouse (modalità incognito, senza estensioni) e facciamo una media. A volte un audit singolo è influenzato da caching o da carico del server in quel momento. Inoltre, confrontiamo con i dati di Google Search Console (Core Web Vitals) dopo qualche giorno, perché gli utenti reali usano connessioni e dispositivi diversi.

Un errore comune: dopo aver applicato le fix, il punteggio Performance migliora ma le metriche nel CrUX restano invariate. Perché? Perché CrUX si aggiorna su un rolling window di 28 giorni. Serve pazienza. Ma se la correzione è sostanziale, vedrai i dati migliorare entro 2-3 settimane.

Quali Errori Evitare nell'Interpretazione dei Report Lighthouse?

Ne abbiamo visti tanti. Ecco i tre peggiori:

• Fissarsi sul punteggio Performance ignorando le altre sezioni: Un sito con punteggio 95 ma con errori di Accessibilità (colori a basso contrasto, mancanza di attributi ARIA) sarà penalizzato da Google? Non direttamente, ma la legge sull'accessibilità (EAA) sta diventando obbligatoria in Europa. Noi di Meteora Web lo consideriamo un fattore di qualità.
• Applicare fix senza testare su mobile: Il test Lighthouse su mobile è spesso più severo per via del throttling. Correggi per mobile, non per desktop. Un sito che funziona bene su mobile funzionerà bene anche su desktop, non viceversa.
• Copiare soluzioni da blog senza capirle: Ad esempio, aggiungere rel="preload" a tutti i CSS senza verificarne il carico effettivo può peggiorare le cose (competizione per la larghezza di banda tra risorse preload).

Il nostro consiglio: fai un backup prima di ogni modifica. Soprattutto se modifichi file di sistema o .htaccess. Lo diciamo perché abbiamo visto siti andare offline per un errore di sintassi in un file di configurazione.

Cosa Fare Adesso

Ecco il piano operativo per la prossima ora:

1. Apri il tuo sito in Chrome DevTools > Lighthouse e genera un report su Mobile. Salva il PDF o scatta uno screenshot dei metric principali.
2. Identifica i tre colli di bottiglia con le stime di risparmio maggiori. Non guardare il punteggio, guarda il risparmio in secondi.
3. Applica una fix alla volta — inizia dalla numero 1, rilancia e verifica. Se il punteggio non migliora, ripristina e prova un'altra strada.
4. Pianifica le fix strategiche (LCP, CLS, JS non utilizzato) per la prossima settimana.
5. Monitora i dati CrUX in Search Console per confermare il miglioramento sugli utenti reali.

Se a questo punto senti di aver bisogno di una mano con le performance del tuo sito, noi di Meteora Web siamo qui — lavoriamo con aziende in tutta Italia dal 2017, e sappiamo cosa significa passare da un sito lento a uno veloce che fa vendere.