I Core Web Vitals sono un insieme di parametri che Google ha definito per migliorare l’esperienza degli utenti.
Negli ultimi anni Google ha fornito una serie di strumenti per misurare le prestazioni dei vari siti. Questi strumenti sono diventati però, nella loro complessità, solo per pochi e anche molti tecnici professionisti li hanno abbandonati perché di fatto troppo complicati e, a volte, confusi e/o inapplicabili.
Per risolvere la situazione, nella primavera del 2020 Google ha focalizzato l’attenzione su tre parametri fondamentali, in modo che i proprietari dei siti non debbano essere guru delle prestazioni per comprendere la qualità dell’esperienza che stanno offrendo ai propri utenti. L’iniziativa Web Vitals mira ad aiutare i siti a concentrarsi sulle metriche che contano di più, i Core Web Vitals, appunto.
I Core Web Vitals sono il sottoinsieme dei Web Vitals che si applicano a tutte le pagine Web, dovrebbero essere misurati da tutti i siti e verranno visualizzati su tutti gli strumenti di Google. Ciascuno dei Core Web Vitals rappresenta un aspetto distinto dell’esperienza dell’utente, è misurabile sul campo e riflette l’esperienza reale di un risultato critico incentrato sull’utente.
Le metriche che compongono i Core Web Vitals si evolveranno nel tempo. L’attuale set per il 2020 si concentra su tre aspetti dell’esperienza dell’utente: caricamento, interattività e stabilità visiva e include le seguenti metriche (e le rispettive soglie per un giudizio buono, migliorabile, scarso):
- LCP [2,5″, 4″ oltre]
- CLS [0,1, 0,25, oltre]
- FID [100 ms, 300 ms, oltre].
I Core Web Vitals dovrebbero diventare parte del giudizio SEO di un sito dal 2021, probabilmente anche dal prossimo Core Update (settembre 2020?).
Largest Contentful Paint (LCP)
La metrica LCP (più grande visualizzazione con contenuti) indica il momento in cui vengono visualizzati il testo o l’immagine più grandi; misura la performance del caricamento. Importante è osservare che quello che conta è quanto appare nella viewport di apertura del sito. Tutto quello che è “below the folder” non viene conteggiato.
Usare titoli molto grandi, immagini di apertura enormi, ma soprattutto video e/o pubblicità piuttosto invasive è molto penalizzante. Ecco un esempio offerto da Philip Walton.
Nei due casi è l’immagine che determina l’LCP.
La metrica First Contentful Paint o FCP (prima visualizzazione con contenuti) indica il momento in cui vengono visualizzati il primo testo o la prima immagine. Essa non è un Core Web Vitals perché descrive solo i primi momenti dell’esperienza utente. Se per esempio mostra il titolo essa non è molto interessante.
In breve, LCP presume che l’oggetto più grande visibile nella finestra sia il contenuto principale (anche se spesso non è così!). L’LCP prende in considerazione solo gli oggetti che vengono renderizzati “above the fold” come immagini, titoli o video. Si noti che non viene considerato il tempo di download (in effetti, nei vecchi tentativi di definire l’esperienza utente era abbastanza inutile considerare parametri che duravano millisecondi, un tempo ininfluente per l’utente): invece di ragionare in termini di kb o Mb, si ragiona in quantità di spazio che l’oggetto utilizza nella finestra dell’utente. Se gli elementi sono renderizzati sia sopra che sotto la piega 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.
Si noti questo ulteriore esempio fornito da Walton.
Qui il testo è l’elemento più grande ed è quello che definisce la metrica.
Pertanto, come regola generale, è importante non inserire above the fold immagini o video superiori ai 250 pixel di larghezza. Immagini di 300 pixel o ad pubblicitari di 300×250 o 336×280 comportano già un’importante penalizzazione.
Cumulative Layout Shift (CLS)
La metrica Cumulative Layout Shift (Variazione layout cumulativa) misura lo spostamento degli elementi visibili all’interno dell’area visibile, quindi la stabilità visiva. Per esempio, si supponga che per ampliare la porzione dedicata alla skin (lo sfondo pubblicitario usato da molti siti) si ridimensioni la pagina del sito. Ciò comporta dopo il caricamento dell’area del sito uno shift dovuto al ridimensionamento con un effetto piuttosto fastidioso.
Il calcolo del CLS è piuttosto complicato ed è il prodotto di due valori, la componente d’impatto e la componente di distanza.
Sempre da Philip Walton (e Milica Mihajlija) viene l’esempio più significativo.
La componente d’impatto – Si osservi questa immagine:
Nel fotogramma a sinistra dell’immagine sopra c’è un elemento che occupa metà della finestra. Nel fotogramma successivo, l’elemento si sposta verso il basso del 25% dell’altezza della finestra. Il rettangolo rosso e tratteggiato indica l’unione dell’area visibile dell’elemento in entrambi i fotogrammi, che, in questo caso, è il 75% della vista totale, quindi la sua componente di impatto è 0,75.
La componente di distanza – Si osservi l’altra immagine di Walton:
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).
Nell’esempio la dimensione della finestra più grande è l’altezza e l’elemento instabile si è spostato del 25% dell’altezza della finestra, il che rende la frazione di distanza 0,25.
Il CLS è dunque 0,75*0,25=0,1875, un risultato definito “migliorabile”.
Un caso pratico – Supponiamo che si voglia utilizzare un menu a tendina dove per una certa voce (Giardino) escano le sottovoci (Piante erbacee, Alberi, Piante da frutto ecc.). Se il menu mostra prima le voci principali (Giardino, Orto, Appartamento) e poi “apre” successivamente i tre menu alle sottovoci, si avrà un CLS scarso, molto penalizzante perché l’utente vedrà “fluttuare” la prima schermata.
First Input Delay (FID)
Misura l’interattività. Il FID misura il tempo che intercorre tra la prima volta in cui un utente interagisce con una pagina (ovvero quando fa clic su un collegamento, tocca un pulsante o utilizza un controllo personalizzato basato su JavaScript) e il momento in cui il browser è effettivamente in grado di rispondere a tale interazione. Altre interazioni, come lo scorrimento e lo zoom, sono azioni continue e non sono considerate.
Perché Google considera solo il primo input delay? Soprattutto perché il primo ritardo di input sarà la prima impressione dell’utente della capacità di risposta del sito e le prime impressioni sono fondamentali per modellare la nostra impressione generale della qualità e dell’affidabilità di un sito.
Infatti, i maggiori problemi di interattività che vediamo oggi sul Web si verificano durante il caricamento della pagina.
Per esempio, non sono buone soluzioni suddividere il codice in più caricamenti oppure caricare troppo JavaScript in anticipo.
Come si misurano i Core Web Vitals
Attualmente, gli strumenti più affidabili sono tre.
Chrome – Partendo dal menu Impostazioni (i tre punti verticali sulla destra in alto), si scelga Altri strumenti/Strumenti per sviluppatori. Si scorra il menu in alto nel riquadro che appare (Elements, Console ecc.) fino a trovare Lighthouse. Si scelga Audit/New Report. Nonostante la documentazione Google lo consigli, questo strumento non è ancora aggiornatissimo (la versione 6.0 di Lighthouse è implementata solo su Google Chrome Canary che però è spesso instabile) e i Core Web Vitals non appaiono chiaramente.
Web Page Test – Anche questo strumento si basa su Lighthouse ed è aggiornato ai Core Web Vitals, ma è piuttosto complesso e lento, decisamente orientato a utenti molto professionali.
Page Speed Insights – Contiene l’aggiornamento ai Web Vitals ed è quello più efficiente e consigliabile. Si veda l’articolo PageSpeed Insights per approfondimenti.
