Analisi Web Vitals | Screaming Frog Club

Core Web Vitals

Screaming Frog SEO Spider attraverso la connessione con PageSpeed Insights API ti permette di misurare facilmente i Core Web Vitals (CWV) per ogni pagina del tuo sito web.

I Core Web Vitals sono un insieme di metriche che Google ha introdotto da maggio 2021 per misurare gli aspetti chiave dell’esperienza dell’utente durante il caricamento di una pagina web. I Core Web Vitals sono una vera e propria rivoluzione che aiuta Google a valutare le pagine web e attribuire il ranking per i risultati di ricerca.

Oggi le metriche sono tre: LCP (caricamento), INP (reattività) e CLS (stabilità visiva). Google le aggiorna nel tempo: a marzo 2024 l’INP ha sostituito il FID come metrica di reattività.

LCP: Largest Contentful Paint

La metrica Largest Contentful Paint (LCP) riporta il tempo di rendering della più grande immagine o blocco di testo visibile all’interno della viewport, rispetto a quando la pagina ha iniziato il caricamento. Come parametro di valutazione Google considera un tempo massimo di 2,5 secondi per garantire un’esperienza utente valida e soddisfacente.

Per assicurarti di raggiungere questo obiettivo per la maggior parte dei tuoi utenti, una buona soglia da considerare è il 75° percentile dei carichi di pagina, segmentati tra dispositivi mobili e desktop.

Timeline di caricamento di una pagina mobile con First Contentful Paint e Largest Contentful Paint — Dal First Contentful Paint al Largest Contentful Paint.

INP: Interaction to Next Paint

L’Interaction to Next Paint (INP) misura la reattività di una pagina: quanto tempo passa tra un’interazione dell’utente (un clic, un tap, la pressione di un tasto) e il momento in cui il browser mostra a schermo la risposta, cioè il “paint” successivo.

Dal 12 marzo 2024 l’INP ha sostituito il First Input Delay (FID) tra i Core Web Vitals. Il FID aveva due limiti importanti:

misurava solo la prima interazione con la pagina, ignorando tutte le successive;
misurava solo il ritardo d’ingresso, cioè l’attesa prima che il browser iniziasse a gestire l’evento, e non il tempo per elaborarlo e aggiornare la pagina.

L’INP invece osserva tutte le interazioni durante l’intera visita e, per ognuna, somma tre fasi:

Input delay: l’attesa prima che partano i gestori dell’evento, di solito perché il thread principale è occupato da altri script;
Processing time: il tempo di esecuzione del codice JavaScript collegato all’interazione;
Presentation delay: il tempo che serve al browser per ricalcolare il layout e disegnare il nuovo frame.

Il valore finale è l’interazione più lenta della visita (sulle pagine con moltissime interazioni Google scarta i valori anomali). È quindi una metrica molto più severa e realistica del FID: una pagina può rispondere bene al primo clic ma bloccarsi quando l’utente apre un filtro o aggiunge un prodotto al carrello.

Le interazioni dell’utente rallentano soprattutto quando il browser è impegnato in altri compiti. Nella timeline qui sotto i long task, le attività che occupano il thread principale per più di 50 ms, sono evidenziati: se l’utente clicca mentre uno di questi è in corso, la risposta arriva solo quando il task è terminato.

Timeline di Chrome DevTools con i Long Tasks che ritardano la risposta alle interazioni — I long task bloccano il thread principale e ritardano le interazioni.

Come parametro di valutazione, per fornire una buona esperienza di navigazione Google indica che l’INP dovrebbe essere uguale o inferiore a 200 millisecondi; tra 200 e 500 ms la pagina va migliorata, oltre i 500 ms la reattività è scarsa. Per assicurarti di raggiungere questo obiettivo per la maggior parte dei tuoi utenti, una buona soglia da misurare è il 75° percentile dei carichi di pagina, segmentati tra dispositivi mobili e desktop.

CLS: Cumulative Layout Shift

Il Cumulative Layout Shift (CLS) è una metrica molto importante incentrata sull’esperienza utente che misura la stabilità visiva di un layout durante il caricamento di una pagina HTML. Questo indice è stato introdotto per limitare spiacevoli cambi inaspettati dovuti ad esempio a banner pubblicitari o altro. Tutti abbiamo avuto la frustrante esperienza di leggere un sito di notizie e avere il testo dell’articolo che salta più in basso mentre la navigazione viene caricata; il CLS misura appunto questa instabilità di navigazione.

Qui sotto puoi vedere questo fenomeno mentre la pagina viene caricata dal browser. Attraverso ogni schermata viene aggiunto del contenuto, causando lo spostamento in alto e in basso degli elementi precedenti.

Timeline di caricamento di una pagina mobile con contenuti che si spostano durante il caricamento (Cumulative Layout Shift) — I contenuti caricati in ritardo spostano gli elementi già visibili.

Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di avere un punteggio CLS di 0,1 o inferiore. Per assicurarti di raggiungere questo obiettivo per la maggior parte dei tuoi utenti, una buona soglia da misurare è il 75° percentile dei carichi di pagina, segmentati tra dispositivi mobili e desktop.

I Core Web Vitals sono delle metriche fondate sui dati reali di Chrome User Experience Report (CrUX) relativi agli ultimi 28 giorni e basate sulle visite degli utenti a una pagina.

Ogni Web Vital è valutato in base a tre classificazioni; Good, Needs Improvement e Poor.

Affinché una pagina venga convalidata dai Core Web Vital Assessment deve essere considerata “Good” in tutte e tre le metriche.

Queste sono le soglie di ciascuna metrica, misurate al 75° percentile:

Metrica	Good	Needs Improvement	Poor
LCP (caricamento)	≤ 2,5 s	2,5 – 4 s	> 4 s
INP (reattività)	≤ 200 ms	200 – 500 ms	> 500 ms
CLS (stabilità visiva)	≤ 0,1	0,1 – 0,25	> 0,25

Analisi Parametri Core Web Vitals

I Core Web Vitals dei siti web sono registrati e memorizzati all’interno del Chrome User Experience Report e li puoi visualizzare essenzialmente in due modi.

Per un singolo URL puoi utilizzare PageSpeed Insights (PSI), che ti segnala se la pagina ha superato o non superato i controlli.

Valutazione Core Web Vitals superata in PageSpeed Insights con LCP 1,9 s, INP 130 ms e CLS 0, più FCP e TTFB — PageSpeed Insights con i dati reali degli ultimi 28 giorni: LCP, INP e CLS nella soglia Good.

La seconda soluzione è consultare la Search Console nella sezione “Core Vitals” che riporta il rendimento delle pagine, gli errori e gli avvertimenti in relazione a queste metriche.

Report Core Web Vitals di Google Search Console con URL poor, need improvement e good su mobile e desktop — Search Console raggruppa gli URL per gruppi di pagine simili.

Nonostante questi due controlli siano efficaci sono altresì estremamente riduttivi perché la prima soluzione permette un controllo unitario degli URL mentre la seconda con GSC agglomera più Url (modelli di URL) e non fornisce i punteggi di qualità unitari.

Screaming Frog analisi Web Vitals

Screaming Frog SEO Spider grazie alla connessione a PageSpeed Insights API ti permette di raccogliere i dati sui Web Vital in modo semplice e ti restituisce dati specifici per ogni URL in base ai dati reali di CrUX e ai dati di laboratorio. Per impostarlo basta seguire pochi e semplici passi.

1. Connessione alle API di PageSpeed: vai in 1Configuration›2API Access›3PageSpeed Insights, inserisci la tua Secret Key e clicca Connect.

Finestra PageSpeed Insights di Screaming Frog con il campo Secret Key e il pulsante Connect — Inserisci la tua API key di PageSpeed Insights e clicca Connect.

1. Impostazioni delle metriche da considerare.

Una volta che sei connesso a PSI devi cliccare sulla scheda “Metriche” e scegliere quali introdurre come parametro di analisi. Nelle prime scansioni dei Core Web Vitals ti consiglio di utilizzare la selezione predefinita in quanto include i dati del rapporto CrUX, i dati di laboratorio di Google Lighthouse e i dati sulle opportunità delle aree da migliorare.

Scheda Metrics della configurazione PageSpeed Insights di Screaming Frog con Device Mobile e le metriche CrUX — Scegli dispositivo e metriche da raccogliere per ogni URL.

1. Esecuzione della scansione.

Concluse le configurazioni sulle metriche delle API puoi avviare il crawler ed aspettare che il sito web venga scansionato e popolato con i dati relativi ai Core Web Vitals.

1. Analisi dei dati

Non ti resta che cliccare sulla scheda PageSpeed per visualizzare tutti i dettagli del crawl e quali URL abbiamo passato il test, quali devono essere migliorati e quali invece presentano degli errori gravi.

Tab PageSpeed di Screaming Frog con PSI Status, Performance Score e metriche di velocità per ogni URL — La tab PageSpeed con le metriche di ogni URL.

L’esempio sopra (con impostazioni di default) presenta nella prima colonna gli URL mentre nella seconda la valutazione dello stato del “Core Web Vitals Assessment”. Il PSI Status è contrassegnato con “Pass” o “Fail” a seconda che sia considerato valido in tutti e tre i Web Vitals.

Nello screenshot puoi notare che l’URL in alto ha un LCP di 1.99s (sotto 2.5s), un dato di reattività di 37 ms (all’epoca il FID, oggi sostituito dall’INP con soglia 200 ms), e un CLS di 0.06 (sotto 0.1) quindi ha passato la convalida dei CWV.

Attraverso questa panoramica sei in grado di esaminare immediatamente quali siano le pagine che non hanno passato il test e su quali metriche specifiche dei CWV intervenire.

Può capitare che alcuni URL non ottengano dati relativi ai CWV, questa condizione si presenta quando non ci sono dati sufficienti sulla velocità in CrUX, o perché la pagina non ha abbastanza visitatori. Solo le pagine più popolari in genere hanno sufficienti dati per il rapporto Chrome UX.

1. Segmentazione dei modelli di errore

Ottenuti i dati puoi esaminare ogni singola prestazione dei CWV utilizzando differenti filtri ed isolando le problematiche da ottimizzare avendo a disposizione ogni URL che presenta le medesime criticità .

Filtri della tab PageSpeed di Screaming Frog con le opportunità di ottimizzazione, da Eliminate Render-Blocking Resources a Request Errors — Un filtro per ogni opportunità di ottimizzazione.

Evidenziando un URL nella finestra superiore e cliccando sulla tab “PageSpeed Details” (finestra inferiore) troverai tutta una serie di dettagli supplementari e delle opportunità per revisionare gli errori o avvertimenti riscontrati.

Tab PageSpeed Details di Screaming Frog con le Opportunities e le risorse con Potential Savings — Le opportunità della pagina e le risorse da ottimizzare.

Ottimizzare Metriche LCP

Iniziamo a definire quali siano le aree che possono incidere sul LCP e quali fattori possono essere ottimizzati per migliorare l’indice della metrica.

Properly Size Images.
Defer Offscreen Images.
Efficiently Encode Images.
Serve Images in Next-Gen Formats.

Il punto di partenza coinvolge le immagini che sono uno degli elementi cardine per le performance delle pagine html. Per migliorare la metrica LCP assicurati che ogni immagine sia correttamente dimensionata, e utilizza il “Lazy Loading” dove appropriato.

E’ consigliabile l’utilizzo di nuovi formati di immagine più efficienti come WebP e migliorare la codifica dei file di immagine esistenti.

Un altro aspetto molto impattante coinvolge i tempi di risposta del server. Un server poco potente porta a risposte lente e a tempi di caricamento maggiori; per questo motivo ti consiglio la scelta di hosting più performanti o di utilizzare le CDNs -Content Delivery Networks per ridurre i tempi di risposta e migliorare il TTFB.

Tra le possibili ottimizzazioni da considerare poni molta attenzione nella gestione delle risorse che bloccano il rendering della pagina. Come ben sai mentre l’HTML viene analizzato, ogni riferimento ai fogli di stile o CSS può causare una pausa del “parser”, ritardando l’LCP.

Idealmente, dovresti rinviare qualsiasi CSS e JavaScript non critico per accelerare il caricamento del tuo contenuto principale e utilizzare il “preload” per le risorse critiche. Un’altra tips è quella di minificare i CSS e Javascript e rimuovere tutti i file non necessari dal caricamento della tua pagina, considera inoltre di utilizzare il “preconnect” per risorse di terze parti (es. Google Analytics, Tag Manager etc.).

Minify CSS.
Minify JavaScript.
Remove Unused CSS.
Remove Unused JavaScript.
Enable Text Compression.
Preconnect to Required Origins.
Preload key Requests.
Use Video Formats for Animated Content.

Ottimizzare INP

L’INP nella maggior parte dei casi peggiora per i lunghi tempi di esecuzione di script di grandi dimensioni, che tengono occupato il thread principale proprio quando l’utente interagisce. La prima azione da intraprendere è quella di minificare e rimuovere le parti degli script inutilizzate, (o interi script) riducendo il tempo speso per l’esecuzione e il rendering di questi file.

Minify JavaScript.
Remove Unused JavaScript.
Reduce the Number of Third-Party Scripts Used.

Per scovare l’elenco delle risorse di terze parti puoi consultare il tuo documento HTML all’interno della scheda PageSpeed Details.

Un’altra ottimizzazione da considerare riguarda il lavoro del thread principale. Se un browser è impegnato nel rendering del thread principale, l’utente non sarà in grado di compiere delle interazioni con la pagina fino a quando questo non sarà completato. Se riduci il tempo di esecuzione del thread principale, le interazioni dell’utente saranno più reattive ed immediate.

Le soluzioni principali riguardano la riduzione dell’esecuzione degli script JavaScript e del lavoro sul main thread. In particolare, per l’INP:

spezza i long task in attività più brevi, cedendo il controllo al browser (per esempio con scheduler.yield() o setTimeout), così le interazioni non restano in coda;
mantieni leggeri i gestori degli eventi e rimanda il lavoro non urgente a dopo il paint;
riduci la dimensione del DOM, perché un DOM molto grande allunga il ricalcolo del layout dopo ogni interazione (Avoid Excessive DOM Size).
Minimise Main-Thread Work
Reduce JavaScript Execution Time

Considera poi che ogni risorsa necessaria per una pagina richiede tempo per essere richiesta, scaricata ed eseguita. Riducendo sia il numero di richieste necessarie che la dimensione totale del download, aiuterai a migliorare i tempi di esecuzione della pagina.

L’attività utili a tale scopo è la minificazione dei CSS e Javascript, la rimozione di fogli di stile/CSS e Javascript inutilizzati e la compressione del testo.

Lower Resource Counts & Sizes.
Minify CSS.
Minify JavaScript.
Remove Unused CSS.
Remove Unused JavaScript.
Enable Text Compression.

Ottimizzare CLS

Come già accennato in precedenza la stabilità del layout è la componente principale per il CLS per garantire un’esperienza di rilievo al navigatore, questo aspetto deve farti concentrare sul servire la pagina nell’ordine appropriato e con una spaziatura definita per ogni risorsa per non creare sbalzi nella navigazione.

Per ottenere dei risultati soddisfacenti devi garantire che tutte le immagini, gli annunci, i video e gli iframe presentino gli attributi <height> e <width> per permettere che le pagine vengano caricate con la spaziatura appropriata ed evitare lo spostamento degli altri contenuti quando vengono aggiunte. Un’altra considerazione in ottica di CLS è quella di dare priorità di caricamento alle risorse dall’alto verso il basso per non far rimbalzare verso l’alto l’utente che magari ha raggiunto un certo livello di profondità di navigazione.

Assicurati che i font personalizzati non causino l’effetto FOIT/FOUT, infatti se i font personalizzati sono applicati in ritardo nel caricamento di una pagina si può verificare che il testo lampeggi mentre viene sostituito (FOUT), o che il testo invisibile venga visualizzato fino a quando il font personalizzato non viene reso (FOIT). Per ovviare a questa latenza ti consiglio di utilizzare il “preload” delle risorse critiche.

Screaming Frog e Web Vitals

Se i tuoi URL non mostrano alcun dato CrUX e lo stato PSI elenca ‘successo’, allora è probabile che l’URL non riceva abbastanza visite di utenti reali per generare dati di velocità sufficienti per il rapporto CrUX. Se dopo il crawl con Screaming Frog ti trovi in questa condizione potresti utilizzare per l’analisi una pagina con layout simile che presenti dati CrUX, o utilizzare i dati di laboratorio simulati (presenti di default nella configurazione del Seo Spider).

Quando devi utilizzare i dati di laboratorio, l’unica metrica non disponibile è l’INP, perché Lighthouse non simula le interazioni di un utente reale. In questo caso usa come indicatore il Total Blocking Time (TBT): misura per quanto tempo il thread principale resta bloccato dai long task durante il caricamento ed è molto correlato all’INP, quindi le risorse che lo fanno crescere sono le prime da ottimizzare.

Nel caso tu debba analizzare un sito di grandi dimensioni potresti superare la quota limite di PageSpeed Insight. Se ti trovi in questa condizione ti consiglio di analizzare un campione significativo o aspettare che la quota si azzeri.

Non dimenticarti che i dati di CrUX si basano sugli ultimi 28 giorni di interazioni con gli utenti, quindi qualsiasi modifica al sito impiegherà 28 giorni per riflettersi in CrUX.

Analisi Web Vitals.