Estratégia de cache no PrestaShop 2026: Redis, Memcached, Varnish, que stack para que loja

Numa loja PrestaShop 8 ou 9 não otimizada, o TTFB (Time To First Byte) ultrapassa correntemente os 800 ms em alojamento partilhado e fica à volta dos 400 ms num VPS de gama média. Efeito direto no LCP (má pontuação nos Core Web Vitals), no crawl budget do Googlebot e na taxa de rejeição. Tudo isto em 2026, quando a referência da Google passou a 200 ms de TTFB e 2,5 s de LCP.

A cache não é um tema de nicho nem reservado aos grandes volumes. É a otimização com maior retorno no PrestaShop, e a que é pior feita: confusão entre cache PHP, cache de objetos, cache HTTP e reverse proxy; configurações por omissão pouco eficazes; pilhas de módulos que se atropelam. Este artigo faz o ponto sobre as quatro camadas de uma stack limpa e dá a regra de decisão Redis, Memcached ou Varnish consoante o perfil da loja.

As quatro camadas de cache de uma loja PrestaShop

Uma loja serve cada página empilhando várias camadas de cache. Conhecer as camadas é evitar empilhar mais do que o necessário: cada camada acrescenta complexidade e pontos de limpeza a controlar.

1. Cache de opcode PHP

O OPcache guarda em cache o bytecode dos ficheiros .php interpretados. Indispensável: sem OPcache, cada pedido ao PrestaShop reinterpreta milhares de ficheiros. Ganho típico: 30 % a 50 % de TTFB. É gratuito, nativo do PHP, e é o primeiro reflexo a validar com php -i | grep opcache em produção. A dimensionar: 256 MB no mínimo para PrestaShop 8/9, opcache.validate_timestamps=0 em produção com reinicialização manual em cada implantação.

2. Cache de objetos (chave-valor em memória)

O PrestaShop guarda em cache certos resultados aplicacionais: sessões de utilizadores, metadados do Smarty (caminhos de templates, configuração dos hooks), resultados de consultas repetitivas. Por omissão, essas caches passam pelo sistema de ficheiros, lento. Em produção séria, deslocam-se para uma base em memória: Redis ou Memcached.

3. Cache HTTP e reverse proxy

Acima do PrestaShop, um reverse proxy (Varnish, cache do NGINX ou edge cache de CDN) interceta os pedidos HTTP e serve respostas pré-renderizadas sem solicitar o PHP. É a otimização com maior alavancagem: ganho típico de 90 % do tempo de servidor nas páginas anónimas em hit de cache.

4. Cache do navegador e CDN

Os recursos estáticos (imagens, CSS, JS, tipos de letra) devem ter cabeçalhos Cache-Control: public, max-age=31536000, immutable e ser servidos por uma CDN. Evidência em 2026, mas mal feita em 40 % das lojas auditadas: max-age demasiado curto, recursos não versionados, variações de cache mal configuradas.

Redis ou Memcached: a decisão na prática

Na cache de objetos, dominam duas escolhas: Redis e Memcached. O debate «qual é mais rápido» está ultrapassado: os dois excedem largamente as necessidades de uma loja PrestaShop. A verdadeira diferença está noutro lado.

Memcached

• Mais simples, menos funcionalidades, menos superfície de ataque e menos armadilhas de configuração.
• Excelente para cache efémera chave-valor pura.
• Sem persistência em disco: um reinício esvazia tudo, o que produz um thundering herd transitório no PHP-FPM.
• Sem estruturas avançadas (listas, sorted sets, pub-sub): uso limitado à cache estrita.

Redis

• Mais rico: estruturas de dados (lists, sets, sorted sets), pub-sub, scripting Lua.
• Persistência opcional (RDB ou AOF): sobrevive aos reinícios.
• Usado muito para além da cache do PrestaShop: sessões em vários servidores, fila do Symfony Messenger, rate limiting.
• Configuração de memória a vigiar (maxmemory, política de eviction), senão consome mais do que o previsto.

Regra prática de 2026: o Redis é a escolha por omissão. O Memcached continua relevante se a loja é voluntariamente minimalista e as únicas necessidades são cache de objetos pura. Qualquer loja que preveja a prazo uma fila de tarefas, rate limiting de API ou sessões partilhadas entre servidores ganha em partir logo para o Redis.

Quando o Varnish faz sentido (e quando não)

O Varnish (ou a cache de página completa do NGINX) é a otimização com maior alavancagem no PrestaShop: serve as páginas anónimas em poucos milissegundos em vez de 400 a 800 ms. Mas o Varnish não muda o jogo em todas as configurações.

Casos em que o Varnish muda tudo

• Tráfego maioritariamente anónimo: visitantes não autenticados, sem preços personalizados por cliente, sem testes A/B com chave no servidor. Catálogo B2C de grande público.
• Volume elevado concentrado em poucos URL: uma página inicial, 50 categorias, 500 páginas de produto representam 80 % do tráfego. A cache faz o essencial do trabalho.
• Pico sazonal previsível: Black Friday, saldos. O Varnish absorve o tráfego sem saturar o PHP-FPM.

Casos em que o Varnish é uma armadilha

• Loja B2B com autenticação obrigatória: cada página é personalizada (preços por grupo de clientes, multiutilizador, orçamentos em curso). O Varnish só serve as páginas públicas (raras) e a complexidade ultrapassa o ganho.
• Personalização do lado do servidor: recomendações por IA por utilizador, testes A/B no servidor, preços dinâmicos. A cache de página completa torna caduca toda a personalização.
• Tráfego anónimo disperso por milhares de URL de cauda longa: se cada URL é visitado uma vez por dia, o hit ratio fica baixo e o Varnish não traz nada.

A alternativa edge cache de CDN

Em 2026, as Cache Rules da Cloudflare, o Permacache da BunnyCDN, a Fastly e outras edge caches fazem o trabalho do Varnish ao nível da CDN, sem servidor adicional. Vantagem: sem camada a manter, distribuição geográfica, integração nativa com WAF. Inconveniente: a limpeza fina é menos flexível do que no Varnish, e o custo pode subir nos grandes volumes. Em 80 % das lojas de média dimensão, a edge cache de CDN tornou-se uma alternativa superior a um Varnish auto-alojado.

Custo real e retorno de uma stack de cache limpa

Custo

• OPcache: 0 €. Ativar e dimensionar bem.
• Redis: 0 € em local (mesmo servidor que o PHP-FPM) a 15 a 30 € por mês num VPS dedicado (Hetzner CX11) ou Redis gerido (Upstash, Redis Cloud) a partir de 10 € por mês.
• Varnish: 0 € em código aberto, mas 1 a 3 dias de instalação e afinação por um administrador de sistemas competente. A orçamentar em tempo, não em licença.
• Edge cache de CDN: Cloudflare Pro a 25 dólares por mês, BunnyCDN cerca de 1 dólar por GB transferido, Fastly a partir de 50 dólares por mês em função do uso.
• Implementação inicial: 2 a 5 dias de desenvolvimento numa loja normal (configuração, testes, limpeza automática por webhook do PrestaShop).

Retorno medido

Em auditorias de lojas PrestaShop 8 de média dimensão depois da implantação de uma stack de cache limpa:

• O TTFB passa de 600 a 800 ms para 80 a 150 ms em hit de cache.
• O LCP desce de 3,2 s para 1,4 s numa página de produto anónima.
• A taxa de rejeição em telemóvel baixa 12 % a 18 % em média.
• A conversão em telemóvel sobe 6 % a 12 %.
• O crawl budget da Google duplica, o que se traduz em 4 a 8 semanas por 15 % a mais de URL indexados.

O custo de oportunidade de não montar uma cache limpa ultrapassa muitas vezes 1 % das vendas anuais. Uma loja com 1 milhão de euros por ano perde tipicamente 10 a 20 mil euros por ano em desempenho degradado.

As armadilhas a evitar

1. Empilhar módulos de cache sem coerência

Muitas lojas acumulam: módulo oficial de cache do PrestaShop, módulo Redis de terceiros, módulo Varnish separado, plugin de CDN. Sem hierarquia clara, as caches invalidam-se mal entre si e alguns hits anulam os outros. É preciso uma única política de cache documentada, com um esquema claro de limpeza em cascata.

2. Gerir mal a limpeza por evento

Quando um preço muda, um stock se atualiza ou um atributo de produto é alterado, a página em causa tem de ser limpa. O PrestaShop não tem hook unificado: é preciso ligar actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter e disparar a limpeza correta (PURGE no Varnish, DEL no Redis, API da CDN). Sem isso, o visitante vê um preço obsoleto, o que pode cair sob a diretiva Omnibus e o Decreto-Lei n.º 70/2007.

3. Guardar em cache páginas personalizadas

O carrinho, a conta de cliente, o checkout e qualquer página com dados do utilizador nunca devem entrar em cache de página completa. A regra do Varnish ou da CDN tem de excluir explicitamente essas rotas (/carrinho, /a-minha-conta, /encomenda, /identidade). Erro frequente: uma loja que guarda tudo em cache por omissão mostra o carrinho de outro cliente. Incidente grave e difícil de diagnosticar depois.

4. Não testar sob carga

Uma cache limpa valida-se sob carga. Uma ferramenta como o k6 ou o Locust permite simular 500 a 1000 visitantes simultâneos e medir o hit ratio, o TTFB sob carga, a estabilidade do PHP-FPM. Sem esse teste, descobrem-se os problemas em produção num dia de pico, o pior momento para corrigir.

5. Esquecer o multiloja e o multimoeda

Uma cache demasiado agressiva numa loja multiloja pode servir a mesma página HTML a todas as lojas, ou servir o preço em euros a um visitante em libras. A chave de cache tem de incluir id_shop, id_lang e id_currency no mínimo. Verificar explicitamente a chave de cache gerada: é o erro silencioso mais caro em perda de conversão.

A stack recomendada por omissão em 2026

Para 80 % das lojas PrestaShop 8 e 9 de média dimensão (200 mil a 5 milhões de euros de vendas por ano):

1. OPcache ativado com 256 MB e opcache.validate_timestamps=0 em produção.
2. Redis como backend da cache de objetos do PrestaShop (sessões, Smarty, metadados). Uma instância chega na maioria dos casos.
3. Edge cache de CDN (Cloudflare ou BunnyCDN) nas páginas de catálogo e CMS públicas, com exclusão explícita das rotas de utilizador.
4. Cache do navegador agressiva nos recursos estáticos (1 ano), versionados por hash através do sistema de assets do PrestaShop.
5. Sem Varnish, salvo caso específico de grande tráfego homogéneo em que a afinação e a manutenção se justificam.

Esta stack implementa-se em 2 a 5 dias, custa 10 a 30 € por mês em custos recorrentes, e traz um ganho de desempenho bem superior ao que se consegue otimizando o código aplicacional. Antes de qualquer otimização de back-end (refundição de módulos, consultas SQL), passar em revista estes cinco pontos continua a ser a primeira etapa rentável.