Una raccolta di best practice che il team di Chrome DevRel ritiene siano i modi più efficaci per migliorare le prestazioni di Core Web Vitals nel 2023.
Nel corso degli anni, Google ha fornito agli sviluppatori web molti consigli su come migliorare il rendimento.
Sebbene ognuno di questi consigli, individualmente, possa migliorare il rendimento di molti siti, l'intero insieme di consigli è indubbiamente un'impresa e, realisticamente, non c'è modo che un'unica persona o un solo sito possa seguirli tutti.
A meno che il rendimento sul web non sia il tuo compito quotidiano, probabilmente non è ovvio quali consigli avranno il maggiore impatto positivo sul tuo sito. Ad esempio, potresti aver letto che l'implementazione di CSS fondamentali può migliorare le prestazioni di caricamento e che è importante ottimizzare le immagini. Ma, se non hai tempo per lavorare su entrambe le cose, come sceglieresti quale scegliere?
Il team di Chrome ha trascorso l'ultimo anno cercando di rispondere a questa domanda: quali sono i consigli più importanti che possiamo dare agli sviluppatori per aiutarli a migliorare le prestazioni per i loro utenti?
Per rispondere adeguatamente a questa domanda, non dobbiamo considerare solo i meriti tecnici di ogni consiglio, 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, alcuni consigli possono avere un enorme impatto teorico, ma in realtà pochissimi siti avranno il tempo o le risorse per implementarli. Analogamente, alcuni consigli sono fondamentali, ma la maggior parte dei siti web sta già seguendo queste pratiche.
In breve, volevamo che il nostro elenco dei principali consigli per migliorare il rendimento web si concentrasse su:
- I consigli che riteniamo avranno il massimo impatto nel mondo reale
- Consigli pertinenti e applicabili alla maggior parte dei siti
- Consigli realistici di implementazione per la maggior parte degli sviluppatori
Nel corso dell'ultimo anno abbiamo dedicato molto tempo a controllare l'intero set di consigli per il rendimento e a valutarli (sia qualitativamente che quantitativamente) in base ai tre criteri riportati sopra.
Questo post illustra i nostri principali consigli per migliorare le prestazioni di ciascuna delle metriche Core Web Vitals. Se non hai esperienza con il rendimento sul web o se stai cercando di decidere quale sarà il rendimento più redditizio, riteniamo che questi consigli siano il punto di partenza migliore.
Largest Contentful Paint (LCP)
La nostra prima serie di consigli riguarda la metrica Largest Contentful Paint (LCP), una misurazione delle prestazioni di caricamento. Tra le tre metriche di Core Web Vitals, LCP è quella con cui il maggior numero di siti riscontra problemi (solo circa la metà di tutti i siti presenti sul web oggi soddisfa la soglia consigliata), quindi iniziamo da lì.
Assicurati che la risorsa LCP sia rilevabile dall'origine HTML
Secondo 2022 Web Almanac di HTTP Archive, il 72% delle pagine per dispositivi mobili ha un'immagine come elemento LCP, il che significa che per la maggior parte dei siti è necessario assicurarsi che le immagini vengano caricate rapidamente.
Ciò che potrebbe non essere ovvio a molti sviluppatori è che il tempo necessario per caricare un'immagine è solo una parte della sfida. Un'altra parte fondamentale è il tempo prima dell'inizio del caricamento di un'immagine e i dati di HTTP Archive suggeriscono che è proprio questo il punto in cui vengono interrotti molti siti.
Infatti, delle pagine in cui l'elemento LCP era un'immagine, il 39% di queste immagini aveva URL di origine non rilevabili dall'origine del documento HTML. In altre parole, tali URL non venivano trovati negli attributi HTML standard (come <img src="..."> o <link rel="preload" href="...">), che consentivano al browser di individuarli rapidamente e iniziare subito a caricarli.
Se una pagina deve attendere il completamento del download, dell'analisi e dell'elaborazione dei file CSS o JavaScript prima che l'immagine inizi a caricarsi, potrebbe essere già troppo tardi.
Come regola generale, se l'elemento LCP è un'immagine, l'URL dell'immagine deve essere sempre rilevabile dal codice sorgente HTML. Ecco alcuni suggerimenti per renderlo possibile:
Carica l'immagine utilizzando un elemento
<img>con l'attributosrcosrcset. Non utilizzare attributi non standard comedata-srcche richiedono JavaScript per il rendering, in quanto risulteranno sempre più lenti. Il 9% delle pagine oscura l'immagine LCP dietro adata-src.Privilegia il rendering lato server (SSR) rispetto al rendering lato client (CSR), in quanto SSR implica che nel codice sorgente HTML è presente il markup dell'intera pagina (inclusa l'immagine). Le soluzioni CSR richiedono l'esecuzione di JavaScript prima che l'immagine possa essere rilevata.
Se devi fare riferimento alla tua immagine da un file CSS o JS esterno, puoi comunque includerla nel codice sorgente HTML tramite un tag
<link rel="preload">. Tieni presente che le immagini a cui fa riferimento gli stili incorporati non sono rilevabili dallo scanner di precaricamento del browser, quindi, anche se si trovano nell'origine HTML, il loro reperimento potrebbe essere comunque bloccato durante il caricamento di altre risorse, quindi il precaricamento può essere utile in questi casi.
Per aiutarti a capire se la tua immagine LCP presenta problemi di rilevabilità, Lighthouse rilascerà un nuovo controllo nella versione 10.0 (previsto a gennaio 2023).
Garantire che la risorsa LCP sia rilevabile dal codice sorgente HTML può portare a miglioramenti misurabili e offre anche ulteriori opportunità per assegnare la priorità alla risorsa, che è il nostro prossimo consiglio.
Assicurati che la risorsa LCP abbia la priorità
Verificare che la risorsa LCP possa essere individuata dal codice sorgente HTML è un primo passo fondamentale per assicurare che la risorsa LCP inizi a caricarsi in anticipo, ma un altro passaggio importante consiste nell'assicurarsi che il caricamento di quella risorsa sia assegnato a priorità e non venga messo in coda dietro a un insieme di altre risorse meno importanti.
Ad esempio, anche se l'immagine LCP è presente nel codice 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 trascorrere un po' di tempo prima che inizi il caricamento della risorsa immagine.
Il modo più semplice per risolvere questo problema è fornire al browser un suggerimento riguardo alle risorse che hanno la priorità più alta impostando il nuovo attributo fetchpriority="high" nel tag <img> o <link> che carica l'immagine LCP. In questo modo indichi al browser di caricarlo prima, invece di attendere il completamento degli script.
Secondo Web Almanac, solo lo 0,03% delle pagine idonee utilizza questa nuova API, il che significa che per la maggior parte dei siti sul web esiste molte opportunità di migliorare LCP con un impegno minimo. Al momento l'attributo fetchpriority è supportato solo nei browser basati su Chromium, ma questa API è un miglioramento progressivo che gli altri browser ignorano, pertanto consigliamo vivamente agli sviluppatori di utilizzarla subito.
Per i browser non Chromium, l'unico modo per garantire che la risorsa LCP abbia la priorità rispetto alle altre risorse è farvi riferimento in precedenza nel documento. Utilizzando di nuovo l'esempio di un sito con molti tag <script> nella sezione <head> del documento, per assicurarti che le risorse LCP abbiano la priorità rispetto a quelle delle risorse di script, puoi aggiungere un tag <link rel="preload"> prima di ognuno di questi script oppure puoi spostare questi script sotto <img> in un secondo momento in <body>. Anche se funziona, è meno ergonomico dell'utilizzo di fetchpriority, quindi ci auguriamo che altri browser aggiungano presto il supporto.
Un altro aspetto fondamentale dell'assegnazione della priorità alla risorsa LCP è assicurarti di non fare nulla che ne causi l'assegnazione di priorità, ad esempio l'aggiunta dell'attributo loading="lazy". Oggi, il 10% delle pagine ha impostato loading="lazy" sull'immagine LCP. Presta attenzione alle soluzioni di ottimizzazione delle immagini che applicano in modo indiscriminato un comportamento di caricamento lento a tutte le immagini. Se forniscono un modo per ignorare questo comportamento, assicurati di utilizzarlo per l'immagine LCP. Se hai dubbi su quale immagine verrà visualizzata come LCP, prova a utilizzare l'euristica per scegliere un candidato ragionevole.
Il differimento delle risorse non critiche è un altro modo per aumentare in modo efficace la priorità relativa della risorsa LCP. Ad esempio, gli script che non alimentano l'interfaccia utente (come gli script di analisi o i widget social) possono essere rinviati in tutta sicurezza fino all'attivazione dell'evento load, per evitare che competano con altre risorse critiche (come la risorsa LCP) per larghezza di banda della rete.
Riassumendo, devi seguire queste best practice per assicurarti che la risorsa LCP venga caricata in anticipo e con priorità elevata:
- Aggiungi
fetchpriority="high"al tag<img>dell'immagine LCP. Se la risorsa LCP viene caricata tramite un tag<link rel="preload">, non preoccuparti: puoi impostarefetchpriority="high"anche su questo tag. - Non impostare mai
loading="lazy"nel tag<img>dell'immagine LCP. In questo modo verrà ridotta la priorità dell'immagine e si ritarderà il caricamento. - Rinvia le risorse non critiche quando possibile. Puoi spostarli alla fine del documento, utilizzare il caricamento lento nativo per immagini o iframe oppure caricarli in modo asincrono tramite JavaScript.
Usa una CDN per ottimizzare il TTFB di documenti e risorse
I due suggerimenti precedenti si concentravano sull'assicurare che la risorsa LCP venga rilevata in anticipo e con priorità, in modo che possa iniziare a caricarsi immediatamente. L'ultimo pezzo di questo puzzle è assicurarsi che arrivi il più rapidamente possibile anche la risposta iniziale del documento.
Il browser non può iniziare a caricare nessuna risorsa secondaria finché non riceve il primo byte della risposta iniziale del documento HTML e prima ciò accade, prima possono verificarsi anche gli altri.
Questo orario è noto come Time to First Byte (TTFB) e il modo migliore per ridurre il TTFB è:
- Pubblica i tuoi contenuti nella posizione più vicina possibile ai tuoi utenti
- Memorizza nella cache i contenuti richiesti di recente in modo che possano essere pubblicati di nuovo rapidamente.
Il modo migliore per eseguire entrambe queste operazioni è utilizzare una CDN. Le reti CDN distribuiscono le tue risorse su server perimetrali, distribuiti in tutto il mondo, limitando così la distanza che queste risorse devono percorrere in rete per raggiungere gli utenti. Le CDN di solito dispongono di controlli della memorizzazione nella cache granulari che possono essere personalizzati e ottimizzati in base alle esigenze del tuo sito.
Molti sviluppatori sanno come utilizzare una rete CDN per ospitare asset statici, ma possono anche pubblicare e memorizzare nella cache documenti HTML, anche quelli generati dinamicamente.
Secondo Web Almanac, solo il 29% delle richieste di documenti HTML è stato gestito da una CDN, il che significa che i siti hanno grandi opportunità di richiedere risparmi aggiuntivi.
Ecco alcuni suggerimenti per la configurazione delle reti CDN:
- Valuta la possibilità di aumentare il tempo per cui i contenuti vengono memorizzati nella cache (ad esempio, è fondamentale che i contenuti siano sempre attuali? Oppure potrebbero esserlo di pochi minuti?).
- Potresti anche memorizzare nella cache i contenuti a tempo indeterminato e quindi svuotare la cache se/quando esegui un aggiornamento.
- Scopri se puoi spostare a livello perimetrale la logica dinamica in esecuzione sul tuo server di origine (una funzionalità delle CDN più moderne).
In generale, ogni volta che è possibile pubblicare i contenuti direttamente dal perimetro (evitando di dover raggiungere il server di origine), le prestazioni sono un vantaggio. E anche nei casi in cui devi riportare il percorso fino al server di origine, le CDN sono generalmente ottimizzate per farlo molto più rapidamente, quindi è una vittoria in entrambi i casi.
Cumulative Layout Shift (CLS)
Il successivo insieme di consigli riguarda la Cumulative Layout Shift (CLS), una misura della stabilità visiva sulle pagine web. Sebbene CLS sia migliorato molto sul web dal 2020, circa un quarto dei siti web non soddisfa ancora la soglia consigliata, quindi per molti siti rimane una grande opportunità di migliorare l'esperienza utente.
Imposta dimensioni esplicite in tutti i contenuti caricati dalla pagina
Le variazioni del layout si verificano in genere quando i contenuti esistenti si spostano al termine del caricamento degli altri. Pertanto, il modo principale per ovviare a questo problema è prenotare il più possibile lo spazio necessario in anticipo.
Il modo più semplice per risolvere le variazioni di layout causate da immagini senza dimensioni è impostare esplicitamente gli attributi width e height (o proprietà CSS equivalenti). Tuttavia, secondo HTTP Archive, il 72% delle pagine ha almeno un'immagine senza dimensioni. Senza una dimensione esplicita, i browser imposteranno inizialmente un'altezza predefinita di 0px e potrebbero causare una notevole variazione del layout quando l'immagine viene infine caricata e vengono rilevate le dimensioni. Ciò rappresenta sia un'enorme opportunità per il web collettivo, sia questa opportunità richiede molto meno sforzo rispetto ad altri consigli suggeriti in questo articolo.
Inoltre, è importante tenere presente che le immagini non sono gli unici a contribuire alla metrica CLS. Le variazioni del layout possono essere causate da altri contenuti che in genere vengono caricati dopo la visualizzazione iniziale della pagina, inclusi annunci di terze parti o video incorporati. La proprietà aspect-ratio può contribuire a contrastare questo problema. Si tratta di una funzionalità CSS relativamente nuova che consente agli sviluppatori di fornire esplicitamente proporzioni per le immagini e per gli elementi non illustrati. In questo modo puoi impostare un valore width dinamico (ad esempio in base alle dimensioni dello schermo) e il browser calcola automaticamente l'altezza appropriata, proprio come fa per le immagini con dimensioni.
A volte non è possibile conoscere la dimensione esatta dei contenuti dinamici poiché per loro stessa natura sono dinamici. Tuttavia, anche se non conosci le dimensioni esatte, puoi comunque adottare misure per ridurre la gravità delle variazioni del layout. Impostare un min-height ragionevole è quasi sempre meglio che consentire al browser di utilizzare l'altezza predefinita di 0px per un elemento vuoto. L'utilizzo di un min-height di solito è una soluzione semplice perché consente comunque al contenitore di raggiungere l'altezza finale dei contenuti, se necessario, ha semplicemente ridotto questa quantità di crescita dall'intero importo a un livello, possibilmente più tollerabile,
Assicurati che le pagine siano idonee per bfcache
I browser utilizzano un meccanismo di navigazione chiamato cache back/forward (o bfcache) per caricare istantaneamente una pagina della cronologia del browser precedente o successiva direttamente da un'istantanea della memoria.
bfcache rappresenta una significativa ottimizzazione delle prestazioni a livello di browser e elimina completamente le variazioni del layout durante il caricamento della pagina, che per molti siti rappresenta la maggior parte della metrica CLS. L'introduzione di bfcache ha causato il più grande miglioramento nella metrica CLS che abbiamo osservato nel 2022.
Nonostante ciò, un numero significativo di siti web non è idoneo per bfcache e, di conseguenza, perde questa opportunità di rendimento sul web senza costi per un numero significativo di navigazioni. A meno che la pagina non carichi informazioni sensibili che non vuoi che vengano ripristinate in memoria, ti consigliamo di verificare che le pagine siano idonee.
I proprietari dei siti dovrebbero verificare che le proprie pagine siano idonee per la memorizzazione nella cache e lavorare per qualsiasi motivo per cui non lo sono. Chrome dispone già di un tester bfcache in DevTools e quest'anno prevediamo di migliorare gli strumenti qui con un nuovo controllo Lighthouse che esegue un test simile e un'API per misurare questo aspetto sul campo.
Anche se abbiamo incluso bfcache nella sezione CLS, dato che abbiamo registrato i maggiori guadagni finora, bfcache in generale migliorerà anche altri Core Web Vitals. È una delle navi di navigazione istantanee disponibili per migliorare drasticamente la navigazione nelle pagine.
Evita animazioni/transizioni che usano proprietà CSS che influenzano il layout
Un'altra causa comune di variazioni del layout è l'animazione degli elementi. Ad esempio, i banner dei cookie o altri banner di notifica che scorrono verso l'alto o verso il basso contribuiscono alla metrica CLS. Questo è particolarmente problematico quando questi banner rimuovono altri contenuti, ma anche quando non lo fanno, l'animazione può comunque influire sulla CLS.
Sebbene i dati di Archivio HTTP non siano in grado di collegare in modo definitivo le animazioni alle variazioni del layout, i dati mostrano che le pagine che animano qualsiasi proprietà CSS che potrebbe influire sul layout hanno una probabilità del 15% inferiore di avere una CLS "buona" rispetto alle pagine nel complesso. Alcune proprietà sono associate a una CLS peggiore di altre. Ad esempio, le pagine che animano le larghezze margin o border hanno una CLS "scarsa" a quasi il doppio della frequenza rispetto alla quale le pagine nel complesso vengono considerate scadenti.
Questo forse non sorprende, perché ogni volta che esegui la transizione o l'animazione di qualsiasi proprietà CSS che genera il layout, si verificheranno variazioni del layout che, se non avvengono entro 500 millisecondi da un'interazione dell'utente, influiranno sulla CLS.
Ciò che potrebbe sorprendere alcuni sviluppatori è che ciò vale anche nei casi in cui l'elemento viene portato al di fuori del normale flusso dei documenti. Ad esempio, gli elementi assolutamente posizionati che animano top o left causeranno variazioni del layout, anche se non trasferiscono altri contenuti. Tuttavia, se invece di animare top o left animerai transform:translateX() o transform:translateY(), il browser non aggiornerà il layout della pagina e quindi non produrrà alcuna variazione del layout.
Preferire l'animazione di proprietà CSS che possono essere aggiornate nel thread del compositore del browser è da tempo una best practice per le prestazioni, perché sposta il lavoro sulla GPU e fuori dal thread principale. Oltre a essere una best practice generale sulle prestazioni, può anche contribuire a migliorare la metrica CLS.
Come regola generale, non animare o trasferire mai proprietà CSS che richiedono l'aggiornamento del layout della pagina da parte del browser, a meno che l'operazione non venga eseguita in risposta al tocco o alla pressione di un tasto da parte dell'utente (anche se non hover). Inoltre, laddove possibile, preferisci le transizioni e le animazioni utilizzando la proprietà CSS transform.
Il controllo di Lighthouse Evita animazioni non composte avvisa quando una pagina anima proprietà CSS potenzialmente lente.
First Input Delay (FID)
L'ultima serie di consigli riguarda il First Input Delay (FID), che misura l'adattabilità di una pagina alle interazioni degli utenti. Al momento la maggior parte dei siti sul web ha un ottimo punteggio in relazione al FID, ma in passato abbiamo documentato le carenze della metrica FID e riteniamo che ci siano ancora molte opportunità per i siti per migliorare la propria reattività generale alle interazioni degli utenti.
La nostra nuova metrica Interaction to Next Paint (INP) è un possibile successore della metrica FID e tutti i consigli riportati di seguito si applicano allo stesso modo sia a FID che a INP. Dato che i siti hanno prestazioni peggiori su INP rispetto a FID, in particolare sui dispositivi mobili, invitiamo gli sviluppatori a prendere seriamente in considerazione questi consigli sulla reattività, pur avendo un valore FID "buono".
Evitare o interrompere attività lunghe
Le attività sono un qualsiasi lavoro discreto svolto dal browser. Le attività includono rendering, layout, analisi, nonché la compilazione e l'esecuzione di script. Quando le attività diventano attività lunghe, ovvero di 50 millisecondi o più, impediscono al thread principale di rispondere rapidamente agli input degli utenti.
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 suddividere attività lunghe può non essere un'operazione semplice come gli altri consigli contenuti in questo articolo, richiede meno sforzo rispetto ad altre tecniche non offerte in questo articolo.
Anche se dovresti sempre cercare di svolgere il minor lavoro possibile in JavaScript, puoi contribuire un po' al thread principale suddividendo le attività lunghe in attività più piccole. A questo scopo, puoi rimanere spesso al thread principale, in modo che gli aggiornamenti del rendering e altre interazioni degli utenti possano avvenire più rapidamente.
Un'altra opzione è considerare l'utilizzo di API come isInputPending e l'API Scheduler. isInputPending è una funzione che restituisce un valore booleano che indica se un input dell'utente è in sospeso. Se restituisce true, puoi passare al thread principale in modo che possa gestire l'input utente in sospeso.
L'API Scheduler è un approccio più avanzato che consente di pianificare il lavoro in base a un sistema di priorità che tengono conto del fatto che il lavoro da svolgere sia visibile all'utente o in background.
Suddividendo attività lunghe, offri al browser più opportunità di adattarsi a lavori critici visibili all'utente, come gestire le interazioni e gli eventuali aggiornamenti del rendering risultanti.
Evita JavaScript non necessario
Non c'è dubbio: i siti web spediscono più codice JavaScript che mai e la tendenza non sembra cambiare a breve. Quando invii troppo codice JavaScript, crei un ambiente in cui le attività concorrono per l'attenzione del thread principale. Ciò può sicuramente influire sulla reattività del tuo sito web, soprattutto durante il periodo di avvio cruciale.
Tuttavia, questo non è un problema irrisolvibile. Hai a disposizione alcune opzioni:
- Utilizza lo strumento di copertura in Chrome DevTools per trovare il codice inutilizzato nelle risorse del tuo sito web. Riducendo le risorse necessarie durante l'avvio, puoi assicurarti che il tuo sito web dedichi meno tempo all'analisi e alla compilazione del codice, il che garantisce un'esperienza utente iniziale più fluida.
- A volte il codice inutilizzato che trovi usando lo strumento di copertura viene contrassegnato come "non utilizzato" perché non è stato eseguito durante l'avvio, ma è comunque necessario per alcune funzionalità in futuro. Si tratta di codice che puoi spostare in un bundle separato tramite la suddivisione del codice.
- Se utilizzi un gestore di tag, assicurati di controllare periodicamente i tag per assicurarti che siano ottimizzati o anche se sono ancora in uso. I tag meno recenti che contengono codice inutilizzato possono essere cancellati per rendere più piccolo ed efficiente il codice JavaScript di Tag Manager.
Evitare aggiornamenti di rendering di grandi dimensioni
JavaScript non è l'unica cosa che può influire sulla reattività del tuo sito web. Il rendering può essere un tipo di lavoro costoso a sé stante e, quando vengono eseguiti aggiornamenti di grandi dimensioni, possono interferire con la capacità del tuo sito web di rispondere agli input degli utenti.
L'ottimizzazione del lavoro di rendering non è un processo semplice e spesso dipende dai tuoi obiettivi. In ogni caso, ci sono alcune cose che puoi fare per assicurarti che gli aggiornamenti del rendering siano ragionevoli e non si dipanano in attività lunghe:
- Evita di utilizzare
requestAnimationFrame()per svolgere lavori non visivi. Le chiamaterequestAnimationFrame()vengono gestite durante la fase di rendering del loop di eventi e, se viene svolto troppo lavoro durante questo passaggio, gli aggiornamenti del rendering possono subire ritardi. È essenziale che qualsiasi attività svolta conrequestAnimationFrame()sia riservata esclusivamente ad attività che prevedono gli aggiornamenti del rendering. - Riduci le dimensioni del DOM. Le dimensioni del DOM e l'intensità del lavoro di layout sono correlate. Quando il renderer deve aggiornare il layout per un DOM di grandi dimensioni, il lavoro necessario per ricalcolare il layout può aumentare in modo significativo.
- Utilizza il contenimento CSS. Il contenimento CSS si basa sulla proprietà CSS
contain, che fornisce al browser istruzioni su come svolgere le attività di layout per il contenitore su cui è impostata la proprietàcontain, incluso l'isolamento dell'ambito del layout e del rendering in una directory principale specifica nel DOM. Non sempre è una procedura facile, ma isolando le aree contenenti layout complessi puoi evitare di svolgere operazioni di layout e rendering non necessarie.
Conclusione
Migliorare le prestazioni delle pagine può sembrare un'attività scoraggiante, soprattutto data la mole di indicazioni da prendere in considerazione sul web. Concentrandoti su questi consigli, tuttavia, puoi affrontare il problema con attenzione e scopo, e possibilmente spostare l'ago della bilancia per i Core Web Vitals del tuo sito web.
Anche se i consigli qui elencati non sono affatto esaustivi, riteniamo, in base a un'attenta analisi dello stato del web, che questi consigli siano i modi più efficaci con cui i siti possono migliorare le prestazioni di Core Web Vitals nel 2023.
Se desideri ulteriori informazioni sui consigli elencati qui, consulta queste guide all'ottimizzazione per saperne di più:
Un nuovo anno e un web più veloce per tutti! Fai in modo che i tuoi siti siano veloci per gli utenti in tutti i modi più importanti.
Foto di Devin Avery