Core Web Vitals di Google, le metriche chiave per la SEO e la UX

Tempo di lettura : 25 minuti

Si chiamano Core Web Vitals, in italiano Segnali web essenziali, e sono un insieme di metriche tecniche incentrate su specifici parametri della user experience per misurare il modo in cui una pagina riesce a fornire un’esperienza fluida e senza interruzioni. Presentate per la prima volta da Google nel maggio 2020 e poi introdotte ufficialmente all’interno dei fattori di ranking che compongono la Page Experience, queste metriche sono al momento costituite da tre componenti – velocità di caricamento dei contenuti, interattività e stabilità visiva, rispettivamente misurabili con Largest Contentful Paint, First Input Delay e Cumulative Layout Shift  – ma sono evolutive e non statiche. Andiamo alla scoperta dei Core Web Vitals, per capire quali sono le metriche sulle prestazioni delle pagine, come funzionano, come misurare e come ottimizzare il sito alla luce di questi nuovi parametri tecnici.

Cosa sono i Core Web Vitals

Il progetto Core Web Vitals di Google è stato descritto per la prima volta nel maggio 2020 dal Web Performance Engineer Ilya Grigorik sul blog di Chromium, che lo ha definito come guida unificata ai segnali di qualità essenziali per offrire una grande esperienza utente sul web.

Non è sempre facile comprendere quali sono gli aspetti importanti su cui concentrare la nostra attenzione nel lavoro di ottimizzazione della user experience del sito, infatti, e quindi Google ha deciso di fissare i Web Vitals per semplificare l’analisi individuando le metriche che contano di più nel processo di lavoro sulla qualità dell’esperienza utente, che resta la chiave per il successo a lungo termine di qualsiasi sito Web.

Se misurare la qualità dell’esperienza dell’utente ha molte sfaccettature e alcuni aspetti sono specifici del sito e del contesto, Google ha individuato un insieme comune di segnali fondamentali per tutte le esperienze web. I Core Web Vitals infatti si applicano a tutte le pagine Web, devono essere misurati da tutti i proprietari del sito e sono visualizzati su tutti gli strumenti di Google. Ciascuno di questi parametri rappresenta un aspetto distinto della UX, è misurabile sul campo e riflette l’esperienza reale di un risultato critico incentrato sull’utente.

Quali sono i Core Web Vitals: le prime metriche scelte da Google

Le metriche che compongono i Segnali web essenziali si evolveranno nel tempo, anticipa Google (ma non con cadenza precisa né assidua, per evitare di modificare con eccessiva frequenza gli obiettivi da raggiungere per SEO e sviluppatori), e nella fase iniziale si concentrano su tre aspetti – caricamento, interattività e stabilità visiva – attraverso tre metriche specifiche con rispettive soglie a cui far riferimento.

Le prime tre metriche che Google ha definito essenziali e vitali per il web sono:

1. Largest Contentful Paint (LCP), che misura l’intervallo di tempo tra l’inizio del caricamento di una pagina e il rendering completo dell’immagine o del blocco di testo più grande nella visualizzazione di un utente. Il punteggio potrebbe cambiare durante il caricamento della pagina e quando il contenuto è visibile, ma il nodo più grande resta nel backlog ancora da visualizzare; ciò diventa più evidente sulle velocità di connessione limitate. In base agli studi di Google, per fornire una buona esperienza utente il LCP dovrebbe verificarsi entro 2,5 secondi dal primo avvio della pagina.
2. First Input Delay (FID), ovvero il tempo necessario affinché una pagina sia pronta per l’interattività dell’utente, ovvero quanto tempo impiega la pagina, mentre viene assemblata, a rispondere a clic, scroll o input da tastiera elaborando corrispondenti i gestori di eventi. L’interazione dell’utente può essere notevolmente ritardata dalle principali attività di script thread-blocking. Per avere prestazioni efficienti, le pagine devono avere un FID inferiore a 100 millisecondi.
3. Cumulative Layout Shift (CLS), che è la distanza misurata e la frazione del viewport che si sposta a causa della manipolazione del DOM o della mancanza di attributi di dimensione per i principali elementi multimediali. Quando non riusciamo a definire le dimensioni per le nostre hero images, ad esempio, il testo sulle pagine sembra inizialmente solo essere dislocato, causando uno “spostamento” distruttivo del layout dei contenuti per i nostri utenti. Le pagine devono mantenere un CLS inferiore a 0,1 per fornire una buona UX.

A partire dal marzo 2024, però, Google sostituirà la metrica della reattività e FID lascerà spazio a INP o Interaction to Next Paint, che supera alcuni dei precedenti limiti di misurazione e permette agli sviluppatori di misurare la reattività “nel modo in cui la sperimentano gli utenti reali del sito”.

Perché ottimizzare metriche e prestazioni: i vantaggi secondo Google

Anche se parliamo di questioni meramente tecniche, dovrebbe essere già chiaro perché è importante lavorare all’ottimizzazione di questi aspetti sulle nostre pagine – non fosse altro per il fatto che i Segnali Web Essenziali sono, come ricordato, una parte del Google Page Experience Update, l’aggiornamento algoritmico partito a giugno 2021 per le ricerche mobile ed esteso poi definitivamente a maggio 2022 anche alle classifiche desktop, e quindi rappresentano dei fattori di ranking per Google.

Quando si parla di performance, però, bisogna prendere in considerazione i concreti effetti sulla navigazione e sulla soddisfazione degli utenti, e sono molteplici gli studi che mettono in relazione l’elemento “tempo” con i rendimenti. E quindi, partendo dal presupposto che nel Web ogni secondo conta e migliora le possibilità di guadagno potenziale, ci sono alcuni motivi validi per cui SEO e digital marketer dovrebbero impegnarsi nel migliorare (e nel manutenere!) le prestazioni delle pagine del sito, concentrandosi almeno su quelle più importanti per il business.

Proprio l’aspetto economico dovrebbe essere una leva che spinge all’ottimizzazione, perché oggi più che mai l’esperienza del cliente è sempre più digitale e la maggior parte delle customer journey ha componenti digitali, anche per gli acquisti offline. Recenti statistiche spiegano che l’85% dei percorsi dei clienti passa almeno una volta attraverso la Ricerca Google, quindi la visibilità in questo ambito favorisce il coinvolgimento e i risultati.

Concentrarsi sui Google Core Web Vitals, poi, significa costruire pagine in grado di soddisfare gli utenti, ancor più che pagine in grado di posizionarsi meglio su Google (un elemento che, come detto, è stato in realtà inferiore alle aspettative), e ciò va nella direzione di un complessivo miglioramento del servizio offerto che ha risultati concreti nei rendimenti. Non bisogna dimenticare, ad esempio, che due indagini separate condotte da Akamai e Deloitte hanno concluso che un ritardo di 1 secondo nel tempo di caricamento di una pagina riduce le conversioni di un drastico 7%-9%. Il tempo di caricamento è uno dei principali fattore che contribuisce all’abbandono di una pagina e l’utente medio non ha pazienza per attendere una pagina che impiega troppo tempo a caricarsi – ed è proprio per questo che Google sta spingendo sui Core Web Vitals come fattore di ranking.

Creare un’esperienza d’uso della pagina web senza ritardi e soluzione di continuità è fondamentale per conquistare e far tornare i clienti, e per aumentare le probabilità che i potenziali clienti visitino il nostro sito web. Trattenere gli utenti è inoltre fondamentale per migliorare le conversioni, mentre (com’è facile intuire) i siti lenti hanno un impatto negativo sulle entrate.

Secondo il team Chromium di Google, l’implementazione dei Core Web Vitals garantisce il 24% in meno di abbandoni di pagine dovuti a ritardi di caricamento e il 24% in meno di abbandoni per i siti di shopping. Inoltre, in un sondaggio sull’esperienza ThinkwithGoogle ha dimostrato che, solo offrendo un’esperienza utente positiva, il 67% in più dei clienti è propenso ad acquistare e il 74% è più propenso a tornare sul sito web.

Sempre prendendo come riferimento alcuni dati diffusi da Google, le prestazioni delle pagine e il miglioramento dei Segnali web essenziali ha un impatto diretto sul coinvolgimento degli utenti e sulle metriche aziendali. Ad esempio:

• Le ricerche hanno dimostrato che, quando un sito soddisfa le soglie di Segnali web essenziali, esiste il il 24% di probabilità in meno che gli utenti abbandonino la pagina durante il caricamento.
• Con ogni riduzione di 100 ms nella metrica Largest Contentful Paint (LCP), il tasso di conversione web di Farfetch è aumentato dell’1,3%.
• La riduzione della metrica Cumulative Layout Shift (CLS) dello 0,2 ha comportato per Yahoo! JAPAN un aumento del 15% delle visualizzazioni di pagina per sessione, una durata delle sessioni del 13% più lunga e una diminuzione della frequenza di rimbalzo di 1,72 punti percentuali.
• Netzwelt ha migliorato le metriche di Segnali web essenziali e ha registrato un aumento del 18% delle entrate pubblicitarie e del 27% delle visualizzazioni di pagina.
• La riduzione del CLS da 1,65 a 0 ha comportato per redBus un aumento significativo del ranking dei domini a livello globale.

Un progetto in evoluzione

Le prime (e ancora attuali) metriche dei Segnali web essenziali misurano tre aspetti importanti dell’esperienza dell’utente sul Web, ma Google è consapevole che “ci sono molti aspetti dell’esperienza dell’utente che non sono ancora coperti”. Da qui deriva la decisione di aggiornare i Core Web Vitals su base annuale e di fornire aggiornamenti regolari sui futuri candidati, sulla motivazione e sullo stato di implementazione – anche se in realtà il set è rimasto identico a quello iniziale ancora oggi, a distanza di due anni.

Ad esempio, anticipava Grigorik, Google stava ragionando investendo nella “costruzione di una migliore comprensione e capacità di misurare la velocità della pagina e altre caratteristiche fondamentali dell’esperienza dell’utente”. In particolare, l’articolo citava la possibilità di “estendere la capacità di misurare la latenza di input tra tutte le interazioni, non solo la prima; nuove metriche per misurare e quantificare la scorrevolezza; primitive e metriche di supporto che consentiranno la consegna di esperienze istantanee e di tutela della privacy sul web e altro ancora”, ma come detto ad oggi non ci sono stati progressi ufficiali.

Come misurare i Segnali web essenziali: i tre valori delle metriche

È bene sottolineare che tali metriche si concentrano sul completamento di determinati eventi – incluso ciò che è interessato in modo interattivo o visivo quando si verificano questi eventi – mentre le pagine vengono caricate fino a un punto di stabilità relativo all’esperienza dell’utente, come ci spiega Detlef Johnson su Search Engine Land.

Ciò significa che i valori del punteggio possono cambiare quando gli utenti interagiscono con la pagina, e in linea generale si ottengono punteggi migliori quando gli eventi si verificano più velocemente lungo gli intervalli di tempo del cronometro.

Google suggerisce un metodo per assicurarci di raggiungere l’obiettivo raccomandato per la maggior parte dei nostri utenti: per ciascuna metrica, una buona soglia di misurazione è “centrare il 75esimo percentile dei page loads, segmentato su dispositivi mobili e desktop”.

Più precisamente, le metriche delle prestazioni per ciascuna statistica Web Vitals sono classificate in base a tre risultati:

• Buono (che significa la promozione)
• Miglioramenti necessari
• Fallito

Gli utenti di lunga data di PageSpeed Insights potrebbero avere familiarità con metriche simili, molte delle quali resteranno invariate, anche se forse non tutte. I Core Web Vitals rappresentano il culmine di queste altre metriche e con esse derivano dalla complessità della Developer Experience, semplificata per consentire a tutti gli utenti (proprietari siti, ma anche webmaster e sviluppatori) di contare su una gradita chiarezza e su meno metriche, ma più grandi, da seguire.

Nel tempo, infatti, Google ha sviluppato molte metriche e strumenti utili per aiutare proprietari di aziende, esperti di marketing e sviluppatori a identificare opportunità per migliorare tutto ciò che è legato alla UX, anche attraverso la collaborazione con milioni di sviluppatori web e proprietari di siti.

Oltre al citato PageSpeed Insights ricordiamo anche Lighthouse, Chrome DevTools, il Rapporto velocità nella Search Console, che sono sicuramente utili e validi: tuttavia, l’abbondanza di metriche e strumenti ha reso impegnativo tenere il passo, comprendere il funzionamento e interpretare tutti i dati forniti, e di conseguenza ha complicato il processo decisionale su dove concentrare i propri sforzi in maniera prioritaria, rendendo appunto necessario un intervento di semplificazione e ottimizzazione.

Come misurare i Core Web Vitals

L’obiettivo di Google è “rendere Core Web Vitals semplice, di facile accesso e misurazione per tutti i proprietari e gli sviluppatori del sito”, sia nell’ecosistema di Google che all’interno delle varie dashboard e strumenti che si possono usare.

Sul fronte pratico, è possibile analizzare, misurare e ottenere score indipendenti per i Segnali Web Essenziali tra dispositivi mobili (telefono) o desktop / laptop.

In alcuni strumenti è possibile specificare quale tipo di dispositivo vuoi testare o passare da un tipo all’altro quando entrambi sono disponibili. Ad esempio, PageSpeed Insights utilizza per impostazione predefinita le statistiche per dispositivi mobili, quindi dovremo passare alla scheda del desktop per vedere la differenza nei punteggi tra le due versioni.

In maniera ancora più intuitiva anche per chi è alle prime armi, Google ha realizzato lo specifico report Segnali web essenziali all’interno della Search Console, che permette di scoprire a colpo d’occhio le prestazioni delle pagine del sito in base a dati sull’utilizzo reali (i cosiddetti dati sul campo).

Quali tool usare per misurare i Core Web Vitals

Johnson elenca anche i tool utili per misurare le metriche Core Web Vitals in aggiunta alla GSC, offrendo dettagli sul loro funzionamento.

• • PageSpeed Insights. È il primo strumento da utilizzare per misurare i valori Web Vitals. Nel rapporto possiamo ottenere sia i dati di laboratorio sia i dati di campo (se disponibili), ma anche molte altre metriche in gran parte correlate al miglioramento delle pagine con errori, in particolare i risultati che influenzano la velocità di una pagina e il download delle sue risorse.
  • Estensione Web Vitals per Chrome. Utilizzando l’estensione di Chrome è possibile accedere a Web Vitals direttamente al caricamento della pagina e, come detto, interagire con la pagina per fare troubleshooting di eventuali problemi con First Input Delay e/o Content Layout Shift. È anche disponibile da pagina a pagina durante la navigazione di siti Web.
  • WebPageTest. Questo strumento di test indipendente permette configurare l’approccio con una varietà di condizioni; costruito dagli ingegneri di Google che fanno parte del team di Chromium, le informazioni sono autorevoli e rendono disponibili le API RESTful.
  • API JavaScript Web Vitals. Permette di usare JavaScript per accedere alle metriche direttamente dal browser e trasmetterle a un repository di nostra scelta. In alternativa, possiamo inserire il test nel processo di sviluppo e assicurarci che le modifiche apportate non influiscano negativamente sui punteggi dopo fatto push alla produzione.
  • Chrome Dev Tools. Chrome stesso fornisce il set definitivo di strumenti per scoprire o rintracciare i problemi utilizzando le informazioni altamente dettagliate disponibili nei rapporti e nelle registrazioni del caricamento della pagina nella scheda Performance. La vasta gamma di strumenti, gli switch e le opzioni infinite sono ideali per un lavoro di ottimizzazione più impegnativo.
  • Chrome User Experience Report. Come parte del suo Chrome User Experience Report (CrUX), Google mostra i dati sul campo di oltre 18 milioni di siti web che hanno raccolto statistiche sufficienti per riportare i Web Vitals. I dati sono conservati nel servizio BigQuery di Google, dove è possibile eseguire query su statistiche da questi siti Web risalenti a diversi anni fa; gli aggiornamenti sono in corso e disponibili il secondo martedì di ogni mese, a seguito dell’accumulazione, informa l’articolo. Per vedere i punteggi di dispositivi mobili e desktop utilizzando il rapporto CrUX, avremo bisogno di “telefono” o “desktop” come fattori di forma del dispositivo nelle nostre istruzioni SQL. È interessante notare che “mobile” non funziona in quanto non è una colonna e “tablet” in origine funzionava solo raramente a causa della scarsità dei dati specificati. I dati dei tablet potevano essere visualizzati nelle query per l’origine (dominio) di Google, ad esempio, ma non li avremmo visti per i siti più tranquilli.

Per facilitare agli sviluppatori la misurazione delle prestazioni di questi parametri sui per i loro siti, è stata rilasciata anche una library JavaScript open source dedicata ai Web-vitals, che può essere utilizzata con qualsiasi analytics provider che supporti metriche personalizzate o, in alternativa, come riferimento per sapere come acquisire accuratamente ciascuno dei Core Web Vitals per gli utenti del nostro sito.

La differenza tra lab data e field data, metriche di campo e metriche di laboratorio

Nel suo primo post, Grigorik spiegava anche la distinzione cruciale tra i cosiddetti field data o dati sul campo (spesso definiti anche Real User Monitoring perché raccolgono le informazioni sulle prestazioni registrate da utenti nel mondo reale su una varietà di dispositivi e condizioni di rete, raccolte in forma anonima) rispetto invece alle misurazioni di laboratorio.

Per scelta, infatti, i Core Web Vitals sono essenzialmente misurabili con metriche sul campo, anche se è possibile anche utilizzare i dati di laboratorio. I Lab Data (i dati di prova controllati, ottenuti attraverso metodo scientifico e metriche oggettive che possono essere calcolate in un ambiente controllato con un certo livello di accuratezza e ripetibilità) restano il modo migliore per testare le prestazioni delle funzionalità durante lo sviluppo, prima che vengano rilasciate agli utenti, e per rilevare le regressioni delle prestazioni prima che si verifichino.

Pur essendo quindi una parte essenziale per offrire grandi esperienze, le misurazioni di laboratorio non possono però sostituire completamente i dati sul campo, e Google ci spiega il motivo. Le prestazioni di un sito possono variare notevolmente in base alle capacità del dispositivo di un utente, alle condizioni della sua rete, a quali altri processi potrebbero essere in esecuzione sul dispositivo e al modo in cui interagiscono con la pagina.

In effetti, ciascuna punteggio delle metriche di Core Web Vitals può essere influenzato dall’interazione dell’utente, e quindi solo la misurazione sul campo può acquisire accuratamente l’immagine completa e fornire le indicazioni utili per intervenire.

Per comprendere davvero le metriche e i punteggi bisogna quindi prima familiarizzare con i concetti di dati di laboratorio e dati di campo, ovvero lab data e field data, topic sul quale anche Detlef Johnson apre un’utile parentesi.

I dati di “laboratorio” di Web Vitals vengono raccolti tramite API del browser come parte dei timer degli eventi di caricamento della pagina e delle approssimazioni matematiche che simulano l’interattività dell’utente. Invece, i dati sul “campo” sono costituiti dalle stesse metriche raccolte dalle esperienze utente effettive di navigazione sulle nostre pagine con i valori di timer dell’evento risultante trasmessi a un repository.

Le condizioni di utilizzo possono comportare punteggi estremamente variabili e gli score stessi possono letteralmente cambiare durante la navigazione delle pagine, motivo per cui dobbiamo capire come viene tabulato ogni punteggio rispetto un determinato ambiente e interpretare veramente i risultati solo dopo aver determinato per la prima volta se stiamo esaminando i dati di laboratorio o sul campo.

Le informazioni sugli strumenti

Possiamo accedere ai dati di laboratorio in tempo reale utilizzando PageSpeed Insights, WebPageTest , Chrome Dev Tools e tramite una nuova estensione del browser Chrome, “Web Vitals”. PSI e WebPageTest calcolano i punteggi dagli eventi di caricamento della pagina e approssimano i ritardi di interattività della pagina, contando i tempi delle attività di script di blocco dei thread.

Gli strumenti di lab data sono incredibilmente utili nel flusso di lavoro per la creazione di report e il miglioramento dei punteggi e “dovrebbero costituire parte del tuo arsenale di SEO tecnica”, consiglia l’autore.

È possibile introdurre la libreria Web Vitals JavaScript nel flusso di lavoro e nella pipeline di test; disponibile tramite CDN, la libreria può essere inclusa nell’HTML di produzione e scritta per trasmettere i dati dei campi raccolti in modo indipendente nel punto in cui desideriamo confrontarli per i report.

Lighthouse fornisce vari punti di accesso che possono essere utili nel workflow di sviluppo e include numerosi test aggiuntivi che possono aiutare a garantire la conformità ai moderni standard Web, e può aiutarci a eseguire il debug di situazioni in cui stiamo riscontrando e risolvendo problemi con i Web Vitals.

Il confronto tra risultati di laboratorio e i dati sul campo

I browser moderni, a cominciare da Chrome, misurano come gli utenti sperimentano effettivamente il nostro sito Web in natura tramite un’API JavaScript incorporato. Possiamo accedervi con qualsiasi JavaScript o scegliere una delle librerie di Google modificate in base alle nostre esigenze. Google raccoglie e, come detto, mostra i dati sul campo dagli utenti di Chrome per il suo rapporto CrUX e, a volte, utilizza le stesse API del browser.

Esistono diversi modi per accedere o visualizzare i dati CrUX: possiamo utilizzare connettori dall’output di BigQuery ad altri servizi Google per la generazione di dashboard, come il connettore predefinito per DataStudio. È più facile accedere ai dati sul campo quando il sito rientra in CrUX, dopo aver verificato la proprietà nella Google Search Console, perché la dashboard visualizza i dati dei campi con un’interfaccia che consente di eseguire il drill down con i clic anziché scrivere query SQL. In alternativa, possiamo semplicemente utilizzare il tool PSI, che fornisce dati che risalgono a un massimo di 28 giorni.

Troubleshooting dei report Web Vitals

A causa della natura dinamica di alcuni dei timing e del modo in cui vengono raccolti, dobbiamo sempre verificare i dati di laboratorio correlando i dati di campo in modo da poter eseguire il debug delle discrepanze. Ad esempio, i caricamenti di pagina successivi possono variare i valori dei risultati quando si utilizza l’estensione Web Vitals, e ciò può accadere per un paio di ragioni, ci spiega Johnson.

Il nostro browser è in grado di assemblare le risorse più velocemente sui refresh grazie all’utilizzo della propria riserva di cache; inoltre, l’estensione può accumulare valori interattivi durante la navigazione della pagina in un modo utile per approssimare i dati sul campo real world, anziché calcolare un punteggio aggiungendo i tempi di task di script thread-blocking.

Per risultati locali più accurati utilizzando l’estensione Web Vitals e Chrome Dev Tools bisogna ricordare di svuotare i dati della cache o bypassarli con shift-refresh quando ci muoviamo velocemente con il browser web nel workflow. Un altro suggerimento è caricare “about: blank” prima di iniziare una sessione di registrazione delle prestazioni in Dev Tools per un nuovo inizio del report.

A livello ideale, i punteggi di laboratorio e di campo non differiscono troppo senza una buona ragione. Ogni volta che si apportano modifiche significative, i risultati del laboratorio saranno in anticipo rispetto ai dati sul campo. Ciò significa che se visualizziamo test falliti sul campo e abbiamo superato i punteggi di laboratorio, dobbiamo pazientare che i dati sul campo vengano rilevati o inviare i dati sul campo ad Analytics in modo indipendente per verificarli.

Come gestire l’analisi delle tre metriche

Si potrebbe immaginare che il punteggio dei dati sul campo più difficile da emulare localmente sia CLS, ma secondo Johnson non è necessariamente vero: possiamo infatti impostare un’opzione per applicare una sovrapposizione di Web Vitals utilizzando l’estensione di Chrome in cui, quando interagisci con la pagina, guardare le modifiche dei punteggi mentre navighiamo.

Questa tecnica funziona anche per FID: il punteggio per questa metrica inizia vuoto; con la prima interazione sulla pagina (clic, scorrimento o input da tastiera), i tempi delle attività di blocco dei thread vengono aggiunti a quel momento, che diventa il punteggio.

Infine, le informazioni estremamente dettagliate in Chrome Dev Tools ci consentono di risolvere i problemi di CLS in modo particolareggiato con registrazione e riproduzione delle prestazioni. Dobbiamo cercare la sezione ” Experience ” che riproduce gli shift CLS nella registrazione, e c’è anche un’impostazione per evidenziare gli spostamenti sul display usando un flash blu che avvolge gli elementi mentre si spostano e si aggiungono al punteggio.

La misurazione dei Segnali Web Essenziali secondo Google

Sul tema è intervenuto anche Martin Splitt, Developer Advocate di Google, che dal suo profilo ufficiale su Twitter ha dedicato una decina di cinguettii (raccolti su seroundtable) per rispondere ad alcune richieste e dubbi sottoposti da vari utenti, in particolare sul metodo di analisi di Google per misurare i Web Vitals.

Nello specifico, Splitt ha spiegato che Googlebot, così come Lighthouse o lo stesso PageSpeed Insights, misura lab data, ovvero dati prestazionali ipotetici di un ambiente praticamente ideale. Quindi non sono dati rappresentativi di ciò che vedono i veri utenti del sito e delle pagine. Ma nel report Web Vitals della Google Search Console è possibile vedere metriche limitate (perché non tutti gli URL potrebbero avere sufficienti) ma rUM, ovvero basate sul campo, sul monitoraggio di utenti reali.

Ciò significa anche che eventuali bassi punteggi in questo strumento significa che le persone vere incontrano difficoltà con le pagine del sito e potrebbero avere scarsa UX, un elemento su cui intervenire. In conclusione, il Googler ci informa di una notizia importante: la valutazione della Page Experience non si servirà di lab data per misurare i Core Web Vitals (o almeno che la questione non è in programma).

Come ottimizzare i Core Web Vitals delle pagine del sito

L’adeguamento dei siti alle metriche dei Segnali web essenziali è stato in realtà lento, nonostante la spinta di Google – che ha come detto inserito i Core Web Vitals nel più ampio concetto di Page Experience, rendendo di fatto LCP, FID e CLS dei fattori di ranking ufficiali – e una ricerca statunitense di novembre 2020 rivelava che meno del 15% del campione analizzato soddisfa i benchmark e supera i criteri di valutazione sull’esperienza fornita agli utenti.

Quello che emerge dallo studio è che attualmente le aree più critiche sembrano essere LCP e CLS, e quindi velocità e stabilità del layout sono gli aspetti su cui concentrare gli sforzi e gli interventi di ottimizzazione del sito.

Per la SEO, però, ci sono anche altri aspetti da valutare: anche “se il tuo sito non soddisfa i benchmark di web vitals oggi, ciò non significa che non verrà classificato affatto”, sottolineava un articolo di Matt Southern su Search Engine Journal, perché “la Ricerca è complessa e i Core Web Vitals sono solo tre dei tanti fattori che Google prende in considerazione quando classifica le pagine”.

Ciò che resta prioritario ancora oggi è il contenuto, la sua qualità e la sua pertinenza rispetto alla query e al search intent, perché “una pagina più pertinente di solito vincerà su una pagina più veloce, ma con contenuti meno pertinenti”, chiosava Southern.
Ad ogni modo, è utile avere una serie di indicazioni e consigli per migliorare le prestazioni delle pagine e adeguare il sito ai nuovi fattori di ranking di Google.

Il lavoro su Segnali web essenziali e Page Speed Update

Entra più nei dettagli dei consigli di ottimizzazione del sito per questo cambiamento un altro approfondimento su Search Engine Journal (da cui sono tratte le successive immagini), curato da Rachel Costello, che individua sette aspetti della page experience per l’utente su cui concentrare le nostre attenzioni, come ad esempio i modi per assicurare un caricamento visivo più veloce e fluido, migliorare l’usabilità mobile e offrire una maggiore sicurezza del sito.

I nuovi fattori di ranking della Page Experience

Innanzitutto, è opportuno ricordare quali sono i diversi elementi che da giugno 2021 contribuiscono a determinare e valutare l’esperienza complessiva di una pagina, presi in considerazione da vari sistemi di ranking di Google:

• Segnali web essenziali. Le tre metriche chiave per valutare le prestazioni, che misurano il caricamento visivo, l’interattività e la stabilità visiva di una pagina durante il caricamento per gli utenti.
• Compatibilità con i dispositivi mobili. La capacità di un sito di essere mobile friendly, e quindi la sua facilità di utilizzo e di navigazione sui dispositivi mobili, inclusa la leggibilità dei contenuti e se i link e gli elementi della pagina sono cliccabili e accessibili.
• HTTPS. Si concentra sul fatto che la connessione di un sito Web sia sicura e se il sito viene servito, o meno, tramite il consigliato protocollo HTTPS.
• Interstitial non intrusivi. Assicura che i contenuti cruciali della pagina non siano ostruiti per gli utenti durante la navigazione da fastidiosi interstitial.

I 7 interventi per ottimizzare il sito per la Page Experience

Ecco dunque quali sono i consigli di Rachel Costello per farci trovare pronti all’appuntamento del prossimo maggio, ma non solo: il miglioramento dell’esperienza sulla pagina può avere effetti positivi sia a breve che a lungo termine, perché servirà a garantire che i nostri utenti possano vivere esperienze di qualità sulle nostre pagine.

Questo lavoro non riguarda infatti solo il soddisfare determinati criteri per i motori di ricerca, ma il tentativo di fornire le migliori esperienze possibili per gli utenti reali, che dovrebbe essere un obiettivo prioritario per qualunque sito.

1. Precaricare le risorse chiave per accelerare i tempi di caricamento visivo

Uno dei primi indicatori per un utente che una pagina sta caricando è l’apparizione di contenuti above the fold. È qui che entra in gioco il Largest Contentful Paint (LCP), la prima metrica Core Web Vitals per misurare la velocità con cui viene caricato l’elemento principale sulla pagina.

Per identificare qual è l’elemento LCP di una pagina è sufficiente ispezionare la pagina in Chrome DevTools e visualizzare il grafico a cascata nella scheda Performance. Dopo aver identificato l’elemento, lo stesso strumento offre un modo semplice per visualizzare l’avanzamento visivo della velocità di caricamento, profilando la pagina durante il processo e fornendo uno screenshot di come si carica nel tempo.

Chrome DevTools ‘Screenshots’ feature

Questo ci aiuterà a scoprire la velocità di caricamento dei diversi elementi della pagina.

Per accelerare il caricamento dell’elemento LCP e del contenuto above the fold, Costello suggerisce di valutare la possibilità di utilizzare metodi come il preloading per indicare al browser di recuperare prima queste risorse come una priorità.

2. Ottimizzare la main thread activity minimizzando i long task

Ci sono molti problemi diversi dietro le quinte che possono far sì che un utente debba attendere che il browser risponda dopo il clic o tap su una pagina: questo è ciò che viene misurato dalla seconda metrica Core Web Vitals, First Input Delay (FID).

Si tratta di un’esperienza che può essere frustrante per gli utenti, ma ci sono cose che possiamo fare per risolvere il problema e ridurre i tempi di attesa tra le interazioni umane e le risposte del browser.

I long taks sono uno dei più comuni “colpevoli” di questo problema: essenzialmente, sono pezzi di codice JavaScript che bloccano il thread principale per un lungo periodo di tempo e fanno sì che la pagina si blocchi e non risponda.

Le attività lunghe in Chrome DevTools si trovano nella parte superiore del grafico a cascata nella scheda Main e sono evidenziate con un triangolo rosso; facendo clic su un long task e andando nella scheda Bottom-Up, vedremo suddivise le diverse attività che si sono verificate all’interno dell’attività, come la compilazione e l’analisi degli script.

La correzione richiesta varierà a seconda delle attività che contribuiscono ai blocchi dei main thread, ma una soluzione comune per la risoluzione di attività lunghe è la suddivisione del codice e l’elaborazione di script in blocchi più piccoli.

3. Riservare spazio per il caricamento di immagini ed embeds

La terza metrica Core Web Vitals, il Cumulative Layout Shift (CLS), esamina la quantità di spostamento del layout visivo di una pagina durante il suo caricamento e misura un aspetto frustrante di UX che probabilmente abbiamo tutti sperimentato: abbiamo intenzione di fare clic su un link particolare, ma la pagina si sposta e finiamo per cliccare accidentalmente su un’area diversa della pagina.

Una delle cause più comuni di un punteggio CLS elevato, e quindi di una UX scadente, è non riservare spazi per il caricamento di immagini e risorse incorporate.

Nell’esempio fornito dall’articolo, la funzione screenshot di Chrome DevTools nella scheda Performance mostra “che il banner di consenso ai cookie di BBC Weather non ha uno spazio allocato per il caricamento”; quindi, una volta caricato, “spinge il contenuto visibile più in basso nel viewport intorno al segno di 3 secondi”. Bisogna invece prevedere uno spazio nella struttura della pagina, di modo che il suo layout resti invariato anche al termine del caricamento della risorsa.

4. Verificare che i modelli di pagina chiave siano mobile-friendly

Da quando il traffico mobile ha superato il volume da desktop nel 2016, è diventato fondamentale garantire che i siti Web fossero ottimizzati per i dispositivi mobili con cui un numero crescente di utenti stava effettivamente navigando.

Il layout e l’usabilità di un sito Web su un dispositivo mobile possono decidere le sorti dell’esperienza dell’utente: ad esempio, dice Costello, “gli utenti dovrebbero essere in grado di vedere i contenuti importanti in modo chiaro e accessibile, senza dover ingrandire”.

Esistono due modi principali per valutare l’usabilità del sito web sui dispositivi mobili: il primo è monitorare il rapporto Usabilità mobile in Google Search Console (che segnalerà problemi come contenuti che non si adattano allo schermo e testo troppo piccolo, oltre a mostrarci un elenco di URL interessati per ogni problema) ed eseguire i key page template nel test ottimizzazione mobile di Google, che è un buon modo per controllare le singole pagine.

5. Fare audit per la sicurezza del sito

Oltre alle prestazioni di caricamento e all’usabilità su dispositivi mobili, anche la sicurezza del sito gioca un ruolo nella determinazione dell’esperienza della pagina.

Google spinge per “assicurarsi che i siti Web presentati nelle SERP siano sicuri per la navigazione degli utenti, senza il rischio di problemi di sicurezza” come malware, software indesiderato, phishing e contenuti ingannevoli.

Un modo semplice per verificare se il nostro sito presenta problemi che potrebbero mettere a rischio gli utenti è il rapporto Problemi di sicurezza in Google Search Console.

6. Verificare che form e risorse incorporate siano serviti tramite HTTPS

Incorporare HTTPS come segnale di esperienza della pagina è un altro modo in cui Google sta cercando di garantire la sicurezza degli utenti durante la navigazione.

La pubblicazione di contenuti che richiedono l’interazione e l’input dell’utente su una connessione HTTP non sicura rappresenta un rischio per gli utenti e rende loro (e i loro dati) più vulnerabili.

Questo aspetto è da ricordare soprattutto per i form in cui gli utenti inseriscono informazioni personali, come i checkout in cui vengono condivise le informazioni di pagamento.

Eseguire un audit SEO per la sicurezza ci permette di verificare la presenza di questi problemi, e anche in SEOZoom c’è uno strumento specifico per scoprire se il sito ha “mixed content”, ovvero contenuti misti con una combinazione di risorse di pagina servita sia su HTTP che su HTTPS.

7. Controllare che gli interstitial non ostruiscano i contenuti cruciali

Se un sito ha interstitial invadenti che occupano molto spazio su una pagina e rendono difficile per gli utenti accedere a contenuti importanti, questo può creare esperienze negative e frustranti.

 Un esempio di un interstitial invadente a sinistra, accanto a un pop-up non invadente a destra

Esaminando manualmente le pagine su dispositivi diversi o utilizzare ancora la funzione screenshot di Chrome DevTools ci permette di visualizzare in che modo gli interstitial potrebbero avere un impatto sui nostri utenti.

Il nostro obiettivo deve essere evitare di interrompere le esperienze di navigazione degli utenti: possiamo valutare la possibilità di riprogettare i popup e gli interstitial in modo che non ostruiscano i contenuti importanti sulla pagina, così come intervenire per consentire alle persone di non dover chiudere manualmente questi annunci per poter continuare il loro viaggio sul sito.

Lo studio su Core Web Vitals e siti: sei mesi dopo l’annuncio poca attenzione

Tornando ai dati del primo studio sull’applicazione dei Core Web Vitals a distanza di sei mesi dalla loro introduzione, Southern rivela come solo “una percentuale decisamente piccola di siti Web è in grado di superare una valutazione dei Segnali Web Essenziali all’interno di PageSpeed Insights”.

Per la precisione, osservando nel complesso i parametri indicati da Google solo “il 12% dei risultati su dispositivi mobili e il 13% su desktop hanno superato la valutazione”, anche se le performance dei siti sono un po’ migliori “quando si tratta di soddisfare i benchmark per un singolo fattore”.
Nello specifico, per il First Input Delay “il 99% degli URL desktop e l’89% degli URL mobili soddisfano il benchmark di 100 millisecondi”, e questo “è un buon segno per gli utenti, poiché significa che saranno in grado di interagire immediatamente con quasi tutte le pagine su cui arrivano”.

Più problematici gli altri due parametri: per il Largest Contentful Paint “il 43% degli URL per dispositivi mobili e il 44% degli URL desktop supera la valutazione” e quindi carica il contenuto principale in meno di 2,5 secondi. Per il Cumulative Layout Shift superano la valutazione di 0,1 “il 46% degli URL per dispositivi mobili e il 47% degli URL desktop”.

Ciò significa, quindi, che “la maggior parte delle pagine su cui atterrano gli utenti impiega più di 2,5 secondi per caricarsi e mostra cambiamenti di layout imprevisti”, fornendo quindi una esperienza non ottimale alle persone, che devono “aspettare il caricamento di una pagina mentre il contenuto oscilla su e giù per lo schermo”.

Core Web Vitals: ancora nel 2022 solo un sito su 5 supera tutte le soglie

A confermare che quella che doveva essere una “rivoluzione algoritmica” – un update in grado di stravolgere le classifiche e di misurare, per la prima volta dati alla mano, le vere prestazioni dei siti rendendole fattori di ranking – ha avuto al momento un impatto meno roboante del previsto è anche il successivo aggiornamento dell’analisi di Milestone Research sui Core Web Vitals, che nell’agosto 2022 ha fatto il punto sulla reale quota di superamento dei benchmark da parte dei siti.

Il dato che emerge subito è che solo il 20% dei siti supera le soglie minime fissate da Google e assicura una grande esperienza utente secondo i criteri di qualità basati sulla misurazione precisa di aspetti essenziali delle performance tecniche di un sito.

Infatti, la maggior parte dei siti non sembra lavorare con molta priorità sul miglioramento di questi parametri, e secondo Milestone non c’è stato alcun miglioramento di rilievo nei settori industriali presi in esame, che portano al dato (piuttosto sconfortante) che a giugno 2022 solo il 19% dei siti studiati sono davvero pronti per tutti e tre i CWV.

Detto in altri termini: solo un sito ogni cinque, di quelli presi in esame dalla ricerca, supera le soglie stabilite da Google per le tre metriche che compongono i Segnali Essenziali Web, ovvero Largest Contentful Paint (LCP), First Input Delay (FID) e Cumulative Layout Shift (CLS), che rispettivamente prendono in esame e misurano le risposte della pagina rispetto a velocità di caricamento, interattività e stabilità visiva.

Come sappiamo, questi Core Web Vitals si applicano a tutte le pagine web, possono (e dovrebbero) essere misurati da tutti i proprietari di siti e sono controllabili da vari strumenti di Google; ognuno di loro rappresenta un aspetto distinto dell’esperienza dell’utente, è misurabile sul campo e riflette l’esperienza nel mondo reale di un risultato critico incentrato sull’utente.

La ricerca di Milestone sui CWV: siti ancora molto indietro su performance e UX

Per fare il punto sull’effettiva applicazione dei CWV, Milestone Inc. ha effettuato più volte il crawling di circa mille siti e 331.000 pagine di siti attivi in settori come servizi finanziari, aziende B2B, sanità, hotel, ristoranti e produzione, raccogliendo dati sulle prestazioni di tutte le pagine del sito.

La media è stata calcolata e misurata rispetto allo standard di performance raccomandate per LCP, FID e CLS, e i siti sono stati classificati in Veloci, Medi e Lenta (Fast, Average, Slow) in ciascuna delle tre metriche; i risultati aggregati sono stati poi riportati a media per ottenere una classificazione complessiva, con possibili giudizi di Buono, Da migliorare o Sotto l’obiettivo (Good, Needs Improvement, Below Target).

A livello generale, gli esperti americani sono rimasti piuttosto sorpreso nel constatare che la quota di siti Core Vitals completamente soddisfatti era in realtà diminuita rispetto all’analisi di ottobre 2021, compiuta sullo stesso campione di siti web: ciò significa che, in poco più di sei mesi, alcuni siti che soddisfacevano lo standard non sono più conformi ai Core Web Vitals, un segno di assenza di misurazione e manutenzione costante dei siti in questione.

Tuttavia, c’è stato un miglioramento significativo per la maggior parte dei siti web nel First Contentful Paint (che però non rientra tra i CVW).

Tra i fattori che causano più frequentemente problemi con le prestazioni ci sono: nuovi contenuti non ottimizzati aggiunti al sito web, come immagini e video, javascript di terze parti e pixel di tracciamento, messaggi pop-up o animazioni che creano spostamenti, o processi di back-end, come la personalizzazione, che riducono la velocità di caricamento.

Nello specifico, il report rivela che il 62% dei siti ha registrato un buono o minimo cumulative layout shift dei contenuti nel 90% o più delle pagine, con un calo di 5 punti rispetto all’ottobre 2021; ad un esame più approfondito, molti di questi siti sembrano trarre vantaggio da design semplici, che utilizzano immagini statiche e nessun video o popup.

Il First Contentful Paint e il Largest Contentful Paint sono i parametri in cui l’esame ha riscontrato i miglioramenti più significativi: meno dell’1% dei siti carica tutti i contenuti primari in meno di 1 secondo e solo il 41% ha iniziato a caricare FCP nel 75% delle pagine in meno di 1 secondo; rispetto al LCP, invece, il 28% dei siti ha caricato i contenuti in meno di 2,5 secondi.

Infine, vanno un po’ meglio le cose rispetto alla interattività della pagina, perché il 98% dei siti ha registrato un First Input Delay accettabile, inferiore a 0,1 secondi.

Core Web Vitals, un fattore di ranking sbiadito

Un’analisi sulla diffusione concreta dei Core Web Vitals arriva anche da Advancedwebranking, che ha eseguito uno studio su un campione di siti molto più ampio del precedente (3 milioni di pagine web dai primi 20 risultati di ricerca di Google) per verificare anche quanto influiscono le prestazioni delle pagine per il posizionamento nella ricerca organica di Google e quale delle metriche di Core Web Vitals è maggiormente correlata a un posizionamento in prima pagina.

In breve, il report rileva che:

• Più alto è il ranking su Google, più bassa è la metrica LCP.
• Solo il 39% delle pagine web analizzate ha superato le metriche Core Web Vitals, mentre il restante 61% era al di sotto della soglia.
• L’80% delle pagine che superano Core Web Vitals su desktop le passano anche su dispositivi mobili .
• I Core Web Vitals sono un fattore di ranking, ma non importante quanto i link, il contenuto o l’intento di ricerca.

Premettendo che, come spesso avviene con le considerazioni che riguardano la SEO, non è possibile correlare determinati fattori con le classifiche effettive di Google e “correlazione non significa causalità” (ovvero, solo perché due cose sono correlate non significa necessariamente che una causi l’altra), ci sono comunque alcuni elementi su cui soffermarsi.

Per quanto riguarda LCP – che, per garantire una buona esperienza utente, dovrebbe verificarsi entro 2,5 secondi dall’inizio del caricamento della pagina – nessuna delle 3 milioni di pagine campionate ha un LCP medio inferiore a 2,5 secondi, ma (dato interessante) i grafici per mobile e desktop mostrano chiaramente che “maggiore è la posizione su Google, minore è la metrica LCP”.

Va meglio, anche in questo caso, analizzando il FID (dove il buono è 100 millisecondi o meno), perché tutte le pagine testate riescono a raggiungere l’obiettivo; tuttavia, notano gli esperti, la differenza nei valori FID tra le prime 20 posizioni non è così grande e non c’è una chiara correlazione tra FID e ranking.

Difficile valutare gli effetti sul ranking del CLS (che deve essere di 0,1 o inferiore per una buona esperienza utente), perché sembra esserci una leggera tendenza visiva che mostra che le classifiche nelle prime posizioni hanno un CLS più basso, ma la differenza tra i valori CLS non è così grande da giustificare una chiara correlazione.

In definitiva, secondo lo studio di Advancedwebranking i Core Web Vitals non sono un fattore di ranking fondamentale su Google, ma possono diventare importanti quando le pagine concorrenti nella Ricerca ottengono buoni punteggi per tutti gli altri fattori rilevanti.

Riprendendo alcune considerazioni di John Mueller, poi, gli esperti spiegano che i CWV sono comunque più di un fattore tie-breaker (un elemento che rompe l’equilibrio a parità di condizioni) e che servono anche a valutare se ci sono possibili ostacoli nel percorso degli utenti, perché considerano l’usabilità del tuo sito dopo che si è classificato (quando le persone effettivamente lo visitano): se ottieniamo più traffico grazie agli sforzi SEO ma il tasso di conversione è basso, quel traffico non sarà così utile come potrebbe essere. Di solito, sono proprio elementi di user experience o velocità che influenzano il tasso di conversione, e quindi analizzare i CWV e correggere le zone problematiche “è un ottimo modo per riconoscere e quantificare i fastidi comuni degli utenti”.