GitHub

A maioria dos tutoriais sobre Cloudflare Workers e Pages faz a comparação errada. Coloca os dois como concorrentes diretos, como se você tivesse que escolher entre um framework e outro. Workers e Pages resolvem problemas diferentes em camadas diferentes — e escolher sem entender essa distinção cria arquiteturas que ficam caras ou que exigem refatoração em seis meses.

O que cada um é, de fato

Workers é uma plataforma de computação. Você escreve código, faz deploy com wrangler deploy, e esse código executa em V8 isolates distribuídos pela rede da Cloudflare — atualmente em mais de 300 pontos de presença. O modelo de execução é event-driven: cada requisição HTTP, mensagem de fila, trigger de cron ou handler de e-mail gera uma invocação. Cold start fica abaixo de 1ms porque V8 isolates compartilham o mesmo processo, ao contrário de containers que sobem do zero.

Pages é uma plataforma de hospedagem. O caso central é: você tem um site ou SPA, faz git push, a Cloudflare roda seu build (npm run build, Hugo, Astro, o que for), e os assets estáticos resultantes são distribuídos pelo CDN global dela. Requisições para esses assets — HTML, JS, CSS, imagens — são servidas diretamente da CDN, sem passar por nenhum runtime de computação.

Pages tem também Pages Functions, que são scripts Workers implantados via convenção de diretório (/functions). A confusão começa aqui: Pages Functions rodam no mesmo V8 runtime de Workers, têm os mesmos bindings (D1, KV, R2, Durable Objects), os mesmos limites de CPU e memória. A diferença entre Pages Functions e Workers puros não é técnica — é operacional.

A conta que muda tudo

No plano pago do Workers ($5/mês), você tem 10 milhões de requisições incluídas e paga $0,30 por milhão acima disso. Cada requisição HTTP processada pelo runtime conta.

No Pages, requisições para assets estáticos não custam nada por requisição — elas são servidas pelo CDN da Cloudflare sem acionar o runtime de Workers. Você paga pelas builds ($20/mês para o plano pro, com até 5.000 builds/mês e 5 builds concorrentes). As requisições para Pages Functions, essas sim, consomem o mesmo orçamento de Workers.

Traduzindo para um caso real: um site com 100 milhões de requisições mensais, sendo 90% para assets estáticos (JS bundles, imagens, páginas HTML) e 10% para rotas de API. No Pages, os 90 milhões de requisições estáticas custam $0. Os 10 milhões de Function calls estão dentro do gratuito das Functions do plano pro. Na arquitetura equivalente com Workers puro servindo os mesmos assets via fetch() contra um R2 bucket, você pagaria $27/mês só pela diferença ($0,30 × 90M requisições acima dos 10M incluídos).

Essa diferença é estrutural e não desaparece conforme a escala aumenta — ela piora.

Onde Workers tem vantagem real

Certos primitivos existem só em Workers. Cron triggers — a capacidade de executar código em horário agendado — não existe em Pages. Se você precisa de um job que roda a cada hora para sincronizar dados, processar uma fila ou limpar registros expirados, isso é Workers. Não tem equivalente em Pages.

Workers também suporta Queues consumers (processar mensagens do Cloudflare Queues de forma assíncrona), Email Workers (receber e processar e-mails), e Workers for Platforms (dispatch para scripts implantados por usuários, útil para SaaS multi-tenant). Esses triggers não-HTTP existem só no modelo Workers.

Durable Objects funcionam nos dois, mas coordenação complexa entre múltiplas instâncias — por exemplo, um servidor WebSocket com estado distribuído — tende a ficar mais limpa em Workers, onde você tem controle total sobre o deploy e o roteamento.

A sobreposição real

Pages Functions e Workers compartilham exatamente o mesmo runtime. Os limites são idênticos: 128MB de memória (hard limit), 10MB de script comprimido no plano pago, 1.000 subrequests por invocação no plano pago, 30s de CPU por requisição. Os bindings disponíveis são os mesmos: D1, KV, R2, Durable Objects, AI, Service Bindings para chamar outros Workers.

Isso significa que uma API de médio porte pode ser construída inteiramente em Pages Functions sem sacrificar nada em termos de capacidade de runtime. A pergunta não é "qual tem mais poder de computação" — é "qual modelo de deploy e billing faz mais sentido para o meu workload".

O critério de decisão

A heurística funciona assim: se o seu projeto tem assets estáticos gerados por build (qualquer framework frontend, gerador de site estático, SPA), Pages é o ponto de partida natural. Você ganha CDN global para os assets sem custo por requisição, preview deployments automáticos por branch, e pipeline de build integrado. As rotas de API ficam em /functions e rodam no mesmo runtime de Workers.

Se o projeto é compute-first — sem assets estáticos significativos, ou com triggers não-HTTP como cron, filas e e-mail — Workers é a escolha direta. O modelo de deploy via wrangler.toml é mais explícito, versionável em código, e se integra melhor com workflows de CI/CD customizados.

A maioria dos projetos não vive num extremo só. Uma SaaS típica tem um frontend (Pages, com CDN gratuito), uma API (Pages Functions, mesma base de código, mesmo deploy), e um conjunto de jobs de background (Workers separados, com cron triggers). Esses Workers de background se conectam ao projeto Pages via Service Bindings — chamadas diretas entre Workers sem passar pela internet pública.

O que a documentação não explica

A Cloudflare documenta Workers e Pages como produtos separados com páginas separadas, o que obscurece um detalhe importante: um projeto Pages pode chamar Workers externos via Service Bindings, e Workers externos podem servir assets de um projeto Pages. Não são silos. São peças que se compõem.

O erro mais comum é reimplementar em Workers o que Pages faz gratuitamente — servir assets estáticos — porque alguém leu sobre Workers primeiro e achou que era "mais avançado". Workers não é mais avançado que Pages. É uma ferramenta diferente para uma camada diferente do problema.