PrestaShop lento: como descobrir se o problema está no servidor, banco, módulos ou front-end

Uma loja PrestaShop lenta costuma produzir um diagnóstico apressado: “o servidor não aguenta”. Às vezes isso é verdade. Em muitos casos, porém, contratar mais CPU e memória apenas torna um gargalo caro um pouco menos visível. Uma consulta sem índice, um hook executado dezenas de vezes, um módulo que consulta uma API durante a montagem da página ou um script de terceiros pode continuar limitando a experiência mesmo depois da troca de infraestrutura.

A investigação correta começa separando sintomas. Uma página pode apresentar conteúdo rapidamente e travar quando o cliente tenta interagir; pode demorar para receber o primeiro byte, mas responder bem depois disso; pode ser rápida para visitantes e lenta para clientes autenticados; ou degradar somente em horários de pico. Cada cenário aponta para uma camada diferente.

Este guia apresenta um método para localizar o gargalo antes de escolher a correção. O objetivo não é transformar toda loja em um laboratório permanente, mas reunir evidências suficientes para responder a uma pergunta simples: onde o tempo está sendo gasto?

Antes de otimizar, defina o que está lento

“A loja demora cinco segundos” ainda é uma informação incompleta. Esses cinco segundos podem estar concentrados antes da resposta do servidor ou depois que o navegador recebe o HTML.

As primeiras medidas devem separar pelo menos quatro momentos:

Tempo até o primeiro byte (TTFB): inclui rede, processamento no servidor e eventuais esperas até o primeiro byte da resposta. Um TTFB alto direciona a investigação para origem, PHP, banco, módulos ou serviços externos.
Largest Contentful Paint (LCP): indica quando o maior elemento visível foi renderizado. Imagens grandes, CSS bloqueante, fontes e prioridade de recursos influenciam essa métrica.
Interaction to Next Paint (INP): mede a capacidade de resposta às interações. JavaScript pesado, listeners em excesso e tarefas longas podem produzir uma página que “parece pronta”, mas demora a reagir.
Cumulative Layout Shift (CLS): registra mudanças inesperadas de layout, comuns quando banners, imagens e vitrines são inseridos sem espaço reservado.

O Google recomenda, como referência de boa experiência, LCP de até 2,5 segundos, INP inferior a 200 milissegundos e CLS de até 0,1. Esses números não substituem o contexto comercial, mas ajudam a distinguir carregamento, interatividade e estabilidade. Consulte a documentação de Core Web Vitals do Google.

Também é importante testar páginas diferentes. Home, categoria, produto, busca, carrinho e checkout percorrem regras e hooks distintos. Uma média única do domínio pode esconder uma página de produto lenta ou um back office que degrada apenas ao abrir pedidos.

Crie uma linha de base reproduzível

Antes de alterar configuração, módulo ou servidor, registre uma linha de base. Sem ela, a sensação de melhora pode vir apenas de cache aquecido, menor tráfego ou rota de rede diferente.

Uma linha de base mínima deve registrar:

URL e tipo de página testada;
horário e volume aproximado de tráfego;
visitante anônimo ou cliente autenticado;
cache frio e cache aquecido;
TTFB, tempo total e tamanho da resposta;
LCP, INP e CLS quando houver dados reais suficientes;
consumo de CPU, memória, swap e I/O durante o teste;
quantidade e tempo total das consultas ao banco;
versão do PrestaShop, PHP, tema e módulos relevantes.

Faça várias medições, não apenas uma. O valor mediano mostra o comportamento típico; percentis mais altos revelam a experiência ruim que afeta parte dos clientes. Uma página com mediana de 800 ms e p95 de oito segundos não está saudável: ela é apenas rápida na maior parte do tempo.

Camada 1: rede, DNS, TLS e CDN

Se o navegador demora até mesmo para estabelecer a conexão, o problema pode ocorrer antes do PrestaShop. Compare o acesso ao domínio público com uma chamada direta à origem em ambiente controlado. Verifique resolução DNS, tempo de conexão TCP, negociação TLS, redirecionamentos e distância até o servidor.

Sinais comuns dessa camada incluem:

vários redirecionamentos antes da página final;
origem localizada longe da maior parte dos clientes;
falhas intermitentes em uma operadora ou região;
CDN encaminhando todas as requisições à origem sem benefício para arquivos estáticos;
imagens, CSS e JavaScript sem cache de navegador adequado;
certificados, IPv6 ou registros DNS configurados de forma inconsistente.

Uma CDN ajuda a distribuir arquivos estáticos e absorver parte do tráfego, mas não corrige automaticamente PHP lento ou consultas ruins. Também exige cuidado: carrinho, checkout, conta do cliente e respostas personalizadas não podem ser tratados como páginas públicas indiferenciadas.

Camada 2: servidor, PHP-FPM e armazenamento

Se o TTFB aumenta junto com CPU, fila do PHP-FPM, swap ou espera de disco, investigue a infraestrutura. O ponto não é observar apenas “quanto há de RAM”, mas entender se algum recurso satura no momento da lentidão.

CPU e processos PHP

CPU elevada pode significar tráfego legítimo, robôs, tarefas agendadas, regeneração de imagens, indexação ou uma rotina cara executada em toda requisição. Verifique se os workers do PHP-FPM estão ocupados, se há fila aguardando processo livre e se o pool está dimensionado para a memória realmente consumida por processo.

Aumentar pm.max_children sem calcular o consumo individual pode trocar fila por falta de memória. Quando o sistema começa a usar swap, a latência frequentemente cresce de forma abrupta.

OPcache

O OPcache armazena bytecode PHP pré-compilado em memória e evita que os scripts sejam carregados e compilados novamente em cada requisição. Confirme se ele está ativo no SAPI que atende o site, se a memória não está esgotada e se há espaço para a quantidade de arquivos da aplicação. A referência oficial está no manual do PHP.

Não copie valores de outra infraestrutura sem medir. Memória insuficiente, excesso de arquivos reiniciando o cache ou uma política de revalidação inadequada podem reduzir o benefício.

Disco e I/O

Backups, logs excessivos, sessões em disco, cache de templates e banco no mesmo volume podem disputar I/O. CPU baixa não significa servidor livre: processos podem estar esperando armazenamento. Observe latência e fila do disco durante o pico, não apenas espaço disponível.

Camada 3: configuração do PrestaShop

Antes de procurar uma falha sofisticada, confirme se a loja não está executando configurações de desenvolvimento em produção.

Na área de desempenho e nos arquivos de configuração, verifique:

modo de produção ativo;
compilação do Smarty sem recompilar todos os templates a cada acesso;
cache de templates habilitado;
cache limpo de forma controlada após deploys;
combinações e minificação de arquivos testadas com o tema e os módulos;
módulos de depuração ou barras de desenvolvimento desabilitados;
logs em nível compatível com produção.

A documentação oficial informa que forçar a compilação do Smarty prejudica o carregamento e orienta manter _PS_MODE_DEV_ e _PS_DEBUG_PROFILING_ desativados em produção. Veja as recomendações de otimização do PrestaShop.

Limpar todo o cache a cada poucos minutos também não é estratégia de desempenho. O primeiro conjunto de acessos após a limpeza paga novamente o custo de reconstrução. A invalidação deve estar ligada a mudanças reais de código, tema, configuração ou conteúdo.

Modo debug e profiling: ferramentas diferentes

O modo debug e o profiling nativo são úteis, mas não têm o mesmo objetivo.

_PS_MODE_DEV_ torna erros e informações de desenvolvimento mais visíveis. Ele ajuda a localizar exceções, avisos, falhas de compatibilidade e comportamentos que estavam sendo ocultados por uma página genérica de erro. É uma ferramenta de diagnóstico funcional, não um medidor completo de desempenho.

_PS_DEBUG_PROFILING_ acrescenta informações de profiling ao processamento da página. Dependendo da versão e do fluxo executado, o painel permite observar indicadores como tempo total, memória, consultas SQL, arquivos carregados e execução de hooks. Ele é especialmente útil para comparar duas páginas semelhantes e perceber, por exemplo, que uma delas dispara muito mais consultas ou concentra tempo em determinado hook.

Em instalações que usam config/defines.inc.php, a ativação costuma ser feita alterando temporariamente a constante:

if (!defined('_PS_DEBUG_PROFILING_')) {
    define('_PS_DEBUG_PROFILING_', true);
}

Ao terminar o diagnóstico, restaure obrigatoriamente:

if (!defined('_PS_DEBUG_PROFILING_')) {
    define('_PS_DEBUG_PROFILING_', false);
}

Como usar o profiler sem contaminar o diagnóstico

O profiling adiciona trabalho à requisição. Portanto, seus números não devem ser tratados como a velocidade normal percebida pelo cliente. Use-o para encontrar proporções e diferenças: qual grupo de consultas domina o tempo, qual página dispara mais hooks, qual módulo aparece repetidamente e qual mudança reduz o custo relativo.

Um roteiro seguro é:

reproduzir a lentidão sem profiler e registrar a linha de base;
usar homologação com dados representativos sempre que possível;
se a produção for indispensável, restringir o acesso, escolher uma janela curta e evitar exposição pública das informações;
ativar profiling, carregar uma única página representativa e salvar os resultados;
desativá-lo imediatamente;
formular uma hipótese e repetir a medição normal após a correção.

Não deixe profiling ou modo debug ativos em produção. Além do custo de desempenho, a saída pode expor detalhes técnicos, caminhos, consultas e informações úteis a um atacante. O próprio PrestaShop recomenda ambos desativados no ambiente produtivo.

O que procurar no resultado

Muitas consultas pequenas: pode indicar padrão N+1, consultas repetidas em loops ou hooks executados várias vezes.
Poucas consultas muito lentas: procure índices ausentes, filtros pouco seletivos, ordenações e tabelas grandes.
Tempo concentrado em hooks: relacione o hook aos módulos registrados e teste a contribuição de cada um em homologação.
Memória muito alta: investigue coleções grandes, carregamento desnecessário de objetos, imagens ou exportações feitas dentro da requisição web.
Diferença grande entre páginas: compare módulos, blocos, número de produtos, combinações e serviços externos presentes em cada rota.

O profiler aponta onde investigar; ele não prova sozinho a causa. Uma consulta pode aparecer lenta porque o banco está aguardando disco, e um hook pode estar lento porque chama uma API externa. A próxima etapa deve confirmar a hipótese na camada correspondente.

Camada 4: banco de dados

Lojas acumulam pedidos, carrinhos, conexões, logs, buscas e dados de módulos. Consultas aceitáveis em uma base pequena podem se tornar críticas depois de anos de operação.

Ative o slow query log por uma janela controlada e analise frequência, duração e volume examinado. A documentação do MySQL explica a configuração e os cuidados do slow query log. Não basta escolher a consulta de maior duração: uma consulta de 100 ms executada milhares de vezes pode consumir mais recursos que uma consulta isolada de dois segundos.

Para cada candidata, verifique:

plano de execução com EXPLAIN;
índices usados e linhas estimadas;
filtros por loja, idioma, grupo e estado;
JOIN, ORDER BY e GROUP BY sobre conjuntos grandes;
consultas repetidas com os mesmos parâmetros;
tabelas de log ou módulo que cresceram sem política de retenção;
bloqueios e transações longas.

Evite criar índices por tentativa. Todo índice ocupa espaço e aumenta o custo de escrita. Ele deve responder a uma consulta real, frequente e medida.

Camada 5: módulos, hooks, overrides e serviços externos

Módulos são parte essencial do PrestaShop, mas cada extensão adiciona código a determinados pontos da aplicação. Um módulo pode ser rápido na home e lento na página de produto; outro pode consultar estoque remoto durante o checkout; um terceiro pode executar lógica mesmo quando seu bloco não aparece visualmente.

Em homologação, relacione os hooks mais caros aos módulos registrados. Desabilite um candidato por vez, repita o mesmo teste e compare. Alterar vários componentes simultaneamente impede saber qual mudança produziu o resultado.

Procure especialmente:

chamadas HTTP síncronas sem timeout curto;
APIs de frete, pagamento, recomendação ou ERP executadas durante a renderização;
consultas dentro de loops de produtos e combinações;
carregamento de configurações individualmente em grande volume;
overrides antigos que repetem trabalho do core;
módulos abandonados ou incompatíveis com a versão atual;
tarefas pesadas que deveriam ser executadas por cron ou fila.

Uma integração externa não deve segurar indefinidamente a página do cliente. Defina timeout, comportamento de contingência e cache quando o dado permitir. Processos que não precisam responder imediatamente ao navegador devem ser movidos para execução assíncrona.

Camada 6: tema, imagens e JavaScript

Quando o TTFB está saudável, mas LCP ou INP continuam ruins, concentre-se no navegador.

Uma imagem de destaque sem dimensões adequadas pode dominar o LCP. Vários arquivos CSS bloqueantes atrasam a primeira renderização. Tags de marketing, chats, pixels, testes A/B e widgets podem ocupar a thread principal depois que o HTML já chegou.

Avalie:

tamanho e formato das imagens realmente entregues;
srcset e dimensões adequadas ao dispositivo;
carregamento prioritário da imagem principal e lazy loading fora da primeira tela;
CSS crítico e arquivos que bloqueiam renderização;
quantidade de JavaScript e tarefas longas;
scripts de terceiros por impacto e retorno comercial;
elementos inseridos sem dimensões reservadas;
excesso de módulos visuais na home.

Não use apenas a nota total de uma ferramenta. Observe a recomendação concreta e confirme em dados reais. Uma otimização que melhora o laboratório, mas quebra personalização, rastreamento ou checkout, não é uma melhoria.

Como relacionar sintoma e provável camada

Uma sequência de diagnóstico que evita desperdício

Uma investigação eficiente pode seguir esta ordem:

medir páginas representativas e separar backend de frontend;
correlacionar a lentidão com CPU, memória, swap, disco e workers;
confirmar configurações de produção, cache e OPcache;
usar debug e profiling de forma controlada para localizar consultas e hooks suspeitos;
analisar slow query log e planos de execução;
testar módulos e integrações individualmente em homologação;
revisar imagens, CSS, JavaScript e terceiros;
corrigir uma causa por vez e repetir a linha de base;
monitorar depois do deploy para verificar picos e regressões.

Essa sequência evita duas armadilhas comuns: trocar servidor sem evidência e aplicar dezenas de “otimizações” ao mesmo tempo. Em ambos os casos, o custo aumenta e o conhecimento sobre a causa continua baixo.

Conclusão

Desempenho não é uma configuração isolada do PrestaShop. É o resultado da rota do usuário até a origem, da capacidade do servidor, do PHP, do banco, dos módulos, das integrações e do código executado no navegador.

O modo debug e o profiling nativo são recursos importantes nessa investigação, desde que usados por uma janela curta, preferencialmente em homologação, e sempre desativados depois. Eles ajudam a transformar “a loja está lenta” em hipóteses verificáveis: há consultas demais, um hook domina o tempo, a memória cresce, um serviço externo bloqueia a resposta ou o gargalo começa apenas no navegador.

Antes de contratar mais infraestrutura, meça. Antes de desabilitar módulos aleatoriamente, compare. Antes de declarar que a otimização funcionou, repita o mesmo cenário.

A AGTI realiza diagnóstico e otimização de lojas PrestaShop analisando aplicação, banco, módulos e infraestrutura como partes da mesma operação. Se sua loja apresenta lentidão, instabilidade ou degradação em horários de pico, fale com nossa equipe para organizar uma análise baseada em evidências.

PrestaShop lento: como descobrir se o problema está no servidor, banco, módulos ou front-end

PrestaShop lento: como descobrir se o problema está no servidor, banco, módulos ou front-end

Antes de otimizar, defina o que está lento

Crie uma linha de base reproduzível

Camada 1: rede, DNS, TLS e CDN

Camada 2: servidor, PHP-FPM e armazenamento

CPU e processos PHP

OPcache

Disco e I/O

Camada 3: configuração do PrestaShop

Modo debug e profiling: ferramentas diferentes

Como usar o profiler sem contaminar o diagnóstico

O que procurar no resultado

Camada 4: banco de dados

Camada 5: módulos, hooks, overrides e serviços externos

Camada 6: tema, imagens e JavaScript

Como relacionar sintoma e provável camada

Uma sequência de diagnóstico que evita desperdício

Conclusão

Referências