O botão de cache do painel: ligamos em 5 hospedagens e três esvaziaram o carrinho da loja

Tem um botão no painel de quase toda hospedagem chamado "cache". Ele promete o ganho de velocidade mais barato do mundo: um clique, nada de plugin, nada de mexer em arquivo. Só que cache é uma daquelas coisas que funcionam maravilhosamente bem até o dia em que não funcionam — e quando dão errado numa loja, dão errado no pior lugar possível: no carrinho, no login e no checkout.

Foi por isso que resolvemos testar. Montamos uma loja WooCommerce igual em cinco hospedagens e ligamos o cache de cada painel para ver o que acontecia de verdade.

Como a loja de teste foi montada

Para o teste ter graça, a loja precisava ter as partes chatas de uma loja real: doze produtos com variação de tamanho, estoque controlado, dois cupons ativos, frete calculado por CEP (com uma faixa de frete grátis acima de R$ 199), conta de cliente e checkout em página separada. Nada de tema exótico: WordPress atualizado, WooCommerce na versão corrente de 2026 e um tema leve, sem page builder.

Antes de ligar qualquer coisa, medimos o tempo de resposta do servidor (TTFB) em três pontos: home, página de produto e página de carrinho com um item dentro. Cada medição foi repetida dez vezes, descartando o primeiro acesso para não contar o "aquecimento".

Depois foi a vez de ligar o cache nativo de cada provedor — aquele que já vem no painel, sem instalar nada — e repetir exatamente o mesmo roteiro.

O que cada painel chama de "cache"

Aqui já aparece a primeira confusão. Nas cinco hospedagens, o botão se chama "cache", mas por baixo roda coisa diferente:

• Hospedagem A: cache de página em NGINX, com opção de excluir carrinho e checkout.
• Hospedagem B: Varnish na frente do Apache, com purga automática ao publicar post.
• Hospedagem C: LiteSpeed com o cache do servidor ligado (sem o plugin no WordPress).
• Hospedagem D: cache de página próprio, com uma lista de "URLs que nunca devem ser cacheadas" que o cliente edita na mão.
• Hospedagem E: cache de objeto + página, com tempo de vida padrão de 30 minutos.

Repare que só uma delas (a D) te entrega uma lista editável sem pedir nada ao suporte. Guarde esse detalhe, ele volta mais adiante.

Os números: todo mundo acelerou

Hospedagem	TTFB home antes	TTFB home depois	Carrinho funcionou?
A	0,71 s	0,14 s	Sim
B	0,85 s	0,19 s	Não
C	0,62 s	0,11 s	Sim
D	0,90 s	0,22 s	Não
E	0,78 s	0,17 s	Não

Nenhuma surpresa na coluna da esquerda: cache de página entrega ganho grande, sempre na casa de 70% a 80% no TTFB. Quem vende hospedagem adora esse número, e com razão — ele é real.

O problema mora na última coluna.

Onde o carrinho quebrou

Três das cinco hospedagens passaram no teste de velocidade e falharam no teste de loja. O sintoma foi sempre parecido, o que ajuda a entender o padrão:

1. O cliente adicionava um produto e o contador do carrinho mostrava "1".
2. Ao navegar para outra página, o contador voltava para "0".
3. Ao voltar para o carrinho, o item tinha sumido.

Em uma das hospedagens (a E), o comportamento foi ainda mais cruel: o carrinho funcionava para quem estava logado, mas não para visitante. Como a maioria das primeiras compras é feita por visitante, o lojista poderia passar semanas achando que a loja estava normal — e só descobrir o estrago na hora de olhar o funil de conversão e ver zero pedidos.

Na hospedagem B, o cupom aplicava em um momento e desaparecia na atualização seguinte. Na D, o estoque ficou travado: o produto aparecia como esgotado mesmo com 40 unidades disponíveis, porque a página de produto foi cacheada com uma informação que muda a cada minuto.

Por que isso acontece

Vale entender o mecanismo, porque ele explica por que "ligar o cache" não é decisão de um clique só.

O WooCommerce guarda o carrinho em cookie e em sessão no servidor. Se o servidor de cache entrega a mesma página HTML para todo mundo, ele pode entregar junto um HTML gerado para o visitante anterior — com o carrinho dele, os cupons dele, o nonce dele. Para não fazer isso, o cache precisa saber ignorar cookies de sessão (woocommerce_cart_hash, wp_woocommerce_session_*), ignorar a página de carrinho, a de checkout e a de "minha conta", e não guardar resposta de requisição com método POST.

Quando o painel não tem essas regras prontas e você não pode adicioná-las, o cache faz exatamente o que prometeu: acelera tudo, inclusive o que não devia.

O que pedir ao suporte antes de apertar o botão

Antes de ligar o cache em uma loja, mande esse roteiro em um único ticket. Resposta vaga é sinal de alerta.

• As páginas de carrinho, checkout e minha conta ficam fora do cache por padrão?
• O cache respeita cookies de sessão do WooCommerce e do usuário logado?
• Existe purga automática quando um produto muda de preço ou de estoque?
• Tem como eu mesmo excluir uma URL específica pela lista de exceções?
• Se algo quebrar, como eu desligo em menos de um minuto?

Essa última pergunta parece óbvia, mas é a que mais gente esquece de fazer. Em duas das hospedagens testadas, o botão de desligar ficava em um submenu diferente do botão de ligar — e uma delas não tinha botão nenhum, só um pedido por ticket.

Se você já ligou e quebrou

O socorro segue uma ordem simples. Desative o cache do painel primeiro, confirme que o carrinho voltou a funcionar, e só depois investigue. Se o painel tiver purge, limpe também o cache de objeto e o de CDN. Faça o teste do carrinho em janela anônima, sem estar logado, porque é assim que o visitante chega. E apague o cache do navegador antes de concluir qualquer coisa — metade dos "continua quebrado" que a gente vê por aí é cache local do próprio navegador do lojista.

O veredito

Cache nativo de painel é boa ideia para blog, site institucional e portfólio: ganho grande, risco baixo. Para loja, ele funciona — em duas das cinco hospedagens funcionou perfeitamente —, mas exige perguntar antes, testar em horário de pouco movimento e ter um plano B à mão.

Se a sua hospedagem não responde direito às perguntas da lista acima, o caminho mais seguro é fazer cache por plugin, dentro do WordPress, com as regras de exclusão do WooCommerce já prontas. Perde um pouco de desempenho em relação ao cache de servidor, mas você vê o que está sendo cacheado e desliga em dois cliques.

Uma loja lenta vende menos. Uma loja com carrinho quebrado não vende nada. Entre os dois problemas, o segundo é bem mais caro.