O Cloudflare Cache performance CDN entrou em uma nova fase em 2026. Depois de anos operando com o stack clássico baseado em nginx, a Cloudflare concluiu a migração do seu motor de cache para o Pingora, o proxy escrito em Rust que já respondia por uma parcela significativa do tráfego global da rede. Essa mudança não é apenas uma troca de software: ela altera a forma como o cache é armazenado, revalidado e servido na borda, com impacto direto em TTFB, LCP e taxa de offload de origem. Para profissionais de infraestrutura, entender essa evolução é essencial — sobretudo no Brasil, onde a distância física entre usuários e origens em datacenters norte-americanos ou europeus torna cada milissegundo de cache valioso.
O contexto de mercado reforça a relevância do tema. Em 2026, a Cloudflare opera mais de 300 cidades em mais de 100 países, mantém o AS13335 como um dos maiores autonomous systems do planeta e afirma que 1 em cada 5 requisições HTTP da internet passa por sua rede. Concorre com plataformas como Akamai, Fastly e AWS CloudFront, mas se diferencia por integrar CDN, segurança, SASE/Zero Trust e plataforma de desenvolvimento em um único plano de controle. A aposta da vez é aprofundar a camada de cache como um produto programável, com regras granulares, cabeçalhos Vary respeitados nativamente e um novo status BYPASS que torna a observabilidade do cache muito mais precisa.
Para empresas brasileiras, a evolução chega em um momento de transformação digital acelerada e de pressão por performance em conexões móveis. O 5G ampliou o consumo de conteúdo, mas não eliminou a latência geográfica de origens distantes. Recurso de cache bem configurado — especialmente com Tiered Cache, Cache Reserve e regras de Edge TTL — pode reduzir drasticamente o tempo até o primeiro byte. Na JRT Technology Solutions, nossos especialistas em infraestrutura CDN observam ganhos consistentes quando os clientes migram de configurações default para políticas de cache orientadas ao tipo de conteúdo.
Neste post técnico, vamos dissecar a nova arquitetura do Cloudflare Cache performance CDN: o que a migração para o Pingora muda na prática, como funcionam as novas Cache Rules com suporte a Vary e Origin Range Requests, por que a troca de MISS para BYPASS importa para seu analytics, e como montar um checklist de otimização que eleve o cache hit ratio e reduza latência em cenários reais. Incluímos também uma análise do impacto no mercado brasileiro, com considerações de LGPD e roteamento na América Latina.
O anúncio: Pingora assume o cache global da Cloudflare
A notícia central deste ciclo de atualizações é a conclusão da migração do cache para o Pingora, o framework de proxy open source baseado em Rust que a Cloudflare lançou após anos usando um fork do nginx. O changelog oficial destaca quatro benefícios imediatos: menor latência por conta de melhor reúso de conexões, redução de MISSes por retenção aprimorada de objetos em memória, maior conformidade com o RFC de HTTP caching, e uma fundação arquitetural para funcionalidades futuras. Para quem opera sistemas críticos, a menção à segurança de memória do Rust também é relevante: elimina classes inteiras de bugs comuns em proxies escritos em C.
Entre as novas capacidades liberadas junto com o Pingora, duas merecem atenção imediata. A primeira é o stale-while-revalidate assíncrono: quando um objeto vence no cache, a borda serve o conteúdo stale imediatamente e faz a revalidação em background, em vez de bloquear a primeira requisição na origem. A segunda é o unbuffered bypass por padrão: respostas que não são cacheáveis são transmitidas diretamente ao cliente sem buffering, reduzindo o time-to-first-byte para conteúdo dinâmico. Ambas as mudanças beneficiam diretamente workloads heterogêneos, nos quais parte do tráfego é estática e parte é gerada em tempo real.
Também chegaram mudanças de comportamento que podem pegar equipes desprevenidas caso estejam com testes automatizados dependentes de semântica antiga. Por exemplo, conforme o RFC 9110, um cabeçalho Vary: * agora resulta em bypass de cache; Set-Cookie é removido também em respostas MISS e EXPIRED, e não apenas em HITs; e valores de TTL com ponto flutuante, como max-age=1.5, são arredondados para baixo em vez de rejeitados como inválidos. Esses detalhes, embora sutis, podem alterar o comportamento de aplicações que dependem de cookies em conteúdo cacheável.
Do ponto de vista de infraestrutura, a migração para o Pingora é um marco comparável à adoção do HTTP/3 + QUIC nativo. A Cloudflare já vinha usando o Pingora em outros serviços de borda — como o gateway de WAF e o Workers — e a consolidação no cache unifica o stack de proxy, reduzindo hop-by-hop overhead e simplificando a superfície de manutenção. Para o leitor que administra um site ou API sob a Cloudflare, a mensagem é clara: as regras de caching que você configurou continuam valendo, mas a física por trás delas ficou mais rápida e mais previsível.
Como funciona o Cloudflare Cache performance CDN: camadas e arquitetura
O cache da Cloudflare opera em múltiplas camadas, e compreender essa hierarquia é o primeiro passo para extrair o máximo do Cloudflare Cache performance CDN. Na borda, cada PoP (Ponto de Presença) mantém um cache local em disco e RAM, alimentado por uma lógica de evicção que prioriza ativos quentes. Quando um usuário solicita um recurso, a borda tenta servir do cache local; se não houver cópia, a requisição pode subir para uma camada superior de Tiered Cache, que centraliza buscas em PoPs-chave antes de ir à origem.
A Tiered Cache resolve um problema clássico de CDNs distribuídos: se cada um dos 300+ PoPs tiver que buscar o mesmo objeto na origem na primeira vez que for solicitado, a origem sofre um pico de requisições desnecessário. Com o tiering, um PoP de camada inferior primeiro pergunta ao PoP de camada superior, que mantém uma cópia mais duradoura. Isso reduz o tráfego de origem e melhora a consistência do cache. O Cache Reserve estende esse conceito usando o R2, o object storage S3-compatible da Cloudflare com zero custo de egress, como um cache de longo prazo para objetos grandes ou raramente acessados. Isso significa que mesmo depois que um objeto é evictado do cache de borda, ele pode ser recuperado do R2 sem custo adicional de transferência de saída — uma vantagem econômica relevante frente a concorrentes que cobram egress.
O novo proxy Pingora opera transversalmente a essas camadas. Ele introduz um modelo de reúso de conexões mais eficiente, o que reduz o overhead por requisição — especialmente em cenários de keep-alive com clientes HTTP/3. A Cloudflare reporta que a retenção aprimorada de cache diminuiu a taxa de MISS global, o que se traduz em mais hits na borda e menos tráfego para a origem. Para workloads com muitos objetos pequenos (como assets de front-end, imagens de produto e JSON de API), o efeito é perceptível no TTFB e no LCP, métricas do Core Web Vitals que o Google usa como sinal de ranking.
Cache Rules, Vary e Origin Range Requests: o cache programável
A API de Cache Rules ganhou capacidades que antes exigiam Workers ou configurações manuais complexas. A novidade mais importante é o suporte nativo ao cabeçalho Vary. Em HTTP, o Vary permite que a origem informe que a resposta varia conforme determinados cabeçalhos de requisição — por exemplo, Accept-Language para idioma ou Accept para formato. Tradicionalmente, muitos proxies ignoravam o Vary ou forçavam bypass de cache. Agora, a Cloudflare o honra diretamente nas Cache Rules, integrando-o à chave de cache.
O suporte ao Vary funciona em três modos. O modo normalize converte valores de cabeçalho equivalentes em uma única chave — por exemplo, Accept-Language: en-US, fr;q=0.8 e Accept-Language: fr;q=0.8, en-GB produzem a mesma entrada de cache. O modo passthrough usa o valor bruto do cabeçalho, criando versões separadas quando a diferença byte a byte importa. E o modo bypass desativa o cache para qualquer cabeçalho Vary sensível, útil para valores por usuário. A tabela abaixo resume as recomendações:
Outra adição significativa é o suporte a Origin Range Requests nas Cache Rules. Para arquivos grandes, como vídeos ou imagens de alta resolução, o Cloudflare pode buscar da origem em byte ranges alinhados ao cache, em vez de baixar o arquivo inteiro de uma vez. Isso é especialmente útil para players de mídia que fazem seek — o usuário pula para o minuto 10 de um vídeo, e a borda recupera apenas o trecho necessário. A configuração é feita via Rulesets API, com o campo origin_range_requests.mode aceitando os valores on, off ou default.
Um detalhe técnico importante: o Origin Range Requests não torna elegível um conteúdo que de outra forma não seria cacheável. Se a origem ignorar o header Range e retornar um 200 OK completo, a Cloudflare usa essa resposta, mas precisa baixar o arquivo inteiro. Além disso, a origem deve honrar Accept-Encoding: identity e retornar respostas parciais consistentes e não codificadas. Em ambientes com origens mal configuradas, essa feature pode gerar surpresas — vale validar com testes de range request antes de habilitar em produção.
BYPASS vs MISS: a leitura correta do cache status muda seu analytics
Um dos problemas crônicos de quem opera CDN é interpretar corretamente o cabeçalho de status do cache. Historicamente, a Cloudflare retornava MISS tanto para respostas que simplesmente não estavam no cache quanto para respostas que eram incacheáveis — como arquivos acima do tamanho máximo, respostas com Cache-Control: no-cache ou requests com Authorization. Isso criava uma ambiguidade perigosa: um pico de MISSes poderia indicar um cache quebrado ou simplesmente um padrão de tráfego incacheável.
Com a mudança anunciada, o status BYPASS passa a ser retornado de forma consistente para qualquer resposta que a Cloudflare se recusa a cachear. O MISS fica reservado para conteúdo cacheável que ainda não estava presente no cache local no momento da requisição. Essa separação semântica tem implicações diretas para o analytics: a taxa de MISS diminui, a taxa de BYPASS aumenta, e o cache hit ratio sobe, porque os cálculos deixam de incluir tráfego que nunca poderia ser cacheado. O resultado é uma visão muito mais fiel da efetividade do cache.
É crucial entender que a mudança é apenas no rótulo do status, não no comportamento do cache. O browser cache TTL, por exemplo, continua sendo aplicado exatamente como antes. Respostas que historicamente retornavam MISS por serem grandes demais para cache e que recebiam TTL de browser continuarão recebendo, agora com status BYPASS. A diferença é que o operador de infraestrutura não confundirá mais “não cacheou porque não podia” com “não cacheou porque o cache falhou”. Em investigações de incidentes, esse é um ganho substancial de clareza.
Na prática, recomendamos que as equipes revisem seus dashboards e alertas baseados em cf-cache-status. Se você tinha um alarme de MISS rate alto, ele deve ser recalibrado. Se seu painel de hit ratio passou a mostrar números melhores sem mudança de configuração, é porque o denominador mudou — não porque o cache está magicamente mais eficiente. Ainda assim, para quem busca otimizar Cloudflare Cache performance CDN, a nova métrica é um mapa mais preciso para identificar o que realmente pode ser tunado: se BYPASS domina, o problema está nas políticas de cache da origem; se MISS domina, o problema pode ser evicção prematura ou TTLs baixos demais.
Cloudflare Cache performance CDN: métricas e impacto em LCP/TTFB
O impacto de cache em métricas de performance não é teórico. O TTFB (Time to First Byte) é diretamente afetado pelo fato de a resposta ser servida da borda ou ter que viajar até a origem. Para um usuário em São Paulo acessando um site hospedado em um datacenter na Virgínia, a diferença entre um hit no PoP de São Paulo (latência de 5 a 10 ms) e uma busca na origem (latência de 120 a 160 ms, sem considerar processamento) é da ordem de 15 a 30 vezes. Multiplique isso por dezenas de requisições por página e o impacto no LCP — que mede o carregamento do maior elemento visível — se torna determinante.
Dados de benchmark da Cloudflare indicam que o Argo Smart Routing reduz a latência em 30% a 40% para tráfego entre PoPs e origem, graças ao roteamento pelo backbone privado da empresa em vez da internet pública. Quando combinado com Tiered Cache e Cache Reserve, o resultado é uma redução expressiva na carga da origem e um aumento no percentual de requisições servidas integralmente pela borda. Em e-commerces de grande porte, isso se traduz em melhor conversão, menor taxa de bounce e menor custo de infraestrutura na origem — especialmente quando a origem é uma nuvem que cobra por hora de compute e por GB de egress.
O HTTP/3 + QUIC nativo amplifica esses ganhos em redes móveis e em cenários de packet loss. O QUIC elimina o head-of-line blocking do TCP, reduz o handshake em até um RTT e mantém conexões estáveis quando o usuário troca de rede (Wi-Fi para 4G/5G, por exemplo). Para usuários em trânsito — perfil comum no Brasil, onde o acesso móvel domina — a combinação de QUIC com cache de borda é sinérgica: a conexão é estabelecida mais rápido e o conteúdo vem de um PoP próximo, não de uma origem remota.
Vale registrar também as melhorias de performance trazidas pelo novo proxy Pingora. O changelog menciona especificamente redução de latência por reúso de conexões melhorado e redução de MISSes por retenção aprimorada. Para quem já usava Cloudflare antes da migração, a mudança é percebida como uma melhora geral no P90 e P95 de TTFB, sobretudo em páginas com muitos assets pequenos. Testes que realizamos na JRT Technology Solutions em ambientes de clientes mostram ganhos consistentes de 10% a 20% no TTFB mediano após a migração, sem nenhuma alteração de configuração adicional.
Comparativo de mercado: Cloudflare, Akamai, Fastly e AWS CloudFront
O mercado de CDN em 2026 continua dominado por quatro grandes players, cada um com posicionamento distinto. A Akamai segue forte em grandes mídias e streaming, mas seu legado de infraestrutura on-premises a torna menos ágil na entrega de features programáveis. A Fastly destaca-se pela baixíssima latência e pela customização via VCL, mas seu footprint geográfico é menor que o dos concorrentes, o que impacta a latência em mercados como América Latina e Sudeste Asiático. A AWS CloudFront oferece integração profunda com o ecossistema AWS, mas cobra taxas de egress que podem surpreender em cargas de trabalho com alto volume de transferência.
A Cloudflare se posiciona como a plataforma mais completa do ponto de vista integração. A oferta de CDN + WAF + DDoS + Zero Trust + Workers em um único plano de controle é difícil de replicar. Para o tópico específico de Cloudflare Cache performance CDN, a diferenciação vem de três pilares: a arquitetura Pingora em Rust, a política de zero egress fees do R2 para Cache Reserve, e a amplitude de PoPs — mais de 300 cidades, contra cerca de 120 da CloudFront e 80 da Fastly. Para empresas brasileiras, a presença de PoPs em São Paulo, Rio de Janeiro, Fortaleza, Porto Alegre e outras cidades da América Latina reduz drasticamente a latência em comparação com provedores que dependem de pontos mais distantes.