Core Web Vitals: cosa sono e come ottimizzarli

Non è un segreto ormai che Google sia sempre più attento a facilitare l’esperienza di navigazione degli utenti privilegiando siti più usabili e veloci.

I Core Web Vitals, introdotti per la prima volta nel 2020 rappresentano il primo importante tentativo da parte di Google di assegnare un “punteggio” all’esperienza utente offerta da un sito.

Ecco perché se possiedi o gestisci un ecommerce non puoi non conoscere queste metriche, ritenute essenziali per garantire una buona esperienza di acquisto ai tuoi utenti.

In particolare sono tre le variabili prese in considerazione per valutare l’esperienza d’uso:

• la Velocità di caricamento (a cui è associato il LCP)
  
• la Reattività della pagina (a cui è associato il FID) 
  
• la Stabilità Visuale degli elementi (a cui è associato il CLS)
  

NB: Nel momento in cui scriviamo, i Core Web Vitals sono tre, ma in futuro potrebbero diventare molti di più.

Infatti, mano a mano che raccoglie dati, Google capisce sempre meglio come poter misurare l’esperienza utente e aggiustare il suo algoritmo.

Vediamoli insieme uno ad uno.

Largest Contentful Paint (LCP)

Il LCP misura il tempo necessario a mostrare l’elemento più grande presente nel viewport, ovvero l’area subito visibile a schermo (che per ovvi motivi cambia da schermo a schermo).
L’elemento più grande può essere un’immagine, un video o un elemento di tipo “blocco” contenente del testo.

Come funziona il LCP

Nell’immagine è possibile vedere come Google identifica l’elemento più grande in pagina:
mano a mano che il browser carica gli elementi dell’above the fold, identifica l’elemento “largest”. Il LCP è dato dalla misura del tempo necessario al browser per mostrare l’immagine arancione.

Come ottimizzare il LCP

Il Largest Contentful Paint ha 3 soglie, come tutti gli altri Core Web Vitals: buono, necessita di miglioramento o scarso.

Per avere un punteggio verde per il Largest Contentful Paint è necessario che l’elemento più grande dello schermo compaia in meno di 2,5 secondi.

Considera che il viewport (l’area visibile) non è uguale per tutti, ma dipende dal dispositivo che stanno utilizzando i visitatori.

Per cui, se, ad esempio gran parte dei tuoi visitatori naviga da desktop con un monitor full-HD, il Largest Contentful Paint farà riferimento all’elemento più grande che compare nella risoluzione full-HD.

Al contrario, se la maggior parte degli utenti navigano da mobile, il Largest Contentful Paint a cui fare riferimento sarà quello della risoluzione mobile.

Il Largest Contentful Paint è impattato da tutto ciò che rallenta la visualizzazione di questo elemento.

Quindi:

• è importante diminuire il Time To First Byte (TTFB) il prima possibile, ad esempio abilitando la full page cache sul server, oltre ad avere un server performante;
• diminuisci il peso della pagina, perché meno dati scarico, più velocemente li scarico;
• eilmina le risorse bloccanti, quindi tutto ciò che c’è nell’header che non serve lo sposto nel body, in modo che diventi non bloccante;
• utilizza le server push. Attraverso le server push io posso bypassare il normale comportamento del browser. Per cui, il browser normalmente scarica le risorse nell’ordine in cui le trova tramite l’HTML. Attraverso le server push, io posso istruire il browser per dirgli: “Guarda, scarica prima questa specifica immagine”, che sarà, ovviamente, l’immagine che fa parte del Largest Contentful Paint;
• quando non è possibile utilizzare le server push, utilizza il preload delle risorse. Utilizzando la direttiva link e preload, io sto dicendo al browser: “Guarda, questa risorsa a breve mi servirà, quindi scaricala subito”.
• un’altra best practice che si può utilizzare è l’inline di immagini.
• è possibile, allo stesso modo, fare il preload dei font;
• utilizza il font-display: swap, invece del font-display: block, in modo da far sì che il testo della pagina sia immediatamente visibile. Se non imposto il font-display: swap, il browser che non ha scaricato il font non mi mostra alcun testo, quindi continuerei a vedere la pagina bianca. Questo significa che se io ho un blocco di testo ed è il mio blocco di testo a rappresentare il mio Largest Contentful Paint, mi sto dando la zappa sui piedi da solo.

First Input Delay

Misura l’interattività della pagina, ovvero il tempo impiegato dal browser per rispondere all’input dell’utente. In altre parole è il tempo che passa dal momento in cui l’utente clicca al momento in cui il browser riceve il comando.

Il dato da tenere in considerazione a proposito del FID è che non è simulabile attraverso tools come Page Speed Insight o Google Lighthouse.

Dal momento che non tutti gli utenti interagiscono nello stesso istante, e che l’interazione varia da sito a sito, non c’è strumento in grado di simulare in maniera attendibile questo comportamento.

Quando il FID per il tuo sito non è disponibile puoi utilizzare una metrica “simile” che è il Total Blocking Time (TBT). L’obiettivo, indipendentemente dalla metrica utilizzata, è quello di rientrare nella soglia di valori ritenuta “buona”.

Come ottimizzare il FID

Il First Input Delay è molto sensibile al JavaScript, perché abbiamo detto che il First Input Delay parte quando il main thread è a riposo. Il main thread è a riposo quando non sta disegnando una pagina e non sta processando i JavaScript. Per cui:

• rimuovi il codice JavaScript inutilizzato, perché comunque, anche se non viene utilizzato, viene comunque parsato, interpretato;
• riduci il tempo utilizzato dai JavaScript;
• riduciamo al minimo i JavaScript;
• una volta completata quest’opera di pulizia, aggiungi gli attributi defer e/o async agli script restanti. L’attributo defer, applicati i JavaScript, posticipa l’esecuzione del JavaScript. Quindi, può essere utile perché il browser effettua l’header della pagina più velocemente, però poi in defer stai solo spostando il problema un po’ dopo, quindi dopo il load.

Cumulative Layout Shift 

Il CLS misura la stabilità visuale degli elementi presenti in pagina ed è dato dalla somma delle percentuali di spostamento degli elementi visibili dopo che sono stati mostrati per la prima volta. 

Immagina di osservare il caricamento di una pagina web al fotofinish. Ogni volta che un elemento cambia posizione tra un fotogramma e l’altro, causa uno shift.

Il Cumulative Layout Shift dunque non è altro che la somma di questi spostamenti. 

Nell’immagine, il CLS è l’area creata dallo spostamento verso il basso dell’elemento verde.  

Come puoi vedere nel frame di sinistra, c’è un’immagine che si trova dalla parte alta dello schermo e che poi, in seguito al caricamento di un’azione che ha fatto il browser, è stata spostata più in basso.

Questo spostamento (lo “shift”), viene misurato dal browser insieme a tutti gli altri spostamenti degli elementi che sono inizialmente visibili all’interno della pagina. Quindi, se un elemento viene spostato e non è visibile nel viewport, questo non verrà considerato ai fini del calcolo del CLS.

Il CLS è un parametro che va da 0 a 1.

Lo possiamo considerare come una misura in percentuale di quanto gli elementi si spostano rispetto alla loro posizione iniziale. Quindi, se hai un CLS inferiore a 0,1 significa che gli elementi all’interno della pagina si sono spostati di meno del 10%.

Come ottimizzare il CLS

Ecco qualche suggerimento:

• aggiungi gli attributi per le dimensioni per immagini e video;
• assicurati che anche gli elementi che vengono caricati in maniera asincrona, come ads, embed o iframe, abbiano già una loro dimensione. La dimensione può essere specificata o tramite attributi, oppure tramite i CSS. L’importante, però, è che il CSS sia critico, ovvero che il CSS sia descritto come un CSS in linea all’interno dell’head della pagina. In questo modo qui, il browser ha subito l’istruzione disponibile;
• inoltre, può essere utile il preload per caricare il web font;
• disattiva il lazy load della parte Above the Fold, quindi fai in modo che venga caricato subito tutto ciò che è immediatamente visibile.

4 aspetti da tenere in considerazione sui Core Web Vitals

Abbiamo detto che i Core Web Vitals rappresentano il primo tentativo di Google per misurare l’esperienza utente. Sebbene ci aiutino a creare una migliore navigazione, presentano anche alcuni limiti di cui tener conto.

1. Non sono in tempo reale: i parametri che osservi oggi, in realtà risalgono a 28 giorni fa. Questo è il tempo necessario a Google per registrare, analizzare ed elaborare i dati.

2. Non rappresentano una verità assoluta: un limite dei Core Web Vitals è che riflettono l’esperienza di navigazione dei soli utenti Chrome. Né Safari né Firefox infatti condividono i dati dei Core Web Vitals con l’ecosistema Google.

3. Non rappresentano l’esperienza di navigazione di TUTTI gli utenti. Come detto nel punto precedente, i CWV rispecchiano l’esperienza di navigazione dei soli utenti che utilizzano Chrome (circa il 75%). Il restante 25% potrebbe avere quindi un’esperienza migliore o peggiore di quella rappresentata.

4. Non sono disponibili per tutte le url: se il tuo ecommerce riceve poco traffico o non in maniera continuativa, potresti non avere Core Web Vitals disponibili.
   Nel caso di un ecommerce ad esempio, è molto probabile che Google non raccolga i Core Web Vitals relativi a tutte le pagine prodotto. Se non ha dati specifici, considererà allo stesso modo tutte le pagine prodotto.

Viste queste limitazioni, il nostro consiglio è di dotarti di software di misurazione alternativi e aggiuntivi rispetto a quelli messi a disposizione da Google. Ad esempio puoi memorizzare i CVW dentro Google Analytics o misurarli con software di RUM (Real User Monitoring).

Se stai notando rallentamenti nel tuo sito ecommerce e vuoi una soluzione definitiva per evitare di perdere i tuoi utenti, ti trovi nel posto giusto.
Per avere un’analisi della tua situazione compila il form in fondo alla pagina.