Loja WooCommerce travando: como saber se o problema é a sua hospedagem

Tem um tipo de problema em loja virtual que é especialmente cruel: aquele em que tudo parece certo e nada funciona.

O site abre. Os produtos aparecem. O cliente coloca no carrinho, vai para o checkout, escolhe o frete — e a tela trava numa bolinha girando que nunca para. Nenhum erro na tela. Nenhuma mensagem. Só o pedido que não acontece.

Se você já passou por isso, sabe o roteiro que vem depois. Desativa um plugin. Testa. Desativa outro. Testa. Troca o tema. Limpa o cache. Pergunta num grupo do Facebook. Alguém diz que é o Elementor, outro jura que é o Mercado Pago, um terceiro manda trocar de tema. Você faz tudo, e a bolinha continua girando.

Esse post é sobre a possibilidade que quase ninguém considera: o problema não está no seu site. Está embaixo dele.

Um caso real

Recebemos há algumas semanas uma loja com exatamente esse sintoma. Checkout congelado no momento de atualizar o pedido, spinner infinito, zero mensagem de erro.

O que fizemos, na ordem:

Desativamos os 31 plugins da loja — primeiro um a um, depois todos de uma vez, deixando só o WooCommerce rodando sozinho. O problema continuou.

Trocamos o tema pelo padrão do WordPress. Continuou.

Suspeitamos do Cloudflare. Migramos o domínio para uma conta nova, limpamos registros de DNS duplicados e um IPv6 errado que estava lá. Depois contornamos o Cloudflare inteiro, apontando a máquina direto para o servidor pelo arquivo hosts. O problema continuou.

Testamos sem as regras de otimização do servidor. Testamos em outro navegador, sem nenhuma extensão. Rodamos o diagnóstico interno do WooCommerce, que apontou ambiente limpo.

Quando você elimina o tema, os plugins, a CDN, o navegador e a aplicação inteira, sobra um lugar só.

O que estava acontecendo

O WooCommerce, no checkout, faz uma chamada em segundo plano para recalcular o pedido — o famoso wc-ajax=update_order_review. Ele espera receber de volta um pedaço de dados estruturados. Um JSON, na linguagem técnica: informação pura, que o navegador entende e usa para atualizar a tela.

O que voltava, em vez disso, era uma página HTML inteira. Uma página que a loja nunca pediu, gerada por alguma camada do próprio servidor de hospedagem, que interceptava a requisição no caminho.

Para o WooCommerce, isso é como pedir o preço de um produto e receber um cardápio de volta. Ele não sabe o que fazer com aquilo. Então não faz nada. E a bolinha gira para sempre.

Era hospedagem compartilhada. Não vou citar a empresa, porque o comportamento aparece em várias delas e o objetivo aqui não é atacar marca nenhuma.

A parte que mais importa

Aqui está o ponto que faz esse caso valer um post inteiro.

Nós descobrimos a causa. Temos o diagnóstico fechado, documentado, reproduzível. E mesmo assim não podemos corrigir.

Porque em hospedagem compartilhada você não tem acesso à camada onde o problema mora. Não dá para olhar a configuração do servidor, não dá para desligar o módulo que está interceptando, não dá para testar uma alternativa. O que dá para fazer é abrir um chamado, explicar tudo de novo para um atendente de primeiro nível, e esperar.

Essa é a conta que ninguém faz na hora de contratar hospedagem barata. Não é o preço da mensalidade. É o custo de ficar parado sem poder agir, com a loja sem vender, dependendo da fila de atendimento de outra empresa.

Como testar se o seu caso é esse

Antes de acusar a hospedagem, elimine o que está do seu lado. Nesta ordem:

1. Desative todos os plugins, menos o WooCommerce. Se o problema sumir, é plugin — reative um a um até achar. Se continuar, siga.
2. Ative um tema padrão do WordPress. Se o problema sumir, é o tema. Se continuar, siga.
3. Contorne o CDN. Se você usa Cloudflare ou similar, aponte sua máquina direto para o IP do servidor pelo arquivo hosts e teste. Se o problema continuar mesmo sem passar pelo CDN, ele está na origem.
4. Olhe o que a chamada realmente devolve. Abra o console do navegador na aba de rede, refaça a ação que trava e procure a requisição com wc-ajax. Se a resposta for HTML em vez de dados, você achou. O servidor está entregando coisa diferente do que a loja pediu.

Se você chegou até o passo 4 e a resposta veio errada, pode parar de mexer no site. O problema não é seu.

Quando hospedagem compartilhada dá conta — e quando não dá

Não vou dizer que hospedagem barata é sempre ruim, porque não é. Para um site institucional de cinco páginas, um blog pessoal, um portfólio, ela resolve bem e o preço é honesto.

O problema começa quando você coloca uma loja em cima dela. Loja é diferente de site: tem sessão de usuário, carrinho, cálculo de frete, chamada para gateway de pagamento, atualização de estoque. É software rodando o tempo todo, não página parada esperando visita. E a velocidade real que ela consegue entregar depende de decisões de infraestrutura que ficam fora do seu alcance em ambiente compartilhado.

E hospedagem compartilhada é, por definição, um servidor dividido entre centenas de contas, com camadas automáticas de otimização e proteção que existem para proteger o conjunto — não para respeitar o funcionamento específico da sua loja. Na maior parte do tempo passa despercebido. Até o dia em que uma dessas camadas resolve interceptar exatamente a chamada que fecha suas vendas.

O sinal de alerta não é o preço. É a resposta que você recebe quando algo dá errado.

O que fazemos diferente

O TMW Blindado existe por causa de casos assim. Servidor gerenciado por nós, sem revenda, com acesso real à máquina. Quando algo trava, a gente entra e olha — não abre chamado e espera. É a mesma lógica que vale para cenários mais graves, como uma loja virtual invadida: quem tem acesso ao servidor resolve; quem não tem, espera na fila.

Se sua loja está com sintoma parecido e você já perdeu fim de semana desativando plugin, fala com a gente. O diagnóstico é gratuito, e em boa parte dos casos a gente descobre em uma conversa se o problema está no site ou embaixo dele.