Quase toda conversa sobre servidor para loja virtual começa com a pergunta errada: “quantas visitas por mês esse plano aguenta?”

Essa métrica funciona razoavelmente bem para sites de conteúdo. Para WooCommerce, ela é quase inútil. Duas lojas com trinta mil visitas mensais podem exigir configurações completamente diferentes dependendo de quantos produtos têm, quantas variações cada produto tem, quantos pedidos processam por hora e o quanto do tráfego chega ao carrinho.

Este guia mostra como dimensionar a partir de dados que você já tem na sua loja, em vez de escolher o plano do meio da tabela e torcer. E explica por que, em muitos casos, a resposta certa não é contratar mais recursos.

Por que WooCommerce consome mais do que um site comum

A diferença estrutural é uma só, e ela explica todo o resto: as páginas mais importantes de uma loja não podem ser servidas por cache.

Em um site de conteúdo, o cache guarda a página montada e a entrega pronta nas visitas seguintes. O servidor quase não trabalha. Em uma loja, o catálogo e as páginas de produto até funcionam assim, mas carrinho, checkout e área do cliente precisam ser únicos para cada visitante — cada uma dessas requisições atravessa o PHP e chega ao banco de dados.

Some a isso três características do WooCommerce:

• Consulta de estoque em tempo real, que não pode ser aproximada.
• Produtos com variações, que multiplicam as consultas de atributo e preço.
• Tarefas em segundo plano, como sincronizações, e-mails transacionais e integrações, que rodam enquanto os clientes navegam.

O resultado prático: o consumo de uma loja é governado pelo volume de requisições que não passam por cache, não pelo total de visitas. É esse número que você precisa estimar.

As quatro variáveis que realmente definem o dimensionamento

1. Requisições dinâmicas simultâneas

É a métrica central. Estime assim: nos horários de pico, quantos visitantes estão simultaneamente no carrinho, no checkout ou logados na conta? Esse número, e não o total de sessões, define quantos processos PHP precisam existir ao mesmo tempo.

Cada processo PHP ocupa memória enquanto executa. A memória do servidor precisa comportar o número de processos simultâneos multiplicado pelo consumo médio de cada um, mais o que o banco de dados reserva, mais o sistema operacional. Servidores que travam em pico quase sempre erraram nessa conta.

2. Tamanho e complexidade do catálogo

Não é só a quantidade de produtos. Uma loja com 500 produtos simples é mais leve que uma com 200 produtos de vinte variações cada, porque as variações multiplicam registros e consultas.

Filtros por atributo são o ponto mais sensível: filtrar por cor, tamanho e faixa de preço ao mesmo tempo gera consultas caras, que consomem processamento e leitura de disco.

3. Volume de pedidos por hora no pico

Cada pedido dispara uma sequência: gravação no banco, comunicação com o meio de pagamento, envio de e-mails, possíveis integrações com ERP ou plataforma de envio. É a operação mais intensiva da loja, e ela acontece justamente quando o tráfego está no máximo.

O número que importa não é a média mensal. É o pico — a hora de maior movimento de uma campanha bem-sucedida.

4. Perfil das integrações

Integrações que rodam em segundo plano competem por recursos com os clientes que estão comprando. Uma sincronização de estoque a cada cinco minutos com um catálogo grande pode consumir mais processamento que o tráfego humano.

Como levantar esses números na sua loja

Todos os dados necessários já existem, e o levantamento leva menos de uma hora:

1. Pedidos no pico: no painel do WooCommerce, identifique o dia de maior volume dos últimos doze meses e o horário de concentração dentro dele.
2. Sessões simultâneas: em uma ferramenta de analytics, veja o número de usuários ativos no minuto de maior movimento desse dia.
3. Proporção de tráfego dinâmico: compare as visualizações de carrinho e checkout com as visualizações totais. Essa proporção é o que define a carga real.
4. Tamanho do banco: verifique o total, com atenção a tabelas de metadados e ao histórico de tarefas agendadas.
5. Consumo atual: no painel do provedor, veja o pico de memória e de processos dos últimos 30 dias.

Com esses cinco números em mãos, a conversa com qualquer fornecedor muda de natureza: você deixa de perguntar “qual plano vocês recomendam” e passa a perguntar “esta configuração comporta esta carga”.

Banco de dados: onde as lojas realmente travam

Em lojas que cresceram, o gargalo raramente é o servidor web. É o banco.

HPOS. O WooCommerce guardava historicamente os pedidos nas mesmas tabelas usadas para posts e metadados do WordPress — uma estrutura pensada para conteúdo, não para transações. O High-Performance Order Storage move os pedidos para tabelas próprias e indexadas. Segundo a documentação oficial, ele é o padrão para novas instalações a partir do WooCommerce 8.2, lançado em outubro de 2023.

Lojas antigas, porém, continuam na estrutura antiga até que a migração seja feita — e essa é a intervenção de maior impacto disponível para uma loja com histórico grande de pedidos. A documentação recomenda ativar o modo de compatibilidade para sincronizar as tabelas antes de trocar a autoridade, e testar em ambiente separado com todas as extensões ativas. É uma migração, não um botão.

Cache de objeto. Sem ele, cada carregamento de página repete dezenas de consultas idênticas ao banco. Um cache de objeto persistente, como o Redis, mantém esses resultados em memória e reduz drasticamente o número de idas ao banco. Para lojas, costuma render mais que qualquer upgrade de hardware equivalente em custo — e exige acesso ao servidor, o que hospedagem compartilhada não oferece.

Higiene do banco. Revisões antigas de produtos, sessões expiradas, logs de tarefas agendadas e dados deixados por plugins removidos incham as tabelas e degradam as consultas. Limpeza periódica é manutenção, não otimização avançada.

Versões. As recomendações atuais do WooCommerce apontam para PHP e banco em versões modernas — na prática, PHP 8.x e MySQL 8.0 ou MariaDB recente. Vale conferir a página oficial de recomendações de servidor na data da decisão, porque esses números sobem periodicamente.

Por que não publicamos uma tabela de RAM por faixa de visitas

Essa tabela existe em muitos lugares e é a razão de boa parte dos dimensionamentos errados.

Uma loja de 300 produtos simples com dez pedidos por dia e uma loja de 300 produtos com quinze variações cada, integração com ERP e cem pedidos na hora de pico aparecem na mesma linha de qualquer tabela por visitas — e precisam de servidores diferentes.

O que substitui a tabela é o método: calcule a memória pelo número de processos simultâneos no pico, reserve a parte do banco separadamente, some a folga do sistema e valide com teste de carga antes de considerar a conta fechada. Um fornecedor sério consegue fazer essa conta com você a partir dos seus números.

Antes de contratar mais recursos

Esta seção pode economizar dinheiro real. Em boa parte dos casos de lentidão, o servidor não é o problema — ou não é o primeiro problema.

1. Migre para o HPOS, se a loja ainda estiver na estrutura antiga e o volume de pedidos for relevante.
2. Ative um cache de objeto persistente. É a intervenção com melhor relação entre esforço e resultado em lojas de porte médio.
3. Atualize a versão do PHP. Versões modernas processam significativamente mais requisições com o mesmo hardware.
4. Revise plugins. Extensões que adicionam consultas a cada carregamento de página são comuns e caras. Meça o custo de cada uma.
5. Limpe o banco. Revisões, sessões e logs acumulados.
6. Verifique as regras de cache. Carrinho e checkout devem estar excluídos — mas o catálogo não precisa estar.
7. Otimize imagens. Não resolve carga de banco, mas melhora a experiência percebida sem custo de infraestrutura.

Feito tudo isso e persistindo o problema, aí sim a restrição é de capacidade — e o dimensionamento passa a fazer sentido.

Sinais de que a loja já passou do ponto

• O painel administrativo demora para abrir a lista de pedidos, mesmo com a loja pública aparentemente normal.
• Erros de tempo limite durante o checkout, especialmente em horários de movimento.
• Pedidos que ficam presos em processamento ou e-mails transacionais que atrasam.
• Aviso de consumo excessivo do provedor atual.
• A loja cai justamente no dia da campanha — o cenário mais caro de todos.

O último merece atenção especial: uma loja fora do ar durante uma campanha perde receita de forma direta e mensurável, e ainda consome verba de mídia sem retorno. Esse é o cálculo que costuma justificar a migração para um Cloud Server para WooCommerce mais rápido do que qualquer comparação de mensalidade.

Conclusão

Dimensionar um servidor para WooCommerce é uma conta, não uma escolha de plano. Ela depende de quatro variáveis que estão nos seus próprios dados: requisições dinâmicas simultâneas no pico, complexidade do catálogo, volume de pedidos por hora e peso das integrações.

Antes de contratar mais recursos, vale garantir que a loja está usando bem os que já tem — HPOS, cache de objeto, versão atual de PHP e banco limpo mudam o patamar de desempenho sem custo de infraestrutura. Depois disso, se a restrição persistir, ela é real e o upgrade se justifica.

Se você já levantou os números da sua loja e quer validar a configuração adequada, conheça o Cloud Server para WooCommerce da TBF Host e compare as opções disponíveis com a carga que você mediu.

Perguntas frequentes

Quantas visitas um servidor para WooCommerce aguenta?

Essa não é a métrica correta para uma loja. O consumo é definido pelas requisições que não passam por cache — carrinho, checkout e área do cliente — e não pelo total de visitas. Duas lojas com o mesmo tráfego podem exigir servidores muito diferentes conforme o número de variações de produto, o volume de pedidos por hora e as integrações ativas.

Quanto de RAM preciso para uma loja WooCommerce?

A memória deve comportar o número de processos PHP simultâneos no horário de pico multiplicado pelo consumo médio de cada processo, mais a reserva do banco de dados e a folga do sistema operacional. Tabelas genéricas de RAM por faixa de visitas ignoram o perfil da loja e são causa frequente de dimensionamento incorreto.

O que é HPOS no WooCommerce?

High-Performance Order Storage é a estrutura em que o WooCommerce armazena pedidos em tabelas próprias e indexadas, em vez das tabelas de posts e metadados do WordPress. Conforme a documentação oficial, é o padrão para novas instalações desde o WooCommerce 8.2, de outubro de 2023. Lojas antigas permanecem na estrutura anterior até que a migração seja feita.

Vale a pena migrar minha loja para o HPOS?

Para lojas com histórico grande de pedidos, costuma ser a intervenção de maior impacto em desempenho. Não é uma simples ativação: a documentação recomenda habilitar o modo de compatibilidade para sincronizar as tabelas, testar em ambiente separado com todas as extensões ativas e só então trocar a autoridade dos dados.

Cache resolve a lentidão de uma loja virtual?

Resolve parcialmente. O cache de página acelera catálogo e páginas de produto, mas carrinho, checkout e área do cliente precisam ser únicos por visitante e não podem ser servidos por cache. Para essas páginas, o que ajuda é o cache de objeto persistente, que reduz o número de consultas repetidas ao banco de dados.

Por que o painel da minha loja está lento se o site parece normal?

Porque o painel administrativo não é servido por cache. Ele mostra o desempenho real do servidor e do banco de dados. Lentidão na listagem de pedidos costuma indicar tabelas de pedidos sobrecarregadas — situação típica de lojas com histórico grande ainda na estrutura antiga de armazenamento.

Preciso de um servidor exclusivo para rodar WooCommerce?

Não necessariamente. Lojas em início de operação, com poucos produtos e volume baixo de pedidos, funcionam bem em planos de hospedagem. O servidor exclusivo passa a fazer sentido quando há volume constante de pedidos, catálogo complexo, integrações em segundo plano ou quando a indisponibilidade tem custo direto de receita.

O que fazer antes de contratar um servidor maior?

Migrar para o HPOS se a loja ainda estiver na estrutura antiga, ativar cache de objeto persistente, atualizar a versão do PHP, revisar plugins que adicionam consultas a cada página, limpar o banco de dados e conferir as regras de exclusão de cache. Se o problema persistir depois disso, a restrição é de capacidade real.