Questa pagina è stata tradotta dall'API Cloud Translation.

I modi più efficaci per migliorare i Core Web Vitals

Nel corso degli anni, la community web ha accumulato una vasta conoscenza in materia di ottimizzazione delle prestazioni web. Sebbene un'ottimizzazione possa migliorare il rendimento di molti siti, applicarle tutte contemporaneamente può essere complicato e, in realtà, solo alcune sono applicabili a un determinato sito.

A meno che le prestazioni web non siano il tuo lavoro quotidiano, probabilmente non è chiaro quali ottimizzazioni avranno il maggiore impatto sul tuo sito. Probabilmente non avrai tempo per tutte, quindi è importante chiederti quali sono le ottimizzazioni più efficaci che puoi scegliere per migliorare il rendimento per i tuoi utenti?

Ecco la verità sulle ottimizzazioni del rendimento: non puoi giudicarle solo in base ai loro meriti tecnici. Devi anche prendere in considerazione i fattori umani e organizzativi che influiscono sulla probabilità di riuscire a implementare una determinata ottimizzazione. Alcuni miglioramenti delle prestazioni potrebbero avere un enorme impatto teorico, ma in realtà pochi sviluppatori avranno il tempo o le risorse per implementarli. D'altra parte, potrebbero esserci best practice per il rendimento di grande impatto che quasi tutti stanno già seguendo. Questa guida identifica le ottimizzazioni del rendimento web che:

Hanno il maggiore impatto nel mondo reale
Sono pertinenti e applicabili alla maggior parte dei siti
Sono realistiche per la maggior parte degli sviluppatori

Nel loro insieme, questi sono i modi più realistici e efficaci per migliorare le metriche di Core Web Vitals. Se non hai familiarità con il rendimento del web o se stai ancora decidendo cosa ti darà il maggiore ritorno sull'investimento, questo è il punto di partenza migliore.

Interaction to Next Paint (INP)

In qualità di metrica Core Web Vital più recente, Interaction to Next Paint (INP) offre alcune delle maggiori opportunità di miglioramento. Tuttavia, poiché molti meno siti superano la soglia per esperienze "buone" rispetto al predecessore deprecato, potresti essere tra i tanti sviluppatori che stanno imparando a ottimizzare la reattività dell'interazione per la prima volta. Inizia con queste tecniche indispensabili per scoprire i modi più efficaci per migliorare l'INP.

1. Interrompi spesso per suddividere le attività lunghe

Le attività sono qualsiasi lavoro distinto svolto dal browser, tra cui rendering, layout, analisi, compilazione o esecuzione di script. Quando un'attività supera i 50 millisecondi di durata, diventa un'attività lunga. Le attività lunghe sono problematiche perché possono impedire al thread principale di rispondere rapidamente alle interazioni degli utenti.

Anche se dovresti sempre cercare di fare il minor lavoro possibile in JavaScript, puoi aiutare il thread principale suddividendo le attività lunghe. Puoi farlo rinunciando spesso al thread principale in modo che gli aggiornamenti del rendering e altre interazioni con l'utente possano avvenire prima.

Supporto dei browser

Origine

L'API Scheduler ti consente di mettere in coda i lavori utilizzando un sistema di priorità. Nello specifico, l'API scheduler.yield() suddivide le attività lunghe garantendo al contempo che le interazioni possano essere gestite senza rinunciare al loro posto nella coda delle attività.

Suddividendo le attività lunghe, offri al browser più opportunità di adattarsi a un lavoro critico che blocca l'utente.

2. Evita JavaScript non necessario

I siti web stanno pubblicando più JavaScript che mai e la tendenza non sembra cambiare. Se carichi troppo JavaScript, crei un ambiente in cui le attività competono per l'attenzione del thread principale. Ciò può influire sulla reattività del tuo sito web, soprattutto durante il periodo di avvio cruciale.

Tuttavia, questo non è un problema irrisolvibile ed è possibile:

Utilizza le funzionalità della piattaforma web Baseline ampiamente disponibili anziché implementazioni basate su JavaScript ridondanti.
Utilizza lo strumento di copertura in Chrome DevTools per trovare il codice non utilizzato negli script. Riducendo le dimensioni delle risorse necessarie all'avvio, puoi assicurarti che le pagine dedichino meno tempo all'analisi e alla compilazione del codice, il che fornisce un'esperienza utente iniziale più fluida.
Usa la suddivisione del codice per creare un bundle separato per il codice non necessario per il rendering iniziale, ma verrà comunque utilizzato in seguito.
Se utilizzi uno strumento di gestione dei tag, ottimizza periodicamente i tag. I tag meno recenti con codice inutilizzato possono essere rimossi per ridurre l'utilizzo di JavaScript in Tag Manager.

3. Evitare aggiornamenti di rendering di grandi dimensioni

L'esecuzione di JavaScript è solo un aspetto che influisce sulla reattività del tuo sito web. Il rendering è un tipo di lavoro costoso in sé e durante gli aggiornamenti di rendering di grandi dimensioni, il tuo sito web potrebbe rispondere ancora più lentamente alle interazioni degli utenti.

L'ottimizzazione del lavoro di rendering non è un processo semplice e dipende dai tuoi obiettivi. In ogni caso, ecco alcune cose che puoi fare per assicurarti che le attività di rendering non diventino lunghe:

Riorganizza le letture e le scritture del DOM nel codice JavaScript per evitare il layout forzato e il thrashing del layout.
Mantieni le dimensioni del DOM ridotte. Le dimensioni del DOM e l'intensità del lavoro di layout sono correlate. Quando il visualizzatore deve aggiornare il layout di un DOM molto grande, il lavoro necessario per ricalcolare il layout può aumentare notevolmente.
Utilizza il contenimento CSS per eseguire il rendering lento dei contenuti DOM fuori schermo. Non è sempre facile, ma se isoli le aree contenenti layout complessi, puoi evitare operazioni di layout e rendering non necessarie.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) è la metrica Core Web Vitals con cui gli sviluppatori hanno più difficoltà: il 40% dei siti nel report sull'esperienza utente di Chrome non raggiunge la soglia LCP consigliata per garantire buone esperienze utente. Il team di Chrome consiglia le seguenti tecniche come i modi più efficaci per migliorare il LCP.

1. Assicurati che la risorsa LCP sia rilevabile dal codice sorgente HTML e abbia la priorità

Il team di Chrome ha notato quanto segue in merito all'LCP sul web:

Secondo l'Almanaco web 2022 di HTTP Archive, il 72% delle pagine mobile ha un'immagine come elemento LCP.
Un'analisi dei dati di utenti reali da Chrome mostra che la maggior parte delle origini con un valore LCP basso passa meno del 10% del tempo LCP p75 a scaricare l'immagine LCP.
Tra le pagine con un valore LCP basso, il caricamento delle relative immagini LCP è in ritardo sul client di 1290 millisecondi al 75° percentile, ovvero più della metà del budget per un'esperienza rapida.
Nelle pagine in cui l'elemento LCP era un'immagine, il 39% di queste immagini aveva URL di origine non rilevabili nella risposta HTML iniziale (ad esempio <img src="..."> o <link rel="preload" href="...">), il che avrebbe consentito allo scanner di precaricamento del browser di rilevarle il prima possibile.
Secondo l'Almanacco del web, solo lo 0,03% delle pagine idonee utilizzava l'attributo HTML fetchpriority per dare priorità alle risorse, incluse quelle che potrebbero migliorare il LCP di una pagina con un impegno relativamente ridotto.

Queste statistiche sono indicative del fatto che gli sviluppatori hanno un'ottima opportunità per ridurre sia il ritardo di caricamento delle risorse sia la durata del caricamento delle risorse per le immagini LCP.

Supporto dei browser

Origine

Se il problema è il ritardo nel caricamento delle risorse, è fondamentale ricordare che potrebbe essere già troppo tardi per ottenere un buon LCP se una pagina deve attendere il caricamento completo di CSS o JavaScript prima che le immagini possano iniziare a caricarsi. Inoltre, è possibile ridurre la durata del carico di risorse di un'immagine LCP assegnando una nuova priorità in modo che riceva una maggiore larghezza di banda e il caricamento sia più rapido usando l'attributo HTML fetchpriority.

Se l'elemento LCP è un'immagine, l'URL dell'immagine deve essere rilevabile nella risposta HTML per ridurre il ritardo di caricamento delle risorse. Ecco alcuni suggerimenti per farlo:

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 saranno sempre più lenti. Il 9% delle pagine oscura l'immagine LCP dietro a data-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 è necessario fare riferimento all'immagine da un file CSS o JS esterno, puoi comunque includerla nel codice sorgente HTML utilizzando un tag <link rel="preload">. Tieni presente che le immagini a cui si fa riferimento negli 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.

Inoltre, puoi accorciare la durata del caricamento di una risorsa assicurandoti che la risorsa LCP venga caricata in anticipo e con priorità elevata:

Aggiungi l'attributo fetchpriority="high" al tag <img> o <link rel="preload"> dell'immagine LCP. In questo modo, la risorsa immagine avrà la priorità e potrà iniziare a caricarsi prima.
Rimuovi l'attributo loading="lazy" dal tag <img> dell'immagine LCP. In questo modo si evita il ritardo di caricamento causato dalla conferma che l'immagine viene visualizzata all'interno o nelle vicinanze dell'area visibile.
Rimanda le risorse non critiche, se possibile. Lo spostamento di queste risorse alla fine del documento, il caricamento lento di immagini o gli iframe oppure il loro caricamento in modo asincrono tramite JavaScript contribuiranno a rendere più rapido il caricamento più rapido di risorse più importanti, come l'immagine LCP.

2. Punta alle navigazioni istantanee

L'esperienza utente ideale è non dover mai attendere il caricamento di una pagina. Le ottimizzazioni LCP, come la rilevabilità e la definizione delle priorità delle risorse, sono efficaci per ridurre il tempo di attesa di un utente per il caricamento e il rendering dell'elemento LCP, ma esiste un limite fisico alla velocità di caricamento di questi byte sulla rete e al loro rendering in una pagina. Prima di raggiungere questo limite, c'è uno sforzo proibitivo per risparmiare solo pochi millisecondi. Per ottenere navigazioni istantanee, dobbiamo quindi adottare un approccio radicalmente diverso.

Le navigazioni istantanee tentano di caricare e visualizzare la pagina prima che l'utente inizi a navigare al suo interno. In questo modo, la pagina sottoposta a prerendering può essere visualizzata immediatamente con un LCP vicino allo zero. Restauri e speculazioni sono due modi per ottenere questo risultato. Quando un utente torna indietro o va avanti a una pagina visitata in precedenza, questa può essere ripristinata rapidamente da una cache in memoria e visualizzata esattamente come l'utente l'ha lasciata. In alternativa, le applicazioni web possono provare a prevedere la pagina successiva che un utente visiterà e, se la previsione è corretta, la pagina successiva sarà già stata caricata e visualizzata quando l'utente vi accederà.

Il ripristino delle pagine visitate in precedenza è reso possibile dalla cache back-forward (bfcache). Per utilizzarla, devi assicurarti che le tue pagine soddisfino i criteri di idoneità di bfcache. I motivi comuni per cui le pagine non sono idonee per bfcache sono perché vengono gestite con istruzioni di memorizzazione nella cache di no-store o hanno listener di eventi unload.

Il ripristino delle pagine completamente visualizzate migliora non solo le prestazioni di caricamento, ma anche la stabilità del layout. Puoi scoprire di più sulla cache bfcache e sulla sua efficacia per migliorare il CLS nella sezione Verificare che le pagine siano idonee per la cache bfcache.

Supporto dei browser

Il prerendering della pagina successiva visitata da un utente è un altro modo efficace per migliorare notevolmente il rendimento LCP ed è reso possibile dall'API Speculation Rules. Per ottenere questi vantaggi, però, assicurati che le pagine corrette vengano pre-elaborate. Le speculazioni errate sprecano risorse sia sul server sia sul client, il che potrebbe influire sulle prestazioni. Quindi, meno sei sicuro di quale sarà la pagina successiva, più conservativo dovresti essere nel prerendering. In caso di dubbi, i dati di analisi possono darti la certezza di eseguire il prerendering in modo più rapido delle pagine con la probabilità più alta di essere visitate successivamente.

3. Utilizzare una CDN per ottimizzare il TTFB

Il suggerimento precedente si concentrava sulle navigazioni istantanee, che offrivano la migliore esperienza possibile agli utenti, ma potrebbero esserci situazioni in cui le tecniche bfcache e di caricamento speculativo non sono applicabili. Supponiamo che un utente segua un link cross-origin al tuo sito in cui la risposta del documento HTML iniziale blocca efficacemente l'LCP. Il browser non può iniziare a caricare nessuna risorsa secondaria finché non riceve il primo byte della risposta. Prima succede, prima tutto il resto può iniziare.

Questo tempo è noto come Time to First Byte (TTFB). I modi migliori per ridurre il TTFB sono:

Pubblica i tuoi contenuti nella posizione più vicina possibile ai tuoi utenti.
Memorizzare questi contenuti nella cache in modo che possano essere pubblicati rapidamente se vengono richiesti di nuovo nel prossimo futuro.

Il modo migliore per fare entrambe le cose è utilizzare una CDN. Le CDN distribuiscono le risorse agli edge server di tutto il mondo, limitando così la distanza che le risorse devono percorrere sulla rete per raggiungere gli utenti. Inoltre, le CDN di solito dispongono di controlli granulari della cache che possono essere ottimizzati in base alle esigenze del tuo sito.

Anche le reti CDN possono pubblicare e memorizzare nella cache i documenti HTML, ma secondo Web Almanac solo il 29% delle richieste di documenti HTML è stato gestito da una rete CDN. Ciò significa che i siti hanno un'opportunità significativa per realizzare ulteriori risparmi.

Ecco alcuni suggerimenti per la configurazione delle reti CDN:

Memorizza nella cache i documenti HTML statici anche per poco tempo. Ad esempio, è importante che i contenuti siano sempre aggiornati? Oppure possono essere inattivi di qualche minuto?
Scopri se puoi spostare la logica dinamica in esecuzione sul tuo server di origine a perimetrale, una funzionalità delle reti CDN più moderne.

Ogni volta che puoi pubblicare contenuti direttamente dall'edge e evitare di passare dal server di origine, il rendimento migliora. Anche nei casi in cui devi completare il percorso fino all'origine, le CDN sono generalmente ottimizzate per farlo più rapidamente, quindi è una soluzione vantaggiosa in entrambi i casi.

Cumulative Layout Shift (CLS)

CLS (Cumulative Layout Shift) è una misura della stabilità visiva di una pagina web. Anche se il CLS è la metrica in cui la maggior parte dei siti tende ad avere un buon rendimento, circa un quarto di questi non soddisfa ancora la soglia consigliata, quindi per molti siti rimane un'importante opportunità per migliorare l'esperienza utente.

1. Imposta dimensioni esplicite in tutti i contenuti caricati dalla pagina

I spostamenti del layout si verificano in genere quando i contenuti esistenti vengono spostati al termine del caricamento di altri contenuti. Il modo principale per migliorare la metrica CLS è riservare il più possibile lo spazio necessario in anticipo.

Il modo migliore per correggere i cambiamenti di layout causati da immagini senza dimensioni è impostare esplicitamente gli attributi width e height o le relative proprietà CSS equivalenti. Il 72% delle pagine ha almeno un'immagine senza dimensioni. Senza una dimensione esplicita, queste immagini hanno un'altezza iniziale di 0px, il che potrebbe causare cambiamenti di layout quando le immagini vengono caricate e il browser ne scopre le dimensioni. Questa rappresenta un'enorme opportunità per il web collettivo e richiede meno impegno rispetto ad alcuni degli altri consigli suggeriti in questa guida.

Supporto dei browser

Origine

Le immagini non sono gli unici elementi che contribuiscono a 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ò essere utile in questo caso. Si tratta di una funzionalità CSS di riferimento ampiamente disponibile che consente agli sviluppatori di impostare esplicitamente un'opzione per le proporzioni su immagini ed elementi diversi dalle immagini. In questo modo puoi impostare un valore width dinamico (ad esempio in base alle dimensioni dello schermo) e fare in modo che il browser calcoli automaticamente l'altezza appropriata, proprio come avviene per le immagini con dimensioni.

Tuttavia, non è sempre possibile conoscere le dimensioni esatte dei contenuti dinamici. Anche se non conosci le dimensioni esatte, puoi comunque ridurre la gravità dei cambiamenti di layout. Impostare un valore 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 è in genere anche una soluzione semplice, in quanto consente comunque al contenitore di espandersi fino all'altezza dei contenuti finali, se necessario, ma riduce la quantità di crescita a un livello auspicabilmente più tollerabile.

2. Assicurati che le pagine siano idonee per bfcache

Come indicato in precedenza in questa guida, la cache back-forward (bfcache) carica immediatamente una pagina precedente o successiva nella cronologia del browser da uno snapshot della memoria. Sebbene la bfcache sia un'ottimizzazione delle prestazioni significativa a livello di browser che migliora il tempo LCP, elimina completamente anche i cambiamenti di layout. Infatti, l'introduzione di bfcache nel 2022 è stata responsabile del più grande miglioramento della CLS che abbiamo osservato quell'anno.

Nonostante ciò, un numero significativo di siti web non è idoneo per la bfcache e quindi non può usufruire di questo vantaggio gratuito per le prestazioni web. A meno che la pagina non carichi informazioni sensibili che non vuoi che vengano ripristinate dalla memoria, assicurati che le pagine siano idonee all'utilizzo di bfcache.

I proprietari del sito devono verificare se le pagine sono idonee per la bfcache e correggere i motivi per cui non lo sono. Chrome ha un tester bfcache in DevTools e puoi anche utilizzare l'API Not Restored Reasons per rilevare i motivi di non idoneità sul campo.

3. Evita animazioni e transizioni che utilizzano proprietà CSS che influiscono sul layout

Un'altra causa comune di variazioni di layout è l'animazione degli elementi. Ad esempio, i banner dei cookie o altri banner di notifica che vengono visualizzati dall'alto o dal basso spesso contribuiscono alla metrica CLS. Questo è particolarmente problematico quando questi banner coprono altri contenuti, ma anche quando non lo fanno, l'animazione può comunque influire sul CLS.

Sebbene i dati di HTTP Archive non possano collegare in modo definitivo le animazioni ai cambiamenti di layout, mostrano che le pagine che animano qualsiasi proprietà CSS che potrebbe influire sul layout hanno il 15% di probabilità in meno di avere un CLS "buono" rispetto alle pagine in generale. Ad alcune proprietà è associato un CLS peggiore rispetto ad altre. Ad esempio, le pagine che animano le larghezze margin o border hanno un CLS "scarso" con una frequenza quasi doppia rispetto alle pagine complessivamente valutate come scarse.

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. Se queste variazioni di layout non si verificano entro 500 millisecondi da un'interazione dell'utente, influiscono sul CLS.

Ciò che potrebbe sorprendere alcuni sviluppatori è che questo vale anche nei casi in cui l'elemento viene estratto dal normale flusso del documento. Ad esempio, gli elementi con posizionamento assoluto che animano top o left causano cambiamenti nel layout, anche se non spostano altri contenuti. Tuttavia, se invece di animare top o left, animazione transform:translateX() o transform:translateY(), il browser non aggiornerà il layout della pagina, evitando così i cambiamenti di 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 dal thread principale alla GPU. 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 al browser di aggiornare il layout della pagina, 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). Se possibile, preferisci le transizioni e le animazioni utilizzando la proprietà CSS transform.

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

Conclusione

Migliorare il rendimento delle pagine può sembrare scoraggiante, soprattutto se si considera la quantità di indicazioni disponibili sul web. Tuttavia, concentrandoti su questo breve elenco di best practice più efficaci, puoi affrontare il problema con rinnovata attenzione e possibilmente spostare l'ago della bilancia per i Core Web Vitals del tuo sito web.

Se vuoi andare oltre le ottimizzazioni elencate di seguito, per saperne di più, consulta queste guide:

Appendice: Log delle modifiche

Le modifiche più importanti a questo documento verranno monitorate qui per aiutare a spiegare quando e perché i consigli principali sono stati modificati.

Ottobre 2024

Aggiornamento del 2024:

INP
- Abbiamo sostituito questa metrica da FID a INP in conformità con il lancio di INP come metrica Core Web Vital e l'abbiamo impostata come metrica principale nell'elenco.
- Abbiamo ritirato il nostro consiglio di utilizzare l'API isInputPending per suddividere le attività lunghe. Per scoprire di più sul nostro ragionamento, consulta l'articolo Ottimizzare le attività lunghe.
LCP
- Abbiamo combinato i consigli di rilevabilità e priorità in un unico posto.
- Abbiamo aggiunto un nuovo consiglio per puntare a navigazioni istantanee.

Gennaio 2023

Questo è l'elenco iniziale dei consigli:

LCP
- Assicurati che la risorsa LCP sia rilevabile dal codice sorgente HTML
- Assicurati che la risorsa LCP abbia la priorità
- Usa una CDN per ottimizzare il TTFB di documenti e risorse
CLS
- Impostare dimensioni esplicite su qualsiasi contenuto caricato dalla pagina
- Assicurati che le pagine siano idonee per la cache bfcache
- Evita animazioni e transizioni che utilizzano proprietà CSS che influiscono sul layout
FID
- Evitare o interrompere attività lunghe
- Evita JavaScript non necessario
- Evitare aggiornamenti di rendering di grandi dimensioni

Puoi anche guardare questa presentazione di Google I/O 2023 per un riepilogo video.