Você investiu R$50 mil em anúncios. Gravou vídeo de vendas. Preparou a sequência de e-mails. A copy está afiada. A equipe está de plantão.
Chega o dia da abertura de carrinho. O e-mail dispara pra lista inteira. Os anúncios estão rodando a todo vapor. Duas mil, três mil pessoas clicam ao mesmo tempo.
E o site cai.
Página branca. Erro 503. Checkout que não carrega. O pessoal do suporte entra em pânico no grupo do WhatsApp. Você recarrega a página. Nada. Recarrega de novo. Nada.
Cada minuto fora do ar com campanha rodando é dinheiro queimando. Se você investe R$1.000 por dia em ads, são R$41 por hora. Parece pouco? Não é o custo do tráfego que dói. É o custo da oportunidade. Aquelas pessoas que clicaram e viram uma tela de erro não vão voltar. Elas vão fechar a aba e seguir com a vida.
Esse cenário acontece toda semana no mercado digital brasileiro. E o pior: quase sempre é evitável.
Por que sites WordPress caem em picos de tráfego
WordPress é o CMS mais usado do mundo. Funciona bem pra quase tudo. Mas ele tem um calcanhar de Aquiles: cada visita sem cache gera uma requisição PHP que consulta o banco de dados MySQL.
Em tráfego normal, tudo bem. O servidor responde tranquilo.
Mas quando centenas ou milhares de pessoas chegam ao mesmo tempo, a coisa muda. Cada uma dessas visitas simultâneas precisa de um processo PHP ativo e de uma conexão com o banco. Quando os processos PHP acabam, as requisições ficam na fila. Quando a fila enche, o servidor começa a recusar conexões. Pronto: erro 503, página branca, site fora do ar.
As causas mais comuns:
Hospedagem compartilhada genérica. Você divide CPU, memória e processos PHP com dezenas de outros sites. Quando seu tráfego sobe, você esbarra no limite do vizinho. Ou o provedor simplesmente te throttla pra proteger os outros clientes. Se você roda campanha pesada e ainda está em hospedagem compartilhada, leia este comparativo entre VPS e hospedagem compartilhada antes de qualquer outra coisa.
Cache ausente ou mal configurado. Sem cache de página, cada visita executa PHP e consulta o banco do zero. Com cache funcionando, o servidor entrega um HTML estático pronto. A diferença de capacidade entre um site com e sem cache é brutal. Pode ser 10x, 50x, dependendo da página. Mas cache mal configurado é quase tão ruim quanto cache nenhum. Página de checkout cacheada que mostra o carrinho de outro cliente? Problema sério. Escolher e configurar o plugin de cache certo é metade do trabalho.
Cache de objeto inexistente. Mesmo com cache de página, áreas dinâmicas (checkout, área de membros, painel) continuam batendo no banco. Redis como cache de objeto reduz drasticamente a carga no MySQL, porque guarda as consultas mais frequentes na memória RAM. Sem Redis, o banco de dados vira o gargalo.
PHP desatualizado ou com poucos workers. PHP 7.4 consome mais memória e é mais lento que PHP 8.x na mesma tarefa. E se o servidor tem só 5 workers PHP, a sexta pessoa simultânea já entra na fila. Em pico de lançamento, 5 workers é o mesmo que nada.
Banco de dados saturado. Tabela wp _ options inchada, transients acumulados, queries lentas de plugins mal escritos. No dia a dia você nem percebe. No pico, cada milissegundo a mais por query se multiplica por milhares de conexões. Se seu site já anda lento no dia a dia , o pico só vai amplificar o problema.
Página de vendas pesada. Page builders com 40 seções, slider com vídeo em autoplay, fontes customizadas carregando do próprio servidor, imagens sem compressão. Tudo isso aumenta o tempo de resposta e o consumo de recursos por visita.
A matemática da capacidade que ninguém te explica
Quando você pergunta "quantas visitas meu site aguenta?", a resposta honesta é: depende do que você quer dizer com "visitas".
100 mil visitas por mês parece muito. Mas distribua isso ao longo de 30 dias, 24 horas por dia, e você tem uma média de 138 visitas por hora. Menos de 3 por minuto. Qualquer servidor decente aguenta isso dormindo.
O problema do lançamento é outro. Você não tem tráfego distribuído. Você tem um pico concentrado.
Imagina: sua lista tem 30 mil pessoas. Você dispara o e-mail de abertura de carrinho às 8h da manhã. Taxa de abertura de 25%. São 7.500 pessoas abrindo o e-mail. Se 40% clicam no link, são 3.000 cliques. Não em uma hora. Em 10, 15 minutos.
3.000 visitas em 15 minutos. Com parte dessas pessoas navegando, clicando em botão, abrindo checkout. Talvez 200, 300 conexões simultâneas no pico real.
Agora soma os anúncios que estão rodando ao mesmo tempo. Mais umas centenas de visitas chegando por fora.
A pergunta certa não é "quantas visitas por mês o servidor aguenta". É "quantas conexões simultâneas ele consegue servir sem degradar". E essa pergunta só se responde com teste de carga. Não com o número bonito que aparece na página de vendas da hospedagem.
Checklist: 2 semanas antes da campanha
Esse é o momento de preparar a infraestrutura. Não na véspera. Duas semanas antes, no mínimo.
Rode um teste de carga real
Você precisa saber o limite do seu servidor antes que seus clientes descubram por você.
Ferramentas como k6 ou Loader.io simulam centenas de usuários simultâneos acessando suas páginas. O teste vai te mostrar em que ponto o tempo de resposta começa a subir, quando as primeiras requisições falham e qual é o teto prático do seu setup atual.
Um teste simples com k6:
import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 },
{ duration: '3m', target: 300 },
{ duration: '2m', target: 500 },
{ duration: '1m', target: 0 },
],
};
export default function () {
http.get('https://seusite.com.br/pagina-de-vendas/');
sleep(1);
}
Esse script sobe gradualmente de 0 a 500 usuários simultâneos e mostra onde o servidor começa a sofrer. Rode contra a página de vendas e contra o checkout. São as duas URLs que vão receber a pancada.
Se o servidor começa a engasgar com 150 usuários simultâneos e você espera 300 no pico, você tem um problema. Melhor descobrir agora do que no dia.
Configure cache de página agressivo
Toda página pública e estática (home, página de vendas, blog, sobre) deve ser servida do cache. O servidor não deve executar PHP pra entregar essas páginas.
Valide que o cache está funcionando de verdade. Acesse a página, veja os headers HTTP. Procure por um header X-Cache: HIT ou equivalente do seu plugin. Se não está lá, o cache não está servindo.
Ative cache de objeto com Redis
Redis guarda no RAM as consultas mais frequentes ao banco de dados. Pra páginas dinâmicas (checkout, área de membros), onde o cache de página não pode atuar, Redis é a diferença entre o banco aguentar e o banco travar.
Se seu servidor não tem Redis instalado, esse é o momento de resolver.
Coloque uma CDN na frente
Uma CDN (Cloudflare, Bunny, CloudFront) distribui seus arquivos estáticos (imagens, CSS, JS) por servidores no mundo todo. Isso tira carga do seu servidor de origem e entrega os arquivos mais rápido pro visitante.
Mas o benefício principal em pico de tráfego é outro: a CDN absorve boa parte das requisições antes delas chegarem ao seu servidor. Se a CDN cachear a página de vendas inteira, seu servidor nem sente a maioria das visitas.
Este guia explica como configurar CDN no WordPress passo a passo.
Garanta PHP 8.x com workers suficientes
Se você ainda está em PHP 7.4, atualize. PHP 8.x é significativamente mais rápido e consome menos memória por processo.
Quanto aos workers: o número ideal depende da sua VPS (memória disponível, tipo de página, plugins ativos). Mas a regra geral é simples. Se o teste de carga mostrou que o servidor engasga antes do volume esperado, aumentar workers PHP (e a memória pra sustentá-los) é uma das primeiras alavancas.
Monte um ambiente de staging
Toda mudança que você fizer nessas duas semanas (configuração de cache, atualização de PHP, ajustes de performance) deve ser testada em staging antes de ir pra produção.
Não teste em produção durante campanha. Se você não tem staging configurado, este guia mostra como criar um .
Otimize a página de vendas
Passe a página de vendas no PageSpeed Insights. Comprima imagens. Remova seções que não convertem. Carregue vídeos via embed (YouTube, Vimeo), não hospedados no próprio servidor. Cada KB a menos por pageview é capacidade a mais no pico.
Se sua operação inclui loja ou checkout WooCommerce, vale revisar os gargalos específicos de WooCommerce lento antes do lançamento.
Checklist: na semana da campanha
A infraestrutura já está preparada. Agora é hora de congelar e monitorar.
Congele mudanças
Nada de atualizar plugin, trocar tema ou instalar ferramenta nova na semana do lançamento. Cada atualização é um risco de incompatibilidade. Se der problema, você vai estar resolvendo bug técnico no momento em que deveria estar acompanhando vendas.
Regra: se não é crítico pra segurança, espera o lançamento acabar.
Faça backup fresco
Backup completo (arquivos + banco de dados) no dia anterior à abertura. Armazenado fora do servidor. Se qualquer coisa der errado, você tem pra onde voltar em minutos, não em horas.
Configure monitoramento de uptime
Use um serviço de monitoramento externo (UptimeRobot, Better Stack, Hetrix Tools) que verifique seu site a cada 1 minuto e envie alerta por WhatsApp, Telegram ou SMS se o site cair.
Você não quer descobrir que o site caiu porque um cliente reclamou no Instagram. Você quer saber antes do cliente.
Alinhe com quem cuida do servidor
Se você tem uma equipe técnica ou um serviço de gestão de infraestrutura, avise sobre o lançamento. Data, hora prevista do pico, volume esperado. Quem cuida do servidor precisa estar de olho, pronto pra agir se necessário.
Durante o pico: o que monitorar e o que fazer
Sinais de que o servidor está chegando no limite
- Tempo de resposta subindo (de 200ms pra 1s, 2s, 5s)
- Taxa de erro começando a aparecer (5xx no log)
- CPU ou memória acima de 85% sustentado
- Fila de processos PHP crescendo
O que fazer se começar a degradar
Primeiro: não entre em pânico e saia mexendo em configuração. A pior coisa que você pode fazer no meio de um pico é alterar config de cache ou reiniciar serviço sem saber o que está causando o problema.
Se o gargalo é PHP: aumentar workers temporariamente (se houver memória disponível) ou reiniciar o serviço PHP pra limpar processos travados.
Se o gargalo é banco de dados: verificar se há queries lentas travando conexões. Reiniciar MySQL em último caso.
Se o gargalo é memória: identificar o que está consumindo (quase sempre PHP) e decidir se dá pra aguentar até o pico passar ou se precisa intervir.
Se nada resolve e o site está fora do ar: ativar uma página estática de contingência (um HTML simples com o link de checkout ou um "volte em X minutos") enquanto resolve. Perder vendas por alguns minutos é melhor que perder por uma hora.
Quem tem equipe técnica de plantão resolve isso em minutos. Quem está sozinho, sem acesso SSH, sem saber o que olhar, perde tempo precioso tentando adivinhar.
Caso real: Marcel Fernandes
Marcel Fernandes é infoprodutor e investe pesado em tráfego pago. Chegou a rodar R$30 mil por dia em anúncios.
Na hospedagem anterior, o servidor caía durante as campanhas. O site saía do ar no momento em que mais precisava estar de pé. Cada queda era dinheiro de anúncio jogado fora e vendas perdidas.
Depois de migrar pra HOSTWP, o cenário mudou. O servidor parou de cair nas campanhas. O tempo de carregamento despencou. E a conversão subiu, porque as pessoas conseguiam acessar a página de vendas e completar a compra sem fricção.
Nas palavras dele: "Confio cegamente e recomendo cegamente."
O ponto aqui não é que a HOSTWP faz mágica. É que infraestrutura bem dimensionada, com cache configurado certo, PHP atualizado, Redis ativo, monitoramento real e alguém de plantão que entende WordPress resolve o problema. Não é complicado. Mas precisa ser feito antes do lançamento, não durante.
Perguntas frequentes
Quantas visitas simultâneas um site WordPress aguenta?
Depende do servidor, da configuração de cache e da complexidade da página. Um WordPress bem otimizado numa VPS com 4GB de RAM, Redis e cache de página pode servir centenas de conexões simultâneas sem degradar. Sem cache, o mesmo servidor pode travar com 50. A única forma de saber o limite real é rodar um teste de carga.
Hospedagem compartilhada aguenta lançamento?
Na maioria dos casos, não. Hospedagem compartilhada divide CPU, memória e I/O entre dezenas (às vezes centenas) de sites no mesmo servidor. Quando o pico de tráfego chega, o provedor limita seus recursos pra proteger os vizinhos. O resultado: timeout, erro 503, página que não carrega. Justamente na hora em que cada clique custou dinheiro. Se você roda campanha de tráfego pago com picos previsíveis, precisa de um ambiente onde os recursos são seus. VPS gerenciada é o mínimo.
Preciso de teste de carga mesmo com pouco tráfego?
Sim. "Pouco tráfego" no dia a dia não diz nada sobre o que acontece quando você liga uma campanha. O padrão muda. Em vez de visitas espalhadas ao longo do dia, você recebe rajadas concentradas em minutos. Um site que funciona bem com 20 visitas por hora pode engasgar com 200 em 5 minutos. Teste de carga mostra onde está o gargalo antes do seu orçamento de mídia mostrar.
Cache resolve sozinho?
Cache de página resolve boa parte do problema. Mas não resolve tudo. Se o seu site tem formulários dinâmicos, carrinho, área de membros, checkout ou qualquer página que não pode ser cacheada, essas requisições vão bater direto no PHP e no banco de dados. Cache também não corrige servidor subdimensionado, banco de dados inchado ou plugins pesados rodando em cada request. Cache é uma camada. Não é a solução inteira.
Com quanto tempo de antecedência devo preparar o site pra campanha?
No mínimo uma semana. O ideal são duas. Isso dá tempo de rodar auditoria de performance, corrigir gargalos, configurar cache e CDN, ajustar limites do servidor, rodar teste de carga, corrigir o que o teste revelar e rodar de novo. Preparar na véspera é apostar que vai dar certo. E quando não dá, o custo é o orçamento de mídia jogado fora.
Prepare seu site antes de ligar a campanha
A HOSTWP cuida da infraestrutura pra quem roda campanha de tráfego pago no WordPress. Auditoria de performance, configuração de servidor, cache, CDN, teste de carga e acompanhamento no dia do pico.
Atendimento direto no WhatsApp em horário comercial. Sem fila, sem ticket, sem robô.
Leia também: Site WordPress Lento? 10 Causas | Auditoria de Performance | VPS ou Hospedagem Compartilhada