Lentidão no WordPress: diagnóstico técnico rápido

19 min de leitura  ·  Guia técnico

Lentidão no WordPress pode ser resolvida com um diagnóstico técnico rápido do servidor, do PHP, do banco de dados e dos plugins. Para identificar o gargalo antes de perder visitas, meça o TTFB, analise consultas lentas e valide os recursos da hospedagem em poucos minutos.

1. Meça o TTFB com GTmetrix, PageSpeed Insights ou curl para criar uma linha de base.
2. Instale o Query Monitor e identifique plugins, hooks e consultas SQL lentas.
3. Verifique CPU, RAM, PHP-FPM e versão do PHP 8.x no servidor.
4. Ative o slow query log no MySQL para capturar consultas acima de 1 segundo.
5. Confira memória PHP, Object Cache e desative plugins suspeitos para isolar a causa.
6. Use CDN e monitoramento contínuo para evitar novas quedas de performance.

Pré-requisitos para diagnosticar lentidão no WordPress

• Acesso ao painel de hospedagem (cPanel, Plesk ou painel próprio) ou SSH ao servidor.
• WordPress instalado e funcional (qualquer versão recente, preferencialmente 6.x).
• PHP 8.1 ou superior configurado no ambiente de hospedagem.
• MySQL 8.0 ou MariaDB 10.6+ como banco de dados.
• Permissão para instalar plugins no painel do WordPress (perfil Administrador).
• Acesso ao arquivo php.ini ou wp-config.php para ajustes de configuração.
• Ferramentas externas: GTmetrix (gratuito), Google PageSpeed Insights (gratuito).

Diagnóstico técnico da lentidão no WordPress medindo o TTFB corretamente

O TTFB (Time to First Byte) é o indicador mais direto de lentidão no WordPress causada pelo servidor. Ele mede o tempo entre o envio da requisição HTTP pelo navegador e o recebimento do primeiro byte de resposta. Valores abaixo de 200ms são considerados saudáveis; entre 200ms e 500ms indicam necessidade de otimização; acima de 500ms representam um problema crítico que impacta diretamente o ranqueamento no Google e a experiência do usuário.

Para medir o TTFB sem instalar nada, use o curl diretamente no terminal do servidor ou da sua máquina local:

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

TTFB: 0.187s
Total: 0.412s

Se o TTFB retornado for superior a 0.5s, o gargalo está no servidor ou no PHP antes mesmo de qualquer plugin ser carregado. Nesse caso, verifique se o PHP-FPM está configurado com workers suficientes para a carga do site. No cPanel, acesse MultiPHP Manager para confirmar a versão do PHP 8.x ativa. Em servidores gerenciados via SSH, verifique o pool do PHP-FPM:

cat /etc/php/8.2/fpm/pool.d/www.conf | grep -E "pm\.|max_children"

pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Se pm.max_children estiver muito baixo para o volume de acessos simultâneos, o PHP-FPM enfileirará requisições e o TTFB disparará. Aumente o valor gradualmente e monitore o consumo de RAM após cada ajuste. Também vale validar se o OPcache está habilitado, pois ele reduz o tempo de compilação do PHP e melhora a resposta inicial do WordPress.

Para análise visual completa com waterfall de recursos, acesse o GTmetrix (gtmetrix.com) e insira a URL do seu site. O relatório exibirá TTFB, LCP (Largest Contentful Paint) e CLS (Cumulative Layout Shift), além de ajudar a validar Core Web Vitals durante o diagnóstico.

Usando o Query Monitor para identificar plugins e consultas lentas

O Query Monitor é o plugin gratuito mais eficaz para diagnosticar lentidão no WordPress causada por código interno — consultas SQL ineficientes, hooks lentos e chamadas de API desnecessárias. Ao ativá-lo, uma barra de administração aparece no topo do site exibindo o tempo total de carregamento da página, número de consultas ao banco de dados e memória consumida.

Para instalar via WP-CLI (recomendado em ambientes de hospedagem com acesso SSH):

wp plugin install query-monitor --activate --allow-root

Installing Query Monitor (3.15.0)
Downloading installation package from https://downloads.wordpress.org/plugin/query-monitor.3.15.0.zip...
Plugin installed successfully.
Activating 'query-monitor'...
Plugin 'query-monitor' activated.

Após a ativação, navegue pelas páginas do seu site logado como administrador. Clique em Query Monitor na barra superior e acesse a aba Queries. Ordene por tempo de execução (coluna "Time") para identificar as consultas mais lentas. Consultas acima de 0.05s merecem atenção; acima de 0.5s são críticas.

Na aba Hooks & Actions, você verá quais hooks do WordPress estão consumindo mais tempo de execução. Se um plugin específico aparecer repetidamente com tempos altos, ele é candidato à desativação ou substituição. Para confirmar, desative o plugin suspeito temporariamente e recarregue a página — se o tempo de carregamento cair significativamente, o problema está isolado.

A aba HTTP API Calls revela chamadas externas feitas durante o carregamento da página. Plugins que fazem requisições a APIs externas (redes de anúncios, serviços de analytics, verificadores de licença) podem adicionar centenas de milissegundos ao tempo de resposta se o servidor externo estiver lento ou indisponível.

Como ativar o slow query log no MySQL para detectar consultas lentas

O slow query log do MySQL registra automaticamente todas as consultas que ultrapassam um tempo definido, permitindo identificar gargalos no banco de dados do WordPress sem depender de plugins. Esta é a abordagem mais confiável para ambientes de produção com alto volume de acessos.

Atenção: Ativar o slow query log em servidores com alto volume de escrita pode gerar arquivos de log grandes rapidamente. Monitore o espaço em disco e desative o log após o diagnóstico.

Edite o arquivo de configuração do MySQL. No Debian 12 ou Ubuntu 24.04, o arquivo geralmente está em /etc/mysql/mysql.conf.d/mysqld.cnf:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Adicione ou descomente as seguintes linhas na seção [mysqld]:

[mysqld]
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 MySQL para aplicar as configurações:

sudo systemctl restart mysql

Após alguns minutos de tráfego real no site, analise o log com o utilitário mysqldumpslow:

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

Reading mysql slow query log from /var/log/mysql/mysql-slow.log
Count: 47  Time=2.31s (108s)  Lock=0.00s (0s)  Rows=1523.0 (71581), wordpress[wordpress]@localhost
  SELECT * FROM wp_posts WHERE post_status='publish' AND post_type='post' ORDER BY post_date DESC

O output mostra as 10 consultas mais lentas ordenadas por tempo total. A consulta SELECT * FROM wp_posts sem índice adequado é um problema clássico em instalações WordPress com muitos posts. Para verificar os índices existentes na tabela:

mysql -u root -p wordpress -e "SHOW INDEX FROM wp_posts;"

Se a coluna post_date não tiver índice e for usada em ORDER BY frequentemente, adicionar um índice composto pode reduzir drasticamente o tempo dessas consultas. Em sites com alto volume de leituras repetidas, também vale avaliar Object Cache com Redis Cache para reduzir a pressão sobre o MySQL. Consulte também o artigo Conectando remotamente ao MySQL - cPanel para gerenciar o banco de dados remotamente com ferramentas como DBeaver ou MySQL Workbench.

Verificando uso de memória PHP e limites de recursos no servidor

A falta de memória PHP é uma causa frequente de lentidão extrema no WordPress — e muitas vezes passa despercebida porque o site continua funcionando, apenas muito mais devagar, antes de apresentar tela branca ou erro 500. O WordPress define um limite padrão de 40MB para o front-end e 64MB para o painel administrativo, valores insuficientes para a maioria das instalações modernas com múltiplos plugins.

Para verificar o limite atual de memória PHP via terminal:

php -i | grep memory_limit

memory_limit => 128M => 128M

Se o valor for 128MB ou menos e o site usar plugins pesados (construtores de página, WooCommerce, plugins de SEO), aumente para 256MB ou 512MB. No wp-config.php, adicione antes da linha /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Se o seu plano de hospedagem não permitir alterar o php.ini diretamente, crie um arquivo .htaccess na raiz do WordPress com:

php_value memory_limit 256M

Para monitorar o consumo de memória em tempo real no servidor (disponível via SSH), use o comando free:

free -h

              total        used        free      shared  buff/cache   available
Mem:           3.8G        2.9G        124M        187M        812M        712M

Se a memória disponível (available) estiver consistentemente abaixo de 200MB, o servidor está sob pressão de memória. Isso causa swap excessivo, que degrada drasticamente a performance do MySQL e do PHP-FPM. Nesse cenário, considere migrar para um plano com mais RAM ou otimizar os processos em execução.

Para verificar quais processos consomem mais memória:

ps aux --sort=-%mem | head -15

Processos do Apache ou Nginx com muitos workers ativos, combinados com instâncias PHP-FPM, são os maiores consumidores em servidores WordPress. Ajuste o número de workers conforme a RAM disponível — uma regra prática é reservar ao menos 50MB por worker PHP-FPM.

Monitorando performance do WordPress com ferramentas externas e alertas

Detectar lentidão de forma reativa — quando um usuário reclama — é tarde demais. A abordagem profissional usa monitoramento contínuo com alertas automáticos para identificar degradação de performance antes que impacte os visitantes. Ferramentas de uptime monitoring verificam o tempo de resposta do site em intervalos regulares e enviam alertas por e-mail ou SMS quando o TTFB ultrapassa um limiar definido.

O UptimeRobot (plano gratuito disponível) monitora o site a cada 5 minutos e registra o histórico de tempo de resposta. Configure um monitor do tipo "HTTP(s)" apontando para a URL principal do WordPress e defina alertas para quando o tempo de resposta ultrapassar 2 segundos.

Para monitoramento mais granular diretamente no servidor, o wp-cron pode ser substituído por um cron real do sistema operacional, evitando que tarefas agendadas do WordPress sejam executadas durante picos de tráfego e causem lentidão momentânea. Desative o wp-cron interno adicionando ao wp-config.php:

define( 'DISABLE_WP_CRON', true );

Em seguida, crie um cron real no servidor (via crontab) para executar o wp-cron a cada 5 minutos:

crontab -e

*/5 * * * * wget -q -O - https://seusite.com.br/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Outra métrica importante é o LCP (Largest Contentful Paint), que mede o tempo até o maior elemento visível da página ser renderizado. Para WordPress, o LCP geralmente é a imagem do hero ou o título principal. Use o Google PageSpeed Insights para verificar o LCP atual e identificar se o problema está no servidor (TTFB alto) ou no carregamento de recursos estáticos (imagens não otimizadas, JavaScript bloqueante). Se o site atende visitantes de diferentes regiões, um CDN e suporte a HTTP/3 podem reduzir a latência percebida e melhorar a entrega de arquivos estáticos.

Para uma visão completa da infraestrutura de hospedagem e como ela afeta a performance do WordPress, consulte o artigo Comparativo: Hospedagem de sites vs. VPS: qual é a melhor opção? — especialmente se o seu site cresceu e os recursos do plano atual já não são suficientes.

Problemas comuns e como resolver

Sintoma: TTFB alto mesmo com cache ativo

Causa: O plugin de cache não está servindo páginas em cache para usuários não logados, ou o cache está sendo invalidado com frequência por plugins que fazem escritas constantes no banco de dados (formulários, contadores de visualizações, plugins de analytics do lado do servidor).
Solução: Verifique os logs do plugin de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache) para confirmar que as páginas estão sendo servidas do cache. Exclua da geração de cache dinâmico as páginas que mudam com frequência e configure o tempo de expiração do cache para pelo menos 1 hora nas páginas estáticas. Se usar Nginx, confirme que o fastcgi_cache está ativo com nginx -T | grep fastcgi_cache. Em ambientes mais exigentes, valide também se há Object Cache persistente com Redis habilitado.

Sintoma: Painel do WordPress lento, mas o front-end carrega normalmente

Causa: Plugins de administração pesados (construtores de página no modo de edição, plugins de backup em execução, plugins de segurança fazendo varreduras) consomem recursos apenas no contexto do painel (/wp-admin/), que geralmente não é coberto pelo cache.
Solução: Acesse o Query Monitor enquanto estiver no painel e verifique a aba Queries nas telas lentas. Identifique plugins que executam muitas consultas SQL no contexto administrativo. Agende backups e varreduras de segurança para horários de baixo tráfego usando o cron do sistema operacional em vez do wp-cron.

Sintoma: Lentidão intermitente em horários de pico

Causa: O servidor não tem workers PHP-FPM ou processos Apache suficientes para atender requisições simultâneas durante picos de tráfego. As requisições ficam enfileiradas, aumentando o TTFB de forma dramática apenas nos momentos de maior acesso.
Solução: Analise os logs de acesso do servidor para identificar os horários de pico: awk '{print $4}' /var/log/apache2/access.log | cut -d: -f2 | sort | uniq -c | sort -rn | head -5. Com base nos horários identificados, ajuste o pm.max_children do PHP-FPM ou o MaxRequestWorkers do Apache. Considere implementar um CDN para servir recursos estáticos e reduzir a carga no servidor de origem.

Sintoma: Erro 500 ou tela branca após atualização de plugin

Causa: O plugin atualizado tem conflito com a versão atual do PHP ou com outro plugin ativo, causando erro fatal que esgota a memória ou gera um loop de execução.
Solução: Ative o modo de depuração do WordPress temporariamente adicionando ao wp-config.php: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);. O log de erros será gravado em wp-content/debug.log. Identifique o plugin causador pelo stack trace e desative-o via FTP ou SSH renomeando a pasta em wp-content/plugins/. Consulte o artigo Como usar o Filezilla como software FTP da minha Hospedagem? para acessar os arquivos via FTP caso o painel do WordPress esteja inacessível.

Perguntas frequentes sobre lentidão no WordPress

Como saber se o WordPress está lento por causa do servidor ou de um plugin?

Use o plugin Query Monitor para identificar consultas SQL lentas e tempo de execução por plugin. Se o TTFB (Time to First Byte) for alto mesmo em páginas sem plugins ativos, o gargalo está no servidor — verifique uso de CPU, RAM e configuração do PHP-FPM. Se o tempo aumentar apenas com plugins específicos ativos, o problema está no código desses plugins.

Qual ferramenta gratuita mede a performance real do WordPress?

O Query Monitor (plugin gratuito) exibe tempo de carregamento, consultas ao banco de dados e hooks lentos diretamente no painel do WordPress. Para análise externa, o GTmetrix e o PageSpeed Insights do Google medem TTFB, LCP e CLS sem necessidade de acesso ao servidor. Combine as duas abordagens para um diagnóstico completo e confiável.

O que é TTFB e qual valor é aceitável para WordPress?

TTFB (Time to First Byte) é o tempo entre a requisição HTTP e o primeiro byte de resposta do servidor. Para WordPress, valores abaixo de 200ms são considerados bons; entre 200ms e 500ms indicam necessidade de otimização; acima de 500ms representam problema crítico que impacta diretamente o ranqueamento no Google e a taxa de rejeição do site.

Como identificar consultas MySQL lentas no WordPress?

Ative o slow query log no MySQL adicionando slow_query_log = 1 e long_query_time = 1 no arquivo my.cnf (ou mysqld.cnf no Debian/Ubuntu). O log registrará todas as consultas que levarem mais de 1 segundo. Complementarmente, o plugin Query Monitor exibe as consultas mais lentas por página diretamente no painel do WordPress, sem necessidade de acesso ao servidor.

Lentidão no WordPress pode ser causada por falta de memória PHP?

Sim. Quando o WordPress atinge o limite de memória PHP (padrão 128MB em muitos planos), ele pode apresentar lentidão extrema, tela branca ou erro 500 antes de travar completamente. Verifique o valor atual com php -i | grep memory_limit no terminal. Aumente para 256MB ou 512MB no php.ini ou no wp-config.php com define('WP_MEMORY_LIMIT', '256M').

Conclusão

Resolver lentidão no WordPress antes que ela afete os visitantes exige uma combinação de monitoramento externo, análise interna com Query Monitor e diagnóstico técnico no nível do servidor. Os pontos de ação mais importantes são:

• Meça o TTFB regularmente com curl ou GTmetrix e configure alertas automáticos via UptimeRobot para ser notificado quando o tempo de resposta ultrapassar 2 segundos.
• Ative o slow query log do MySQL periodicamente para capturar consultas ineficientes e use o Query Monitor para correlacionar os problemas com plugins específicos no painel do WordPress.
• Monitore memória PHP e workers do servidor — ajuste o WP_MEMORY_LIMIT no wp-config.php e o pm.max_children do PHP-FPM conforme o crescimento do tráfego, antes que os limites sejam atingidos em produção.

Leia também

• Como otimizar o WordPress para alta performance em VPS Linux: Guia Completo
• Solucionar problemas de lentidão em sites PHP no VPS Linux e servidor dedicado
• Passo a passo para corrigir tela branca no WordPress

Precisa de ajuda com performance do WordPress?

Um ambiente de hospedagem bem dimensionado é a base para um WordPress rápido — plugins otimizados e configurações corretas de PHP e MySQL fazem pouca diferença se o servidor não tiver recursos suficientes para a demanda do seu site. A AviraHost oferece planos de hospedagem com PHP 8.3, suporte a LiteSpeed e recursos escaláveis para WordPress.

Conheça os planos de hospedagem WordPress da AviraHost