Como os workers da Web e os service workers podem melhorar o desempenho do seu site e quando usar um worker da Web em vez de um service worker.
Esta visão geral explica como os workers da Web e os workers de serviço podem melhorar o desempenho do seu site e quando usar um worker da Web em vez de um worker de serviço. Confira o restante desta série para padrões específicos de comunicação de janelas e service workers.
Como os trabalhadores podem melhorar seu site
O navegador usa uma única linha de execução (a linha de execução principal) para executar todo o JavaScript em uma página da Web, além de realizar tarefas como renderizar a página e executar a coleta de lixo. Executar um código JavaScript excessivo pode bloquear a linha de execução, atrasando a execução dessas tarefas pelo navegador e levando a uma experiência ruim para o usuário.
No desenvolvimento de aplicativos iOS/Android, um padrão comum para garantir que a linha de execução principal do app permaneça livre para responder aos eventos do usuário é transferir as operações para outras linhas de execução. Na verdade, nas versões mais recentes do Android, bloquear a linha de execução principal por muito tempo leva a um erro.
Na Web, o JavaScript foi projetado com base no conceito de uma única linha de execução e não tem os recursos necessários para implementar um modelo de várias linhas de execução, como o dos apps, como memória compartilhada.
Apesar dessas limitações, é possível alcançar um padrão semelhante na Web usando workers para executar scripts em linhas de execução em segundo plano, permitindo que eles realizem tarefas sem interferir na linha de execução principal. Os workers são um escopo JavaScript inteiro em execução em uma linha de execução separada, sem memória compartilhada.
Neste post, você vai aprender sobre dois tipos diferentes de workers (workers da Web e workers de serviço), as semelhanças e diferenças entre eles e os padrões mais comuns para usá-los em sites de produção.

Profissionais da Web e service workers
Semelhanças
Workers da Web e workers de serviço são dois tipos de workers disponíveis para sites. Eles têm algumas coisas em comum:
- Ambos são executados em uma linha de execução secundária, permitindo que o código JavaScript seja executado sem bloquear a linha de execução principal e a interface do usuário.
- Eles não têm acesso aos objetos
Window
eDocument
, então não podem interagir diretamente com o DOM e têm acesso limitado às APIs do navegador.
diferenças
Pode-se pensar que a maioria das coisas que podem ser delegadas a um worker da Web pode ser feita em um worker de serviço e vice-versa, mas há diferenças importantes entre eles:
- Ao contrário dos workers da Web, os workers de serviço permitem interceptar solicitações de rede (pelo evento
fetch
) e detectar eventos da API Push em segundo plano (pelo eventopush
). - Uma página pode gerar vários workers da Web, mas um único service worker controla todas as guias ativas no escopo em que foi registrado.
- A vida útil do worker da Web está intimamente acoplada à guia a que ele pertence, enquanto o ciclo de vida do worker de serviço é independente dela. Por esse motivo, o fechamento da guia em que um worker da Web está em execução vai encerrar ele, enquanto um worker de serviço pode continuar em execução em segundo plano, mesmo quando o site não tem nenhuma guia ativa aberta.
Casos de uso
As diferenças entre os dois tipos de workers sugerem em quais situações é possível usar um ou outro:
Os casos de uso de workers da Web geralmente estão relacionados ao descarregamento de trabalho (como computações pesadas) para uma linha de execução secundária, para evitar o bloqueio da interface.

- Exemplo:a equipe que criou o videogame PROXX queria deixar a linha de execução principal o mais livre possível para cuidar da entrada do usuário e das animações. Para isso, eles usaram workers da Web para executar a lógica do jogo e a manutenção do estado em uma linha de execução separada.

As tarefas de service workers geralmente estão mais relacionadas a atuar como um proxy de rede, processando tarefas em segundo plano e coisas como armazenamento em cache e modo off-line.

Exemplo:em um PWA de podcast, é possível permitir que os usuários faça o download de episódios completos para ouvir off-line. Um worker de serviço e, em particular, a API Background Fetch podem ser usados para esse fim. Dessa forma, se o usuário fechar a guia enquanto o episódio está sendo transferido, a tarefa não precisa ser interrompida.

Ferramentas e bibliotecas
A comunicação entre janelas e workers pode ser implementada usando diferentes APIs de nível inferior. Felizmente, há bibliotecas que abstraem esse processo, cuidando dos casos de uso mais comuns. Nesta seção, vamos abordar duas delas que cuidam de workers da janela para workers da Web e workers de serviço, respectivamente: Comlink e Workbox.

Comlink
A Comlink é uma biblioteca RPC pequena (1,6 mil) que cuida de muitos detalhes subjacentes ao criar sites que usam Web Workers. Ele foi usado em sites como PROXX e Squoosh. Confira aqui um resumo das motivações e exemplos de código.
Workbox
A Workbox é uma biblioteca conhecida para criar sites
que usam workers de serviço. Ele empacota um conjunto de práticas recomendadas em torno de coisas como armazenamento em cache, off-line,
sincronização em segundo plano etc. O módulo workbox-window
oferece uma
maneira conveniente de trocar mensagens entre o service worker e a página.
Próximas etapas
O restante desta série se concentra em padrões de comunicação de janelas e service workers:
- Guia de armazenamento em cache imperativo: chamar um service worker da página para armazenar recursos em cache com antecedência (por exemplo, em cenários de pré-carregamento).
- Atualizações de transmissão: chamar a página do service worker para informar sobre atualizações importantes (por exemplo, uma nova versão do site está disponível).
- Comunicação bidirecional: delegar uma tarefa a um worker de serviço (por exemplo, um download pesado) e manter a página informada sobre o progresso.
Para padrões de comunicação de janela e worker da Web, confira: Usar workers da Web para executar JavaScript fora da linha de execução principal do navegador.