L’utente e la sua esperienza al centro della SEO, o quanto meno in una posizione di rilievo, insieme ai contenuti e agli altri aspetti che concorrono a determinare il posizionamento delle pagine su Google: è partito proprio oggi il Page Experience Update, l’aggiornamento algoritmico con cui Google introduce come fattore di ranking una serie di elementi tecnici che valutano le prestazioni delle pagine dei siti rispetto all’esperienza fornita agli utenti. Proviamo a fare una ricapitolazione generale su questo importante update e sui metodi per calcolare i punteggi delle metriche (dove ci sono alcune novità).

La lunga attesa verso il nuovo aggiornamento dei fattori di ranking

Lo attendiamo da oltre un anno, da quando Google introdusse il nuovo set di metriche che avrebbe usato per calcolare le prestazioni delle pagine Web che influiscono sulla qualità della user experience, che poi abbiamo imparato a chiamare con il nome di Core Web Vitals o Segnali Web Essenziali. Sempre nel 2020, poi, abbiamo scoperto che queste metriche sarebbero diventate un fattore di ranking insieme ad altri elementi tecnici, in quello che è stato chiamato appunto Google Page Experience Update, inizialmente previsto per maggio 2021 e poi slittato fino alla metà di giugno.

Annuncio Google Page Experience

Ed è proprio qui che siamo ora, pronti a vedere gli effetti concreti di questa “rivoluzione algoritmica” in termini di variazioni di ranking per i nostri progetti, nella consapevolezza che, per scelta precisa del motore di ricerca, l’esperienza sulle pagine non sarà completamente integrata nei sistemi di ranking di Google prima della fine di agosto. Questo per quanto riguarda i dispositivi mobile, mentre l’update per le pagine desktop dovrebbe essere lanciato completamente prima della fine dell’anno.

Il panorama attuale del Web è ancora di grande arretratezza rispetto a questi temi: una recente ricerca di Conductor e Digital Marketing Depot rivela che solo il 13% dei siti analizzati in tre industrie chiave quali Retail, Tech e Finance/Insurance soddisfano i benchmark dei Core Web Vitals.

Introduzione al Page Experience Update

Può essere utile, a questo punto, riepilogare cosa sia effettivamente l’aggiornamento per l’esperienza sulle pagine nei risultati della Ricerca Google (traduzione dalle pagine di supporto ufficiali di Big G), rifacendoci alle indicazioni di Patrick Kettner, Developer Advocate della compagnia, che in una nuova serie di video sul canale YouTube Google Search Central ci offre una completa panoramica sul tema.

Google spiega cos'è Page Experience update

Il primo episodio è incentrato comprensibilmente sulle definizioni: il Page Experience Update è “un nuovo input per il ranking di Google Search”, che valuta “quanto sia effettivamente buona per gli utenti l’esperienza su ogni pagina del Web”. Google ha “sempre detto che la user experience è essenziale per il posizionamento nella ricerca” e ora, “grazie ai progressi nelle capacità dei browser, possiamo elencare con fiducia qualsiasi contenuto nel carosello delle top stories e nei normali risultati di ricerca”, e sviluppatori e proprietari di siti hanno riferimenti tecnici precisi da seguire per offrire pagine conformi agli standard.

Metriche oggettive per misurare le performance

Uno degli aspetti più rilevanti di questo aggiornamento sta nel fatto che, finora, “il concetto di web performance è sempre stato soggettivo”: ciò che è veloce sul mio computer, dice Kettner, “può essere inaccettabilmente lento per le persone che usano il sito”.

Invece, la Page Experience “ci permette di concentrarci su queste persone e assicurarci che stiano effettivamente sperimentando il sito in un modo che soddisfa anche noi”. In pratica, “stabilisce un obiettivo di base verso cui i team possono lavorare allo sviluppo per assicurarsi che gli utenti stiano avendo un’ottima UX”.

La novità è che questo aggiornamento guarda e misura proprio l’esperienza dell’utente: le metriche che compongono la Page Experience “sono, in parte, raccolte dal Chrome User Experience Report, un insieme di dati pubblici che mostra quanto velocemente o meno milioni di URL su internet sono stati caricati e si sono comportati sui dispositivi reali delle persone reali”.

Quali metriche compongono il fattore di ranking Page Experience

All’interno di questo complesso fattore di ranking ci sono in realtà due diversi gruppi di metriche.

Il primo è composto da elementi definiti come “valori booleani”, ovvero “cose che si hanno o non si hanno”: mobile friendliness, pagine con protocollo HTTPS, navigazione sicura, assenza di annunci interstitial intrusivi.

I 4 valori booleani del Page Experience

Il secondo gruppo contiene invece “metriche che valutano la tua pagina in base a quelle che sono le esperienze dei vostri utenti reali sui loro dispositivi reali”, ovvero i Core Web Vitals, definiti come “un elenco, aggiornato annualmente, di metriche che definiscono ciò che serve per avere quella grande esperienza utente di cui stiamo parlando”. Attualmente, come sappiamo, i primi tre Segnali Web Essenziali individuati da Google sono First Input Delay, Largest Contentful Paint e Cumulative Layout Shift.

Il significato della Page Experience

In conclusione, Kettner spiega che la Page Experience “consiste nel lavorare per garantire che i tuoi utenti ottengano ciò che vogliono nel miglior modo possibile”: offre dati e rapporti personalizzati in base agli utenti reali delle pagine, e quindi mette in luce aspetti concreti e problematici che possiamo migliorare.

Dobbiamo però comprendere un aspetto importante: la Page Experience “riguarda ciò che l’utente sta effettivamente sperimentando e non è qualcosa che si si applica a tutto il tuo sito web”; ogni utente usa il sito in modo diverso, mentre ogni singolo URL viene esaminato individualmente.

Per chiarire questo punto, Kettner invita a controllare il Page Experience Report in Search Console (Rapporto Esperienza con le pagine), che “dà una visione impressionante su quali parti del sito hanno bisogno di più lavoro”: ad esempio, la home page “potrebbe avere risultati fantastici, ma le tue pagine di contenuto potrebbero essere meno che ideali”. E questo potrebbe portare a posizionamenti alti per la home, mentre le altre pagine restano indietro.

Ma “la grande notizia è che niente di tutto questo è una scatola nera: tutti i Core Web Vitals sono estratti mensilmente dal Chrome User Experience Report”, e quindi tutti possono monitorarli e verificarli.

Google aggiorna gli strumenti per misurare i Core Web Vitals

Il Page Experience Update è concepito per dare risalto alle pagine che offrono esperienze utente ottime, ma questo aspetta resta comunque “solo” uno dei diversi fattori che vengono presi in considerazione dai sistemi di Google: tradotto in altri termini, non è detto che l’aggiornamento porti davvero a stravolgimenti delle classifiche e, inoltre, vista la sua implementazione graduale, potrebbero non esserci scossoni immediati e Google sarà comunque in grado di monitorare eventuali problemi imprevisti o indesiderati.

E la natura progressiva di questo update si nota anche dal fatto che, proprio nelle ultime settimane, Google ha aggiornato alcuni metodi con cui misura queste metriche per includere formule affilate in risposta ai casi portati dagli sviluppatori sul campo.

L’articolo di Detlef Johnson su Search Engine Land ci aiuta a orientarci in questo scenario complesso, spiegando come usare i lab data e i field data per l’ottimizzazione per la Page Experience.

Come funzionano le misurazioni dei Segnali Web Essenziali

I Core Web Vitals sono metriche di grandi prestazioni relative alla velocità, che determinano il raggiungimento di “un’esperienza stabile, visualizzabile e utilizzabile per una data viewport del dispositivo e inclusi contenuti offscreen fino a 9000 pixel verticali”.

Più veloce è meglio, com’è semplice intuire, e pertanto in linea di massima valutazioni delle metriche più basse sono migliori.

I dati sul campo, che sono presi in considerazione per il ranking, variano a seconda della potenza del dispositivo dell’utente reale, delle dimensioni dello schermo e della connettività di rete. I dati di laboratorio hanno valori predefiniti per questi e, tranne nel caso di Page Speed ​​Insights, possono essere calibrati dagli sviluppatori per simulare tutti i tipi di condizioni; questi lab data non vengono considerati per le classifiche.

Le modifiche al First Contentful Paint

Anche se non è inserito ufficialmente nei primi tre CWV, i componenti del First Contentful Paint (FCP) contribuiscono comunque ai segnali web essenziali: di recente, la soglia per ottenere un punteggio di “buono” è aumentata da 1,0 a 1,8 secondi.

FCP tiene conto di Time to First Byte (che rappresenta più un riflesso del tempo di risposta del server che qualcosa che si possa manipolare direttamente con il codice) e del tempo necessario per elaborare le risorse di blocco del rendering come il CSS.

Le modifiche al Largest Contentful Paint

Piccole modifiche sono giunte anche riguardo al Largest Contentful Paint, che è “una pietra miliare significativa nel ciclo di vita di una pagina”: originariamente, la metrica non includeva alcuni elementi fuori schermo, mentre invece ora individua l’elemento più grande anche se successivamente è stato rimosso dalla pagina DOM una volta scoperto, o quando si qualificano più immagini della stessa dimensione.

Queste situazioni si verificano quando i caroselli caricano e memorizzano nella cache il contenuto per le slide fuori schermo.

Un’altra modifica utile è che ora LCP ignora le immagini di sfondo.

Le modifiche al Cumulative Layout Shift

Novità, infine, per il CLS: per evitare che situazioni quali sessioni di navigazione estremamente lunghe compromettano i punteggi di questa metrica, le sessioni di “finestra” più piccole sono limitate a 5 secondi, contrassegnate come terminate da un intervallo di 1 secondo come limite per trovare i 5 peggiori secondi di spostamento del layout della pagina.

Questa sembra essere una rappresentazione “molto migliore del cambiamento rispetto al conteggio di sessioni completamente scoperte che possono durare 20 minuti o più e dare punteggi che sono esagerati e fuori proporzione.

L’utilità dei dati di PageSpeed Insights

Secondo Johnson, il trucco per ottimizzare le pagine per i Core Web Vitals sta “nell’imparare più di un modo ufficiale per recuperare i punteggi, che diventa ulteriormente complicato da come pensare ai dati che stai visualizzando”.

Anche Page Speed ​​Insights, spesso il primo riferimento per i professionisti SEO, non fornisce da solo informazioni sufficienti per “raccontare l’intera storia”: il tool è infatti progettato per “fornire un’istantanea completa agli sviluppatori per la risoluzione dei problemi di prestazioni”; quando disponibili da CrUX, i dati di campo aggregati su un precedente periodo di 4 settimane sono utili per fare confronti, ma l’aspetto dei dati di laboratorio e di campo mostrerà senza dubbio una differenza tra i due report.

La varianza è infatti “un evento naturale tra le sessioni di test e quando si confrontano i test di diversi dispositivi e/o reti”: i dati sul campo variano quindi tanto quanto il pubblico di un determinato sito web. I field data PSI, quindi, “rappresentano un intervallo di dati, aggregati nei 28 giorni precedenti, fino al valore dell’intera giornata completata più di recente”.

Quando attendersi i cambiamenti di ranking (e quali range temporali saranno esaminati)

L’autore dice quindi che il fattore di ranking Page Experience “potrebbe presumibilmente fare affidamento sugli stessi punteggi aggregati dei precedenti 28 giorni”, ma è improbabile, “poiché sarebbe molto più performante se si basasse invece sul set di dati BigQuery aggregato preparato per 28 giorni del mese precedente”.

Ciò significa, quindi, che “eventuali modifiche alla classifica avranno effetto il secondo martedì di ogni nuovo mese”.

In questo modo, i dati BigQuery per i rapporti CrUX sarebbero “sottoposti a un processo di ottimizzazione delle prestazioni che prepara i dati del mese precedente per il consumo pubblico”. Al momento, tale indicizzazione, e possibilmente la memorizzazione nella cache di determinate risposte alla query, consente “agli utenti di CrUX di eseguire query in modo storico fino alla fine del 2017, quando i dati sono stati raccolti per la prima volta”.

La differenza pratica tra lab data e field data

Johnson approfondisce ulteriormente il complesso tema della differenza tra dati di laboratorio e sul campo, ricordando che i punteggi di Lighthouse Lab in PSI sono “calibrati per essere rappresentativi dei tuoi percentili superiori” per gli scenari peggiori, come quello di browser poco potenti su reti lente. Con questa scelta, Google intenzionalmente fa in modo che gli sviluppatori abbiano un feedback più ricco per risolvere più facilmente le aree problematiche che possono verificarsi, anche se tali situazioni sono meno comuni nel mondo reale.

Se i punteggi di laboratorio fossero “indicativi di condizioni più medie, non rivelerebbero i colli di bottiglia delle prestazioni che gli sviluppatori devono vedere per apportare modifiche per migliorare l’esperienza della pagina in condizioni di stress”.

Al contrario, i dati sul campo forniscono esempi di utilizzo nel mondo reale, e più precisamente “sono indicativi del pubblico registrato dai browser con l’utilizzo reale del tuo sito web”. Sono importanti “perché sono ciò che Google utilizza per il fattore di ranking dell’esperienza con la pagina”.

Quasi sempre, i punteggi dei dati sul campo saranno migliori dei punteggi dei dati di laboratorio per la stessa pagina. Inoltre, i dati sul campo possono “restare stabili nel tempo una volta preparati per prestazioni di archiviazione a lungo termine, con dati recenti preparati di recente su base mensile, mentre i dati di laboratorio possono differire a ogni nuovo test”.

Quando i browser hanno le autorizzazioni necessarie per trasmettere i punteggi, i field data vengono inviati e raccolti per l’uso da parte di PSI, di qualsiasi strumento Core Web Vitals che utilizza l’API aperta CrUX o per coloro che scrivono Core Web Vitals JavaScript nelle pagine web. L’unico modo per esaminare i dati del campo in tempo reale è “optare per scrivere il codice JavaScript e raccoglierlo per uso personale in una console o repository del browser, o inviarlo a Google Analytics”.

Usare i lab data per l’ottimizzazione

Il progetto Lighthouse open source alimenta i dati di laboratorio, è stato implementato in Dev Tools e può anche essere installato in un pacchetto fornito con il proprio Command Line Interpreter (CLI). Lighthouse in Dev Tools può essere configurato in modo che corrisponda a potenza e velocità ridotte o aumentate rispetto all’impostazione predefinita “percentile superiore”: in concreto, potremmo simulare potenza e velocità variabili, ad esempio, se abbiamo i mezzi per fornire esperienze più elaborate a determinate soglie simulate, implementando una strategia di miglioramento progressivo.

Le considerazioni finali

In definitiva, dovremmo interessarci davvero a risolvere i problemi e migliorare i fattori di prestazione che influenzano la page experience, anche se non siamo sviluppatori o non ci preoccupiamo della SEO, perché questi elementi “sono incredibilmente importanti per il modo in cui le nostre pagine e le applicazioni che eseguono il rendering delle pagine, comprese le applicazioni native con WebView, vengono vissute dagli utenti reali sul campo”.

Troppo spesso, un’app che riceve un utilizzo intenso si traduce in innumerevoli ore di frustrazione e può avere un impatto negativo sui profitti: ad esempio, Detlef Johnson racconta un’esperienza personale con “le app native del NYTimes su schermi delle dimensioni di smartphone, che caricano contenuti e script lentamente anche nelle migliori condizioni di rete”. Ciò comporta ritardi nello scorrimento e nel clic anche dopo il rendering di una notizia principale nella finestra; inoltre, “può essere davvero terribile navigare in continui cambiamenti di layout quando gli annunci vengono caricati in momenti ritardati”.

Google ha molti casi di studio che mostrano l’effetto positivo sulle entrate generato dall’implementazione delle correzioni delle prestazioni, che portano a esperienze più positive. Tornando all’esempio del noto quotidiano, Johnson conclude che “se non fosse per il valore dei contenuti del NYTimes, la loro app potrebbe essere ulteriormente derisa e subire un utilizzo molto inferiore rispetto a quello di cui gode attualmente”.