Cache de página completa no PrestaShop: quando serve e o que deixar de fora

Sempre que alguém abre uma página de produto, o PrestaShop arranca, consulta a base de dados dezenas ou centenas de vezes, monta o modelo e devolve o HTML. Para o visitante seguinte que abre a mesma página, repete exatamente o mesmo trabalho. A cache de página completa guarda esse HTML da primeira vez e serve-o diretamente nas seguintes, sem executar o PrestaShop.

A diferença no tempo de resposta do servidor pode ser enorme. Mas uma loja não é um blog: tem carrinho, sessão, preços por cliente e um banner de cookies. Pôr em cache o que não se deve é a forma mais rápida de mostrar a um cliente o carrinho de outro.

As caches que o PrestaShop já tem (e em que se distingue)

• Cache de modelos Smarty: guarda os modelos compilados. Acelera a montagem, mas o PrestaShop continua a ser executado em cada visita.
• Cache de objetos ou consultas (Memcached, Redis, APCu): guarda resultados de consultas. Menos carga na base de dados, mas o PHP continua a ser executado.
• OPcache: guarda o PHP compilado. Imprescindível, e não tem nada a ver com o HTML.
• Cache de página completa: guarda o resultado final. É a única que evita executar o PrestaShop.

Não competem: somam-se. Uma loja bem montada tem sempre OPcache, e cache de consultas e de página conforme o tráfego e o catálogo.

Que páginas se podem pôr em cache

A regra prática: põe-se em cache para o visitante anónimo e sem carrinho. Assim que há sessão de cliente ou produtos no carrinho, a página é gerada normalmente.

O que é preciso resolver antes de a ativar

Partes dinâmicas dentro de uma página que vai para cache

A página de produto é igual para todos, mas o contador do carrinho no cabeçalho não. Também não o «Olá, Marta» nem os preços, se tiver grupos de clientes com tabelas de preços diferentes. Há duas formas de o resolver: não usar cache para quem tem sessão ou carrinho, ou carregar essas partes depois por AJAX. A primeira é a mais segura.

Preços por grupo, país ou moeda

Se um cliente B2B vê outros preços, nunca deve receber a versão em cache do anónimo, nem o contrário. O mesmo com moedas e países que alteram impostos: ou se guarda uma versão por combinação, ou essas visitas não vão para cache.

Telemóvel e computador

Se o seu tema gera HTML diferente para telemóvel, precisa de versões separadas por dispositivo. Se for um tema responsive puro, basta uma versão.

Cookies e consentimento

É o ponto mais esquecido. Se o seu banner de cookies decide no servidor que scripts são impressos, a primeira página em cache «congela» a decisão de quem a gerou. Um visitante que aceitou tudo gera a página com os píxeis ativos, e o seguinte, que ainda não decidiu, recebe-os na mesma.

As soluções habituais: o banner aplica o bloqueio no navegador, sobre uma página igual para todos, ou a cache guarda versões separadas conforme o estado do consentimento.

Invalidar: o verdadeiro problema

Pôr em cache é fácil. O difícil é saber quando uma página guardada deixou de estar certa. Numa loja isso acontece a toda a hora:

• Muda um preço ou uma descrição.
• Ativa uma regra de carrinho ou um preço específico.
• Um produto esgota com uma encomenda.
• Edita uma categoria, um fabricante ou uma página CMS.

Se a cache não der por isso, os clientes veem o preço antigo ou um produto «disponível» que já não está. Há duas estratégias: expiração por tempo (a página vale uma hora e depois é regenerada) e limpeza por evento (ao guardar um produto, limpa-se o que o afeta). O correto é combiná-las: limpeza quando muda alguma coisa e expiração como rede de segurança.

E algo que convém saber: as alterações que não passam pelo back office, como uma importação por SQL direto ou um ERP que escreve na base de dados sem usar a API, não disparam nenhum evento. Se o seu stock entra assim, precisa de limpar a cache no fim de cada sincronização.

Quando não compensa

• Lojas com quase todo o tráfego identificado, como um B2B em que todos iniciam sessão: a percentagem de acertos será baixa.
• Catálogos que mudam a cada poucos minutos por sincronização com fornecedores: a cache é limpa antes de servir alguma coisa.
• Um servidor lento por outra causa: uma consulta mal indexada ou um módulo que chama uma API externa em cada página. A cache disfarça isso para o anónimo, mas o cliente que compra continua a sofrê-lo no checkout, que é onde importa.

Primeiro, uma base atualizada

Uma cache de página sobre PHP 7.x e PrestaShop 1.6 continua a servir depressa os anónimos, mas o carrinho e o pagamento, que nunca vão para cache, continuam igualmente lentos. Com PHP 8, OPcache bem configurado e o PrestaShop em dia, a parte que não pode ir para cache já é muito mais rápida. Por isso, numa loja muito desatualizada, atualizar costuma ser o primeiro passo de desempenho e a cache o segundo.

Checklist antes de a ativar

• OPcache ativo e com memória suficiente.
• Carrinho, encomenda, pagamento, conta e controladores de módulos excluídos.
• Sem cache para visitantes com sessão ou carrinho, ou com partes dinâmicas por AJAX.
• Teste de consentimento em duas janelas privadas.
• Teste de preço: mude um e confirme que a página de produto o reflete.
• Teste de stock: encomende a última unidade e veja a página de produto.
• Limpeza no fim de cada sincronização externa.

Como resolver no PrestaShop

O All In One Cache gere três caches a partir de um painel: página completa em disco, consultas SQL em Redis (PrestaShop 8 ou superior, com as tabelas de encomendas, carrinhos, sessões e stock bloqueadas de origem) e OPcache. Na de página decide o que fica de fora, incluindo URL por expressão regular, pode separar versões por dispositivo e a limpeza está ligada ao PrestaShop: ao guardar um produto, uma categoria, um preço específico, uma regra de carrinho ou uma página CMS a cache é limpa, e ao validar uma encomenda ou alterar o stock limpa-se a do stock. Também pode limpar um URL concreto ou tudo a partir do painel, e vê acertos e falhas. Se preferir que a deixemos configurada e testada na sua loja, existe o serviço de All In One Cache.