I Core Web Vitals per la SEO: Come funzionano e come migliorarli
Con l’aggiornamento del Page Experience Update di Google, è diventato sempre più importante avere delle buone prestazioni per il proprio sito web: caricamenti di pagina in tempi brevi, stabilità visiva dei contenuti, uso di risorse e immagini ottimizzate, accessibilità e altro ancora.
Segnali Web Essenziali e Prestazioni della pagina web
Tutto questo richiede una serie di accorgimenti tecnici nell’uso di Javascript e CSS, oltre che la necessità di fare molta attenzione alla fase di progettazione e design del sito: l’usabilità diventa sempre più importante.
Questo insieme di novità e di nuove metriche è stato denominato Core Web Vitals, tradotto in italiano come Segnali Web Essenziali.
Le metriche dei Core Web Vitals
Ecco le metriche principali misurate dai Segnali web essenziali:
LCP (Largest Contentful Paint): viene usato per misurare le prestazioni di caricamento. Per offrire una buona esperienza utente, dovremmo ottenere un punteggio LCP inferiore a 2,5 secondi dall’inizio del caricamento della pagina.
INP (Interaction to Next Paint): misura l’interattività. Dovremmo assicurarci che il valore sia inferiore a 100 millisecondi. Questa metrica ha sostituito FID nel marzo 2024.
CLS (Cumulative Layout Shift): misura la stabilità visiva. Il punteggio CLS dovrebbe essere inferiore a 0,1
Per una spiegazione tecnica più approfondita sul significato e il funzionamento delle singole metriche sono già disponibili diversi articoli online, come ad esempio YoastSEO: Learn about the three Core Web Vitals: LCP, FID & CLS, per questo motivo preferisco qui concentrarmi su come poter migliorare, dal punto di vista pratico, il proprio sito o applicativo web per poter ottenere un miglior posizionamento.
In linea generale, il mio suggerimento è quello di non spendere troppe energie sul capire come migliorare ogni singolo dettaglio, anche perché spesso questo porta a dover fare le cose in fretta e farle male. Ad esempio, installare semplicemente un plugin su WordPress per la gestione della cache e il miglioramento delle prestazioni, non significa aver fatto una buona operazione.
A volte infatti i plugin di caching potrebbero sovraccaricare il server oppure potrebbero riempire il codice HTML di elementi aggiuntivi tramite Javascript, che possono creare problemi di rendering nel lungo termine.
Per capire meglio i vari aspetti dobbiamo fare un po’ di analisi, anche aiutandoci con strumenti come Lighthouse o la scheda Rete del nostro browser.
Come effettuare una prima analisi per i Core Web Vitals
Anzitutto partiamo dallo strumento Network del nostro browser, facendo clic destro sulla pagina web e poi su Ispeziona, oppure premendo il tasto F12 (può essere diverso a seconda del proprio sistema operativo) e poi aggiorniamo la pagina. Clicchiamo il primo elemento della lista a destra e guardiamo i Tempi per vedere quanto ci ha messo la pagina a rispondere. Ecco un esempio:
La scheda Rete del browser ci mostra i tempi di caricamento della pagina
Possiamo vedere che la pagina si è caricata completamente in meno di 400ms e che abbiamo avuto un tempo di attesa del server di 140ms, che in genere avviene per il caricamento in HTTPS e l’attesa di eventuali query al database. In questo esempio, non viene eseguita alcuna operazione sul DB, è una pagina semi statica, quindi anche per questo è più veloce.
Tuttavia c’è da dire che questo risultato lo ottengo su una pagina che il mio browser ha già in cache, cioè ha già memorizzato alcune risorse nella sua memoria e per questo viene caricata più velocemente. Il risultato cambia se aggiorno la pagina con CTRL+F5 oppure in incognito o eliminando la cache. Ecco come:
La pagina senza cache ci ha messo 400ms in più a caricarsi
Il caricamento completo senza cache ci ha messo circa 400ms in più, segno che un nuovo utente che visita il sito per la prima volta ci mette mediamente il doppio del tempo a caricare la pagina rispetto a un utente di ritorno che ha già memorizzato le risorse del sito nel proprio browser. Ovviamente questa è una conclusione un po’ affrettata, ma è giusto per comprendere il concetto.
Vediamo ora un esempio di una pagina che esegue diverse query al database in background, alcune molto pesanti. Come cambiano i tempi di caricamento? Ecco l’esempio:
Una pagina che esegue query e carica immagini ci mette molto più tempo a caricarsi
In questo caso più realistico, vediamo che abbiamo un tempo maggiore di attesa (536ms), probabilmente dovuto all’handshake SSL e all’esecuzione delle query.
Soprattutto però abbiamo un tempo di caricamento totale molto maggiore: ben 2,69s, di cui 1,18 per il DOM.
I dettagli sulle varie voci della scheda Network variano in base al browser, possiamo trovarli qui: Firefox, Chrome.
Da queste informazioni ricaviamo alcune prime ipotesi di lavoro: probabilmente potremmo migliorare il caricamento delle immagini, ottimizzandone i formati e riducendone il peso, oltre ad analizzare le query al database per capire dove si trovano i colli di bottiglia.
Se vogliamo ottenere suggerimenti utili per gli addetti ai lavori, possiamo utilizzare Lighthouse tramite PageSpeed Insights, oppure WebPageTest. Questi strumenti ci permetteno di inserire un URL da analizzare e ottenere un report con diverse indicazioni. Vediamo un esempio:
Il risultato di una scansione PageSpeed Insights
Conoscendo la pagina web analizzata, anche perché ci ho già lavorato molto per ottimizzarla, so bene che nel concreto non è facile soddisfare tutti i punti suggeriti dal report. Per questo, il mio consiglio è di fare il possibile senza dover risolvere ogni cosa, anche perché spesso è difficile spiegare questa necessità al cliente per giustificare ulteriore budget. Facciamo quello che possiamo, la perfezione è molto difficile da raggiungere e richiede grossi investimenti economici.
In ogni caso vediamo meglio i singoli suggerimenti e cosa fare nel concreto:
Dovremmo usare i formati WebP o AVIF per le immagini, che sono mediamente più leggeri del 50% rispetto ai classici PNG o JPEG
Dovremmo ridurre le dimensioni delle immagini, che potrebbero venire caricate a 1500px di larghezza ma visualizzate al massimo a 900px
Se possibile, riduciamo il codice Javascript che non viene mai eseguito, o il codice CSS che non viene utilizzato, anche se ovviamente non è così semplice come può sembrare. Il mio suggerimento è di verificare quantomeno se nella pagina stiamo caricando Javascript o CSS esterni che in realtà non servono, ad esempio il plugin di uno slider che nella nostra pagina non è presente
Possiamo codificare meglio le immagini esportandole in qualità inferiore quando le salviamo, di base si può stare su una qualità tra 70 e 85, ma dipende dal software e dall’immagine. La percezione visiva in genere cambia di poco.
Verifichiamo qual è l’elemento più grande visualizzato nella pagina, ad esempio il banner o l’immagine principale, per capire se possiamo ottimizzarlo
Verifichiamo il caching delle risorse della pagina, in genere possiamo usare l’header Cache-Control impostato a “no-cache, max-age=31536000, must-revalidate” per la maggior parte di immagini, CSS, Javascript, font e via dicendo
Questi sono i punti sui quali personalmente ritengo sia più fattibile iniziare a lavorare. Mi è infatti capitato di doverlo fare in passato e tra analisi, studio delle soluzioni e lavoro effettivo tutto questo può richiedere davvero decine di ore.
Da questa analisi che abbiamo fatto possiamo trarre delle conclusioni ed elaborare alcune proposte.
Hardware e hosting
I problemi di lentezza potrebbero in realtà derivare da query molto pesanti sul database che rallentano la risposta data dal server, problemi di hosting, firewall, rewrite rules o altro ancora.
Ci tengo anche a fare una piccola precisazione in merito al servizio di hosting e al relativo hardware: spesso si pensa che sia necessario acquistare server dedicati con molta RAM e CPU performanti. Per la maggior parte dei siti web medi, al giorno d’oggi è più che sufficiente una VPS con 4 vCPU e 8GB di RAM che possono tranquillamente reggere anche un centinaio di siti.
Chiaramente se abbiamo un ecommerce con migliaia di visite quotidiane o un applicativo che deve svolgere pesanti operazioni (query, conversione di immagini massive, ecc.) può avere più senso acquistare un server dedicato con almeno 8 core e 16 GB di RAM.
La scelta dell’hosting può influire molto sulla velocità di caricamento delle pagine web.
Un fornitore da valutare per chi sta cercando un servizio di hosting è Ionos, che con la VPS include anche la licenza Plesk a prezzo conveniente, o in alternativa posso consigliare anche OVH e Keliweb.
Come ottimizzare le immagini
Le pagine web caricano molte risorse: stili CSS per la grafica, file Javascript per i plugin, file dei font per i caratteri, e appunto le immagini. Se usiamo immagini troppo pesanti, la pagina si caricherà più lentamente.
Per questo motivo è consigliato utilizzare più formati e più dimensioni per ogni immagine. In genere si usano i formati JPEG, PNG e WEBP. Le dimensioni possono essere inferiori ai 1920px di larghezza (gli schermi Full HD sono 1920×1080) e i 1080px di altezza.
Chiaramente, per un piccolo sito web è meno importante. Se usiamo una sola immagine nel nostro articolo avremo pochi problemi di prestazioni.
Scrivere però un articolo con una decina di immagini JPEG 1000×1000, dove ognuna pesa 2MB, significherà che l’utente dovrà scaricare oltre 20MB per caricare la pagina. Questo può significare il raggiungimento di tempi di caricamento lunghi, anche di svariati secondi, soprattutto su reti internet più lente.
La soluzione più semplice, alla portata di chiunque, è di convertire le immagini in una versione più leggera. Un JPEG solitamente non ha bisogno della massima qualità. Carichiamo una versione con qualità inferiore, così il peso sarà molto minore ma la differenza visiva sarà quasi impercettibile.
Usando Photoshop possiamo salvare l’immagine con qualità 7. Con GIMP possiamo esportare le immagini in qualità 60. Controlliamo di aver ottenuto un buon compromesso tra peso e qualità visiva e carichiamo la nostra immagine nel sito.
Da qualche tempo ormai si stanno diffondendo sempre di più nuovi formati di immagini, WEBP e AVIF, che usano una compressione che permette di ridurre di molto, anche del 50%, il peso di una immagine. Questo diventa importante per rendere la pagina web più veloce da caricare.
Per quanto riguarda larghezza e altezza, un buon compromesso in genere è tra i 600x600px e i 1000x1000px. Dipende anche dal tipo di contenuto: un prodotto potrebbe richiedere una immagine più grande, anche per esigenze grafiche, mentre un banner a schermo intero o un hero probabilmente richiederà una dimensione di circa 1920x600px.
Possiamo riuscire a convertire facilmente JPEG e PNG in WEBP eAVIF, quest’ultimo un po’ meno diffuso, anche se sta prendendo piede un po’ alla volta. I programmi più usati in genere sono Photoshop e GIMP, quindi vediamo velocemente cosa possiamo fare con questi software.
CMS come WordPress spesso fanno queste operazioni di conversione in automatico. È opportuno comunque verificarlo. È possibile anche usare dei plugin per il proprio CMS per ottimizzare le immagini in modo automatico e programmatico, come LiteSpeed Cache per WordPress, oppure EWWW Image Optimizer.
Una breve digressione tecnica per i più curiosi (o nerd): in genere le conversioni di questo genere vengono effettuate tramite librerie disponibili gratuitamente, che in alcuni casi si possono anche installare sul proprio PC ed eseguire da riga di comando: libwebp e libavif per i nuovi formati citati, ma anche libjpeg e libpng per i formati vecchi.
Allo stesso modo si possono generalmente installare anche sul proprio server e poi programmare un cron per eseguire in modo schedulato la conversione in massa di immagini, ad esempio tramite ImageMagick. Ecco un esempio di comando per la conversione da PNG a WebP:
Come le immagini, anche video e audio possono essere ottimizzati. Fermo restando quanto detto sulle librerie per la conversione di immagini, i file video e audio in genere utilizzano ffmpeg come base, o altre librerie simili. Ecco un esempio da riga di comando:
$ ffmpeg -i input.mp4 output.avi
Questo è un sistema molto utile e funzionale, ma poco pratico per i più. Ecco allora che entra in nostro aiuto un ottimo software gratuito e open source: Handbrake.
Molto semplicemente, apriamo un video su Handbrake e selezioniamo un preset di conversione, ecco uno screenshot di esempio:
Con Handbrake è possibile scegliere un preset per la conversione
Una volta terminata la conversione, otteniamo un video molto più leggero dell’originale ma con poca differenza visiva.
Succede spesso infatti che chi si occupa di video editing ci fornisca un video con un bitrate o un qualità eccessivi, ad esempio un video in 4K con Bitrate di 20.000 Kbit, quando a noi è sufficiente un video in Full HD (1080p) con bitrate di 8.000 Kbit.
Ecco una preimpostazione base che posso suggerire:
Preset Fast 1080p 30
Formato MP4 oppure WebM
Codificatore Video H.264
La conversione potrebbe richiedere più tempo a seconda del nostro hardware. Se abbiamo una buona scheda video possiamo velocizzare il processo usando una conversione che sfrutta i codec video, ad esempio VCNper schede video AMD, o NVENC per Nvidia, selezionando dai preset la relativa opzione, come H265 AMD VCE, in base alle scelte disponibili.
Per quanto riguarda i file audio, può capitare di dover convertire da un formato ad un altro, oppure di voler ridurre il peso finale, ad esempio per podcast molto lunghi. In questo caso possiamo usare Free audio converter, e trasformare il nostro file in MP3, OGG, AAC, o altri formati. Il più diffuso e usato generalmente è l’MP3.
Ecco un esempio di impostazione del software:
Free audio converter può essere usato per convertire file audio
In alternativa, online possiamo trovare diversi strumenti per la conversione dei nostri file multimediali.
Servire i contenuti in modo “lazy”
Il lazy loading ci permette di dire al browser che un contenuto deve essere caricato “in modo pigro”, cioè che può venire scaricato successivamente perché è di secondaria importanza.
Qui dovremmo parlare in dettaglio di come funziona la coda di rendering di un documento web, ma per questo argomento rimando all’utile guida di MDN: Populating the page: how browsers work che spiega più in dettaglio ciò che riguarda DNS, Handshake, Parsing, Rendering e via dicendo.
Ciò che ci serve sapere nella pratica, che migliora di molto i tempi di caricamento di una pagina ed è relativamente semplice da realizzare, è che tutte le immagini che vengono visualizzate solo scrollandobelow the fold, cioè sotto alla prima parte visibile della pagina, possono essere caricate in modo lazy. In realtà, se anche applicassimo questa strategia alle prime immagini visibili, non ci sarebbero particolari svantaggi, ma è davvero utile soprattutto per le immagini successive.
Per fare questo possiamo aggiungere l’attributo loading=”lazy” alle nostre immagini e agli iframe:
Definire loading lazy significa che l’immagine può essere caricata dopo il resto del contenuto, questo aumenta la velocità di caricamento
Indicare esplicitamente gli attributi width e height è molto utile perché così il browser sa già quanto spazio usare per renderizzare l’immagine nella pagina, e anche questo aumenta la velocità di caricamento
Il decoding async indica che l’immagine può essere decodificata dopo aver renderizzato il resto del contenuto, rendendo quindi il caricamento immediato più veloce
È quindi raccomandato inserirli tutti quando possibile.
Se usiamo WordPress, possiamo caricare una immagine tramite le funzioni PHP del CMS nel nostro tema in questo modo, secondo la documentazione di wp_get_attachment_image:
Per quanto riguarda invece il caricamento di Javascript, CSS e Font, siano essi in locale o in remoto, è consigliato usare preconnect, dns-prefetch, prefetch e preload, a seconda delle necessità. Ecco un esempio di caso d’uso reale:
Per semplificare molto, queste indicazioni che forniamo al browser sono utili perché aiutano a definire quali risorse vengono caricate nella pagina e in che modo. Il browser potrà così decidere quali risorse caricare prima perché sono più importanti, riducendo così il tempo di caricamento.
