Uma loja WooCommerce lenta nem sempre precisa trocar de plataforma. Antes de reconstruir o tema ou migrar, é preciso saber de onde vem a lentidão, porque cada causa tem um remédio diferente e algumas viajam junto com a loja: imagens pesadas, scripts de terceiros e um catálogo mal estruturado continuam lentos em qualquer plataforma. A decisão sensata segue uma ordem: medir, separar a causa, testar a correção numa cópia e só então comparar custos. Este guia é para quem tem uma loja WooCommerce em operação, percebe páginas ou checkout lentos e está ouvindo que a solução é migrar.
De onde vem a lentidão: servidor, tema, scripts ou consultas?
Um artigo do blog oficial da WooCommerce, publicado em 9/10/2026 e consultado em 20/10/2026, organiza a lentidão em três problemas: o servidor demora para montar a página, a página fica pesada depois de carregar, ou a página não pode ser servida do cache e é reconstruída a cada visita. Na prática, vale separar o primeiro em dois, porque servidor fraco e consulta pesada ao banco de dados pedem correções diferentes.
| Causa provável | Sintoma típico | Como verificar | Primeira correção a testar |
|---|---|---|---|
| Servidor | Demora antes de qualquer conteúdo aparecer, inclusive no painel | Versão do PHP e limite de memória em Ferramentas > Saúde do site; resposta do checkout com plugins desativados | Atualizar o PHP, ajustar o plano de hospedagem |
| Consultas ao banco | Páginas de categoria, busca, pedidos ou painel lentos com o mesmo servidor | Query Monitor, painel de consultas por componente; armazenamento de pedidos em uso | Ativar o HPOS, remover a extensão que gera consultas pesadas |
| Tema | Página pesada, muitos arquivos de layout, mudança visual ao carregar | Trocar temporariamente para um tema padrão em homologação | Corrigir o tema ou reconstruí-lo |
| Scripts e plugins | Arquivos carregados em páginas onde não são usados | Query Monitor, painéis de scripts e estilos | Remover, substituir ou restringir o plugin |
| Imagens | Página leve em código, mas lenta para exibir a foto principal | PageSpeed Insights, oportunidades de imagem | Redimensionar e comprimir; carregamento tardio fora da primeira tela |
| Cache | Páginas públicas rápidas às vezes e lentas em outras | Teste em janela anônima e conferência das regras de cache | Configurar o cache de página, mantendo carrinho e checkout fora dele |
Alguns pontos dessa tabela vêm direto da documentação. Os requisitos de servidor do WooCommerce 10.8 em diante pedem PHP 8.3 ou superior e limite de memória de 256 MB ou mais. O HPOS, que move os pedidos para tabelas próprias, é o padrão em instalações novas desde o WooCommerce 8.2, mas lojas antigas não migram sozinhas: a ativação fica em WooCommerce > Configurações > Avançado > Recursos e fica bloqueada enquanto houver extensão incompatível. A documentação para desenvolvedores orienta deixar páginas dinâmicas, como carrinho e checkout, fora do cache, e o artigo do blog oficial acrescenta a área “Minha conta” e sugere conferir em janela anônima: se o número de itens do carrinho aparece errado, algo está em cache onde não deveria.
O artigo também lista quando a hospedagem passa a ser a suspeita principal: PHP, HPOS, plugins e cache já resolvidos e o checkout ainda levando cerca de 4 segundos para responder; painel lento mesmo com plugins desativados; velocidade que muda muito conforme o horário; ou limite de memória do PHP abaixo de 256 MB.
Como testar hipóteses sem enganar a medição?
O PageSpeed Insights mostra dois tipos de dado, e a decisão precisa dos dois. Os dados de campo vêm do relatório de experiência do usuário do Chrome, cobrem os 28 dias anteriores e mostram o 75º percentil dos visitantes reais. Os dados de laboratório são uma carga simulada, úteis para depurar, mas que, segundo a documentação do Google, podem não captar gargalos do mundo real e variam entre execuções por rede, hardware e concorrência de recursos. Os limites de “bom” para as métricas principais são LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1, conforme a mesma documentação.
Para que uma comparação de antes e depois signifique alguma coisa:
- Fixe a jornada. Mesma página inicial, mesma categoria, mesmo produto, mesmo carrinho e checkout. O artigo oficial sugere começar por uma página de produto e pelo checkout.
- Fixe o dispositivo e as condições. Mesmo perfil de celular e de rede no laboratório, mesma ferramenta, mesmo horário aproximado.
- Repita a medição. Como o laboratório varia, registre várias execuções de cada página, e não uma só.
- Mude uma coisa por vez. Se o PHP, o cache e o tema mudam juntos, não dá para saber qual resolveu.
- Teste em homologação. A documentação de solução de problemas orienta desativar todos os plugins e reativá-los um a um, e trocar temporariamente para um tema padrão; isso não se faz na loja em produção. Para investigar a loja publicada sem afetar clientes, o artigo oficial cita o plugin Health Check & Troubleshooting, que desativa plugins só na sessão de quem está testando.
- Confira os dados de campo depois. A correção levada à produção precisa aparecer nos dados de visitantes reais ao longo das semanas seguintes, já que o relatório cobre 28 dias.
Uma ressalva sobre a homologação: ela costuma ter menos tráfego, menos pedidos e outro cache. Uma hipótese confirmada lá ainda precisa ser conferida na loja publicada.
Modelo de relatório de diagnóstico
O modelo abaixo é documental: ele organiza um diagnóstico, mas não traz resultados de uma loja real. Os campos entre colchetes são preenchidos com as suas medições. A leitura de exemplo logo depois é ilustrativa, sem números, só para mostrar como uma conclusão se apoia nas evidências.
RELATÓRIO DE DIAGNÓSTICO DE DESEMPENHO - LOJA WOOCOMMERCE
1. Contexto do teste
Ambiente: [produção / homologação] Data e horário: [ ]
Ferramenta: [PageSpeed Insights / outra] Perfil: [celular / computador]
Execuções por página: [ ]
Versões: WordPress [ ] WooCommerce [ ] PHP [ ] Tema [ ]
Hospedagem e plano: [ ] Limite de memória: [ ]
Armazenamento de pedidos: [HPOS / posts] Cache de página: [sim / não, qual]
Extensões ativas: [quantidade e lista]
2. Jornada medida
Inicial [URL] Categoria [URL] Produto [URL] Carrinho Checkout
3. Resultados (por página)
Dados de campo: LCP [ ] INP [ ] CLS [ ] (ou "sem dados suficientes")
Laboratório: LCP [ ] CLS [ ] Tempo de resposta do servidor [ ]
Principais oportunidades apontadas: [ ]
4. Hipóteses testadas (uma por linha)
Hipótese | Mudança feita | Onde | Antes | Depois | Conclusão
5. Causa principal e causas secundárias
[servidor / consultas / tema / scripts / imagens / cache]
6. Recomendação
[corrigir a instalação / reconstruir o tema / avaliar migração]
Custo estimado: [valor da proposta] Limitação conhecida: [ ]Leitura ilustrativa. Numa loja fictícia, o checkout está lento nos dados de campo. Em homologação, com plugins desativados, o tempo de resposta do servidor cai; reativando um a um, a queda some quando volta uma extensão de recomendação de produtos que gera muitas consultas, segundo o Query Monitor. O tema padrão não muda o resultado do checkout. A conclusão do relatório é corrigir a instalação (substituir ou restringir aquela extensão) e não reconstruir o tema nem migrar.
Corrigir, reconstruir o tema ou trocar de plataforma?
Com a causa identificada, compare os três caminhos pelo que eles resolvem e pelo que custam.
| Caminho | Indicado quando o relatório mostra | Resolve | Não resolve | Custo e risco |
|---|---|---|---|---|
| Corrigir a instalação | PHP antigo, HPOS desativado, cache mal configurado, plugin pesado, imagens grandes, plano de hospedagem insuficiente | A maior parte dos problemas de servidor, consultas e cache | Um tema estruturalmente pesado | Menor; exige testes em homologação e rotina de manutenção |
| Reconstruir o tema | O tema padrão melhora muito o resultado e o tema atual não tem como ser corrigido | Peso da página, mudança visual ao carregar, scripts do tema | Servidor fraco, consultas pesadas, scripts de terceiros | Médio; o layout precisa ser redesenhado e testado |
| Trocar de plataforma | A loja corrigida continua dependendo de uma manutenção que a operação não sustenta, ou há requisitos que a plataforma não atende | Manutenção de servidor e de núcleo, que passam ao fornecedor da plataforma | Imagens, scripts de terceiros, catálogo e conteúdo, que vão junto | Maior; envolve dados, URLs, integrações, layout e risco de perder tráfego orgânico |
A troca de plataforma é uma decisão de operação, não de velocidade. Se ela fizer sentido pelo relatório, o planejamento da migração do WooCommerce para Shopify mostra o que levar, o que reconstruir e o que testar, e vale antes comparar WooCommerce e Shopify em controle técnico, custo e manutenção. Em qualquer caminho, a velocidade é parte do SEO no projeto da loja virtual, e uma migração mal planejada pode custar mais em tráfego do que a lentidão.
Condições e limites
Os requisitos de servidor, o comportamento do HPOS, as recomendações de cache e os limites das métricas foram consultados em 20/10/2026 nas páginas oficiais e podem mudar. As correções descritas não garantem um resultado de velocidade ou de conversão: o efeito depende da loja, da hospedagem e das extensões. Este texto não oferece um serviço de manutenção contínua; quem mantém a loja depois da correção precisa estar definido em contrato.
Próximo passo
Se a dúvida é se a manutenção do WooCommerce cabe na sua operação, comece por comparar WooCommerce e Shopify. Para lojas WooCommerce existentes, a página de criação de loja com WooCommerce descreve o diagnóstico de versões, plugins, tema e hospedagem que antecede a proposta: o que corrigir, o que atualizar e se faz sentido reconstruir.
