I nostri principali consigli relativi ai Segnali web essenziali per il 2023

Una raccolta delle best practice che il team di Chrome DevRel ritiene essere i modi più efficaci per migliorare le prestazioni dei Segnali web essenziali nel 2023.

Nel corso degli anni, noi di Google abbiamo dato molti consigli agli sviluppatori web su come migliorare il rendimento.

Sebbene ognuno di questi consigli, singolarmente, può migliorare il rendimento di molti siti, l'insieme completo di consigli è certamente ingestibile e, realisticamente, non c'è modo che una persona o un sito possa seguirli tutti.

A meno che le prestazioni web non siano il tuo lavoro quotidiano, probabilmente non è ovvio quali consigli avranno il maggiore impatto positivo sul tuo sito. Ad esempio, potresti aver letto che l'implementazione di CSS essenziali può migliorare le prestazioni di caricamento e come hai saputo che è importante ottimizzare le immagini. Se invece non hai tempo per dedicarti a entrambe le cose, come potresti decidere quale scegliere?

L'anno scorso, il team di Chrome ha provato a 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, dobbiamo considerare non solo i meriti tecnici di una determinata raccomandazione, ma anche fattori umani e organizzativi che influenzano la probabilità che gli sviluppatori siano effettivamente in grado di adottare queste raccomandazioni. In altre parole, alcuni consigli potrebbero avere un enorme impatto in teoria, ma in realtà pochissimi siti hanno il tempo o le risorse per implementarli. Allo stesso modo, alcuni consigli sono fondamentali, ma la maggior parte dei siti web già segue queste pratiche.

In breve, volevamo che il nostro elenco dei principali consigli per il rendimento sul web fosse incentrato su:

• I consigli che riteniamo avranno il maggiore impatto nel mondo reale
• Consigli pertinenti e applicabili alla maggior parte dei siti
• Consigli realistici da implementare per la maggior parte degli sviluppatori

Nell'ultimo anno abbiamo dedicato molto tempo a verificare l'insieme completo di suggerimenti per il rendimento che offriamo e a valutare ciascuno di essi (sia qualitativamente che quantitativamente) in base ai tre criteri sopra indicati.

In questo post vengono illustrati i nostri principali consigli per migliorare le prestazioni di ciascuna delle metriche Segnali web essenziali. Se non hai esperienza con il rendimento sul web o se stai cercando di decidere cosa ti farà ottenere il massimo dal tuo budget, riteniamo che questi consigli siano il punto di partenza migliore.

Largest Contentful Paint (LCP)

Il nostro primo insieme di consigli riguarda la Largest Contentful Paint (LCP), ovvero una misurazione delle prestazioni di caricamento. Delle tre metriche di Segnali web essenziali, il valore LCP è quello con cui si verificano problemi nel maggior numero di siti: solo circa la metà di tutti i siti web oggi raggiunge la soglia consigliata. Iniziamo da lì.

Assicurati che la risorsa LCP sia rilevabile dall'origine HTML

Secondo il 2022 Web Almanac di HTTP Archive, il 72% delle pagine mobile ha un'immagine come elemento LCP, il che significa che per ottimizzare la metrica LCP, la maggior parte dei siti dovrà assicurarsi che le immagini vengano caricate rapidamente.

Ciò che potrebbe non essere ovvio per molti sviluppatori è che il tempo necessario per caricare un'immagine è solo una parte del problema. Un'altra parte fondamentale è il tempo prima che un'immagine inizi a caricarsi e i dati di HTTP Archive suggeriscono che è quello il punto in cui molti siti entrano in gioco.

Infatti, il 39% delle pagine in cui l'elemento LCP era un'immagine aveva URL di origine che non erano rilevabili dall'origine del documento HTML. In altre parole, questi URL non sono stati trovati negli attributi HTML standard (come <img src="..."> o <link rel="preload" href="...">), il che consentirebbe al browser di rilevarli rapidamente e iniziare a caricarli immediatamente.

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 sempre essere rilevabile dal codice HTML. Ecco alcuni suggerimenti per renderlo possibile:

• Carica l'immagine utilizzando un elemento <img> con l'attributo src o srcset. Non utilizzare attributi non standard come data-src che richiedono JavaScript per il rendering, in quanto questo processo sarà sempre più lento. Il 9% delle pagine oscura l'immagine LCP dietro data-src.

• Preferisci il rendering lato server (SSR) al rendering lato client (CSR), in quanto SSR implica che il markup completo della pagina (inclusa l'immagine) è presente nel codice sorgente HTML. Le soluzioni CSR richiedono l'esecuzione di JavaScript prima che l'immagine possa essere rilevata.

• Se occorre fare riferimento all'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 fanno riferimento gli stili incorporati non sono rilevabili dallo scanner di precaricamento del browser, pertanto, anche se sono trovate nel codice sorgente HTML, il loro rilevamento potrebbe comunque essere bloccato sul caricamento di altre risorse, quindi il precaricamento può essere utile in questi casi.

Per aiutarti a capire se l'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 HTML può portare a miglioramenti misurabili e offre anche ulteriori opportunità per assegnare una priorità alla risorsa, che è il nostro prossimo consiglio.

Assicurati che la risorsa LCP abbia la priorità

Assicurarsi che la risorsa LCP possa essere rilevata dal codice sorgente HTML è un primo passaggio fondamentale per garantire che la risorsa LCP inizi a caricarsi in anticipo, ma un altro passaggio importante consiste nell'assicurarsi che il caricamento della risorsa sia assegnato una priorità e non venga inserito in coda dietro una serie 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 decina di tag <script> nella sezione <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 un suggerimento al browser in merito 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 anziché attendere il completamento degli script.

Secondo l'Almanacco web, solo lo 0,03% delle pagine idonee sta sfruttando questa nuova API, il che significa che la maggior parte dei siti web ha molte opportunità di migliorare il valore LCP con poco lavoro. Sebbene l'attributo fetchpriority sia attualmente supportato solo nei browser basati su Chromium, questa API è un miglioramento progressivo che altri browser ignorano, quindi consigliamo vivamente agli sviluppatori di usarla ora.

Per i browser non Chromium, l'unico modo per assicurarsi che la risorsa LCP abbia la priorità rispetto alle altre risorse è farvi riferimento in precedenza nel documento. Utilizzando nuovamente l'esempio di un sito con molti tag <script> nella sezione <head> del documento, per accertarti che la tua risorsa LCP abbia la priorità prima di quelle risorse di script, potresti aggiungere un tag <link rel="preload"> prima di questi script oppure spostarli sotto <img> più avanti nel <body>. Anche se funziona, è meno ergonomico rispetto all'uso di fetchpriority, quindi ci auguriamo che altri browser lo supportino a breve.

Un altro aspetto fondamentale nell'assegnazione della priorità alla risorsa LCP consiste nell'assicurarsi di non fare nulla che ne causi la riduzione della priorità, ad esempio aggiungendo l'attributo loading="lazy". Oggi, il 10% delle pagine ha impostato loading="lazy" sull'immagine LCP. Fai attenzione alle soluzioni di ottimizzazione delle immagini che applicano indiscriminatamente 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 non sai quale immagine sia l'LCP, prova a utilizzare l'euristica per scegliere un candidato ragionevole.

Il differimento di risorse non critiche è un altro modo per aumentare in modo efficace la priorità relativa della risorsa LCP. Ad esempio, gli script che non sono alla base dell'interfaccia utente (come quelli di analisi o i widget social) possono essere posticipati in modo sicuro fino all'attivazione dell'evento load, così da non competere con altre risorse fondamentali (come la risorsa LCP) per la larghezza di banda della rete.

Per riepilogare, segui 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 temere perché puoi impostare anche fetchpriority="high" su quel tag.
• Non impostare mai loading="lazy" sul tag <img> dell'immagine LCP. In questo modo la priorità dell'immagine verrà ridotta e il caricamento dell'immagine verrà ritardato.
• Rimanda le risorse non critiche quando possibile. Puoi spostarli alla fine del documento utilizzando 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 erano mirati ad assicurare che la risorsa LCP venga scoperta in anticipo e abbia la priorità, in modo che possa iniziare a caricarsi immediatamente. L'ultimo elemento di questo puzzle è assicurarsi che anche la risposta iniziale del documento arrivi il più rapidamente possibile.

Il browser non può iniziare a caricare le sottorisorse finché non riceve il primo byte della risposta iniziale del documento HTML. Prima ciò avviene, prima può iniziare anche tutto il resto.

Questo valore è noto come Time to First Byte (TTFB) e il modo migliore per ridurre il TTFB è:

• Pubblica i tuoi contenuti il più vicino possibile agli utenti
• Memorizza nella cache i contenuti richiesti di recente in modo che i contenuti richiesti di recente possano essere nuovamente pubblicati in tempi brevi.

Il modo migliore per eseguire entrambe le operazioni è utilizzare una rete CDN. Le CDN distribuiscono le risorse a server perimetrali, che sono distribuiti in tutto il mondo, limitando così la distanza che queste risorse devono percorrere sulla rete per gli utenti. Le CDN di solito hanno controlli di memorizzazione nella cache granulari che possono essere personalizzati e ottimizzati in base alle esigenze del sito.

Molti sviluppatori hanno dimestichezza con l'utilizzo di una rete CDN per ospitare asset statici, ma possono pubblicare e memorizzare nella cache anche documenti HTML, anche quelli che vengono generati dinamicamente.

Secondo l'Almanacco web, solo il 29% delle richieste di documenti HTML è stato inviato da una rete CDN, il che significa che i siti hanno notevoli opportunità di ottenere ulteriori risparmi.

Ecco alcuni suggerimenti per la configurazione delle reti CDN:

• Valuta la possibilità di aumentare per quanto tempo i contenuti vengono memorizzati nella cache (ad esempio, è fondamentale che i contenuti siano sempre aggiornati? O potrebbe essere inattivo qualche minuto?).
• Prendi in considerazione anche la memorizzazione nella cache dei contenuti per sempre e quindi di svuotare la cache se/quando effettui un aggiornamento.
• Scopri se puoi spostare a perimetro la logica dinamica attualmente in esecuzione sul tuo server di origine (una funzionalità delle reti CDN più moderne).

In generale, ogni volta che è possibile pubblicare contenuti direttamente dal perimetro (evitando un viaggio al server di origine), il rendimento è vantaggioso. E anche nei casi in cui devi fare il viaggio fino al server di origine, le reti CDN sono generalmente ottimizzate per farlo molto più rapidamente, quindi è un vantaggio in ogni caso.

Cumulative Layout Shift (CLS)

Il prossimo insieme di consigli riguarda il Cumulative Layout Shift (CLS), ovvero una misurazione della stabilità visiva delle pagine web. Sebbene il CLS sia molto migliorato sul web dal 2020, circa un quarto dei siti web non raggiunge ancora la soglia consigliata, pertanto per molti siti rimane una grande opportunità di migliorare l'esperienza utente.

Impostare le dimensioni esplicite per i contenuti caricati dalla pagina

In genere le variazioni di layout si verificano quando i contenuti esistenti vengono spostati al termine del caricamento di altri contenuti. Pertanto, il modo principale per mitigare questo problema è prenotare lo spazio necessario in anticipo.

Il modo più semplice per correggere le variazioni del layout causate da immagini non dimensionate è impostare esplicitamente gli attributi width e height (o proprietà CSS equivalenti). Tuttavia, secondo HTTP Archive, il 72% delle pagine ha almeno un'immagine non ridimensionata. Senza una dimensione esplicita, i browser imposteranno inizialmente un'altezza predefinita pari a 0px e potrebbero causare una notevole variazione del layout quando l'immagine viene caricata finalmente e vengono rilevate le dimensioni. Ciò rappresenta un'enorme opportunità per il web collettivo e richiede uno sforzo molto minore rispetto ad altri consigli suggeriti in questo articolo.

È inoltre importante tenere presente che le immagini non sono le uniche fattori che apportano al CLS. Le variazioni del layout possono essere causate 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ò contribuire a contrastare questo fenomeno. Si tratta di una funzionalità CSS relativamente nuova che consente agli sviluppatori di fornire esplicitamente proporzioni e elementi non immagine. Ciò ti consentirà di impostare un width dinamico (ad esempio in base alle dimensioni dello schermo) e di far calcolare automaticamente l'altezza appropriata al browser, più o meno come per le immagini con dimensioni.

A volte non è possibile conoscere le dimensioni esatte dei contenuti dinamici, poiché sono, per loro stessa natura, dinamici. Tuttavia, anche se non conosci la dimensione esatta, puoi comunque adottare delle misure per ridurre la gravità delle variazioni del layout. Impostare un valore min-height ragionevole è quasi sempre meglio che consentire al browser di utilizzare l'altezza predefinita 0px per un elemento vuoto. Anche l'utilizzo di un min-height è di solito una soluzione semplice, in quanto consente comunque al container di crescere fino all'altezza finale del contenuto, se necessario. Ha solo ridotto la quantità di crescita dall'intero importo a un livello, speriamo più accettabile, più tollerabile.

Assicurati che le pagine siano idonee per la cache back-forward

I browser utilizzano un meccanismo di navigazione chiamato cache back-forward (o bfcache in breve) per caricare istantaneamente una pagina da una versione precedente o successiva della cronologia del browser direttamente da un'istantanea della memoria.

La bfcache è un'ottimizzazione significativa delle prestazioni a livello di browser ed elimina completamente le variazioni del layout durante il caricamento pagina, che per molti siti è quella in cui si verifica la maggior parte della metrica CLS. L'introduzione della bfcache ha causato il più grande miglioramento della metrica CLS che abbiamo riscontrato nel 2022.

Ciononostante, un numero significativo di siti web non è idoneo per la cache back-forward e quindi si perde questa vittoria senza costi in termini di prestazioni web per un numero significativo di navigazioni. A meno che la tua pagina non carichi informazioni sensibili che non vuoi ripristinare dalla memoria, assicurati che le pagine siano idonee.

I proprietari dei siti devono verificare che le loro pagine siano idonee per la cache back-forward e cercare le ragioni per cui non è così. Chrome ha già un tester bfcache in DevTools e quest'anno prevediamo di migliorare i nostri strumenti con un nuovo controllo di Lighthouse per eseguire un test simile e un'API per misurare il problema sul campo.

Anche se abbiamo incluso la cache bfcache nella sezione CLS, poiché abbiamo riscontrato i maggiori guadagni finora, in genere migliora anche altri Segnali web essenziali. È una delle numerose navigazioni istantanee disponibili per migliorare drasticamente la navigazione nelle pagine.

Evita animazioni/transizioni che usano proprietà CSS che provocano il layout

Un'altra fonte comune di variazioni del layout è quando gli elementi sono animati. Ad esempio, i banner dei cookie o altri banner di notifica che scorrono dall'alto o dal basso contribuiscono spesso alla metrica CLS. Questo aspetto è particolarmente problematico quando questi banner rimuovono altri contenuti. Tuttavia, anche quando non lo sono, la loro animazione può comunque influire sulla metrica CLS.

Sebbene i dati di HTTP Archive non possano collegare in modo definitivo le animazioni alle variazioni del layout, i dati mostrano che le pagine che animano qualsiasi proprietà CSS che potrebbero influire sul layout hanno il 15% di probabilità in meno di avere una metrica CLS "buona" rispetto alle pagine complessive. Alcune proprietà sono associate a una metrica CLS peggiore di altre. Ad esempio, le pagine che si animano con larghezze di margin o border presentano un valore CLS "scarso" quasi doppio rispetto a quello delle pagine complessivamente considerate scadenti.

Forse non c'è da sorprendersi, perché ogni volta che esegui la transizione o l'animazione di qualsiasi proprietà CSS che induce il layout, si verificherà una variazione del layout che, se non entro 500 millisecondi da un'interazione dell'utente, avrà effetto sulla metrica CLS.

Ciò che può sorprendere alcuni sviluppatori è che ciò si verifichi anche nei casi in cui l'elemento viene preso al di fuori del normale flusso di documenti. Ad esempio, gli elementi posizionati in modo assoluto che si animano di top o left causeranno variazioni del layout, anche se non vengono spinti altri contenuti. Tuttavia, se invece di animare top o left anima transform:translateX() o transform:translateY(), il browser non aggiornerà il layout della pagina e non produrrà alcuna variazione.

La preferenza per l'animazione di proprietà CSS che possono essere aggiornate nel thread di composizione 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 per le prestazioni, può anche contribuire a migliorare la metrica CLS.

Come regola generale, non animare o eseguire mai la transizione di qualsiasi proprietà CSS che richieda al browser di aggiornare il layout di pagina, a meno che tu non lo faccia in risposta a un tocco o alla pressione dei tasti dell'utente (anche se non hover). Inoltre, quando possibile, preferisci transizioni e animazioni utilizzando la proprietà transform CSS.

Il controllo Lighthouse Evita animazioni non composte ti avvisa quando una pagina anima proprietà CSS potenzialmente lente.

First Input Delay (FID)

Il nostro ultimo insieme di consigli riguarda il First Input Delay (FID), ovvero una misura della reattività di una pagina alle interazioni degli utenti. Sebbene la maggior parte dei siti web al momento abbia un buon punteggio con il FID, in passato abbiamo documentato le carenze della metrica FID e crediamo che ci siano ancora molte opportunità per i siti di migliorare la loro reattività generale alle interazioni degli utenti.

La nostra nuova metrica Interaction to Next Paint (INP) è un possibile successore di FID e tutte le raccomandazioni che seguono si applicano ugualmente bene sia a FID che a INP. Dato che il rendimento dei siti sul sito INP è peggior rispetto a quello sul FID, in particolare sui dispositivi mobili, invitiamo gli sviluppatori a prendere seriamente in considerazione questi consigli relativi alla reattività, nonostante abbiano un valore FID "buono".

Evitare o suddividere attività lunghe

Per attività si intende qualsiasi attività discreta svolta dal browser. Le attività includono rendering, layout, analisi, compilazione ed esecuzione di script. Quando le attività diventano attività lunghe, ovvero 50 millisecondi o più, impediscono al thread principale di rispondere rapidamente agli input utente.

Secondo l'almanacco web, esistono molte prove che suggeriscono che gli sviluppatori potrebbero fare di più per evitare o interrompere attività lunghe. Anche se suddividere le attività lunghe potrebbe non essere tanto faticoso quanto altre raccomandazioni in questo articolo, è meno faticoso rispetto ad altre tecniche non offerte in questo articolo.

Anche se dovresti sempre cercare di fare il minor lavoro possibile in JavaScript, puoi agevolare il thread principale suddividendo le attività lunghe in attività più piccole. Puoi farlo restituendo spesso il thread principale in modo che gli aggiornamenti di rendering e altre interazioni degli utenti avvengano più rapidamente.

Un'altra opzione consiste nel prendere in considerazione l'utilizzo di API come isInputPending e l'API Scheduler. isInputPending è una funzione che restituisce un valore booleano che indica se l'input di un utente è in sospeso. Se restituisce true, puoi cedere 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 tiene conto del fatto che il lavoro svolto sia visibile all'utente o in background.

Suddividendo le attività lunghe, offri al browser più opportunità di adattarsi al lavoro critico visibile all'utente, come la gestione delle interazioni e degli eventuali aggiornamenti del rendering risultanti.

Evita codice JavaScript non necessario

Non c'è dubbio: i siti web pubblicano più JavaScript che mai e la tendenza sembra che non cambierà in breve tempo. Quando distribuisci troppo codice JavaScript, crei un ambiente in cui le attività competono per l'attenzione del thread principale. Questo può sicuramente influire sulla reattività del tuo sito web, soprattutto durante il periodo di avvio cruciale.

Tuttavia, questo non è un problema irrisolvibile. Hai alcune opzioni a disposizione:

• Utilizza lo strumento di copertura in Chrome DevTools per trovare il codice inutilizzato nelle risorse del tuo sito web. Riducendo le dimensioni delle risorse necessarie durante l'avvio, puoi assicurarti che il tuo sito web impieghi meno tempo per analizzare e compilare il codice, il che si traduce in un'esperienza utente iniziale più fluida.
• A volte il codice inutilizzato che trovi con lo strumento di copertura è contrassegnato come "non utilizzato" perché non è stato eseguito durante l'avvio, ma è comunque necessario per alcune funzionalità in futuro. Questo è il codice che puoi spostare in un bundle separato tramite la suddivisione del codice.
• Se utilizzi uno strumento di gestione dei tag, assicurati di controllare periodicamente i tag per verificarne l'ottimizzazione o anche se vengono ancora utilizzati. I tag meno recenti con codice inutilizzato possono essere cancellati per rendere il codice JavaScript di Tag Manager più piccolo ed efficiente.

Evita aggiornamenti del rendering di grandi dimensioni

JavaScript non è l'unica cosa che può influire sulla reattività del tuo sito web. Il rendering può essere di per sé un tipo di lavoro costoso e, quando si verificano 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 dagli obiettivi che vuoi raggiungere. Anche in questo caso, ci sono alcune cose che puoi fare per assicurarti che gli aggiornamenti del rendering siano ragionevoli e non si estendano in attività lunghe:

• Evita di utilizzare requestAnimationFrame() per svolgere opere non visive. Le chiamate requestAnimationFrame() vengono gestite durante la fase di rendering del loop di eventi e, se durante questo passaggio viene fatto troppo lavoro, gli aggiornamenti del rendering possono subire ritardi. È essenziale che tutto il lavoro che svolgi con requestAnimationFrame() sia riservato esclusivamente ad attività che prevedono aggiornamenti del rendering.
• Riduci le dimensioni del DOM. Le dimensioni del DOM e l'intensità del lavoro sul 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 significativamente.
• Utilizza il contenimento CSS. 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à contain, incluso persino l'isolamento dell'ambito del layout e del rendering in una radice specifica nel DOM. La procedura non è sempre facile, ma isolando le aree contenenti layout complessi, puoi evitare di occuparti di layout e rendering non necessari.

Conclusione

Migliorare le prestazioni di una pagina può sembrare un'attività scoraggiante, soprattutto perché esiste una montagna di indicazioni da prendere in considerazione in tutto il web. Tuttavia, concentrandoti su questi consigli, puoi affrontare il problema con attenzione e scopo e, possibilmente, spostare l'ago della bilancia in relazione ai Segnali web essenziali del tuo sito web.

Sebbene le raccomandazioni qui elencate non siano esaustive, riteniamo, sulla base di un'attenta analisi dello stato del web, che siano il modo più efficace per consentire ai siti di migliorare le prestazioni dei Segnali web essenziali nel 2023.

Se desideri andare oltre i consigli qui elencati, consulta queste guide all'ottimizzazione per saperne di più:

• LCP di Optimize
• CLS di Optimize
• Ottimizza FID
• Ottimizza INP

Brindiamo a un nuovo anno e un web più veloce per tutti! Fai in modo che i tuoi siti siano veloci per gli utenti nei modi che ritieni più importanti.

Foto di Devin Avery