Cache de página e CDN (Cloudflare) resolvem pico de acesso na loja virtual? O que o cache absorve e o que sobra para o servidor

Cache de página e CDN absorvem o tráfego que é igual para todo visitante — catálogo, listagem, imagem e CSS —, mas carrinho, checkout, login, busca interna e ‘meus pedidos’ não podem ser cacheados, porque cada visitante vê uma resposta diferente: sobra para o servidor exatamente a parte que fatura.

Cache de página e Cloudflare resolvem pico de acesso na loja virtual?

Resolvem boa parte do pico e não resolvem a parte que vende — as duas coisas são verdade ao mesmo tempo. Cache de página com CDN (Cloudflare ou outra) tira do servidor o tráfego de pico de acesso que é igual para toda a loja. Cache, em uma frase, é guardar uma resposta já pronta para entregar de novo sem refazer o trabalho. E só dá para guardar aquilo que é igual para todo mundo.

Uma página de produto é a mesma para todos os visitantes que chegaram do anúncio: mesmo texto, mesma foto, mesmo preço. Dá para gerar uma vez e servir muitas. Já o carrinho é diferente em cada aba aberta — ele mostra o que aquele visitante colocou dentro. Não existe versão única para guardar.

A consequência prática é o que muda a sua decisão. Com cache de página funcionando, a visita de catálogo que se repete não executa o código da loja nem consulta o banco de dados: sai pronta da borda (o ponto da CDN mais perto do visitante) ou do disco do seu servidor. O que continua batendo no servidor é carrinho, checkout, login, busca interna e área do cliente — pouco volume por cliente, mas o volume que fatura.

Por isso a ordem de gasto importa. Contratar servidor maior sem cache é pagar máquina para refazer, a cada visita, um trabalho que já estava pronto. Este artigo não ensina a configurar plugin nem a clicar em painel da Cloudflare — ensina a decidir o que o cache vai tirar de você e o que vai sobrar.

CDN, cache de página e cache de objeto: qual é a diferença, em linguagem de leigo

São três coisas que o dono da loja ouve como sinônimo e que resolvem problemas diferentes:

• CDN (rede de distribuição de conteúdo). Cópia dos seus arquivos espalhada por vários pontos do mundo, para o visitante baixar do ponto mais perto dele. Resolve imagem, CSS, JavaScript e vídeo — o peso da página.
• Cache de página (full page cache). O HTML pronto — o texto que o navegador transforma em página na tela — guardado inteiro. Quem pede aquela URL recebe o arquivo já montado, sem executar o código da loja (PHP, no caso do WooCommerce) e sem consultar o banco de dados.
• Cache de objeto (Redis ou Memcached). O resultado de uma consulta ao banco guardado na memória, para a loja não perguntar duas vezes a mesma coisa em sequência. Só entra em ação quando a página precisa ser gerada.

Cada um mora em um lugar. A CDN fica antes do seu servidor, na frente de tudo. O cache de página pode ficar na borda (a própria Cloudflare) ou dentro da VPS (nginx, plugin de cache do WooCommerce). O cache de objeto fica sempre dentro da VPS, entre a aplicação e o banco.

Regra de bolso: CDN alivia banda e latência. Cache de página alivia CPU. Cache de objeto alivia banco de dados. Quem tem sintoma de CPU no teto não conserta com CDN.

A confusão custa caro num caso específico e muito comum: o dono ativa a Cloudflare, vê o site acelerar porque as imagens passaram a vir de perto, e conclui que “cacheou a loja”. Na configuração padrão, a Cloudflare não guarda HTML por conta própria — ela guarda os arquivos estáticos, e só passa a guardar HTML se você criar uma regra de cache para isso. Sem essa regra, toda visita continua acordando o código da loja e o banco. No dia do pico, a conta chega igual.

Se você ainda não sabe qual dos três é o seu aperto, o caminho é o checklist de gargalo em WooCommerce. Se o sintoma for consulta lenta e erro de conexão, é gargalo de banco de dados, e a resposta não está no cache de página.

O corte que importa: o que pode sair do cache e o que nunca vai poder

Esta é a tabela mental que permite prever quanto do pico o cache realmente tira. O critério é um só: a resposta é igual para qualquer visitante ou é personalizada? Servir a página cacheada de um visitante para outro mostraria o carrinho errado e, no pior caso, dado pessoal de outro cliente.

Há casos de fronteira que confundem, e vale reconhecê-los antes de descobrir no dia da campanha: preço por grupo de cliente (atacado x varejo), frete calculado por CEP, contador de estoque ao vivo, moeda e multi-idioma. Todos quebram a premissa de “resposta igual para todos”. Ou você separa a versão cacheada por essa variável, ou tira a página do cache, ou tira aquele pedaço do HTML e carrega depois.

Esse “tira o pedaço” tem nome: cache de fragmento. A página inteira é cacheada, e só o bloco que muda — o mini-carrinho no topo, o “olá, Fulano” — é buscado à parte depois que a página abre. Resposta de API pública de catálogo (o endereço que devolve dados de produto em formato de máquina) também costuma aceitar cache com segurança.

O funil na prática fica assim: quem só olha é servido pelo cache e quase não custa; quem compra atravessa o cache por definição e vai até o servidor e o banco. Isso é bom para a sua conta e é o motivo de o cache nunca zerar a carga.

Como saber se o cache está mesmo funcionando (ou se você só acha que está)

Toda resposta que o servidor manda vem acompanhada de campos técnicos invisíveis para o visitante, chamados cabeçalhos de resposta. Um deles diz se aquela página veio pronta do cache (HIT) ou foi gerada na hora (MISS). É a única prova objetiva de que o cache está pegando — e dá para ver sem terminal.

1. Abra a loja no navegador e pressione F12 para abrir o painel de desenvolvedor. Vá na aba Rede (ou Network).
2. Recarregue a página, sem forçar recarga com Ctrl+F5 — recarga forçada pede uma versão nova e atrapalha o teste. Clique na primeira linha da lista, que é o documento HTML da própria página.
3. Procure, entre os cabeçalhos de resposta, o campo cf-cache-status (é o nome que a Cloudflare usa) ou x-cache (usado por outras camadas, inclusive plugin e nginx).
4. Recarregue uma segunda vez. A primeira visita que gera a página é MISS — alguém tem de gerar. A segunda tem de virar HIT. Se nunca vira, o cache não está pegando naquela rota.

Alguns valores enganam quem lê rápido. DYNAMIC e BYPASS significam “não cacheado”: DYNAMIC é “esta URL nem entrou nas regras de cache”; BYPASS é “entrou, mas alguma coisa mandou pular” — em geral um cookie. EXPIRED quer dizer que a página estava no cache, o tempo de vida acabou e ela foi gerada de novo. Nenhum dos três é HIT, por mais que o painel da CDN mostre número bonito de tráfego economizado (esse número inclui imagem e CSS).

Teste em aba anônima e depois logado na sua própria loja. Cache que só funciona deslogado é o comportamento correto e esperado — são os cookies de sessão e de carrinho que devem desligá-lo. Cache que entrega página de usuário logado é bug grave, não otimização: confira se a configuração está mandando ignorar usuário autenticado e as rotas de carrinho, checkout e minha-conta.

E teste página de produto e de categoria, não só a home — o erro de diagnóstico mais frequente deste assunto está na próxima seção. Anote o resultado antes do pico: sem linha de base, você não vai saber se o cache degradou ou se o tráfego cresceu. É o mesmo raciocínio de monitoramento de VPS.

Os casos em que o cache engana e você jura que está protegido

• O cache que nunca aquece. Cada link de campanha chega com um parâmetro diferente grudado na URL (o trecho depois do ?, usado para rastrear a origem do clique). Para o cache, cada variação é uma URL nova — MISS garantido em todas. Solução: configurar a chave de cache para ignorar os parâmetros de campanha.
• O cache que só mede a home. A home está HIT, o dono dorme tranquilo, e a loja inteira está MISS porque a regra nunca cobriu as URLs de produto e categoria.
• O cache que some no deploy. Toda publicação costuma limpar tudo, e a loja volta a gerar cada página do zero. Publicar alteração no meio do pico é apagar a proteção no pior momento possível.
• O cookie que desliga o cache. Chat de atendimento, banner de consentimento ou plugin que grava sessão em toda visita fazem o cache pular todo mundo — e aparece como BYPASS. Só isso já devolve a loja inteira para o servidor de aplicação.
• Tempo de vida curto demais. Cache que expira em poucos segundos quase não é cache: a chance de uma segunda visita cair dentro da janela é pequena, e você paga a geração quase toda vez.
• Robô e raspador de preço com URLs únicas. Tráfego automatizado que varia a URL passa por cima do cache e vai direto ao servidor. Antes de comprar capacidade para atender isso, vale separar cliente de robô nos logs.

O outro lado da moeda é preço e estoque desatualizados. A reação instintiva — encurtar o tempo de vida para todo mundo — é a pior saída, porque destrói o cache inteiro para consertar um produto. O caminho é invalidar por evento: quando o estoque muda, a loja avisa o cache para descartar aquela página específica. Tudo o mais continua servido pronto.

Quando o SwarmBurst não é a resposta: cache e otimização vêm antes do burst

Vale dizer com clareza onde o produto não serve, porque é isso que sustenta o resto do texto. Burst é subir máquinas extras na nuvem pública só durante o pico e removê-las quando a demanda cai — o conceito inteiro está em o que é cloud bursting. Ele não se aplica nestes casos:

• Não existe nem cache básico. Capacidade extra vai atender requisição que nem precisava ser gerada. Cache primeiro, sempre.
• O site é pesado todo dia, não só no pico. Aí o problema é a aplicação — tema, plugin, consulta ruim. Burst não conserta lentidão crônica; ele multiplica a mesma lentidão em mais máquinas.
• O aperto é do banco de dados. Acrescentar nó de aplicação abre mais conexões contra o mesmo banco e pode piorar. O caso está detalhado em gargalo de banco MySQL na VPS.
• O tráfego é robô. Filtrar antes de comprar capacidade, sob pena de pagar nuvem para servir raspador.
• A loja não roda em contêiner nem tem estado fora da máquina. Falta o pré-requisito técnico do burst, e sem ele subir réplica não resolve pico de tráfego: é trabalho de arrumação, não de escala.

A frase honesta, que custa venda e economiza frustração: em loja que nunca cacheou, o cache costuma ser o ganho maior e mais barato disponível, e pode dar conta do pico sem nenhuma máquina extra. O preparo que vem antes de qualquer capacidade adicional está em preparar a loja para a Black Friday sem trocar de servidor.

Quando o burst volta a fazer sentido: cache configurado e o teto ainda estourando

O cenário legítimo é bem específico: HIT confirmado em produto e categoria, publicações congeladas no dia, banco com folga medida durante o movimento — e, mesmo assim, o servidor satura na hora da campanha, com 502 e 504 aparecendo justamente no checkout.

Faz sentido que sobre carga. No dia de campanha, a proporção de visitas que viram compra sobe, e compra não passa pelo cache. O cache tirou o passeio; ficou a parte cara — mais consulta, mais gravação, mais tempo de processamento por requisição.

Para saber quanto sobrou, repita o teste de carga com o cache ligado e mirando só as rotas dinâmicas: adicionar ao carrinho, login, checkout. Esse número é o teto real da sua loja. Comparar com o pico que você espera — nas datas do calendário de picos do e-commerce brasileiro — é o que transforma palpite em decisão.

Se o teto real ficar abaixo do pico, a pergunta seguinte é de quantas horas: poucas horas de aperto por mês favorecem reforço por hora em vez de servidor maior o ano inteiro, e a conta está em aumentar o plano ou pagar reforço só no pico.

É aí que o SwarmBurst entra: um agente instalado no cluster do próprio cliente, com a aplicação na VPS fixa no dia comum e nós extras na nuvem pública só no pico, removidos quando a demanda cai — o desenho desse arranjo está em como configurar cloud bursting no Docker Swarm. Sem migrar a loja para uma plataforma no meio do caminho.

Se você já tem o resultado do teste de HIT e o número do último pico em mãos, é uma conversa no WhatsApp para ler isso junto e dizer se o caso é de cache, de banco ou de teto real.

Quero avaliar o meu caso

Perguntas frequentes

Cache de página funciona para usuário logado?

Cache que entrega página de usuário logado é bug grave. O comportamento correto é cache apenas para usuários deslogados — são os cookies de sessão e de carrinho que devem desligá-lo. Teste em aba anônima e depois logado na sua própria loja para verificar se a configuração está mandando ignorar usuário autenticado e as rotas de carrinho, checkout e minha-conta.

Cache resolve se o gargalo for o banco de dados?

Não. Se o sintoma for consulta lenta e erro de conexão, o problema está no banco de dados, não no cache de página. A resposta é cache de objeto (Redis ou Memcached) entre a aplicação e o banco, ou otimização das consultas. Acrescentar nós de aplicação abre mais conexões contra o mesmo banco e pode piorar.

O cache desaparece quando eu publico uma alteração na loja?

Sim. Toda publicação costuma limpar tudo, e a loja volta a gerar cada página do zero. Publicar alteração no meio do pico é apagar a proteção no pior momento possível. Vale planejar as atualizações para fora das janelas de tráfego alto.

Vale gastar com cache ou já era para contratar mais servidor?

Em loja que nunca cacheou, o cache costuma ser o ganho maior e mais barato disponível. Contratar servidor maior sem cache é pagar máquina para refazer, a cada visita, um trabalho que já estava pronto. Capacidade extra só resolve quando a aplicação e o banco já estão otimizados e o cache já está em pé.