Come sono calcolate le soglie dei Core Web Vitals da Google
I Core Web Vitals sono un insieme di metriche di campo che misurano quindi giornalmente aspetti importanti dell’esperienza utente reale sul Web. Core Web Vitals includono metriche, nonché soglie target per ciascuna metrica, che aiutano gli sviluppatori a capire qualitativamente se l’esperienza del loro sito è :
- “Buona”
- “Necessita di miglioramenti”
- “Scarsa”
Questo post spiegherà l’approccio utilizzato per scegliere le soglie per le metriche Core Web Vitals in generale da parte di Google, e come sono state scelte le soglie per ogni specifica metrica Core Web Vitals.
Aggiornamento: metriche e soglie di Core Web Vitals #
Nel 2020 i Core Web Vitals erano tre metriche: Largest Contentful Paint (LCP), First Input Delay (FID) e Cumulative Layout Shift (CLS). Tutt’ora sono le metriche più importanti,
Ciascuna metrica misurava un aspetto diverso dell’esperienza dell’utente:
LCP misura la velocità di caricamento percepita e segna il punto nella sequenza temporale di caricamento della pagina in cui è probabile che il contenuto principale della pagina sia stato caricato;
FID misura la reattività e quantifica l’esperienza che gli utenti provano quando provano a interagire per la prima volta con la pagina;(ad esempio toccando un pulsante)
CLS misura la stabilità visiva e quantifica lo spostamento di layout imprevisto del contenuto della pagina visibile.
Ogni metrica Core Web Vitals ha soglie temporali associate, che classificano le prestazioni come “buone”, “da migliorare” o “scarse”:
| Buono | Scarso | Percentile | |
| Largest Contentful Paint | ≤2500ms | >4000ms | 75 |
| First Input Delay | ≤100ms | >300ms | 75 |
| Cumulative Layout Shift | ≤0.1 | >0.25 | 75 |
Inoltre, per classificare le prestazioni complessive di una pagina o di un sito, google utilizza il 75° percentile di tutte le visualizzazioni di pagina per quella pagina o sito. In altre parole, se almeno il 75% delle visualizzazioni di pagina di un sito soddisfa la soglia “buono“, il sito viene classificato come con rendimento “buono” per quella metrica. Al contrario, se almeno il 25% delle visualizzazioni di pagina soddisfa la soglia “scarsa”, il sito viene classificato come con prestazioni “scarse”. Quindi, ad esempio, un LCP del 75° percentile di 2 secondi è classificato come “buono“, mentre un LCP del 75° percentile di 5 secondi è classificato come “scarso“.
Criteri per le soglie della metrica Core Web Vitals #
Quando Google ha stabilito le soglie per le metriche Core Web Vitals, ha innanzitutto identificato i criteri che ciascuna soglia doveva soddisfare. Di seguito, spieghiamo i criteri che hanno utilizzato in Google per valutare le soglie metriche 2020 Core Web Vitals. Le sezioni successive approfondiranno il modo in cui questi criteri sono stati applicati per selezionare le soglie per ciascuna metrica nel 2020. Negli anni sono stati prevediamo apportati miglioramenti e aggiunte ai criteri e alle soglie per migliorare ulteriormente la capacità di misurare le esperienze utente eccezionali .
Esperienza utente di alta qualità #
Quando ottimizziamo i siti web, il nostro obiettivo principale è ottimizzare per l’utente e la sua qualità dell’esperienza. Detto questo, miriamo a garantire che le pagine che soddisfano le soglie “buone” di Core Web Vitals offrano un’esperienza utente di alta qualità.
Per identificare una soglia associata a un’esperienza utente di alta qualità, Google guarda alla percezione umana e alla ricerca HCI(interfaccia uomo-macchina).
Mentre questa ricerca è talvolta riassunta utilizzando un’unica soglia fissa, Google la interpreta come un intervallo tra valori. Ad esempio, la ricerca sulla quantità di tempo che gli utenti in genere aspettano prima di perdere la concentrazione è talvolta descritta come 1 secondo, mentre la ricerca si esprime come un intervallo, da centinaia di millisecondi a più secondi.
Il fatto che le soglie di percezione varino a seconda dell’utente e del contesto, è ulteriormente supportato dai dati aggregati e resi anonimi dalle metriche di Google Chrome, che mostrano che non c’è un solo periodo di tempo in cui gli utenti aspettano che una pagina web visualizzi il contenuto prima di interrompere il caricamento della pagina.
Piuttosto, questi dati mostrano una distribuzione regolare e continua. Per uno sguardo più approfondito alle soglie di percezione umana e alla ricerca HCI pertinente, se vuoi approfondire leggi The Science Behind Web Vitals.
Nei casi in cui per una determinata metrica fosse disponibile una ricerca pertinente sull’esperienza utente e vi fosse un ragionevole consenso sull’intervallo di valori in letteratura, Google utilizza questo intervallo come input per guidare il processo di selezione della soglia.
Nei casi in cui la ricerca sull’esperienza utente non è disponibile, (ad esempio per il parametro Cumulative Layout Shift) Google valuta le pagine del mondo reale che soddisfano diverse soglie candidate per una metrica, per identificare una soglia che si traduca in una buona esperienza utente.
Raggiungibile da contenuti web esistenti #
Inoltre, per garantire che i proprietari dei siti possano riuscire a ottimizzare i loro siti web per raggiungere le soglie “buone“, Google richiede che tali soglie siano raggiungibili per i contenuti esistenti sul Web. Ad esempio, mentre zero millisecondi è una soglia “buona” per un LCP ideale, che si traduce in esperienze di caricamento istantanee, una soglia di zero millisecondi non è praticamente realizzabile nella maggior parte dei casi, a causa delle latenze di elaborazione della rete e del dispositivo. Pertanto, zero millisecondi non è una soglia “buona” per un LCP ragionevole per i Core Web Vitals.
Quando Google valuta le soglie di Core Web Vitals come “buone” per un sito web, viene verificato che tali soglie siano raggiungibili, in base ai dati del Rapporto sull’esperienza utente di Chrome (CrUX). Per confermare che una soglia sia raggiungibile, è richiesto che almeno il 10% delle pagine soddisfi attualmente la soglia “buono”. Inoltre, per garantire che sia ben ottimizzato i siti non vengono classificati in modo errato a causa della variabilità dei dati sul campo, Google verifica anche che i contenuti ben ottimizzati soddisfino costantemente la soglia “buono”.
Al contrario, Google stabilisce la soglia come “scadente” individuando un livello di performance che attualmente solo una minoranza di pagine non raggiunge. A meno che non siano disponibili ricerche pertinenti per definire una soglia “scarsa”, per impostazione predefinita il 10-30% delle pagine con le peggiori prestazioni è classificato come “scadente”.
Considerazioni finali sui criteri #
Durante la valutazione delle soglie per alcune pagine, si è riscontrato che i criteri erano talvolta in conflitto tra loro. Ad esempio, può esserci una discrepanza tra il fatto che una soglia sia costantemente raggiungibile e garantisca allo stesso tempo esperienze utente costantemente positive.
Inoltre, dato che la ricerca sulla percezione umana in genere fornisce una gamma di valori e le metriche sul comportamento degli utenti mostrano cambiamenti graduali nel comportamento, Google ha scoperto che spesso non esiste un’unica soglia “corretta” per una metrica. Pertanto, l’approccio per i Core Web Vitals è stato quello di scegliere le soglie che soddisfano al meglio i criteri di cui sopra, pur riconoscendo che non esiste una soglia perfetta e che a volte potrebbe dover scegliere tra più soglie di pagine ragionevoli.
Piuttosto che chiederci “qual è la soglia perfetta?” Ci siamo invece concentrati sulla domanda “quale soglia di candidato soddisfa meglio i nostri criteri?”
Bryan McQuade Google dev
Scelta del percentile #
Come notato in precedenza, per classificare il rendimento complessivo di una pagina o di un sito, Google utilizza il valore del 75° percentile di tutte le visite per una tale pagina o sito. Il 75° percentile è stato scelto sulla base di due criteri. In primo luogo, il percentile dovrebbe garantire che la maggior parte delle visite a una pagina o a un sito abbia raggiunto il livello di rendimento target. In secondo luogo, il valore al percentile scelto non dovrebbe essere eccessivamente influenzato da valori anomali.
Questi obiettivi sono in qualche modo in contrasto tra loro. Per soddisfare il primo obiettivo, un percentile più alto è in genere una scelta migliore. Tuttavia, con percentili più elevati, aumenta anche la probabilità che il valore risultante sia influenzato da valori anomali. Se alcune visite a un sito avvengono su connessioni di rete instabili che si traducono in campioni LCP eccessivamente grandi, non vogliamo che la classificazione di un sito sia decisa da questi campioni anomali. Ad esempio, se stessimo valutando il rendimento di un sito con 100 visite utilizzando un percentile elevato come il 95°, sarebbero necessari solo 5 campioni anomali affinché il valore del 95° percentile sia influenzato dai valori anomali.
Quindi dopo un’analisi approfondita, il team di svilppo CWV ha concluso che il 75° percentile raggiunge un equilibrio ragionevole. Utilizzando il 75° percentile, Google sa che la maggior parte delle visite al sito (3 su 4) ha registrato il livello di rendimento target o superiore.
Largest Contentful Paint
Qualità dell’esperienza #
1 secondo è spesso citato come la quantità di tempo che un utente attenderà prima di iniziare a perdere la concentrazione su un’attività. A un esame più attento della ricerca pertinente, il team Google ha scoperto che 1 secondo è un’approssimazione per descrivere un intervallo di valori, che va da diverse centinaia di millisecondi a diversi secondi.
Due fonti comunemente citate per la soglia di 1 secondo sono Card et al e Miller. Card definisce una soglia di “risposta immediata” di 1 secondo, citando le teorie unificate della cognizione di Newell.
Newell spiega le risposte immediate come “risposte che devono essere fornite a uno stimolo all’incirca entro un secondo (ovvero, all’incirca da ~0,3 secondi a ~3 secondi).”
Miller, osserva che “le attività che gli esseri umani con le comunicazioni della macchina cambieranno seriamente il loro carattere se i ritardi di risposta sono superiori a due secondi, con una possibile estensione di un altro secondo circa”.
La ricerca di Miller e Card descrive la quantità di tempo che un utente attenderà prima di perdere la concentrazione come un intervallo, da circa 0,3 a 3 secondi, il che suggerisce che la nostra soglia “buona” LCP dovrebbe rientrare in questo intervallo.
Realizzabilità #
Utilizzando i dati di CrUX, possiamo determinare la percentuale di pagine sul Web che soddisfano le soglie “buone” per LCP.
% di origini CrUX classificate come “buone” (per soglie LCP candidate)
| 1 sec. | 1.5 sec. | 2 sec. | 2.5 sec. | 3sec. | |
| telefono | 3.5% | 13% | 27% | 42% | 55% |
| desktop | 6.9% | 19% | 36% | 51% |
64% |
Mentre meno del 10% delle pagine soddisfa la soglia di 1 secondo, tutte le altre soglie da 1,5 a 3 secondi soddisfano il nostro requisito secondo cui almeno il 10% delle pagine soddisfa la soglia “buono” e sono quindi ancora candidati validi.
Inoltre, per garantire che la soglia scelta sia costantemente raggiungibile per i siti ben ottimizzati, Google analizza le prestazioni LCP per i siti con le migliori prestazioni sul Web, per determinare quali soglie sono costantemente raggiungibili per questi siti. In particolare, mira a identificare una soglia costantemente raggiungibile al 75° percentile per i siti con le migliori prestazioni. Trova quindi che le soglie di 1,5 e 2 secondi non sono sempre raggiungibili, mentre 2,5 secondi sono sempre raggiungibili.
Per identificare una soglia “scarsa” per LCP, sono utilizzati i dati CrUX(Chrome User Experience Report) per identificare una soglia raggiunta dalla maggior parte delle origini:
% di origini CrUX(Chrome User Experience Report) classificate come “Basse” (per soglie LCP candidate)
| 3 sec. | 3.5 sec. | 4 sec. | 4.5 sec. | 5 sec. | |
| telefono | 45% | 35% | 26% | 18% | 15% |
| desktop | 36% | 26% | 19% | 14% |
10% |
Per una soglia di 4 secondi, circa il 26% delle pagine mobile e il 21% delle pagine desktop sarebbero classificate come scadenti. Questo rientra nell’ intervallo target del 10-30%, quindi Google conclude che 4 secondi è una soglia “scarsa” accettabile.
Pertanto, concludiamo che 2,5 secondi è una soglia “buona” ragionevole e 4 secondi è una soglia “scarsa” ragionevole per Il Largest Contentful Paint.
First Input Delay
Qualità dell’esperienza #
La ricerca è ragionevolmente coerente nel concludere che i ritardi nel feedback visivo fino a circa 100 ms sono percepiti come causati da una fonte associata, come un input dell’utente.
Questo suggerisce che una soglia “buona” di 100 ms per il First input delay è probabilmente appropriata come barra minima: se il ritardo per l’elaborazione dell’input supera i 100 ms, non vi è alcuna possibilità che altri passaggi di elaborazione e rendering vengano completati in tempo.
Due fonti comunemente citate per questi argomenti sono Jackob Nielsen “Response times: The 3 important limits” Card e Miller, “the perception of causality“.
Miller definisce la soglia di risposta per “Risposta all’attivazione del controllo” come “l’indicazione dell’azione data, normalmente, dal movimento di un tasto, interruttore o altro elemento di controllo che segnala che è stato fisicamente attivato un processo.
Questa risposta dovrebbe essere… percepita come parte dell’azione meccanica indotta dall’operatore.
Il tempo di ritardo: non deve essere più di 0,1 secondi” e successivamente “il ritardo tra la pressione di un tasto e il feedback visivo non deve essere superiore a 0,1-0,2 secondi”.
Più recentemente, in “Towards the Temporally Perfect Virtual Button” Kaaresoja et al hanno studiato la percezione della simultaneità tra il tocco di un pulsante virtuale su un touchscreen e il successivo feedback visivo che indica che il pulsante è stato toccato, su vari ritardi.
Quando il ritardo tra la pressione del pulsante e il feedback visivo era di 85 ms o meno, i partecipanti hanno riferito che il feedback visivo è apparso contemporaneamente alla pressione del pulsante il 75% delle volte.
Inoltre, per ritardi di 100 ms o meno, i partecipanti hanno riportato una qualità percepita costantemente elevata della pressione del pulsante, con una diminuzione della qualità percepita per ritardi da 100 ms a 150 ms e il raggiungendo livelli molto bassi per ritardi di 300 ms.
Alla luce di quanto sopra, Google ha concluso che la ricerca indica un intervallo di valori intorno a 100 ms come soglia di First Input Delay appropriata per questo Web Vital. In fine, dato che gli utenti hanno segnalato bassi livelli di qualità per ritardi di 300 ms o più, 300 ms si presentano come una soglia ragionevole “scarsa”.
Realizzabilità #
Utilizzando i dati di CrUX, Google determina che la maggior parte delle pagine sul Web soddisfa la soglia “buono” per un FID di 100 ms al 75° percentile:
% di origini CrUX classificate come “buone” per soglia FID 100ms
| 100ms | |
| telefono | 78% |
| desktop | >99% |
Inoltre, osserviamo che i migliori siti sul Web sono in grado di raggiungere costantemente questa soglia al 75° percentile (e spesso la raggiungono al 95° percentile).
Considerato quanto sopra, Google ha concluso che 100 ms è una ragionevole soglia “buona” per FID.
Cumulative Layout Shift#
Qualità dell’esperienza #
Cumulative Layout Shift (CLS) è una nuova metrica che misura di quanto si sposta il contenuto visibile di una pagina. Dato che CLS è un parametro piuttosto recente, non ci sono ancora ricerche che possano informare Google direttamente sulle soglie per questa metrica.
Pertanto, per identificare una soglia in linea con le aspettative degli utenti, Google ha valutato le pagine del mondo reale con diverse quantità di spostamento del layout, per determinare la quantità massima di spostamento percepita come accettabile prima di causare interruzioni significative durante il consumo del contenuto della pagina.
Nei test interni, Google ha scoperto che i livelli di spostamento da 0,15 in su erano costantemente percepiti come dirompenti, mentre gli spostamenti di 0,1 e inferiori erano evidenti ma non eccessivamente dirompenti. Pertanto, sebbene lo spostamento del layout pari a zero sia l’ideale, Google ha concluso che i valori fino a 0,1 sono soglie CLS “buone”.
Realizzabilità #
Sulla base dei dati CrUX, possiamo vedere che quasi il 50% delle origini ha CLS di 0,05 o inferiore.
% di origini CrUX classificate come “buone” (per soglie CLS candidate)
| 0.05 | 0.1 | 0,15 | |
| telefono | 49% | 60% | 69% |
| desktop | 42% | 59% | 69% |
Sebbene i dati CrUX suggeriscano che 0,05 potrebbe essere una ragionevole soglia CLS “buona”, Google riconosce che ci sono alcuni casi in cui è attualmente difficile evitare cambiamenti di layout dirompenti. Ad esempio, per i contenuti incorporati di terze parti, come gli incorporamenti di social media, l’altezza del contenuto incorporato a volte non è nota fino al termine del caricamento, il che può portare a uno spostamento del layout maggiore di 0,05.
Pertanto, ha concluso che, mentre molte pagine soddisfano la soglia di 0,05, la soglia CLS leggermente meno rigorosa di 0,1 raggiunge un migliore equilibrio tra qualità dell’esperienza e realizzabilità .
Inoltre, per determinare una soglia “scarsa” per CLS, Google ha utilizzato i dati CrUX per identificare una soglia raggiunta dalla maggior parte delle pagine:
% di origini CrUX classificate come “scarse” (per soglie CLS candidate)
| 0.15 | 0.20 | 0,25 | 0.30 | |
| telefono | 31% | 25% | 20% | 18% |
| desktop | 31% | 23% | 18% | 16% |
Per una soglia di 0,25, circa il 20% delle pagine mobile e il 18% delle pagine desktop sarebbero classificate come “scarse“. Questo rientra nel suo intervallo target del 10-30%, quindi Google ha concluso che 0,25 è una soglia “scarsa” accettabile.
