Magento 2 CDN: guia de configuração Cloudflare vs Fastly

Uma CDN na frente do Magento 2 pode tirar a maior parte do tráfego estático dos seus servidores, aproximar os assets dos visitantes e absorver picos de bots. Ela também pode quebrar o checkout, mostrar o carrinho de um cliente para outro ou servir CSS velho por uma semana. A diferença está no que você deixa a CDN guardar em cache e em como ela é purgada. Este artigo compara as duas escolhas mais comuns para o Magento Open Source e o Adobe Commerce 2.4.8, Fastly e Cloudflare, e explica como configurar cada uma com segurança.

O que uma CDN deve guardar em cache

Uma storefront Magento tem três tipos de resposta:

• Assets estáticos em /static/: CSS, JavaScript, fontes, imagens do tema. Eles são versionados pelo static file signing, então a URL muda a cada deploy. Seguro guardar em cache por muito tempo.
• Media em /media/: imagens de produto, imagens de categoria, uploads do CMS. Mudam pouco, e as imagens de catálogo redimensionadas têm seus próprios caminhos de cache. Seguro guardar em cache por muito tempo.
• Respostas HTML e de API: páginas, chamadas AJAX, REST e GraphQL. Algumas são públicas e cacheáveis, muitas são privadas. É aqui que os erros acontecem.

Cachear estáticos e media no edge tem pouco risco e dá a maior parte do ganho de banda. Cachear HTML no edge dá o maior ganho de velocidade para os visitantes, mas só funciona se a CDN entender as regras de cache do Magento: quais páginas são cacheáveis, como variam por customer group e moeda e como purgá-las por tag.

Fastly: um full page cache no edge

O Fastly roda sobre Varnish, e a integração com o Magento vem pelo módulo Fastly CDN (fastly/magento2). No Adobe Commerce em infraestrutura cloud, o Fastly faz parte da plataforma. No Magento Open Source ou no Adobe Commerce self hosted, você instala o módulo e abre sua própria conta no Fastly.

O módulo adiciona o Fastly como opção de aplicação de full page cache. Depois de selecionado e configurado com o service ID e o API token, ele:

• Envia ao seu serviço Fastly um VCL que segue as regras de cache do Magento, parecido com o VCL que o Magento gera para o Varnish.
• Traduz as cache tags do Magento em surrogate keys do Fastly, de modo que o save de um produto purga exatamente as páginas que mostram aquele produto, no edge.
• Trata o cookie X-Magento-Vary para que as páginas sejam cacheadas por contexto.
• Oferece recursos extras no admin, como configurações de otimização de imagem, módulos de edge e regras de bloqueio. Quais estão disponíveis depende do seu plano no Fastly.

Nesse setup o Fastly substitui o Varnish como full page cache. Você não precisa de um Varnish local atrás dele, embora alguns setups mantenham um como shield.

composer require fastly/magento2
bin/magento module:enable Fastly_Cdn
bin/magento setup:upgrade

Configure em Stores, Configuration, Advanced, System, Full Page Cache, escolha Fastly CDN como aplicação de cache, informe as credenciais e depois envie o VCL pelo admin. Teste antes em staging com um serviço Fastly separado. Um upload de VCL errado afeta todo o tráfego de uma vez.

Pontos de atenção com o Fastly

• Os purges são rápidos, mas um purge total esvazia o edge em todo lugar. Evite purges totais automáticos a cada deploy, a menos que seu tráfego aguente o cache frio.
• A taxa de hit depende das mesmas coisas que no Varnish: blocks marcados com cacheable="false" no layout, valores de vary demais e parâmetros de query que tornam cada URL única. Leia o guia de full page cache com Varnish, quase tudo se aplica ao Fastly.
• Mantenha o módulo atualizado junto com a versão do Magento. Ele se engancha na invalidação de cache, e uma versão desatualizada pode deixar páginas velhas no edge.

Cloudflare: estáticos primeiro

O Cloudflare funciona de outro jeito. Ele é um reverse proxy e CDN na frente da sua origem, sem módulo oficial do Magento que mapeie cache tags para purges. De fábrica, o Cloudflare cacheia respostas pela extensão do arquivo e não cacheia HTML. Para o Magento, esse padrão é um ponto de partida razoável: arquivos estáticos e media ficam em cache no edge, e o HTML vai para a sua origem, onde o Varnish o serve.

Um setup comum:

1. O DNS da loja aponta para o Cloudflare em modo proxied.
2. O Cloudflare cacheia /static/ e /media/, com um edge cache TTL longo definido por uma cache rule.
3. O HTML passa direto para a sua origem, onde o Varnish atua como full page cache.
4. O Cloudflare também entrega TLS no edge, proteção contra DDoS e regras de bots.

Por que não cachear HTML no Cloudflare?

Dá para fazer, com cache rules que marcam o HTML como elegível para cache. O problema é o purge e a variação. O Magento não avisa o Cloudflare quando um produto muda, então as páginas em cache ficam velhas até o TTL acabar ou até você purgar na mão. O Cloudflare também não conhece o cookie X-Magento-Vary a menos que você configure custom cache keys, e errar isso significa clientes de um grupo vendo os preços de outro grupo. Alguns módulos de terceiros ligam os purges do Magento à API do Cloudflare. Se for por esse caminho, teste com cuidado os estados logado, customer groups, moedas e o carrinho. Para a maioria das lojas, manter o HTML no Varnish e usar o Cloudflare para estáticos, media e proteção é o setup mais seguro.

Configurações do Cloudflare que dão problema

• Rocket Loader muda a forma como o JavaScript carrega. Ele conflita com o RequireJS em temas Luma e com os scripts de inicialização inline que o Magento usa. Mantenha desligado na loja.
• Email obfuscation e outros recursos de reescrita de HTML podem alterar templates do Knockout ou JSON inline. Se algo quebra só através do Cloudflare, tente desligar isso.
• Regras de cache everything que incluem /checkout/, /customer/, /rest/ ou /graphql sem um bypass cuidadoso vão vazar dados privados. Nunca cacheie esses caminhos.
• Challenges de proteção contra bots em caminhos de API podem quebrar integrações e callbacks de pagamento. Exclua caminhos de webhook e de API dos challenges.

IP real do visitante atrás de uma CDN

Com qualquer CDN na frente, o seu servidor vê os endereços IP da CDN como se fossem o cliente. Os recursos do Magento que dependem do IP remoto, como restrição de IP do admin, rate limiting e checagens antifraude em extensões de pagamento, passam a ver o endereço errado. Corrija no web server. Para o Cloudflare, o nginx pode confiar nos ranges do Cloudflare e ler o header deles:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header CF-Connecting-IP;

Isso é só um trecho. O Cloudflare publica a lista completa de ranges IPv4 e IPv6, e você deve incluir todos e manter a lista atualizada. O Fastly também publica seus ranges e envia o IP do cliente no header Fastly-Client-IP. O guia de configuração do nginx cobre o setup do realip com mais detalhe.

Servindo estáticos e media de um host separado

O Magento consegue montar URLs de estáticos e media em um host diferente do da storefront, usando as configurações de base URL para static view files e media files em Stores, Configuration, General, Web, Base URLs. Os config paths são web/unsecure/base_static_url, web/secure/base_static_url, web/unsecure/base_media_url e web/secure/base_media_url.

bin/magento config:set web/secure/base_static_url https://cdn.example.com/static/
bin/magento config:set web/secure/base_media_url https://cdn.example.com/media/

Isso é útil com uma pull CDN que não está na frente do site todo. Se o domínio inteiro já passa pelo Cloudflare ou pelo Fastly, um host separado adiciona uma consulta DNS e uma conexão TLS por pouco ganho. Com HTTP/2 e HTTP/3, servir tudo de um host só costuma ser mais rápido.

Se usar um host separado, defina headers CORS para fontes na CDN ou na origem. Sem eles os navegadores bloqueiam web fonts de outra origem, e o sintoma é fontes de ícones faltando na storefront.

Deploys e cache busting

O static file signing dá URLs estáticas novas a cada deploy, então a CDN busca arquivos novos sem precisar de purge. Mantenha dev/static/sign habilitado. Arquivos de media não têm URLs versionadas. Se você substituir uma imagem mantendo o mesmo nome de arquivo, purgue esse caminho na CDN.

Depois de um deploy que muda templates, o HTML ainda precisa ser atualizado. Com o Fastly isso é um cache clean do Magento, que dispara o purge. Com o Cloudflare na frente do Varnish, o cache clean do Magento purga o Varnish, e o Cloudflare não entra porque não estava cacheando HTML.

Fastly ou Cloudflare?

• No Adobe Commerce cloud, o Fastly já está lá. Use.
• Se você quer full page cache no edge com purge por tag de verdade, o Fastly com o módulo do Magento é a opção estabelecida.
• Se você quer uma camada simples e barata para arquivos estáticos, media, TLS e proteção, mantendo o Varnish como cache de página, o Cloudflare funciona bem.

Seja qual for a escolha, meça com visitantes reais antes e depois, por exemplo com dados de campo no relatório de Core Web Vitals, e confira se carrinho, checkout e páginas de cliente se comportam corretamente através da CDN.

FAQ

O Cloudflare consegue cachear páginas HTML do Magento 2?

Consegue com cache rules, mas o Magento não purga o Cloudflare quando produtos mudam e preço por grupo exige custom cache keys. A maioria das lojas mantém o HTML no Varnish e usa o Cloudflare para estáticos e media.

Preciso de Varnish se uso Fastly?

Não. Com o módulo do Fastly, ele é a aplicação de full page cache e cuida do cache e dos purges por tag no edge.

Por que o Magento mostra o IP errado do visitante atrás de uma CDN?

O servidor vê a CDN como o cliente. Configure o módulo realip no nginx para confiar nos ranges da CDN e ler o header com o IP do cliente.

Devo ligar o Rocket Loader do Cloudflare no Magento?

Não. Ele muda como os scripts carregam e conflita com o RequireJS e com os scripts de inicialização inline do Magento.

Atendo como freelancer em Magento e Adobe Commerce, incluindo setups de CDN e cache. Se precisar de ajuda com isso, fale comigo.