Lighthouse: ottimizza la velocità del sito web

Kayce Basques

Sofia Emelianova

Panoramica

Utilizza il riquadro Lighthouse per eseguire un controllo completo del tuo sito web. Il riquadro Lighthouse genera un report che fornisce informazioni sui seguenti aspetti del tuo sito web:

• Prestazioni
• Accessibilità
• Best practice
• SEO

... e molte altre metriche.

Il seguente tutorial ti aiuta a iniziare a utilizzare Lighthouse in Chrome DevTools.

Per scoprire di più su come Lighthouse può migliorare la qualità del tuo sito web, consulta la documentazione di Lighthouse.

Scopo del tutorial

Questo tutorial ti insegna a utilizzare Chrome DevTools per trovare modi per velocizzare il caricamento dei tuoi siti web.

Continua a leggere o guarda la versione video di questo tutorial:

Questo video è stato realizzato con Chrome 68. La maggior parte di quanto descritto è ancora valida, ma alcune funzionalità sono state aggiornate. Ad esempio, il riquadro Controlli ora si chiama Lighthouse e ha un aspetto diverso, ma sono ancora disponibili tutte le stesse opzioni.

Prerequisiti

Dovresti avere esperienza di base nello sviluppo web, simile a quella insegnata in questo corso introduttivo allo sviluppo web.

Non devi sapere nulla sul rendimento del caricamento.

Introduzione

Sono Tony. Tony è molto famoso nella società dei gatti. Ha creato un sito web per consentire ai fan di scoprire i suoi piatti preferiti. I suoi fan adorano il sito, ma Tony continua a ricevere lamentele sul suo caricamento lento. Tony ti ha chiesto di aiutarlo ad accelerare il sito.

Il gatto Tony.

Passaggio 1: esegui un audit del sito

Ogni volta che vuoi migliorare il rendimento del caricamento di un sito, inizia sempre con un controllo. Il controllo ha due funzioni importanti:

• Crea una base di riferimento in base alla quale misurare le modifiche successive.
• Ti fornisce suggerimenti pratici sulle modifiche che avranno l'impatto maggiore.

Configura

Innanzitutto, devi configurare un nuovo ambiente di lavoro per il sito web di Tony, in modo da poter apportare modifiche in un secondo momento:

1. Remixa il progetto del sito web su Glitch. Il nuovo progetto si apre in una scheda. Questa scheda verrà indicata come scheda dell'editor.

   

   Il nome del progetto cambia da tony a un nome generato in modo casuale. Ora hai una tua copia modificabile del codice. In un secondo momento apporterai modifiche a questo codice.

2. Nella parte inferiore della scheda dell'editor, fai clic su Anteprima > Anteprima in una nuova finestra. La demo si apre in una nuova scheda. Questa scheda verrà indicata come scheda demo. Il caricamento del sito potrebbe richiedere del tempo.

   

3. Apri DevTools insieme alla demo.

   

Punto chiave: per il resto degli screenshot di questo tutorial, DevTools viene mostrato in una finestra separata.

Stabilire un valore di riferimento

La linea di base è un record del rendimento del sito prima di apportare miglioramenti.

1. Apri il riquadro Lighthouse. Potrebbe essere nascosto dietro Altri pannelli.

   Nota: questo riquadro è basato sul suo omonimo, Lighthouse, uno strumento automatico per migliorare la qualità delle app web.

   

2. Fai in modo che le impostazioni di configurazione del report Lighthouse corrispondano a quelle nello screenshot. Ecco una spiegazione delle diverse opzioni:

   • check_box Cancella dati archiviati. L'attivazione di questa casella di controllo cancella tutto lo spazio di archiviazione associato alla pagina prima di ogni controllo. Lascia attiva questa impostazione se vuoi verificare l'esperienza dei visitatori che accedono al tuo sito per la prima volta. Disattiva questa impostazione se vuoi l'esperienza di visita ripetuta.
   • check_box Abilita campionamento di JS. Questa opzione è disattivata per impostazione predefinita. Se è attiva, aggiunge stack di chiamate JavaScript dettagliati alla traccia delle prestazioni, ma potrebbe rallentare la generazione dei report. La traccia è disponibile in more_vert Menu Strumenti > Visualizza traccia non limitata dopo la generazione del report Lighthouse.
   • Limitazione simulata (impostazione predefinita) . Questa opzione simula le condizioni tipiche di navigazione su un dispositivo mobile. Si chiama "simulata" perché Lighthouse non riduce effettivamente la velocità durante la procedura di controllo. ma estrapola il tempo necessario per il caricamento della pagina in condizioni di utilizzo da dispositivo mobile. L'impostazione Limitazione di DevTools (avanzata), invece, limita effettivamente la CPU e la rete, con il compromesso di un processo di controllo più lungo.
   • Modalità > Navigazione (predefinita). Questa modalità analizza un singolo caricamento di pagina, che è ciò di cui abbiamo bisogno in questo tutorial. Per ulteriori informazioni, vedi Le tre modalità.
   • Dispositivo > Dispositivo mobile. L'opzione Dispositivo mobile modifica la stringa dello user agent e simula un viewport per dispositivi mobili. L'opzione per computer disattiva praticamente le modifiche per il mobile.
   • Categorie > check_box Rendimento. Una singola categoria abilitata consente a Lighthouse di generare un report solo con il set di controlli corrispondente. Puoi lasciare attive le altre categorie se vuoi vedere i tipi di consigli che forniscono. La disattivazione delle categorie non pertinenti velocizza leggermente la procedura di controllo.

3. Fai clic su Analizza caricamento pagina. Dopo 10-30 secondi, il pannello Lighthouse mostra un report sul rendimento del sito.

   

Gestione degli errori dei report

Se ricevi un errore nel report Lighthouse, prova a eseguire la scheda demo da una finestra di navigazione in incognito senza altre schede aperte. In questo modo, hai la certezza di eseguire Chrome da uno stato pulito. In particolare, le estensioni di Chrome possono interferire con la procedura di controllo.

Informazioni sul report

Il numero nella parte superiore del report indica il punteggio del rendimento complessivo del sito. In seguito, man mano che apporti modifiche al codice, dovresti vedere questo numero aumentare. Un punteggio più alto indica un rendimento migliore.

Metriche

Scorri verso il basso fino alla sezione Metriche e fai clic su Espandi visualizzazione. Per leggere la documentazione relativa a una metrica, fai clic su Scopri di più.

Questa sezione fornisce misurazioni quantitative del rendimento del sito. Ogni metrica fornisce informazioni su un aspetto diverso del rendimento. Ad esempio, First Contentful Paint indica quando i contenuti vengono visualizzati per la prima volta sullo schermo, un traguardo importante nella percezione da parte dell'utente del caricamento della pagina, mentre Tempo di interattività indica il punto in cui la pagina sembra essere abbastanza pronta per gestire le interazioni degli utenti.

Screenshot

Di seguito è riportata una raccolta di screenshot che mostrano l'aspetto della pagina durante il caricamento.

Opportunità

Segue la sezione Opportunità, che fornisce suggerimenti specifici su come migliorare il rendimento del caricamento di questa pagina specifica.

Fai clic su un'opportunità per saperne di più.

Fai clic su Scopri di più… per visualizzare la documentazione sul motivo per cui un'opportunità è importante e consigli specifici su come risolvere il problema.

Diagnostica

La sezione Diagnostica fornisce ulteriori informazioni sui fattori che contribuiscono al tempo di caricamento della pagina.

Controlli superati

La sezione Verifiche superate mostra le attività svolte correttamente dal sito. Fai clic per espandere la sezione.

Passaggio 2: esperimento

La sezione Opportunità del report Lighthouse fornisce suggerimenti su come migliorare il rendimento della pagina. In questa sezione, implementi le modifiche consigliate alla base di codice, controllando il sito dopo ogni modifica per misurare l'impatto sulla velocità.

Attiva la compressione del testo

Il report indica che l'attivazione della compressione del testo è una delle principali opportunità per migliorare il rendimento della pagina.

La compressione del testo consiste nel ridurre, o comprimere, le dimensioni di un file di testo prima di inviarlo tramite la rete. È un po' come comprimere una cartella prima di inviarla per email per ridurne le dimensioni.

Prima di attivare la compressione, ecco alcuni modi per verificare manualmente se le risorse di testo sono compresse.

Apri il riquadro Rete e seleziona Impostazioni > Utilizza righe di richiesta di grandi dimensioni.

Punto chiave:se non vedi la colonna Dimensioni nella tabella delle richieste di rete, fai clic con il tasto destro del mouse sull'intestazione della tabella e seleziona Dimensioni.

Ogni cella Dimensione mostra due valori. Il valore superiore corrisponde alle dimensioni della risorsa scaricata. Il valore minimo è la dimensione della risorsa non compressa. Se i due valori sono uguali, la risorsa non viene compressa quando viene inviata sulla rete. In questo esempio, i valori superiore e inferiore per bundle.js sono entrambi 1.4 MB.

Puoi anche verificare la compressione controllando le intestazioni HTTP di una risorsa:

1. Fai clic su bundle.js e apri la scheda Intestazioni.

   

2. Cerca un'intestazione content-encoding nella sezione Intestazioni di risposta. Non dovresti visualizzarne uno, il che significa che bundle.js non è stato compresso. Quando una risorsa è compressa, questa intestazione è solitamente impostata su gzip, deflate o br. Per una spiegazione di questi valori, consulta la sezione Direttive.

Basta con le spiegazioni. È ora di apportare alcune modifiche. Attiva la compressione del testo aggiungendo un paio di righe di codice:

1. Nella scheda dell'editor, apri server.jse aggiungi le due righe (evidenziate) seguenti:

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. Assicurati di inserire app.use(compression()) prima di app.use(express.static('build')).

   

   Nota: in genere, dovresti installare il pacchetto compression tramite un comando come npm i -S compression, ma questa operazione è già stata eseguita per te.

3. Attendi che Glitch implementi la nuova build del sito. Un'emoji felice nell'angolo in basso a sinistra indica che il deployment è andato a buon fine.

Utilizza i flussi di lavoro che hai appreso in precedenza per verificare manualmente che la compressione funzioni:

1. Torna alla scheda della demo e ricarica la pagina.

   La colonna Dimensioni ora dovrebbe mostrare due valori diversi per le risorse di testo come bundle.js. Il valore superiore 269 KB per bundle.js è la dimensione del file inviato sulla rete, mentre il valore inferiore 1.4 MB è la dimensione del file non compresso.

   

2. La sezione Intestazioni di risposta per bundle.js ora deve includere un'intestazione content-encoding: gzip.

   

Esegui di nuovo il report Lighthouse sulla pagina per misurare l'impatto della compressione del testo sul rendimento del caricamento della pagina:

1. Apri il riquadro Lighthouse e fai clic su Esegui un controllo nella barra delle azioni in alto.

   

2. Lascia le impostazioni invariate e fai clic su Analizza il caricamento della pagina.

   

Bene! Sembra che ci siano dei progressi. Il punteggio del rendimento complessivo dovrebbe essere aumentato, il che significa che il sito sta diventando più veloce.

Compressione del testo nel mondo reale

La maggior parte dei server ha soluzioni semplici come questa per attivare la compressione. Basta cercare su come configurare il server che utilizzi per comprimere il testo.

Ridimensionare le immagini

Il nuovo report indica che le dimensioni adeguate delle immagini sono un'altra grande opportunità.

Il ridimensionamento delle immagini consente di velocizzare il tempo di caricamento riducendo le dimensioni dei file. Se l'utente visualizza le tue immagini sullo schermo di un dispositivo mobile largo 500 pixel, non ha senso inviare un'immagine larga 1500 pixel. Idealmente, ti consigliamo di inviare un'immagine larga al massimo 500 pixel.

1. Nel report, fai clic su Usa immagini di dimensioni adeguate per vedere quali immagini devono essere ridimensionate. Sembra che tutte e quattro le immagini siano più grandi del necessario.

   

2. Nella scheda dell'editor, apri src/model.js.

3. Sostituisci const dir = 'big' con const dir = 'small'. Questa directory contiene copie delle stesse immagini con dimensioni diverse.

4. Esegui di nuovo il controllo della pagina per vedere in che modo questa modifica influisce sul rendimento del caricamento.

   

Sembra che la modifica abbia solo un impatto minore sul punteggio del rendimento complessivo. Tuttavia, un aspetto che il punteggio non mostra chiaramente è la quantità di dati di rete che stai risparmiando per i tuoi utenti. Le dimensioni totali delle vecchie foto erano di circa 6,1 MB, mentre ora sono di soli 633 kB. Puoi controllarlo nella barra di stato in fondo al riquadro Rete.

Ridimensionamento delle immagini nel mondo reale

Per un'app di piccole dimensioni, potrebbe essere sufficiente una modifica delle dimensioni una tantum come questa. Tuttavia, per un'app di grandi dimensioni, questa soluzione non è scalabile. Ecco alcune strategie per gestire le immagini nelle app di grandi dimensioni:

• Ridimensiona le immagini durante il processo di compilazione.
• Crea più dimensioni di ogni immagine durante il processo di compilazione e poi utilizza srcset nel codice. Durante l'esecuzione, il browser si occupa di scegliere le dimensioni più adatte al dispositivo su cui è in esecuzione. Consulta la sezione Immagini con dimensioni relative.
• Utilizza una CDN di immagini che ti consenta di ridimensionare dinamicamente un'immagine quando la richiedi.
• Come minimo, ottimizza ogni immagine. Spesso questo può comportare risparmi enormi. L'ottimizzazione consiste nell'eseguire un'immagine tramite un programma speciale che riduce le dimensioni del file immagine. Per ulteriori suggerimenti, consulta la sezione Ottimizzazione obbligatoria delle immagini.

Elimina le risorse che bloccano la visualizzazione

Il tuo ultimo report indica che l'eliminazione delle risorse che bloccano il rendering è ora la più grande opportunità.

Una risorsa che blocca la visualizzazione è un file JavaScript o CSS esterno che il browser deve scaricare, analizzare ed eseguire prima di poter mostrare la pagina. L'obiettivo è eseguire solo il codice CSS e JavaScript di base necessario per visualizzare correttamente la pagina.

La prima operazione, quindi, consiste nel trovare il codice che non deve essere eseguito al caricamento della pagina.

1. Fai clic su Elimina le risorse di blocco della visualizzazione per visualizzare le risorse che stanno bloccando: lodash.js e jquery.js.

   

2. A seconda del sistema operativo, premi quanto segue per aprire il menu dei comandi:

   • Su Mac, Comando+Maiusc+P
   • Su Windows, Linux o ChromeOS, Ctrl+Maiusc+P

3. Inizia a digitare Coverage e seleziona Mostra copertura.

   

   Nel riquadro di navigazione si apre la scheda Copertura.

   

4. Fai clic su Aggiorna Ricarica. La scheda Copertura fornisce una panoramica della quantità di codice in bundle.js, jquery.js e lodash.js che viene eseguita durante il caricamento della pagina.

   

   Questo screenshot indica che circa il 74% e il 30% dei file jQuery e Lodash non vengono utilizzati, rispettivamente.

5. Fai clic sulla riga jquery.js. DevTools apre il file nel riquadro Origini. Una riga di codice è stata eseguita se accanto è presente una barra verde. Una barra rossa accanto a una riga di codice indica che non è stata eseguita e non è necessaria al caricamento della pagina.

   

6. Scorri un po' il codice jQuery. Alcune delle righe che vengono "eseguite" sono in realtà solo commenti. Eseguire questo codice tramite un programma di minificazione che rimuove i commenti è un altro modo per ridurre le dimensioni del file.

In breve, quando lavori con il tuo codice, la scheda Copertura può aiutarti ad analizzarlo riga per riga e a inviare solo il codice necessario per il caricamento della pagina.

I file jquery.js e lodash.js sono necessari per caricare la pagina? La scheda Blocco richieste può mostrarti cosa succede quando le risorse non sono disponibili.

1. Fai clic sulla scheda Rete e apri di nuovo il menu di comando.

2. Inizia a digitare blocking e poi seleziona Mostra blocco richieste. Si apre la scheda Blocco richieste.

   

3. Fai clic su Aggiungi pattern, digita /libs/* nella casella di testo e premi Invio per confermare.

   

4. Ricarica la pagina. Le richieste jQuery e Lodash sono rosse, il che significa che sono state bloccate. La pagina si carica ancora ed è interattiva, quindi sembra che queste risorse non siano necessarie.

   

5. Fai clic su Rimuovi tutti i pattern per eliminare il pattern di blocco /libs/*.

In generale, la scheda Blocco richieste è utile per simulare il comportamento della pagina quando una determinata risorsa non è disponibile.

Ora rimuovi i riferimenti a questi file dal codice e controlla di nuovo la pagina:

1. Nella scheda dell'editor, apri template.html.

2. Elimina i tag <script> corrispondenti:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. Attendi il ricoinvolgimento e il nuovo deployment del sito.

4. Controlla di nuovo la pagina dal riquadro Lighthouse. Il tuo punteggio complessivo dovrebbe essere migliorato di nuovo.

   

Ottimizzazione del percorso di rendering critico nel mondo reale

Il percorso di rendering critico si riferisce al codice necessario per caricare una pagina. In generale, puoi accelerare il caricamento della pagina inviando solo il codice critico durante il caricamento e poi caricando dinamicamente tutto il resto.

• È improbabile che tu trovi script che puoi rimuovere direttamente, ma spesso scoprirai che molti script non devono essere richiesti durante il caricamento della pagina e possono invece essere richiesti in modo asincrono. Vedi Utilizzare async o defer.
• Se utilizzi un framework, controlla se ha una modalità di produzione. Questa modalità potrebbe utilizzare una funzionalità come il tree shaking per eliminare il codice non necessario che blocca il rendering critico.

Riduci il lavoro del thread principale

Il tuo ultimo report mostra alcuni potenziali risparmi minori nella sezione Opportunità, ma se scorri verso il basso fino alla sezione Diagnostica, sembra che il principale collo di bottiglia sia un'attività eccessiva del thread principale.

Nel thread principale il browser esegue la maggior parte del lavoro necessario per visualizzare una pagina, ad esempio l'analisi sintattica e l'esecuzione di HTML, CSS e JavaScript.

Nota: questa sezione fornisce una breve introduzione al riquadro Rendimento. Consulta il riferimento alle funzionalità di rendimento per scoprire di più su come utilizzarle per analizzare il rendimento delle pagine.

L'obiettivo è utilizzare il riquadro Rendimento per analizzare il lavoro svolto dal thread principale durante il caricamento della pagina e trovare modi per posticipare o rimuovere il lavoro non necessario.

1. Apri Rendimento > Impostazioni di acquisizione e imposta Rete su 3G lento e CPU su Rallentamento 6x.

   

   I dispositivi mobili in genere hanno più vincoli hardware rispetto ai laptop o ai computer, quindi queste impostazioni ti consentono di testare il caricamento della pagina come se stessi utilizzando un dispositivo meno potente.

2. Fai clic su Aggiorna Ricarica. DevTools ricarica la pagina e poi produce una visualizzazione di tutto ciò che doveva fare per caricarla. Questa visualizzazione verrà indicata come traccia.

   

La traccia mostra l'attività in ordine cronologico, da sinistra a destra. I grafici FPS, CPU e NET in alto forniscono una panoramica dei frame per secondo, dell'attività della CPU e dell'attività di rete.

La barra gialla visualizzata nella sezione Panoramica indica che la CPU era completamente occupata dall'attività di scripting. Questo è un indizio che potrebbe indicare che puoi velocizzare il caricamento della pagina riducendo il lavoro in JavaScript.

Esamina la traccia per trovare modi per ridurre il lavoro di JavaScript:

1. Fai clic sulla sezione Orari per espanderla.

   

   Ci sono diverse misurazioni di Tempi dell'utente di React. Sembra che l'app di Tony utilizzi la modalità di sviluppo di React. Il passaggio alla modalità di produzione di React probabilmente produrrà alcuni facili miglioramenti delle prestazioni.

2. Fai di nuovo clic su Tempi per comprimere la sezione.

3. Sfoglia la sezione Principale. Questa sezione mostra un log cronologico dell'attività del thread principale, da sinistra a destra. L'asse Y (dall'alto verso il basso) mostra il motivo per cui si sono verificati gli eventi.

   

   In questo esempio, l'evento Evaluate Script ha causato l'esecuzione della funzione (anonymous), che ha causato l'esecuzione di __webpack__require__, che ha causato l'esecuzione di ./src/index.jsx e così via.

4. Scorri verso il basso fino alla fine della sezione Principale. Quando utilizzi un framework, gran parte dell'attività superiore è causata dal framework, che in genere non è sotto il tuo controllo. L'attività causata dalla tua app si trova in genere in basso.

   

   In questa app, sembra che una funzione chiamata App stia causando molte chiamate a una funzione mineBitcoin. Sembra che Tony stia usando i dispositivi dei suoi fan per fare il mining di criptovaluta…

   Nota: anche se le chiamate effettuate dal framework non sono in genere sotto il tuo controllo, a volte potresti strutturare l'app in modo che il framework funzioni in modo inefficiente. La ristrutturazione dell'app per utilizzare il framework in modo efficiente può essere un modo per ridurre il lavoro del thread principale. Ciò richiede una conoscenza approfondita del funzionamento del framework e del tipo di modifiche che puoi apportare al tuo codice per utilizzarlo in modo più efficiente.

5. Apri la scheda Dal basso verso l'alto in basso. Questa scheda suddivide le attività che hanno richiesto più tempo. Se non vedi nulla nella sezione Dal basso verso l'alto, fai clic sull'etichetta della sezione Principale.

   

   La sezione Dal basso verso l'alto mostra solo le informazioni relative all'attività o al gruppo di attività attualmente selezionato. Ad esempio, se hai fatto clic su una delle attività mineBitcoin, la sezione Dal basso verso l'alto mostrerà solo le informazioni relative a quell'attività.

   La colonna Tempo personale indica il tempo trascorso direttamente in ogni attività. In questo caso, circa l'82% del tempo del thread principale è stato speso per la funzione mineBitcoin.

È arrivato il momento di verificare se l'utilizzo della modalità di produzione e la riduzione dell'attività JavaScript accelerano il caricamento della pagina. Inizia con la modalità di produzione:

1. Nella scheda dell'editor, apri webpack.config.js.
2. "mode":"development" modificato in "mode":"production".
3. Attendi il deployment della nuova build.

4. Esegui di nuovo la verifica della pagina.

   

Riduci l'attività JavaScript rimuovendo la chiamata a mineBitcoin:

1. Nella scheda dell'editor, apri src/App.jsx.
2. Commenta la chiamata a this.mineBitcoin(1500) in constructor.
3. Attendi il deployment della nuova build.
4. Esegui di nuovo la verifica della pagina.

Come sempre, ci sono ancora cose da fare, ad esempio ridurre le metriche Largest Contentful Paint e Cumulative Layout Shift.

Risultato: ma sembra che l'ultima modifica abbia causato un enorme aumento del rendimento.

Ridurre il lavoro del thread principale nel mondo reale

In generale, il riquadro Rendimento è il modo più comune per capire quali attività vengono eseguite dal tuo sito durante il caricamento e trovare modi per rimuovere le attività non necessarie.

Se preferisci un approccio più simile a console.log(), l'API User Timing ti consente di contrassegnare arbitrariamente determinate fasi del ciclo di vita dell'app per monitorare la durata di ciascuna di queste fasi.

Riepilogo

• Quando vuoi ottimizzare il rendimento del caricamento di un sito, inizia sempre con un audit. Il controllo stabilisce una linea di base e fornisce suggerimenti su come migliorare.
• Apporta una modifica alla volta e controlla la pagina dopo ogni modifica per vedere come questa modifica isolata influisce sul rendimento.

Passaggi successivi

Esegui audit sul tuo sito. Se hai bisogno di aiuto per interpretare il report o per trovare modi per migliorare le prestazioni di caricamento, consulta tutti i modi per ricevere assistenza dalla community di DevTools:

• Segnala i bug relativi a questo documento nel repository developer.chrome.com.
• Invia segnalazioni di bug su DevTools alla pagina Bug di Chromium.
• Discutere di funzionalità e modifiche nella mailing list. Non utilizzare la mailing list per domande sull'assistenza. Utilizza invece Stack Overflow.
• Puoi trovare assistenza generale su come utilizzare DevTools su Stack Overflow. Per inviare richieste di bug, utilizza sempre Chromium Bugs.
• Inviaci un tweet all'indirizzo @ChromeDevTools.