Web Workers vs Service Workers: o que são e por que usá-los

Web Workers vs Service Workers: o que são e por que usá-los

Os navegadores executam a maior parte do seu JavaScript na thread principal — o mesmo lugar que lida com entrada do usuário, animações e a pintura da página. Quando trabalho pesado acontece ali (parsing de grandes volumes de dados, processamento de imagens, cálculos complexos), a interface pode travar ou “congelar”. Os workers existem para mover certas tarefas para fora da thread principal ou fora do controle direto da página, para que sua app continue responsiva.

O problema que os workers resolvem

Se sua página está ocupada fazendo uma computação de 200ms, o navegador não consegue rolar suavemente, responder a cliques ou manter animações a 60fps. Workers ajudam permitindo que você execute trabalho em segundo plano enquanto a thread principal foca na interface.

Definições rápidas

Um Web Worker é uma thread JavaScript em segundo plano que você cria a partir de uma página. É ideal para tarefas pesadas de CPU que, de outra forma, bloqueariam a UI.

Um Service Worker é um tipo especial de worker que fica entre sua web app e a rede. Ele pode interceptar requisições, armazenar respostas em cache e habilitar recursos como suporte offline e notificações push.

Um modelo mental simples: “threads” vs “proxy de rede”

Pense em um Web Worker como um ajudante fazendo cálculos em outra sala. Você envia uma mensagem, ele processa e responde.

Pense em um Service Worker como um guarda na porta. Requisições por páginas, scripts e chamadas de API passam por ele, e ele pode decidir buscar da rede, servir do cache ou responder de forma personalizada.

O que você vai aprender neste artigo

Ao final, você saberá:

• quando um web worker é a ferramenta certa para performance (e o que ele não pode acessar)
• o que um service worker possibilita para cache offline, atualizações e comportamento de PWA
• como a comunicação (como postMessage) se encaixa no modelo de workers, e por que a Cache Storage API importa para o modo offline

Esta visão estabelece o “porquê” e o modelo mental — a seguir vamos nos aprofundar em como cada tipo de worker se comporta e onde se encaixa em projetos reais.

Por que os navegadores têm workers em primeiro lugar

Quando você abre uma página web, a maior parte do que você “sente” acontece na thread principal. Ela é responsável por desenhar pixels (renderização), reagir a toques e cliques (entrada) e executar muito do JavaScript.

A thread principal é uma fila compartilhada

Porque renderização, tratamento de entrada e JavaScript frequentemente revezam na mesma thread, uma tarefa lenta pode fazer todo o resto esperar. É por isso que problemas de performance tendem a se manifestar como problemas de responsividade, não apenas “código lento”.

Como o bloqueio se apresenta para os usuários:

• Rolagem com travamentos (jank)
• Botões não respondem a cliques de imediato
• Digitação acompanha com atraso o teclado
• Animações congelam por um momento

Assíncrono não é o mesmo que paralelismo

JavaScript tem muitas APIs assíncronas — fetch(), timers, eventos — que ajudam a evitar espera ativa. Mas assíncrono não faz o trabalho pesado rodar ao mesmo tempo que a renderização.

Se você fizer computação cara (processamento de imagem, parsing de JSON grande, criptografia, filtragem complexa) na thread principal, ela ainda competirá com as atualizações de UI. “Assíncrono” pode adiar quando algo roda, mas pode continuar executando na mesma thread principal e causar jank quando ocorrer.

Onde os workers se encaixam na arquitetura do navegador

Workers existem para que os navegadores mantenham a página responsiva enquanto ainda fazem trabalho significativo.

• Web Workers permitem executar JavaScript em uma thread de fundo para tarefas pesadas de CPU.
• Service Workers rodam separadamente de qualquer página, atuando mais como uma camada de rede e cache que pode funcionar mesmo quando a página não está aberta.

Em suma: workers protegem a thread principal para que sua app continue interativa enquanto realiza trabalho real em segundo plano.

O que é um Web Worker?

Um Web Worker é uma forma de executar JavaScript fora da thread principal. Em vez de competir com o trabalho de UI (renderização, rolagem, resposta a cliques), um worker roda em sua própria thread de fundo para que tarefas pesadas terminem sem fazer a página parecer “presa”.

Pense nele como: a página permanece focada na interação do usuário, enquanto o worker trata tarefas pesadas de CPU como parsing de arquivos grandes, cálculos ou preparação de dados para gráficos.

Onde ele roda

Um Web Worker roda em uma thread separada com seu próprio escopo global. Ele ainda tem acesso a muitas APIs web (timers, fetch em vários navegadores, crypto, etc.), mas é propositalmente isolado da página.

Dedicated Worker vs Shared Worker

Existem algumas variantes comuns:

• Dedicated Worker: conectado a uma única página/aba. Quando essa página some, o worker normalmente é terminado.
• Shared Worker: pode ser compartilhado por múltiplas páginas/abas da mesma origem, útil para coordenar trabalho entre abas (por exemplo, compartilhar uma única conexão ou sincronizar estado).

Se você nunca usou workers antes, a maioria dos exemplos mostra Dedicated Workers.

Como os Web Workers se comunicam

Workers não chamam funções da sua página diretamente. A comunicação acontece por mensagens:

• A página envia dados ao worker com postMessage().
• O worker responde também com postMessage().
• Os dados são transferidos usando o algoritmo structured clone, que suporta muitos tipos nativos (objetos, arrays, strings, números, Maps/Sets, ArrayBuffers, e mais).

Para dados binários grandes, você pode melhorar a performance transferindo a propriedade de um ArrayBuffer (assim ele não é copiado), mantendo a passagem de mensagens rápida.

Limites comuns (por projeto)

Porque um worker é isolado, há algumas restrições importantes:

• Sem acesso direto ao DOM: um worker não pode ler ou modificar o HTML, CSS ou layout da página.
• Globais diferentes: você não tem window ou document. Workers rodam sob self (um escopo global de worker), e as APIs disponíveis podem diferir da página principal.
• Mentalidade assíncrona: como tudo é baseado em mensagens, você organiza seu código em torno de enviar trabalho e receber resultados.

Usado corretamente, um Web Worker é uma das maneiras mais simples de melhorar o desempenho da thread principal sem mudar o que sua app faz — apenas onde o trabalho caro acontece.

Quando usar Web Workers (e quando não usar)

Web Workers são ótimos quando sua página fica “presa” porque o JavaScript está fazendo trabalho demais na thread principal. A thread principal também é responsável por interações do usuário e renderização, então tarefas pesadas ali podem causar jank, cliques atrasados e rolagem congelada.

Casos ideais para Web Workers

Use um Web Worker quando você tem trabalho pesado de CPU que não precisa de acesso direto ao DOM:

• Cálculos pesados: simulações, computação numérica, crunching de dados.
• Parsing e transformação: parsing de JSON grande, parsing de CSV, validação de esquema.
• Compressão / descompressão: workloads estilo zip/gzip, codificação/decodificação.
• Processamento de imagem: redimensionamento, filtros, geração de thumbnails (frequentemente combinado com OffscreenCanvas em navegadores que suportam).

Um exemplo prático: se você recebe um payload JSON grande e o parsing causa stutter na UI, mova o parsing para um worker e envie o resultado de volta.

Dicas de manipulação de dados (para velocidade)

A comunicação com um worker acontece via postMessage. Para dados binários grandes, prefira objetos transferíveis (como ArrayBuffer) para que o navegador transfira a propriedade de memória ao worker em vez de copiá-la.

// main thread
worker.postMessage(buffer, [buffer]); // transfere o ArrayBuffer

Isso é especialmente útil para buffers de áudio, bytes de imagem ou outros grandes blocos de dados.

Quando não usar Web Workers

Workers têm overhead: arquivos extras, passagem de mensagens e fluxo de depuração diferente. Evite-os quando:

• A tarefa é pequena (milissegundos) e ocorre raramente.
• O trabalho requer leituras/escritas frequentes no DOM (workers não podem tocar o DOM).
• Você precisa de latência ultrabaixa em ida e volta; ping-pong constante com postMessage pode anular o benefício.

Regra prática

Se uma tarefa pode causar uma pausa perceptível (frequentemente ~50ms+) e pode ser expressa como “entrada → computação → saída” sem acesso ao DOM, um Web Worker geralmente vale a pena. Se for principalmente atualizações de UI, mantenha na thread principal e otimize lá.

O que é um Service Worker?

Um Service Worker é um arquivo JavaScript especial que roda em segundo plano no navegador e atua como uma camada de rede programável para seu site. Em vez de rodar na própria página, ele fica entre sua web app e a rede, permitindo decidir o que acontece quando a app solicita recursos (HTML, CSS, chamadas de API, imagens).

Noções básicas do ciclo de vida (register → install → activate → control)

Um Service Worker tem um ciclo de vida separado de qualquer aba:

• Register: a página informa ao navegador “este site tem um service worker” (normalmente a partir do seu JS principal).
• Install: o navegador faz o download e executa a etapa de install, frequentemente usada para pré-cache de arquivos importantes.
• Activate: o novo worker assume, tipicamente após fechar abas antigas ou quando é seguro substituir uma versão anterior.
• Control: uma vez ativo, ele pode “controlar” páginas dentro do seu escopo e começar a interceptar requisições.

Como ele pode ser parado e reiniciado a qualquer momento, trate-o como um script orientado a eventos: faça trabalho rápido, armazene estado em armazenamento persistente e evite supor que ele está sempre em execução.

Regras de escopo e origem (em alto nível)

Service Workers são limitados à mesma origem (mesmo domínio/protocolo/porta) e controlam apenas páginas sob seu escopo — normalmente a pasta onde o arquivo do worker é servido (e abaixo dela). Eles também exigem HTTPS (exceto localhost) porque podem afetar requisições de rede.

APIs que você verá com frequência

• Fetch event: intercepta requisições e decide usar rede, cache ou uma resposta customizada.
• Cache Storage API: armazena e recupera respostas em cache para uso offline e velocidade.
• Clients API: comunica-se com e gerencia abas/janelas abertas que seu worker controla.

Para que Service Workers são usados

Um Service Worker é usado principalmente para ficar entre sua web app e a rede. Ele pode decidir quando usar a rede, quando usar dados em cache e quando fazer algum trabalho em segundo plano — sem bloquear a página.

Suporte offline (cache inteligente)

A tarefa mais comum é habilitar experiências offline ou em conexões ruins, fazendo cache de assets e respostas.

Algumas estratégias práticas de cache:

• Cache-first: ótimo para arquivos estáticos (CSS, JS, logos). Rápido, funciona offline.
• Network-first: bom para conteúdo que muda com frequência (notícias, feeds). Recorre ao cache quando offline.
• Stale-while-revalidate: exibe conteúdo em cache imediatamente e atualiza em segundo plano para a próxima vez.

Geralmente isso é implementado com a Cache Storage API e manipulação do evento fetch.

Visitas repetidas mais rápidas

Service Workers podem melhorar a percepção de velocidade em visitas de retorno por:

• Precaching: salvar os arquivos essenciais do app durante a instalação (frequentemente chamado de app shell).
• Runtime caching: cachear páginas ou respostas de API conforme o usuário navega.

O resultado é menos requisições de rede, inicialização mais rápida e performance mais consistente em conexões instáveis.

Recursos em segundo plano (quando suportado)

Service Workers podem alimentar funcionalidades de background como push notifications e background sync (suporte varia por navegador/plataforma). Isso significa que você pode notificar usuários ou reenviar uma requisição falhada mais tarde — mesmo que a página não esteja aberta.

Blocos de construção para PWA

Se você está construindo um progressive web app, Service Workers são uma peça central por trás de:

• Instalabilidade (em conjunto com o web app manifest)
• Páginas offline confiáveis (por exemplo, um fallback amigável)
• O modelo app shell para navegação rápida

Diferenças-chave: Web Worker vs Service Worker

Se lembrar de apenas uma coisa: Web Workers ajudam sua página a fazer trabalho pesado sem congelar a UI, enquanto Service Workers ajudam sua app a controlar requisições de rede e se comportar como um app instalável (PWA).

Onde eles rodam (para que servem)

Um Web Worker é para tarefas pesadas de CPU — parsing de grandes dados, gerar thumbnails, crunching de números — para que a thread principal permaneça responsiva.

Um Service Worker é para manuseio de requisições e tarefas do ciclo de vida da app — suporte offline, estratégias de cache, background sync e push notifications. Ele pode ficar entre sua app e a rede.

Tempo de vida e “quem o possui”

Um Web Worker normalmente está vinculado à página/aba. Quando a página some, o worker geralmente também some (a menos que você use casos especiais como SharedWorker).

Um Service Worker é orientado a eventos. O navegador pode iniciá-lo para lidar com um evento (como fetch ou push) e encerrá-lo quando ocioso. Isso significa que ele pode rodar mesmo quando nenhuma aba está aberta, desde que um evento o desperte.

Acesso e controle da rede

Um Web Worker não pode interceptar requisições da página. Ele pode usar fetch() para buscar dados, mas não pode reescrever, cachear ou servir respostas para outras partes do seu site.

Um Service Worker pode interceptar requisições de rede (via evento fetch), decidir se vai à rede, responder do cache ou retornar um fallback.

Armazenamento e cache

Um Web Worker não gerencia o cache HTTP da sua app.

Um Service Worker usa comumente a Cache Storage API para armazenar e servir pares requisição/resposta — isso é a base para cache offline e carregamentos “instantâneos” em visitas repetidas.

Como configurá-los (passos em alto nível)

Colocar um worker para rodar é principalmente sobre onde ele roda e como é carregado. Web Workers são criados diretamente por um script de página. Service Workers são registrados por uma página que o navegador então instala e que fica “à frente” das requisições de rede do seu site.

Web Worker: crie a partir da sua página

Um Web Worker nasce quando sua página cria um. Você aponta para um arquivo JavaScript separado e se comunica via postMessage.

// main.js (running on the page)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });

worker.postMessage({ action: 'start', payload: { /* ... */ } });

worker.onmessage = (event) => {
  console.log('From worker:', event.data);
};

Um bom modelo mental: o arquivo do worker é apenas outra URL de script que sua página pode buscar, mas que roda fora da thread principal.

Service Worker: registre-o (uma vez) e deixe o navegador instalar

Service Workers devem ser registrados a partir de uma página que o usuário visite:

// main.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Após o registro, o navegador cuida do ciclo install/activate. Seu sw.js pode ouvir eventos como install, activate e fetch.

Por que Service Workers exigem HTTPS

Service Workers podem interceptar requisições e cachear respostas. Se o registro fosse permitido via HTTP, um atacante na rede poderia injetar um sw.js malicioso e efetivamente controlar visitas futuras. HTTPS (ou http://localhost para desenvolvimento) protege o script e o tráfego que ele pode influenciar.

Mentalidade de versionamento: trate arquivos de worker como "releases" implantáveis

Navegadores cacheiam e atualizam workers de forma diferente de scripts normais de página. Planeje atualizações:

• Mude o arquivo quando o comportamento mudar (frequentemente implantando um novo sw.js/bundle do worker).
• Em Service Workers, espere um fluxo de “atualização”: um novo worker instala e então ativa quando for seguro.
• Ao mudar regras de cache, inclua lógica de limpeza durante a ativação para que caches antigos não permaneçam.

Se quiser uma estratégia de rollout mais suave, veja /blog/debugging-workers para hábitos de teste que pegam casos de atualização cedo.

Depuração e testes de workers no navegador

Workers falham de maneiras diferentes do JavaScript “normal” de página: rodando em contextos separados, com seu próprio console, e podendo ser reiniciados pelo navegador. Uma rotina sólida de depuração economiza horas.

Depurando Web Workers (DevTools)

Abra o DevTools e procure alvos específicos de worker. No Chrome/Edge, você frequentemente verá workers listados em Sources (ou via a entrada “Dedicated worker”) e no seletor de contexto do Console.

Use as mesmas ferramentas da thread principal:

• Logs no console: logs de um Web Worker aparecem no DevTools, mas verifique se você está no contexto correto.
• Breakpoints: coloque breakpoints dentro do script do worker; percorra handlers de onmessage e funções de longa execução.
• Profiling de performance: grave um trace de Performance e verifique se a thread principal permanece responsiva enquanto o worker faz o trabalho pesado.

Se mensagens parecem “perdidas”, inspecione ambos os lados: verifique se você está chamando worker.postMessage(...), se o worker tem self.onmessage = ..., e se a forma da mensagem bate entre os dois.

Depurando Service Workers (painel Application)

Service Workers são melhor depurados no painel Application:

• Cheque o status do registro, escopo e as versões active/waiting/installed.
• Use controles de ciclo de vida como Skip waiting e Unregister para resetar um estado ruim.
• Habilite Update on reload para evitar perseguir código desatualizado durante iterações.

Também observe o Console para erros de install/activate/fetch — eles frequentemente explicam porque o cache ou o comportamento offline não funcionam.

Armadilhas comuns e dicas de teste

Problemas de cache são o maior sorvedouro de tempo: cachear os arquivos errados (ou com muita agressividade) pode manter HTML/JS antigos. Durante testes, faça hard reload e confirme o que está sendo servido do cache.

Para testes realistas, use o DevTools para:

• simular modo Offline e verificar páginas de fallback
• aplicar throttling de rede
• recarregar várias vezes para validar atualizações de Service Worker e manipulação de mensagens

Se você está iterando rápido em um PWA, pode ajudar gerar um app base limpo (com um Service Worker e output de build previsíveis) e então refinar estratégias de cache. Plataformas como Koder.ai podem ser úteis para esse tipo de experimentação: você pode prototipar um app React a partir de um prompt de chat, exportar o código e ajustar os workers e regras de cache com um ciclo de feedback mais rápido.

Considerações de segurança, privacidade e performance

Workers podem deixar apps mais suaves e capazes, mas também mudam onde o código roda e o que ele pode acessar. Uma checagem rápida em segurança, privacidade e performance evita bugs-surpresa — e usuários insatisfeitos.

Limites de segurança (e por que same-origin importa)

Tanto Web Workers quanto Service Workers são restritos pela política de mesma origem: eles só podem interagir diretamente com recursos da mesma scheme/host/porta (a menos que o servidor permita acesso cross-origin via CORS). Isso evita que um worker puxe silenciosamente dados de outro site e misture na sua app.

Service Workers têm proteções adicionais: geralmente exigem HTTPS (ou localhost no desenvolvimento) porque podem interceptar requisições de rede. Trate-os como código privilegiado: mantenha dependências mínimas, evite carregar código dinamicamente e versionar a lógica de cache com cuidado para que caches antigos não sigam servindo arquivos desatualizados.

Privacidade e expectativas do usuário

Recursos em segundo plano devem ser previsíveis. Push notifications são poderosas, mas prompts de permissão são fáceis de abusar.

Peça permissão apenas quando houver um benefício claro (por exemplo, depois que o usuário habilitar alertas nas configurações) e explique o que será recebido. Se você sincroniza ou pré-busca dados em background, comunique isso de forma clara — usuários notam atividade de rede inesperada ou notificações.

Riscos de performance a observar

Workers não são “performance grátis”. Usá-los em excesso pode ter efeito contrário:

• Overhead de mensagens: chamadas frequentes a postMessage (especialmente com objetos grandes) podem se tornar gargalos. Prefira agrupar e usar objetos transferíveis quando apropriado.
• Custo de memória: cada worker tem sua própria memória e overhead de inicialização; muitos workers podem aumentar uso de RAM e consumo de bateria.
• Crescimento do cache: um Service Worker que cacheia agressivamente pode inchar o armazenamento. Adicione limites de cache e limpeza durante atualizações.

Fallback gracioso

Nem todo navegador suporta todas as capacidades (ou usuários podem bloquear permissões). Faça feature-detect e degrade de forma limpa:

if ('serviceWorker' in navigator) {
  // register service worker
} else {
  // continue without offline features
}

O objetivo: a funcionalidade principal deve continuar funcionando, com “extras” (offline, push, computação pesada) adicionados quando disponíveis.

Padrões comuns que usam ambos juntos

Web Workers e Service Workers resolvem problemas diferentes, então eles se complementam bem quando uma app precisa tanto de computação pesada quanto de carregamento rápido e confiável. Um bom modelo mental é: Web Worker = computação, Service Worker = rede + cache, thread principal = UI.

Padrão 1: Processamento de imagem + galeria offline

Imagine uma app que permite editar fotos (redimensionar, filtros, remoção de fundo) e ver uma galeria depois sem conexão.

• Um Web Worker faz o trabalho pesado de CPU (decodificar, transformar, gerar thumbnails) para que rolagem e toques permaneçam suaves.
• Um Service Worker cacheia as thumbnails e os originais na Cache Storage (ou metadados no IndexedDB) e os serve instantaneamente em visitas repetidas ou offline.

Essa abordagem “computar e depois cachear” mantém responsabilidades claras: o worker gera saídas e o service worker decide como armazená-las e servi-las.

Padrão 2: Sincronização de dados + cache em segundo plano

Para apps com feeds, formulários ou dados de campo:

• Um Web Worker pode normalizar grandes payloads JSON, executar diffing ou validar dados sem bloquear a UI.
• Um Service Worker pode cachear respostas de API para inicialização rápida e lidar com leituras offline. Quando a conectividade retornar, ele pode atualizar caches e (quando suportado) coordenar background sync.

Mesmo sem sync de background completo, um service worker ainda melhora a velocidade percebida ao servir respostas cacheadas enquanto a app atualiza em segundo plano.

Manter responsabilidades separadas

Evite misturar papéis:

• Thread de UI: renderização, entrada do usuário, acessibilidade, wiring mínimo de estado.
• Web Worker: computação pura e preparação de dados (frequentemente via postMessage).
• Service Worker: roteamento de requisições, estratégia de cache, fallbacks offline.

Checklist rápido: qual você precisa?

• A tarefa é pesada em CPU (parsing, encoding, crypto, processamento de imagem/áudio)? Use um Web Worker.
• A tarefa é sobre interceptar fetch, comportamento offline ou cache? Use um Service Worker.
• Precisa de UI rápida e carregamento/offline rápido? Use ambos, mas mantenha o limite claro: compute no web worker, armazene/serve via service worker.

FAQ: perguntas práticas que as pessoas fazem

Um Service Worker pode acessar o DOM?

Não. Um Service Worker roda em segundo plano, separado de qualquer aba de página, e não tem acesso direto ao DOM (os elementos HTML da página).

Essa separação é intencional: Service Workers foram projetados para continuar funcionando mesmo quando nenhuma página está aberta (por exemplo, para responder a um evento de push ou servir arquivos em cache). Como pode não haver nenhum documento ativo para manipular, o navegador mantém esse isolamento.

Se um Service Worker precisa afetar o que o usuário vê, ele se comunica com as páginas via mensagens (por exemplo, postMessage) para que a página atualize a UI.

Eu preciso de um Service Worker para usar um Web Worker?

Não. Web Workers e Service Workers são independentes.

• Web Worker: mova trabalho pesado de JavaScript para fora da thread principal (parsing, cálculos, processamento de imagem) para manter a UI responsiva.
• Service Worker: recursos em nível de rede (offline, cache, interceptação de requisições, push/background sync).

Você pode usar apenas um, ou ambos quando sua app precisar de computação e funcionalidades de rede/offline.

Workers são suportados em todos os navegadores?

Em navegadores modernos, Web Workers têm amplo suporte e costumam ser a escolha “base”.

Service Workers também são amplamente suportados nas versões atuais dos principais navegadores, mas há mais requisitos e casos de borda:

• Eles exigem HTTPS (exceto localhost para desenvolvimento).
• Algumas funcionalidades (como push notifications) variam por navegador e plataforma.

Se compatibilidade ampla for importante, trate Service Worker como aprimoramento progressivo: construa uma boa experiência central primeiro e adicione offline/push quando disponível.

Isso vai deixar meu site mais rápido automaticamente?

Não automaticamente.

• Um Web Worker ajuda quando seu site é desacelerado por JavaScript pesado na thread principal. Mover esse trabalho pode reduzir jank e melhorar responsividade — mas você ainda paga overhead para enviar dados de ida e volta.
• Um Service Worker ajuda quando seu site é lento por conta de requisições de rede. Cache e manipulação inteligente de fetch podem fazer visitas repetidas parecerem instantâneas — mas cachear coisas erradas pode provocar conteúdo obsoleto.

Os ganhos reais vêm de usar o worker certo para o gargalo certo, e medir antes e depois.