Panoramica dei worker

In che modo web worker e service worker possono migliorare le prestazioni del tuo sito e quando utilizzare un web worker rispetto a un service worker.

Andrew Guan

Demián Renzulli

Questa panoramica spiega in che modo i web worker e i service worker possono migliorare le prestazioni del tuo sito e quando utilizzarli rispetto a un service worker. Consulta il resto di questa serie per scoprire pattern specifici di comunicazione dei worker operativi e delle finestre.

In che modo i lavoratori possono migliorare il tuo sito web

Il browser utilizza un singolo thread (il thread principale) per eseguire tutto il codice JavaScript in una pagina web, nonché per eseguire attività come il rendering della pagina e la garbage collection. L'esecuzione di una quantità eccessiva di codice JavaScript può bloccare il thread principale, ritardando l'esecuzione di queste attività da parte del browser e compromettendo l'esperienza utente.

Nello sviluppo di applicazioni per iOS/Android, un pattern comune per assicurarsi che il thread principale dell'app rimanga libero per rispondere agli eventi utente consiste nell'offrire le operazioni a thread aggiuntivi. Di fatto, nelle versioni più recenti di Android, bloccare il thread principale per troppo tempo comporta un arresto anomalo dell'app.

Sul web, JavaScript è stato progettato intorno al concetto di un singolo thread e non dispone di funzionalità necessarie per implementare un modello multi-threading come quello delle app, come la memoria condivisa.

Nonostante queste limitazioni, è possibile ottenere un pattern simile sul web utilizzando i worker per eseguire script nei thread in background, in modo che possano eseguire attività senza interferire con il thread principale. I worker sono un intero ambito JavaScript in esecuzione in un thread separato, senza memoria condivisa.

In questo post scoprirai due diversi tipi di worker (web worker e service worker), le loro somiglianze e differenze e i modelli più comuni per il loro utilizzo nei siti web di produzione.

Web worker e service worker

Somiglianze

I web worker e i service worker sono due tipi di worker disponibili per i siti web. Hanno alcune cose in comune:

• Entrambi vengono eseguiti in un thread secondario, consentendo l'esecuzione del codice JavaScript senza bloccare il thread principale e l'interfaccia utente.
• Non hanno accesso agli oggetti Window e Document, quindi non possono interagire direttamente con il DOM e hanno accesso limitato alle API del browser.

Differenze

Si potrebbe pensare che la maggior parte delle cose che possono essere delegate a un web worker può essere fatto in un service worker e viceversa, ma ci sono differenze importanti tra loro:

• A differenza dei web worker, i service worker consentono di intercettare le richieste di rete (tramite l'evento fetch) e ascoltare gli eventi dell'API Push in background (tramite l'evento push).
• Una pagina può generare più web worker, ma un singolo service worker controlla tutte le schede attive nell'ambito con cui è stata registrata.
• La durata del web worker è strettamente associata alla scheda a cui appartiene, mentre il ciclo di vita del worker di servizio è indipendente da questo. Per questo motivo, la chiusura della scheda in cui è in esecuzione un web worker ne comporta la terminazione, mentre un service worker può continuare a essere eseguito in background, anche quando sul sito non sono aperte schede attive.

Nota: per periodi di lavoro relativamente brevi come l'invio di un messaggio, è probabile che il browser non termini un service worker se non ci sono schede attive, ma se l'attività richiede troppo tempo il browser arresterà il service worker, altrimenti c'è rischio per la privacy e la batteria dell'utente. API come Recupero in background, che ti consentono di evitare la terminazione del service worker.

casi d'uso

Le differenze tra entrambi i tipi di lavoratori suggeriscono in quali situazioni uno potrebbe voler utilizzare l'uno o l'altro:

I casi d'uso per i web worker sono più comunemente correlati alla riduzione del carico di lavoro (come i calcoli pesanti) a un thread secondario, per evitare di bloccare l'UI.

• Esempio: il team che ha sviluppato il videogioco PROXX voleva lasciare il thread principale il più libero possibile per occuparsi dell'input e delle animazioni degli utenti. A questo scopo, hanno utilizzato i web worker per eseguire la logica di gioco e la manutenzione dello stato in un thread separato.

Le attività dei service worker sono generalmente più correlate al funzionamento come proxy di rete, alla gestione delle attività in background e ad altri aspetti come la memorizzazione nella cache e la modalità offline.

Esempio:in una PWA per i podcast, potresti voler consentire agli utenti di scaricare puntate complete per ascoltarle offline. A questo scopo è possibile utilizzare un service worker e, in particolare, l'API Background Fetch. In questo modo, se l'utente chiude la scheda durante il download della puntata, l'attività non deve essere interrotta.

L'interfaccia utente viene aggiornata per indicare l'avanzamento di un download (a sinistra). Grazie ai service worker, l'operazione può continuare a essere eseguita dopo che tutte le schede sono state chiuse (a destra).

Strumenti e librerie

La comunicazione con finestra e worker può essere implementata utilizzando diverse API di livello inferiore. Fortunatamente, esistono librerie che astraggono questo processo, occupandosi dei casi d'uso più comuni. In questa sezione ne tratteremo due che si occupano rispettivamente di finestra per web worker e service worker: Comlink e Workbox.

Comlink

Comlink è una piccola libreria RPC (1600) che si occupa di molti dettagli sottostanti durante la creazione di siti web che utilizzano web worker. È stato utilizzato in siti web come PROXX e Squoosh. Un riepilogo delle sue motivazioni ed esempi di codice sono disponibili qui.

Workbox

Workbox è una libreria molto popolare per creare siti web che utilizzano i service worker. Raccoglie una serie di best practice relative, ad esempio, alla memorizzazione nella cache, alla modalità offline, alla sincronizzazione in background e così via. Il modulo workbox-window offre un modo conveniente per scambiare messaggi tra il service worker e la pagina.

Passaggi successivi

Il resto di questa serie è incentrato sui pattern di comunicazione dei lavoratori finestra e dei servizi:

• Guida alla memorizzazione nella cache imperativa: chiamata a un service worker dalla pagina per memorizzare le risorse in anticipo (ad esempio, in scenari di precaricamento).
• Trasmetti aggiornamenti: chiamata alla pagina dal service worker per informare in merito ad aggiornamenti importanti (ad esempio, è disponibile una nuova versione del sito web).
• Comunicazione bidirezionale: delega di un'attività a un service worker (ad esempio un download impegnativo) e tiene la pagina informata sullo stato di avanzamento.

Per i pattern di comunicazione tra worker finestra e web, consulta: Utilizza i web worker per eseguire JavaScript dal thread principale del browser.