A Melhor Configuração do Cloudflare para Passar no Core Web Vitals

Otimizando o Core Web Vitals com Cloudflare: O Que Ativar e O Que Evitar

O Cloudflare oferece uma ampla variedade de configurações que podem impactar seu Core Web Vitals, tanto positiva quanto negativamente. Enquanto algumas configurações melhoram a performance, outras introduzem atrasos ou interferem na renderização da página. Vamos detalhar as opções mais comuns do Cloudflare e sob quais condições você deve ativá-las!

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

Perguntas Comuns de Configuração do Cloudflare: Frequentemente reviso configurações do Cloudflare para clientes. Embora eu pudesse escrever livros sobre como configurar uma CDN como o Cloudflare, a maioria das perguntas gira em torno de um simples 'devo ativar esta configuração?'. Este artigo responde a essas perguntas com as considerações apropriadas para as configurações mais comuns do Cloudflare relacionadas ao Core Web Vitals.

Free vs. Pro: Vale a Pena Fazer o Upgrade?

Speed > Optimization

Polish

O Polish otimiza imagens hospedadas no seu domínio do Cloudflare comprimindo-as, removendo metadados e, opcionalmente, convertendo-as para WebP. Para um guia completo sobre otimização de imagens, veja otimizar imagens para o Core Web Vitals.

Tamanhos de imagem menores geralmente melhorarão o Largest Contentful Paint ao melhorar a duração do carregamento do recurso de imagem. No entanto, como o LCP é influenciado por múltiplos fatores além da duração do carregamento do recurso 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 suporta conversão para AVIF; para AVIF, você precisa do Cloudflare Image Resizing (um serviço separado e pago).

Mirage (descontinuado)

O Mirage foi descontinuado pelo Cloudflare em 15 de setembro de 2025 e foi automaticamente desativado em todos os domínios. Os navegadores modernos agora suportam nativamente o lazy loading através do atributo loading="lazy", tornando a abordagem baseada em JavaScript do Mirage desnecessária.

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

Recomendação: Esta configuração não existe mais. Se você a vir em um guia mais antigo, ignore-a.

Speed Brain

O Speed Brain usa a Speculation Rules API para acelerar o Time to First Byte fazendo o prefetch de navegações futuras. As Speculation Rules são extremamente eficazes para melhorar todos os Core Web Vitals, incluindo o Largest Contentful Paint. O Speed Brain está disponível em todos os planos (incluindo o gratuito) e atualmente usa o nível de avidez conservative, que só faz o prefetch quando um usuário está prestes a clicar em um link.

Não recomendo depender do Speed Brain porque configurar speculation rules manualmente é fácil e muito mais eficaz do que a abordagem genérica do Cloudflare. A configuração manual permite que você escolha seus próprios níveis de avidez, direcione URLs específicas e use o prerendering em vez de apenas prefetching.

Recomendação: Desative e configure as speculation rules manualmente. Se você não for configurá-las sozinho, deixar o Speed Brain ativado é melhor do que não ter nenhuma speculation rule.

Cloudflare Fonts

O Cloudflare Fonts automatiza a hospedagem própria (self-hosting) de fontes. Esta é uma ótima ideia porque hospedar recursos importantes elimina novas conexões externas, que são por padrão mais lentas do que reutilizar a conexão já aberta para o seu site via proxy do Cloudflare.

É mais eficaz tirar 15 minutos e manualmente configurar a hospedagem própria de arquivos de fonte. Infelizmente, muitos sistemas CMS não permitem isso. Nesse caso, ativar o Cloudflare Fonts é uma opção perfeitamente válida. Note que o Cloudflare Fonts ainda está em beta (desde 2023) e não funciona quando o APO está ativado.

Recomendação: Desative por padrão; ative apenas se a hospedagem própria manual não for uma opção.

Early Hints

Early Hints aceleram a entrega de recursos críticos (como estilos, fontes ou imagens) sugerindo-os antes que o conteúdo HTML real seja enviado ao navegador. Para enviar um resource hint através do Cloudflare, o Cloudflare lerá seus cabeçalhos de resposta e extrairá os resource hints de lá.

Se você se sente confortável em enviar resource hints nos cabeçalhos de resposta HTTP, sugiro fortemente ativar esse recurso. No entanto, esteja ciente de que os resource hints em cabeçalhos podem ficar muito mais ocultos para sua equipe de desenvolvimento do que os resource hints na <head> da página. Se configurados incorretamente, eles podem desacelerar as coisas em vez de acelerá-las. Portanto, use com cautela. Apesar de estar disponível há anos, a adoção do Early Hints ainda está abaixo de 3% de acordo com o 2025 Web Almanac.

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

Auto Minify

O Cloudflare pode minificar seu HTML, CSS e JavaScript dinamicamente (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 arquivos.

Recomendação: Ative a minificação de HTML. Para CSS e JavaScript, a minificação em tempo de build (durante o seu processo de deployment) produz resultados melhores do que a abordagem dinâmica do Cloudflare. Se você não tem um processo de build, ativar os três não há problema.

Rocket Loader

O Rocket Loader 'adia' (defers) todo o JavaScript em uma página da web retendo os scripts temporariamente e depois injetando-os na página alguns momentos depois. Este é um truque desagradável (ou engenhoso, dependendo da sua visão) que precisa de muitas verificações e hacks para garantir que funcionará corretamente em todos os navegadores. Ele também oculta os scripts do preload scanner, um mecanismo projetado para acelerar o carregamento de recursos críticos.

Pelas razões acima, obviamente, não sou fã de ativar o Rocket Loader cegamente. Os scripts devem ser agendados com base na sua importância. Scripts críticos precisam carregar e executar cedo, enquanto scripts não essenciais podem esperar até que o navegador esteja ocioso.

O Rocket Loader do Cloudflare não faz isso. Ele retém todos os scripts e, em um certo ponto, os injeta sem considerar sua importância. O Rocket Loader apenas prioriza outros recursos, como o elemento LCP, fontes e estilos sobre os scripts. Além disso, o Rocket Loader usa o event handler unload, que é uma API descontinuada que impede o funcionamento do Back-Forward Cache (bfcache) do navegador. Isso significa que navegar para trás e para frente acionará recarregamentos completos da página em vez de restaurações instantâneas.

Se o seu CMS não permite adiar scripts ou um timing de script mais refinado, o Rocket Loader pode ser sua melhor opção. Mas para a maioria dos sites, agendar scripts manualmente é muito mais eficaz.

Recomendação: Desative e agende scripts manualmente. Ative apenas se você não tiver outra maneira de adiar ou controlar a execução de scripts.

Automatic Platform Optimization for WordPress

O APO do Cloudflare faz o cache de páginas inteiras em seus servidores edge, uma técnica conhecida como full-page edge caching. Quando implementado corretamente, ele melhorará o Time to First Byte (e subsequentemente o LCP e FCP) para um certo tipo de visitante!

No entanto, há um problema. O full-page edge caching frequentemente precisa ser ignorado (bypassed) automaticamente. Por exemplo, quando um usuário faz login ou adiciona itens ao carrinho, o APO é desativado automaticamente, pois o conteúdo da página se torna personalizado. Nesse ponto, servir uma página genérica em cache não é mais uma opção. Como o APO precisa funcionar para todos os tipos de sites, o cache será ignorado muito mais do que o necessário para o seu site. É por isso que a configuração manual de cache quase sempre será mais eficaz 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 um controle melhor sobre quando o cache é 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 escolha óbvia. O HTTP/2 é uma grande melhoria em relação ao protocolo antigo HTTP/1.1. O HTTP/2 faz muitas coisas, mas o mais importante é que ele elimina o antigo efeito cascata, permitindo que vários arquivos sejam enviados pela mesma conexão em paralelo. O HTTP/2 existe há 10 anos e é amplamente suportado por navegadores e servidores!

Recomendação: Ative os três.

HTTP/3 (with QUIC)

O HTTP/3 com QUIC é ainda mais rápido que o HTTP/2 devido a melhorias na configuração da conexão e na latência. O HTTP/3 permite que vários streams sejam enviados de forma independente, mesmo se um deles estiver atrasado. O QUIC combina handshakes de transporte e criptografia, o que reduz o tempo de conexão. Isso resulta em tempos de TTFB até 10% mais rápidos! De acordo com o 2025 Web Almanac, 38% dos sites agora suportam HTTP/3.

Recomendação: Ative.

Brotli Compression

O Brotli é um algoritmo de compressão que produz arquivos menores que o Gzip. O Cloudflare ativa o Brotli por padrão em todos os planos. Certifique-se de que ele continue ativado. De acordo com o 2025 Web Almanac, 46% das requisições servidas por CDN agora usam a compressão Brotli.

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

0-RTT Connection Resumption

O 0-RTT Connection Resumption acelera conexões seguras pulando o handshake inicial quando um usuário revisita um site. Ele usa chaves de criptografia armazenadas anteriormente, permitindo que os dados sejam enviados imediatamente, reduzindo a latência e melhorando o tempo de carregamento da página.

Recomendação: Ative.

Automatic Signed Exchanges (descontinuado)

Signed Exchanges (SXGs) costumavam permitir que a Pesquisa do Google fizesse o prefetch do seu conteúdo enquanto preservava a privacidade do usuário. As SXGs podiam melhorar o LCP em aproximadamente 450ms para visitantes vindos dos resultados da Pesquisa do Google.

No entanto, o Cloudflare descontinuou as SXGs em outubro de 2025. O recurso foi removido e não está mais disponível. Se você o tinha ativado, ele foi automaticamente desativado. O Speed Brain (Speculation Rules) é o substituto mais próximo para prefetching, embora funcione apenas para navegações same-site, e não para cross-origin prefetching a partir da Pesquisa do Google, como as SXGs faziam.

Recomendação: Esta configuração não existe mais.

Scrape Shield

O Scrape Shield protege o conteúdo do seu site. Embora isso possa parecer uma boa ideia, sou fervorosamente contra ativar quaisquer opções do Scrape Shield. O Scrape Shield funciona injetando JavaScript em sua página para decodificar o conteúdo previamente ofuscado. Esse compromisso entre velocidade e ocultar o conteúdo não faz sentido para mim. Spammers reais não são enganados, enquanto usuários reais recebem scripts extras que desaceleram a página.

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

Bot Fight Mode e Super Bot Fight Mode

Esta é a configuração do Cloudflare mais prejudicial ao seu 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 de 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 da thread principal antes que sua página possa se tornar interativa.

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 tem o mesmo problema. A ironia: esses modos são projetados para bloquear bots, mas punem todos os usuários reais que visitam seu 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 WAF ou o rate limiting do Cloudflare. Estes não injetam JavaScript no lado do cliente.

Caching > Configuration

Purge Cache

Limpar o cache (purging) invalidará todos os arquivos em cache pelo Cloudflare, incluindo folhas de estilo, JavaScript, imagens e até caches de página inteira. E embora o purge cache tecnicamente não seja uma configuração, devo alertar sobre a limpeza do cache. Limpar o cache tornará seu site mais lento até que o cache seja reconstruído!

Recomendação: Evite limpar todo o cache se possível. Limpe apenas os arquivos afetados!

Caching Level

O Caching Level determina como o Cloudflare lida com query strings. Você vai querer dar uma boa olhada nesta configuração.

A opção 'mais rápida' é 'Ignore query string'. Isso serve o mesmo recurso independentemente da query string. Esta é uma boa opção apenas se você tiver 100% de certeza de que as query strings não são usadas em seu site. Nesse caso, query strings adicionadas por outros são ignoradas.

'Standard' serve um arquivo em cache diferente para cada query string diferente. Esta é a configuração padrão para o Cloudflare, mas em combinação com o full-page edge caching e parâmetros de rastreamento (tracking) como os parâmetros utm, esta configuração pode causar incompatibilidade de cache e uma taxa de acerto de cache (cache hit ratio) menor! Considere remover os parâmetros de rastreamento com Cloudflare Workers para resolver isso.

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

Browser Cache TTL

O Browser Cache TTL diz ao navegador por quanto tempo ele pode fazer cache de recursos estáticos. Recursos em cache podem ser servidos diretamente do navegador e ficam disponíveis muito mais rápido do que recursos de rede remotos. Isso significa que um Browser Cache TTL curto invalidaria o cache do navegador frequentemente, diminuindo a taxa de acerto de cache (cache hit ratio). Então, a menos que seus arquivos estáticos mudem frequentemente, defina essa configuração para o máximo.

Recomendação: Defina para 1 ano se possível.

Development Mode

O Development Mode ignorará (bypass) todo o cache do Cloudflare enquanto ativado. Pode ser tentador ativar o development mode durante o desenvolvimento. Por favor, não ative o development mode, ele também desativa o cache para todos os outros visitantes. Em vez disso, configure um domínio de desenvolvimento onde você possa desenvolver ou se exclua do cache do Cloudflare configurando regras de cache.

Recomendação: Não ative!

Caching > Tiered Cache

O Tiered Cache reduz o número de requisições ao seu servidor de origem e aumenta a taxa de acerto de cache (cache hit ratio) instruindo o Cloudflare a procurar por arquivos não cacheados em seus próprios servidores primeiro. Isso reduz ainda mais a carga em seu servidor backend e libera recursos extras.

Recomendação: Ative a Smart Tiered Caching Topology.

Em todos os sites monitorados pelo CoreDash, sites usando uma CDN configurada adequadamente mostram um TTFB 55% mais rápido no p75 em comparação com sites sem uma CDN. A combinação de HTTP/3, Brotli e tiered caching do Cloudflare faz uma diferença mensurável na prática. Use o Real User Monitoring para verificar se a sua configuração do Cloudflare está realmente funcionando para os seus usuários.