Dez milissegundos parecem pouco para um site que consulta banco de dados, autentica usuários e monta páginas. Nos meus projetos, essa conta mudou quando passei a medir o trabalho feito pelo Worker e a separar o que pode acontecer no navegador, no cache, no R2 e no banco de dados.
No Workers Free, o limite de CPU por requisição HTTP é 10 ms. Ele mede o tempo de processamento do código do Worker; o tempo aguardando uma chamada de rede não entra nessa medida. Para ficar dentro do limite, reduza o trabalho no servidor, faça consultas menores, use cache e leve ao navegador cálculos que não precisam de proteção no back-end.
O que o limite de 10 ms mede
O Workers Free permite até 10 milissegundos de CPU por requisição HTTP. Esse número mede o tempo em que o Worker executa o próprio código. A espera por uma chamada de rede, como fetch() ou uma consulta ao banco de dados, não entra nessa contagem. Ainda assim, muitas subconsultas ou uma resposta difícil de processar podem acrescentar trabalho ao Worker.
O plano também tem outros limites. A documentação consultada em novembro de 2026 informa até 100 mil requisições por dia no Free e até 50 subrequests por invocação. D1 e R2 têm cotas próprias. Acompanhe os números atuais na documentação de limites do Workers; valores de plano podem mudar.
Deixe o navegador fazer o trabalho que cabe a ele
Uma aplicação de página única (SPA) entrega a interface e executa parte da lógica no navegador de quem visita. Isso reduz o processamento no Worker quando a tarefa é interativa e pode usar os recursos locais do dispositivo. Um editor, uma calculadora ou um mapa com filtros simples pode fazer vários cálculos no cliente, enquanto o servidor entrega os dados necessários.
Essa escolha depende do tipo de informação. Um painel fechado para usuários pode funcionar bem com conteúdo carregado depois da entrada. Uma página pública que precisa aparecer em buscas pode se beneficiar da renderização do HTML no servidor (SSR). Eu uso SSR onde o HTML inicial precisa trazer o conteúdo e deixo a interação no navegador quando ela não precisa de uma execução protegida no servidor.
Não coloque no navegador segredos, chaves privadas, regras de acesso ou dados que o cliente não pode alterar. O visitante pode inspecionar o código enviado ao navegador e modificar chamadas locais. Valide no Worker toda operação que protege conta, pagamento ou conteúdo privado.
Reduza consultas e evite processar os mesmos dados
Quando uma página precisa de dados externos, use cache para respostas que podem ser reaproveitadas. Se o Worker pede a mesma informação repetidas vezes e transforma tudo de novo, cada etapa adiciona processamento. Também evite carregar dezenas de milhares de linhas para exibir apenas uma página de resultados.
No D1, índices e paginação ajudam a limitar o trabalho e as linhas lidas. A tabela atual do plano Free inclui 5 milhões de linhas lidas e 100 mil linhas escritas por dia, além de 5 GB de armazenamento. Ao atingir o limite diário, as consultas podem falhar até a cota renovar. Confira métricas no painel e ajuste as consultas antes de aumentar o tráfego.
Uma chamada de API externa não gasta o tempo de CPU enquanto o Worker espera pela resposta, mas ainda usa uma subrequest. A resposta também precisa ser lida e processada. Portanto, escolha serviços externos por função e disponibilidade, não como uma forma automática de eliminar custos ou limites.
Use o R2 para arquivos e conteúdo conhecido
O R2 guarda imagens, Markdown e JSON sem exigir que cada arquivo esteja dentro do build do site. Uma página pode buscar um objeto pela chave e o catálogo pode carregar um índice preparado. Isso ajuda a publicar conteúdo sem reconstruir todas as páginas e evita varrer o bucket em cada visita.
R2 e D1 têm trabalhos diferentes. R2 é armazenamento de objetos; não substitui consultas relacionais quando você precisa filtrar muitos campos ou atualizar registros de usuários. Eu uso arquivo para dados que o site localiza por um caminho conhecido e banco de dados para cadastros e informações que pedem consulta ou escrita frequente.
As cotas do R2 também são separadas. O nível Standard tem 10 GB-mês, 1 milhão de operações Classe A e 10 milhões de Classe B incluídos por mês. Leituras de objetos entram em Classe B; listar objetos e gravá-los entram em Classe A. Veja a tabela de preços do R2 antes de dimensionar um catálogo grande.
Divida as tarefas por função, sem criar etapas inúteis
Um projeto pode usar um Worker para as páginas, o R2 para mídia, D1 para dados consultáveis e KV ou Cache para valores que precisam de leitura rápida. Separar serviços ajuda a escolher o recurso certo para cada tarefa. Dividir uma única operação em vários Workers só para evitar medir o processamento pode adicionar chamadas e complexidade; comece pelo desenho da função e meça o resultado.
Também vale evitar bibliotecas e frameworks que o projeto não precisa. Dependências podem aumentar o pacote e adicionar trabalho ao processamento. Isso não significa que todo framework passe do limite: meça uma rota real, acompanhe o tempo de CPU e retire o que não traz valor para o projeto.
Meus projetos mostram que dá para fazer mais com menos
No vídeo, mostrei rotas de projetos que eu já uso. O Item Maps ficava perto de 2 ms em média; outros projetos variavam entre 3 e 7 ms conforme a tarefa. São medições que vi nos meus próprios painéis durante a gravação, não uma garantia de que qualquer site terá o mesmo resultado. Bots, rotas diferentes e picos de uso podem alterar a conta.
Também mostrei páginas com SSR, contas de usuário, mapas, filtros e conteúdo em vários idiomas. O ponto para mim é medir cada rota e não mandar para o Worker tudo o que o navegador consegue executar. Uma página pública pode precisar de HTML renderizado pelo servidor; um mapa interativo pode deixar a interação para o cliente.
Quando faz sentido passar para o Workers Paid
Se o projeto precisa de mais CPU, armazenamento, leitura do banco ou requisições do que o plano Free oferece, o plano pago pode ser a decisão mais simples. A Cloudflare lista um preço mínimo de US$ 5 por conta e limites ampliados; confira a página de preços antes de estimar o custo mensal.
Eu recomendo otimizar o que está medindo consumo alto, mas também recomendo pagar quando o projeto depende de capacidade maior. Uma aplicação comercial que já tem usuários e receita pode valer mais do que o custo de reduzir cada consulta ao extremo. Faça a conta pelo uso real e acompanhe o painel depois da mudança.
O que conferir
- Meça CPU por rota no painel da Cloudflare.
- Mova para o navegador apenas tarefas que não precisam de proteção no servidor.
- Use cache, índices e paginação para evitar processamento repetido.
- Acompanhe também as cotas de requisições, D1 e R2.
O que pode dar errado
Confundir o limite de CPU com o tempo total de espera de uma requisição.
Expor segredos ou confiar no navegador para proteger dados privados.
Supor que chamadas externas não têm nenhum limite ou custo.
Dividir o código em Workers sem medir se isso reduz o trabalho.
Perguntas frequentes
O Workers Free tem mesmo um limite de 10 ms?
Sim. No limite atual, uma requisição HTTP pode usar até 10 ms de CPU no plano Free. A espera por chamadas de rede não entra nessa medida.
Consultas ao D1 contam como CPU do Worker?
O tempo aguardando a resposta do banco não entra no CPU time do Worker. A consulta ainda tem limites próprios de linhas lidas, linhas escritas e armazenamento.
Devo processar tudo no navegador para ficar abaixo de 10 ms?
Não. Leve ao navegador apenas o que pode ser executado com segurança no cliente. Autorização, segredos e operações protegidas continuam no servidor.
Quando vale pagar pelo Workers?
Quando o projeto precisa de mais capacidade, passa a atingir limites ou o custo do plano pago é menor que o esforço de reduzir cada operação. Compare o uso real com os limites atuais.
