Core Web Vitals: il Page Speed è Ora Ancora Più Importante per la SEO

Page Experience e i relativi Core Web Vitals diventeranno ufficialmente utilizzati come fattore per posizionare le pagine a partire da Giugno 2021.

Fonte: Google

Il modo più semplice per analizzare le metriche relative al tuo sito è attraverso il report Segnali Web Essenziali presente in Google Search Console. Con questo report, puoi facilmente vedere se le tue pagine vengono categorizzate come “scadenti”, “che richiedono un miglioramento”, “buone”.

All’interno del report, puoi trovare informazioni più dettagliate riguardo particolari problematiche, oltre alla lista delle pagine interessate.

Fatto 1: Le metriche sono divise fra desktop e mobile, ma solo i segnali mobile verranno utilizzati per posizionare le pagine. Google sta infatti passando al 100% verso il mobile indexing, quindi ha senso utilizzare solo i segnali di velocità provenienti da mobile, visto che le pagine verranno indicizzate proprio in base alla loro versione mobile.

Fatto 2: I dati provengono dal Chrome User Experience Report (CrUX), che registra i dati degli utenti Chrome che hanno fatto l’opt-in. Queste metriche verranno giudicate in base al 75esimo percentile degli utenti, il che significa che se il 70% dei tuoi utenti rientra nella categoria “buona”, ma il 5% cade in “richiede miglioramenti”, la tua pagina verrà giudicata come “richiede di miglioramenti”.

Fatto 3: Le metriche verranno calcolate per ogni singola pagina individualmente, ma se non ce ne sono abbastanza a disposizione per una specifica, John Mueller ha detto che i segnali provenienti da altre sezioni del sito potrebbero essere utilizzati.

Fatto 4: Con l’aggiunta di queste nuove metriche, AMP non è più un requisito per entrare all’interno di Top Stories da mobile. Dato che le nuove storie non avranno dati a sufficienza relativi alla velocità, è probabile che le metriche provenienti dalle pagine di categoria o dall’intero dominio vengano utilizzate al loro posto.

Fatto 5: Le Single Page Applications non misurano FID e LCP per le transizioni di pagina. Ne parleremo più avanti.

Fatto 6: Le metriche possono cambiare nel tempo, così come i requisiti minimi. Google ha già modificato il modo in cui elabora le metriche relative alla velocità nel corso degli anni, così come il metro di misura utilizzato per giudicare un sito veloce o non. Ad esempio nel nostro caso, abbiamo intrapreso delle azioni lo scorso anno per migliorare le nostre metriche, ma dovremmo farlo di nuovo a fronte delle modifiche fatte da Google.

Prima di cominciare, è bene ricordare che esistono oltre 200 fattori di posizionamento. Non mi aspetterei molto miglioramento solo a fronte di buoni punteggi sui Core Web Vitals. Non si sa quanto questi andranno ad impattare il posizionamento, ma probabilmente non si tratterà di un segnale particolarmente forte, specialmente considerando che molti dei componenti del page experience erano già utilizzati da Google per determinare il posizionamento delle pagine.

Diamo uno sguardo ad ognuno dei componenti dei Core Web Vitals singolarmente.

Ecco i tre componenti che fanno attualmente parte dei Core Web Vitals:

• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)
• First Input Delay (FID)

Largest Contentful Paint (LCP) — loading

L’LCP è l’elemento visibile più grande che viene caricato all’interno del viewport.

Fonte: web.dev/vitals

Solitamente l’elemento più grande è un’immagine di copertina, o anche il tag <h1>, ma potrebbe essere uno qualsiasi fra questi:

• Elemento <img>
• Elemento <image> che include un elemento <svg>
• L’immagine all’interno di un elemento <video>
• Un’immagine di sfondo caricata con la funzione url()
• Un blocco di testo

<svg> e <video> potrebbero essere aggiunti in futuro.

Come vedere l’LCP

All’interno di PageSpeed Insights, l’elemento LCP viene specificato all’interno della sezione Diagnostica. Per la pagina testata, l’LCP è la nostra immagine di copertina all’interno dell’articolo del blog.

All’interno degli Strumenti per sviluppatori di Chrome, segui questi passaggi:

1. Performance > e spunta “Screenshots”
2. Clicca su ‘Start profiling and reload page’
3. L’LCP apparirà sul grafico temporale 
4. Clicca sul nodo all’interno del grafico; questo è il tuo LCP

Ottimizzare l’LCP

Dato che il nostro elemento LCP e quello di molte altre pagine è l’immagine di copertina, possiamo migliorare le cose precaricando l’immagine, o renderla inline per far sì che venga scaricata insieme al codice HTML. In pratica, vogliamo far sì che l’immagine venga caricata più velocemente rispetto ad adesso.

Risorse

• Ottimizzare il Largest Contentful Paint — web.dev
• Analizzare il Largest Contentful Paint — Paul Irish (video)
• Come Migliorare il Page Speed dall’Inizio alla Fine — Ahrefs

Cumulative Layout Shift (CLS) — visual stability

Il CLS misura il modo in cui gli elementi si spostano, o quanto il layout della pagina sia stabile. Prende in considerazione la dimensione dei contenuti e quanto questi si muovono. Uno dei problemi principali con questa metrica è che continua a misurare tutto anche dopo il caricamento della pagina. Google sta raccogliendo feedback su questa metrica, ed è quindi probabile che venga alterata in futuro.

Fonte: web.dev/vitals

È fastidioso quando provi a fare click di qualcosa su di una pagina e questo elemento si muove, facendoti così fare click su qualcos’altro. Accade spesso anche a me. Faccio click su qualcosa e, di colpo, finisco con il farlo su di un annuncio, che mi porta da tutt’altra parte. Da utente, è frustrante.

Alcune problematiche comuni che alterano il CLS sono:

• Immagini senza dimensioni specificate
• Ads, embeds, e iframes senza dimensioni specificate
• Contenuti inseriti attraverso Javascript
• Font e stili applicati in seguito al caricamento

Come analizzare il CLS

All’interno del PageSpeed Insights, nella sezione diagnostica, troverai la lista di elementi che si muove.

Utilizzando WebPageTest, all’interno di Filmstrip View, usa le seguenti opzioni:

• Evidenzia Layout Shifts
• Dimensione thumbnail: Grande
• Intervallo Thumbnail: 0,1 sec

Nota come il nostro font cambi stile nell’intervallo compreso fra 5,1 e 5,2 secondi, spostando il layout man mano che il nostro font personalizzato viene caricato.

Puoi anche provate il Layout Shift GIF Generator. 

Anche Smashing Magazine ha un’interessante tecnica che ha condiviso e che consiste nell’applicare un bordo solido rosso da 3px a tutti gli elementi e registrare un video mentre si carica la pagina. Questo permette di capire dove avvengono i movimenti di layout.

Ottimizzare il CLS

Per la nostra pagina di test, sarebbe il caso di precaricare il font personalizzato, eliminarlo del tutto (non credo lo faremo), o utilizzarne uno di default per la fase iniziale di caricamento, applicando quello personalizzato solo quando la pagina è completamente carica. Queste soluzioni sacrificano un po’ di cose in termini di branding, stile, costanza, ecc… dobbiamo quindi decidere quale per noi è la miglior strada da seguire.

Risorse

• Cosa forza il layout/reflow — Paul Irish
• Ottimizzare il Cumulative Layout Shift — web.dev
• Debug del Layout Shifts — web.dev
• Capire il Cumulative Layout Shift — Annie Sullivan (video)
• Come evitare i movimenti di layout causati dai font per il web

First Input Delay (FID) — interactivity

Il FID rappresenta il tempo che passa dal momento in cui l’utente interagisce e la pagina risponde di conseguenza. Puoi pensarlo come un indicatore di responsività. Questo non include però lo scorrimento o lo zoom.

Alcuni esempi di interazione sono:

• click su di un link o un pulsante
• inserimento del testo all’interno di un campo form
• selezione di un elemento da un dropdown
• click su di una checkbox

È frustrante quando clicchi su qualcosa e non succede nulla sulla pagina.

Fonte: web.dev/vitals

Non tutti gli utenti interagiranno con una pagina, e potresti quindi non avere un valore FID. Questo è lo stesso motivo per cui alcuni strumenti non riescono a calcolare questo parametro, non potendo interagire con la pagina. Utilizza quindi il Total Blocking (TBT) Time al suo posto.

Cosa causa il FID

Javascript che compete con il thread principale. Esiste solo un thread principale, e Javascript entra in competizione per farci girare sopra altri task.

Fonte: https://web.dev/long-tasks-devtools

Mentre un task viene eseguito, la pagina non è in grado di rispondere agli input degli utenti. Questo è quello che causa il ritardo. Più lungo è il task, più lungo sarà il ritardo che affligge l’utente. Le pause fra l’esecuzione di un task e un altro sono momenti che la pagina ha per rispondere alle interazioni degli utenti.

Ottimizzare il FID

Non vedo particolari problematiche in termini di FID per il nostro sito, ma in generale, quello che devi fare è spezzare i task o rinviare il caricamento dei JavaScript finchè questi non sono necessari. 

Resources

• Ottimizzare il First Input Delay — web.dev
• Come Migliorare il Page Speed dall’Inizio alla Fine — Ahrefs

La differenza fra i dati di laboratorio e quelli sul campo è che questi ultimi sono presi da utenti reali e variano in base a rete, dispositivi, caching ecc…, mentre quelli di laboratorio sono ottenuti misurando sempre le stesse condizioni, sperando che si tratti di risultati ripetibili.

Dati sul campo

Dati di laboratorio

Mi piace il report all’interno di GSC, perchè puoi vedere i dati di molte pagine in un sol colpo. I dati sono però soggetti ad un ritardo, in quanto sono calcolati su di una media mobile di 28 giorni, e questo potrebbe portare dei ritardi nell’aggiornamento. In Chrome 88, Google aggiungerà i Core Web Vitals agli Strumenti per Sviluppatori.

Puoi anche trovare il peso di ogni metrica su Lighthouse in ogni momento e verificare i cambiamenti nel corso del tempo.

Conclusione

Il motivo per cui vuoi migliorare i Core Web Vitals, è per fornire ai tuoi utenti una migliore esperienza. È ancora da vedere l’impatto che questi avranno sulla SEO, ma come ho detto nel mio articolo relativo al page speed, dovrebbero aiutarti a raccogliere più dati all’interno del tuo analytics, che darà la “sensazione di un aumento”.

Lavora con i tuoi sviluppatori; sono loro gli esperti in questo caso. Il Page Speed può essere un argomento spinoso. Se sei solo, dovresti poter fare affidamento su di un plugin o un servizio che sia in grado di risolvere questi problemi, come WP Rocket o NitroPack.