Il deployment di un service worker può modificare il comportamento di un sito web in modi inaspettati. Poiché Workbox semplifica la scrittura e il deployment di un service worker, può essere più facile perdere alcuni degli effetti di un service worker su un sito web una volta eseguito il deployment.
Questo non significa che l'utilizzo di Workbox porti a risultati negativi, ma solo che la comodità che offre può rendere più facile imbattersi in alcune insidie se non si è a conoscenza di ciò che viene associato al deployment di un service worker.
Insidie di pre-memorizzazione
La pre-memorizzazione nella cache è stata trattata in precedenza in questi documenti, senza spiegare completamente come l'esercitazione possa tornare indietro. Potresti riscontrare problemi se applichi la pre-memorizzazione nella cache a troppi asset o se il service worker viene registrato prima che la pagina abbia la possibilità di completare il caricamento degli asset critici.
Poiché il comportamento predefinito di workbox-webpack-plugin
è istruire il service worker a prememorizzare automaticamente nella cache gli asset generati,
questo può essere problematico in modo facile da ignorare, poiché la barriera all'adozione è ridotta.
workbox-webpack-plugin.
In questo esempio, pre-memorizzazione nella cache di 14 asset nel progetto attuale per un totale di 352 kilobyte per impostazione predefinita.Quando un service worker pre-memorizza nella cache gli asset durante l'installazione, vengono avviate contemporaneamente una o più richieste di rete. Ciò può potenzialmente essere problematico per l'esperienza utente se non rispetta le tempistiche. Anche se i tempi sono corretti, si può comunque finire per sprecare dati se la quantità di asset prememorizzati nella cache non è in qualche modo limitata.
Sta tutto nel tempismo
Se un service worker pre-memorizza nella cache qualsiasi elemento, l'ora in cui è registrato è importante.
I service worker vengono spesso registrati utilizzando elementi <script> incorporati.
Ciò significa che i parser HTML potrebbero scoprire il codice di registrazione del service worker prima che vengano caricati gli asset critici della pagina.
Questo è un problema. Un service worker dovrebbe essere idealmente neutrale in caso di prestazioni e non peggiorare le prestazioni. Offri agli utenti un favore e registra un service worker quando viene attivato l'evento load della pagina.
In questo modo si riduce la possibilità che la pre-memorizzazione nella cache interferisca con il caricamento degli asset critici di una pagina, il che a sua volta significa che la pagina può essere interattiva più velocemente senza dover fare i conti con le richieste di rete per gli asset che potrebbero non essere necessari se non in seguito.
Fai attenzione all'utilizzo dei dati
A prescindere dalle tempistiche, la pre-memorizzazione nella cache comporta l'invio delle richieste di rete. Se un manifest degli asset da pre-memorizzare nella cache non viene selezionato attentamente, il risultato potrebbe essere una certa quantità di spreco.
Lo spreco di dati è un potenziale compromesso dalla memorizzazione nella cache, ma non tutti hanno accesso a internet veloce o a piani dati illimitati. Quando esegui la pre-memorizzazione nella cache, valuta la possibilità di eliminare asset particolarmente grandi e di fare affidamento sulla memorizzazione nella cache di runtime per acquisirli, invece di fare ipotesi costose.
L'avvio del service worker può ritardare le richieste di rete
I Service worker vengono eseguiti in un processo separato dal resto del codice di un sito web. Questo processo inizia e si interrompe spesso. Quando un service worker deve gestire un evento di recupero dopo un periodo di inattività, il browser deve prima dedicare del tempo all'avvio del service worker. Questo overhead aggiuntivo prima della gestione di una richiesta è ridotto rispetto al vantaggio di fornire una risposta dalla cache anziché dalla rete.
Quando utilizzi strategie che non possono essere pubblicate dalla cache e devono essere indirizzate alla rete, in particolare quando gestisci le richieste di navigazione, i tempi di avvio aggiungono sempre un certo ritardo. A seconda delle funzionalità del dispositivo e/o della pressione della CPU, una richiesta di navigazione può subire un notevole ritardo dovuto a lenti di avvio dei Service worker. Il deployment di un service worker senza consapevolezza di questo ritardo significa che gli utenti potrebbero riscontrare un hit di prestazioni involontario.
Questo problema è stato risolto con Chrome Preload, ma non è ancora supportato in tutti i browser. Tuttavia, vale la pena considerare il suo utilizzo, che viene illustrato più avanti in questa documentazione.
Le strategie basate sulla cache possono tornare indietro
Le strategie di memorizzazione nella cache che prima consultano la cache o solo la consultano sono ottimi vantaggi sia per l'accesso offline che per le prestazioni. Tuttavia, tendono a causare problemi in alcuni casi selezionati.
Memorizzazione nella cache di runtime per gli asset statici senza versione
I bundler di solito versioneno gli asset statici con un hash basato sui contenuti nel nome del file (ad esempio, styles.a4edf38c.css).
Nei Service worker che utilizzano strategie di memorizzazione nella cache, che consultano prima la cache per gli asset statici e che utilizzano una strategia basata sulla rete per il markup della pagina,
non dovrebbero verificarsi problemi di memorizzazione nella cache poiché nel markup delle risorse aggiornate si fa riferimento agli asset, che viene sempre recuperato dalla rete.
I problemi sorgono in situazioni in cui gli asset statici senza versione vengono memorizzati nella cache durante il runtime utilizzando queste strategie.
Se la funzionalità di un sito web è fornita da app.js e viene utilizzata una strategia di runtime basata sulla cache, app.js viene aggiornato in un secondo momento senza modificare il nome del file, la versione inizialmente memorizzata nella cache continua a essere fornita dalla cache anziché aggiornata.
La soluzione consiste nell'utilizzare una strategia che consulti la rete per eventuali aggiornamenti, ad esempio network-first o stale-while-riconvalida. In alternativa, gli strumenti di creazione possono generare un manifest di pre-memorizzazione nella cache per questi asset, poiché la logica di pre-memorizzazione nella cache di Workbox li terrà aggiornati.
In ogni caso, valuta attentamente il controllo delle versioni degli asset statici, mediante un hash nel nome dell'asset o nella stringa di query. In questo modo eviterai problemi con asset inattivi nei service worker che utilizzano strategie di runtime cache-first per gli asset statici.
Quote di Mind Storage
È comune implementare gli aggiornamenti del service worker di tanto in tanto e, quando gli aggiornamenti vengono implementati, le vecchie cache con nomi scaduti solitamente vengono eliminate durante l'attivazione del nuovo service worker.
Tuttavia, alcune iterazioni dei service worker sono di lunga durata o i nomi delle cache potrebbero non essere aggiornati nei nuovi aggiornamenti. In questi casi, le vecchie risorse statiche possono accumularsi nelle cache man mano che vengono implementati gli aggiornamenti. I browser impostano le quote di spazio di archiviazione e i limiti possono variare. È un buon motivo per essere consapevoli.
Workbox mitiga questi problemi in modo efficace, ma le quote di spazio di archiviazione possono comunque essere superate. Puoi ottenere un controllo più preciso delle cache con il modulo workbox-expiration.
Non temere
Eseguire il deployment di un service worker non è cosa da poco. Tuttavia, non dovrebbe essere un'impresa spaventosa, ma anche un po' di pianificazione e consapevolezza su cosa comporta l'implementazione di un service worker con Workbox. Man mano che procedi, questa documentazione ti aiuterà a risolvere questi problemi con cura e sicurezza.