Precarica i moduli

Sérgio Gomes
X

Lo sviluppo basato su moduli offre alcuni vantaggi concreti in termini di memorizzabilità nella cache, aiutandoti a ridurre il numero di byte da inviare agli utenti. La granularità del codice è utile anche per il caricamento della storia, dare la priorità al codice critico della tua applicazione.

Tuttavia, le dipendenze dei moduli introducono un problema di caricamento, in quanto il browser deve attendere il caricamento di un modulo prima di scoprire quali sono le sue dipendenze. Sola andata per risolvere il problema consiste nel precaricare le dipendenze, in modo che il browser possa i file in anticipo e mantenere la connessione occupata.

<link rel="preload"> è un modo per richiedere in modo dichiarativo le risorse in anticipo, prima che il browser ne abbia bisogno.

<head>
  <link rel="preload" as="style" href="critical-styles.css">
  <link rel="preload" as="font" crossorigin type="font/woff2" href="myfont.woff2">
</head>

Supporto dei browser

  • Chrome: 50.
  • Bordo: ≤79.
  • Firefox: 85.
  • Safari: 11.1.

Origine

Questo approccio funziona particolarmente bene con risorse come i caratteri, che sono spesso nascosti all'interno dei file CSS, a volte di diversi livelli. In questa situazione, il browser debba aspettare vari viaggi di andata e ritorno prima di scoprire che è necessario recuperare un file di caratteri di grandi dimensioni, quando avrebbe potuto usarlo per avviare il download e sfruttare la larghezza di banda completa della connessione.

<link rel="preload"> e la sua intestazione HTTP equivalente forniscono un modello semplice e modo di comunicare immediatamente al browser i file critici che saranno necessari nell'ambito della navigazione corrente. Quando il browser vede il precaricamento, avvia un il download prioritario della risorsa, in modo che quando è effettivamente necessaria già recuperati o parzialmente recuperati. ma non per i moduli.

È qui che le cose si complicano. Esistono diverse modalità di credenziale per e, per ottenere un successo della cache, devono corrispondere, altrimenti recuperando la risorsa due volte. Inutile dire che il doppio recupero è un errore, spreca la larghezza di banda dell'utente e lo fa attendere più a lungo, senza un valido motivo.

Per i tag <script> e <link>, puoi impostare la modalità delle credenziali con il token crossorigin . Tuttavia, si scopre che <script type="module"> senza L'attributo crossorigin indica una modalità delle credenziali di omit, che non esiste per <link rel="preload">. Ciò significa che dovrai cambia l'attributo crossorigin in <script> e <link> in uno degli altri valori e potreste non trovare un modo facile per farlo se quello che state il tentativo di precaricare è una dipendenza di altri moduli.

Inoltre, il recupero del file è solo il primo passaggio per eseguire effettivamente il codice. In primo luogo, il browser deve analizzarlo e compilarlo. L'ideale è questo dovrebbe avvenire anche in anticipo, in modo che quando il modulo è necessario, il codice pronto per l'esecuzione. Tuttavia, V8 (il motore JavaScript di Chrome) analizza e compila i moduli in modo diverso rispetto ad altri JavaScript. <link rel="preload"> non fornire un modo per indicare che il file che si sta caricando è un modulo, in modo che tutto il browser che puoi fare è caricare il file e inserirlo nella cache. Una volta che lo script è stato caricato utilizzando una <script type="module"> (o caricato da un altro modulo), il browser analizza e compila il codice come modulo JavaScript.

In poche parole, sì. Avendo un tipo specifico di link per il precaricamento dei moduli, possiamo scrivere codice HTML semplice senza preoccuparsi della modalità credenziali in uso. La le impostazioni predefinite funzionano.

<head>
  <link rel="modulepreload" href="super-critical-stuff.mjs">
</head>
[...]
<script type="module" src="super-critical-stuff.mjs">

Poiché ora il browser sa che il precaricamento è un modulo, può essere intelligente e analizzare e compilare il modulo al termine del recupero, anziché attendere fino a quando non viene eseguito.

Supporto dei browser

  • Chrome: 66.
  • Bordo: ≤79.
  • Firefox: 115.
  • Safari: 17.

Origine

E per quanto riguarda i moduli delle dipendenze?

Divertente che dovresti chiedere! C'è qualcosa che non si è trattato in questo articolo: la ricorsione.

La specifica <link rel="modulepreload"> in realtà consente di caricare facoltativamente non solo del modulo richiesto, ma anche di tutto il relativo albero delle dipendenze. I browser non devono necessariamente ma possono farlo.

Quale sarebbe la migliore soluzione cross-browser per precaricare un modulo e i suoi albero delle dipendenze perché è necessario l'albero completo per eseguire l'app?

I browser che scelgono di precaricare le dipendenze in modo ricorsivo devono avere una solida deduplicazione di moduli, quindi in generale la best practice prevede la dichiarazione del modulo e l'elenco delle sue dipendenze e assicurarsi che il browser non recuperi lo stesso modulo due volte.

<head>
  <!-- dog.js imports dog-head.js, which in turn imports
       dog-head-mouth.js, which imports dog-head-mouth-tongue.js. -->
  <link rel="modulepreload" href="dog-head-mouth-tongue.mjs">
  <link rel="modulepreload" href="dog-head-mouth.mjs">
  <link rel="modulepreload" href="dog-head.mjs">
  <link rel="modulepreload" href="dog.mjs">
</head>

Il precaricamento dei moduli migliora le prestazioni?

Il precaricamento può aiutare a massimizzare l'utilizzo della larghezza di banda, comunicando al browser cosa deve recuperare in modo che non rimanga bloccato con nulla da fare durante i lunghi viaggi di andata e ritorno. Se stai sperimentando con i moduli e riscontri problemi di prestazioni dovuti a alberi delle dipendenze, creare un elenco semplice di precaricamenti può essere sicuramente utile.

Detto questo, le prestazioni del modulo sono ancora in fase di sviluppo, quindi assicurati puoi esaminare attentamente ciò che accade nella tua applicazione con gli Strumenti per sviluppatori e Nel frattempo, valuta la possibilità di raggruppare la tua applicazione in più blocchi. Ci sono molte Il lavoro dei moduli in corso, però, è in corso in Chrome, quindi ci stiamo avvicinando i bundlerranno il meritato riposo!