Panoramica dei worker

Come i web worker e i service worker possono migliorare le prestazioni del tuo sito e quando utilizzare un web worker anziché un service worker.

Andrew Guan

Demián Renzulli

Questa panoramica spiega come i web worker e i service worker possono migliorare le prestazioni del tuo sito web e quando utilizzare un web worker anziché un service worker. Guarda il resto di questa serie per modelli specifici di comunicazione tra finestre e service worker.

Come 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 svolgere attività come il rendering della pagina e l'esecuzione della garbage collection. L'esecuzione di codice JavaScript eccessivo può bloccare il thread principale, ritardando l'esecuzione di queste attività da parte del browser e causando un'esperienza utente negativa.

Nello sviluppo di applicazioni iOS/Android, un pattern comune per garantire che il thread principale dell'app rimanga libero di rispondere agli eventi utente è quello di scaricare le operazioni su thread aggiuntivi. Infatti, nelle ultime versioni di Android, il blocco del thread principale per un periodo di tempo troppo lungo causa l'arresto anomalo dell'app.

Sul web, JavaScript è stato progettato attorno al concetto di un singolo thread e non dispone delle funzionalità necessarie per implementare un modello multithreading come quello delle app, ad esempio la memoria condivisa.

Nonostante queste limitazioni, è possibile ottenere un pattern simile sul web utilizzando i worker per eseguire script in thread in background, consentendo loro di eseguire attività senza interferire con il thread principale. I worker sono un intero ambito JavaScript in esecuzione su 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 pattern più comuni per utilizzarli nei siti web di produzione.

Web worker e service worker

Analogie

Web worker e 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, pertanto non possono interagire direttamente con il DOM e hanno accesso limitato alle API del browser.

Differenze

Si potrebbe pensare che la maggior parte delle operazioni che possono essere delegate a un web worker possano essere eseguite in un service worker e viceversa, ma esistono importanti differenze tra i due:

• A differenza dei web worker, i service worker ti consentono di intercettare le richieste di rete (tramite l'evento fetch) e di 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 è stato registrato.
• Il ciclo di vita del web worker è strettamente legato alla scheda a cui appartiene, mentre il ciclo di vita del service worker è indipendente. Per questo motivo, la chiusura della scheda in cui è in esecuzione un web worker lo interromperà, mentre un service worker può continuare a essere eseguito in background, anche quando il sito non ha schede attive aperte.

Casi d'uso

Le differenze tra i due tipi di worker suggeriscono in quali situazioni è preferibile utilizzare l'uno o l'altro:

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

• Esempio:il team che ha creato il videogioco PROXX voleva lasciare il thread principale il più libero possibile per gestire l'input dell'utente e le animazioni. Per raggiungere questo obiettivo, hanno utilizzato i web worker per eseguire la logica e la manutenzione dello stato del gioco su un thread separato.

I task dei service worker sono generalmente più correlati alla funzione di proxy di rete, alla gestione dei task in background e ad aspetti come la memorizzazione nella cache e la modalità offline.

Esempio:in una PWA di podcast, un utente potrebbe voler consentire agli utenti di scaricare puntate complete per ascoltarle offline. Un service worker e, in particolare, l'API Background Fetch possono essere utilizzati a questo scopo. In questo modo, se l'utente chiude la scheda durante il download dell'episodio, l'attività non deve essere interrotta.

Strumenti e librerie

La comunicazione tra finestre 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, esamineremo due di questi che si occupano rispettivamente di window to web worker e service worker: Comlink e Workbox.

Comlink

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

Workbox

Workbox è una libreria molto usata per creare siti web che utilizzano service worker. Racchiude un insieme di best practice su aspetti quali la memorizzazione nella cache, la modalità offline, la sincronizzazione in background e così via. Il modulo workbox-window fornisce un modo pratico per scambiare messaggi tra il service worker e la pagina.

Passaggi successivi

Il resto di questa serie si concentra sui pattern per la comunicazione tra finestre e service worker:

• Guida alla memorizzazione nella cache imperativa: chiama un service worker dalla pagina per memorizzare nella cache le risorse in anticipo (ad es. negli scenari di prefetching).
• Aggiornamenti di trasmissione: chiama la pagina dal service worker per comunicare aggiornamenti importanti (ad es. è disponibile una nuova versione del sito web).
• Comunicazione bidirezionale: delega di un'attività a un service worker (ad es. un download pesante) e aggiornamento della pagina sullo stato di avanzamento.

Per i pattern di comunicazione tra finestre e web worker, consulta: Utilizzare i web worker per eseguire JavaScript al di fuori del thread principale del browser.