A melhor configuração da Cloudflare para passar nos Core Web Vitals

Otimizar os Core Web Vitals com a Cloudflare: o que ativar e o que evitar

A Cloudflare oferece várias definições que afetam os Core Web Vitals, tanto pela positiva como pela negativa. Algumas melhoram o desempenho; outras causam atrasos ou interferem com a renderização da página. Eis as opções mais comuns da Cloudflare e as condições em que as deve ativar.

Revisto pela última vez por Arjen Karel em fevereiro de 2026

Dúvidas comuns sobre a configuração da Cloudflare: Analiso frequentemente configurações da Cloudflare para clientes. Dava para escrever livros sobre a configuração de uma CDN como a Cloudflare, mas a maioria das perguntas resume-se a um simples 'devo ativar esta definição?'. Este artigo responde a essas questões, com as recomendações adequadas para as definições mais comuns da Cloudflare associadas aos Core Web Vitals.

Free vs. Pro: vale a pena o upgrade?

Speed > Optimization

Polish

O Polish otimiza as imagens alojadas no domínio na Cloudflare: comprime-as, remove metadados e pode convertê-las para WebP. Para um guia completo sobre otimização de imagens, consulte otimizar imagens para os Core Web Vitals.

Ficheiros de imagem mais pequenos melhoram normalmente o Largest Contentful Paint ao encurtar o image resource load duration. Contudo, como o LCP depende de múltiplos fatores além do tempo de carregamento das imagens, não espere melhorias drásticas.

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

Mirage (descontinuado)

A Cloudflare descontinuou o Mirage a 15 de setembro de 2025 e desativou-o automaticamente em todos os domínios. Os browsers modernos já são compatíveis de forma nativa com lazy loading através do atributo loading="lazy", o que torna desnecessária a abordagem por JavaScript do Mirage.

O Mirage otimizava as imagens com base nas condições da rede. A implementação era 'lenta por conceção': bloqueava as imagens até medir a velocidade da rede. Este bloqueio podia causar Layout Shifts e, ironicamente, um Largest Contentful Paint mais lento.

Recomendação: Esta definição já não existe. Se a vir num guia antigo, ignore-a.

Speed Brain

O Speed Brain usa a Speculation Rules API para acelerar o Time to First Byte através do prefetch de navegações futuras. As Speculation Rules são extremamente eficazes a 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 usa atualmente o nível de eagerness conservative, que só faz prefetch quando o utilizador está prestes a clicar num link.

Não recomendo depender do Speed Brain: configurar speculation rules manualmente é fácil e muito mais eficaz do que a abordagem padronizada da Cloudflare. A configuração manual permite definir os próprios níveis de eagerness, escolher URLs específicos e recorrer a prerendering em vez de apenas prefetch.

Recomendação: Desative e configure as speculation rules manualmente. Se não as for configurar por si próprio, manter o Speed Brain ativo é melhor do que não ter speculation rules de todo.

Cloudflare Fonts

O Cloudflare Fonts automatiza o self-hosting de fontes. É uma excelente ideia: fazer self-hosting de recursos críticos elimina novas ligações externas que, por definição, são mais lentas do que reutilizar a ligação já aberta ao site no proxy da Cloudflare.

É mais eficaz dedicar 15 minutos a configurar manualmente o self-hosting dos ficheiros de fontes. Infelizmente, muitos CMS não o permitem. 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 com o APO ativo.

Recomendação: Desative por predefinição; ative apenas se o self-hosting manual não for viável.

Early Hints

Os Early Hints aceleram a entrega de recursos críticos (como estilos, fontes ou imagens), sugerindo-os antes de o conteúdo HTML propriamente dito ser enviado para o browser. Para enviar um resource hint através da Cloudflare, esta lê os headers de resposta e extrai daí os resource hints.

Se tem facilidade em enviar resource hints nos headers de resposta HTTP, recomendo vivamente a ativação desta funcionalidade. No entanto, tenha em conta que os resource hints nos headers ficam muito mais escondidos da equipa de desenvolvimento do que os resource hints no <head> da página. Se ficarem mal configurados, podem abrandar o site em vez de o acelerar. Use, por isso, com precaução. Apesar de estarem disponíveis há anos, a taxa de adoção dos Early Hints continua abaixo dos 3%, de acordo com o Web Almanac de 2025.

Recomendação: Ative apenas se estiver a enviar corretamente os headers de resource hints.

Auto Minify

A Cloudflare consegue minificar HTML, CSS e JavaScript em tempo real. 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 ficheiro.

Recomendação: Ative a minificação de HTML. Para CSS e JavaScript, a minificação em build time (durante o processo de deploy) traz melhores resultados do que a abordagem em tempo real da Cloudflare. Se não tiver um processo de build, ativar as três opções não traz problemas.

Rocket Loader

O Rocket Loader adia todo o JavaScript numa página web: retém os scripts temporariamente e injeta-os na página momentos depois. É um truque agressivo (ou engenhoso, dependendo da perspetiva) que exige uma série de verificações e hacks para garantir que funciona em todos os browsers. Além disso, esconde os scripts do preload scanner, um mecanismo concebido para acelerar o carregamento de recursos críticos.

Pelos motivos acima, é evidente que não sou adepto de ativar o Rocket Loader às cegas. Os scripts devem ser planeados consoante a sua importância: os scripts críticos têm de carregar e executar cedo, enquanto os não essenciais podem esperar até o browser estar inativo.

O Rocket Loader da Cloudflare não faz isso. Retém todos os scripts e, a certa altura, injeta-os sem qualquer consideração pela sua importância. Limita-se a priorizar outros recursos em relação aos scripts, como o elemento de LCP, fontes e estilos. Pior ainda: o Rocket Loader usa o event handler unload, uma API descontinuada que impede a Back-Forward Cache (bfcache) do browser de funcionar. Isto significa que navegar para a frente e para trás vai forçar o recarregamento total da página em vez de restaurações instantâneas.

Se o seu CMS não permite o adiamento de scripts nem um controlo mais refinado dos tempos de execução, o Rocket Loader pode ser a melhor alternativa. Mas, para a maioria dos sites, planear o carregamento dos scripts manualmente é muito mais eficaz.

Recomendação: Desative e planeie os scripts manualmente. Ative apenas se não tiver outra forma de adiar ou controlar a execução de scripts.

Automatic Platform Optimization para WordPress

O APO da Cloudflare guarda páginas inteiras em cache nos seus servidores de edge, uma técnica conhecida como full-page edge caching. Quando bem implementado, melhora o Time to First Byte (e, por consequência, o LCP e o FCP) para determinado tipo de visitantes!

No entanto, há um senão. O full-page edge caching tem muitas vezes de ser ignorado (bypass) de forma automática. Por exemplo, quando um utilizador inicia sessão ou adiciona artigos ao carrinho, o APO desativa-se automaticamente porque o conteúdo da página passa a ser personalizado. A partir daí, servir uma página genérica em cache deixa de ser opção. Como o APO tem de funcionar para todo o tipo de sites, a cache sofre bypass muito mais vezes do que o necessário no seu site. É por isso que configurar a cache manualmente é quase sempre mais eficaz do que o APO da Cloudflare.

Recomendação: Ative o APO ou, melhor ainda, configure as suas próprias regras de full-page edge caching para um controlo superior sobre quando a cache sofre bypass.

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

Ativar o HTTP/2, o HTTP/2 to Origin e o Enhanced HTTP/2 Prioritization é uma decisão óbvia. O HTTP/2 é uma evolução enorme face ao antigo protocolo HTTP/1.1. Traz inúmeras vantagens, mas a principal é eliminar o velho efeito de escada ao permitir o envio de múltiplos ficheiros em paralelo pela mesma ligação. O HTTP/2 existe há 10 anos e é amplamente compatível com browsers e servidores!

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

HTTP/3 (com QUIC)

O HTTP/3 com QUIC é ainda mais rápido do que o HTTP/2 graças a melhorias no estabelecimento da ligação e na latência. O HTTP/3 permite o envio independente de múltiplos streams, mesmo que um deles sofra atrasos. O QUIC combina os handshakes de transporte e de encriptação, o que reduz o tempo de ligação. O resultado é um TTFB até 10% mais rápido! Segundo o Web Almanac de 2025, 38% dos sites já são compatíveis com HTTP/3.

Recomendação: Ative.

Compressão Brotli

O Brotli é um algoritmo de compressão que gera ficheiros mais pequenos do que o Gzip. A Cloudflare ativa o Brotli por predefinição em todos os planos. Certifique-se de que se mantém ativo. De acordo com o Web Almanac de 2025, 46% dos pedidos servidos por CDN já usam compressão Brotli.

Recomendação: Mantenha ativo (vem ligado por predefinição).

0-RTT Connection Resumption

O 0-RTT Connection Resumption acelera as ligações seguras ao ignorar o handshake inicial quando um utilizador regressa ao site. Recorre a chaves de encriptação guardadas previamente, permitindo o envio imediato de dados, o que reduz a latência e melhora o tempo de carregamento da página.

Recomendação: Ative.

Automatic Signed Exchanges (descontinuado)

As Signed Exchanges (SXGs) permitiam que o Google Search fizesse prefetch do seu conteúdo salvaguardando a privacidade do utilizador. As SXGs conseguiam melhorar o LCP em cerca de 450 ms para visitantes vindos dos resultados do Google Search.

No entanto, a Cloudflare descontinuou as SXGs em outubro de 2025. A funcionalidade foi removida e já não está disponível. Quem a tinha ativada viu-a ser desligada automaticamente. O Speed Brain (Speculation Rules) é a alternativa mais próxima para prefetch, embora funcione apenas para navegações no mesmo site, e não para prefetching cross-origin a partir do Google Search como as SXGs faziam.

Recomendação: Esta definição já não existe.

Scrape Shield

O Scrape Shield protege o conteúdo do site. Embora possa parecer uma boa ideia, sou terminantemente contra ativar qualquer opção do Scrape Shield. Ele funciona através da injeção de JavaScript na página para descodificar o conteúdo previamente ofuscado. Esta cedência na velocidade em troca de esconder conteúdo não faz qualquer sentido: não engana os spammers reais e sobrecarrega os utilizadores legítimos com scripts adicionais que tornam a página mais lenta.

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

Bot Fight Mode e Super Bot Fight Mode

Esta é a definição da Cloudflare mais prejudicial de todas para os Core Web Vitals. Quando ativado, o Bot Fight Mode injeta um script chamado invisible.js em todas as páginas. Este script executa um desafio de browser que acrescenta mais de 2000 milissegundos de tempo de execução de CPU a cada carregamento de página. São 2 segundos completos de bloqueio da main thread antes de a página se tornar interativa.

Na prática, ativar o Bot Fight Mode pode fazer a sua pontuação no PageSpeed cair 20 pontos ou mais. O Super Bot Fight Mode tem exatamente o mesmo problema. A ironia: estes modos foram concebidos para travar bots, mas penalizam qualquer utilizador real que visite o site.

Recomendação: Desative quer o Bot Fight Mode, quer o Super Bot Fight Mode. Se precisa de proteção contra bots, use antes regras de WAF ou rate limiting da Cloudflare. Estas opções não injetam JavaScript do lado do cliente.

Caching > Configuration

Purge Cache

Limpar a cache invalida todos os ficheiros guardados em cache pela Cloudflare, incluindo folhas de estilo, JavaScript, imagens e até caches de página inteira. E embora o Purge Cache não seja tecnicamente uma definição, deixo o aviso: limpar a cache vai deixar o site mais lento até a cache ser reconstruída!

Recomendação: Evite limpar toda a cache, se possível. Limpe apenas os ficheiros afetados!

Caching Level

O Caching Level determina como a Cloudflare lida com query strings. Convém analisar com atenção esta definição.

A opção 'mais rápida' é 'Ignore query string'. Entrega o mesmo recurso independentemente da query string. Só é uma boa escolha se tiver 100% de certeza de que o site não usa query strings. Nesse caso, quaisquer query strings adicionadas por terceiros são ignoradas.

A opção 'Standard' serve um ficheiro em cache diferente para cada query string diferente. É a predefinição da Cloudflare, mas, combinada com full-page edge caching e parâmetros de tracking (como os parâmetros UTM), esta definição pode provocar cache mismatch e uma taxa inferior de cache hit ratio! Considere remover parâmetros de tracking com Cloudflare Workers para solucionar isto.

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

Browser Cache TTL

O Browser Cache TTL indica ao browser durante quanto tempo pode guardar recursos estáticos em cache. Os recursos em cache podem ser servidos diretamente pelo browser e ficam disponíveis muito mais depressa do que os recursos remotos da rede. Isso significa que um Browser Cache TTL curto invalidaria a cache do browser com frequência, reduzindo o cache hit ratio. Assim, a menos que os seus ficheiros estáticos mudem com frequência, configure esta definição para o valor máximo.

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

Development Mode

Enquanto estiver ativo, o Development Mode faz bypass a toda a cache da Cloudflare. Pode ser tentador ativá-lo durante o desenvolvimento. Por favor, não o ative: isso também desativa a cache para todos os outros visitantes. Em alternativa, configure um domínio de desenvolvimento próprio para programar ou exclua-se da cache da Cloudflare criando regras de cache.

Recomendação: Não ative!

Caching > Tiered Cache

O Tiered Cache reduz o número de pedidos ao seu servidor de origem e aumenta o cache hit ratio ao instruir a Cloudflare a procurar primeiro ficheiros sem cache nos seus próprios servidores. Isto reduz ainda mais a carga no servidor de backend e liberta recursos adicionais.

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

Entre os sites monitorizados pelo CoreDash, os que utilizam uma CDN bem configurada apresentam um TTFB no p75 55% mais rápido face aos que não usam CDN. A combinação de HTTP/3, Brotli e tiered caching da Cloudflare faz uma diferença mensurável no terreno. Use Real User Monitoring para verificar se a sua configuração da Cloudflare está mesmo a funcionar para os seus utilizadores.