Cosa sono i Core Web Vitals e come si ottimizzano

I Core Web Vitals aiutano a quantificare l’esperienza del sito web e permettono di individuare nuove opportunità di miglioramento.

Sono un’iniziativa promossa da Google per poter fornire dei segnali qualitativi che vadano a valutare la user experience.

Nel tempo Google stessa ha fornito moltissimi tool per misurare le performance di un sito web, ma per poter andare incontro anche alle esigenze dei meno tecnici, ha voluto semplificare l’accesso a queste informazioni rimuovendo quella che potenzialmente potrebbe essere una barriera, come ad esempio l’elevata competenza tecnica necessaria per comprendere un report sulle performance (più avanti nei includiamo un pezzettino).

Per quanto di metriche nei Web Vitals ce ne siano parecchie, ne esistono alcune, i Core Web Vitals, che servono proprio a comprendere al volo la situazione di un sito web, senza entrare troppo nel dettaglio con ulteriori analisi.

Cosa sono i Core Web Vitals?

Come menzionato in precedenza i Core Web Vitals sono un sottoinsieme dei più estesi Web Vitals. Ogni Core Web Vitals rappresenta una elemento distinto della user experience, è misurabile sul campo e riflette un’esperienza reale.

Come Google stessa afferma, i Core Web Vitals non rimarranno sempre gli stessi, ma si evolveranno nel tempo. Ad oggi però i tre aspetti sulla quale la User Exprience si basa sono:

• Caricamento: con il Largest Contentful Paint (LCP) si misurano le performance di caricamento. Per considerare buona questa metrica il valore registrato deve essere inferiore ai 2.5 secondi. Viene considerato pessimo oltre i 4 secondi.
• Interattività: con il First Input Delay (FID) si misura l’interattività. Per fornire una buona user experience le pagine dovrebbero registrare un FID al di sotto dei 100 ms. Oltre i 300 ms la metrica è considerata negativa.
• Stabilità visuale: con il Cumulative Layout Shift (CLS) si misura la stabilità visuale. Un valore ottimale deve rimanere sotto lo 0.1. Oltre il 2.5 viene considerata negativa.

Ok, se fin qui ho parlato aramaico, non ti preoccupare, andrò nel dettaglio dei singoli Core Web Vitals tra pochissimo.

Come si misurano i Core Web Vitals?

Google crede fermamente che i Core Web Vitals siano critici per tutte le esperienze web. Per questo motivo tutti i suoi tool principali li riportano. Per poter calcolare LCP, FID e CLS puoi quindi avvalerti di diversi strumenti come:

• Chrome User Experience Report: rapporto basato sull’esperienza degli utenti di Chrome che misura quindi dati reali attraverso le loro azioni quotidiane nella navigazione di tutti i giorni. Il progetto è fornito come progetto pubblico su Google BigQuery. Per saperne di più puoi visitare la documentazione ufficiale di Google.
• PageSpeed Insights: forse il tool più conosciuto. Basta inserire nell’apposita barra l’URL del sito web che si vuole controllare ed entro qualche secondo ti verrà restituito un rapporto completo sullo stato delle performance, comprensivo dei Core Web Vitals.
• Search Console: mette a disposizione un rapporto verticale sullo stato dei Core Web Vitals. Il rapporto, denominato Metriche Essenziali sotto la sezione Esperienza, mostra quali pagine registrano valori ottimali, migliorabili e pessimi. Come sempre Search Console è un tool di cui difficilmente si può fare a meno.

Altri modi per misurare i Core Web Vitals

Se non ti bastano i tre tool offerti da Google, in Web Tea usiamo anche Screaming Frog con l’integrazione alle API di PageSpeed attiva. Avviando la scansione avremo nel giro di qualche minuto un rapporto dettagliato sullo stato dei Core Web Vitals per ogni pagina del sito web. Se anche tu, usi Screaming Frog, ti consigliamo di seguire questa guida a riguardo.

Se invece sei un nerd di prima categoria, come lo sono io, allora ti interesserà sapere che il team di Google Chrome ha messo a disposizione la repository web-vitals, una libreria JavaScript che consiste in un wrapper già pronto per la produzione che sfrutta le web APIs per misurare ogni metrica accuratamente. Potrai quindi mandare le metriche direttamente ad Analytics o ad una dashboard personalizzata, a te la scelta. Ti lascio qui di seguito il link alla repo di Google Chrome.

Sempre per i nerd ricordo che i Core Web Vitals possono essere misurati anche attraverso l’uso di Chrome DevTools e Lighthouse (lo stesso di Chrome DevTools, ma che ricordo essere disponibile in versione: CLI e modulo Node). In merito all’uso di questi tool i dati prodotti sono da considerare come dati di laboratorio e non come presi direttamente sul campo.

L’impiego di Chrome DevTools, ad esempio, è perfetto per misurare le performance durante la fase di sviluppo.

Tra le altre cose il FID non è disponibile in questo tipo di misurazione, in questo caso è consigliabile usare il TBT (Total Blocking Time) il quale calcola il tempo passato tra l’evento di FCP (First Contentful Paint) e TTI (Time To Interactive).

Cos’è il Largest Contenful Paint?

Come già anticipato il Largest Contenful Paint è una metrica che misura il caricamento, più precisamente la velocità di caricamento percepito. Più precisamente ancora LCP misura il tempo di rendering dell’immagine o blocco di testo visibile nel viewport, relativo a quando la pagina inizia il caricamento.

Tradotto significa che LCP è il tempo necessario dall’elemento di testo o immagine più grande e visibile in pagina per essere completamente visibile. Solitamento questo corrisponde ad un logo, ad una slider o al titolo di un contenuto.

Quanto deve essere il valore di LCP per essere considerato buono?

Per fornire una buona user experience il Largest Contentful Paint deve essere inferiore ai 2.5 secondi.

Per determinare questo punteggio vengono presi in considerazione i seguenti elementi:

• <img>
• <image> dentro un SVG
• <video> viene considerata l’immagine usata come poster e non il video in se
• Un elemento con un’immagine di sfondo caricata via url()
• Elementi che contengono nodi di testo

Vediamo un esempio di come il Largest Contenful Paint viene calcolato:

Dal DevTools di Google Chrome si può vedere quando si verifica il LCP. Nello screenshot qui sopra, possiamo vedere che l’evento si verifica a 982.4ms e il nodo ad essere considerato come “il più grande” in pagina è un elemento image, nello specifico, questo:

Bisogna tenere da conto che l’elemento più grande in pagina potrebbe cambiare nel tempo. Come nell’esempio che segue:

Il rettangolo verde indica l’elemento più grande in pagina e da come si può notare mano a mano che la pagina carica l’elemento in questione cambia. Ci sono casi in cui questo non succede perché magari l’elemento rimane sempre il più grande, come nell’esempio qui sotto.

Come si ottimizza il Largest Contentful Paint?

Arrivati a questo punto è normale chiedersi, come posso ottimizzare il LCP? Per capire cosa fare, dobbiamo ancora capire cosa lo influenza. I fattori sono quattro:

• Risposta del server lenta
• JavaScript o CSS bloccanti
• Tempo di caricamento delle risorse
• Rendering client-side

A questo punto le tecniche per poter ottimizzare il Largest Contentful Paint sono chiare:

• Caricamento instantaneo con il pattern PRPL: acronimo che sta per Preload delle risorse più importanti, Render della rotta principale il prima possibile, Pre-cache degli assets rimanenti, Lazy load delle altre rotte e degli assets non critici.
• Ottimizzare il Critical Rendering Path: si riferisce all’attività di prioritizzare la visualizzazione del contenuto correlato all’azione dell’utente.
• Ottimizzare il CSS: caricare in un secondo momento il CSS non critico, minificazione, critical CSS e ottimizzazione delle immagini di sfondo con l’uso di media queries.
• Ottimizzare le immagini: uso di un formato corretto, compressione, responsive, dimensioni corrette, uso di una CDN.
• Ottimizzare i web fonts: evitare testo invisibile durante il caricamento del font, ottimizzare i web font, ridurre la dimensione dei WebFont
• Ottimizzare il JavaScript (per i siti renderizzati client-side): ridurre il payload con il code splitting, rimuovere codice inutilizzato, minificare e comprimere, usare codice moderno per browser moderni

Pss! Se tutto questo è aramaico puoi sempre contattarci 🙂

Cos’è il First Input Delay?

Per quanto sia importantissimo sapere quanto tempo ci impiegano i pixel ad essere dipinti, ugualmente importante è la velocità con la quale questi pixel diventano interattivi.

Il First Input Delay è una metrica che aiuta a misurare la responsività (inteso come risposta da parte della User Interface) e interattività.

Più tecnicamente il FID misura il tempo tra la prima interazione dell’utente con la pagina (es. quando cliccano su un link, un bottone o un controllo gestito con JavaScript) al momento in cui il browser è effettivamente pronto a gestire tale evento.

Quanto deve essere il valore di FID per essere considerato buono?

100 millisecondi o meno. Questa è il tempo che deve essere registrato per poter considerare il First Input Delay come buono. Oltre i 300 ms qualcosa è veramente messo male e deve essere rivisto.

Per capire a pieno il First Input Delay bisogna capire da che cosa è dipesa questa latenza. Il browser ha un main thread che esegue svariate operazioni durante il ciclo di vita della pagina web. Se questo thread è occupato, non può certamente rispondere all’input dell’utente.

L’essere occupato può dipendere dal fatto che il browser potrebbe essere impegnato a fare il parsing o eseguendo un grosso file JavaScript. Mentre fa questo non può eseguire altri event listener.

Teniamo da conto inoltre che anche interazioni senza event listener sono tenute in considerazione, come l’uso di input, checkbox, bottoni, radio button, menu a tendina e link. Queste azioni non useranno un event listener, ma necessitano del main thread per funzionare.

Come si ottimizza il First Input Delay?

Per migliorare il First Input Delay si possono seguire le medesime operazioni usate per migliorare il TBT (Total Blocking Time).

Alcune delle attività più impattanti sono:

• Riduzione dell’impatto di codice di terze parti
• Riduzione del tempo di esecuzione di JavaScript
• Minimizzare il lavoro del main thread
• Mantenere un numero basso di richieste e le dimensioni di trasferimento contenute.

Cos’è il Cumulative Layout Shift?

Il CLS è una metrica che misura la stabilità visuale. In particolar modo quantifica gli spostamenti inattesi del layout. Ok, non è chiarissimo detta così. Vediamo di fare un esempio.

Supponiamo che tu abbia appena iniziato a leggere un articolo molto interessante, sei immerso nella lettura, quando di punto in bianco, BAM, un banner pubblicatario carica in ritardo e ti sposta il contenuto verso il basso, perdi il segno, ti infastidisci perché devi scorrere per riprendere a leggere.

Il Cumulative Layout Shift calcola proprio questo spostamento inatteso e ci bacchetta se questo valore fosse troppo elevato.

La colpa comunque non è solo dei banner pubblicitari, ma potrebbe essere tranquillamente delle risorse caricate in asincrono, elementi aggiunti alla pagina web dinamicamente, video o immagini di dimensioni sconosciute, font, widget che si ridimensionano in autonomia e chi più ne ha più ne metta.

Quanto deve essere il valore del CLS per essere considerato buono?

Il CLS deve essere inferiore a 0.1. Oltre i 2.5 è considerato pessimo. Questo numero però non è espresso in millisecondi, secondi o pixel. Come viene calcolato esattamente? Il ragionamento dietro è abbastanza semplice, bisogna fare solo un calcolo.

layout shift = frazione d'impatto * distanza d'impatto

Per la frazione d’impatto bisogna calcolare quanto spazio occupava e occupa l’elemento instabile

Nel primo frame dell’immagine qui sopra l’elemento prende il 50% dell’altezza della parte visibile dello schermo, successivamente si sposta verso il basso del 25%. L’unione quindi della sua dimensione originale e di quella a spostamento avvenuto è pari al 75%. Possiamo determinare quindi che la frazione d’impatto è 0.75.

La frazione di distanza è la distanza più elevata per cui l’elemento si è mosso. Prima abbiamo detto che l’elemento si è spostato del 25% del viewport. Questo quindi significa che la frazione di distanza è di 0.25.

Mettendo insieme i numeri otterremo quindi:

0.75 * 0.25 = 0.1875

Se invece lo spostamento fosse atteso? I layout shift che si verificano entro 500 millisecondi da un input dell’utente hanno il flag hadRecentInput impostato e quindi non viene calcolato.

Come si ottimizza il Cumulative Layout Shift?

Tra i tre Web Vitals forse è la più semplice da ottimizzare. Per poter evitare quanto più possibile i Layout Shift ricorda sempre di:

• Includere sempre larghezza e altezza agli elementi come immagini e video. In alternativa puoi riservare lo spazio necessario usando proprietà CSS specifiche. In questo modo il browser allocherà lo spazio necessario ancor prima che l’immagine o il video vengano effettivamente caricati.
• Mai inserire contenuto sempre il contenuto esistente, a meno che non sia in seguito all’input di un utente.
• Prediligere animazioni attraverso l’uso di transform piuttosto che con le singole proprietà CSS come height, width, top, left, right, bottom.

Parti sempre da un’analisi

Se il tuo sito soffre in performance, forse è il caso di fare una bella analisi e capire qual è la causa. Noi possiamo aiutarti. Dai un’occhiata al nostro servizio di miglioramento performance e se sei interessato a fare due chiacchiere contattaci. Il tè lo offriamo noi 🙂

Crediti immagine: David Clode