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

> TTFB de 800 ms, LCP de 3,2 s, crawl budget da Google saturado: numa loja PrestaShop não otimizada, a cache é a otimização com maior retorno em 2026, e a pior feita. As quatro camadas de uma stack limpa, a regra de decisão Redis, Memcached ou Varnish, e a stack por omissão recomendada para 80 % das lojas de média dimensão.

- Página: <https://www.datafirefly.com/pt/2026/08/14/estrategia-cache-prestashop-redis-memcached-varnish-que-stack-2026/>
- Idioma: pt
- Publicado em: 2026-08-14
- Atualizado em: 2026-09-03
- Outros idiomas: [fr](https://www.datafirefly.com/2026/08/14/strategie-cache-prestashop-redis-memcached-varnish-2026/index.md), [en](https://www.datafirefly.com/en/2026/08/14/prestashop-cache-strategy-redis-memcached-varnish-2026/index.md), [es](https://www.datafirefly.com/es/2026/08/14/estrategia-cache-prestashop-redis-memcached-varnish-2026/index.md), [it](https://www.datafirefly.com/it/2026/08/14/strategia-cache-prestashop-redis-memcached-varnish-2026/index.md), [de](https://www.datafirefly.com/de/2026/08/14/cache-strategie-prestashop-redis-memcached-varnish-2026/index.md), [pl](https://www.datafirefly.com/pl/2026/08/14/strategia-cache-prestashop-redis-memcached-varnish-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/08/14/cachestrategie-prestashop-redis-memcached-varnish-2026/index.md)
- Índice: <https://www.datafirefly.com/pt/2026/llms.txt>

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.