Visão geral dos workers

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.

Andrew Guan
Andrew Guan
Demián Renzulli
Demián Renzulli

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.

Diagrama mostrando dois links entre o objeto Window e um worker da Web e um worker de serviç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 e Document, 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 evento push).
  • 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.

Diagrama mostrando uma vinculação do objeto Window a um worker da Web.
  • 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.
Captura de tela do videogame PROXX.

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.

Captura de tela do videogame PROXX.

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.

Captura de tela de um PWA de podcast.
A interface é atualizada para indicar o progresso de um download (à esquerda). Graças aos service workers, a operação pode continuar sendo executada quando todas as guias forem fechadas (à direita).

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.

Captura de tela do videogame PROXX.

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.