Novità di Lighthouse 6.0

Nuove metriche, aggiornamento del punteggio di rendimento, nuovi controlli e altro ancora.

Oggi rilasciamo Lighthouse 6.0.

Lighthouse è uno strumento di controllo automatico dei siti web che aiuta gli sviluppatori a trovare opportunità e strumenti di diagnostica per migliorare l'esperienza utente dei loro siti. È disponibile in Chrome DevTools, npm (come modulo Node e CLI) o come estensione del browser (in Chrome e Firefox). È alla base di molti servizi Google, tra cui PageSpeed Insights.

Lighthouse 6.0 è disponibile immediatamente su npm e in Chrome Canary. Altri servizi Google che utilizzano Lighthouse riceveranno l'aggiornamento entro la fine del mese. Verrà implementata nella versione stabile di Chrome 84 (a metà luglio).

Per provare l'interfaccia a riga di comando Lighthouse Node, utilizza i seguenti comandi: bash npm install -g lighthouse lighthouse https://www.example.com --view

Questa versione di Lighthouse include un gran numero di modifiche elencate nel log delle modifiche della versione 6.0. In questo articolo esamineremo i punti salienti.

• Nuove metriche
• Aggiornamento del punteggio di rendimento
• Nuovi controlli
• Lighthouse CI
• Riquadro di Chrome DevTools rinominato
• Emulazione mobile
• Estensione del browser
• Budget
• Link alla posizione della sorgente
• Novità all'orizzonte
• Grazie.

Nuove metriche

Lighthouse 6.0 introduce tre nuove metriche nel report. Due di queste nuove metriche, ovvero Largest Contentful Paint (LCP) e Cumulative Layout Shift (CLS), sono implementazioni di laboratorio di Core Web Vitals.

Largest Contentful Paint (LCP)

La visualizzazione elemento più grande (LCP) è una misura dell'esperienza di caricamento percepita. Indica il punto durante il caricamento della pagina in cui i contenuti principali o "più grandi" sono stati caricati e sono visibili all'utente. LCP è un importante complemento di First Contentful Paint (FCP), che cattura solo l'inizio dell'esperienza di caricamento. LCP fornisce agli sviluppatori un indicatore della velocità con cui un utente è effettivamente in grado di visualizzare i contenuti di una pagina. Un punteggio LCP inferiore a 2,5 secondi è considerato "buono".

Per saperne di più, guarda questo approfondimento sull'LCP di Paul Irish.

Cumulative Layout Shift (CLS)

CLS (Cumulative Layout Shift) è una misura della stabilità visiva. quantifica la misura in cui i contenuti di una pagina cambiano visivamente. Un punteggio CLS basso indica agli sviluppatori che i loro utenti non stanno riscontrando cambiamenti ingiustificati dei contenuti.Un punteggio CLS inferiore a 0,10 è considerato "buono".

Il CLS in un ambiente di laboratorio viene misurato fino al termine del caricamento della pagina. Mentre sul campo puoi misurare il CLS fino alla prima interazione dell'utente o includendo tutti gli input dell'utente.

Per ulteriori informazioni, guarda questo approfondimento sul CLS di Annie Sullivan.

Tempo di blocco totale (TBT)

Total Blocking Time (TBT) quantifica la reattività al caricamento, misurando il tempo totale in cui il thread principale è stato bloccato per il tempo necessario a evitare la reattività all'input. Il TBT misura il tempo totale tra First Contentful Paint (FCP) e Tempo all'interattività (TTI). È una metrica complementare al TTI e offre più sfumature per quantificare l'attività del thread principale che blocca la capacità di un utente di interagire con la tua pagina.

Inoltre, il TBT ha una buona correlazione con la metrica sul campo First Input Delay (FID), che è un Core Web Vital.

Aggiornamento del punteggio rendimento

Il punteggio relativo alle prestazioni in Lighthouse viene calcolato da una combinazione ponderata di più metriche per riepilogare la velocità di una pagina. Di seguito è riportata la formula del punteggio del rendimento 6,0.

Fase	Nome metrica	Peso della metrica
In anticipo (15%)	First Contentful Paint (FCP)	15%
Media (40%)	Indice di velocità (SI)	15%
	Largest Contentful Paint (LCP)	25%
In ritardo (15%)	Tempo di interattività (TTI)	15%
Thread principale (25%)	Tempo di blocco totale (TBT)	25%
Prevedibilità (5%)	Cumulative Layout Shift (CLS)	5%

Sebbene siano state aggiunte tre nuove metriche, ne sono state rimosse tre precedenti: First Meaningful Paint, First CPU Idle e Max Potential FID. I pesi delle metriche rimanenti sono stati modificati per sottolineare l'interattività del thread principale e la prevedibilità del layout.

Per fare un confronto, di seguito è riportato il punteggio della versione 5:

Fase	Nome metrica	Peso
In anticipo (23%)	First Contentful Paint (FCP)	23%
Media (34%)	Indice di velocità (SI)	27%
	First Meaningful Paint (FMP)	7%
Completato (46%)	Tempo all'interattività (TTI)	33%
	Primo momento di inattività della CPU (FCI)	13%
Thread principale	RPI potenziale massimo	0%

Ecco alcuni punti salienti delle modifiche al punteggio tra le versioni 5 e 6 di Lighthouse:

• Il peso del TTI è stato ridotto dal 33% al 15%. Questa decisione è stata presa in risposta diretta ai feedback degli utenti sulla variabilità del TTI, nonché alle incoerenze nelle ottimizzazioni delle metriche che hanno portato a miglioramenti dell'esperienza utente. Il TTI è ancora un indicatore utile per capire quando una pagina è completamente interattiva, ma con il TBT come complemento, la variabilità è ridotta. Con questa modifica al sistema di punteggio, ci auguriamo di incoraggiare gli sviluppatori a ottimizzare in modo più efficace per l'interattività degli utenti.
• Il peso del FPC è stato ridotto dal 23% al 15%. La misurazione solo quando viene visualizzato il primo pixel (FCP) non ci ha fornito un quadro completo. Se la combini con la misurazione del momento in cui gli utenti riescono a vedere ciò che li interessa maggiormente (LCP), riflette meglio l'esperienza di caricamento.
• RPI potenziale massimo è stato ritirato. Non viene più visualizzata nel report, ma è ancora disponibile nel file JSON. Ora è consigliabile esaminare il TBT per quantificare l'interattività anziché l'mpFID.
• First Meaningful Paint è stato ritirato. Questa metrica era troppo variabile e non aveva un percorso di standardizzazione valido, in quanto l'implementazione è specifica per le parti interne di rendering di Chrome. Anche se alcuni team ritengono che i tempi di FMP siano utili sul proprio sito, la metrica non riceverà ulteriori miglioramenti.
• La metrica Prima inattività CPU è stata ritirata perché non è sufficientemente distinta da TTI. TBT e TTI sono le metriche di riferimento per l'interattività.
• Il peso di CLS è relativamente basso, anche se prevediamo di aumentarlo in una versione principale futura.

Variazioni dei punteggi

In che modo queste modifiche influiscono sui punteggi dei siti reali? Abbiamo pubblicato un'analisi delle variazioni del punteggio utilizzando due set di dati: un insieme generale di siti e un insieme di siti statici creato con Eleventy. In sintesi, circa il 20% dei siti registra un miglioramento significativo del punteggio, circa il 30% non registra quasi alcuna variazione e circa il 50% registra una diminuzione di almeno cinque punti.

Le variazioni del punteggio possono essere suddivise in tre componenti principali:

• Modifiche al peso del punteggio
• correzioni di bug alle implementazioni delle metriche sottostanti
• variazioni della curva del punteggio individuale

Le modifiche al peso del punteggio e l'introduzione di tre nuove metriche hanno determinato la maggior parte delle modifiche al punteggio complessivo. Le nuove metriche per le quali gli sviluppatori devono ancora eseguire l'ottimizzazione hanno un peso significativo nel punteggio di rendimento della versione 6. Mentre il punteggio medio del rendimento del corpus di test nella versione 5 era di circa 50, i punteggi medi delle nuove metriche Tempo di blocco totale e Largest Contentful Paint erano di circa 30. Insieme, queste due metriche rappresentano il 50% del peso nel punteggio di rendimento della versione 6 di Lighthouse, quindi è naturale che una percentuale elevata di siti abbia registrato cali.

Le correzioni di bug al calcolo della metrica sottostante possono comportare punteggi diversi. Ciò riguarda relativamente pochi siti, ma può avere un impatto significativo in determinate situazioni. Nel complesso, circa l'8% dei siti ha registrato un miglioramento del punteggio a causa di modifiche all'implementazione delle metriche e circa il 4% dei siti ha registrato una diminuzione del punteggio a causa di modifiche all'implementazione delle metriche. Circa l'88% dei siti non è stato interessato da queste correzioni.

Le modifiche alle curve dei singoli punteggi hanno influito anche sulle variazioni complessive dei punteggi, anche se in misura molto ridotta. Periodicamente verifichiamo che la curva del punteggio sia in linea con le metriche osservate nel set di dati HTTPArchive. Se si escludono i siti interessati da modifiche sostanziali all'implementazione, aggiustamenti minori alla curva del punteggio per le singole metriche hanno migliorato i punteggi di circa il 3% dei siti e diminuito quelli di circa il 4%. Circa il 93% dei siti non è stato interessato da questa modifica.

Calcolatore del punteggio

Abbiamo pubblicato un calcolatore del punteggio per aiutarti a esplorare il punteggio del rendimento. Il calcolatore fornisce anche un confronto tra i punteggi delle versioni 5 e 6 di Lighthouse. Quando esegui un controllo con Lighthouse 6.0, il report include un link al calcolatore con i risultati compilati.

Nuovi controlli

Codice JavaScript inutilizzato

Stiamo sfruttando la copertura del codice di DevTools in un nuovo controllo: JavaScript inutilizzato.

Questo controllo non è del tutto nuovo: è stato aggiunto a metà del 2017, ma, a causa dell'overhead delle prestazioni, è stato disattivato per impostazione predefinita per mantenere Lighthouse il più veloce possibile. Ora la raccolta di questi dati sulla copertura è molto più efficiente, quindi possiamo attivarla per impostazione predefinita.

Audit di accessibilità

Lighthouse utilizza la fantastica libreria axe-core per la categoria Accessibilità. In Lighthouse 6.0 abbiamo aggiunto i seguenti controlli:

• aria-hidden-body
• aria-hidden-focus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• duplicate-id-active
• duplicate-id-aria

Icona mascherabile

Le icone mascherabili sono un nuovo formato di icone che consente di visualizzare le icone della tua PWA su tutti i tipi di dispositivi. Per migliorare al massimo l'aspetto della tua PWA, abbiamo introdotto un nuovo controllo per verificare se il file manifest.json supporta questo nuovo formato.

Dichiarazione del set di caratteri

L'elemento meta charset dichiara quale codifica dei caratteri deve essere utilizzata per interpretare un documento HTML. Se questo elemento non è presente o se viene dichiarato in un secondo momento nel documento, i browser utilizzano una serie di approcci euristici per indovinare quale codifica utilizzare. Se un browser fa una supposizione errata e viene trovato un elemento meta charset tardivo, in genere il parser ignora tutto il lavoro svolto fino a quel momento e ricomincia da capo, il che comporta esperienze negative per l'utente. Questo nuovo controllo verifica che la pagina abbia una codifica dei caratteri valida e che sia definita in anticipo.

Lighthouse CI

Lo scorso novembre, in occasione del CDS, abbiamo annunciato Lighthouse CI, il server e la CLI Node open source che monitora i risultati di Lighthouse su ogni commit nella pipeline di integrazione continua. Da allora abbiamo fatto molta strada dalla release alpha. Lighthouse CI ora supporta numerosi provider CI, tra cui Travis, Circle, GitLab e GitHub Actions. Le immagini Docker pronte per il deployment semplificano la configurazione e un nuovo design della dashboard ora rivela le tendenze in ogni categoria e metrica di Lighthouse per un'analisi dettagliata.

Inizia a utilizzare Lighthouse CI nel tuo progetto oggi stesso seguendo la nostra guida introduttiva.

Rinominato il riquadro di Chrome DevTools

Abbiamo rinominato il riquadro Controlli in Lighthouse. Non c'è altro da dire.

A seconda delle dimensioni della finestra di DevTools, il riquadro si trova probabilmente dietro il pulsante ». Puoi trascinare la scheda per modificare l'ordine.

Per visualizzare rapidamente il riquadro con il menu Comandi:

1. Premi "Control+Maiusc+J" (o "Comando+Opzione+J" su Mac) per aprire DevTools.
2. Premi Control+Shift+P (o Command+Shift+P su Mac) per aprire il menu Comando.
3. Inizia a digitare "Faro".
4. Premi Enter.

Emulazione mobile

Lighthouse segue un approccio mobile-first. I problemi di prestazioni sono più evidenti in condizioni di utilizzo tipico su dispositivi mobili, ma spesso gli sviluppatori non eseguono test in queste condizioni. Ecco perché la configurazione predefinita in Lighthouse applica l'emulazione per dispositivi mobili. L'emulazione è costituita da:

• Condizioni di rete e CPU lente simulate (tramite un motore di simulazione chiamato Lantern).
• Emulazione dello schermo del dispositivo (la stessa disponibile in Chrome DevTools).

Fin dall'inizio, Lighthouse ha utilizzato Nexus 5X come dispositivo di riferimento. Negli ultimi anni, la maggior parte degli ingegneri delle prestazioni ha utilizzato Moto G4 per scopi di test. Ora Lighthouse segue questa strada e ha cambiato il proprio dispositivo di riferimento in Moto G4. In pratica, questa modifica non è molto evidente, ma di seguito sono riportate tutte le modifiche rilevabili da una pagina web:

• Le dimensioni dello schermo sono passate da 412 x 660 px a 360 x 640 px.
• La stringa user agent è leggermente modificata, la parte del dispositivo che in precedenza era Nexus 5 Build/MRA58N ora sarà Moto G (4).

A partire da Chrome 81, Moto G4 è disponibile anche nell'elenco di emulazione dei dispositivi di Chrome DevTools.

Estensione del browser

L'estensione di Chrome per Lighthouse è stata un modo pratico per eseguire Lighthouse localmente. Purtroppo, è stato complicato fornire assistenza. Dato che il riquadro Lighthouse di Chrome DevTools offre un'esperienza migliore (il report si integra con altri riquadri), abbiamo ritenuto di poter ridurre il sovraccarico di lavoro tecnico semplificando l'estensione di Chrome.

Anziché eseguire Lighthouse localmente, l'estensione ora utilizza l'API PageSpeed Insights. Siamo consapevoli che questa sostituzione non sarà sufficiente per alcuni dei nostri utenti. Ecco le differenze principali:

• PageSpeed Insights non è in grado di eseguire la revisione di siti web non pubblici, poiché viene eseguito tramite un server remoto e non tramite l'istanza locale di Chrome. Se devi eseguire il controllo di un sito web non pubblico, utilizza il pannello Lighthouse di DevTools o la CLI di Node.
• Non è garantito che PageSpeed Insights utilizzi la versione più recente di Lighthouse. Se vuoi utilizzare la versione più recente, utilizza Node CLI. L'estensione del browser riceverà l'aggiornamento circa 1-2 settimane dopo il rilascio.
• PageSpeed Insights è un'API di Google e il suo utilizzo comporta l'accettazione dei Termini di servizio delle API di Google. Se non vuoi o non puoi accettare i Termini di servizio, utilizza il riquadro Lighthouse di DevTools o la CLI di Node.

La buona notizia è che la semplificazione della storia del prodotto ci ha permesso di concentrarci su altri problemi di ingegneria. Di conseguenza, abbiamo rilasciato l'estensione Lighthouse per Firefox.

Budget

Lighthouse 5.0 ha introdotto i budget di rendimento, che supportano l'aggiunta di soglie per la quantità di ciascun tipo di risorsa (ad esempio script, immagini o CSS) che una pagina può pubblicare.

Lighthouse 6.0 aggiunge il supporto per le metriche di budgeting, quindi ora puoi impostare soglie per metriche specifiche come il tasso di clic finale. Per il momento, i budget sono disponibili solo per Node CLI e Lighthouse CI.

Link alla posizione di origine

Alcuni dei problemi rilevati da Lighthouse in una pagina possono essere ricondotti a una riga specifica del codice sorgente e il report indicherà il file e la riga esatti pertinenti. Per semplificare la navigazione in DevTools, facendo clic sulle posizioni specificate nel report si apriranno i file pertinenti nel riquadro Origini.

All'orizzonte

Lighthouse ha iniziato a sperimentare la raccolta di mappe di origine per supportare nuove funzionalità, come:

• Rilevamento di moduli duplicati nei bundle JavaScript.
• Rilevamento di polyfill o trasformazioni eccessivi nel codice inviato ai browser moderni.
• Miglioramento del controllo JavaScript inutilizzato per fornire granularità a livello di modulo.
• Visualizzazioni di albero che mettono in evidenza i moduli che richiedono un'azione.
• Visualizzazione del codice sorgente originale per gli elementi del report con una "posizione di origine".

Queste funzionalità verranno attivate per impostazione predefinita in una versione futura di Lighthouse. Per il momento, puoi visualizzare gli audit sperimentali di Lighthouse con il seguente flag CLI:

lighthouse https://web.dev --view --preset experimental

Grazie.

Ti ringraziamo per aver utilizzato Lighthouse e per aver fornito un feedback. Il tuo feedback ci aiuta a migliorare Lighthouse e ci auguriamo che Lighthouse 6.0 ti consenta di migliorare più facilmente il rendimento dei tuoi siti web.

Come puoi procedere

• Apri Chrome Canary e prova il riquadro Lighthouse.
• Utilizza la CLI Node: npm install -g lighthouse && lighthouse https://yoursite.com --view.
• Esegui Lighthouse CI con il tuo progetto.
• Consulta la documentazione relativa ai controlli di Lighthouse.
• Buon divertimento a migliorare il web.

Siamo appassionati di web e amiamo collaborare con la community di sviluppatori per creare strumenti che contribuiscano a migliorare il web. Lighthouse è un progetto open source e vogliamo ringraziare tutti i collaboratori che ci aiutano con tutto, dalle correzioni di errori ortografici al refactoring della documentazione fino a nuovi audit. Ti interessa dare il tuo contributo? Dai un'occhiata al repository GitHub di Lighthouse.