Questa documentazione ha già parlato della pre-memorizzazione nella cache, ma non abbastanza su come migliorarla. Questo è importante perché, indipendentemente dal fatto che utilizzi Workbox, è facile pre-memorizzare troppi dati nella cache e sprecare dati e larghezza di banda. Devi fare attenzione a come il payload di pre-memorizzazione nella cache influisce sull'esperienza utente.
Mentre leggi questo documento, tieni presente che si tratta di linee guida generali. L'architettura e i requisiti della tua applicazione potrebbero richiedere operazioni diverse rispetto a quanto suggerito qui, ma queste linee guida fungono da valori predefiniti.
Azione: pre-memorizzazione nella cache di risorse statiche critiche
I migliori candidati per la pre-memorizzazione nella cache sono asset statici fondamentali, ma quale risorsa viene considerata "importante"? Dal punto di vista dello sviluppatore, si può avere la tentazione di pensare che un'intera applicazione sia "critica", ma ciò che conta di più è il punto di vista dell'utente. Considera gli asset critici come quelli assolutamente necessari per fornire un'esperienza utente:
- Fogli di stile globali.
- File JavaScript che forniscono funzionalità globali.
- HTML della shell dell'applicazione, se applicabile alla tua architettura.
Promemoria: si tratta di linee guida generali, non di consigli complessi. Per la prememorizzazione degli asset, è preferibile optare per la pre-memorizzazione nella cache, anziché di più.
Azione: pre-memorizzazione nella cache di un fallback offline per siti web di più pagine
Per i tipici siti web di più pagine, è possibile che tu faccia affidamento su una strategia di memorizzazione nella cache network-first o solo rete per gestire le richieste di navigazione.
In questi casi, dovrai assicurarti che il service worker venga pre-memorizzato nella cache e risponda con una pagina di riserva offline quando l'utente effettua una richiesta di navigazione mentre è offline. Un modo per farlo in Workbox potrebbe essere utilizzare una strategia di sola rete con un fallback offline, sfruttando anche il precaricamento della navigazione:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
In questo modo, se un utente passa alla modalità offline e apre una pagina che non è nella cache, riceverà almeno alcuni contenuti offline.
Forse sì: considera la precauzione speculativa
Anche se potrebbe capitare di non farlo, esiste un potenziale vantaggio nella memorizzazione nella cache degli asset che vengono utilizzati solo in determinati casi. Pensaci in questo modo: gli utenti comporteranno alcuni download di dati aggiuntivi iniziali, con il vantaggio speculativo di accelerare le richieste future per questi asset.
E ora il grande avvertimento: fai molto attenzione se decidi di farlo. Per farlo è facile sprecare i dati e la decisione deve basarsi sui dati. Inoltre, evita di inserire in modo speculativo asset che cambiano spesso nella cache, poiché l'utente dovrà sostenere un utilizzo dei dati aggiuntivo ogni volta che il codice di pre-memorizzazione nella cache rileva una nuova revisione. Osserva i flussi di utenti nelle tue analisi per vedere dove tendono ad andare gli utenti. Se hai dei dubbi sulla precauzione speculativa degli asset, probabilmente è un buon segno non per farlo.
Forse non è consentito: pre-memorizzare nella cache l'HTML statico
Questa linea guida vale soprattutto per i siti statici in cui i file HTML separati vengono generati da un generatore di siti statico oppure manualmente, anziché essere generati dinamicamente o forniti da un backend di un'applicazione. Se questo descrive la tua architettura, probabilmente sarebbe meglio se non pre-memorizzazione nella cache ogni file HTML per il tuo sito web.
Un problema della pre-memorizzazione dei file HTML di un intero sito nella cache è che il markup che viene ora pre-memorizzato nella cache verrà sempre eseguito dalla cache in un secondo momento fino all'aggiornamento del service worker. Questo è ottimo per le prestazioni, ma può portare a un significativo tasso di abbandono della cache se il codice HTML del tuo sito web cambia spesso.
Tuttavia, ci sono un paio di eccezioni a questa regola. Se stai implementando un sito web di piccole dimensioni con pochi file HTML statici, probabilmente è opportuno pre-memorizzare nella cache tutte le pagine in modo che siano disponibili offline. Se hai un sito web particolarmente grande, prendi in considerazione l'inserimento speculativo di prememorizzazione nella cache di alcune pagine di alto valore e un fallback offline e affidati alla memorizzazione nella cache di runtime per memorizzare automaticamente altre pagine nella cache.
Non pre-memorizzare nella cache immagini adattabili o favicon
Non si tratta di una linea guida generale, ma piuttosto di una regola generale. Le immagini adattabili sono una soluzione complessa a un problema complesso: gli utenti che usano molti dispositivi usano molti dispositivi, ognuno dei quali presenta dimensioni diverse, densità dei pixel e supporto di formati alternativi. Se pre-memorizzazione nella cache un intero set di immagini reattive, è probabile che tu stia pre-memorizzando nella cache diverse immagini quando l'utente potrebbe finire per scaricarne solo una.
I favicon presentano una situazione simile, in quanto i siti web spesso implementano un intero set di favicon in scenari diversi. Molto spesso, viene richiesta una sola favicon, il che comporta uno spreco di precauzioni per un intero set di favicon.
Fai un favore agli utenti ed evita di pre-memorizzare nella cache set di immagini e favicon adattabili. Affidati alla memorizzazione nella cache di runtime. Se devi pre-memorizzare nella cache le immagini più utilizzate che non fanno parte di un insieme di immagini adattabili o favicon. Le immagini SVG sono meno rischiose in termini di utilizzo dei dati: un singolo file SVG viene eseguito in modo ottimale indipendentemente dalla densità dei pixel di una determinata schermata.
Azioni sconsigliate: pre-memorizzare i polyfill nella cache
La variazione del supporto dei browser per le API è una sfida costante per gli sviluppatori web e il polyfilling è uno dei modi in cui questa sfida viene affrontata. Un modo per ridurre al minimo il costo delle prestazioni dei polyfill è eseguire il controllo delle funzionalità e caricare solo i polyfill per i browser che ne hanno bisogno.
Poiché il caricamento condizionale dei polyfill avviene durante il runtime rispetto all'ambiente attuale, la pre-memorizzazione dei polyfill nella cache è una scommessa. Alcuni utenti ne trarranno vantaggio, mentre altri finiranno per sprecare larghezza di banda per polyfill non necessari.
Non pre-memorizzare i polyfill. Affidati alla memorizzazione nella cache di runtime per garantire che vengano memorizzate nella cache solo nei browser che ne richiedono la memorizzazione per evitare sprechi di dati.
Conclusione
La pre-memorizzazione nella cache richiede in anticipo la scelta degli asset di cui gli utenti hanno effettivamente bisogno, ma puoi sicuramente ottenerla nel modo giusto in modo da dare priorità al rendimento e all'affidabilità futuri.
Se non hai la certezza che determinati asset debbano essere pre-memorizzati nella cache, la soluzione migliore potrebbe essere chiedere a Workbox di escluderli e di creare una route di memorizzazione nella cache di runtime per gestirli. In entrambi i casi, la prememorizzazione verrà trattata dettagliatamente più avanti in questa documentazione, così potrai applicare questi principi alla tua logica di pre-memorizzazione nella cache in futuro.