Velocidade de carregamento WordPress: medir e comparar sites

Você abre o painel do cliente e o site demora a responder. Testa no PageSpeed, o score é 45. No site do outro cliente, 92. A conclusão parece óbvia: o primeiro está lento. Só que os dois testes foram feitos em horários diferentes, um com cache quente e outro com cache frio, e o servidor de um responde em 200 ms enquanto o do outro responde em 1,8 s. Antes de instalar mais um plugin de cache, é preciso medir a velocidade de carregamento WordPress de forma comparável entre sites.

Este artigo propõe uma ordem de diagnóstico diferente da receita comum. Primeiro separar o que é problema de servidor do que é problema de página. Depois montar uma linha de base que permita dizer qual site está realmente pior, e não apenas qual foi testado no pior momento.

Por que o score do PageSpeed não serve para comparar sites

O PageSpeed Insights e ferramentas parecidas dão uma nota que varia com o que foi carregado no momento do teste. Anúncios, scripts de terceiros, A/B tests e até o horário do dia mudam o resultado. Comparar o score de dois sites diferentes é comparar duas medições feitas em condições distintas.

Além disso, o score mistura duas camadas que exigem correções opostas. Uma delas é a resposta do servidor. A outra é o que o navegador faz depois que o HTML chega. Se o TTFB está alto, nenhum ajuste de imagem ou minificação vai resolver. Por isso a primeira etapa é isolar o TTFB.

Separe TTFB de métricas de página

O TTFB (Time to First Byte) mede quanto tempo o servidor leva para começar a responder. Ele depende de hospedagem, PHP, banco de dados e cache de objeto. As métricas de página (LCP, CLS, INP) dependem de imagens, CSS, JavaScript e plugins. São problemas diferentes, com soluções diferentes.

Na prática, se o TTFB passa de 600 ms em um site com cache ativo, o problema é de infraestrutura. Instalar plugin de cache adicional só mascara o sintoma e adiciona peso. Se o TTFB está baixo mas o LCP está alto, aí sim a investigação é de página.

Como medir a velocidade de carregamento WordPress sem poluir o resultado

Para comparar sites, você precisa de condições iguais. Use sempre o mesmo navegador, a mesma região de teste e o mesmo horário. Se possível, faça três execuções por site e use a mediana, não a média. A média é distorcida por picos.

1. Ative o cache do site e aqueça a página inicial visitando-a uma vez.
2. Abra as ferramentas de desenvolvedor (F12) e vá até a aba Network.
3. Marque a opção de desabilitar cache do navegador para simular um visitante novo.
4. Recarregue e observe o campo Waiting (TTFB) e o tempo total de carregamento.
5. Repita três vezes e anote a mediana de cada métrica.

Para o TTFB, uma alternativa é usar curl no terminal, que remove a variável do navegador:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://seusite.com.br

Rode o comando três vezes e compare. Se o TTFB variar muito entre execuções, o servidor está instável. Isso por si só já é um achado de diagnóstico.

Core Web Vitals WordPress: o que olhar em cada métrica

As Core Web Vitals são LCP, CLS e INP. Cada uma aponta para um tipo de problema diferente.

• LCP (Largest Contentful Paint): tempo até o maior elemento visível aparecer. Geralmente é a imagem de destaque ou o título. Costuma melhorar com imagem otimizada, pré-carregamento e remoção de scripts que bloqueiam a renderização.
• CLS (Cumulative Layout Shift): o quanto a página “pula” enquanto carrega. Quase sempre vem de imagem sem dimensão definida, fonte que troca ou banner injetado por script.
• INP (Interaction to Next Paint): tempo de resposta a cliques e toques. Pode piorar com excesso de JavaScript de terceiros, como chat, pixel e widgets de comentário.

Para ver os dados de campo, e não só o teste de laboratório, o relatório de Core Web Vitals do Search Console é a fonte mais confiável. Ele mostra o que usuários reais experimentaram. A documentação oficial do Google sobre Core Web Vitals detalha cada métrica e os limites recomendados.

Montando uma linha de base entre sites de clientes diferentes

O erro mais comum ao testar velocidade de vários sites é comparar medições feitas em contextos diferentes. Para uma linha de base justa, defina um protocolo fixo e registre os resultados numa planilha. Cada site vira uma linha, com data, horário, TTFB, LCP e total de requisições.

Com essa tabela, a conversa muda. O cliente B não precisa de mais plugin de cache: o TTFB alto indica que o problema é o servidor. O cliente A tem TTFB bom, mas LCP alto, o que aponta para imagens ou scripts. O cliente C está saudável. Sem a linha de base, os três pareceriam “lentos” porque foram testados em momentos ruins.

Se você administra muitos sites, manter esse registro manualmente fica inviável. Um painel de gestão que centraliza métricas de vários sites ajuda a ver quem saiu da linha de base sem abrir cada um. É o tipo de coisa que o painel 100% WP faz ao reunir monitoramento e manutenção em um só lugar.

Quando o problema é servidor, não plugin

Se o TTFB medido com cache ativo passa de 600 ms de forma consistente, a investigação é outra. Verifique:

• Versão do PHP. Versões antigas processam mais devagar.
• Cache de objeto. Sem Redis ou Memcached, cada requisição consulta o banco.
• Consultas lentas. Plugins que fazem muitas queries pesam no TTFB.
• Sobrecarga do servidor. Hospedagem compartilhada com muitos sites no mesmo IP sofre com vizinhos barulhentos.

Nesses casos, trocar de plugin de cache não resolve. O caminho é ajustar PHP, ativar cache de objeto ou migrar de hospedagem. Para diagnosticar consultas lentas, os logs de erro do WordPress e o modo de depuração ajudam a localizar o que está travando.

Quando NÃO usar essa abordagem

O método de linha de base serve para comparar sites entre si e acompanhar evolução ao longo do tempo. Ele não substitui um teste de carga real. Se o objetivo é saber quantos visitantes simultâneos o site aguenta, é preciso uma ferramenta de load testing, não o DevTools.

Também não faz sentido comparar sites com naturezas diferentes. Um e-commerce com carrinho e checkout tem métricas naturalmente piores que um blog institucional. Nesse caso, compare cada site com ele mesmo ao longo do tempo, não com o outro.

Erros comuns ao medir velocidade de vários sites

1. Testar sempre no horário de pico e concluir que o site é lento.
2. Comparar score de PageSpeed de sites diferentes sem olhar TTFB.
3. Instalar plugin de cache em site com TTFB alto e achar que resolveu.
4. Ignorar dados de campo do Search Console e confiar só no teste de laboratório.
5. Não registrar os resultados, perdendo a linha de base.

Prevenção: transforme a medição em rotina

Meça os sites sempre no mesmo dia da semana e horário. Registre TTFB, LCP e número de requisições. Quando um site sair da linha de base, investigue antes de mexer em qualquer coisa. Atualizações de plugin, mudanças de tema e novos scripts de terceiros são as causas mais comuns de regressão. Manter um checklist de SEO técnico ajuda a não esquecer de revalidar após cada mudança.

Se o site depende de plugins desatualizados, a performance sofre junto. Vale revisar se algum plugin abandonado no WordPress está carregando scripts desnecessários. E se você gerencia muitos sites, padronizar a rotina de manter vários sites WordPress atualizados evita que a lentidão apareça sem aviso.

Quando chamar alguém

Se o TTFB está alto mesmo com cache ativo e PHP atualizado, o problema pode estar na infraestrutura da hospedagem. Nesse caso, abra um ticket com os números medidos: TTFB, horário e URL. Dados concretos aceleram o atendimento. Se depois de otimizar imagens, scripts e banco o LCP continuar acima de 2,5 s, pode ser hora de uma auditoria mais profunda, considerando até trocar de servidor ou refazer o tema.