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.
Al momento sono essenzialmente tre ma credo che in seguito, oltre all’affinamento degli stessi saranno introdotte altre metriche sempre più orientate a garantire un’esperienza di navigazione più soddisfacente.
- 1. 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.
- 2. FID: First Input Delay
Il First Input Delay (FID) di una pagina misura la sua reattività alle interazioni dell’utente. Per esempio, se un utente fa clic su un link, o seleziona un menu a tendina il FID valuta quanto velocemente questa azione viene eseguita sulla pagina.
Di solito, le interazioni dell’utente sono ritardate quando un browser è impegnato nell’esecuzione di altri compiti.
Ad esempio analizzando la timeline di caricamento qui sotto, vediamo delle barre blu che identificano il tempo necessario per caricare una risorsa (come un file JavaScript) che richiede un tempo piuttosto prolungato.
Se un utente facesse clic su qualcosa all’interno della pagina HTML durante questo intervallo di tempo l’interazione sarebbe rinviata fino a quando il browser non ha portato a termine il processo precedente.
Come parametro di valutazione, per fornire una buona esperienza di navigazione per l’utente, Google indica che la metrica First Input Delay dovrebbe essere uguale o inferiore a 100 millisecondi. 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.
- 3. 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.
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.
Google ha fornito una comoda illustrazione delle soglie per ciascuna metrica.
Come visualizzare i parametri vitali del core web di una pagina?
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.
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.
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.
Analizzare i Core Vitals con Screaming Frog
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.
- 2. 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.
- 3. 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.
- 4. 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.
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 FID di 37ms (sotto 100ms), 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.
- 5. 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à .
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.
Come Ottimizzare la metrica LCP (Largest Contentful Paint)
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.
Come Ottimizzare il FID (First Input Delay)
Il FID nella maggior parte dei casi viene influenzato negativamente da lunghi tempi di esecuzione di script di grandi dimensioni. 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 la riduzione del Main Thread.
- 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.
Come Ottimizzare il CLS (Cumulative Layout Shift)
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.
Web Vitals: gestione di casi particolari con Screaming Frog
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 è il FID – First Input Delay per la mancanza dell’interazione richiesta dall’utente. In questo caso puoi utilizzare come indicatore il Total Blocking Time (TBT) per vedere quali risorse vengono bloccate e di conseguenza considerarle come criticità che può far aumentare il FID.
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.
