Dalla seconda metà di giugno 2012 Google ha iniziato a considerare le performance di un sito web come fattore di ranking.
I parametri usati per stabilire queste performance sono le metriche Core Web Vitals (segnali essenziali) che includono tre metriche chiave: Largest Contentful Paint (LCP), First Input Delay (FID) e Cumulative Layout Shift (CLS).
In questa guida, vediamo cosa sono queste metriche introdotte da Google per migliorare l’esperienza utente in termini di velocità di caricamento delle pagine, reattività e stabilità visiva, e come influiscono sulla SEO.
Ma soprattutto vediamo come possiamo ottimizzare un sito risolvendo i problemi legati a queste tre metriche, migliorando dunque l’esperienza utente, il posizionamento nei motori di ricerca, il traffico verso il tuo sito.
Cosa sono i Core Web Vitals – Segnali di Esperienza Utente (UX)
I Core Web Vitals fanno parte di un pacchetto di aggiornamenti, il Page Experience Update, e sono dei segnali di qualità essenziali per misurare l’esperienza utente sul web, ovvero l’usabilità e la qualità di una pagina web.
Si tratta di metriche che misurano quanto bene un sito web si comporta in termini di esperienza utente, in particolare per quanto riguarda la velocità di caricamento delle pagine, la reattività, o interattività, e la stabilità visuale.
Ma non si tratta solo di velocità. Questi segnali misurano un insieme di fattori che contribuiscono al modo in cui una pagina viene vissuta da un utente che naviga da un certo dispositivo, con una particolare connessione, da una specifica località.
Una buona esperienza per qualcuno, può non esserlo per altri. I Core Web Vitals esaminano l’insieme delle visite degli utenti e le soglie sono valutate al 75°
percentile dell’insieme degli utenti.
I segnali del Page Experience Update
Fanno parte di questo grande aggiornamento:
- Core Web Vitals
- Mobile Friendly
- Safe Browsing
- HTTPS
- No Intrusive Interstitials.
Quali sono i Core Web Vitals
Al momento in cui scriviamo questa guida, i Core Web Vitals sono questi 3:
- Largest Contentful Paint (LCP) – Esperienza di caricamento
- First Input Delay (FID) – Velocità di risposta dell’interazione
- Cumulative Layout Shift (CLS) – Stabilità visiva del contenuto.
Vediamoli nel dettaglio.
LCP – Largest Contentful Paint
La metrica LCP misura il tempo che impiega il contenuto principale di una pagina, l’elemento più grande, per scaricarsi ed essere pronto per interagire.
Vengono misurati alcuni elementi come l’immagine o il blocco di contesto più grande all’interno del viewport dell’utente, immagini, immagini di sfondo, video, elementi di testo a livello di blocco, come i tag di paragrafo.
Gli elementi a livello di blocco utilizzati per il calcolo del punteggio di Largest Contentful Paint possono essere gli elementi <main> e <sezione>, così come gli elementi heading, div, form.
Secondo Google, il valore ideale si aggira intorno ai 2,5 secondi. Oltre i 4 secondi, l’esperienza utente diventa “poor”, ovvero “povera”.
Gli elementi più grandi di una pagina sono i contenuti più pesanti, ovvero:
- immagini e miniature di video
- elementi con immagini caricate sullo sfondo (con la proprietà di “background image”)
- contenitori di elementi testuali: elementi di intestazioni e paragrafi (H1, H2, p).
Tra le cause del rallentamento dell’elemento più grande:
- il server che risponde lentamente – Time To First Byte (TTFB) (è forse il caso di un upgrade o di un cambio hosting).
- “Risorse di Blocco della Visualizzazione”: fogli di stile e script che vengono caricati nella finestra del browser prima di iniziare il rendering della pagina, prima del caricamento dell’HTML, dei contenuti, bloccando il rendering iniziale.
- Immagini non ottimizzate o pubblicate in formati obsoleti come JPEG o PNG o in GIF che possono allungare notevolmente i tempi di caricamento delle pagine.
In sintesi, tra le cause di una scarsa LCP
1. Tempi di risposta lenti del server
2. Blocco del rendering di JavaScript e CSS
3. Tempi di caricamento delle risorse
4. Rendering lato client.
LCP – Come risolvere
Come accennato, è bene valutare un upgrade o il cambio di provider, se il problema dipende dal server.
- Per quanto riguarda le risorse di blocco, si può ovviare lasciando precaricare le risorse più importanti, quelle che servono per strutturare la pagina, come i fogli di stile, script, i font, inserendo l’attributo rel=”preload” sul tag <link> nel documento HTML.
Esempio: <link rel=”preload” as “style” href=css/style.css”>
In sostanza, il preload indica al browser che una risorsa deve essere caricata prima che inizi il rendering della pagina.
- Tutto ciò che deve essere anticipato nella prima schermata (above the fold), perché serve al rendering della pagina, può essere inserito in linea, nel documento HTML della pagina, e non collegato all’esterno.
- Al contrario, tutto ciò che non è importante per il rendering della prima schermata, si può deferire e caricare in modalità asincrona (caricamento indipendente rispetto a tutte le altre risorse della pagina).
Esempio: <link rel=”async” as= “script” href=”js/morescript.js”>
- Minificare fogli di stile e script con eliminazione degli spazi vuoti, commenti e rientri nel codice.
- Ottimizzare le immagini e altri media: per quanto riguarda le immagini, si dovrebbero comprimere con una buona percentuale di compressione; ridimensionare; usare formati appropriati come i WebP, JPG o SVG (vettoriale); deferire il caricamento delle immagini che sono fuori dalla prima schermata (Lazy Load).
Gli Scalable Vector Graphics (SVG) sono un formato di immagine leggero che può essere scalato senza perdita di qualità. Sono ideali per loghi, icone e grafica semplice.
L’uso di SVG può ridurre significativamente il tempo di caricamento del sito web e migliorare i Core Web Vitals.
Lazy Load significa caricamento rinviato di immagini e video, fino a quando non sono necessarie. Su WordPress si può implementare questa funzione con diversi plugin.
Se la causa è un tempo di risposta lento del server:
- Ottimizzare il server
- Adottare un CDN – (Content Delivery Network) è una rete di server distribuiti geograficamente che fornisce contenuti digitali, come pagine web, immagini, video e file
- Usare la Cache.
Se la causa è il blocco del rendering di JavaScript e CSS:
- Minimizzare i CSS
- Rinviare i CSS (non critici)
- Inline dei CSS
- Minimizzare e comprimere i file JavaScript
- Rimandare il JavaScript non utilizzato.
Altri interventi:
- Ottimizzare e comprimere le immagini
- Precaricare le risorse importanti
- Comprimere i file di testo
- Fornire risorse diverse in base alla connessione di rete (servizio adattivo)
- Mettere in cache le risorse utilizzando un service worker.
FID – First Input Delay
Questa metrica misura il tempo che intercorre tra la prima interazione dell’utente sulla pagina (es: click su un pulsante) e la risposta fornita dal browser.
L’obiettivo di FID è quello di misurare la reattività di un sito durante il caricamento.
Un FID ideale dovrebbe essere uguale inferiore a 100 millisecondi.
Cosa si intende con prima interazione?
La prima interazione è quella che avviene prima del caricamento completo della pagina.
Per interazione si intende un’interazione diretta, come
- un click su un pulsante o su un link
- le aree di inserimento del testo
- le tendine e le caselle di controllo
Lo scorrimento (scrolling) e lo zooming (l’ingrandimento della pagina o di un elemento) non vengono considerati interazioni.
Da cosa può dipendere un tempo di risposta eccessivo rispetto all’interazione?
- Presenza di codice di terze parti tutti gli script caricati da un dominio diverso da quello della pagina, ovvero script di terze parti: Google, Facebook, Iubenda ecc. Esempi sono gli script di tracciamento, Google Tag Manager, banner per il consenso cookie, ecc.
- Script non ottimizzato e ridondante, caratteristica dei CMS come WordPress, in cui pacchetti Javascript vengono ricaricati più volte.
- Numero eccessivo di risorse esterne alla pagina da caricare, nel caso in cui per esempio ci sono diversi fogli di stile o javascript.
FID – Come risolvere
- Ridurre l’impatto del codice di terze parti
- Ridurre il tempo di esecuzione degli script eliminando tutto quello che non è necessario e minimizzando il codice.
- Spostare il codice degli script più pesanti su un Web Worker, su un altro blocco javascript che verrà eseguito in background e in parallelo rispetto agli script che gestiscono l’interfaccia utente.
CLS – Cumulative Layout Shift
La metrica CLS indica quanto è stabile o instabile il layout di una pagina; in che modo si spostano gli elementi che si trovano al suo interno.
Il CLS si riferisce allo spostamento inaspettato di elementi della pagina web mentre la pagina è ancora in fase di download.
Gli elementi che tendono a spostarsi sono font, immagini, video, moduli di contatto, pulsanti e altri tipi di contenuti.
Ridurre al minimo il CLS è importante perché le pagine che si spostano possono causare una cattiva esperienza dell’utente.
Un CLS ideale dovrebbe essere uguale o inferiore a 0,1.
In questo caso, dunque, il valore è decimale o percentuale (misurato in termini di occupazione percentuale dell’area visiva).
Lo spostamento avviene quando, per esempio, al caricamento della pagina vediamo un elemento in alto scendere in basso.
La differenza tra le due posizioni determina lo shift e lo spostamento. Più elementi si spostano, più si alza la metrica.
CLS – Come intervenire
In genere, i problemi legati a questa metrica hanno a che fare con le dimensioni degli elementi pesanti che si trovano in pagina, immagini o video in iframe, presi da youtube o vimeo.
Nel dettaglio, con questi fattori:
- Immagini senza dimensioni
- Annunci, embed e iframe senza dimensioni
- Contenuti dinamici
- Font Web
- Azioni che attendono una risposta dalla rete prima di aggiornare il DOM”.
La soluzione è dichiarare le dimensioni di altezza e larghezza di immagini ed elementi video nell’HTML oppure usare una regola CSS che riserva uno spazio apposito a questi elementi.
Per quanto riguarda le immagini responsive, invece, è bene assicurarsi che le diverse dimensioni delle immagini per le diverse viewport utilizzino lo stesso aspect ratio.
Due modi per indicare le dimensioni:
<img src=”pippo.jpg” width=”850” height=”520” alt=”Pippo” />
img {aspect-ratio: attr(width) / attr(height); }
In questo modo fissiamo le proporzioni precise degli elementi.
CLS e contenuti dinamici
Un’altra accortezza è quella di evitare di inserire contenuti dinamici (banner, CTA, oggetti incorporati come video di YouTube, Tweet, ecc.) all’interno di un layout già definito. Questi contenuti possono essere caricati in uno spazio predisposto.
CLS e Web Fonts
Anche i Web Font, come i Google Fonts (o altri font di terze parti), causano problemi rispetto alla metrica CLS, che possiamo però risolvere usando il precaricamento, con il rel=”preload”, e l’attributo di stile font-display con valore optional.
Un modo per evitare che ciò accada è quello di utilizzare rel=”preload” nel link per scaricare il font web.
Come misurare i Core Web Vitals?
Esistono diversi tool con i quali misurare i Core Web Vitals.
Search Console
In Search Console è disponibile il rapporto Core Web Vitals, all’interno dell’area dedicata al Page Experience Update.
Il rapporto aiuta a valutare le pagine del sito – sia lato desktop sia lato mobile, e a identificare quelle che richiedono attenzione sulla base dei dati reali.
PageSpeed Insights
PageSpeed Insights è stato aggiornato per integrare Lighthouse 6.0, il che lo rende in grado di misurare i Core Web Vitals e di notificare le aree di intervento. Leggi la guida su come leggere i dati di PageSpeed.
Lighthouse
Con Lighthouse si possono fare ulteriori verifiche sui Core Web Vitals – LCP e CLS, e sulla metrica – Total Blocking Time (TBT), legata al First Input Delay.
Nota bene: il report di Search Console mostra l’andamento delle pagine in base ai dati di utilizzo reali del report CrUX, si basa su dati reali (Field Data), mentre i dati di Lighthouse sono basati su utenti, dispositivi simulati e connessioni internet simulate. Cioè mostra i dati basati sui cosiddetti “dati di laboratorio” (Lab Data), utili per il debug di problemi di prestazioni durante lo sviluppo di un sito web, ma che potrebbero non cogliere i colli di bottiglia del mondo reale.
Web Page Test
È un altro strumento che si può usare per avere dati più tecnici. La simulazione integra impostazioni per localizzazione, browser e tipo di connessione.
H3 Chrome DevTools
Chrome DevTools aiuta a trovare e a risolvere i problemi di instabilità visiva di una pagina che possono contribuire allo spostamento del layout cumulativo (CLS).
Il tool consente di selezionare uno spostamento di layout per visualizzarne i dettagli nella scheda Riepilogo.
Per vedere il punto in cui si verifica lo spostamento, si può passare con il mouse su “Spostati da” e “Spostati in”. Chrome DevTools misura anche il Tempo di blocco totale (TBT), utile per migliorare il First Input Delay (FID).
Chrome UX Report (CrUX)
Questo report è un insieme pubblico di dati reali sull’esperienza utente in milioni di siti web. Il report Chrome UX riporta dati reali.
Estensione Web Vitals
L’estensione si può installare dal Chrome Web Store e misura in tempo reale le tre metriche Core Web Vitals.
È possibile scaricare e installare l’estensione in questa pagina.
Conclusione, in attesa dei cambiamenti di Google
Google migliora di continuo la sua comprensione dell’esperienza utente, aggiornando i Core Web Vitals e le altre metriche, perché i Core Web Vitals non sono le uniche metriche dell’esperienza utente su cui concentrarsi. Ce ne sono altre (Web Vitals, non “Core”, ovvero non essenziali), di cui tener conto nella globalità del sito.
Recentemente, al Google I/O, Annie Sullivan e Michal Mocny hanno presentato una nuova metrica denominata INP o Interaction to Next Paint, il cui ingresso è previsto a marzo 2024.
Interaction to Next Paint è una metrica che valuta la reattività complessiva di una pagina alle interazioni dell’utente, osservando la latenza di tutte le interazioni qualificate che si verificano durante la navigazione della pagina.
Per offrire una buona esperienza all’utente, già sappiamo che un sito web dovrebbe cercare di avere un Interaction to Next Paint di 200 millisecondi, o anche meno.
