Una delle funzionalità dei Service worker è la possibilità di salvare i file nella cache durante l'installazione del Service worker. In questo caso si parla di "prememorizzazione nella cache". La pre-memorizzazione nella cache consente di pubblicare file memorizzati nella cache al browser senza accedere alla rete. Usa la pre-memorizzazione nella cache per gli asset critici di cui il tuo sito ha bisogno anche quando è offline: pagina principale, stili, immagine di riserva e script essenziali.
Perché dovresti usare Workbox?
L'uso di Workbox per la pre-memorizzazione nella cache è facoltativo. Puoi scrivere il tuo codice per prememorizzare nella cache gli asset critici durante l'installazione del service worker. Il vantaggio principale dell'utilizzo di Workbox è il controllo della versione pronta all'uso. Incontrerai molti meno problemi di aggiornamento degli asset prememorizzati nella cache con Workbox rispetto al caso in cui dovessi gestire autonomamente il controllo delle versioni e l'aggiornamento di questi file.
Manifest di pre-memorizzazione nella cache
La pre-memorizzazione nella cache si basa su un elenco di URL e sulle informazioni sul controllo delle versioni associate per ciascun URL. Complessivamente, queste informazioni sono note come manifest di pre-cache. Il manifest è la "fonte di riferimento" per lo stato di tutto ciò che si trova nella preregistrazione per una determinata versione di un'app web. Un manifest di pre-cache, nel formato utilizzato da Workbox, ha un aspetto simile a questo:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Una volta installato il service worker, nell'Archiviazione cache vengono create tre voci della cache per ciascuno dei tre URL elencati. Nell'URL del primo asset sono già incluse 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 sono in grado di rilevare questo comportamento ed escludere un campo di revisione. Gli
altri due asset non includono informazioni sul controllo delle versioni negli URL, quindi gli strumenti
di creazione di Workbox creano un campo revision separato, contenente un hash dei contenuti
del file locale.
Gestione di risorse prememorizzate nella cache
L'aggiunta di asset alla cache è solo una parte della storia 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 service worker in grado di verificare quali URL sono stati
prememorizzati nella cache e restituire in modo affidabile le risposte memorizzate nella cache, bypassando la
rete nel processo. Poiché il service worker controlla la cache per verificare la presenza di risposte
(e le utilizza prima della rete), questa è chiamata strategia cache-first.
Aggiornamenti efficienti
Un manifest di pre-cache fornisce una rappresentazione esatta dello stato previsto della cache. Se una combinazione URL/revisione nel manifest 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 prememorizzati nella cache devono essere aggiornati.
Aggiornamenti alle risorse prememorizzate nella cache
Man mano che rilasci nuove versioni dell'app web nel corso del tempo, devi mantenere aggiornati gli URL precedentemente memorizzati nella cache, prememorizzare nella cache nuovi asset ed eliminare le voci obsolete. Se continui a generare un manifest di pre-cache completo ogni volta che ricrei il tuo sito, questo manifest funge da "fonte attendibile" per lo stato di pre-cache in qualsiasi momento.
Se esiste già un URL con un nuovo campo di revisione o se sono stati aggiunti o eliminati dal manifest, il tuo service worker segnala che è necessario eseguire gli aggiornamenti come parte dei gestori di eventi install e activate. Ad esempio, se hai apportato alcune modifiche al tuo sito e
ricompilato, il manifest pre-cache 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 comunica al service worker che è necessario effettuare nuove richieste per aggiornare le voci precedentemente memorizzate nella cache ('offline.svg' e 'index.html') e memorizzare nella cache i nuovi URL ('app.ffaa4455.js'), nonché le eliminazioni per pulire gli URL non più utilizzati ('app.abcd1234.js').
Esperienza di installazione reale in "app store"
Un altro vantaggio della pre-memorizzazione nella cache è che permette di offrire agli utenti un'esperienza che altrimenti sarebbe difficile da ottenere al di fuori di un'installazione di "app store". Quando un utente visita qualsiasi pagina della tua app web per la prima volta, puoi potenzialmente prememorizzare nella cache tutti gli URL necessari per mostrare in anticipo una delle visualizzazioni della tua app web, senza dover aspettare che visiti ogni singola visualizzazione.
Quando un utente installa un'app, si aspetta che ogni parte venga visualizzata rapidamente, non solo le visualizzazioni a cui ha effettuato in passato. La pre-memorizzazione nella cache offre la stessa esperienza alle app web.
Quali asset devono essere prememorizzati nella cache?
Consulta la guida Identifica gli elementi che vengono caricati per avere un'idea di quali URL è più opportuno prememorizzare nella cache. La regola generale prevede di prememorizzare nella cache qualsiasi codice HTML, JavaScript o CSS caricato in anticipo ed è fondamentale per visualizzare la struttura di base di una determinata pagina.
È preferibile evitare di memorizzare nella cache contenuti multimediali o altri asset caricati in un secondo momento (a meno che non siano essenziali per la funzionalità dell'app web). Utilizza invece una strategia di memorizzazione nella cache di runtime per assicurarti che questi asset vengano memorizzati nella cache man mano.
Tieni sempre presente che la pre-memorizzazione nella cache comporta l'utilizzo di larghezza di banda di rete e spazio di archiviazione sul dispositivo di un utente (proprio come avviene per l'installazione di un'app da uno store). Spetta a te, in qualità di sviluppatore, pre-memorizzare nella cache ed evitare un file manifest di pre-cache troppo pieno.
Gli strumenti di creazione di Workbox consentono di indicare il numero di elementi nel manifest di pre-cache e le dimensioni totali del payload di pre-cache.
I visitatori ricorrenti della tua app web traggono vantaggio a lungo termine dal costo iniziale della prememorizzazione nella cache, poiché la possibilità che offre di evitare che la rete si ripaga rapidamente in cambio di larghezza di banda risparmiata nel tempo.