Lighthouse: misurare la velocità di un sito e individuare miglioramenti

Lighthouse è uno strumento di audit automatizzato che identifica problemi e possibili miglioramenti nelle prestazioni di una pagina web, nell'accessibilità, nelle migliori pratiche e nell'ottimizzazione per i motori di ricerca (SEO). Analizza il caricamento di una pagina in Chrome DevTools, traccia una metrica lenta alle richieste, ai file o ai task di esecuzione coinvolti, cambia una cosa e misura di nuovo nelle stesse condizioni. Un punteggio singolo non rappresenta l'esperienza di ogni visitatore né determina il posizionamento di una pagina nei motori di ricerca.

Lighthouse e PageSpeed Insights: qual è la differenza?

La panoramica ufficiale di Lighthouse descrive gli audit tramite Chrome DevTools, riga di comando o modulo Node. I principianti possono partire dal pannello incluso in Chrome per desktop, senza installare estensioni. Questo percorso è utile anche per pagine con una sessione autenticata o pagine di sviluppo locale.

La documentazione di PageSpeed Insights distingue i dati di laboratorio da quelli sul campo. I primi sono una diagnostica Lighthouse generata in condizioni specifiche. I dati sull’esperienza degli utenti reali provengono dal Chrome User Experience Report (CrUX) e coprono gli ultimi 28 giorni di raccolta. Se una pagina ha pochi campioni, il servizio può mostrare dati per l’origine (stesso schema URL, host e porta) oppure non offrire dati degli utenti reali. Un risultato di laboratorio non implica che siano disponibili statistiche sui visitatori reali per quella pagina specifica.

Per un controllo rapido di un URL pubblico, inseriscilo in PageSpeed Insights, analizzalo, e seleziona separatamente i risultati per mobile e desktop. Per le pagine visibili solo dopo l'accesso, o per gli URL locali non raggiungibili esternamente, usa DevTools locali invece del servizio esterno. Non inviare URL privati o token di accesso a un servizio di analisi esterno.

Le misurazioni di un rapporto descrivono l'URL di destinazione e le condizioni di esecuzione. Una dimostrazione con un URL pubblico di esempio non misura il sito web che pubblica la guida o il tuo sito web. Mantieni separata la sezione sull'esperienza dell'utente reale dalla sezione diagnostica di Lighthouse quando leggi un rapporto.

Scegli prima la pagina e le condizioni di misurazione

• Obiettivo: specificare l'URL da testare, includendo articoli rappresentativi, elenchi o pagine di prodotto piuttosto che solo la home page. Non combinare modelli diversi come se fossero risultati prima e dopo per la stessa pagina.
• Stato: registrare se questa è una visita iniziale o ripetuta, lo stato di accesso e come vengono gestiti i banner di consenso. Per una pagina pubblica che non richiede il login, un profilo separato o una finestra in incognito può aiutare a ridurre gli effetti delle estensioni.
• Ambiente: registrare le versioni di Chrome e Lighthouse, la selezione mobile o desktop, il metodo di limitazione della rete e della CPU, e l'orario della misurazione. Evitare di eseguire grandi download o altri lavori pesanti allo stesso tempo.
• Archiviazione: L’opzione Clear storage cancella i dati memorizzati dal sito per approssimare una visita iniziale. Può influenzare lo stato di accesso e di consenso, quindi non abilitarla casualmente durante una sessione contenente lavoro importante. Durante la verifica di una pagina con accesso effettuato, scegli le impostazioni che preservano lo stato richiesto e usale in modo coerente nelle successive comparazioni.

Verificare mentre si è connessi come amministratore può caricare script, barre degli strumenti e politiche della cache diversi da quelli utilizzati da un visitatore anonimo. Misura la pagina pubblica separatamente quando la questione riguarda lettori ordinari. Se l'obiettivo è una funzionalità per utenti con accesso effettuato, registra esplicitamente quello stato.

Analizza il caricamento di una pagina in Chrome DevTools

1. Apri la pagina in Chrome per desktop. Verifica che l'indirizzo pubblico sia corretto, per esempio, e che la pagina non sia stata reindirizzata a una schermata di errore.
2. Apri DevTools, per esempio con F12 o Ctrl+Shift+I su Windows. Se la scheda Lighthouse è nascosta, trovala tramite il menu di overflow delle schede o Strumenti aggiuntivi nel menu DevTools. I nomi dei menu possono differire in base alla lingua e alla versione del browser.
3. Per un audit iniziale del caricamento della pagina, seleziona Navigazione sotto Modalità. Scegli Mobile o Desktop sotto Dispositivo. La modalità Mobile è un test di laboratorio con vincoli selezionati, piuttosto che una riproduzione delle prestazioni di ogni telefono reale.
4. Seleziona Prestazioni sotto Categorie, aggiungendo Accessibilità, Best Practices o SEO quando necessario. Verifica le impostazioni di cancellazione dei dati del sito e throttling e mantieni i loro valori invariati durante i confronti.
5. Seleziona Analizza caricamento pagina, o il pulsante equivalente nella tua versione. La pagina si ricarica, quindi salva preventivamente moduli incompleti o altri lavori non salvati. Evita di interagire con la pagina durante l'analisi e attendi il rapporto.
6. Verifica l'URL richiesto, l'URL finale, le impostazioni e le versioni. Salva il rapporto come HTML o JSON, selezionando il formato necessario se il menu di esportazione lo permette. I rapporti possono contenere indirizzi interni o informazioni diagnostiche, quindi considera il loro contenuto prima di condividerli.

Scegli una modalità diversa per scenari diversi da un audit di caricamento di base. La documentazione del flusso utente Lighthouse distingue Navigation per una singola navigazione, Timespan per un periodo che può includere interazioni e Snapshot per lo stato attuale della pagina. Non confrontare i risultati di Timespan o Snapshot come se fossero il punteggio completo delle prestazioni di Navigation. Considera Snapshot quando la domanda riguarda uno stato specifico, come l’accessibilità mentre un menu è aperto.

Leggi le metriche e gli indizi diagnostici prima del punteggio

La spiegazione del calcolo del punteggio di prestazioni descrive una media ponderata dei valori trasformati delle metriche. Ridurre il numero di avvisi diagnostici non aumenta il punteggio di una quantità corrispondente. I punteggi da 90 a 100 sono indicati come buoni, da 50 a 89 come da migliorare e da 0 a 49 come scarsi. Queste fasce interpretano una singola esecuzione; non definiscono tutti i ritardi accettabili per gli utenti reali.

La documentazione TBT definisce un compito lungo come uno che supera i 50 millisecondi, contando l'eccesso oltre i 50 millisecondi come tempo di blocco. TBT non è la stessa metrica di Interaction to Next Paint (INP), che riguarda la reattività alle interazioni dell'utente. Controlla separatamente le metriche Core Web Vitals dei veri utenti—LCP, INP e CLS—nei dati di campo.

Espandi le informazioni e le diagnostiche del rapporto per trovare gli elementi e le risorse interessati. Se l'elemento LCP è un'immagine nel viewport iniziale, inizia con la dimensione del trasferimento e i tempi di richiesta. Per grandi spostamenti del layout, verifica se è riservato spazio per immagini e annunci. Limitarsi a caricare in modalità lazy un'immagine importante della prima schermata o a ritardare ogni script allo stesso modo può compromettere la visualizzazione o la funzionalità necessaria, quindi identifica prima la causa e l'uso.

Per un'analisi più approfondita, continua con registrazioni e Insights nel pannello Prestazioni, come spiegato nella guida Chrome su Lighthouse e il pannello Prestazioni. Punteggi elevati in Accessibilità o SEO non certificano la completa conformità all'accessibilità o un posizionamento elevato nei motori di ricerca. L'uso della tastiera e la qualità effettiva dei contenuti, tra altre questioni al di fuori dei controlli automatizzati, devono comunque essere esaminati.

Cambia una cosa e misura di nuovo nelle stesse condizioni

1. Scegli un problema con un impatto significativo sugli utenti e una causa specifica. Per un'immagine sovradimensionata nella viewport iniziale, ad esempio, sperimenta prima con un'immagine adeguata alla sua dimensione visibile.
2. Conserva i file originali, le impostazioni e il report. Apporta modifiche localmente o in un ambiente di test e verifica che le cache forniscano i nuovi file dopo la distribuzione. Non nascondere funzionalità necessarie né mostrare una pagina diversa solo all'audit al fine di ottenere un punteggio più alto.
3. Ripeti le misurazioni con lo stesso URL, stato di login, modalità dispositivo e impostazioni di throttling. Confronta le metriche grezze e l'intervallo e la mediana delle esecuzioni ripetute piuttosto che un solo punteggio migliore. Se scegli cinque esecuzioni per condizione, ad esempio, usa lo stesso numero sia prima che dopo la modifica.
4. Verifica che la metrica target migliori e che il layout, i pulsanti, i moduli e le interazioni con la tastiera funzionino ancora. Se la modifica non aiuta o interrompe la funzionalità, ripristina i file e le impostazioni salvate e indaga un'altra causa.

La guida alla variabilità delle misurazioni spiega che cambiamenti di rete, dispositivo, server o pagina possono modificare i punteggi senza cambiamenti al codice. Anche lo stato degli annunci e dei banner di consenso fa parte delle condizioni di confronto. Registra nel rapporto data, URL, versioni degli strumenti, impostazioni, metriche e modifica effettuata. Valuta le metriche degli utenti reali dopo un periodo di raccolta e con un numero di campioni sufficienti.

Quando l'analisi fallisce o i risultati differiscono sostanzialmente

Se una pagina non riesce a caricare, l'accesso è bloccato o i reindirizzamenti falliscono, controlla l'URL finale e una normale risposta HTTP prima di interpretare un punteggio. Non rimuovere l'autenticazione per esporre una pagina privata a un test esterno. Per misurazioni locali, verifica le impostazioni di login e cancellazione dei dati del sito. Se potrebbero essere coinvolte estensioni, ripeti lo stesso obiettivo in un ambiente con minore influenza delle estensioni.

Una differenza tra PageSpeed Insights e il punteggio del tuo PC non è automaticamente un fallimento. Prima confronta le versioni di Lighthouse, i percorsi di accesso al server, le impostazioni del dispositivo e di limitazione di rete e CPU, e lo stato dei cookie. Non cercare di far corrispondere i punteggi mobile e desktop; confronta i cambiamenti prima e dopo all'interno di ciascuna condizione e considera le metriche dei veri visitatori.