Magento 2 lento pode indicar falta de capacidade, mas também pode ser consequência de cache ineficiente, consultas demoradas, filas acumuladas, extensões pesadas ou serviços externos que atrasam cada requisição. Trocar o servidor sem identificar o gargalo costuma apenas aumentar o custo e manter o defeito.
Antes de reiniciar serviços ou limpar todos os caches, escolha páginas representativas e registre horário, URL, visão de loja, tipo de usuário e tempo percebido. O diagnóstico abaixo ajuda a separar lentidão do navegador, aplicação, banco de dados, Redis, OpenSearch e integrações.
Magento 2 lento: descubra onde o tempo é gasto
Não trate toda demora como um único problema. Uma página pode começar a responder tarde porque o backend está ocupado, mas também pode receber o HTML rapidamente e continuar lenta por causa de imagens, JavaScript ou chamadas assíncronas.
Compare pelo menos estas rotas:
- página inicial e uma página CMS simples;
- categoria com muitos produtos e filtros;
- produto simples e produto configurável;
- carrinho e primeira etapa do checkout;
- busca com um termo conhecido;
- Admin, se a lentidão também aparecer na operação interna.
Repita os testes como visitante, cliente autenticado e em janela anônima. Uma diferença grande entre a primeira visita e as seguintes pode apontar para cache; lentidão exclusiva do cliente autenticado exige observar sessões, conteúdo privado e requisições específicas.
1. Meça o tempo de resposta sem depender apenas do navegador
As ferramentas de desenvolvedor do navegador ajudam a visualizar DNS, conexão, espera pelo primeiro byte, download e recursos bloqueadores. Para uma medição simples pelo terminal, use uma URL pública controlada:
curl -o /dev/null -s -w 'HTTP: %{http_code}nTTFB: %{time_starttransfer}snTotal: %{time_total}sn' 'https://exemplo.com.br/produto.html'
O comando não explica a causa, mas permite comparar URLs e horários. Se o tempo até o primeiro byte estiver alto, investigue aplicação e infraestrutura. Se o HTML chegar rapidamente e a página continuar incompleta, concentre-se em imagens, fontes, JavaScript, tags de marketing e chamadas Ajax.
2. Confirme o modo de operação e o estado dos caches
Em uma cópia controlada ou com acesso autorizado ao ambiente, verifique o modo do Magento:
bin/magento deploy:mode:show
bin/magento cache:status
Produção não deve operar permanentemente em modo developer. Confira também se caches importantes estão habilitados e se não voltam a ficar inválidos logo após uma limpeza. Isso pode indicar deploy incompleto, customização com invalidação excessiva ou alterações recorrentes de configuração.
Não use uma limpeza geral como primeiro teste. Ela remove evidências, aumenta o trabalho para reconstrução do cache e pode piorar temporariamente a resposta. Quando páginas continuam antigas ou não chegam ao cache de página completa, siga o diagnóstico de Varnish no Magento 2.
3. Verifique se Varnish ou CDN realmente entregam as páginas públicas
Uma página configurada para cache pode ser processada repetidamente pelo PHP se houver falha no Varnish, bypass indevido, cookies desnecessários ou blocos personalizados incompatíveis. Compare os cabeçalhos HTTP de uma mesma URL em chamadas sucessivas e observe os indicadores disponibilizados pela infraestrutura.
Não presuma que todo resultado sem cache representa erro: carrinho, checkout, conta do cliente e outras respostas privadas possuem tratamento diferente. O objetivo é descobrir se páginas públicas elegíveis estão chegando à camada de cache e permanecendo nela pelo período esperado.
4. Relacione a lentidão com PHP-FPM e recursos do servidor
CPU alta é apenas uma pista. Registre simultaneamente consumo de processador, memória, espera por disco, quantidade de processos PHP, fila do PHP-FPM e reinicializações. Poucos workers podem formar fila durante picos; workers demais podem esgotar memória e provocar troca para disco.
Confira ainda se o PHP usado pela aplicação é o esperado e se o OPcache está ativo e dimensionado para o código implantado. Mudanças nesses parâmetros devem ser homologadas e acompanhadas por métricas. Copiar valores de outra loja sem considerar memória, tráfego e extensões pode agravar a instabilidade.
5. Encontre consultas lentas e bloqueios no banco de dados
Categorias grandes, regras comerciais, relatórios, extensões e consultas personalizadas podem pressionar o banco. Durante o período afetado, procure aumento de conexões, consultas demoradas, bloqueios e espera por disco. O log de consultas lentas, quando habilitado de forma planejada, ajuda a identificar padrões reais.
Evite criar índices diretamente com base em uma única consulta. Alterações no esquema precisam considerar tabelas declarativas, upgrades, operações de gravação e comportamento do módulo responsável. Primeiro relacione a consulta à URL ou tarefa que apresentou demora; depois valide a correção em homologação.
6. Examine Redis sem apagar sessões e caches
Redis pode armazenar cache e sessões, conforme a arquitetura adotada. Latência, falta de memória, conexões excessivas ou política de remoção inadequada podem afetar navegação, login e carrinho. Com as credenciais corretas e sem expô-las no histórico do terminal, consulte indicadores como memória utilizada, clientes conectados, expirações e remoções.
redis-cli INFO memory
redis-cli INFO clients
redis-cli INFO stats
Não execute FLUSHALL ou FLUSHDB como diagnóstico. Além de não revelar a causa, esses comandos podem remover dados necessários à operação. Se a lentidão vier acompanhada de perda de itens, veja também como investigar quando o carrinho do Magento 2 esvazia sozinho.
7. Separe lentidão do catálogo de problemas no OpenSearch
Se busca, categorias ou filtros são os principais pontos lentos, compare a resposta dessas páginas com uma página CMS. Verifique saúde do serviço de busca, uso de recursos, tempo das consultas, tamanho dos índices e erros de conexão registrados pela aplicação.
Um produto ausente e uma pesquisa lenta podem ter origens diferentes. Antes de reconstruir índices indiscriminadamente, confirme o escopo com o roteiro para quando a busca do Magento 2 não encontra produtos.
8. Observe cron, indexadores, filas e tarefas concorrentes
A lentidão pode aparecer em horários específicos porque importações, indexação, feeds, backups ou integrações disputam CPU, memória e banco com os clientes. Compare os horários de degradação com o agendamento operacional.
bin/magento indexer:status
bin/magento cron:run --group default
O segundo comando executa tarefas e não deve ser disparado repetidamente em produção sem planejamento. Para falhas persistentes, investigue o cron do Magento 2, incluindo PHP CLI, tarefas perdidas e sobreposição de execuções.
9. Teste extensões e serviços externos com método
Frete, pagamento, antifraude, cálculo fiscal, ERP, recomendações e tags de terceiros podem atrasar páginas ou etapas específicas. Use logs com duração das chamadas, monitoramento distribuído disponível no ambiente e comparação entre uma requisição normal e outra lenta.
Não desative módulos diretamente em produção para “ver se melhora”. Reproduza em homologação, preserve a mesma configuração relevante e altere um componente por vez. Se a demora ocorre apenas no checkout, registre método de entrega, pagamento, CEP, perfil do cliente e chamada que permaneceu pendente.
10. Só redimensione a infraestrutura depois de confirmar o limite
Aumento de capacidade faz sentido quando as medições mostram saturação consistente e a aplicação já utiliza cache e serviços corretamente. Considere tráfego simultâneo, campanhas, importações, quantidade de SKUs, múltiplas lojas e margem para picos.
O relatório final deve relacionar sintoma, métrica, horário, componente responsável, mudança testada e resultado. Assim, a decisão pode ser corrigir uma extensão, ajustar filas, revisar banco, aumentar workers ou ampliar recursos — em vez de substituir toda a infraestrutura por tentativa.
Perguntas frequentes
Limpar o cache resolve Magento 2 lento?
Pode aliviar um sintoma específico, mas não corrige automaticamente consultas demoradas, PHP saturado, Redis sem memória ou integrações lentas. Antes da limpeza, registre URLs, horários, cabeçalhos e métricas para não apagar pistas importantes.
Como saber se a lentidão está no servidor ou no frontend?
Compare o tempo até o primeiro byte com o tempo total de carregamento. Espera inicial alta direciona a análise para backend e infraestrutura; HTML rápido seguido de demora aponta para imagens, JavaScript, fontes ou chamadas feitas pelo navegador.
Redis sempre melhora a performance do Magento?
Redis pode reduzir trabalho repetido e centralizar sessões, mas precisa estar corretamente configurado e monitorado. Falta de memória, latência, conexões excessivas ou remoção de chaves podem transformar o serviço em um gargalo.
Quando vale a pena trocar o servidor?
Quando métricas reproduzíveis mostram saturação de CPU, memória, disco, rede ou processos mesmo após a correção de problemas de aplicação, cache e tarefas concorrentes. O dimensionamento deve considerar operação normal e picos previstos.
Conclusão
Um Magento 2 lento deve ser investigado por camadas. Meça páginas representativas, separe backend de frontend e correlacione a demora com PHP, banco, Redis, OpenSearch, cron e integrações. Se sua equipe precisa localizar o gargalo sem colocar a operação em risco, o suporte especializado em Magento pode ajudar a estruturar o diagnóstico e validar as correções.

