Come Migliorare le Core Web Vitals

Le Core Web Vitals (CWV) sono un insieme di metriche che aiutano Google a valutare le prestazioni complessive delle pagine web.

Queste tre metriche sono:

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. Cumulative Layout Shift (CLS)

Ognuna delle tre Core Web Vitals rappresenta un aspetto distintivo dell’esperienza dell’utente.

Insieme ad altre web vitals, LCP, FID e CLS fanno parte dei segnali di esperienza di pagina di Google che vengono utilizzati per scopi di ranking.

Le CWV misurano e valutano tre aspetti delle pagine web: caricamento, interattività e stabilità visiva.

La prima Core Web Vital è LCP (Largest Contentful Paint). La metrica LCP viene utilizzata per misurare il tempo che impiega l’immagine più grande o il blocco di testo più grande all’interno di una viewport predefinita per diventare visibile a partire dal momento in cui una pagina inizia a caricarsi. Il benchmark attuale di Google per Largest Contentful Paint è inferiore a 2,5 secondi.

La seconda Core Web Vital di Google è FID (o First Input Delay). La metrica FID valuta la reattività della pagina e misura il tempo che impiega una pagina a reagire all’input dell’utente (clic, tocco o pressione del tasto). Un buon First Input Delay è considerato inferiore a 100 millisecondi.

Ultima ma non meno importante, la metrica CLS misura la stabilità visiva di una pagina. Se le pagine web hanno elementi instabili durante il caricamento della pagina, ci sarà un punteggio CLS scadente. Un buon punteggio Cumulative Layout Shift dovrebbe essere uguale o inferiore a 0,1.

Come le Core Web Vitals correlano con le impressioni e i click organici

Se si legge uno qualsiasi dei casi di studio sulle Core Web Vitals, si troveranno molte informazioni contraddittorie su quanto un buon punteggio CWV correla con le impressioni e i click organici. Ho volutamente inserito questa sezione all’inizio dello studio per mostrare come l’ottimizzazione delle CWV ha funzionato per noi e perché l’abbiamo resa una delle nostre principali priorità per l’anno in corso.

Il rapporto CWV in Google Search Console ha un limite di 3 mesi sui dati disponibili. Quindi, per monitorare i nostri progressi in modo più conveniente rispetto agli strumenti di Google, abbiamo creato un’integrazione tra l’API di Google Search Console e PowerBI di Microsoft. In questo modo, siamo riusciti a combinare tutti i dati in un unico cruscotto e abbiamo potuto raccogliere tutti i dati storici senza limiti.

Punto di Partenza

Tutto il processo di ottimizzazione delle CWV è iniziato con la verifica della nostra situazione attuale in Google Search Console.

Oltre a Search Console, è possibile utilizzare PageSpeed Insights di Google per verificare le CWV sul proprio sito web. Tuttavia, è importante comprendere la differenza chiave tra i due e come valutano le CWV.

Search Console si basa sui dati di campo, vale a dire i dati Chrome User Experience Report (CrUX), il che significa che i punteggi delle CWV si basano su come gli utenti reali vivono l’esperienza delle pagine. Questi dati vengono aggiornati ogni 28 giorni, quindi bisogna attendere tutto questo tempo prima di poter vedere i risultati dei miglioramenti delle prestazioni.

PageSpeed Insights determina i punteggi in base ai dati di laboratorio, una simulazione di ciò che Google ritiene essere un utente web medio. È possibile verificare qualsiasi pagina in qualsiasi momento.

Quindi, PageSpeed Insights è utile quando si desidera ottenere una stima rapida di ciò che sta accadendo con le CWV su una determinata pagina.

Come abbiamo migliorato le metriche delle Core Web Vitals

Quando abbiamo appreso per la prima volta delle tre Core Web Vitals, la loro ottimizzazione ci sembrava un compito banale. Consultavamo il report di Lighthouse, PageSpeed Insights e Search Console e seguivamo le raccomandazioni che ci venivano date. Cosa poteva andare storto?

Solo qualche settimana dopo ci siamo resi conto che potevano esserci centinaia di problemi che portavano a punteggi scadenti delle CWV. Quindi, per condividere la nostra esperienza e risparmiarvi un sacco di tempo, ho fatto del mio meglio per raccogliere tutto ciò che è stato fatto in un formato facilmente comprensibile.

Preparazione di server e CDN Geo-specifici

– Metriche interessate: TTFB, LCP –

Il tempo di risposta del server è fondamentale e può annullare tutti gli sforzi di ottimizzazione delle CWV se non viene curato in anticipo. Una delle metriche che aiutano Google a valutare il tempo di risposta di un server si chiama Time to First Bite (TTFB) e, sebbene non sia una Core Web Vital, fa parte di altre Web Vitals.

Il TTFB misura il tempo che intercorre tra quando un utente arriva su un sito web e il momento in cui viene caricato il primo “bite” di informazione. Di solito, il TTFB dovrebbe essere inferiore a 600 ms.

Un TTFB scadente influisce negativamente su LCP, quindi renderlo il più basso possibile è fondamentale. Nella maggior parte dei casi, il punteggio TTFB può essere migliorato semplicemente passando a un provider di hosting migliore. Tuttavia, non era questo il caso di link-assistant.com.

Link-assistant.com ha un pubblico globale e Google utilizza i dati di monitoraggio degli utenti reali (RUM) per determinare se una specifica pagina soddisfa i criteri delle Web Vitals. Ciò significa che se il TTFB è buono per, ad esempio, gli Stati Uniti e cattivo per l’India, quest’ultimo finirà per abbassare il punteggio finale del TTFB.

Prima che le CWV diventassero così importanti, avevamo solo una posizione del server, negli Stati Uniti. Ovviamente, questo non era sufficiente per un sito web che aveva un pubblico multinazionale.

Ciò ci ha indirizzato verso l’ipotesi che i volumi di traffico provenienti dall’India fossero troppo alti per un singolo server. Quindi molto probabilmente il server era sovraccarico, il che comportava un pessimo TTFB per tutte le posizioni diverse dall’India. Abbiamo quindi aggiunto due nuovi server: uno a Osaka e l’altro a Singapore.

Poiché i server aggiuntivi sono stati aggiunti solo una settimana fa circa, dovremo aspettare che i risultati finali si manifestino. Tuttavia, il miglioramento è già visibile per la maggior parte delle posizioni.

Lo stesso problema con il TTFB è stato osservato nelle Americhe. Non solo i punteggi del TTFB non sono migliorati per le posizioni negli Stati Uniti, ma c’erano anche tempi di risposta del server enormemente alti per gli utenti in Brasile e Cile.

Qui abbiamo tratto alcune conclusioni. Innanzitutto, il nostro traffico organico nelle Americhe è pesante come in India, quindi due server probabilmente non sono in grado di gestire il flusso senza compromettere il TTFB.

In secondo luogo, uno dei nostri server era su Wowrack. Il nostro team di sviluppo ha scoperto che questo server era gravemente sovraccarico, aveva specifiche tecniche piuttosto datate e si trovava nella famigerata zona dell'”Internet più antico” sulla costa ovest degli Stati Uniti, il che ha comportato significativi ritardi di connessione tra gli utenti e il server stesso.

Come soluzione finale, abbiamo recentemente configurato un server AWS aggiuntivo, quindi ora abbiamo tre server negli Stati Uniti. I risultati dei miglioramenti che abbiamo apportato non sono ancora significativi, ma li terremo d’occhio e aggiorneremo questo studio in seguito.

Nel complesso, l’ottimizzazione del TTFB per link-assistant.com ci ha permesso di migliorare significativamente questa metrica, che a sua volta ha comportato un miglioramento anche dell’LCP. Un risultato vincente per noi.

Inoltre, quando eravamo certi che il TTFB fosse abbastanza buono, ci siamo assicurati che tutti i nostri asset statici (immagini, CSS, Javascript) fossero caricati da CDNs anziché dai nostri server. Anche se in modo indiretto, avere tutti gli asset statici su CDNs aiuta a migliorare i punteggi del TTFB, perché i server non vengono sovraccaricati con richieste aggiuntive per caricare immagini, CSS o JS.

Nota

Acquisire server aggiuntivi è una soluzione costosa, che non è obbligatoria al 100% dei casi. Se il tuo sito web serve un pubblico locale, puoi tranquillamente utilizzare un solo server vicino al tuo pubblico di riferimento. Se si verificano problemi con il TTFB, prova soluzioni meno radicali, come cambiare il provider di hosting. Se i problemi persistono, consulta questo articolo di Google.

Rimandare i JS di terze parti

– Metriche interessate: LCP –

I JS di terze parti includono tutto, dai pulsanti di condivisione di Facebook ai tracker di Google Analytics presenti in una pagina. Questi elementi della pagina consumano sempre molte risorse di rendering. Inoltre, ogni volta che un browser rileva un tale pezzo di JS, interrompe il rendering dell’HTML fino a quando non ha finito di renderizzare il JS. Tutto ciò porta inevitabilmente a un cattivo LCP.

Quello che abbiamo fatto è stato prima analizzare quali JS di rendering bloccanti avevamo nelle nostre pagine. Dalla ricerca, abbiamo visto che i principali bloccanti erano i pulsanti di condivisione sui social media, i blocchi di commenti di Facebook, gli embed di YouTube e Sleeknote, che utilizzavamo per i pop-up.

Ad esempio, i video incorporati di YouTube da soli potevano contribuire fino al 30% di risparmio di tempo per l’LCP:

Anche se non era obbligatorio, ci siamo sbarazzati di tutti gli script di terze parti dove era possibile per ottenere punteggi LCP migliori.

Allo stesso tempo, c’erano pagine in cui volevamo mantenere i pulsanti di condivisione sui social media, Sleeknote o i tracker di GA.

Per mantenere questi elementi della pagina senza compromettere l’LCP, li abbiamo spostati dal percorso di rendering critico. Ciò è stato fatto aggiungendo uno dei seguenti attributi alla tag <script>:

• Async. Questo attributo dice al browser di eseguire lo script in modo asincrono senza mettere in pausa l’analisi di una pagina. Abbiamo utilizzato questo attributo per gli script che erano sensibili al caricamento ritardato (Google Analytics):

Solo per completezza, ecco una spiegazione visiva degli attributi defer e async:

Vale la pena notare che è necessario evitare di utilizzare l’attributo defer e utilizzare async per vari script di tracciamento. Nel nostro caso, mancavamo quasi il 15% dei dati sugli obiettivi in Google Analytics dopo aver spostato lo script di tracciamento alla fine del percorso di rendering.

Nota

La stessa tecnica è stata applicata anche al nostro JS personalizzato. Abbiamo esaminato tutto il Javascript utilizzato sulle nostre pagine e abbiamo analizzato quali parti erano irrilevanti per eliminarle e quali parti dovevano essere mantenute: nella maggior parte dei casi le abbiamo fatte caricare in modo asincrono con l’attributo async.

2. Ottimizzazione dell’utilizzo dei caratteri

– Metriche interessate: LCP, CLS –

I caratteri web sono fondamentali per un design accattivante, una migliore leggibilità e l’identità del marchio, ma sono anche file pesanti che possono impiegare del tempo per caricarsi e danneggiare sia l’LCP che il CLS.

Se un carattere di terze parti viene utilizzato per un blocco di testo che rappresenta l’elemento LCP, il punteggio LCP può essere influenzato negativamente perché il browser impiegherà del tempo per caricare e recuperare questo carattere.

Per quanto riguarda il Cumulative Layout Shift, il principale problema dei caratteri di terze parti è che prima che un carattere specifico venga caricato, il browser visualizzerà un carattere di sistema. Una volta caricato, il carattere di terze parti può occupare più spazio sullo schermo, influenzando così la stabilità visiva di una pagina, causando uno spostamento del layout e portando a un punteggio CLS scadente.

Ecco come appare lo spostamento del layout:

Prima che le Core Web Vitals diventassero una cosa, avevamo molti caratteri diversi in una singola pagina.

A volte, questi caratteri non venivano nemmeno utilizzati ma venivano comunque caricati. Come si può vedere dalla schermata qui sotto.

Il carattere Roboto veniva utilizzato esclusivamente nel tooltip a comparsa, che non era visibile sui dispositivi mobili, ma allo stesso tempo il carattere veniva comunque caricato.

Utilizzavamo anche molti caratteri esterni, come i Google Fonts, che erano memorizzati al di fuori del nostro server.

Quindi, la prima cosa che abbiamo fatto è stata eliminare tutti i caratteri esterni e passare a quelli di sistema (Arial, Helvetica, Verdana, Tahoma, ecc.). Questa soluzione semplice ha funzionato straordinariamente bene per noi e abbiamo visto un grande miglioramento sia nei punteggi LCP che CLS.

Abbiamo anche capito che potrebbero esserci casi in cui avremmo avuto bisogno di utilizzare caratteri di terze parti. Per tali casi, rendiamo il carattere auto-ospitato sui nostri server e lo pre-carichiamo nella sezione head dell’HTML di una pagina. Come tocco finale, ci siamo anche assicurati di non utilizzare caratteri icona. Questi sono i caratteri utilizzati per sostituire le immagini schematiche, come una lente di ingrandimento, utilizzata per le barre di ricerca. Tali icone sono state sostituite da immagini SVG ospitate sui nostri server in modo che il browser non debba caricarle da fonti esterne ogni volta.

Nota Importante

L’auto-ospitamento dei caratteri web potrebbe non aiutare a migliorare l’LCP se il tuo sito web non utilizza CDN e HTTP/2. Prova a sperimentare sia con caratteri auto-ospitati che di terze parti per vedere quale soluzione funziona meglio per te.

3. Estrarre CSS e JS critici

– Metriche interessate: LCP –

Il CSS è una risorsa che blocca il rendering, il che significa che una pagina non può essere renderizzata finché il browser non recupera e analizza tutti i file CSS. Se il CSS è pesante, ci vorrà molto tempo per caricarlo, influenzando direttamente il punteggio LCP.

Nel nostro caso, non era solo la dimensione del CSS che utilizzavamo. Prima dell’inizio dei lavori di ottimizzazione, avevamo un unico foglio di stile CSS per tutte le pagine, con oltre 70.000 righe. Lo stesso CSS pesante veniva caricato per ogni pagina, anche se non veniva effettivamente utilizzato lì.

Per risolvere questo problema, abbiamo prima consultato il rapporto di copertura negli Strumenti per sviluppatori di Chrome. Abbiamo quindi esaminato tutti i contenuti di quel file CSS e ci siamo sbarazzati di tutte le righe irrilevanti. Questo ci ha permesso di ridurne significativamente la dimensione effettiva e la percentuale di byte inutilizzati.

Nota

Per ridurre ulteriormente la dimensione dei nostri file CSS e garantire che non influiscano negativamente sul punteggio LCP, li abbiamo anche sottoposti a un processo di minificazione del CSS.

I fogli di stile CSS spesso contengono commenti, spazi e interruzioni di linea superflui, e sbarazzarsi di tutto ciò può spesso aiutare a ridurre la dimensione finale del file fino al 50%. Abbiamo utilizzato CSS Minifier per ridurre la dimensione del nostro CSS e JSCompress per fare lo stesso con il Javascript che blocca il rendering.

Alla fine, il nostro team di sviluppo ha sviluppato uno strumento dedicato, che ora gestisce la minificazione in modo automatico.

Inoltre, proprio come è stato per il JS, non c’era bisogno di caricare lo stesso enorme CSS per ogni pagina ogni volta. Quindi abbiamo estratto solo gli stili necessari per l’area sopra la piega di una pagina specifica e li abbiamo aggiunti al file HTML di quella pagina.

4. Compressione del contenuto HTTP

– Metriche interessate: LCP –

La compressione del contenuto HTTP è un’ottima pratica per ridurre la dimensione dei file trasferiti tra il server e il browser. Questo può ridurre significativamente i tempi di caricamento delle pagine e migliorare il punteggio LCP.

Per comprimere il contenuto HTTP, abbiamo configurato la compressione gzip sul nostro server. Questo ha permesso di ridurre notevolmente la dimensione dei file che vengono inviati al browser, migliorando così l’LCP.

La compressione gzip è una tecnica di compressione dei dati che riduce la dimensione dei file senza perdere informazioni. Questo consente di trasferire i file più velocemente e quindi di migliorare il tempo di caricamento delle pagine.

5. Ottimizzazione delle immagini

– Metriche interessate: LCP –

Le immagini non ottimizzate possono rallentare il caricamento delle pagine e influenzare negativamente il punteggio LCP. Pertanto, abbiamo prestato particolare attenzione all’ottimizzazione delle immagini per migliorare le prestazioni delle Core Web Vitals.

Per ottimizzare le immagini, abbiamo seguito i seguenti passaggi:

• Abbiamo ridimensionato le immagini alle dimensioni effettive in cui devono essere visualizzate sulla pagina. Ridurre le dimensioni fisiche delle immagini può ridurre significativamente la loro dimensione di file e accelerare il processo di caricamento.
• Abbiamo utilizzato un formato di compressione adatto per ogni immagine. Ad esempio, le immagini con pochi dettagli e colori piatti sono state convertite in formati come PNG o SVG, che offrono una migliore compressione per questo tipo di immagini. Le immagini con molte sfumature o dettagli complessi sono state convertite in formato JPEG, che è più adatto per immagini complesse.
• Abbiamo utilizzato strumenti di compressione delle immagini per ridurre ulteriormente la dimensione dei file. Questi strumenti riducono la dimensione dei file senza perdere qualità visiva.
• Abbiamo implementato la compressione progressiva delle immagini per migliorare l’esperienza dell’utente durante il caricamento delle pagine. La compressione progressiva consente di visualizzare un’anteprima dell’immagine mentre viene caricata, anziché attendere il caricamento completo.

Ottimizzare le immagini ha avuto un impatto significativo sul punteggio LCP e sul tempo di caricamento delle pagine in generale. Abbiamo notato un miglioramento notevole nelle prestazioni dopo aver implementato queste ottimizzazioni.

6. Ultimi aggiustamenti

Dopo aver completato i passaggi precedenti, abbiamo effettuato gli ultimi aggiustamenti per ottimizzare ulteriormente le Core Web Vitals.

Abbiamo eseguito un’analisi approfondita delle nostre pagine per individuare eventuali altri problemi che potrebbero influire sul punteggio delle CWV. Ad esempio, abbiamo verificato se ci fossero script o risorse aggiuntive che bloccavano il rendering o causavano ritardi nell’interattività.

Abbiamo anche verificato l’utilizzo dei cookie sul nostro sito web e abbiamo ridotto al minimo il numero di cookie utilizzati per evitare rallentamenti nelle prestazioni.

Infine, abbiamo eseguito numerosi test e monitorato costantemente le prestazioni delle Core Web Vitals utilizzando strumenti come Google Search Console, PageSpeed Insights e Lighthouse.

Risultati delle ottimizzazioni delle Core Web Vitals

Dopo aver effettuato tutte le ottimizzazioni sopra descritte, abbiamo notato un miglioramento significativo dei punteggi delle Core Web Vitals.

Il punteggio LCP è migliorato notevolmente, con un tempo di caricamento inferiore a 2,5 secondi. Il punteggio FID è diminuito a meno di 100 millisecondi, rendendo la pagina più reattiva all’input dell’utente. Il punteggio CLS è rimasto inferiore a 0,1, garantendo una maggiore stabilità visiva.

Questi miglioramenti hanno avuto un impatto diretto sulle prestazioni complessive delle pagine. Abbiamo notato un significativo aumento dei clic organici e delle impressioni, indicando una migliore esperienza dell’utente e un miglior posizionamento nel ranking di Google.

L’ottimizzazione delle Core Web Vitals è un processo continuo

È importante sottolineare che l’ottimizzazione delle Core Web Vitals è un processo continuo. Le prestazioni delle pagine possono deteriorarsi nel tempo a causa di nuove modifiche o aggiornamenti, quindi è fondamentale monitorare costantemente le CWV e apportare eventuali correzioni o miglioramenti necessari.

Continueremo a tenere d’occhio le Core Web Vitals di link-assistant.com e a implementare ulteriori ottimizzazioni se necessario. Mantenere una buona esperienza utente e un alto posizionamento nel ranking di Google è fondamentale per il successo del nostro sito web.

Considerazioni Finali

Le Core Web Vitals sono diventate un fattore di ranking essenziale per Google. Ottimizzare le CWV può avere un impatto significativo sulle prestazioni delle pagine, sull’esperienza dell’utente e sul posizionamento nel ranking di Google.

Nel nostro studio di caso sulle Core Web Vitals, abbiamo dimostrato come abbiamo migliorato le CWV per link-assistant.com e come ciò ci ha aiutato a recuperare da un improvviso calo di posizioni nel ranking.

Le ottimizzazioni che abbiamo effettuato includono l’impostazione di server e CDN geo-specifici, il rimando dei JS di terze parti, l’ottimizzazione dell’utilizzo dei caratteri, l’estrazione di CSS e JS critici, la compressione del contenuto HTTP, l’ottimizzazione delle immagini e gli ultimi aggiustamenti.

Queste ottimizzazioni hanno portato a un significativo miglioramento delle Core Web Vitals e hanno avuto un impatto positivo sulle prestazioni delle pagine e sui risultati organici.

Ricordate che l’ottimizzazione delle Core Web Vitals è un processo continuo. È importante monitorare costantemente le prestazioni delle pagine, apportare correzioni o miglioramenti e rimanere aggiornati sulle ultime linee guida e best practice di Google per garantire un’esperienza utente ottimale e un alto posizionamento.

Articolo tratto da Link-Assistant