A melhor configuração do Cloudflare para passar no Core Web Vitals

Otimizando o Core Web Vitals com o Cloudflare: o que ativar e o que evitar

O Cloudflare oferece uma série de configurações que impactam o Core Web Vitals, tanto para o bem quanto para o mal. Enquanto alguns ajustes melhoram o desempenho, outros causam atrasos ou interferem na renderização da página. Veja as opções mais comuns do Cloudflare e em quais condições você deve ativá-las.

Última revisão por Arjen Karel em fevereiro de 2026

Dúvidas comuns sobre a configuração do Cloudflare: costumo revisar configurações do Cloudflare para clientes. Eu poderia escrever livros sobre como configurar uma CDN como o Cloudflare, mas a maioria das perguntas se resume a um simples 'devo ativar esta opção?'. Este artigo responde a essas dúvidas, analisando as principais configurações do Cloudflare que afetam o Core Web Vitals.

Free vs. Pro: vale a pena fazer o upgrade?

Velocidade > Otimização

Polish

O Polish otimiza imagens hospedadas no seu domínio no Cloudflare: ele comprime os arquivos, remove metadados e pode convertê-los para WebP. Para um guia completo sobre otimização de imagens, veja como otimizar imagens para o Core Web Vitals.

Arquivos de imagem menores costumam melhorar o Largest Contentful Paint ao reduzir a duração de carregamento do recurso de imagem. No entanto, como o LCP depende de vários outros fatores além do carregamento das imagens, não espere melhorias drásticas.

Recomendação: ative e escolha 'Lossy WebP' para obter os melhores resultados. Note que o Polish não é compatível com conversão para AVIF; para usar AVIF, você precisa do Cloudflare Image Resizing (um serviço pago à parte).

Mirage (descontinuado)

O Cloudflare descontinuou o Mirage em 15 de setembro de 2025 e desativou o recurso automaticamente em todos os domínios. Os navegadores modernos hoje oferecem suporte nativo a lazy loading por meio do atributo loading="lazy", tornando desnecessária a abordagem do Mirage baseada em JavaScript.

O Mirage otimizava imagens com base nas condições da rede. A implementação era lenta por definição: ela bloqueava as imagens até que a velocidade da conexão fosse medida. Esse bloqueio podia causar Layout Shifts e, ironicamente, um Largest Contentful Paint mais lento.

Recomendação: esta opção não existe mais. Se você a vir em algum guia antigo, ignore.

Speed Brain

O Speed Brain usa a Speculation Rules API para acelerar o Time to First Byte, fazendo o prefetch de navegações futuras. A Speculation Rules API é extremamente eficiente para melhorar todas as métricas do Core Web Vitals, incluindo o Largest Contentful Paint. O Speed Brain está disponível em todos os planos (inclusive no gratuito) e hoje usa o nível de eagerness conservative, que só faz o prefetch quando o usuário está prestes a clicar em um link.

Não recomendo depender do Speed Brain: configurar regras de especulação manualmente é simples e muito mais eficiente do que a solução genérica do Cloudflare. A configuração manual permite escolher seus próprios níveis de eagerness, mirar URLs específicas e usar prerendering em vez de apenas prefetch.

Recomendação: desative e configure as regras de especulação manualmente. Se você não for configurá-las por conta própria, deixar o Speed Brain ativado ainda é melhor do que não usar nenhuma regra de especulação.

Cloudflare Fonts

O Cloudflare Fonts automatiza o self-hosting de fontes. A ideia é excelente: hospedar recursos críticos no próprio domínio elimina novas conexões externas, que por padrão são mais lentas do que reutilizar a conexão já aberta com o site no Cloudflare.

É mais eficiente dedicar 15 minutos para configurar o self-hosting dos arquivos de fontes manualmente. Infelizmente, muitos CMSs não permitem isso. Nesse caso, ativar o Cloudflare Fonts é uma opção perfeitamente válida. Vale notar que o Cloudflare Fonts ainda está em beta (desde 2023) e não funciona com o APO ativado.

Recomendação: deixe desativado por padrão; ative apenas se o self-hosting manual não for uma opção viável.

Early Hints

O recurso de Early Hints acelera a entrega de recursos críticos (como estilos, fontes ou imagens), avisando o navegador sobre eles antes do envio do conteúdo HTML. Para enviar um resource hint pelo Cloudflare, o serviço lê os cabeçalhos de resposta HTTP e extrai as dicas de lá.

Se você tem facilidade para enviar resource hints nos cabeçalhos de resposta HTTP, recomendo muito ativar esse recurso. No entanto, tenha em mente que resource hints em cabeçalhos ficam muito mais escondidos da equipe de desenvolvimento do que no <head> da página. Se forem mal configurados, podem piorar o desempenho em vez de acelerar. Use com cautela. Apesar de disponível há anos, a adesão ao Early Hints ainda é inferior a 3%, de acordo com o Web Almanac de 2025.

Recomendação: ative apenas se você estiver enviando cabeçalhos de resource hint corretamente.

Auto Minify

O Cloudflare consegue minificar HTML, CSS e JavaScript on-the-fly. A minificação de HTML remove espaços em branco e comentários, reduzindo ligeiramente o tamanho da transferência. A minificação de CSS e JavaScript faz o mesmo para esses tipos de arquivo.

Recomendação: ative a minificação de HTML. Para CSS e JavaScript, minificar em tempo de build (durante o processo de deploy) traz resultados melhores do que a abordagem on-the-fly do Cloudflare. Se você não tem um processo de build, pode ativar as três opções.

Rocket Loader

O Rocket Loader adia todo o JavaScript da página: ele retém os scripts temporariamente e os injeta instantes depois. É um truque agressivo (ou engenhoso, dependendo do seu ponto de vista) que exige muitos ajustes e hacks para funcionar direito em todos os navegadores. Ele também esconde os scripts do preload scanner, um mecanismo projetado justamente para acelerar o carregamento de recursos críticos.

Por esses motivos, obviamente, não sou a favor de ativar o Rocket Loader às cegas. Os scripts devem ser agendados com base na sua importância. Scripts críticos precisam carregar e executar cedo; scripts não essenciais podem esperar até o navegador ficar ocioso.

O Rocket Loader do Cloudflare não faz isso. Ele retém todos os scripts e, a certa altura, injeta tudo sem critério de prioridade. O Rocket Loader apenas prioriza outros recursos, como o elemento do LCP, fontes e estilos em relação aos scripts. Além disso, ele usa o manipulador do evento unload, uma API obsoleta que impede o funcionamento do Back-Forward Cache (bfcache) do navegador. Com isso, navegar para frente e para trás no histórico exigirá o recarregamento completo da página, em vez de uma restauração instantânea.

Se o seu CMS não permite adiar scripts ou controlar o timing deles com precisão, o Rocket Loader pode ser a melhor saída. Mas, para a maioria dos sites, agendar os scripts manualmente é muito mais eficiente.

Recomendação: desative e agende os scripts manualmente. Só ative se não houver outra forma de adiar ou controlar a execução dos scripts.

Automatic Platform Optimization for WordPress

O APO do Cloudflare salva páginas inteiras em cache nos servidores de borda, técnica conhecida como full-page edge caching. Quando bem implementado, ele melhora o Time to First Byte (e, consequentemente, o LCP e o FCP) para determinado perfil de visitante!

Porém, há um detalhe. O full-page edge caching frequentemente precisa ser ignorado de forma automática. Por exemplo, quando um usuário faz login ou adiciona itens ao carrinho, o APO é desativado automaticamente porque o conteúdo da página passa a ser personalizado. Nesse ponto, entregar uma página genérica em cache deixa de ser viável. Como o APO precisa funcionar para qualquer tipo de site, o cache acaba sendo ignorado muito mais vezes do que o necessário. É por isso que configurar o cache manualmente quase sempre traz resultados melhores do que o APO do Cloudflare.

Recomendação: ative o APO ou, melhor ainda, configure suas próprias regras de full-page edge caching para ter maior controle sobre quando o cache deve ser ignorado.

HTTP/2, HTTP/2 to Origin e Enhanced HTTP/2 Prioritization

Ativar HTTP/2, HTTP/2 to Origin e Enhanced HTTP/2 Prioritization é uma decisão óbvia. O HTTP/2 é uma evolução enorme em relação ao antigo protocolo HTTP/1.1. Ele traz muitas melhorias, mas a principal é eliminar o velho efeito escada, permitindo o envio de vários arquivos em paralelo pela mesma conexão. O HTTP/2 já existe há 10 anos e conta com suporte de praticamente todos os navegadores e servidores!

Recomendação: ative as três opções.

HTTP/3 (com QUIC)

O HTTP/3 com QUIC é ainda mais rápido que o HTTP/2 graças a melhorias no estabelecimento da conexão e na latência. O HTTP/3 permite o envio de múltiplos fluxos de dados de forma independente, mesmo que um deles sofra atraso. O QUIC combina o handshake de transporte com o de criptografia, reduzindo o tempo de conexão. O resultado é um TTFB até 10% mais rápido! Segundo o Web Almanac de 2025, 38% dos sites já oferecem suporte ao HTTP/3.

Recomendação: ative.

Compressão Brotli

O Brotli é um algoritmo de compressão que gera arquivos menores que o Gzip. O Cloudflare ativa o Brotli por padrão em todos os planos. Certifique-se de mantê-lo ativado. De acordo com o Web Almanac de 2025, 46% das requisições entregues por CDN já usam compressão Brotli.

Recomendação: mantenha ativado (já vem ativado por padrão).

0-RTT Connection Resumption

O 0-RTT Connection Resumption agiliza conexões seguras pulando o handshake inicial quando um usuário retorna ao site. O recurso reaproveita chaves de criptografia salvas anteriormente para enviar dados de imediato, o que diminui a latência e reduz o tempo de carregamento da página.

Recomendação: ative.

Automatic Signed Exchanges (descontinuado)

O Signed Exchanges (SXGs) permitia que a Busca do Google fizesse o prefetch do conteúdo preservando a privacidade do usuário. O SXGs conseguia reduzir o LCP em cerca de 450 ms para visitantes vindos dos resultados de busca do Google.

No entanto, o Cloudflare descontinuou o SXGs em outubro de 2025. O recurso foi removido e não está mais disponível. Quem tinha a opção ativada teve o recurso desligado automaticamente. O Speed Brain (Speculation Rules) é o substituto mais próximo para prefetch, embora funcione apenas para navegações no mesmo site, e não para prefetch cross-origin a partir da Busca do Google como o SXGs fazia.

Recomendação: esta opção não existe mais.

Scrape Shield

O Scrape Shield protege o conteúdo do site. Embora isso pareça uma boa ideia, sou totalmente contra ativar qualquer opção do Scrape Shield. Ele funciona injetando JavaScript na página para decodificar o conteúdo previamente ofuscado. Essa troca de velocidade em troca de tentar esconder conteúdo não faz nenhum sentido. Spammers reais não caem nisso, e os usuários reais acabam recebendo scripts extras que deixam a página mais lenta.

Recomendação: desative a Email Address Obfuscation e desative o Hotlink Protection.

Bot Fight Mode e Super Bot Fight Mode

Esta é a configuração do Cloudflare mais prejudicial para o Core Web Vitals. Quando ativado, o Bot Fight Mode injeta um script chamado invisible.js em todas as páginas. Esse script executa um desafio no navegador que adiciona mais de 2.000 milissegundos de tempo de execução da CPU a cada carregamento de página. São 2 segundos inteiros de bloqueio na main thread antes que a página possa responder a interações.

Na prática, ativar o Bot Fight Mode pode derrubar sua pontuação no PageSpeed em 20 pontos ou mais. O Super Bot Fight Mode sofre do mesmo problema. A ironia: esses modos foram criados para barrar bots, mas punem todos os usuários reais que visitam o site.

Recomendação: desative tanto o Bot Fight Mode quanto o Super Bot Fight Mode. Se você precisa de proteção contra bots, use as regras de WAF do Cloudflare ou rate limiting. Essas opções não injetam JavaScript no cliente.

Cache > Configuração

Limpar cache

Limpar o cache invalida todos os arquivos armazenados pelo Cloudflare, incluindo folhas de estilo, JavaScript, imagens e até o cache de páginas inteiras. E, embora limpar o cache não seja tecnicamente uma configuração, preciso alertar sobre isso: limpar o cache vai deixar seu site mais lento até que o cache seja reconstruído!

Recomendação: evite limpar todo o cache se puder. Limpe apenas os arquivos afetados!

Nível de cache

O nível de cache determina como o Cloudflare lida com query strings. Vale a pena analisar bem esta configuração.

A opção mais rápida é a 'Ignore query string'. Ela entrega o mesmo recurso independentemente dos parâmetros na URL. Só é uma boa escolha se você tiver 100% de certeza de que query strings não são usadas no site. Nesse cenário, parâmetros adicionados por terceiros são ignorados.

A opção 'Standard' entrega um arquivo diferente em cache para cada query string distinta. Essa é a configuração padrão do Cloudflare. Porém, combinada com full-page edge caching e parâmetros de rastreamento (como parâmetros UTM), ela pode causar disparidade de cache e derrubar o cache hit ratio! Considere remover parâmetros de rastreamento com o Cloudflare Workers para resolver isso.

Recomendação: use 'Ignore query string' sempre que possível, ou 'Standard'. Evite a opção 'No query string'.

TTL do cache do navegador

O TTL do cache do navegador informa ao navegador por quanto tempo ele pode armazenar recursos estáticos em cache. Recursos em cache são entregues direto pelo navegador e ficam disponíveis muito mais rápido do que recursos buscados na rede. Um TTL curto invalida o cache do navegador com frequência, derrubando o cache hit ratio. Portanto, a menos que seus arquivos estáticos mudem com frequência, ajuste essa opção para o valor máximo.

Recomendação: defina como 1 ano, se possível.

Modo de desenvolvimento

O modo de desenvolvimento ignora todo o cache do Cloudflare enquanto estiver ativo. Pode ser tentador ativá-lo durante o desenvolvimento, mas não faça isso: ele também desativa o cache para todos os outros visitantes. Em vez disso, configure um domínio de desenvolvimento específico ou crie regras de cache para excluir apenas o seu tráfego do cache do Cloudflare.

Recomendação: não ative!

Cache > Tiered Cache

O Tiered Cache reduz o número de requisições ao servidor de origem e aumenta o cache hit ratio, orientando o Cloudflare a buscar arquivos não armazenados em cache primeiro em seus próprios servidores. Isso reduz ainda mais a carga no servidor backend e libera recursos.

Recomendação: ative a opção Smart Tiered Caching Topology.

Entre os sites monitorados pelo CoreDash, aqueles que usam uma CDN bem configurada apresentam um TTFB 55% mais rápido no p75 em comparação com sites sem CDN. A combinação de HTTP/3, Brotli e tiered caching do Cloudflare faz uma diferença mensurável nos dados de campo. Use Real User Monitoring para confirmar se a configuração do Cloudflare está realmente trazendo resultados para os usuários.