A melhor configuração do CloudFlare para passar nos Core Web Vitals

Otimizando Core Web Vitals com Cloudflare: O que habilitar e o que evitar

O Cloudflare oferece uma ampla gama de configurações que podem impactar os Core Web Vitals, tanto positiva quanto negativamente. Enquanto algumas configurações melhoram o desempenho, 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 habilitá-las!

Perguntas Comuns de Configuração do CloudFlare: Eu 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 habilitar esta configuração?'. Este artigo responde a essas perguntas com as considerações apropriadas para as configurações mais comuns do CloudFlare relacionadas aos Core Web Vitals.

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

Speed > Optimization

Polish 

O Polish otimiza imagens hospedadas no seu domínio CloudFlare comprimindo-as, removendo seus metadados e opcionalmente convertendo-as em imagens WebP. 

Tamanhos de imagem menores geralmente melhoram o Largest Contentful Paint melhorando a duração do carregamento do recurso da imagem (image resource load duration). No entanto, como o LCP é influenciado por múltiplos fatores além da duração de carregamento do recurso de imagens, não espere melhorias drásticas!

Recomendação: Habilite e escolha 'Lossy Webp' para obter os melhores resultados.

Mirage

O Mirage otimiza imagens com base nas condições da rede. Embora esta ideia seja nobre, a implementação é 'lenta por design'. Para otimizar as imagens para todas as condições de rede, as imagens na página precisam ser bloqueadas até que a velocidade da conexão de rede tenha sido medida.  Esse bloqueio de imagens pode causar Layout Shifts e, ironicamente, uma pontuação menor de Largest Contentful Paint.

Recomendação: Evite habilitar em qualquer circunstância!

Speed Brain

O Speed brain usa a Speculation Rules API para acelerar o Time to First Byte fazendo prefetch de navegações futuras. Embora as Speculation Rules sejam extremamente eficazes na melhoria de todos os Core Web Vitals, incluindo o Largest Contentful Paint, eu não recomendo ativar este recurso do CloudFlare porque 'auto-configurar' as Speculation Rules é muito fácil e muito mais eficaz do que a solução 'tamanho único' do CloudFlare, mesmo com sua integração RUM! 

Recomendação: Desative e configure as speculation rules manualmente

CloudFlare Fonts

O CloudFlare fonts automatiza o self-hosting de fontes. Esta é uma ótima ideia porque o self-hosting de recursos importantes elimina conexões novas e externas, que por padrão são mais lentas do que reutilizar a conexão já aberta para o seu site via proxy do CloudFlare.

É mais eficaz levar 15 minutos e configurar manualmente arquivos de fonte em self-hosting. Infelizmente, há muitos sistemas CMS que não permitem isso. Nesse caso, ativar as CloudFlare fonts é uma opção perfeitamente válida.

Recomendação: Desative por padrão; ative apenas se o self-hosting 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 hint de recurso através do CloudFlare, o CloudFlare lerá seu cabeçalho de resposta e extrairá hints de recursos de lá. 

Se você se sente confortável enviando hints de recursos em cabeçalhos de resposta html, sugiro fortemente a ativação deste recurso. No entanto, esteja ciente de que hints de recursos podem estar muito mais ocultos para sua equipe de desenvolvimento do que hints de recursos no head da página. Se configurados incorretamente, eles podem tornar as coisas mais lentas em vez de acelerá-las. Portanto, use com cautela.

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

Rocket Loader™

O Rocket loader 'adia' todos os JavaScripts em uma página web retendo-os temporariamente e injetando-os na página novamente 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. Além disso, esse truque 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 em sua importância. Scripts críticos precisam ser carregados e executados 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 os scripts e, em um certo momento, os injeta sem considerar sua importância. O Rocket loader prioriza apenas outros recursos como o elemento LCP, fontes e estilos sobre scripts. Se o seu CMS não permite o adiamento de scripts ou um timing de script mais refinado, o rocket loader pode ser a sua melhor opção.

Recomendação: Desative e agende os 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 armazena páginas inteiras em cache nos seus servidores edge, uma técnica conhecida como full-page edge caching. Quando implementado corretamente, irá melhorar o Time to First Byte (e subsequentemente o LCP e FCP) para um certo tipo de visitante! 

No entanto, há um detalhe. O Full Page edge caching muitas vezes precisa ser contornado 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 em cache genérica 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 melhor controle sobre quando o cache é contornado.

HTTP/2 & HTTP/2 to Origin & Enhanced HTTP/2 Prioritization

Ativar HTTP/2, HTTP/2 to Origin & Enhanced HTTP/2 Prioritization é uma decisão fácil.  HTTP/2 é uma enorme melhoria em relação ao antigo protocolo HTTP/1.1. O HTTP/2 faz muitas coisas, mas o mais importante é que elimina o antigo efeito de escada, 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

HTTP/3 (with QUIC)

O HTTP/3 com QUIC é ainda mais rápido do que o HTTP/2  devido às melhorias na configuração da conexão e na latência. Basicamente, o HTTP/3 permite que múltiplos fluxos sejam enviados de forma independente, mesmo que um deles esteja 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!

Recomendação: ative

0-RTT Connection Resumption

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 os tempos de carregamento da página. 

Recomendação: ative

Automatic Signed Exchanges (SXGs)

Signed exchanges (SXG) permitem que a Pesquisa do Google faça prefetch do seu conteúdo preservando a privacidade do usuário. Isso significa que os resultados mostrados na Pesquisa do Google podem fazer prefetch de alguns recursos-chave (como HTML, JavaScript, CSS, imagens ou fontes) de maneira a preservar a privacidade. Automatic Signed Exchanges melhorarão seu Largest Contentful Paint e Time to First Byte!

Recomendação: ative

Scrape Shield

O Scrape Shield protege o conteúdo do seu site. Embora isso possa parecer uma boa ideia, sou fervorosamente contra a ativação de quaisquer opções do Scrape shield. O Scrape shield funciona injetando JavaScript em sua página para decodificar o conteúdo previamente ofuscado. Esse trade-off em velocidade versus ocultação de conteúdo não faz sentido para mim. Spammers reais não são enganados, enquanto usuários reais recebem scripts extras que deixam a página mais lenta.

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

Caching > Configuration

Purge Cache

Limpar o cache (Purge Cache) irá invalidar todos os arquivos armazenados em cache pelo CloudFlare, incluindo folhas de estilo, JavaScript, imagens e até mesmo caches de página inteira. E embora o purge cache não seja tecnicamente uma configuração, devo alertar sobre a limpeza do cache. Limpar o cache tornará o 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 (eu sei: 'o que há num nome!'). 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 só é uma boa opção se você tiver 100% de certeza de que query strings não são usadas no seu site. Nesse caso, as 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 como parâmetros utm, esta configuração pode causar uma incompatibilidade de cache e uma taxa de acerto de cache (cache hit ratio) mais baixa!

Recomendação: Ignore query string sempre que possível ou standard, evite a opção 'No query string' se possível.

Browser Cache TTL

O Browser Cache TTL diz ao navegador por quanto tempo ele pode armazenar recursos estáticos em cache. Recursos em cache podem ser servidos diretamente do navegador e ficam disponíveis muito mais rapidamente do que os recursos de rede remotos. Isso significa que um browser cache TTL curto invalidaria o cache do navegador frequentemente, diminuindo a taxa de acertos de cache (cache-hit-ratio). Portanto, 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 (Modo de desenvolvimento) ignorará todo o cache do CloudFlare enquanto estiver ativo. Pode ser tentador para você ativar o modo de desenvolvimento durante o desenvolvimento. Por favor, não ative o modo de desenvolvimento, ele também desativa o cache para todos os outros visitantes. Em vez disso, configure um domínio de desenvolvimento onde você pode desenvolver ou exclua-se do cache do CloudFlare configurando regras de cache..

Recomendação: não ative!

Caching > Tiered Cache

O Tiered cache (cache em camadas) reduziu o número de solicitações para o seu servidor de origem e aumenta o cache hit ratio ao instruir o CloudFlare a procurar por arquivos não armazenados em cache nos seus próprios servidores primeiro. Isso reduz ainda mais a carga no seu servidor back-end e libera recursos extras.

Recomendação: ative o smart cache topology