Riduci i payload JavaScript con la suddivisione del codice

A nessuno piace aspettare. Oltre il 50% degli utenti abbandona un sito web se il caricamento richiede più di 3 secondi.

L'invio di payload JavaScript di grandi dimensioni influisce notevolmente sulla velocità del tuo sito. Anziché inviare tutto il codice JavaScript all'utente non appena viene caricata la prima pagina dell'applicazione, suddividi il bundle in più parti e invia solo ciò che è necessario all'inizio.

Perché la suddivisione del codice è utile?

La suddivisione del codice è una tecnica che mira a ridurre al minimo i tempi di avvio. Se inviamo meno JavaScript all'avvio, possiamo rendere le applicazioni interattive più velocemente riducendo al minimo il lavoro del thread principale durante questo periodo critico.

Per quanto riguarda Core Web Vitals, la riduzione dei payload JavaScript scaricati all'avvio contribuirà a migliorare i tempi di Interaction to Next Paint (INP). Il ragionamento alla base è che, liberando il thread principale, l'applicazione è in grado di rispondere più rapidamente agli input degli utenti riducendo i costi di avvio relativi all'analisi, alla compilazione e all'esecuzione di JavaScript.

A seconda dell'architettura del tuo sito web, in particolare se si basa molto sul rendering lato client, la riduzione delle dimensioni dei payload JavaScript responsabili del rendering del markup può portare a tempi di Largest Contentful Paint (LCP) migliori. Ciò può verificarsi quando la risorsa LCP viene rilevata in ritardo dal browser fino al completamento del markup lato client o quando il thread principale è troppo occupato per eseguire il rendering dell'elemento LCP. Entrambi gli scenari possono ritardare il tempo LCP della pagina.

Misura

Lighthouse mostra un controllo non riuscito quando è necessaria una quantità significativa di tempo per eseguire tutto il codice JavaScript su una pagina.

Un controllo Lighthouse non riuscito che mostra che l'esecuzione degli script richiede troppo tempo.

Dividi il bundle JavaScript per inviare solo il codice necessario per la route iniziale quando l'utente carica un'applicazione. In questo modo viene ridotta al minimo la quantità di script da analizzare e compilare, il che si traduce in tempi di caricamento delle pagine più rapidi.

I bundler di moduli più diffusi come webpack, Parcel e Rollup ti consentono di suddividere i bundle utilizzando le importazioni dinamiche. Ad esempio, considera il seguente snippet di codice che mostra un esempio di metodo someFunction attivato quando viene inviato un modulo.

import moduleA from "library";

form
.addEventListener("submit", e => {
  e
.preventDefault();
  someFunction
();
});

const someFunction = () => {
 
// uses moduleA
}

In questo caso, someFunction utilizza un modulo importato da una determinata libreria. Se questo modulo non viene utilizzato altrove, il blocco di codice può essere modificato per utilizzare un'importazione dinamica per recuperarlo solo quando il modulo viene inviato dall'utente.

form.addEventListener("submit", e => {
  e
.preventDefault();
 
import('library.moduleA')
   
.then(module => module.default) // using the default export
   
.then(() => someFunction())
   
.catch(handleError());
});

const someFunction = () => {
   
// uses moduleA
}

Il codice che compone il modulo non viene incluso nel bundle iniziale e ora viene caricato in modo lazy o fornito all'utente solo quando è necessario dopo l'invio del modulo. Per migliorare ulteriormente il rendimento della pagina, precarica i chunk critici per dare la priorità e recuperarli prima.

Sebbene lo snippet di codice precedente sia un esempio semplice, il caricamento lento delle dipendenze di terze parti non è uno schema comune nelle applicazioni più grandi. In genere, le dipendenze di terze parti sono suddivise in un bundle del fornitore separato che può essere memorizzato nella cache poiché non si aggiornano così di frequente. Puoi scoprire di più su come il plug-in SplitChunksPlugin può aiutarti a farlo.

La suddivisione a livello di route o componente quando si utilizza un framework lato client è un approccio più semplice al caricamento differito di diverse parti dell'applicazione. Molti strumenti di framework popolari che utilizzano webpack forniscono astratti per semplificare il caricamento lazily rispetto a dover gestire le configurazioni autonomamente.