Una funzionalità dei worker di servizio è la possibilità di salvare i file nella cache durante l'installazione del worker di servizio. Questa operazione è nota come "precaching". La memorizzazione nella cache consente di inviare i file memorizzati nella cache al browser senza accedere alla rete. Utilizza il precaricamento 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 service 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. Nel complesso, queste informazioni sono note come manifest precache. Il manifest è la "fonte attendibile" dello stato di tutto ciò che deve essere memorizzato nella cache per una determinata versione di un'app web. Un manifest precache, nel formato utilizzato da Workbox, ha il seguente aspetto:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Quando il service 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.
Pubblicazione di risorse pre-cache
L'aggiunta di asset alla cache è solo una parte della storia del precaching: una volta memorizzati nella cache, gli asset 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 precache fornisce una rappresentazione esatta dello stato della cache previsto. Se una combinazione di URL/revisione nel manifest cambia, un worker di servizio sa che la voce memorizzata nella cache precedente 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 pre-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 un URL con un nuovo campo di revisione o se alcuni URL sono stati aggiunti o rimossi dal file manifest, il service worker deve eseguire aggiornamenti nell'ambito dei gestori 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 i nuovi URL ('app.ffaa4455.js'
), nonché le eliminazioni per ripulire gli URL che non vengono 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 una pagina della tua app web, puoi potenzialmente memorizzare nella cache tutti gli URL necessari per visualizzare qualsiasi delle sue visualizzazioni in anticipo, senza dover attendere 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 è precache qualsiasi codice HTML, JavaScript o CSS caricato all'inizio ed è fondamentale per la visualizzazione della struttura di base di una determinata pagina.
È preferibile evitare il precaching 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 compilazione di Workbox ti aiutano indicando il numero di elementi nel manifest precache e le dimensioni totali del payload precache.
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.