Una caratteristica dei Service worker è la possibilità di salvare i file nella cache durante l'installazione del Service worker. Questo processo è noto come "pre-memorizzazione nella cache". La precauzione consente di pubblicare file memorizzati nella cache nel browser senza accedere alla rete. Usa la memorizzazione nella cache per gli asset critici necessari per il tuo sito anche offline: pagina principale, stili, immagine di riserva e script essenziali.
Perché dovresti utilizzare Workbox?
L'utilizzo di Workbox per la memorizzazione nella cache è facoltativo. Puoi scrivere il tuo codice per pre-memorizzare nella cache gli asset critici durante l'installazione del service worker. Il vantaggio principale dell'utilizzo di Workbox è il controllo della versione pronto all'uso. Incontrerai molti meno problemi di aggiornamento degli asset pre-memorizzati nella cache utilizzando Workbox rispetto a quando dovevi gestire autonomamente il controllo delle versioni e l'aggiornamento di questi file.
Pre-memorizzazione nella cache dei manifest
La memorizzazione nella cache dipende da un elenco di URL e da informazioni associate sul controllo delle versioni per ogni URL. Complessivamente, queste informazioni sono note come manifest di pre-cache. Il file manifest è la "fonte attendibile" per lo stato di tutto ciò che deve trovarsi nella precache per una determinata versione di un'app web. Un file manifest precache, nel formato utilizzato da Workbox, ha un aspetto simile al seguente:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Quando il service worker viene installato, in Cache Storage vengono create tre voci di cache per ciascuno dei tre URL elencati. Il primo asset contiene già nell'URL informazioni sul controllo delle versioni (app è il nome effettivo del file e .abcd1234 contiene le informazioni sul controllo delle versioni, subito prima dell'estensione del file.js). Gli strumenti di creazione di Workbox possono rilevare questo problema ed escludere un campo di revisione. Gli altri due asset non includono informazioni sul controllo delle versioni negli URL, perciò gli strumenti di creazione di Workbox creano un campo revision separato, contenente un hash dei contenuti del file locale.
Pubblicazione di risorse pre-cache
L'aggiunta di asset alla cache è solo una parte del processo di pre-memorizzazione nella cache: una volta che gli asset sono memorizzati nella cache, devono rispondere alle richieste in uscita. Ciò richiede un listener di eventi fetch nel tuo service worker in grado di verificare quali URL sono stati prememorizzati nella cache e restituire le risposte memorizzate nella cache in modo affidabile, bypassando la rete nel processo. Dal momento che il service worker controlla la cache per trovare risposte
(e utilizza quelle prima della rete), si parla di
strategia cache-first.
Aggiornamenti efficienti
Un manifest precache fornisce una rappresentazione esatta dello stato previsto della cache; se nel file manifest una combinazione di URL/revisione cambia, un service worker sa che la voce precedente memorizzata nella cache non è più valida e deve essere aggiornata. È sufficiente una singola richiesta di rete, effettuata automaticamente dal browser nell'ambito del controllo degli aggiornamenti del service worker, per determinare quali URL pre-memorizzati nella cache devono essere aggiornati.
Aggiornamenti alle risorse pre-memorizzate nella cache
Man mano che rilasci nuove versioni dell'app web, devi mantenere aggiornati gli URL precedentemente memorizzati nella cache, pre-memorizzare nella cache nuovi asset ed eliminare le voci obsolete. Se continui a generare un manifest pre-cache completo ogni volta che ricrei il sito, quel manifest funge da "fonte attendibile" per lo stato di preregistrazione in qualsiasi momento.
Se esiste già un URL con un nuovo campo di revisione o se sono stati aggiunti o eliminati dal manifest, significa che il service worker deve eseguire aggiornamenti, nell'ambito dei gestori di eventi install e activate. Ad esempio, se hai apportato alcune modifiche al sito e ricompilato, il file manifest precache più recente potrebbe aver subito le seguenti modifiche:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Ognuna di queste modifiche indica al service worker che è necessario effettuare nuove richieste per aggiornare le voci precedentemente memorizzate nella cache ('offline.svg' e 'index.html') e memorizzare nuovi URL ('app.ffaa4455.js') nella cache, nonché le eliminazioni per ripulire gli URL non più utilizzati ('app.abcd1234.js').
Esperienza di installazione realmente "app store"
Un altro vantaggio della memorizzazione nella cache è che puoi offrire agli utenti un'esperienza che sarebbe altrimenti difficile da ottenere al di fuori di un'installazione "app store". Quando un utente visita per la prima volta qualsiasi pagina della tua app web, puoi potenzialmente prememorizzare nella cache tutti gli URL necessari per mostrare in anticipo qualsiasi visualizzazione della tua app web, senza dover aspettare fino a quando non visita ogni singola visualizzazione.
Quando un utente installa un'app, si aspetta che venga mostrata rapidamente ogni parte, non solo le visualizzazioni che ha visitato in passato. La prememorizzazione nella cache permette di usufruire della stessa esperienza nelle app web.
Quali asset devono essere pre-memorizzati nella cache?
Consulta la guida Identifica cosa viene caricato per avere un quadro di quali URL è più adatto per la preregistrazione. La regola generale è pre-memorizzare nella cache tutti i codici HTML, JavaScript o CSS caricati in anticipo ed è fondamentale per visualizzare la struttura di base di una determinata pagina.
È preferibile evitare di memorizzare nella cache i contenuti multimediali o altri asset che vengono caricati in un secondo momento (a meno che non sia fondamentale per la funzionalità della tua app web). Utilizza invece una strategia di memorizzazione nella cache di runtime per assicurarti che questi asset vengano memorizzati nella cache a consumo.
Tieni sempre presente che la memorizzazione nella cache comporta l'utilizzo di larghezza di banda e spazio di archiviazione della rete sul dispositivo di un utente, proprio come avviene nell'installazione di un'app da uno store. Spetta a te, in qualità di sviluppatore, pre-memorizzare la cache con oculatezza ed evitare un manifest di pre-cache eccessivo.
Gli strumenti di creazione di Workbox indicano il numero di elementi presenti nel file manifest di pre-cache e la dimensione totale del payload di pre-cache.
I visitatori abituali della tua applicazione web traggono vantaggio nel lungo periodo dal costo iniziale della pre-cache, in quanto la capacità che offre di evitare la rete si ripaga rapidamente risparmiando larghezza di banda nel tempo.