Come si misura la velocità di un sito web?

Oggi voglio parlarti di come misurare la velocità di un sito web.

Partiamo da un presupposto: misurare l’esperienza utente che offre il nostro sito è fondamentale se vogliamo metterci le mani.

Perché? 

Semplicemente perché, come diceva Galileo Galilei, ciò che non è misurabile non è migliorabile.

Quindi prima di preoccuparci di come intervenire sull’ottimizzazione del nostro sito, cerchiamo di capire quali metriche sono più importanti quando parliamo di Web Performance. 

Quali sono le metriche da misurare quando andiamo a fare un’analisi delle web performance?

Esistono decine di metriche utilizzabili per misurare le performance di un sito, ma le più significative sono quelle che permettono di misurare in maniera più accurata l’esperienza dell’utente nel sito.

Non bisogna quindi limitarsi alle metriche fornite dagli strumenti ma bisogna anche utilizzare quelle che possono descrivere meglio l’esperienza dell’utente sul sito.

Se analizziamo il ciclo di vita di una pagina web, dal momento in cui viene scaricata sul dispositivo al momento in cui viene consumata, possiamo identificare 3 momenti significativi:

1. Download della pagina (la pagina è appena stata scaricata ed è ancora bianca)
2. Render della pagina (la pagina viene disegnata a schermo)
3. La pagina è pronta per essere utilizzata

Durante questo processo, l’utente si porrà delle domande e la risposta a tali domande determinerà l’esperienza dell’utente sul sito:

1. Sta succedendo qualcosa? Si sta caricando qualcosa sulla pagina?
2. Quello che sto vedendo è utile?
3. Quello che sto vedendo e che ho sullo schermo è usabile?
4. Quello che vedo sullo schermo è piacevole e facilmente fruibile?

Per ognuna di queste 4 domande Google ha identificato una o più metriche che corrispondono a una momento ben specifico del ciclo di vita della pagina web.

Rappresentazione dei tempi di caricamento, delle varie fasi di caricamento di una pagina.

Le metriche identificate da Google sono 6 e sono le stesse utilizzate per calcolare il punteggio di google Lighthouse.

Andiamo ora a vedere nel dettaglio queste metriche.

FIRST CONTENTFUL PAINT (FCP)

Questo si chiama First Contentful Paint perché è il primo contenuto che inizia a disegnare qualcosa di utile, che fa capire all’utente che sulla pagina sta succedendo qualcosa.

Risponde alle domanda: sta succedendo qualcosa? Si sta caricando qualcosa sulla pagina?

LARGEST CONTENTFUL PAINT (LCP)

Largest Contentful Paint, quindi è l’elemento più grande che viene mostrato sulla pagina nella parte “Above The Fold”, perché è importante ricordarsi sempre che fa fede ciò che vedo nello schermo senza fare lo scroll.

Risponde alle domanda: quello che sto vedendo è utile?

SPEED INDEX (SI)

Misura il tempo necessario a mostrare il 90% del contenuto visibile della pagina.

Quando la pagina è visibile per il 90%, l’utente ha visto praticamente tutto e quindi ha esattamente la percezione che la pagina si sta caricando correttamente.

Risponde alla domanda: è utile ciò che sto vedendo?

FCP, LCP e SI misurano quindi quanto velocemente avviene il render, ovvero quanto velocemente la pagina viene disegnata a video.

TIME TO INTERACTIVE (TTI)

Il Time To Interactive misura il tempo necessario alla pagina per essere pronta a rispondere agli input dell’utente.

La pagina è considerata “pronta” quando il processo principale del browser (il main thread) è rimasto a riposo per almeno 5 secondi. 

In pratica se l’utente clicca sul bottone quel bottone fa qualcosa.

Risponde alla domanda: quello che sto vedendo sullo schermo è usabile?

TOTAL BLOCKING TIME (TBT)

Il Total blocking Time è la somma del tempo in cui il processo principale del browser (main thread) è occupato per più di 50ms.

Quando il browser è occupato non può rispondere all’input dell’utente.

Risponde alla stessa domanda del Time To Interactive: quello che sto vedendo sullo schermo è usabile?

CUMULATIVE LAYOUT SHIFT (CLS)

Il cumulative layout shift misura la percentuale di spostamento degli elementi visibili nell’area visibile sullo schermo della pagina.

Quando gli elementi si spostano nella pagina, l’utente vive un’esperienza non ottimale in quanto potrebbe non riuscire a leggere i contenuti presenti oppure potrebbe non riuscire a cliccare sul bottone che aveva scelto.

Risponde alla domanda: quello che vedo sullo schermo è piacevole e facilmente fruibile?

L’ultima metrica di cui voglio parlarti è il First Input Delay che pur non facendo parte di Lighthouse è una metrica molto importante.

FIRST INPUT DELAY (FID)

Il first input delay misura il tempo necessario al browser per rispondere all’input dell’utente.

Si differenzia dal Time To Interactive perché la sua misurazione parte in seguito all’input dell’utente. Quindi se gli utenti non dovessero mai cliccare/interagire sulla pagina in alcun modo, il FID sarebbe uguale a 0. 

Il motivo per cui il FID non fa parte delle metriche di Google Lighthouse è presto detto: Lighthouse non può cliccare da solo sugli elementi della pagina o meglio non saprebbe come simulare il comportamento dell’utente (non saprebbe dove cliccare e quando).

Ora che conosci le metriche principali utilizzate per misurare l’esperienza dell’utente sul sito posso parlarti dei Core Web Vitals, che possiamo considerare un’evoluzione di queste metriche.

Cosa sono i Core Web Vitals

I Core Web Vitals sono il tentativo da parte di Google di misurare l’esperienza dell’utente attraverso 3 metriche: Largest Contentful Paint, Cumulative Layout Shift e First Input Delay (FID).

La differenza sostanziale rispetto alle metriche di cui ti ho parlato poco fa è che i Core Web Vitals sono estratti da browser reali di utenti Chrome (compresi Android, Edge, Opera) e quindi rappresentano in maniera più veritiera l’esperienza di navigazione degli utenti sul tuo sito.

Non rappresentano la verità assoluta in quanto non rappresentano il 100% dei visitatori del sito (ad esempio Firefox e Safari non inviano dati a Google), in più non sono in tempo reale e sono disponibili solo se il sito riceve abbastanza traffico per tutto il mese.

Se vuoi approfondire i Core Web Vitals, cosa sono e cosa scarica il cheatsheet oppure richiedi gratuitamente il link per il webinar che ho realizzato sui Core Web Vitals.

Cosa fare una volta che abbiamo raccolto i dati?

La raccolta dei dati non è un’operazione una tantum, dal momento che possono variare nel tempo. Per questo motivo bisogna raccogliere e monitorare costantemente i dati e prendere decisioni basate sui dati.

Ogni metrica racconta un pezzo di verità sull’esperienza degli utenti nel sito e permette di identificare eventuali problemi di performance.

Una volta identificato il problema bisogna inoltre essere in grado di intervenire applicando la soluzione specifica, senza compromettere gli altri parametri. Se ad esempio implementi il lazy load per migliorare il tempo di caricamento della pagina ma non lo fai nella maniera corretta, rischi di peggiorare il cumulative layout shift e il largest contentful paint .

Ottimizzare le web performance di un sito è una vera e propria partita a scacchi contro il browser, e può diventare un’esperienza veramente frustrante se non sai come affrontarla.

Sono aperte le iscrizioni alla terza edizione del workshop “Ottimizzare siti fa schifo… se non sai come farlo”

il primo workshop italiano incentrato sul miglioramento delle web performance per rendere i siti a prova di Core Web Vitals.

Trovi tutte le informazioni cliccando sul bottone qui sotto:

Voglio saperne di più