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 possono avere un impatto enorme in teoria, 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 delle prestazioni web che:
- Hanno l'impatto più grande 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 le esperienze "buone" rispetto al precedente ritirato, potresti essere tra i molti sviluppatori che stanno imparando per la prima volta a ottimizzare la reattività all'interazione. 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 la durata di un'attività supera i 50 millisecondi, 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.
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, in particolare durante il periodo di avvio cruciale.
Tuttavia, non si tratta di un problema irrisolvibile e hai a disposizione diverse opzioni:
- 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 durante l'avvio, puoi assicurarti che le pagine impieghino meno tempo per analizzare e compilare il codice, il che offre un'esperienza utente iniziale più fluida.
- Utilizza la suddivisione del codice per creare un bundle separato per il codice non necessario per il rendering iniziale, ma che verrà comunque utilizzato in un secondo momento.
- Se utilizzi uno strumento di gestione dei tag, ottimizza periodicamente i tag. I tag precedenti con codice inutilizzato possono essere rimossi per ridurre l'impronta JavaScript del tuo tag manager.
3. Evita aggiornamenti di rendering di grandi dimensioni
L'esecuzione di JavaScript è solo uno dei fattori che influiscono 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 da cosa stai cercando di ottenere. Tuttavia, ecco alcune cose che puoi fare per assicurarti che le attività di rendering non diventino lunghe:
- Riorganizza le letture e le scritture 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 dallo 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'Almanacco web 2024 di HTTP Archive, il 73% delle pagine mobile ha un'immagine come elemento LCP.
- Un'analisi dei dati degli utenti reali di Chrome mostra che la maggior parte delle origini con un LCP scadente spende meno del 10% del tempo LCP p75 per 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 35% 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, il 15% 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.
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, la durata del caricamento delle risorse di un'immagine LCP può essere ridotta riassegnandole la priorità in modo che riceva più larghezza di banda e si carichi più rapidamente utilizzando 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'attributosrc
osrcset
. Non utilizzare attributi non standard comedata-src
che richiedono JavaScript per il rendering, in quanto saranno sempre più lenti. Il 7% delle pagine oscura l'immagine LCP dietrodata-src
. - Preferisci il rendering lato server (SSR) al rendering lato client (CSR), poiché il rendering lato server presuppone che il markup completo della pagina (inclusa l'immagine) sia presente nel codice sorgente HTML. 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 fanno riferimento gli stili in linea non sono rilevabili dallo scanner di precaricamento del browser, pertanto, anche se si trovano nel codice sorgente HTML, il loro rilevamento potrebbe essere ancora bloccato durante il caricamento di altre risorse. In questi casi, il precaricamento può essere utile.
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. Spostare queste risorse alla fine del documento, caricare le immagini con il caricamento differito o gli iframe oppure caricarle in modo asincrono utilizzando JavaScript contribuirà a liberare il percorso per il caricamento più rapido di risorse più importanti come l'immagine LCP.
2. Punta a 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. Molto prima di raggiungere questo limite, è necessario un impegno proibitivo per risparmiare solo qualche altro millisecondo. Pertanto, per ottenere navigazioni istantanee, dobbiamo 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 pre-renderizzata può essere visualizzata immediatamente con un LCP quasi nullo. I restauri e le supposizioni sono due modi per farlo. 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 più comuni per cui le pagine non sono idonee per la bfcache sono perché vengono pubblicate con direttive di memorizzazione nella cache no-store
o con 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.
Browser Support
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. Pertanto, meno hai la certezza di quale sarà la pagina successiva, più devi essere prudente con il 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 consiglio precedente si concentrava sulle navigazioni istantanee, che offrono agli utenti la migliore esperienza possibile, ma potrebbero esserci situazioni in cui le tecniche di 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 le risorse secondarie finché non riceve il primo byte della risposta. Prima succede, prima si può iniziare a fare tutto il resto.
Questo tempo è noto come Time to First Byte (TTFB). I modi migliori per ridurre il TTFB sono:
- Pubblica i tuoi contenuti il più vicino possibile geograficamente ai tuoi utenti.
- Memorizzali 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 in genere dispongono di controlli granulari della cache che possono essere ottimizzati in base alle esigenze del tuo sito.
Le CDN possono anche pubblicare e memorizzare nella cache i documenti HTML, ma secondo l'Almanacco del web, solo il 33% delle richieste di documenti HTML è stato pubblicato da una CDN. Ciò significa che i siti hanno un'opportunità significativa per realizzare ulteriori risparmi.
Ecco alcuni suggerimenti per la configurazione delle CDN:
- Memorizza nella cache i documenti HTML statici anche per poco tempo. Ad esempio, è importante che i contenuti siano sempre aggiornati? Oppure può essere in ritardo di qualche minuto?
- Scopri se puoi spostare la logica dinamica in esecuzione sul server di origine nell'edge, una funzionalità della maggior parte delle CDN 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 effettuare 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. Sebbene il CLS sia 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, pertanto per molti siti rimane un'importante opportunità per migliorare l'esperienza utente.
1. Impostare dimensioni esplicite su qualsiasi contenuto caricato 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 il CLS è prenotare lo spazio necessario il più possibile 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 66% 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.
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 width
dinamico (ad esempio in base alle dimensioni dello schermo) e lasciare che sia il browser a calcolare automaticamente l'altezza appropriata, in modo molto simile a quanto 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 la cache 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 della bfcache nel 2022 ha determinato il miglioramento più significativo del CLS registrato quell'anno.
Nonostante ciò, un numero significativo di siti web non è idoneo per la bfcache e quindi non può usufruire di questo vantaggio senza costi per le prestazioni web. A meno che la pagina non carichi informazioni sensibili che non vuoi che vengano ripristinate dalla memoria, assicurati che le tue pagine siano idonee all'utilizzo della cache back-forward.
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 si inseriscono dall'alto o dal basso spesso contribuiscono al 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.
Forse non è sorprendente, perché ogni volta che esegui la transizione o l'animazione di qualsiasi proprietà CSS che determina il layout, si verificano spostamenti 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 delle 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 per il rendimento, può anche contribuire a migliorare il CLS.
Come regola generale, non animare o applicare transizioni alle proprietà CSS che richiedono l'aggiornamento del layout della pagina da parte del browser, a meno che non lo faccia in risposta a un tocco o a una pressione di un tasto dell'utente (non hover
). Se possibile, preferisci le transizioni e le animazioni che utilizzano 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 delle best practice più efficaci, puoi affrontare il problema con rinnovato impegno e, auspicabilmente, migliorare i Core Web Vitals del tuo sito web.
Se vuoi andare oltre le ottimizzazioni elencate qui, leggi queste guide per saperne di più:
Appendice: log delle modifiche
Le modifiche principali a questo documento verranno monitorate qui per spiegare quando e perché i consigli principali sono cambiati.
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 unito i consigli sulla visibilità e sulla definizione delle priorità in un unico documento.
- 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 alla risorsa LCP sia assegnata la priorità
- Utilizza 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
- Evita o suddividi le attività lunghe
- Evita JavaScript non necessario
- Evita aggiornamenti di rendering di grandi dimensioni
Puoi anche guardare questa presentazione di Google I/O 2023 per un riepilogo video.