SEO Gennaro Mancini 24 Gennaio 2023 Tempo di lettura : 14 minuti

Gli interventi più importanti per migliorare i Core Web Vitals sul sito

Mettici alla prova

Analizza il tuo sito

Seleziona la lingua del database:

È ormai da tre anni che Google ha introdotto il concetto di Core Web Vitals o Segnali Web Essenziali, le metriche prestazionali che misurano le risposte delle pagine alle interazioni “vere” degli utenti (grazie ai cosiddetti dati sul campo) per consentirci di risolvere il problema delle esperienze utente negative sul sito. Entrati a far parte del Page Experience system e quindi ufficialmente fattore di ranking, per molti proprietari o gestori di siti questi parametri rischiano di essere ostici da comprendere e da affrontare: per questo, Google ha condiviso una guida agli interventi di ottimizzazione principali a cui dare priorità.

Core Web Vitals: le best practices per ottimizzare il sito

Il team di Chrome DevRel ha trascorso l’ultimo anno cercando di rispondere a una domanda: quali sono i consigli più importanti da dare agli sviluppatori per aiutarli a migliorare le prestazioni per i loro utenti? Da questa riflessione (e da questo intenso lavoro) è nata la guida alle best practices per ottimizzare i Core Web Vitals e aiutarci, in concreto, a decidere a cosa dare la priorità quando il nostro tempo è limitato.

Firmata da ben cinque autori – i Googler Philip Walton, Rick Viscomi, Barry Pollard, Brendan Kenny e Jeremy Wagner – la pagina di supporto rappresenta una raccolta delle indicazioni che Google ritiene siano più efficaci per migliorare le prestazioni dei Segnali Web Essenziali, aggiungendosi ai numerosi suggerimenti forniti finora per migliorare i punteggi di queste metriche.

Come si legge in pagina, infatti, ognuno dei consigli precedenti “può, individualmente, migliorare le prestazioni di molti siti”, ma “l’intero set di consigli è certamente travolgente e, realisticamente, non c’è modo che una persona o un sito possa seguirli tutti”. A meno che le prestazioni web non siano il nostro lavoro quotidiano, infatti, probabilmente non è facile individuare quali interventi possano generare il maggiore impatto positivo sul sito: ad esempio, “potresti aver letto che l’implementazione di CSS critici può migliorare le prestazioni di caricamento e potresti anche aver sentito che è importante ottimizzare le tue immagini”, prosegue l’articolo, ma come decidere a cosa dedicarsi se non abbiano tempo per lavorare su entrambe le cose?

Come migliorare i Core web Vitals, l’elenco dei consigli tecnici per intervenire

Si è quindi reso necessario fornire una guida pensata in modo diverso, prendendo in considerazione non solo i meriti tecnici di una data raccomandazione, ma anche i fattori umani e organizzativi che influenzano la probabilità che gli sviluppatori siano effettivamente in grado di adottare questi consigli. In altre parole, alcune raccomandazioni possono avere un enorme impatto in teoria, ma in realtà pochissimi siti avranno il tempo o le risorse per implementarle; allo stesso modo, alcuni interventi sono fondamentali, ma la maggior parte dei siti Web sta già seguendo queste pratiche.

Alla luce di ciò, la nuova guida di Google al miglioramento dei Core Web Vitals si concentra su tre punti chiave che consentono di superare i limiti del vecchio approccio:

Raccomandazioni che possono avere il maggiore impatto nel mondo reale.
Raccomandazioni pertinenti e applicabili alla maggior parte dei siti.
Raccomandazioni realistiche e possibili da implementare per la maggior parte degli sviluppatori.

Gli interventi su Largest Contentful Paint (LCP)

La prima serie di raccomandazioni riguarda Largest Contentful Paint (LCP), che è una misura delle prestazioni di carico, stimando nello specifico il tempo necessario affinché il contenuto principale di una pagina diventi visibile agli utenti. Stando alle statistiche rivelate da webdev, è quella con cui il maggior numero di siti ha difficoltà, in quanto solo la metà circa di tutti i siti sul Web oggi soddisfa la soglia consigliata.

Rendere la risorsa LCP rilevabile dall’origine HTML

Secondo il Web Almanac 2022 di HTTP Archive, il 72% delle pagine per dispositivi mobili ha un’immagine come elemento LCP: ne consegue che, affinché la maggior parte dei siti ottimizzi il proprio LCP, dovranno garantire che tali immagini possano essere caricate rapidamente.

Ciò che potrebbe non essere ovvio per molti sviluppatori è che il tempo necessario per caricare un’immagine è solo una parte della sfida, perché un’altra parte critica è il tempo prima che un’immagine inizi a caricarsi, e i dati suggeriscono che è proprio qui che in realtà molti siti inciampano.

Infatti, tra le pagine in cui l’elemento LCP era un’immagine, il 39% di quelle immagini aveva URL di origine che non erano rilevabili dalla fonte del documento HTML. In altre parole, quegli URL non sono stati trovati negli attributi HTML standard (come <img src=”…”>o <link rel=”preload” href=”…”>), cosa che invece avrebbe consentito al browser di scoprirli rapidamente e iniziare a caricarli immediatamente.

Attendere che i file CSS o JavaScript siano completamente scaricati, analizzati ed elaborati prima ancora che l’immagine possa iniziare a caricarsi potrebbe essere già troppo tardi per le prestazioni di una pagina. Al contrario, garantire che la risorsa LCP sia rilevabile dall’origine HTML può portare a miglioramenti misurabili e sblocca anche ulteriori opportunità per dare priorità alla risorsa.

Come regola generale, dice Google, se il nostro elemento LCP è un’immagine l’URL dell’immagine dovrebbe essere sempre individuabile dalla sorgente HTML. Alcuni suggerimenti per renderlo possibile sono:

Caricare l’immagine utilizzando un elemento <img> con l’attributo src o srcset, senza utilizzare attributi non-standard come data-src che richiedono JavaScript per il rendering, poiché sarà sempre più lento. Il 9% delle pagine oscura la propria immagine LCP dietro data-src.
Preferire il rendering lato server (SSR) rispetto al rendering lato client (CSR), poiché SSR implica che il markup dell’intera pagina (inclusa l’immagine) sia presente nell’origine HTML. Le soluzioni CSR richiedono l’esecuzione di JavaScript prima che l’immagine possa essere rilevata.
Se l’immagine deve essere referenziata da un file CSS o JS esterno, possiamo comunque includerla nel codice sorgente HTML tramite un tag <link rel=”preload”>. Le immagini cui fanno riferimento gli stili in linea non sono rilevabili dallo scanner di precaricamento del browser quindi, anche se vengono trovate nell’origine HTML, la loro individuazione potrebbe comunque essere bloccata durante il caricamento di altre risorse, quindi il precaricamento può essere utile in questi casi.

Dare la priorità alla risorsa LCP

Un primo passaggio fondamentale per garantire che la risorsa LCP possa iniziare a caricarsi in anticipo è quindi accertarci che la stessa possa essere scoperta dall’origine HTML, ma un altro punto importante è garantire che il caricamento di quella risorsa abbia la priorità, e non sia messo in coda dietro un gruppo di altre risorse meno importanti.

Ad esempio, anche se l’immagine LCP è presente nel sorgente HTML utilizzando un tag <img> standard, se la pagina include una dozzina di tag <script> nel <head> del documento prima di quel tag <img>, potrebbe passare un po’ di tempo prima che la risorsa immagine inizi a caricarsi.

Il modo più semplice per risolvere questo problema è fornire un suggerimento al browser su quali risorse hanno la massima priorità impostando il nuovo attributo fetchpriority=”high” sul tag <img> o <link> che carica l’immagine LCP. Questo comando indica al browser di caricare l’immagine prima, invece di aspettare il completamento di quegli script.

Sempre secondo il Web Almanac, solo lo 0,03% delle pagine idonee sta sfruttando questa nuova API, e pertanto ci sono molte opportunità per la maggior parte dei siti sul Web di migliorare LCP con pochissimo lavoro. Sebbene l’attributo fetchpriority sia attualmente supportato solo nei browser basati su Chromium, questa API è un miglioramento progressivo che altri browser semplicemente ignorano, quindi Google consiglia “vivamente agli sviluppatori di utilizzarla ora”.

Per i browser non Chromium, l’unico modo per garantire che la risorsa LCP abbia la priorità rispetto ad altre risorse è farvi riferimento in precedenza nel documento. Usando di nuovo l’esempio di un sito con molti tag <script> nel <head> del documento, per esser certi che la risorsa LCP abbia la priorità rispetto a quelle risorse di script possiamo aggiungere un tag <link rel=”preload”> prima di uno qualsiasi di quegli script, oppure spostare quegli script al di sotto del successivo <img> nel <body>. Sebbene funzioni, è meno ergonomico rispetto all’utilizzo di fetchpriority, quindi bisogna sperare che altri browser aggiungano presto il supporto.

Un altro aspetto critico dell’assegnazione della priorità alla risorsa LCP consiste nell’assicurarsi di non fare nulla che ne provochi la depriorizzazione , come l’aggiunta dell’attributo loading=”lazy”. Oggi, il 10% delle pagine ha effettivamente impostato un lazy loading sulla propria immagine LCP. La guida suggerisce di prestare attenzione alle soluzioni di ottimizzazione delle immagini che applicano indiscriminatamente un comportamento di caricamento lento a tutte le immagini, cercando di impostare un modo per ignorare tale comportamento per l’immagine LCP – se non siamo sicuro di quale immagine sarà l’LCP, dice l’articolo, possiamo provare “a utilizzare l’euristica per scegliere un candidato ragionevole”.

Rinviare le risorse non critiche è un altro modo per aumentare efficacemente la priorità relativa della risorsa LCP: ad esempio, gli script che non alimentano l’interfaccia utente (come script di analisi o widget social) possono essere posticipati in modo sicuro fino a dopo l’attivazione dell’evento load, il che garantisce che non competano con altre risorse critiche (come la risorsa LCP) per la larghezza di banda della rete .

Per riassumere, Google ci invita a seguire queste best practices per garantire che la risorsa LCP venga caricata in anticipo e con priorità elevata:

Impostare fetchpriority=”high”al tag <img> dell’immagine LCP o al tag <link rel=”preload”>, se la la risorsa LCP viene caricata in questo modo.
Non impostare mai loading=”lazy”sul tag <img> dell’immagine LCP, altrimenti perderemoperderà la priorità dell’immagine e ritarderemo l’avvio del caricamento.
Rimandare le risorse non critiche quando possibile: possiamo spostarle alla fine del documento, utilizzando il caricamento lento nativo per immagini o iframe, o caricarle in modo asincrono tramite JavaScript.

Usare un CDN per ottimizzare il TTFB di documenti e risorse

I due consigli precedenti si sono concentrati sul garantire che la risorsa LCP venga scoperta in anticipo e riceva una priorità in modo che possa iniziare a caricarsi immediatamente. L’ultimo pezzo di questo puzzle è assicurarci che anche la risposta iniziale del documento arrivi il più rapidamente possibile.

Come spiegano gli sviluppatori di Chrome DevRel, il browser non può iniziare a caricare alcuna sottorisorsa fino a quando non riceve il primo byte della risposta iniziale del documento HTML: prima ciò accade, prima può iniziare anche tutto il resto. Questo tempo è noto come Time to First Byte (TTFB) e il modo migliore per ridurre il TTFB è:

Offrire contenuti il più geograficamente vicino possibile ai nostri utenti.
Memorizzare nella cache il contenuto, in modo che il contenuto richiesto di recente possa essere nuovamente offerto rapidamente.

Il modo migliore per fare entrambe queste cose è usare un CDN, che distribuiscono le risorse ai server perimetrali, sparsi in tutto il mondo, limitando così la distanza che tali risorse devono percorrere in rete fino agli utenti finali. I CDN di solito hanno anche controlli di memorizzazione a grana fine nella cache, che possono essere personalizzati e ottimizzati per le esigenze del nostro sito.

Molti sviluppatori hanno familiarità con l’utilizzo di un CDN per ospitare asset statici, ma i CDN possono servire e memorizzare nella cache anche documenti HTML, compresi quelli generati dinamicamente.

Secondo il Web Almanac, solo il 29% delle richieste di documenti HTML è stato servito da un CDN, il che significa che esiste un’opportunità significativa per i siti di richiedere ulteriori risparmi.

Alcuni suggerimenti per configurare i CDN sono:

Valutare l’aumento della durata della memorizzazione nella cache dei contenuti – ad esempio, è effettivamente fondamentale che i contenuti siano sempre aggiornati? O possono essere obsoleti per alcuni minuti?
Considerare eventualmente anche la memorizzazione nella cache del contenuto a tempo indeterminato e quindi l’eliminazione della cache se/quando eseguiamo un aggiornamento.
Scoprire se è possibile spostare la logica dinamica attualmente in esecuzione sul server di origine verso l’edge (una funzionalità della maggior parte dei CDN moderni).

In generale, ogni volta che possiamo servire contenuti direttamente dall’edge (evitando un viaggio al server di origine) è una vittoria in termini di prestazioni. E anche nei casi in cui dobbiamo fare il viaggio di ritorno al server di origine, i CDN sono generalmente ottimizzati per farlo molto più rapidamente, quindi è una vittoria in entrambi i casi.

Gli interventi su Cumulative Layout Shift (CLS)

La profonda guida pubblicata su web.dev si concentra poi sul secondo Core Web Vitals, ovvero il Cumulative Layout Shift (CLS), che sappiamo essere una misura della stabilità visiva del layout delle pagine web. A partire dal 2020, le statistiche dicono che questa metrica è migliorata molto sul Web, ma circa un quarto dei siti Web non soddisfa ancora la soglia consigliata, offrendo quindi una grande opportunità per molti siti di migliorare la propria esperienza utente.

Impostare dimensioni esplicite su qualsiasi contenuto caricato dalla pagine

I cambiamenti di layout di solito si verificano quando il contenuto esistente si sposta dopo che altri contenuti hanno terminato il caricamento: pertanto, il modo principale per mitigare questo problema è prenotare il più possibile ogni spazio richiesto in anticipo.

Il modo più semplice per correggere i cambiamenti di layout causati da immagini non dimensionate è impostare esplicitamente gli attributi width e height (o proprietà CSS equivalenti), ma secondo HTTP Archive ancora oggi il 72% delle pagine ha almeno un’immagine non dimensionata. Senza una dimensione esplicita, i browser imposteranno inizialmente un’altezza predefinita di 0px e potrebbero quindi causare un notevole spostamento del layout quando l’immagine viene finalmente caricata e le dimensioni vengono scoperte. Ciò rappresenta un’enorme opportunità per il Web collettivo e tale opportunità richiede uno sforzo molto inferiore rispetto ad alcune delle altre raccomandazioni suggerite nell’articolo.

È anche importante tenere presente che le immagini non sono gli unici contributori di CLS. I cambiamenti di layout possono essere causati da altri contenuti che in genere vengono caricati dopo il rendering iniziale della pagina, inclusi annunci di terze parti o video incorporati. La proprietà aspect-ratio può aiutare a combattere questo problema: si tratta di una funzionalità CSS relativamente nuova che consente agli sviluppatori di fornire esplicitamente un rapporto di aspetto alle immagini e agli elementi non immagine. Ciò ci consentirà di impostare una width dinamica (ad esempio in base alle dimensioni dello schermo) e fare in modo che il browser calcoli automaticamente l’altezza appropriata, più o meno come fanno per le immagini con dimensioni.

A volte non è possibile conoscere l’esatta dimensione del contenuto dinamico poiché è, per sua stessa natura, dinamico: tuttavia, anche se non conosciamo le dimensioni esatte dell’elemento, possiamo comunque adottare misure per ridurre la gravità dei cambiamenti di layout. L’impostazione di un min-height ragionevole è quasi sempre meglio che consentire al browser di utilizzare l’altezza predefinita di 0px per un elemento vuoto. Anche l’uso di una min-height è di solito una soluzione semplice, in quanto consente comunque al contenitore di crescere fino all’altezza del contenuto finale, se necessario, e aiuta a ridurre quella quantità di crescita dall’intero importo a un livello auspicabilmente più tollerabile.

Rendere le pagine idonee per bfcache

I browser utilizzano un meccanismo di navigazione chiamato cache back/forward, o bfcache in breve, per caricare istantaneamente una pagina precedente o successiva nella cronologia del browser direttamente da uno snapshot della memoria.

Il bfcache è una significativa ottimizzazione delle prestazioni a livello di browser ed elimina completamente i cambiamenti di layout durante il caricamento della pagina, che per molti siti è la parte in cui si verifica la maggior parte del loro CLS, e secondo Google “l’introduzione di bfcache ha generato il più grande miglioramento in CLS che abbiamo visto nel 2022″.

Nonostante ciò, un numero significativo di siti Web non è idoneo per bfcache e quindi perde questa vittoria in termini di prestazioni Web per un numero significativo di navigazioni: a meno che la nostra pagina non stia caricando informazioni sensibili che non desideriamo vengano ripristinate dalla memoria, il consiglio degli esperti è assicurarci che le nostre pagine siano idonee.

Dal punto di vista pratico, come proprietari dei siti possiamo verificare che le pagine siano idonee per bfcache e lavorare su qualsiasi motivo per cui non lo siano: Chrome ha già un tester bfcache in DevTools e quest’anno prevede “di migliorare gli strumenti con un nuovo audit Lighthouse che esegue un test simile e un’API per misurarlo sul campo”. Inoltre, aggiunge l’articolo, bfcache generalmente migliorerà anche altri Core Web Vitals (anche se per ora sembra dare i maggiori guadagni proprio sul CLS) ed è considerato una delle numerose navigazioni istantanee disponibili per migliorare drasticamente la navigazione delle pagine.

Evitare animazioni/transizioni che utilizzano proprietà CSS layout-inducing

Un’altra fonte comune di spostamenti di layout riguarda le animazioni degli elementi: ad esempio, i cookie banner o altri banner di notifica che scorrono dall’alto o dal basso spesso contribuiscono a CLS. Ciò è particolarmente problematico quando questi banner escludono altri contenuti, ma anche quando non lo fanno l’animazione può comunque avere un impatto su CLS.

Sebbene i dati di HTTP Archive “non possano collegare in modo definitivo le animazioni ai cambiamenti di layout”, i dati mostrano che le pagine che animano qualsiasi proprietà CSS che potrebbe influire sul layout hanno il 15% in meno di probabilità di avere un CLS “buono” rispetto alle pagine in generale, e inoltre alcune proprietà sono associate a CLS peggiore di altre. Ad esempio, le pagine che animano larghezze margin o border hanno un CLS “scarso” a quasi il doppio della frequenza con cui le pagine complessive vengono valutate come scadenti.

Questo forse non è sorprendente, dicono gli sviluppatori di Chrome DevRel, perché ogni volta che trasferiamo o animiamo una proprietà CSS layout-inducing si verificheranno cambiamenti di layout, e se questi cambiamenti di layout non sono entro 500 millisecondi da un’interazione dell’utente, avranno un impatto su CLS.

Ciò che può sorprendere alcuni sviluppatori è che questo è vero anche nei casi in cui l’elemento viene portato al di fuori del normale flusso di documenti: ad esempio, elementi posizionati in modo assoluto che animano top o left causeranno cambiamenti di layout, anche se non stanno spingendo via altri contenuti. Tuttavia, se invece di animare top o left si anima transform:translateX() o transform:translateY(), il browser non aggiornerà il layout della pagina e quindi non produrrà alcun cambiamento di layout.

Preferire l’animazione delle proprietà CSS che possono essere aggiornate sul thread del compositor del browser è stata a lungo una best practices per le prestazioni, perché sposta quel lavoro sulla GPU e fuori dal thread principale e – oltre a supportare le prestazioni generali, può anche aiutare a migliorare CLS.

Come regola generale, non dobbiamo animare o trasferire mai alcuna proprietà CSS che richieda al browser di aggiornare il layout della pagina, a meno che non lo stiamo facendo in risposta a un tocco dell’utente o alla pressione di un tasto (ma non hover). E, quando possibile, dovremmo preferire le transizioni e le animazioni utilizzando la proprietà CSS transform.

L’audit Lighthouse Evita animazioni non composte avvisa quando una pagina anima proprietà CSS potenzialmente lente.

Gli interventi su First Input Delay (FID)

Ovviamente, l’ultima serie di raccomandazioni riguarda il First Input Delay (FID), che è una misura della reattività di una pagina alle interazioni dell’utente: anche se la maggior parte dei siti sul Web attualmente ottiene ottimi risultati in FID, in passato Google ha documentato carenze della metrica FID e ritiene che ci siano ancora molte opportunità per i siti di migliorare la loro reattività generale alle interazioni degli utenti.

La guida parla esplicitamente anche della nuova metrica Interaction to Next Paint (INP), definita “un possibile successore di FID”, e tutte le raccomandazioni riportate di seguito si applicano ugualmente bene sia a FID che a INP. Dato che i siti ottengono risultati peggiori su INP rispetto a FID, in particolare sui dispositivi mobili, i Googler invitano gli sviluppatori a prendere seriamente in considerazione questi consigli sulla reattività, anche se riscontrano un FID “buono”.

Evitare o interrompere compiti lunghi

Le attività o task sono qualsiasi parte del lavoro discreto svolto dal browser, e includono il rendering, il layout, l’analisi e la compilazione e l’esecuzione di script. Quando le attività diventano attività lunghe, ovvero 50 millisecondi o più, impediscono al thread principale di rispondere rapidamente agli input dell’utente.

Secondo il Web Almanac, ci sono molte prove che suggeriscono che gli sviluppatori potrebbero fare di più per evitare o interrompere attività lunghe; anche se la suddivisione di attività lunghe potrebbe essere uno sforzo più impegnativo degli altri consigli presentati, è comunque più “semplice” rispetto ad altre tecniche escluse dall’articolo (sulla base delle premesse su esposte).

Il principio da rispettare è sforzarci di fare il minor lavoro possibile in JavaScript, ma possiamo aiutare un po’ il thread principale suddividendo le attività lunghe in attività più piccole: uno dei metodi per raggiungere l’obiettivo è dare spesso priorità al thread principale, in modo che gli aggiornamenti del rendering e altre interazioni dell’utente possano avvenire più rapidamente.

Un’altra opzione è prendere in considerazione l’utilizzo di API come isInputPending e Scheduler API:

La prima – isInputPending – è una funzione che restituisce un valore booleano che indica se un input dell’utente è in sospeso: se restituisce true, possiamo far passare il thread principale in modo che possa gestire l’input dell’utente in sospeso.

L’API Scheduler è un approccio più avanzato, che consente di pianificare il lavoro in base a un sistema di priorità che tiene conto del fatto che il lavoro svolto sia visibile all’utente o in background.

Interrompendo le attività lunghe, offriamo al browser maggiori opportunità di adattarsi a lavori critici visibili all’utente, come la gestione delle interazioni e gli eventuali aggiornamenti di rendering risultanti.

Evitare JavaScript non necessario

Secondo Google non ci sono dubbi: i siti web stanno inviando più JavaScript che mai e la tendenza non sembra destinata a cambiare tanto presto. Un ricorso massivo a JavaScript però crea un ambiente in cui le attività competono per l’attenzione del thread principale, e ciò può sicuramente influire sulla reattività del sito Web, specialmente durante quel cruciale periodo di avvio.

Questo non è un problema irrisolvibile, tuttavia, e abbiamo alcune opzioni di ottimizzazione:

Utilizzare il coverage tool in Chrome DevTools per trovare il codice inutilizzato nelle risorse del nostro sito web. Riducendo le dimensioni delle risorse necessarie durante l’avvio, possiamo assicurarci che il sito Web impieghi meno tempo ad analizzare e compilare il codice, determinando un’esperienza utente iniziale più fluida.
A volte il codice inutilizzato che troviamo utilizzando lo strumento di copertura è contrassegnato come “inutilizzato” perché non è stato eseguito durante l’avvio, ma è ancora necessario per alcune funzionalità in futuro: questo è il codice che possiamo spostare in un pacchetto separato tramite la suddivisione del codice.
Se utilizziamo un tag manager, è importante controllare periodicamente i tag per esser certi che siano ottimizzati o anche che siano ancora in uso. I tag meno recenti con codice inutilizzato possono essere eliminati per rendere il codice JavaScript del tag manager più piccolo e più efficiente.

Evitare aggiornamenti di rendering di grandi dimensioni

JavaScript non è l’unica cosa che può influenzare la reattività del sito web: anche il rendering può essere un tipo di lavoro costoso a sé stante e, quando si verificano aggiornamenti di rendering di grandi dimensioni, possono interferire con la capacità del sito Web di rispondere agli input dell’utente.

L’ottimizzazione del lavoro di rendering non è un processo semplice e spesso dipende da ciò che stiamo cercando di ottenere; ad ogni modo, ci dice la guida, ci sono alcune cose che possiamo fare per garantire che gli aggiornamenti di rendering siano ragionevoli e non si estendano in attività lunghe:

Evitare di usare requestAnimationFrame() per fare qualsiasi lavoro non visivo. Le chiamate requestAnimationFrame() vengono gestite durante la fase di rendering del ciclo di eventi: quando viene eseguito troppo lavoro durante questo passaggio, gli aggiornamenti del rendering possono essere ritardati. È essenziale che qualsiasi lavoro svolto con requestAnimationFrame() sia riservato esclusivamente alle attività che comportano aggiornamenti del rendering.
Mantenere piccole le dimensioni del DOM. La dimensione del DOM e l’intensità del lavoro di layout sono correlate: quando il renderer deve aggiornare il layout per un DOM molto grande, il lavoro richiesto per ricalcolare il layout può aumentare notevolmente.
Usare CSS containment. Il contenimento CSS si basa sulla proprietà CSS contain, che fornisce istruzioni al browser su come eseguire il lavoro di layout per il contenitore su cui è impostata la proprietà, inclusi anche l’isolamento dell’ambito del layout e il rendering in una radice specifica nel DOM. Non è sempre un processo facile, ma isolando le aree contenenti layout complessi possiamo evitare di eseguire lavori di layout e rendering non necessari.

Migliorare i Core Web Vitals con questi interventi alla portata di tutti

I Core Web Vitals sono una metrica importante per fornire un’esperienza utente positiva e per influenzare positivamente la valutazione nel ranking su Google.

Migliorare le prestazioni della pagina può sembrare un compito arduo, soprattutto considerando che c’è una montagna di indicazioni sul Web da considerare, ma questa nuova guida è sufficientemente sintetica, realistica e applicabile alla maggior parte dei siti Web, e soprattutto può dare un impatto significativo in termini di risultati da raggiungere e di superamento delle soglie di punteggio dei Segnali Web Essenziali delle nostre pagine.

Seguendo questi consigli, che prevedono come detto l’utilizzo di un CDN per ridurre il TTFB, l’impostazione di dimensioni esplicite per i contenuti on-page per migliorare CLS, rendere le pagine idonee per bfcache ed evitare JavaScript e animazioni/transizioni non necessari per FID, possiamo capire come gestire al meglio il nostro tempo, implementando soluzioni fattibili e pratiche che davvero possono aiutarci a migliorare le prestazioni.