Come i Core Web Vitals cambiano la SEO
Google ha annunciato nel suo blog ufficiale l’introduzione di una serie di metriche che valutano la user experience (UX) di un sito web e ritenute essenziali per una buona esperienza utente e un web più piacevole.
Questi fattori sono la base del progetto “Core Web Vitals 2020” e saranno integrate alla SEO attraverso un set di specifici indicatori di UX che diventeranno ufficialmente un fattore di ranking nel 2021.
Google è da tempo impegnato a rendere più semplice ed efficace l’usabilità dei siti web con l’obiettivo di facilitare l’esperienza di navigazione degli utenti e fornire risposte velocemente e in modo chiaro.
Come misurare le performance di un sito web
Ad oggi le performance di un sito possono essere misurate usando:
PageSpeed Insights
Lighthouse
Search Console
Chrome UX Report
Chrome DevTools
Web Vitals Extension
Questi strumenti si basano su dati raccolti dalla Chrome User Experience, un set di dati pubblici e metriche sull’esperienza utente provenienti dagli utenti che utilizzano Chrome in condizioni reali.
Tuttavia questi dati sono un campione perché comprendono solo quelli di utenti che hanno dato il consenso ad alcune condizioni come la sincronizzazione della cronologia e l’abilitazione dei report sulle statistiche di utilizzo.
Fortunatamente abbiamo a disposizione alcuni strumenti per tracciare questi dati che vedremo alla fine.
Cosa sono i Web Vitals
I Web Vitals sono parametri standard per misurare la qualità dell’esperienza di navigazione di un utente su un sito web. Tra questi ce ne sono tre chiamati “Core” ritenuti fondamentali da Google e consistono in metriche e indicatori legati alla velocità, al tempo di risposta e alla stabilità del layout di un sito web.
Questi sono i tre fattori principali:
LCP: Largest Contentful Paint – Velocità di caricamento (loading)
FID: First Input Delay – Interattività della pagina (interctivity)
CLS: Cumlative Layout Shift – Stabilità visiva del caricamento (visual stability)
Largest Contentful Paint (LCP)
La metrica LCP indica il tempo di rendering dell’elemento più grande (Largest) visibile all’interno della schermo quando si carica il sito e misura la performance del caricamento.
Nel dettaglio può essere compreso tra:
elementi di tipo immagini
elementi di tipo immagini dentro a elementi di tipo
elementi di tipo video
Questa metrica presume che l’oggetto più grande visibile nella finestra sia il contenuto principale e penalizza contenuti invasivi come titoli molto grandi, immagini di apertura enormi, video, banner pubblicitari e pop-up. Nei due esempi che seguono, l’elemento più grande individuato sono le due immagini principali.
Per fornire una buona esperienza utente i siti dovrebbero caricare il contenuto “above the fold” entro i primi 2,5 secondi e sono considerati lenti già sopra i 4 secondi.
Da notare che non viene considerato il tempo di download ma la quantità di spazio che l’oggetto utilizza nella finestra dell’utente. Se gli elementi sono renderizzati sia sopra che sotto il limite della pagina, solo la parte visibile è considerata rilevante.
Lo stesso vale per gli elementi in scala. Un’icona di 800×800 pixel se ridotta a 50×50 pixel conta solo per 50 pixel. Se si ingrandiscono le immagini, è rilevante solo la dimensione dell’immagine originale.
Pertanto, come regola generale, è importante non inserire “above the fold” video o immagini superiori a 250 pixel di larghezza. Immagini di 300 pixel o banner pubblicitari di 336×280 o 300×250 comportano già penalizzazione importante.
Sono above the fold quei contenuti che riescono a riempire lo schermo del device dell’utente senza che questo debba fare alcun movimento di scroll ovvero senza che l’utente faccia niente né con il mouse né con il dito da mobile
First Input Delay (FID)
Il Cumulative Layout Shift misura lo spostamento degli elementi visibili e i cambiamenti di layout che arrivano all’improvviso e si verificano durante l’intera durata della visita della pagina causando uno shift dopo il caricamento dell’area del sito dovuto al ridimensionamento, con un effetto piuttosto fastidioso.
Il calcolo del CLS è piuttosto complicato e si esprime come il prodotto di due valori, la componente d’impatto e la componente di distanza utilizzando questa formula:
punteggio layout shift = componente impatto * componente distanza
La componente d’impatto misura lo spazio normale occupato da un elemento nella finestra e quello che occupa dopo il suo spostamento. L’unione dell’area visibile dell’elemento prima e dopo lo spostamento decreta la percentuale della vista totale quindi la sua componente di impatto.
La componente di distanza è la distanza maggiore che un elemento instabile ha coperto nel riquadro durante lo spostamento (in orizzontale o in verticale) diviso per la dimensione più grande della finestra (larghezza o altezza, a seconda di quale sia maggiore) e si misura sempre in percentuale.
Il CLS è dunque il prodotto di queste due componenti e per una buona UX dovrebbe essere inferiore a 0,1.
L’immagine precedente mostra un blocco di testo – che occupa metà della parte visibile dello schermo – spostarsi in basso di un 25% dell’altezza della finestra. Il rettangolo rosso indica l’unione dell’area visibile dell’elemento prima e dopo lo spostamento, ossia 50% + 25% = 75% della finestra, quindi la componente d’impatto è 0,75.
E siccome l’elemento instabile si è spostato del 25% dell’altezza della finestra, il valore della componente di distanza è 0,25.
In base alla formula scritta in precedenza, il punteggio CLS è uguale a 0,75 * 0,25 = 0,1875 che risulta essere migliorabile.
La page experience
Gli sviluppatori di Google hanno elencato i criteri presi in esame per la valutazione di un sito e le metriche utilizzate dall’algoritmo per capire come un utente percepisce l’usabilità di una pagina web.
Alcuni fattori di posizionamento indispensabili che Google richiede sono:
ottimizzare per i dispositivi mobili
minimizzare al massimo il caricamento delle pagine
garantire la sicurezza con HTTPS
strutturare adeguatamente gli annunci pubblicitari con gli interstitial (pagine pubblicitarie realizzate con JavaScript o Flash)
Come migliorare i Core Web Vitals
Google consiglia di correggere tutte le metriche etichettate come “Scarse” e alcune delle correzioni di pagina più comuni dovrebbero includere:
ridurre le dimensioni della pagina a meno di 500 KB.
limitare il numero di risorse della pagina a 50.
valutare l’introduzione di AMP
Conclusioni
Google ha creato una nuova libreria JavaScript dedicata ai Core Web Vitals e API che permettono di misurare ogni parametro e raccogliere dati degli utenti reali. In questo modo è possibile sfruttare le API per tracciare autonomamente il comportamento degli utenti sfruttando Google Tag Manager per trasferire le metriche su Google Analytics ed esportarle su Google Data Studio.
In definitiva possiamo dire che l’introduzione dei Core Web Vitals ci ricorda ancora una volta che l’obiettivo principale rimane quello di creare siti facili e veloci da navigare, soprattutto per gli utenti mobile. Sottovalutare questi aspetti non solo rischia di diminuire le conversioni del nostro sito ma il pericolo è rimanere confinato alle posizioni più basse della SERP.
