Panoramica dei worker

In che modo i web worker e i service worker possono migliorare le prestazioni del tuo sito e quando utilizzare un web worker o 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 web e quando utilizzare un web worker o un service worker. Dai un'occhiata al resto di questa serie per trovare modelli specifici di comunicazione tra finestre e worker di servizio.

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 raccolta dei rifiuti. 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 per iOS/Android, un pattern comune per garantire che il thread principale dell'app rimanga libero di rispondere agli eventi utente è scaricare le operazioni su thread aggiuntivi. Infatti, nelle ultime versioni di Android, il blocco del thread principale per troppo tempo provoca un 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 di multithreading come quello delle app, ad esempio la memoria condivisa.

Nonostante queste limitazioni, è possibile ottenere un modello 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 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 gli schemi più comuni per utilizzarli nei siti web di produzione.

Web worker e service worker

Analogie

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

Differenze

Si potrebbe pensare che la maggior parte delle attività che possono essere delegate a un web worker possa essere eseguita in un servizio worker e viceversa, ma esistono differenze importanti 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 in base all'ambito con cui è stato registrato.
• La durata del worker web è strettamente associata alla scheda a cui appartiene, mentre il ciclo di vita del worker di servizio è indipendente. Per questo motivo, la chiusura della scheda in cui è in esecuzione un web worker ne comporta l'interruzione, mentre un service worker può continuare a funzionare 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 uno o l'altro:

I casi d'uso per i web worker sono più comunemente correlati al trasferimento di lavoro (ad esempio calcoli pesanti) a un THREAD secondario per evitare di bloccare l'interfaccia utente.

• Esempio: il team che ha creato il videogioco PROXX voleva lasciare il thread principale il più libero possibile per occuparsi dell'input dell'utente e delle animazioni. Per farlo, hanno utilizzato i web worker per eseguire la logica di gioco e la gestione dello stato su un thread separato.

Le attività dei worker di servizio sono in genere più legate al ruolo di proxy di rete, alla gestione delle attività in background e ad aspetti come la memorizzazione nella cache e l'offline.

Esempio: in una PWA di podcast, potresti voler consentire agli utenti di scaricare le puntate complete per ascoltarle offline. A questo scopo, è possibile utilizzare un worker di servizio 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.

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, ne illustreremo due che si occupano rispettivamente di window to web worker e service worker: Comlink e Workbox.

Comlink

Comlink è una piccola (1600) biblioteca RPC che si occupa di molti dettagli di base durante la creazione di siti web che utilizzano i web worker. È stato utilizzato in siti web come PROXX e Squoosh. Qui puoi trovare un riepilogo delle motivazioni e degli esempi di codice.

Workbox

Workbox è una libreria molto utilizzata per creare siti web che utilizzano i worker di servizio. Racchiude una serie di best practice su aspetti come la memorizzazione nella cache, l'offline, la sincronizzazione in background e così via. Il modulo workbox-window fornisce un modo pratico per scambiare messaggi tra il servizio worker e la pagina.

Passaggi successivi

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

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

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