Varnish instalado, VCL carregada, cache type marcado como Varnish no admin, e a loja continua com o mesmo tempo de resposta de antes. Todo mundo já mexeu no TTL, no grace, no backend timeout. Nada muda.
Antes de culpar o Varnish, vale lembrar uma regra do Magento que a documentação da Adobe diz com todas as letras: se existir pelo menos um bloco não cacheável no layout, a página inteira deixa de ser cacheada. Não é o bloco que sai do cache. É a página.
O teste de dez segundos
A VCL que o Magento gera devolve um cabeçalho de diagnóstico em toda resposta:
curl -sI https://sualoja.com.br/ | grep -i x-magento-cache-debugTrês respostas possíveis, e cada uma aponta para um lugar diferente:
HIT— está cacheando. O problema é outro.MISS— não tinha em cache agora, mas vai guardar. Rode de novo; se virar HIT, tudo certo.UNCACHEABLE— é o nosso caso. O Magento mandouno-storee o Varnish marcou a página como "nem tente" pelos próximos 2 minutos.
Não adianta olhar o Cache-Control por fora: a VCL do Magento reescreve esse cabeçalho para no-store em toda página, de propósito, para o navegador não guardar HTML. Quem responde a pergunta é o X-Magento-Cache-Debug.
O grep que acha o culpado
Na raiz da loja:
grep -rn 'cacheable="false"' vendor app/code app/design --include=*.xmlVai voltar bastante coisa, e boa parte é legítima: no 2.4.8 o próprio core usa o atributo em mais de cem lugares, todos em carrinho, checkout, minha conta e páginas de pedido. Páginas que ninguém quer cachear mesmo.
O que você procura são duas coisas. Primeira, ocorrência em layout de catálogo — catalog_product_view.xml, catalog_category_view.xml — que é o que mata a performance da vitrine. Segunda, e essa é a bomba:
grep -rn 'cacheable="false"' --include=default.xml vendor app/code app/designO default.xml vale para todas as páginas. Um atributo desses ali desliga o full page cache do site inteiro. No core do 2.4.8 não existe nenhum caso assim — se aparecer, é módulo de terceiro ou tema.
Achei. E agora?
Depende do que o bloco faz.
Se o conteúdo é igual para todo mundo, o atributo está ali por preguiça de quem escreveu o módulo. Tire e teste. Em tema ou módulo próprio, edite o arquivo. Em módulo de terceiro, sobrescreva o layout no seu tema em vez de mexer no vendor.
Se o conteúdo muda por cliente (nome, itens do carrinho, lista de desejos), o caminho certo é private content: o bloco vira uma seção declarada em sections.xml e o navegador busca o dado por JavaScript, com o HTML continuando cacheado para todo mundo. Dá mais trabalho e é o único jeito de ter as duas coisas.
Se muda pouco e não é por cliente (um contador, um banner rotativo), use ttl no bloco. Com Varnish, bloco com TTL vira um esi:include, cacheado à parte, e a página continua inteira no cache.
Depois de mexer:
php bin/magento cache:clean layout full_page
curl -sI https://sualoja.com.br/ | grep -i x-magento-cache-debugRode o curl duas vezes. A primeira quase sempre é MISS.
Perguntas rápidas
Como saber se o Varnish está mesmo no meio do caminho?
Se o cabeçalho X-Magento-Cache-Debug aparece na resposta, a VCL do Magento está carregada e o Varnish está respondendo. Se não aparece nenhum, provavelmente as requisições estão indo direto para o PHP.
Posso simplesmente apagar o cacheable=false do módulo no vendor?
Funciona até o próximo composer update, que devolve o arquivo original. O certo é sobrescrever aquele layout no seu tema ou num módulo seu, assim a alteração sobrevive à atualização.
O Hyvä ou o PWA mudam essa regra?
A regra é do Magento, não do tema: quem decide é o layout XML processado no backend. Mudar de tema não faz um bloco marcado como não cacheável voltar a ser cacheado.
Pra conferir na fonte
- Configure a cacheable page (public content) — Adobe Developer
- Private content — Adobe Developer
- Magento_PageCache: varnish6.vcl — Magento no GitHub
- Configure Varnish and Commerce — Adobe Experience League