Como os web workers e os service workers podem melhorar o desempenho do seu site e quando usar um web worker em vez de um service worker.
Esta visão geral explica como os workers da Web e de serviço podem melhorar o desempenho do seu site e quando usar cada um deles. Confira o restante desta série para padrões específicos de comunicação de janela e service worker.
Como os workers 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 fazer a coleta de lixo. A execução de código JavaScript em excesso pode bloquear a linha de execução principal, atrasando a execução dessas tarefas pelo navegador e prejudicando a experiência do usuário.
No desenvolvimento de apps para iOS/app 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. Nas versões mais recentes do Android, bloquear a linha de execução principal por muito tempo faz com que o app falhe.
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 a memória compartilhada.
Apesar dessas limitações, um padrão semelhante pode ser alcançado 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.
Nesta postagem, você vai conhecer dois tipos diferentes de workers (web workers e service workers), as semelhanças e diferenças entre eles e os padrões mais comuns para usá-los em sites de produção.
Web workers e service workers
Semelhanças
Web workers e service workers 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
WindoweDocument. Por isso, não podem interagir diretamente com o DOM e têm acesso limitado às APIs do navegador.
diferenças
Pode parecer que a maioria das coisas que podem ser delegadas a um web worker também podem ser feitas em um service worker e vice-versa, mas há diferenças importantes entre eles:
- Ao contrário dos workers da Web, os service workers 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 ligada à guia a que ele pertence, enquanto o ciclo de vida do service worker é independente dela. Por isso, fechar a guia em que um worker da Web está em execução vai encerrá-lo, enquanto um service worker pode continuar em execução em segundo plano, mesmo quando o site não tem guias ativas abertas.
Casos de uso
As diferenças entre os dois tipos de workers sugerem em quais situações é melhor usar um ou outro:
Os casos de uso de workers da Web geralmente estão relacionados à transferência 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 (link em inglês) 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, processar tarefas em segundo plano e coisas como armazenamento em cache e modo off-line.
Exemplo: em um PWA de podcast, talvez você queira permitir que os usuários baixem episódios completos para ouvir off-line. Um service worker e, em particular, a API Background Fetch podem ser usados para essa finalidade. Assim, se o usuário fechar a guia enquanto o episódio estiver sendo baixado, a tarefa não será interrompida.
Ferramentas e bibliotecas
A comunicação entre janelas e workers pode ser implementada usando diferentes APIs de nível inferior. Felizmente, existem bibliotecas que abstraem esse processo, cuidando dos casos de uso mais comuns. Nesta seção, vamos abordar duas delas que cuidam da janela para workers da Web e service workers, respectivamente: Comlink e Workbox.
Comlink
Comlink é uma pequena biblioteca RPC (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. Um resumo das motivações e exemplos de código podem ser encontrados aqui.
Workbox
A Workbox é uma biblioteca conhecida para criar sites
que usam service workers. Ele empacota um conjunto de práticas recomendadas para armazenamento em cache, sincronização em segundo plano,
modo off-line 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 para comunicação entre 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é-busca).
- Transmitir atualizações: 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 service worker (por exemplo, um download pesado) e manter a página informada sobre o progresso.
Para padrões de comunicação de janelas e workers da Web, confira: Usar workers da Web para executar JavaScript fora da linha de execução principal do navegador.