Você abre o e-mail e lá está: “meu site está lento”. O cliente percebeu antes de você. Enquanto isso, o painel de métricas que você configurou meses atrás está cheio de gráficos que ninguém olhou. A checagem automática de performance existe exatamente para inverter essa ordem: o alerta chega antes do cliente, com o número que comprova a queda e o momento em que ela começou.
Neste guia, você vai montar um sistema de checagem automática de performance para vários sites WordPress. A ordem é: definir o que medir, escolher a frequência, guardar o histórico e transformar o resultado em alerta por e-mail. Também vamos ver como separar queda real de oscilação da hospedagem e o que fazer quando o cliente é quem percebe a lentidão primeiro.
O que medir em cada site (e o que ignorar)
Nem toda métrica merece um alerta. Algumas oscilam tanto que viram ruído e fazem você ignorar o sistema. Na prática, três números resolvem a maior parte dos casos:
| Métrica | O que revela | Frequência sugerida |
|---|---|---|
| TTFB (Time to First Byte) | Resposta do servidor, PHP e banco de dados | A cada 15 ou 30 minutos |
| Peso e número de requisições da home | Imagens, scripts e CSS carregados na página inicial | Uma vez por dia |
| PageSpeed (Lighthouse) mobile | Experiência real de carregamento no celular | Uma vez por semana |
O TTFB é o mais sensível: sobe rápido quando o banco cresce, quando um plugin faz consulta pesada ou quando a hospedagem está saturada. Por isso, é o melhor candidato a checagem frequente. Já o PageSpeed demora para rodar e consome recurso, então faz sentido semanalmente, ou depois de cada mudança relevante no site.
Se você ainda não sabe qual métrica atacar primeiro, vale ler o guia de auditoria de performance WordPress em vários sites. Ele ajuda a priorizar antes de montar o monitoramento.
Com que frequência rodar cada checagem
A frequência depende do custo da medição e do tempo que você leva para reagir. Medir de minuto em minuto gera dado demais e alerta demais. Medir uma vez por mês deixa o cliente descobrir o problema antes de você.
- TTFB a cada 15 ou 30 minutos: é barato, roda rápido e detecta queda de servidor ou gargalo de banco.
- Peso da home uma vez por dia: captura imagem nova sem compressão, script de terceiro adicionado ou plugin que engordou a página.
- PageSpeed mobile uma vez por semana: serve como termômetro, não como alarme. Mudanças bruscas aqui merecem investigação, mas não acordam ninguém de madrugada.
Em resumo, a checagem automática de performance precisa de camadas: uma rápida para detectar queda, uma média para acompanhar tendência e uma lenta para validar a experiência final. Assim você não afoga o time em alerta e ainda pega o problema cedo.
Onde guardar o histórico (e por que isso importa)
Sem histórico, você não sabe se o site está lento hoje ou se sempre foi assim. E sem essa comparação, é impossível separar queda real de oscilação normal da hospedagem.
O histórico pode ficar em três lugares, e a escolha depende do tamanho da operação:
- Planilha compartilhada: funciona para poucos sites e times pequenos, mas exige alguém alimentando os dados.
- Ferramenta de monitoramento externa: já guarda série histórica e gera gráfico, mas costuma cobrar por site monitorado.
- Painel de gestão de vários sites: centraliza a série de todos os sites no mesmo lugar, o que ajuda quando o volume cresce.
O ponto central é ter pelo menos 30 dias de histórico por métrica. Com isso, você consegue definir uma faixa normal para cada site. Por exemplo: se o TTFB de um site fica entre 200 ms e 400 ms na maior parte do tempo, um pico para 900 ms é sinal claro de que algo mudou.
Como transformar medição em alerta por e-mail
Painel que ninguém abre não serve para nada. O valor da checagem automática de performance está no alerta que chega até você, não no gráfico bonito.
A regra é simples: dispare e-mail apenas quando o valor sair da faixa normal por tempo suficiente para não ser ruído. Na prática, isso significa três condições:
- Limite definido por site: cada site tem sua faixa, então o alerta precisa ser configurado individualmente, não com um número único para todos.
- Confirmação em duas medições seguidas: evita alerta falso por pico isolado de rede ou de hospedagem.
- Janela de silêncio: depois de disparar, o sistema espera algumas horas antes de mandar o mesmo alerta de novo, para não lotar a caixa de entrada.
Se o seu monitoramento de uptime já está configurado, vale reaproveitar a mesma lógica de alerta. O artigo sobre monitoramento de uptime em vários sites mostra como estruturar isso.
Queda real ou oscilação da hospedagem?
Esse é o diagnóstico que separa quem usa monitoramento de quem sofre com ele. Hospedagem compartilhada oscila. Rede oscila. Um pico isolado não significa problema.
Para decidir, observe três coisas:
- Duração: pico de poucos minutos costuma ser oscilação. Queda que se mantém por uma hora ou mais é problema real.
- Alcance: se vários sites na mesma hospedagem sobem juntos, o problema é do servidor, não do site.
- Correlação com mudança: plugin atualizado, tema alterado ou pico de tráfego explicam boa parte das quedas. Sem mudança recente, a suspeita aumenta.
Quando a queda é real e não tem causa óbvia, o próximo passo é investigar o que está pesando. O guia de profiler de plugins WordPress ajuda a isolar o culpado sem chute.
Quando o cliente percebe antes do monitor
Se o cliente reclamou primeiro, o problema não é só de performance: é de processo. Três causas comuns:
- Limite de alerta frouxo: o sistema só avisa quando o site já está muito lento, e nesse ponto o cliente já sentiu.
- Métrica errada: você monitora PageSpeed semanal, mas o que dói no cliente é o TTFB em horário de pico.
- Alerta sem dono: o e-mail chega, mas ninguém está escalado para agir.
Corrigir isso é mais gestão do que técnica. Defina quem recebe o alerta, qual o tempo máximo de resposta e o que fazer quando o problema não se resolve rápido. Ter um manual para cliente WordPress com o que está incluído no contrato evita discussão sobre prazo de correção.
Quando NÃO montar checagem automática
Monitorar tem custo: tempo de configuração, ruído de alerta e manutenção do próprio sistema. Em alguns cenários, não vale a pena:
- Site único e estável: uma verificação manual por semana resolve, e o esforço de automatizar não se paga.
- Site em desenvolvimento: a performance muda a cada commit, então o histórico vira lixo.
- Orçamento apertado: se não há verba para ferramenta, uma planilha simples com TTFB semanal já dá visibilidade mínima.
Em resumo, automatize quando o número de sites ou a criticidade justificar. Para poucos sites, o esforço pode ser maior que o benefício.
Erros comuns ao configurar checagem automática de performance
Alguns tropeços aparecem em quase toda configuração:
- Medir de dentro do servidor: o resultado não reflete a experiência do usuário, que passa por rede e CDN.
- Usar o mesmo limite para todos os sites: cada site tem faixa própria, e um limite único gera alerta falso em uns e alerta tardio em outros.
- Alertar em toda medição fora da média: sem confirmação em duas leituras, o time aprende a ignorar o e-mail.
- Não registrar mudanças: sem anotar deploy, atualização de plugin ou troca de hospedagem, você perde a correlação que explica a queda.
- Esquecer o mobile: boa parte do tráfego real vem do celular, e medir só desktop esconde o problema que o cliente vê.
Para comparar sites com critério, vale conferir o guia de velocidade de carregamento WordPress, que detalha como medir sem cair em comparação injusta.
Prevenção: manter o sistema útil ao longo do tempo
Um sistema de checagem automática de performance envelhece. Sites mudam, hospedagens mudam, o time muda. Para ele continuar útil:
- Revise os limites de alerta a cada trimestre, com base no histórico recente.
- Remova do monitoramento sites que saíram do portfólio, para não gerar alerta órfão.
- Documente quem recebe cada alerta e qual o tempo de resposta esperado.
- Guarde o histórico de mudanças junto com o histórico de métricas, para correlação futura.
Quando o número de sites cresce, manter esse sistema site a site vira trabalho em tempo integral. É aí que um painel como o 100% WP faz diferença: ele centraliza atualizações, backups, monitoramento e segurança de vários sites WordPress em um lugar só, o que reduz o tempo gasto em verificação manual e libera espaço para agir nos alertas que importam.
Quando chamar alguém
Se a queda de performance é recorrente mesmo com monitoramento ativo, o problema pode estar na hospedagem, no tema ou em um plugin específico. Nesses casos, vale envolver um desenvolvedor ou especialista em performance para investigar a fundo. O serviço de site lento do 100% WP é uma opção para quem precisa de diagnóstico e correção sem montar esse processo internamente.
Em resumo, a checagem automática de performance não substitui o diagnóstico, mas garante que você descubra o problema antes do cliente. Com métricas certas, frequência adequada, histórico e alerta por e-mail, o monitoramento de vários sites WordPress deixa de ser um painel esquecido e passa a ser parte real da operação.
