Cloudflare lança Workers Cache, otimizando performance e custo em aplicações de borda

O BLOG-3262, nome interno do Workers Cache, não é só mais um cache na borda. É uma mudança arquitetural no modelo de execução dos Workers: agora o cache fica *na frente* do Worker, não atrás dele. Isso muda a conta de custo: em acerto, zero CPU, zero tempo de execução, só a taxa fixa por requisição. Em falha, o Worker roda uma vez, gera a resposta e popula o cache em duas camadas, local (data center mais próximo) e global (agregação da rede). A camada superior é preenchida na primeira requisição de qualquer parte do mundo, então hits subsequentes vêm direto dela, mesmo sem ter passado antes pelo mesmo data center.

Ele serve quem constrói aplicações SSR completas dentro de um único Worker: frameworks como Next.js, Remix ou SvelteKit rodando nativamente na borda. Antes, cada requisição disparava um render completo. Agora, basta um Cache-Control: public, max-age=300, stale-while-revalidate=3600 para que a primeira requisição pague o custo, e todas as próximas até 5 minutos sejam servidas como estático, com atualização silenciosa em segundo plano. E isso funciona em todos os pontos de entrada: rotas públicas, service bindings, preview URLs e Workers for Platforms, cada um com seu cache isolado por ctx.props, sem risco de vazamento entre tenants.

Em fevereiro de 2026, a Cloudflare focou em otimizar conteúdo *para IA*, com Markdown for Agents e Claude Managed Agents. Em março e abril, investiu em infraestrutura de IA: Kimi K2.5 e sandboxes 100x mais rápidos. O BLOG-3262 fecha o ciclo: não é mais sobre entregar melhor *para agentes*, mas sobre tornar a borda *viável como origem real*. Antes, Workers eram 'camada de transformação' à frente de um backend. Hoje, são a origem, e o cache precisava seguir essa evolução. A mudança real é técnica e conceitual: o cache deixou de ser configurado por zona (Page Rules, Cache Rules) e passou a pertencer ao Worker, com purga programática, chaves multi-tenant e suporte nativo a Vary e stale-while-revalidate, algo que a Cache API antiga não oferecia.

Para equipes de DevOps e engenharia de plataformas, o BLOG-3262 reduz o trade-off clássico entre frescor e performance em aplicações SSR. Não exige adaptação de framework, não depende de ISR (Incremental Static Regeneration) ou ferramentas específicas, usa HTTP padrão. Isso simplifica pipelines CI/CD: nenhuma etapa de build pré-renderiza, nenhuma lógica de fallback para cache expirado. Segurança também melhora: purgas são isoladas por entrypoint, sem risco de invalidar cache de outro Worker ou de conteúdo estático da zona. Para custos em nuvem, o impacto é direto: menos execuções = menos CPU faturada. E, ao integrar com Smart Placement, permite manter o código perto do usuário *e* perto dos dados, sem ter que escolher um ou outro.