Existe uma categoria de problema em loja virtual que quase sempre tem a mesma causa e quase nunca é diagnosticada corretamente.

O cliente adiciona um produto e o contador do carrinho não muda. O preço exibido não corresponde ao da promoção. Um visitante vê o nome de outra pessoa no cabeçalho. Um produto esgotado continua aparecendo como disponível.

Nenhum desses é bug do WooCommerce. Todos são cache mal configurado — e a explicação está em uma característica que separa lojas de sites de conteúdo: parte das páginas precisa ser diferente para cada visitante.

Este guia explica o que pode ser cacheado em uma loja, o que nunca deve, quais camadas resolvem o que e como diagnosticar quando algo dá errado.

Por que cache é mais delicado em loja

Em um site de conteúdo, a lógica é simples: todo mundo vê a mesma coisa. A página montada uma vez serve a todos os visitantes, e o cache é quase gratuito em complexidade.

Em uma loja, isso deixa de valer para uma parte do site. Carrinho, checkout, área de conta e qualquer elemento que reflita a sessão do visitante precisam ser únicos por pessoa. Entregar a versão em cache de uma dessas páginas significa mostrar a alguém o estado de outra pessoa — no melhor caso um carrinho vazio, no pior um dado que não deveria ser exposto.

A consequência prática é que cache em loja não é uma configuração de ligar ou desligar. É uma configuração de onde ligar e onde não ligar — e é aí que a maioria dos problemas nasce.

O mapa: o que cachear e o que não

Página ou elemento	Cache de página?	Por quê
Home e páginas institucionais	Sim	Iguais para todos
Catálogo e categorias	Sim	Conteúdo comum
Página de produto	Sim, com cuidado	Preço e estoque exigem invalidação
Resultados de busca interna	Geralmente não	Muitas variações, pouco reaproveitamento
Carrinho	Nunca	Único por visitante
Checkout	Nunca	Único por visitante
Minha conta	Nunca	Contém dados pessoais
Contador de itens do carrinho	Nunca	Reflete a sessão
Área de afiliados ou atacado	Nunca	Preço varia por perfil

Os quatro últimos itens são a origem de quase todos os incidentes. Vale conferi-los explicitamente na configuração da sua loja — plugins de cache costumam trazer as exclusões corretas por padrão, mas configurações manuais, regras de servidor e camadas de borda frequentemente as ignoram.

Um cuidado específico: o contador do carrinho

Merece seção própria porque é o problema mais comum e o mais confuso de diagnosticar.

O contador de itens costuma aparecer no cabeçalho, que é parte de todas as páginas — inclusive as cacheáveis. Ou seja: uma página de produto perfeitamente cacheável contém um elemento que não pode ser cacheado.

A solução usual é carregar esse elemento separadamente, por uma chamada que acontece depois do carregamento da página. Quando essa chamada também é cacheada — por engano, por regra de servidor ou por uma camada de borda mal configurada —, o contador congela: o cliente adiciona produtos e o número não muda.

O sintoma é enganoso porque parece problema do carrinho. Não é: o produto foi adicionado corretamente. Só a exibição está desatualizada.

As camadas e o que cada uma resolve

“Cache” designa coisas diferentes que atuam em pontos distintos. Em uma loja, as quatro camadas se complementam:

Cache de página

Guarda o HTML montado e o entrega pronto. É o de maior impacto em catálogo e páginas de produto — e o que exige as exclusões descritas acima.

Cache de objeto

Guarda os resultados das consultas ao banco de dados. É o mais relevante para lojas, porque atua onde o cache de página não pode atuar: carrinho, checkout, área de conta e painel administrativo continuam consultando o banco, e essas consultas repetidas passam a ser resolvidas em memória.

Exige um serviço próprio no servidor, o que hospedagem compartilhada normalmente não permite. É um dos argumentos concretos para um ambiente com acesso ao servidor.

Cache de código

Evita que o PHP recompile a aplicação a cada requisição. Costuma ser configuração de servidor e beneficia todas as páginas, cacheadas ou não.

CDN

Distribui os arquivos estáticos geograficamente. Para lojas com muitas fotos de produto, o ganho é expressivo — mas ela precisa respeitar as mesmas exclusões, e uma CDN cacheando o checkout produz exatamente os problemas descritos aqui. O funcionamento dessa camada está no artigo sobre o que é CDN.

Invalidação: quando o cache precisa ser limpo

A segunda família de problemas vem daqui: a página está cacheada corretamente, mas com conteúdo desatualizado.

Eventos que exigem invalidação:

• Mudança de preço, inclusive por promoção programada.
• Alteração de estoque, especialmente quando um produto esgota.
• Publicação ou edição de produto.
• Início e fim de campanhas com regras de desconto.
• Alteração de frete ou de regras fiscais.

Plugins de cache bem construídos tratam a maior parte disso automaticamente. Os pontos que costumam escapar são as promoções programadas — que começam sem que nada seja editado — e as integrações que alteram preço ou estoque por fora do painel, como sincronizações com ERP.

Um alerta específico de estoque: cachear a informação de disponibilidade por tempo longo em uma loja com poucas unidades pode resultar em venda de produto esgotado. Se o estoque é apertado, vale reduzir o tempo de cache das páginas de produto ou excluir o indicador de disponibilidade do cache.

Como diagnosticar

Um roteiro que resolve a maior parte dos casos:

1. Reproduza em janela anônima. Se o problema não aparece logado e aparece deslogado, é quase certamente cache.
2. Verifique se a página deveria estar cacheada, consultando a lista de exclusões contra o mapa deste artigo.
3. Teste com o cache desativado. Se o problema some, a causa está confirmada.
4. Verifique camada por camada. Plugin, servidor e CDN podem estar cacheando de forma independente — e a exclusão precisa existir em todas.
5. Confira as regras da CDN separadamente. É a camada mais esquecida e a que mais causa problema em loja.
6. Observe o comportamento após uma alteração de preço, para validar a invalidação.

O passo 4 é o que mais gente pula. É comum a exclusão estar correta no plugin e ausente na configuração do servidor ou da CDN — e o resultado é um problema intermitente, que aparece para alguns visitantes e não para outros.

O que o cache não resolve em uma loja

Vale delimitar, porque cache virou resposta automática para lentidão.

Checkout lento continua lento. Ele não pode ser cacheado, então a velocidade depende do servidor, do banco e dos plugins que rodam ali. É a página mais crítica da loja e a que menos se beneficia de cache.

Painel administrativo continua lento, pelo mesmo motivo. Se a lista de pedidos demora, o problema é banco — e cache de página não toca nisso.

Consultas pesadas continuam pesadas. Filtros por múltiplos atributos geram consultas caras que o cache de página só resolve para a combinação exata já visitada.

Para esses casos, o caminho é cache de objeto, ajuste do banco e revisão de plugins — os temas do artigo sobre dimensionamento de servidor para WooCommerce.

Checklist de configuração

• Carrinho, checkout e minha conta estão excluídos em todas as camadas?
• O contador de itens do carrinho carrega separadamente e não está sendo cacheado?
• A CDN respeita as mesmas exclusões que o plugin?
• A invalidação acontece ao alterar preço e estoque?
• Promoções programadas disparam limpeza no início e no fim?
• Integrações que alteram preço por fora do painel invalidam o cache?
• Existe cache de objeto ativo?
• O tempo de cache das páginas de produto é compatível com o giro do seu estoque?

Conclusão

Cache em loja virtual não é uma configuração de ligar ou desligar — é um mapa do que pode e do que não pode ser guardado. Catálogo e páginas de produto sim; carrinho, checkout, conta e qualquer elemento que reflita a sessão, nunca.

Os problemas se dividem em duas famílias: exclusões faltando, que fazem visitantes verem o estado de outros, e invalidação falha, que mantém preço e estoque desatualizados. Ambas são de configuração, não de plataforma.

E vale a delimitação honesta: as páginas mais críticas de uma loja são justamente as que o cache de página não alcança. Para elas, o que resolve é cache de objeto, banco ajustado e recursos reservados. Conheça o Cloud Server para WooCommerce da TBF Host e avalie o ambiente adequado à sua operação.

Perguntas frequentes

Posso usar cache em uma loja WooCommerce?

Sim, e deve. O que não pode ser cacheado são as páginas e elementos únicos por visitante: carrinho, checkout, área de conta, contador de itens e áreas com preço por perfil. Catálogo, páginas de categoria, home e páginas institucionais se beneficiam normalmente do cache de página.

Por que o contador do carrinho não atualiza?

Porque ele aparece no cabeçalho, que faz parte de todas as páginas, inclusive as cacheáveis. A solução usual é carregá-lo separadamente, depois do carregamento da página. Quando essa chamada também é cacheada — por regra de servidor ou pela CDN —, o número congela, embora o produto tenha sido adicionado corretamente.

Quais páginas devo excluir do cache em uma loja?

Carrinho, checkout, minha conta, o contador de itens do carrinho e qualquer área com preço variável por perfil, como atacado ou afiliados. Resultados de busca interna geralmente também não compensam. Essas exclusões precisam existir em todas as camadas: plugin, servidor e CDN.

Por que o preço aparece errado no meu site?

Normalmente é falha de invalidação: a página está cacheada com o conteúdo anterior à alteração. Os casos que mais escapam são as promoções programadas, que começam sem que nada seja editado, e as integrações que alteram preço por fora do painel, como sincronizações com sistemas de gestão.

O que é cache de objeto e por que ele importa em lojas?

É a camada que guarda em memória os resultados das consultas ao banco de dados. Ela importa especialmente em lojas porque atua onde o cache de página não pode: carrinho, checkout, área de conta e painel administrativo continuam consultando o banco, e essas consultas repetidas passam a ser resolvidas em memória.

Cache resolve a lentidão do checkout?

Não. O checkout não pode ser cacheado por precisar ser único para cada visitante, então sua velocidade depende do servidor, do banco de dados e dos plugins que rodam nessa etapa. É a página mais crítica da loja e a que menos se beneficia de cache de página.

A CDN pode causar problemas na minha loja?

Pode, se não respeitar as mesmas exclusões configuradas no plugin de cache. Uma CDN cacheando carrinho ou checkout produz exatamente os problemas de visitantes vendo o estado de outros. É a camada mais esquecida no diagnóstico e uma das que mais causam incidentes intermitentes.

Meu produto esgotado continua aparecendo disponível. É cache?

Provavelmente sim. Se a informação de disponibilidade está cacheada por um período longo e a loja tem estoque apertado, é possível vender um produto já esgotado. Nesses casos, vale reduzir o tempo de cache das páginas de produto ou excluir o indicador de disponibilidade do cache.