Precaricamento di navigazione per HTML Network-first

Quando un service worker gestisce gli eventi fetch, il browser attende che il service worker fornisca una risposta. Sebbene la latenza della richiesta di rete sia una parte importante dell'attesa, il browser potrebbe anche dover attendere l'avvio del service worker e attivare i callback dell'evento fetch.

Il tempo di avvio varia in base al dispositivo e alle sue capacità, ma può essere considerevole, a volte anche mezzo secondo se la CPU è lenta o se funziona in uno stato limitato a causa delle condizioni ambientali. Se le risposte di navigazione vengono fornite da un'istanza Cache, è probabile che il miglioramento delle prestazioni derivante dall'evitare la rete superi questo tempo di avvio. Per le richieste di navigazione che arrivano alla rete, l'introduzione di un service worker può creare un ritardo percepibile.

Inserisci precaricamento navigazione

Il precaricamento della navigazione è una funzionalità del service worker che risolve il ritardo causato dal tempo di avvio del service worker. Se il precaricamento di navigazione non è abilitato, sia l'avvio del service worker sia la richiesta di navigazione che gestisce avvengono in modo consecutivo:

Una barra gialla e blu, con due segmenti che mostrano azioni consecutive. Il primo segmento, in giallo, riporta la scritta "Avvio software" e un segmento blu con la dicitura "Richiesta di navigazione".

Questo non è l'ideale, ma puoi correggerlo abilitando il precaricamento di navigazione, che assicura che l'avvio del service worker e la richiesta di navigazione avvengano contemporaneamente:

Due barre, una sull'altra e allineate a sinistra, che rappresentano due azioni simultanee. La barra gialla ha l'etichetta "Avvio software", mentre quella blu ha l'etichetta "Richiesta di navigazione".

Sebbene il precaricamento della navigazione rappresenti un'ottima ottimizzazione delle prestazioni per i siti che utilizzano i service worker, non è una funzione da abilitare in tutte le situazioni. In particolare, i siti che utilizzano una shell dell'app pre-memorizzata nella cache non hanno bisogno del precaricamento della navigazione, in quanto la cache gestisce la richiesta di navigazione per il markup della shell dell'app senza latenza di navigazione. In questi casi, la risposta precaricata andrà sprecata, il che non è un granché.

Il momento migliore per utilizzare il precaricamento di navigazione è quando un sito web non può pre-memorizzare nella cache il codice HTML. Pensa ai siti web in cui le risposte al markup sono dinamiche e variano per elementi come lo stato di autenticazione. Le richieste di navigazione per questi tipi di contenuti possono utilizzare una strategia network-first (o anche solo rete) ed è in questo caso che il precaricamento della navigazione può fare una grande differenza.

Utilizzo del precaricamento di navigazione in Workbox

Utilizzare il precaricamento di navigazione direttamente in un service worker non basato su Workbox è complicato. Innanzitutto, non è supportato in tutti i browser. In secondo luogo, può essere difficile fare chiarezza. Puoi imparare a usarlo direttamente in questo fantastico video esplicativo di Jake Archibald.

Workbox semplifica l'utilizzo del precaricamento della navigazione, poiché il metodo enable del modulo workbox-navigation-preload esegue i controlli di supporto delle funzionalità necessari e crea il listener di eventi activate per abilitarlo per te.

Da qui, i vantaggi del precaricamento della navigazione si realizzano nel supporto dei browser, utilizzando Workbox per gestire le richieste di navigazione con un gestore della strategia network-first:

import * as navigationPreload from 'workbox-navigation-preload';
import {NetworkFirst, StaleWhileRevalidate} from 'workbox-strategies';
import {registerRoute, NavigationRoute, Route} from 'workbox-routing';
import {precacheAndRoute} from 'workbox-precaching';

// Precache the manifest
precacheAndRoute(self.__WB_MANIFEST);

// Enable navigation preload
navigationPreload.enable();

// Create a new navigation route that uses the Network-first, falling back to
// cache strategy for navigation requests with its own cache. This route will be
// handled by navigation preload. The NetworkOnly strategy will work as well.
const navigationRoute = new NavigationRoute(new NetworkFirst({
  cacheName: 'navigations'
}));

// Register the navigation route
registerRoute(navigationRoute);

// Create a route for image, script, or style requests that use a
// stale-while-revalidate strategy. This route will be unaffected
// by navigation preload.
const staticAssetsRoute = new Route(({request}) => {
  return ['image', 'script', 'style'].includes(request.destination);
}, new StaleWhileRevalidate({
  cacheName: 'static-assets'
}));

// Register the route handling static assets
registerRoute(staticAssetsRoute);

Quando il precaricamento della navigazione è attivato, Workbox risponderà alle richieste di navigazione che utilizzano le strategie NetworkFirst o NetworkOnly con la risposta precaricata.

Come faccio a capire se il precaricamento della navigazione funziona?

Nelle build di sviluppo, Workbox registra molte informazioni su ciò che fa. Se vuoi controllare se il precaricamento della navigazione funziona in Workbox, apri la console in un browser di supporto durante una richiesta di navigazione e verrà visualizzato un messaggio di log che indica quanto segue:

Uno screenshot dei log di Workbox nella console dei DevTools di Chrome. I messaggi vengono letti, dall'alto verso il basso: "Il router risponde a /", "Utilizzo di una richiesta di navigazione precaricata per /" e "Utilizzo di NetworkFirst per rispondere a /".

Per impostazione predefinita, questo logging non sarà visibile nelle build di produzione, quindi non sarà visibile quando esegui il deployment del service worker in produzione, ma è un ottimo modo per verificare che il precaricamento della navigazione funzioni (tra le altre cose).

Personalizzazione delle risposte precaricate

Quando utilizzi il precaricamento della navigazione, potrebbero verificarsi scenari in cui è necessario personalizzare le risposte precaricate nel backend di un'applicazione. Uno degli scenari in cui potrebbe essere utile è i Service worker che riproducono in streaming contenuti parziali dalla rete.

In questi casi, conviene sapere che le richieste di precaricamento vengono inviate con un'intestazione Service-Worker-Navigation-Preload impostata con il valore predefinito true:

Service-Worker-Navigation-Preload: true

Quindi, nel backend della tua applicazione, puoi controllare questa intestazione e modificare la risposta in base alle tue esigenze. Se per qualsiasi motivo il valore predefinito dell'intestazione risulta problematico, puoi modificarlo nel contesto della finestra. Tieni presente che qualsiasi lavoro svolto sul server per la lettura di questa intestazione spetta a te e al di fuori dell'ambito di Workbox.

Conclusione

Il precaricamento di navigazione è difficile da ottenere se utilizzato direttamente, ma ne vale la pena per garantire che un service worker non impedisca al browser di effettuare richieste di navigazione. Grazie a Workbox, puoi beneficiare del precaricamento di navigazione con molto meno lavoro. Per maggiori dettagli sul modulo workbox-navigation-preload, consulta la relativa documentazione di riferimento.