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

Patrick Stox
Patrick Stox è Product Advisor, Technical SEO e Brand Ambassador di Ahrefs. E’ tra gli organizzatori di Raleigh SEO Meetup, Raleigh SEO Conference, Beer & SEO Meetup, Findability Conference, e moderatore di /r/TechSEO.
    I Core Web Vitals sono delle metriche di velocità che fanno parte del Page Experience di Google, un segnale che serve a misurare l’esperienza degli utenti su di un sito. Queste metriche misurano il caricamento della parte grafica attraverso il Largest Contentful Paint (LCP), la stabilità grafica con il Cumulative Layout Shift (CLS), e l’interattività della pagina attraverso il First Input Delay (FID)

    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) — loading

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

    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

    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.

    È 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

    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.

    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.

    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

    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

     LCPFIDCLS
    Chrome User Experience Report
    PageSpeed Insights
    Google Search Console (Core Web Vitals report)
    Web-vitals JavaScript library
    web.dev
    Web Vitals Extension

    Dati di laboratorio

     LCPFIDCLS
    Chrome DevTools✘ (usa il TBT)
    Lighthouse✘ (usa il TBT)
    WebPageTest✘ (usa il TBT)
    PageSpeed Insights✘ (usa il TBT)
    web.dev✘ (usa il TBT)

    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.