Questa documentazione ha trattato in precedenza la prememorizzazione nella cache, ma non abbastanza su come procedere in modo corretto. Questo è importante perché, indipendentemente dal fatto che utilizzi Workbox, è facile prememorizzare nella cache troppo e potenzialmente sprecare dati e larghezza di banda. Devi fare attenzione al modo in cui il payload di pre-memorizzazione nella cache influisce sull'esperienza utente.
Mentre leggi il documento, considera che si tratta di linee guida generali. L'architettura e i requisiti della tua applicazione potrebbero richiedere di eseguire operazioni diverse da quanto suggerito qui, ma queste linee guida fungono da buoni valori predefiniti.
Azione: preregistrazione nella cache gli asset statici critici
I candidati ideali per la pre-memorizzazione nella cache sono gli asset statici critici, ma ciò che viene considerato come "critico" asset? Dal punto di vista degli sviluppatori, l'intera applicazione potrebbe essere tentata di essere considerata "critica", ma il punto di vista dell'utente è ciò che conta di più. Pensa agli asset critici come a quelli assolutamente necessari per offrire 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 rigidi. L'ideale è ridurre la pre-memorizzazione nella cache piuttosto che aumentarla.
Azione consigliata: prememorizza nella cache un fallback offline per i siti web con più pagine
Per i tipici siti web con più pagine, potresti fare affidamento su una strategia di memorizzazione nella cache network-first o solo rete per gestire le richieste di navigazione.
In questi casi, è opportuno assicurarsi che il service worker pre-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 solo di 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 visita una pagina che non è nella sua cache, visualizzerà almeno alcuni contenuti offline.
Forse sì: prendi in considerazione la pre-memorizzazione speculativa
È un grande "forse" ma c'è un potenziale vantaggio nella memorizzazione preliminare nella cache degli asset che vengono utilizzati solo in determinati scenari. Considerala in questo modo: gli utenti dovranno eseguire alcuni download iniziali dei dati in più, con il vantaggio speculativo di accelerare le richieste future per questi asset.
Attenzione: fai molto attenzione se decidi di farlo. È facile sprecare i dati per farlo e la decisione dovrebbe basarsi sui dati. Inoltre, evita di eseguire la pre-memorizzazione nella cache speculativa degli asset che cambiano di frequente, poiché l'utente incorrerà in 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 gli utenti a dirigersi. Se hai dei dubbi sulla precauzione speculativa della memorizzazione nella cache degli asset, è probabilmente un buon segno di non farlo.
Azione non consigliata: prememorizzare nella cache il codice HTML statico
Questa linea guida si applica maggiormente ai siti statici in cui file HTML discreti sono generati da un generatore di siti statico o creati manualmente, invece di essere generati dinamicamente o forniti dal backend di un'applicazione. Se questo descrive la tua architettura, probabilmente la cosa migliore è non prememorizzare nella cache ogni file HTML del tuo sito web.
Un problema della pre-memorizzazione nella cache di un intero sito di file HTML è che il markup che ora viene prememorizzato nella cache verrà sempre fornito dalla cache in un secondo momento fino all'aggiornamento del Service worker. Questo è ottimo per le prestazioni, ma può determinare un tasso di abbandono della cache significativo se il codice HTML del tuo sito web cambia spesso.
Tuttavia, ci sono un paio di eccezioni a questa regola. Se stai implementando un piccolo sito web con alcuni file HTML statici, probabilmente puoi pre-memorizzare nella cache tutte le pagine in modo che siano disponibili offline. Se hai un sito web di grandi dimensioni, prendi in considerazione la preparazione speculativa nella cache di alcune pagine di alto valore e un fallback offline e affidati alla memorizzazione nella cache di runtime per memorizzare altre pagine nella cache.
Azione sconsigliata: prememorizzare nella cache immagini adattabili o favicon
Non si tratta di una linea guida generale, bensì di una regola. Le immagini adattabili rappresentano una soluzione complessa per un problema complesso: hai molti utenti su molti dispositivi e ognuno ha dimensioni dello schermo, densità di pixel e supporto di formati alternativi. Se pre-memorizzi nella cache un intero insieme di immagini adattabili, probabilmente stai pre-memorizzando nella cache diverse immagini quando l'utente potrebbe scaricarne solo una.
Le favicon presentano una situazione simile, in quanto i siti web spesso implementano un intero insieme di favicon per scenari diversi. Molto spesso, viene richiesta una sola favicon, di conseguenza la pre-memorizzazione di un intero insieme di favicon comporta uno spreco di risorse analoghe.
Offri agli utenti un favore e non prememorizzare nella cache i set di immagini reattive e di favicon. Fai affidamento sulla memorizzazione nella cache del runtime. Se devi prememorizzare nella cache le immagini, prememorizza nella cache le immagini più utilizzate che non fanno parte di un insieme di immagini adattabili o favicon. I contenuti SVG sono meno rischiosi in termini di utilizzo dei dati, poiché un singolo SVG esegue il rendering in modo ottimale, indipendentemente dalla densità dei pixel di una determinata schermata.
Azione sconsigliata: prememorizzare nella cache i polyfill
Il supporto variabile dei browser per le API è una sfida continua per gli sviluppatori web e il polyfilling è uno dei modi in cui viene affrontata. Un modo per ridurre al minimo il costo delle prestazioni dei polyfill è eseguire il controllo delle funzionalità e caricare i polyfill solo per i browser che ne hanno bisogno.
Poiché il caricamento dei polyfill viene caricato in modo condizionale durante il tempo di esecuzione rispetto all'ambiente attuale, pre-memorizzare nella cache i polyfill è una sfida. Alcuni utenti ne trarranno vantaggio, mentre altri finiranno per sprecare larghezza di banda per polyfill non necessari.
Non prememorizzare nella cache i polyfill. Fai affidamento sulla memorizzazione nella cache di runtime per assicurarti che vengano memorizzate nella cache solo nei browser che richiedono di evitare sprechi di dati.
Conclusione
La pre-memorizzazione nella cache richiede una certa precauzione in merito agli asset di cui i tuoi utenti hanno effettivamente bisogno, ma puoi sicuramente farlo in modo da dare la priorità all'affidabilità e alle prestazioni future.
Se non sai con certezza se determinati asset devono essere pre-memorizzati nella cache, la soluzione migliore potrebbe essere indicare a Workbox di escluderli e creare un percorso di memorizzazione nella cache di runtime per gestirli. In ogni caso, la prememorizzazione nella cache verrà trattata in dettaglio più avanti in questa documentazione, per cui in futuro sarai in grado di applicare questi principi alla logica di pre-memorizzazione nella cache.