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 memorizzazione nella cache anticipata consente di inviare i 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 utilizzare Workbox?
L'utilizzo di Workbox per il pre-caching è facoltativo. Puoi scrivere il tuo codice per precaricare gli asset critici durante l'installazione del servizio worker. Il vantaggio principale dell'utilizzo di Workbox è il controllo della versione immediato. Avrai molti meno problemi ad aggiornare gli asset pre-cache utilizzando Workbox rispetto a se dovessi gestire autonomamente il controllo delle versioni e l'aggiornamento di questi file.
Precaricare i manifest
La precaricazione è basata su un elenco di URL e informazioni sul controllo delle versioni associate per ciascun URL. Complessivamente, queste informazioni sono note come manifest di pre-cache. Il manifest è la "fonte di dati" 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'
}]
Quando il servizio worker è installato, vengono create tre voci della cache nello spazio di archiviazione della cache per ciascuno dei tre URL elencati. Il primo asset ha informazioni sul controllo delle versioni già incluse nel relativo URL (app è il nome file effettivo e .abcd1234 contiene le informazioni sul controllo delle versioni, subito prima dell'estensione del file .js). Gli strumenti di compilazione di Workbox possono rilevare questo problema ed escludere un campo di revisione. Gli altri due asset non includono informazioni sul controllo delle versioni nei relativi URL, pertanto gli strumenti di compilazione 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 vengono memorizzati nella cache, devono rispondere alle richieste in uscita. Ciò richiede un ascoltatore di eventi fetch nel tuo service worker che possa controllare quali URL sono stati memorizzati nella cache e restituire in modo affidabile le risposte memorizzate nella cache, bypassando la rete. Poiché il service worker controlla la cache per le risposte
(e le utilizza prima della rete), si tratta di una
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 memorizzati nella cache devono essere aggiornati.
Aggiornamenti alle risorse prememorizzate nella cache
Man mano che rilasci nuove versioni della tua app web, devi mantenere aggiornati gli URL pre-caricati in precedenza, pre-caricare i nuovi asset ed eliminare le voci obsolete. Finché continui a generare un manifest precache completo ogni volta che ricostruisci il sito, questo manifest funge da "fonte attendibile" per lo stato del precache 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 lo hai ricostruito, l'ultimo manifest precache potrebbe aver subito le seguenti modifiche:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Ogni una di queste modifiche indica al tuo worker di servizio che devono essere eseguite nuove richieste per aggiornare le voci memorizzate nella cache in precedenza ('offline.svg' e 'index.html') e memorizzare nella cache nuovi URL ('app.ffaa4455.js'), nonché le eliminazioni per ripulire gli URL che non sono più utilizzati ('app.abcd1234.js').
Esperienza di installazione "come in un app store"
Un altro vantaggio del precaching è che puoi offrire agli utenti un'esperienza che altrimenti sarebbe difficile da ottenere al di fuori di un'installazione di un "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 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 che ha visitato in passato. Il precaricamento offre la stessa esperienza alle app web.
Quali asset devono essere memorizzati nella cache in anticipo?
Consulta di nuovo la guida Identificare i contenuti caricati per avere un quadro chiaro degli URL che ha più senso memorizzare nella cache in anticipo. 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 il precaricamento di contenuti multimediali o altri asset che vengono caricati in un secondo momento (a meno che non siano fondamentali per la funzionalità della tua app web). Utilizza invece una strategia di memorizzazione nella cache al runtime per assicurarti che questi asset vengano memorizzati nella cache man mano che vengono utilizzati.
Tieni sempre presente che la memorizzazione nella cache prevede l'utilizzo della larghezza di banda e dello spazio di archiviazione della rete sul dispositivo di un utente (proprio come accade con l'installazione di un'app da un app store). Spetta a te, in qualità di sviluppatore, eseguire la precache in modo ponderato ed evitare un manifest precache eccessivamente grande.
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 abituali della tua app web traggono vantaggio nel lungo periodo dal costo iniziale del precaching, poiché la possibilità di evitare la rete si ripaga rapidamente in termini di larghezza di banda risparmiata nel tempo.