Nel maggio 2020, Google ha annunciato che Core Web Vitals sarebbe diventato parte degli algoritmi di Google nel 2021 , ma ha detto ai proprietari dei siti che “non è necessario agire immediatamente”. Entro novembre 2020, Google ha rivelato che questo aggiornamento sarebbe entrato in vigore a maggio 2021, quindi per i proprietari di siti e i SEO di tutto il mondo, è arrivato il momento di agire sul Page Experience Update.
Cosa sono i principali parametri vitali Web?
I principali dati vitali web sono un insieme di metriche utilizzate per misurare il caricamento, l’interattività e la stabilità visiva di un sito web. Tutti e tre sono legati alla velocità del sito in un modo o nell’altro, che è qualcosa che sappiamo essere importante sia per i motori di ricerca che per gli utenti da molto tempo.
La cosa veramente interessante di Core Web Vitals, e in particolare di Page Experience Update, è che Google spesso non è molto disponibile con le specifiche degli aggiornamenti degli algoritmi. Ma in questo caso, ci sono state fornite le metriche esatte che dobbiamo misurare e migliorare e la data in cui questo aggiornamento entrerà in vigore. Ciò indica che Page Experience sarà sicuramente un aggiornamento importante, ma anche per il quale possiamo effettivamente prepararci, purché il processo di audit sia dettagliato e accurato. Di seguito sono riportate le metriche che devono essere analizzate in un audit di Core Web Vitals:
Largest Contentful Paint (LCP) misura le prestazioni di caricamento (ovvero, quanto tempo impiega l’elemento più grande nel viewport per caricarsi). Per fornire una buona esperienza utente, l’LCP dovrebbe avvenire entro 2,5 secondi dall’inizio del caricamento della pagina o un massimo di 4 secondi per evitare un punteggio “scarso” (anche se tra 2,5 e 4 secondi “necessita ancora di miglioramenti”).
First Input Delay (FID) misura l’interattività (ovvero, quanto tempo impiega il sito web a rispondere quando un utente fa clic su qualcosa). Per fornire una buona esperienza utente, le pagine dovrebbero avere un FID inferiore a 100 millisecondi o un massimo di 300 millisecondi per evitare un punteggio “scarso” (anche se tra 100 e 300 millisecondi “necessita ancora di miglioramenti”). All’interno del processo di audit descritto in questo articolo viene utilizzata una metrica simile, “Total Blocking Time (TBT)”, perché First Input Delay richiede dati sul campo, ma questo audit utilizza i dati di laboratorio perché i dati sul campo potrebbero non essere sempre disponibili per il sito web che sei auditing.
Cumulative Layout Shift (CLS) misura la stabilità visiva (ad esempio, se la pagina salta o meno mentre l’utente scorre il contenuto). Per fornire una buona esperienza utente, le pagine dovrebbero mantenere un CLS inferiore a 0,1 o un minimo di 0,25 per evitare un punteggio “scarso” (sebbene tra 0,1 e 0,25 “necessiti ancora di miglioramenti”).
Questo audit si concentra sulle metriche con un punteggio “scarso” poiché queste saranno le principali aree prioritarie, ma è possibile modificarlo per includere anche le “esigenze di miglioramento”. Quindi, ora che sappiamo cosa stiamo controllando, entriamo nel processo di audit stesso.
Come controllare i dati vitali Web di base utilizzando Screaming Frog
Sapere cosa sono i principali parametri vitali web è una cosa, ma trovare un modo per controllare e comunicare i problemi fondamentali web vitali ai clienti in un modo che sia sia utile che attuabile è una sfida che i SEO di tutto il mondo devono affrontare. Il processo di audit che ho messo insieme è progettato per fornire dettagli reali, esempi e dati con cui lavorare quando si affrontano i problemi di Core Web Vitals.
Per avviare l’audit, avrai bisogno di tre cose:
- Una versione a pagamento del crawler del sito web Screaming Frog.
- Una chiave API di PageSpeed Insights (che puoi ottenere da questa pagina della documentazione di Google PageSpeed Insights ).
- Il dominio del sito web che stai controllando.
Passaggio 1: collegare la chiave API di PageSpeed Insights a Screaming Frog
Innanzitutto, dovrai collegare la tua chiave API PageSpeed Insights a Screaming Frog. Ciò ti consentirà di accedere ai dati e ai consigli di PageSpeed Insights pagina per pagina. Riceverai solo un numero limitato di query PageSpeed Insights (circa 25.000 al giorno) che dovrebbero essere sufficienti per i siti più piccoli, ma per i siti più grandi, sarai in grado di applicare gli apprendimenti dalle pagine per cui ricevi le query al resto di il sito.
- Con la tua chiave API PageSpeed Insights in mano, apri Screaming Frog e vai a Configurazione> Accesso API> PageSpeed Insights.
- Incolla la tua chiave API nella casella “Chiave segreta”.
- Fai clic su “Connect”.

Una volta connesso, fai clic su “Metriche”. Qui definirai le metriche che verranno visualizzate durante la tua scansione. Ai fini di questo controllo, seleziono “Tutti i gruppi di metriche”, ma puoi scegliere solo quelli su cui desideri generare un rapporto e fare clic su “OK”.
I gruppi di metriche disponibili sono i seguenti:
- Panoramica – Fornisce informazioni generali sulla pagina, come le dimensioni della pagina e il potenziale risparmio di carico che potrebbe essere realizzato sulla pagina.
- Metriche CrUX – Dati dal Rapporto sull’esperienza utente di Chrome . Se i dati sul campo sono disponibili da utenti nella vita reale che hanno effettuato l’accesso, verranno visualizzati qui.
- Lighthouse Metrics – La maggior parte dei dati di laboratorio che utilizziamo nell’ambito dell’audit proviene da qui, inclusi i punteggi LCP, TBT e CLS.
- Opportunità – Fornisce suggerimenti per i miglioramenti della velocità della pagina specifici per ogni pagina.
- Diagnostica – Fornisce informazioni aggiuntive sulle prestazioni complessive del sito web sottoposto a scansione.

Passaggio 2: scansione del sito web
Successivamente, dovrai iniziare la scansione. Copia il dominio del sito web di cui stai eseguendo la scansione e incollalo nella casella nella parte superiore del crawler che dice “Inserisci URL per spider”. Durante la scansione del sito, noterai che sono presenti una barra di avanzamento “Scansione” e “API” nell’angolo in alto a destra. Dovrai attendere che entrambi raggiungano il 100% prima di iniziare ad analizzare i dati.

Passaggio 3: Segnala la dimensione del problema
Prima di entrare nello specifico di ciò che deve essere risolto, il primo passo è comunicare l’entità del problema. Per fare ciò, è necessario esaminare la percentuale di pagine che non superano le soglie minime di Core Web Vitals.
Nella barra di navigazione in alto, seleziona “Page Speed”, quindi “Esporta”.

Esaminando i dati esportati, trova le seguenti colonne e filtra di conseguenza:
- Tempo di pittura contenuto più grande (ms) – Filtra per trovare tutte le pagine con LCP di 4000 ms o più.
- Tempo di blocco totale (ms) – Filtra per trovare tutte le pagine con TBT di 300 ms o più.
- Spostamento layout cumulativo – Filtro per trovare tutte le pagine con CLS di 0,25 o superiore.
Aggiungi questi dati a un foglio dati separato in modo che tu o il tuo cliente possiate visualizzare facilmente le pagine che non superano ogni Core Web Vital. È quindi possibile generare rapporti su una percentuale di pagine del sito che non superano la soglia minima di Core Web Vitals. Ecco un esempio che ho inviato di recente a un cliente:
- Il 95% delle pagine ha una più grande vernice di contenuto di oltre 4 secondi (errore) – vedere la scheda “LCP> 4s” nella scheda tecnica allegata.
- Il 58% delle pagine ha un tempo di blocco totale di oltre 300 millisecondi (errore) – vedere la scheda “TBT> 300 ms” nella scheda tecnica allegata.
- Il 93% delle pagine ha un punteggio di spostamento cumulativo del layout superiore a 0,25 (errore) – vedere la scheda “CLS> 0,25” nella scheda tecnica allegata.
Ora sei armato di un elenco completo (o di un elenco di esempio, se il sito era troppo grande) di pagine che non soddisfano le soglie minime di Core Web Vitals, in modo che gli sviluppatori sappiano esattamente dove cercare le pagine con errori. Se noti degli schemi (ad esempio, sono solo le pagine del blog e così via), puoi segnalarlo anche adesso.
Passaggio 4: segnalare i problemi specifici di ciascuna pagina e formulare raccomandazioni appropriate
Questa è la parte dell’audit in cui trasformiamo i problemi in soluzioni. Sappiamo che X quantità di pagine non superano le soglie minime di Core Web Vitals, ma cosa possiamo fare noi / il cliente al riguardo? È qui che l’API PageSpeed Insights funziona davvero con la sua magia.
Sul lato destro, nella scheda “Panoramica”, scorri verso il basso fino a “PageSpeed”. Qui troverai l’elenco dei problemi / consigli relativi alla velocità della pagina e, per la maggior parte, Core Web Vitals.
Vi è un’ampia varietà di problemi diversi segnalati qui. Se ce ne sono di cui non hai familiarità, cercali sul sito web web.dev per ottenere maggiori informazioni. Anche se i dati disponibili all’interno di Screaming Frog e PageSpeed Insights potrebbero non fornire un elenco completamente esaustivo di tutti i problemi che possono avere un impatto su Core Web Vitals, sicuramente aiuta quando si analizza il sito del tuo / del tuo cliente nel suo complesso.
Fare clic su un problema per visualizzare le pagine interessate ed esportarle per salvarle nel foglio dati. Stai ora segnalando le specifiche di quante pagine sono interessate da un particolare problema e gli URL delle pagine interessate. Nell’esempio seguente, ho esportato un elenco di tutte le pagine che dispongono di risorse di blocco del rendering che potrebbero avere un impatto negativo su LCP. Ora posso consigliare al cliente di esaminare questo elenco e di decidere se è possibile incorporare, rinviare o rimuovere le risorse su queste pagine.

Per ciascuna delle raccomandazioni che stai facendo, sarai anche in grado di vedere i “Risparmi” che potrebbero essere realizzati risolvendo quel particolare problema, in byte o in millisecondi. Utilizzando i dati esportati per ogni problema, è ora possibile sommare i potenziali risparmi per ogni problema e il risparmio medio che si potrebbe ottenere per pagina risolvendo tale problema, in modo da poter fornire i propri consigli per quali problemi affrontare per primi in base al quantità di potenziale risparmio di carico che è possibile ottenere. Nell’esempio seguente, il risparmio in millisecondi e byte è molto maggiore per il differimento delle immagini fuori schermo rispetto alla rimozione di CSS inutilizzati, quindi il differimento delle immagini fuori schermo avrà una priorità più alta.

Passaggio 5: segnalare esempi di problemi specifici di ciascuna pagina
Segnalando esempi di problemi specifici di ciascuna pagina, forniamo un set di dati più granulare che consente al cliente / sviluppatori di capire rapidamente qual è il problema e se è qualcosa che può essere risolto o meno.
Seguendo l’esempio delle risorse di blocco del rendering, ora è necessario selezionare uno degli URL interessati da questo problema e selezionare la scheda “Page Speed Details” nella barra di navigazione inferiore. Il pannello in basso a sinistra mostrerà ora le informazioni sulla velocità della pagina relative alla pagina selezionata. Vai a Opportunità> Elimina risorse che bloccano il rendering.
Nel riquadro in basso a destra, ora vedrai gli URL delle risorse che bloccano il rendering su quella pagina, la loro dimensione (in byte) e il potenziale risparmio di caricamento della pagina che potrebbe essere realizzato (in millisecondi) se questi blocchi del rendering le risorse vengono eliminate.

Sfortunatamente, non puoi esportare questi problemi specifici in blocco (per quanto ne so), ma puoi copiare e incollare alcuni esempi nel tuo foglio dati e cercare nuovamente eventuali schemi. Spesso, le stesse risorse appariranno su più pagine / ogni pagina del sito, quindi gli insegnamenti possono essere applicati a tutto il sito.
Dopo aver raccolto questi dati per ogni problema sul sito, è possibile fornire un rapporto scritto con raccomandazioni per ogni problema in ordine di priorità e fare riferimento ai dati nella scheda tecnica.
Passaggio 6: una volta apportate le modifiche, eseguire nuovamente la scansione del sito e confrontare
Prima completi questo audit, meglio è, poiché alcuni problemi richiederanno tempo per risolversi. Una volta risolti i problemi, puoi tornare al passaggio uno e ripetere la scansione del sito per vedere come sono cambiate le cose. È qui che le tue percentuali di pagine che non soddisfano le soglie minime di Core Web Vitals torneranno utili, poiché mostra un modo semplice e veloce per capire se le tue modifiche hanno avuto o meno l’impatto desiderato.
Quando riferisco ai clienti su Core Web Vitals e Page Experience Update, le domande che spesso mi vengono poste riguardano il modo in cui questo aggiornamento influenzerà le classifiche. Nonostante questo sia chiaramente un aggiornamento importante, non prevedo che i siti web che non hanno raggiunto le soglie minime vedano un enorme calo delle classifiche dall’oggi al domani. Sarà più probabile che si tratti di siti che hanno contenuti eccellenti in grado di soddisfare o superare le soglie minime di Core Web Vitals vedendo un leggero miglioramento nelle classifiche, il che, ovviamente, significherà lievi cali di classifica per i concorrenti che superano. Questa opinione è supportata dalle linee guida di Google sull’argomento:
“Sebbene tutti i componenti dell’esperienza sulla pagina siano importanti, daremo la priorità alle pagine con le migliori informazioni complessive, anche se alcuni aspetti dell’esperienza sulla pagina sono scadenti. Una buona esperienza sulla pagina non esclude la presenza di contenuti interessanti e pertinenti. Tuttavia, nei casi in cui sono presenti più pagine con contenuti simili, l’esperienza della pagina diventa molto più importante per la visibilità nella ricerca “.
I proprietari di siti che sono in grado di soddisfare le soglie minime si stanno mettendo in netto vantaggio in termini di visibilità della ricerca e, sebbene non possiamo prevedere esattamente cosa accadrà il giorno in cui verrà pubblicato l’aggiornamento Page Experience, questo processo di controllo ti aiuterà a prepararti bene.