Magento 2 lento não significa automaticamente que a loja precisa de um servidor maior. A demora pode nascer no PHP, banco de dados, cache, indexadores, mecanismo de busca, integrações ou navegador do cliente. Sem delimitar a camada afetada, aumentar recursos ou limpar caches pode apenas mascarar o problema.
O diagnóstico mais seguro começa com uma medição reproduzível: mesma página, mesmo contexto de cliente, horário registrado e comparação entre respostas. Os nove testes abaixo ajudam a transformar a percepção de lentidão em evidências técnicas.
Por que o Magento 2 fica lento?
Uma página do Magento pode depender de configuração, sessão, catálogo, estoque, regras comerciais, extensões e serviços externos. No frontend, ainda entram imagens, JavaScript, fontes, tags de marketing e chamadas de terceiros. Por isso, duas URLs da mesma loja podem apresentar tempos completamente diferentes.
Antes de mudar a infraestrutura, identifique o alcance:
- A lentidão ocorre na loja inteira ou somente em busca, categoria, produto, carrinho ou checkout?
- O painel administrativo também está lento?
- O problema afeta visitantes, clientes autenticados ou ambos?
- É contínuo ou aparece em horários específicos?
- Começou depois de deploy, importação, instalação de módulo ou mudança de configuração?
Magento 2 lento: faça estes 9 testes
1. Meça o tempo de resposta sem depender apenas do navegador
Abra as ferramentas de desenvolvimento do navegador e examine a aba de rede. Diferencie uma espera longa pela resposta HTML de uma página que responde rapidamente, mas demora para carregar imagens, scripts ou serviços externos.
Uma medição simples pelo terminal ajuda a verificar redirecionamento, conexão e tempo até o primeiro byte:
curl -sS -o /dev/null -w 'HTTP: %{http_code}nTTFB: %{time_starttransfer}snTotal: %{time_total}sn' https://loja.exemplo.com.br/Repita o teste algumas vezes e compare páginas distintas. Uma única execução não representa o comportamento da operação, especialmente quando existe cache de página completa, CDN ou oscilação de rede.
2. Compare páginas públicas, sessão autenticada e áreas sem cache
Teste a página inicial, uma categoria, um produto, o carrinho e uma rota do painel. Se páginas públicas ficam rápidas depois da primeira requisição, mas carrinho e checkout continuam lentos, o gargalo pode estar no processamento dinâmico, nas sessões ou em uma integração.
Faça também uma comparação controlada entre janela anônima e cliente autenticado. Não use ferramentas de carga diretamente em produção sem autorização e limites definidos: o objetivo inicial é reproduzir a lentidão, não criar tráfego artificial.
3. Confirme o modo de operação e o estado dos caches
Uma loja de produção operando em modo inadequado pode executar trabalhos adicionais durante as requisições. Consulte o modo e o estado dos caches sem alterá-los:
bin/magento deploy:mode:show
bin/magento cache:statusUm cache desabilitado pode ser intencional durante manutenção, mas precisa ser investigado quando permanece assim em produção. Antes de executar cache:flush, registre o estado atual e confirme qual camada está com problema. Limpar tudo elimina conteúdo reutilizável, aumenta o trabalho das primeiras requisições e pode agravar temporariamente a lentidão.
Se o cache utiliza Redis e há erros de conexão, pressão de memória ou perda de sessões, siga o guia de diagnóstico de Redis no Magento 2 antes de reiniciar o serviço.
4. Correlacione a lentidão com logs e exceções
Registre a URL, o horário e a ação executada. Em seguida, examine os arquivos de var/log, relatórios da aplicação, log do servidor web e registros do PHP-FPM. Procure eventos no mesmo intervalo, evitando concluir que toda mensagem antiga está relacionada ao sintoma.
tail -n 200 var/log/system.log
tail -n 200 var/log/exception.logErros repetidos dentro de loops, timeouts de APIs, falhas de conexão e avisos produzidos em grande volume podem aumentar o tempo de processamento. Se a lentidão evoluir para indisponibilidade, o roteiro de investigação do erro 500 no Magento 2 ajuda a separar aplicação, PHP e servidor web.
5. Verifique filas, saturação e tempo de execução do PHP-FPM
Observe CPU, memória, uso de swap e processos durante a ocorrência. CPU baixa não comprova que o ambiente está saudável: processos PHP podem estar aguardando banco, Redis, DNS ou APIs externas.
Nos registros do PHP-FPM, procure sinais de limite de processos, filas acumuladas, encerramentos e requisições demoradas. O dimensionamento deve considerar memória disponível e consumo real de cada processo. Aumentar indiscriminadamente o número de workers pode causar falta de memória e piorar a estabilidade.
Também confirme se a versão e as extensões do PHP usadas pela interface web correspondem ao ambiente esperado. O PHP da linha de comando pode utilizar outro arquivo de configuração, portanto uma consulta via CLI não prova, sozinha, como o PHP-FPM está configurado.
6. Investigue o banco de dados sem editar tabelas
Se a espera está no backend, consulte métricas de conexões, CPU, disco, bloqueios e consultas lentas. Operações de catálogo, relatórios, integrações e extensões podem gerar consultas caras ou concorrência no banco.
Com acesso autorizado, uma consulta de leitura como SHOW FULL PROCESSLIST; pode revelar sessões em espera no momento do problema. O log de consultas lentas também é útil, desde que seja habilitado e analisado pela equipe responsável pela infraestrutura.
Não remova registros nem crie índices diretamente em produção como primeira tentativa. Alterações no esquema precisam considerar os mecanismos declarativos do Magento, o código responsável pela consulta e um teste em homologação.
7. Confira indexadores, cron e acúmulo de tarefas
Consulte os indexadores:
bin/magento indexer:status
bin/magento indexer:show-modeEstados pendentes ou processamento prolongado podem afetar atualização de catálogo, preços, estoque e regras. A causa, porém, pode estar no cron, banco, volume de alterações ou extensão personalizada. Executar reindexação completa durante um pico de acesso pode competir por recursos com a vitrine.
Confira também se os agendamentos são criados e consumidos. O artigo sobre cron Magento 2 que não executa mostra como avaliar o agendador sem tratar a execução manual como solução definitiva.
8. Isole busca, extensões e integrações externas
Se a lentidão está concentrada na pesquisa, filtros ou categorias, examine a comunicação com o mecanismo de busca, o tempo das consultas e a saúde do serviço. Já atrasos no checkout podem depender de antifraude, pagamento, frete, cálculo fiscal, ERP ou personalizações.
Use os logs e o painel de rede para identificar chamadas demoradas. Em homologação, compare o fluxo com integrações controladas ou ambientes de teste disponibilizados pelos fornecedores. Não desabilite módulos essenciais diretamente em produção apenas para “ver se melhora”, pois isso pode interromper pedidos ou deixar dados em estado inconsistente.
9. Separe lentidão do servidor de lentidão no frontend
Quando o HTML chega rapidamente, mas a página demora para ficar utilizável, investigue o frontend. Imagens grandes, JavaScript excessivo, tags de terceiros, fontes, erros em sequência e conteúdo estático ausente podem prejudicar a navegação mesmo com o backend respondendo bem.
Compare o tempo até a resposta inicial com o carregamento total e procure arquivos bloqueadores ou requisições que permanecem pendentes. Se CSS ou JavaScript falharam depois de uma publicação, use o checklist para arquivos estáticos que não carregam após o deploy.
Como organizar as evidências antes de corrigir
Registre em um único chamado:
- URL e horário exato do teste;
- tipo de usuário e conteúdo do carrinho, quando aplicável;
- tempo até o primeiro byte e tempo total;
- código HTTP e identificador de requisição, se disponível;
- consumo de CPU, memória e banco no intervalo;
- trechos relevantes dos logs;
- deploys, importações ou mudanças executadas antes do sintoma.
Essa correlação evita otimizações genéricas. Se uma consulta específica domina o tempo, aumentar o cache do navegador não resolverá. Se o atraso está em um script externo, ajustar o banco também não produzirá o efeito esperado.
Conclusão
O diagnóstico de um Magento 2 lento deve separar backend, infraestrutura, cache, banco, serviços externos e frontend antes de qualquer correção. Meça primeiro, preserve os registros e altere uma variável por vez, preferencialmente em homologação.
Se a loja continua lenta e sua equipe precisa correlacionar aplicação, PHP, banco e serviços de cache, entre em contato com os especialistas em suporte Magento para uma avaliação técnica orientada por evidências.
Perguntas frequentes sobre Magento 2 lento
Limpar o cache resolve a lentidão do Magento 2?
Pode aliviar um cache inconsistente, mas não corrige automaticamente problemas de banco, PHP, integrações ou frontend. Uma limpeza completa também aumenta o processamento das primeiras requisições e pode esconder evidências.
Como saber se o problema está no servidor ou no frontend?
Compare o tempo até o primeiro byte com o tempo total de carregamento. Resposta HTML demorada aponta para backend ou infraestrutura; HTML rápido seguido de longa espera sugere imagens, JavaScript, fontes ou chamadas externas.
Servidor com CPU baixa significa que o Magento está saudável?
Não. Processos podem estar aguardando banco de dados, Redis, disco, DNS ou APIs externas. CPU, memória, filas, conexões e tempos das dependências devem ser analisados em conjunto.
É seguro reindexar a loja durante a lentidão?
Depende do volume e da causa. Uma reindexação completa pode consumir banco, CPU e disco, aumentando a disputa com a vitrine. Primeiro verifique o status dos indexadores e execute intervenções pesadas em janela controlada.
Quando é necessário aumentar a infraestrutura?
Quando as medições demonstram saturação recorrente de recursos mesmo após corrigir consultas, caches, tarefas, extensões e configurações. O dimensionamento deve ser baseado na carga observada e no consumo real da aplicação.
