Solucionar plugin causando lentidão no WordPress (e desativar cirurgicamente)

17 min de leitura  ·  Guia técnico

Plugin causando lentidão no WordPress é um dos problemas mais comuns em sites que cresceram organicamente, acumulando dezenas de extensões ao longo do tempo. Para identificar e desativar o plugin responsável pela lentidão de forma cirúrgica, siga estes passos:

1. Meça o TTFB atual do site com uma ferramenta externa (WebPageTest ou curl).
2. Instale e ative o plugin Query Monitor para mapear o tempo de execução por plugin.
3. Identifique os plugins com maior tempo de execução ou maior número de queries SQL.
4. Desative os suspeitos via WP-CLI ou renomeando a pasta via FTP/cPanel.
5. Meça o TTFB novamente após cada desativação para confirmar o culpado.
6. Substitua ou remova definitivamente o plugin problemático e limpe o cache.

Pré-requisitos para diagnosticar plugin causando lentidão no WordPress

• Acesso ao painel WordPress com perfil de administrador.
• Acesso SSH ao servidor para uso do WP-CLI (recomendado para desativação cirúrgica).
• WP-CLI instalado no servidor — versão 2.8 ou superior.
• Acesso FTP ou gerenciador de arquivos do cPanel como alternativa ao SSH.
• PHP 8.1 ou superior — versões antigas amplificam o impacto de plugins mal otimizados.
• Plugin Query Monitor disponível no repositório oficial do WordPress.org.
• Ambiente de staging (recomendado) para testar desativações antes de aplicar em produção.
• Permissão de escrita na pasta wp-content/plugins/ do servidor.

Como identificar plugin causando lentidão no WordPress com Query Monitor

O diagnóstico preciso de lentidão causada por plugin começa pela medição objetiva do tempo de resposta do servidor. O TTFB (Time To First Byte) é o indicador mais direto: ele mede quanto tempo o servidor leva para processar a requisição antes de enviar qualquer dado ao navegador. Um TTFB acima de 600ms em hospedagem compartilhada ou acima de 300ms em VPS já indica gargalo no backend.

Antes de instalar qualquer ferramenta, meça o TTFB atual via terminal para ter uma linha de base:

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

TTFB: 1.243s
Total: 1.891s

Com a linha de base registrada, instale o Query Monitor pelo painel WordPress em Plugins > Adicionar novo, pesquise "Query Monitor" e ative. Após a ativação, acesse qualquer página do site logado como administrador — uma barra de administração aparecerá no topo com dados de desempenho.

Clique em Query Monitor > Hooks & Actions para ver o tempo de execução por hook. Em seguida, acesse Queries para visualizar todas as consultas SQL agrupadas por componente. Plugins que executam dezenas de queries por requisição ou que realizam chamadas a APIs externas durante o carregamento aparecem claramente nesta tela.

Preste atenção especial às colunas:

• Caller — identifica qual plugin ou tema originou a query.
• Time — tempo de execução individual da query em milissegundos.
• Rows — número de linhas retornadas; queries que retornam milhares de linhas sem paginação são candidatas a otimização.

Plugins de construtores de página (page builders), sliders, plugins de SEO com rastreamento ativo e plugins de e-commerce com inventário grande são os candidatos mais frequentes a gargalos de banco de dados. Anote os nomes dos plugins suspeitos antes de prosseguir para a desativação.

Desativar plugin suspeito via WP-CLI sem acessar o painel admin

A desativação cirúrgica de plugins é o método mais eficiente para isolar o responsável pela lentidão sem afetar outros componentes do site. O WP-CLI permite executar essa operação diretamente no servidor via SSH, sem depender do painel WordPress — o que é especialmente útil quando o próprio painel está lento ou inacessível.

Conecte-se ao servidor via SSH e navegue até o diretório raiz do WordPress:

ssh usuario@ip-do-servidor
cd /home/usuario/public_html

Liste todos os plugins ativos para confirmar os nomes exatos:

wp plugin list --status=active --path=/home/usuario/public_html

+--------------------------+----------+-----------+---------+
| name                     | status   | update    | version |
+--------------------------+----------+-----------+---------+
| woocommerce              | active   | none      | 8.3.1   |
| elementor                | active   | available | 3.18.0  |
| revslider                | active   | none      | 6.7.0   |
| wordfence                | active   | none      | 7.11.0  |
+--------------------------+----------+-----------+---------+

Para desativar um plugin específico sem afetar os demais:

wp plugin deactivate revslider --path=/home/usuario/public_html

Plugin 'revslider' deactivated.

Após a desativação, meça o TTFB novamente:

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

TTFB: 0.412s

Se o TTFB caiu significativamente, o plugin desativado é o culpado. Se não houve melhora, reative-o e passe para o próximo suspeito:

wp plugin activate revslider --path=/home/usuario/public_html
wp plugin deactivate elementor --path=/home/usuario/public_html

Para desativar todos os plugins de uma vez e testar o TTFB do WordPress puro (útil para confirmar que o problema está em algum plugin e não no tema ou no servidor):

wp plugin deactivate --all --path=/home/usuario/public_html

Atenção: desativar todos os plugins simultaneamente pode quebrar funcionalidades críticas do site, como formulários de contato, autenticação de usuários e integrações de pagamento. Execute este comando apenas em ambiente de staging ou fora do horário de pico.

Desativar plugin via FTP ou gerenciador de arquivos do cPanel

Quando o acesso SSH não está disponível, a alternativa é renomear a pasta do plugin diretamente no sistema de arquivos. O WordPress verifica a existência da pasta do plugin a cada requisição; ao não encontrá-la com o nome original, desativa o plugin automaticamente e registra um aviso no banco de dados.

Conecte-se ao servidor via FTP usando o FileZilla (veja o guia Como usar o FileZilla como software FTP da minha Hospedagem) ou acesse o Gerenciador de Arquivos no cPanel.

Navegue até o diretório:

/public_html/wp-content/plugins/

Localize a pasta do plugin suspeito, por exemplo revslider, e renomeie-a para:

revslider_DESATIVADO

Acesse o site e meça o TTFB. Se houver melhora, confirme o culpado. Para reativar, basta renomear a pasta de volta ao nome original. Este método é especialmente útil quando o painel WordPress está inacessível por timeout causado pelo próprio plugin problemático.

Atenção: ao renomear a pasta, o WordPress pode exibir um aviso de "plugin inválido" no painel admin. Isso é esperado e não causa dano ao banco de dados. Basta renomear de volta para restaurar o estado anterior.

Analisar queries SQL pesadas geradas por plugins no WordPress

Nem toda lentidão causada por plugin se manifesta como tempo de execução PHP alto. Muitos plugins geram consultas SQL ineficientes que sobrecarregam o banco de dados, especialmente em sites com grande volume de posts, usuários ou pedidos WooCommerce. O Query Monitor exibe essas queries, mas para uma análise mais profunda é possível habilitar o log de queries lentas diretamente no MySQL ou MariaDB.

No servidor, edite o arquivo de configuração do MySQL (geralmente em /etc/mysql/mysql.conf.d/mysqld.cnf no Ubuntu ou /etc/my.cnf no AlmaLinux 9):

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Reinicie o serviço:

systemctl restart mysql

Após alguns minutos de tráfego, analise o log:

mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

Count: 47  Time=3.21s (150s)  Lock=0.00s (0s)  Rows=8432.0 (396304)
SELECT * FROM wp_postmeta WHERE meta_key LIKE '_sku%'

Queries como SELECT * FROM wp_postmeta WHERE meta_key LIKE '%valor%' sem índice são características de plugins de e-commerce ou SEO mal otimizados. Com o nome da tabela e o padrão da query, é possível identificar qual plugin a origina consultando o código-fonte ou usando o Query Monitor com a opção de rastreamento de chamadas ativada.

Para sites hospedados em planos compartilhados sem acesso ao MySQL via SSH, o acesso remoto ao MySQL via cPanel permite executar análises de performance diretamente pelo MySQL Workbench ou DBeaver.

Substituir ou otimizar plugin problemático no WordPress

Identificado o plugin responsável pela lentidão, existem três caminhos: substituição por alternativa mais leve, configuração para reduzir o impacto, ou remoção definitiva. A escolha depende da funcionalidade que o plugin oferece e do quanto ela é crítica para o negócio.

Plugins de slider (Revolution Slider, Slider Revolution, LayerSlider) são historicamente pesados por carregarem scripts e estilos em todas as páginas, mesmo onde não são usados. A solução mais eficaz é substituí-los por blocos nativos do Gutenberg ou pelo Splide.js integrado manualmente apenas nas páginas necessárias.

Para plugins que não podem ser substituídos, algumas otimizações reduzem o impacto:

• Desativar carregamento global de scripts: muitos plugins oferecem opção para carregar assets apenas em páginas específicas. Verifique as configurações avançadas do plugin.
• Limitar o escopo de execução: use o hook is_page() ou is_singular() no functions.php do tema para condicionar o carregamento do plugin.
• Habilitar cache de objetos: plugins que fazem queries repetidas ao banco de dados se beneficiam do Redis ou Memcached como cache de objetos, reduzindo o número de consultas SQL por requisição.
• Atualizar o plugin: versões antigas frequentemente contêm ineficiências corrigidas em releases posteriores. Verifique o changelog antes de atualizar em produção.

Após qualquer alteração, limpe o cache do WordPress e do servidor antes de medir o TTFB novamente:

wp cache flush --path=/home/usuario/public_html

Success: The cache was flushed.

Problemas comuns e como resolver

Sintoma: TTFB alto mesmo após desativar todos os plugins

Causa: o gargalo não está nos plugins, mas no tema ativo, em configurações de PHP (memory_limit baixo, opcache desativado) ou em recursos insuficientes do servidor (CPU ou memória RAM esgotados).
Solução: troque temporariamente para o tema padrão do WordPress (Twenty Twenty-Four) via WP-CLI com wp theme activate twentytwentyfour e meça o TTFB. Se melhorar, o tema é o culpado. Se não melhorar, verifique o uso de CPU e memória com top ou htop no servidor e considere um upgrade de plano ou migração para VPS.

Sintoma: Painel WordPress inacessível por timeout ao tentar desativar plugin

Causa: o plugin problemático está causando timeout durante o próprio carregamento do painel admin, impedindo o acesso à tela de plugins.
Solução: use o WP-CLI via SSH para desativar o plugin sem carregar o painel: wp plugin deactivate nome-do-plugin --path=/caminho/wordpress. Alternativamente, renomeie a pasta do plugin via FTP ou gerenciador de arquivos do cPanel conforme descrito na seção anterior.

Sintoma: Query Monitor não aparece na barra de administração

Causa: o plugin pode estar instalado mas não ativo, ou o usuário logado não tem perfil de administrador, ou um plugin de cache está servindo a página sem executar o PHP.
Solução: confirme que o plugin está ativo com wp plugin list --name=query-monitor. Limpe o cache do site antes de acessar. Certifique-se de estar logado com um usuário com papel de Administrador, não Editor ou Autor.

Sintoma: Lentidão ocorre apenas em páginas específicas, não no site inteiro

Causa: o plugin problemático é carregado condicionalmente apenas em determinados tipos de página (single post, página de produto WooCommerce, página de checkout) ou o conteúdo específico da página contém shortcodes ou blocos que ativam o plugin.
Solução: acesse a página lenta logado como administrador com o Query Monitor ativo e analise quais plugins aparecem na aba Hooks & Actions exclusivamente nessa página. Compare com uma página rápida para identificar a diferença.

Sintoma: Site ficou com layout quebrado após desativar plugin

Causa: o plugin desativado fornecia funcionalidades de frontend (shortcodes, blocos Gutenberg, widgets) que o tema ou o conteúdo das páginas ainda referencia.
Solução: reative o plugin imediatamente com wp plugin activate nome-do-plugin. Antes de desativar definitivamente, substitua todos os shortcodes e blocos do plugin nas páginas afetadas por alternativas nativas ou de outro plugin. Use o modo de manutenção durante a transição para evitar que visitantes vejam o layout quebrado.

Perguntas frequentes sobre plugin causando lentidão no WordPress

Como saber qual plugin está deixando o WordPress lento?

A forma mais precisa é usar o plugin Query Monitor, que exibe o tempo de execução de cada plugin por requisição, incluindo o número de queries SQL geradas e o tempo total consumido. Outra abordagem é desativar todos os plugins via WP-CLI e reativá-los um a um, medindo o TTFB após cada ativação para isolar o culpado. Combine as duas técnicas para um diagnóstico mais rápido: use o Query Monitor para identificar os três principais suspeitos e depois confirme com a desativação individual.

Posso desativar plugins do WordPress sem acessar o painel admin?

Sim. Via WP-CLI, execute wp plugin deactivate nome-do-plugin --path=/caminho/do/wordpress com acesso SSH ao servidor — o comando opera diretamente no banco de dados sem carregar o painel WordPress. Também é possível renomear a pasta do plugin via FTP ou gerenciador de arquivos do cPanel, o que força o WordPress a desativá-lo automaticamente na próxima requisição. O método FTP é útil quando o SSH não está disponível no plano de hospedagem contratado.

O que é TTFB e por que ele indica lentidão causada por plugin?

TTFB (Time To First Byte) é o tempo que o servidor leva para enviar o primeiro byte de resposta ao navegador após receber a requisição. Quando um plugin executa consultas pesadas ao banco de dados ou chamadas a APIs externas durante o carregamento da página, o PHP fica bloqueado aguardando essas operações antes de gerar o HTML — o que aumenta o TTFB visivelmente. Um TTFB alto indica que o gargalo está no processamento do servidor, não no download de assets do frontend, o que aponta diretamente para plugins, temas ou configurações de PHP/banco de dados.

Desativar um plugin pode quebrar o site WordPress?

Depende do plugin e de como o conteúdo do site foi construído. Plugins de segurança, cache, construtores de página ou funcionalidades críticas como WooCommerce podem afetar significativamente o comportamento do site ao serem desativados. Por isso, recomenda-se testar em ambiente de staging antes de desativar em produção, ou usar o modo de manutenção para evitar impacto nos visitantes durante o diagnóstico. Plugins simples de widgets ou integrações de redes sociais geralmente podem ser desativados sem risco imediato.

Query Monitor é seguro para usar em produção?

O Query Monitor exibe dados sensíveis de banco de dados e configuração do servidor apenas para usuários logados como administrador, sendo seguro para uso em produção durante o diagnóstico. Visitantes não autenticados não têm acesso a nenhuma informação do plugin. Ainda assim, recomenda-se desativá-lo após concluir o diagnóstico, pois ele adiciona um overhead mensurável a cada requisição ao coletar e processar dados de performance — overhead que é desnecessário em operação normal do site.

Conclusão

• Meça antes de agir: registre o TTFB com curl antes de qualquer mudança para ter uma linha de base objetiva e confirmar melhorias após cada desativação.
• Use WP-CLI para desativação cirúrgica: desative plugins individualmente via SSH sem depender do painel WordPress, especialmente quando o próprio painel está lento ou inacessível por causa do plugin problemático.
• Substitua, não apenas remova: após identificar o plugin culpado, avalie alternativas mais leves ou configure o plugin existente para carregar apenas nas páginas onde é necessário, em vez de remover a funcionalidade completamente.

Leia também

• Solucionar erro 500 no WordPress: diagnóstico rápido e correção definitiva
• Guia para resolver erro de memória no WordPress: diagnóstico e ampliação
• Migrar WordPress entre hospedagens sem downtime: procedimento completo

Precisa de ajuda com hospedagem WordPress mais rápida?

Um ambiente de hospedagem bem configurado — com PHP 8.3, OPcache ativo e suporte a Redis — reduz significativamente o impacto de plugins pesados e facilita o diagnóstico de lentidão. Os planos de hospedagem da AviraHost incluem cPanel, WP-CLI disponível via SSH e suporte técnico especializado para WordPress.

Conheça os planos de hospedagem WordPress da AviraHost