I Core Web Vitals rappresentano un insieme di metriche che consentono di valutare la qualità dell’esperienza utente su un sito web. Tra queste, ci sono tre parametri principali noti, appunto, come “Core”:
- Largest Contentful Paint (LCP): Misura la velocità di caricamento
- Cumulative Layout Shift (CLS): Misura la stabilità visiva
- First Input Delay (FID): Valuta l’interattività della pagina
Ne abbiamo parlato in questo articolo, in cui abbiamo spiegato anche perché Google considera questi parametri essenziali per valutare la qualità di un sito web.
Ma come possiamo ottimizzarli?
Scopriamolo insieme passo dopo passo.
Largest Contentful Paint (LCP)
Il Largest Contentful Paint (LCP) è una metrica essenziale per valutare le prestazioni di caricamento di una pagina web. Tuttavia, molti siti faticano a raggiungere la sua soglia ottimale.
Vediamo punto per punto dove poter intervenire.
LCP rilevabile dall’origine HTML
Per ottimizzarlo è cruciale renderlo facilmente rilevabile dall’origine HTML. Ciò significa che l’URL dell’immagine o della risorsa LCP dovrebbe essere correttamente inserito negli attributi HTML standard come <img src=””> o <link rel=”preload” href=””>.
Inoltre, si consiglia di preferire il rendering lato server (SSR) rispetto al rendering lato client (CSR), poiché l’SSR implica che il markup completo della pagina, compresa l’immagine, sia presente nell’origine HTML.
Se l’immagine viene referenziata da un file CSS o JS esterno, è possibile includerla nel codice sorgente HTML utilizzando il tag <link rel=”preload”>.
È fondamentale anche dare priorità alla risorsa LCP. Se ci sono molti tag <script> nel <head> del documento prima dell’immagine LCP, potrebbe passare del tempo prima che l’immagine inizi a caricarsi e questa dinamica non è vista favorevolmente da Google.
Priorità con l’attributo fetchpriority=”high”
Una soluzione consiste nell’impostare l’attributo fetchpriority=”high” sul tag <img> o <link> che carica l’immagine LCP. Questo attributo indica al browser di dare la massima priorità al caricamento dell’immagine, evitando di attendere il completamento degli script.
Ottimizzare il Time to First Byte (TTFB)
Per ottimizzare il Time to First Byte (TTFB), che rappresenta il tempo necessario per ricevere la prima risposta del documento HTML, è fondamentale utilizzare un CDN (Content Delivery Network).
I CDN distribuiscono le risorse ai server perimetrali distribuiti in tutto il mondo, riducendo la distanza fisica che le risorse devono percorrere per raggiungere gli utenti finali.
Questo a primo impatto potrebbe sembra un aspetto marginale, ma quando la partita delle performance si gioca su frazioni di secondo, fare in modo che le risorse impieghino fisicamente meno tempo ad essere trasferite, può fare la differenza.
Utilizzare un CDN consente quindi di offrire contenuti più vicini geograficamente agli utenti e di memorizzare nella cache il contenuto per un accesso più rapido.
Per configurare correttamente un CDN, consigliamo di valutare al meglio le impostazioni di durata della memorizzazione nella cache dei contenuti, e di valutare la memorizzazione nella cache a tempo indeterminato, spostando la logica dinamica sul server perimetrale.
Inoltre, servire i contenuti direttamente dall’edge del CDN è una tecnica che permette di offrire ulteriori vantaggi in termini di prestazioni.
Cumulative Layout Shift (CLS)
Il secondo paramentro Core Web Vitals, il Cumulative Layout Shift (CLS), misura la stabilità visiva del layout delle pagine web.
Nonostante siano stati fatti progressi nel migliorare questa metrica, circa un quarto dei siti web non raggiunge ancora la soglia consigliata, offrendo quindi un’opportunità significativa per migliorare l’esperienza utente e, soprattutto, per assicurarsi un vantaggio competitivo rispetto ai competitor.
Impostare dimensioni esplicite
Un modo per mitigare il problema dei cambiamenti di layout è quello di impostare dimensioni esplicite per ogni contenuto caricato sulla pagina.
Spesso, i cambiamenti di layout si verificano quando il contenuto esistente si sposta dopo il completamento del caricamento di altri contenuti. Per evitare ciò, è consigliabile impostare esplicitamente gli attributi width e height (o le relative proprietà CSS) per le immagini.
Tuttavia, secondo HTTP Archive, il 72% delle pagine contiene almeno un’immagine senza dimensioni specificate. In assenza di dimensioni esplicite, il browser imposta un’altezza predefinita di 0px, causando uno spostamento significativo del layout quando l’immagine viene caricata e le dimensioni vengono scoperte.
Correggere questa situazione rappresenta un’opportunità notevole per migliorare l’esperienza utente.
Utilizzare la proprietà CSS aspect-ratio
È importante notare che le immagini non sono l’unico fattore che contribuisce al CLS. I cambiamenti di layout possono essere causati anche da altri contenuti caricati dopo il rendering iniziale della pagina, come annunci di terze parti o video incorporati.
È il caso che afflige molto spesso ad esempio i siti di news o altri siti di informazione che incorporano banner di terze parti per la monetizzazione.
La proprietà CSS aspect-ratio può essere utile in questi casi. Essa consente di fornire un rapporto di aspetto esplicito alle immagini e agli elementi non immagine. Ciò consente al browser di calcolare automaticamente l’altezza appropriata in base alla larghezza, riducendo i cambiamenti di layout.
Anche se non conosciamo le dimensioni esatte del contenuto dinamico, impostare un min-height ragionevole è preferibile all’utilizzo dell’altezza predefinita di 0px per un elemento vuoto.
L’utilizzo di un min-height riduce l’ampiezza del cambiamento di layout, consentendo al contenitore di espandersi fino all’altezza del contenuto finale se necessario.
Cache back/forward (bfcache) dei browser
Altro aspetto importante è quello di rendere le pagine idonee per la cache back/forward (bfcache) dei browser. Questo meccanismo di navigazione consente di caricare istantaneamente una pagina precedente o successiva dalla cronologia del browser, eliminando i cambiamenti di layout durante il caricamento.
Secondo Google, l’introduzione di bfcache ha portato al miglioramento più significativo nel CLS nel 2022. Tuttavia, molti siti web non sono ancora idonei per la bfcache e perdono così i vantaggi di questa ottimizzazione delle prestazioni.
Ancora oggi Google sta lavorando per migliorare gli strumenti di test e audit per verificare la compatibilità con la bfcache.
Animare o modificare proprietà CSS
Un’altra fonte comune di cambiamenti di layout sono le animazioni degli elementi, come i banner dei cookie o altre notifiche che scorrono dall’alto o dal basso.
I dati di HTTP Archive indicano che le pagine che animano proprietà CSS che influenzano il layout hanno meno probabilità di ottenere un CLS “buono” rispetto alle pagine complessive.
Alcune proprietà, come larghezze, margini o bordi animati, sono associate a un CLS peggiore rispetto ad altre. Ogni volta che si anima una proprietà CSS che influisce sul layout, si verificano cambiamenti di layout.
È importante quindi evitare di animare o modificare proprietà CSS che richiedono al browser di aggiornare il layout della pagina, a meno che non sia in risposta a un’interazione dell’utente.
In questo caso è consigliabile preferire l’utilizzo della proprietà CSS transform per le transizioni e le animazioni, poiché sposta il lavoro sulla GPU e al di fuori del thread principale, migliorando così le prestazioni complessive e aiutando a ridurre il CLS.
First Input Delay (FID)
Naturalmente, esistono anche delle raccomandazioni specifiche riguardanti il First Input Delay (FID), che misura la reattività di una pagina alle interazioni dell’utente.
Nonostante molti siti web ottengano buoni risultati in FID, Google ha evidenziato alcune carenze comuni nella metrica e crede che ci siano ancora molte opportunità per migliorare la reattività complessiva dei siti web alle interazioni degli utenti.
Evitare o interrompere compiti lunghi
Una delle raccomandazioni è quella di evitare o interrompere compiti lunghi che possono influire sulla reattività della pagina. I compiti includono varie attività svolte dal browser, come il rendering, il layout, l’analisi e l’esecuzione di script.
Quando queste attività richiedono più di 50 millisecondi, il thread principale del browser può essere rallentato, ritardando così la risposta alle interazioni dell’utente.
Gli sviluppatori dovrebbero suddividere i compiti lunghi in compiti più piccoli per dare priorità al thread principale e consentire una gestione più rapida delle interazioni dell’utente e degli aggiornamenti del rendering.
Utilizzare isInputPending e Scheduler API
Un modo per arrivare a questo risultato è utilizzare API come isInputPending e Scheduler API.
L’API isInputPending restituisce un valore booleano che indica se ci sono input dell’utente in sospeso. Se il valore restituito è true, è possibile consentire al thread principale di gestire gli input dell’utente in sospeso.
L’API Scheduler, invece, consente di pianificare il lavoro in base a un sistema di priorità, distinguendo tra lavoro visibile all’utente e lavoro in background.
Evitare JavaScript non necessario
Un’altra raccomandazione utile per migliorare l’FID riguarda l’evitare JavaScript non necessario.
I siti web attualmente inviano una quantità sempre maggiore di JavaScript e ciò può creare un ambiente in cui le attività competono per l’attenzione del thread principale, influenzando la reattività complessiva del sito, soprattutto durante la fase di avvio.
Gli sviluppatori possono ottimizzare il codice JavaScript eliminando le parti inutilizzate mediante l’utilizzo dello strumento di copertura disponibile in Chrome DevTools.
In questo modo, si riducono le dimensioni delle risorse da analizzare e compilare, consentendo una maggiore fluidità dell’esperienza utente iniziale.
Inoltre, è consigliabile controllare periodicamente i tag utilizzati tramite un tag manager per eliminare quelli non più necessari e ottimizzare le dimensioni e l’efficienza del codice JavaScript.
Ottimizzare i rendering di grandi dimensioni
Non solo il JavaScript, ma anche il rendering di grandi dimensioni possono influire sulla reattività del sito web.
Aggiornamenti di rendering di grandi dimensioni possono interferire con la capacità del sito di rispondere alle interazioni dell’utente. È possibile ottimizzare il lavoro di rendering evitando di utilizzare la chiamata requestAnimationFrame() per compiti non visivi.
Questa chiamata viene gestita durante la fase di rendering e un eccessivo carico di lavoro può causarne ritardi negli aggiornamenti.
Inoltre, mantenere il DOM (Document Object Model) piccolo e utilizzare il contenimento CSS mediante la proprietà contain può aiutare a evitare lavori di layout e rendering non necessari.
Ottimizzare i Core Web Vitals non è semplice
Bene! Siamo giunti alla fine di questo articolo.
Come avrai capito dai nostri suggerimenti, ottimizzare i Core Web Vitals non è semplice e gli interventi richiedono spesso capacità tecniche non indifferenti, che spesso dipendono tra l’altro dal tipo di struttura utilizzata dal sito web, come ad esempio il CMS e le sue dinamiche.
Proprio per questa ragione abbiamo creato una soluzione come Phantom Layer, per permettere ai nostri clienti di intervenire su tutti questi aspetti in maniera automatica, ottimizzando i Core Web Vitals in appena 48h, senza dover impiegare lunghe sessioni di sviluppo o ricorrere a impegnative consulenze tecniche.
Stanley Napeñas
ICT Strategist & Developer @ ArrasGroupspa.com
“PhantomLayer ha migliorato notevolmente la velocità di caricamento e le prestazioni del sito web e delle pagine durante la navigazione, migliorando anche il punteggio Google PageSpeed Insight. In particolare, i contenuti fotografici adesso si caricano in modo molto rapido e l’esperienza utente risulta fluida, mettendoci in condizione di intrattenere i visitatori per più tempo, poiché essi riescono a visualizzare l’intera pagina in modo più veloce. “
Non trovi il piano giusto?
Ti serve più potenza?
Contattaci e scopri le nostre soluzioni Custom pensate per eCommerce, Portali di News e Siti Web di livello Enterprise.
