O que é um profiler de plugins WordPress e por que ele resolve o que a auditoria geral não resolve
Você abre o site do cliente e ele demora 4 segundos para renderizar. Já passou pelo cache, já minificou CSS e JS, já otimizou imagens, e o tempo não caiu. A auditoria de performance WordPress olha o site inteiro, mas não responde à pergunta que interessa: qual plugin está consumindo o tempo. Um profiler de plugins WordPress isola exatamente isso, mostrando quanto cada plugin gasta em queries, hooks e chamadas HTTP.
Na prática, a diferença é entre saber que o site está lento e saber que o plugin de formulário adiciona 380 ms em cada carregamento por causa de uma consulta que roda no init. O primeiro diagnóstico leva a chutes. O segundo leva a uma decisão.
Query Monitor: o profiler de plugins que você já pode instalar
O Query Monitor é o profiler mais usado em WordPress. Ele é gratuito, vive no repositório oficial e adiciona uma barra de ferramentas no rodapé do site quando você está logado. A documentação oficial do plugin fica em wordpress.org/plugins/query-monitor.
O ponto que muita gente ignora: o Query Monitor não mede o tempo de carregamento total do site. Ele mede o que acontece do lado do PHP, dentro do WordPress. Ou seja, ele mostra o custo de cada plugin em processamento, não o tempo de download de imagens ou o TTFB do servidor. Para a segunda parte, use o teste de velocidade de carregamento WordPress em paralelo.
Como ler a aba Queries sem se perder
Ao abrir qualquer página do site logado, clique em “Queries” na barra do Query Monitor. A tela mostra três coisas úteis:
- O tempo total gasto em queries MySQL naquela página.
- A lista de queries, ordenada por tempo, com o tempo de cada uma.
- Quem chamou cada query: o nome do plugin ou do tema aparece como “Caller”.
Você procura por queries que aparecem várias vezes com o mesmo padrão. Um plugin que roda a mesma consulta 40 vezes numa página de arquivo costuma ter problema de cache interno. O tempo somado dessas repetições é o que você vai comparar depois.
A aba Hooks mostra o custo por componente
A aba “Hooks & Actions” lista os hooks do WordPress e quanto cada callback gasta. É aqui que você descobre, por exemplo, que um plugin registra uma função no wp_head que leva 120 ms. A aba “HTTP API” mostra as chamadas externas feitas por plugins, com o tempo de resposta de cada uma. Um plugin de frete que consulta uma API externa a cada carregamento de página aparece aqui, e o tempo dele não é culpa do seu servidor.
Medir tempo de carregamento de plugins: o método antes e depois
O Query Monitor mostra o custo agregado, mas nem sempre separa um plugin específico. Para isolar, você precisa do método antes e depois: medir, desativar um plugin, medir de novo, comparar. O problema é fazer isso num site de cliente em produção.
Regra número um: nunca desative plugin em horário de pico
Desativar um plugin em produção pode quebrar o layout, o checkout ou o formulário de contato. Se o site é de e-commerce, o risco é pedido perdido. Escolha uma janela de baixo tráfego, avise o cliente e tenha o backup do dia em mãos. O artigo sobre falha de backup no WordPress explica o que verificar antes de confiar no arquivo de restauração.
Passo a passo do teste controlado
- Anote o tempo de referência: abra a home, uma página interna e o checkout (se houver) com o Query Monitor ativo e registre o tempo total de queries e o número de queries.
- Desative um único plugin em Plugins → Plugins instalados.
- Limpe o cache de objeto e o cache de página, se houver. Sem isso, a medição mente.
- Recarregue as mesmas três páginas e anote os mesmos números.
- Reative o plugin e repita com o próximo da lista.
Uma diferença de 20 ms pode ser ruído do servidor. Diferenças acima de 100 ms em queries são sinal claro. Repita a medição duas vezes antes de concluir, porque variação de rede e cache de opcode distorcem o resultado.
Quando o site não pode sair do ar nem por cinco minutos
Se o cliente não autoriza janela de manutenção, clone o site para um ambiente de teste. A maioria dos painéis de hospedagem oferece isso. No clone, você pode desativar plugins à vontade, ativar WP_DEBUG e SAVEQUERIES sem medo. O comportamento de performance costuma ser próximo o suficiente para decidir qual plugin pesa. A ressalva é que o clone pode ter menos tráfego e cache diferente, então os tempos absolutos não batem, mas a proporção entre plugins se mantém.
O que fazer com o plugin que você identificou como pesado
Encontrar o culpado é metade do trabalho. A outra metade é decidir o que fazer. Existem três caminhos, e a escolha depende do custo de cada um.
| Situação | Caminho indicado | Risco |
|---|---|---|
| Plugin tem opção de desativar módulo ou carregar script só onde precisa | Configurar | Baixo, mas exige testar cada tela |
| Plugin faz o mesmo que outro já instalado, com menos custo | Substituir | Médio, migração de dados e ajuste de layout |
| Plugin é essencial e não tem alternativa viável | Convocar | Baixo, mas exige aceitar o custo |
Configurar antes de substituir
Muitos plugins pesados têm configuração que reduz o custo. Plugins de formulário costumam carregar CSS e JS em todas as páginas, mesmo onde não há formulário. Plugins de slider fazem o mesmo. Verifique se existe opção de carregar assets apenas nas páginas onde o shortcode aparece. Isso costuma resolver mais do que trocar de plugin.
Substituir com cuidado
Trocar plugin é a decisão mais arriscada. Antes de remover, confirme que os dados migram, que os shortcodes continuam funcionando e que o layout não quebra. Se o plugin em questão for de login, o artigo sobre trocar plugin de login WordPress sem perder acesso mostra o procedimento seguro. Para outros tipos, a lógica é parecida: nunca desinstale antes de ter o substituto configurado e testado.
Convocar com o plugin pesado
Alguns plugins são pesados por natureza e não têm alternativa. Um plugin de assinatura recorrente, por exemplo, faz validações que custam tempo. Nesse caso, aceite o custo e compense em outro lugar: cache de página mais agressivo, CDN, upgrade de servidor. O importante é saber que o tempo gasto ali é consciente, não um mistério.
Erros comuns ao usar profiler de plugins WordPress
- Medir com cache ativo. O cache de página esconde o custo real do PHP. Desative-o durante o teste.
- Desativar vários plugins de uma vez. Você perde a atribuição. Um por vez, sempre.
- Confundir tempo de query com tempo de rede. Uma query rápida pode gerar uma resposta lenta se o banco estiver em outro servidor.
- Ignorar o admin. O painel também carrega plugins. Um plugin pesado no admin atrapalha a edição de conteúdo, mesmo que o site público esteja rápido.
- Deixar o Query Monitor ativo para visitantes. Ele só deve aparecer para administradores logados. Verifique a configuração antes de sair do site.
Prevenção: como não voltar a esse problema
Depois de identificar o plugin pesado, crie uma rotina de medição. Meça o tempo de queries da home uma vez por mês e guarde o número. Quando ele subir, você sabe que algo novo entrou. O artigo sobre auditoria de performance em vários sites mostra como organizar essa rotina quando você administra mais de um cliente.
Além disso, antes de instalar qualquer plugin novo, verifique se ele carrega assets em todas as páginas ou só onde precisa. Essa única checagem evita a maior parte dos problemas de peso por plugin.
Quando chamar alguém
Se você já isolou o plugin, já testou configuração e substituição, e o site continua lento, o problema pode estar fora do WordPress: banco de dados inchado, servidor sem opcache ou consultas externas lentas. Nesse ponto, vale revisar o banco com o guia de limpeza de banco de dados WordPress lento antes de contratar alguém. Se o problema persistir, um profissional de infraestrutura consegue olhar o servidor, não só o site.
Quem administra vários sites sente esse problema multiplicado: cada cliente tem um conjunto diferente de plugins, e o plugin pesado de um não é o do outro. O 100% WP ajuda a manter a lista de plugins de todos os sites visível em um só lugar, para você perceber quando um plugin novo entra e o tempo de queries sobe.
