Core web vitals: i limiti di cui nessuno parla

In questi ultimi mesi avrai sicuramente sentito parlare dei Core Web Vitals e dell’imminente aggiornamento dell’algoritmo di Google.

In pratica Google ha dichiarato che entro Agosto aggiungerà – tra i centinaia di fattori di posizionamento già esistenti – questi 3 parametri:

LCP (Largest Contentful Paint): misura il tempo impiegato a visualizzare l’elemento grafico o testuale più grande visibile sulla pagina.
FID (First Input Delay): misura la reattività del sito ovvero il tempo trascorso da quando l’utente compie un’azione a quando il sito “risponde”.
CLS: (Cumulative Layout Shift): misura la stabilità visuale degli elementi presenti in pagina.

L’obiettivo è tentare di misurare in maniera oggettiva l’esperienza di navigazione dell’utente all’interno del sito.

Se il tuo sito è lento, Google potrebbe decidere di penalizzarlo “posizionandolo” più in basso nei risultati di ricerca. Ma se gli utenti scappano dal sito senza acquistare non penso che il tuo problema sarà essere ultimo su Google.

Secondo Google, l’utente ha sicuramente una pessima esperienza quando:

1 – il sito è lento a caricarsi (e la pagina rimane bianca)
2 – è poco reattivo (ovvero clicchi / tappi e non succede nulla)
3 – gli elementi cambiano di posizione durante il caricamento della pagina

Indice dei contenuti

Ma cosa cambierà, all’atto pratico, per noi addetti del settore?

La risposta è….

NULLA.

il tuo sito deve già essere veloce e usabile altrimenti i visitatori del tuo sito lo abbandonano. Indipendentemente da ciò che dice Google.

Il tuo sito deve già essere veloce e usabile altrimenti i visitatori del tuo sito lo abbandonano. Indipendentemente da ciò che dice Google.

MA…

Visto che stiamo giocando al gioco di Google è utile conoscere le regole del suo gioco,le zone grigie e le limitazioni. Solo attraverso la conoscenza e l’esperienza è infatti possibile vincere.

SAI QUALI SONO I LIMITI DEI CORE WEB VITALS?

Prima di svelarteli, sai come fa Google a rilevare questi parametri?

Li rileva dal browser Google Chrome, e lo fa:
simulando un utente (proveniente dalla Germania e che usa una connessione sfigatissima a 1.5mbit),
aggregando i dati letti dai visitatori del sito che utilizzano Chrome.

In particolare vengono utilizzati i dati di chi ha il “invio statistiche e crash report” abilitato e la sincronizzazione della cronologia attivata. La stragrande maggioranza degli utenti.

Questi dati vengono raccolti per ogni pagina del sito poi aggregati.

Se sono abbastanza finiscono in un database gigantesco chiamato CrUX (Chrome UX Report).

Può succedere quindi che nel CrUX NON siamo presenti i dati di tutte le pagine del sito.

I dati CrUX sono gli stessi che vengono mostrati nella Google Search Console. Questi dati sono in ritardo di 28 giorni, in quanto Google ha bisogno di circa un mese per collezionare dati.

Questo significa che quando modifichi il sito, devi aspettare almeno 28 giorni per far si che Google ti mostri la situazione aggiornata.

Una cosa che non tutti sanno è che Chrome su iOS (iPhone e iPad) non è altro che Safari con una grafica differente, in quanto per via dei vincoli imposti da Apple, Chrome deve usare lo stesso motore di Safari.

Questo significa che anche se gli utenti iPhone usano Chrome, i dati di navigazione degli iPhone non vengono presi in considerazione.

Un’altra cosa importante da sapere è che solo i browser basati su Chromium ovvero Chrome, Edge, Opera, Samsung Internet sono tecnicamente in grado di fornire i core web vitals.

Questo significa che i core web vitals NON RAPPRESENTANO LA VERITÀ’ e che da soli non sono sufficienti a misurare le performance o l’usabilità del sito, in quanto misurano solo una parte dell’esperienza d’uso che potrebbero avere una parte dei visitatori del sito.

I Core Web Vitals NON RAPPRESENTANO LA VERITÀ’ e da soli non sono sufficienti a misurare le performance o l’usabilità del sito

Fare affermazioni su un sito basandosi esclusivamente CWV è come 𝐚𝐟𝐟𝐞𝐫𝐦𝐚𝐫𝐞 𝐜𝐡𝐞 𝐬𝐞 𝐪𝐮𝐚𝐥𝐜𝐮𝐧𝐨 𝐦𝐚𝐧𝐠𝐢𝐚 𝐝𝐮𝐞 𝐩𝐨𝐥𝐥𝐢, 𝐞 𝐪𝐮𝐚𝐥𝐜𝐮𝐧 𝐚𝐥𝐭𝐫𝐨 𝐧𝐨, 𝐢𝐧 𝐦𝐞𝐝𝐢𝐚 𝐡𝐚𝐧𝐧𝐨 𝐦𝐚𝐧𝐠𝐢𝐚𝐭𝐨 𝐮𝐧 𝐩𝐨𝐥𝐥𝐨 𝐚 𝐭𝐞𝐬𝐭𝐚, 𝐚𝐧𝐜𝐡𝐞 𝐬𝐞 𝐝𝐢 𝐟𝐚𝐭𝐭𝐨 𝐬𝐚𝐩𝐩𝐢𝐚𝐦𝐨 𝐜𝐡𝐞 𝐮𝐧𝐨 𝐧𝐨𝐧 𝐥’𝐡𝐚 𝐦𝐚𝐧𝐠𝐢𝐚𝐭𝐨 (Trilussa docet)

I core web vitals possono quindi essere non accurati perchè:
sono misurati con condizioni troppo differenti da quelle reali degli utenti
prendono in considerazione solo una parte degli utenti che navigano sul sito, utenti che non compongono necessariamente un campione rappresentativo.
mostrano solo alcune url
sono in ritardo di almeno 28 giorni

COSA FARE QUINDI?

Innazitutto iniziare a prendere con le pinze i dati provenienti dai core web vitals.

Sicuramente ha senso raccogliere e misurare i dati in maniera più accurata utilizzando una fonte INDIPENDENTE da Google.

La fonte migliore dei dati è il browser degli utenti (tutti gli utenti e tutti i browser) e per sfruttarla si possono utilizzare software specializzati in Real User Monitoring (R.U.M.) oppure si possono utilizzate script “artigianali” realizzati ad hoc.
Questi dati una volta raccolti possono essere visualizzati in Google Analytics o in Google Data Studio.
Inoltre è utile inserire l’analisi delle web performance nel proprio workflow di sviluppo, preoccupandosi di svolgere i test correttamente prima di pubblicare il sito online.