La memorizzazione nella cache del runtime consiste nell'aggiunta graduale delle risposte a una cache "a mano a mano" Sebbene la memorizzazione nella cache di runtime non sia utile per l'affidabilità della richiesta attuale, può contribuire a rendere più affidabili le richieste future relative allo stesso URL.
La cache HTTP del browser è un esempio di memorizzazione nella cache di runtime; viene compilata solo dopo una richiesta per un determinato URL. Tuttavia, i service worker permettono di implementare la memorizzazione nella cache in runtime che va oltre ciò che può offrire la sola cache HTTP.
Diventare strategici
A differenza della prememorizzazione nella cache (che tenta sempre di pubblicare un insieme di file predefiniti da una cache), la memorizzazione nella cache di runtime può combinare l'accesso alla rete e alla cache in diversi modi. In genere, ogni combinazione è definita una strategia di memorizzazione nella cache. Le principali strategie di memorizzazione nella cache includono:
- Network-first
- Prima cache
- Riconvalida in caso di inattività
Network-first
Con questo approccio, il service worker tenta prima di recuperare una risposta dalla rete. Se la richiesta di rete ha esito positivo, perfetto. La risposta viene restituita all'applicazione web e una copia della risposta viene archiviata utilizzando l'API Cache Storage, creando una nuova voce o aggiornando una voce precedente per lo stesso URL.
Se la richiesta di rete ha esito negativo o richiede troppo tempo per restituire una risposta, viene restituita invece la risposta più recente dalla cache.
Prima cache
Una strategia basata sulla cache è essenzialmente l'opposto di una strategia network-first. Con questo approccio, quando il service worker intercetta una richiesta, utilizza innanzitutto l'API Cache Storage per verificare se è disponibile una risposta memorizzata nella cache. In caso affermativo, la risposta viene restituita all'app web.
In caso di fallimento della cache, tuttavia, il service worker andrà in rete e tenterà di recuperare una risposta lì. Se la richiesta di rete ha esito positivo, questa viene restituita all'app web e viene salvata una copia in una cache. Questa copia memorizzata nella cache verrà utilizzata per ignorare la rete la volta successiva che verrà effettuata una richiesta per gli stessi URL.
Riconvalida in caso di inattività
La riconvalida in caso di inattività è qualcosa di ibrido. Quando lo utilizzi, il tuo worker di servizio verifica immediatamente la presenza di una risposta memorizzata nella cache e, se presente, la ritrasmette alla tua app web.
Nel frattempo, indipendentemente dal fatto che ci sia stata una corrispondenza della cache, il tuo worker di servizio attiva anche una richiesta di rete per ricevere una risposta "aggiornata". Questa risposta viene utilizzata per aggiornare qualsiasi risposta precedentemente memorizzata nella cache. Se il controllo iniziale della cache non è andato a buon fine, viene restituita anche una copia della risposta di rete alla tua applicazione web.
Perché dovresti utilizzare Workbox?
Queste strategie di memorizzazione nella cache corrispondono a formule che normalmente dovresti riscrivere ogni volta nel tuo service worker. Invece di farvi ricorso, Workbox le offre pacchettizzate come parte della sua libreria di strategie, pronte per essere utilizzate dal tuo service worker.
Workbox fornisce inoltre supporto per il controllo delle versioni, consentendo di scadere automaticamente le voci memorizzate nella cache o di inviare una notifica alla tua app web quando si verificano aggiornamenti a una voce precedentemente memorizzata nella cache.
Quali strategie devono essere memorizzate nella cache e con quali strategie?
La memorizzazione nella cache del runtime può essere considerata un complemento della memorizzazione nella cache. Se è già stata prememorizzata nella cache tutti gli asset, l'operazione è stata completata: non è necessario memorizzare nella cache nulla in fase di runtime. È probabile che, per qualsiasi app web relativamente complessa, non preveda comunque tutto nella cache.
I file multimediali più grandi, gli asset pubblicati da un host di terze parti come una rete CDN o le risposte dell'API sono solo alcuni esempi dei tipi di asset che non possono essere pre-memorizzati in modo efficace nella cache. Usa il riquadro Network (Rete) in DevTools per identificare le richieste che rientrano in questa categoria e, per ciascuna di esse, valuta quale compromesso tra aggiornamento e affidabilità è appropriato.
Usa lo stato inattivo-mentre-riconvalida per dare la priorità all'affidabilità rispetto all'aggiornamento
Poiché una strategia di riconvalida in caso di inattività restituisce una risposta memorizzata nella cache quasi immediatamente, dopo che la cache è stata compilata tramite la prima richiesta, noterai prestazioni affidabili e veloci quando utilizzi questa strategia. Ciò comporta il compromesso tra la restituzione di dati di risposta che potrebbero essere obsoleti rispetto a quelli recuperati dalla rete. Questa strategia è la più indicata per asset come le immagini del profilo utente o le risposte iniziali dell'API utilizzate per compilare una visualizzazione, quando sai che mostrare qualcosa immediatamente è fondamentale, anche se si tratta di un valore meno recente.
Utilizza Network-first per dare la priorità all'aggiornamento rispetto all'affidabilità
In un certo senso, l'uso di una strategia basata sulla rete significa ammettere la sconfitta nella battaglia contro la rete. È una priorità, ma ciò porta con sé incertezza sull'affidabilità. Per alcuni tipi di asset, è preferibile avere una risposta aggiornata per recuperare informazioni obsolete. Ad esempio, potresti preferire l'aggiornamento quando effettui una richiesta API per il testo di un articolo che viene aggiornato di frequente.
Utilizzando una strategia network-first all'interno di un service worker, invece di andare direttamente contro la rete, hai il vantaggio di poter passare a something, anche se si tratta di una risposta potenzialmente obsoleta. L'affidabilità non sarà rapida, ma almeno offline.
Usa cache-first per gli URL con versione
In una strategia basata sulla cache, una volta che una voce viene memorizzata nella cache, non viene mai aggiornata. Per questo motivo, assicurati di utilizzarlo solo con asset che probabilmente non cambieranno. In particolare, funziona al meglio per gli URL che contengono informazioni sul controllo delle versioni, lo stesso tipo di URL che dovrebbero essere pubblicati anche con un'intestazione della risposta Cache-Control: max-age=31536000.