Solucionar lentidão no WordPress: causas reais e correções

17 min de leitura  ·  Guia técnico

WordPress lento é um problema que afeta desde blogs pessoais até lojas WooCommerce de alto volume, e as causas reais raramente são óbvias à primeira vista. Identifique o gargalo principal, aplique as correções na ordem certa e o tempo de carregamento cai de forma consistente. Veja abaixo como diagnosticar e corrigir cada causa de raiz.

1. Meça o TTFB atual com curl -o /dev/null -s -w "%{time_starttransfer}\n" https://seusite.com.br
2. Verifique se OPcache está ativo no PHP com php -r "echo opcache_get_status()['opcache_enabled'];"
3. Analise consultas SQL lentas com o plugin Query Monitor
4. Ative ou configure um plugin de cache de página (LiteSpeed Cache, W3 Total Cache)
5. Otimize imagens e ative carregamento lazy nativo
6. Revise o plano de hospedagem: recursos insuficientes são a causa raiz mais comum

Pré-requisitos para solucionar lentidão no WordPress

• Acesso ao painel de hospedagem (cPanel, Plesk ou SSH)
• WordPress 6.x instalado e atualizado
• PHP 8.1 ou superior (recomendado PHP 8.3)
• Permissão para instalar plugins no painel WordPress
• Acesso ao banco de dados MySQL 8.0 ou MariaDB 10.6+
• Ferramenta de medição de performance: GTmetrix, PageSpeed Insights ou curl

Solucionar lentidão no WordPress: diagnóstico inicial com métricas reais

Antes de qualquer ajuste, você precisa de números concretos. O TTFB (Time to First Byte) é o indicador mais direto de lentidão no servidor — valores acima de 600 ms indicam problema no backend, não no frontend. Rode o comando abaixo para medir sem cache de CDN:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConexão: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://seusite.com.br

DNS: 0.012s
Conexão: 0.045s
TTFB: 0.820s
Total: 1.340s

Um TTFB de 0,82 s indica que o PHP ou o banco de dados está demorando para gerar a resposta. Instale o plugin Query Monitor para ver exatamente quais consultas SQL e hooks PHP estão consumindo mais tempo. Após instalar, acesse qualquer página do site logado como administrador e clique na barra de administração em "Query Monitor" para ver o painel detalhado.

Registre também o número de consultas ao banco de dados por página. Páginas comuns de WordPress devem ter menos de 50 queries; lojas WooCommerce com muitos produtos podem chegar a 150 queries sem cache — esse é o sinal para ativar object cache com Redis.

Para artigos relacionados à otimização geral do servidor que hospeda o WordPress, consulte Dicas de Otimização de Servidores Linux.

OPcache e PHP 8.3: o ganho de performance mais rápido de implementar

O OPcache é a otimização de PHP com maior impacto imediato no WordPress porque elimina a recompilação dos arquivos PHP a cada requisição. Em instalações com mais de 500 arquivos PHP (o WordPress core já tem mais de 2.000), o ganho de TTFB é consistente.

Verifique se o OPcache está ativo:

php -r "var_dump(opcache_get_status()['opcache_enabled']);"

bool(true)

Se retornar bool(false) ou erro, o OPcache está desativado. No cPanel, acesse MultiPHP INI Editor, selecione o domínio e ative opcache.enable = 1. Em servidores com acesso SSH, edite o arquivo de configuração do PHP:

sudo nano /etc/php/8.3/fpm/conf.d/10-opcache.ini

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.save_comments=1
opcache.fast_shutdown=1

Após salvar, reinicie o PHP-FPM:

sudo systemctl restart php8.3-fpm

O parâmetro opcache.max_accelerated_files=10000 é importante para WordPress com muitos plugins — o valor padrão de 2.000 pode ser insuficiente e causar cache miss constante, anulando o benefício do OPcache.

Cache de página: como configurar W3 Total Cache com Redis no Nginx

O cache de página é a segunda camada mais importante para acelerar o WordPress. Sem ele, cada visita executa todo o ciclo PHP + MySQL mesmo para conteúdo estático. Em servidores Nginx, a combinação W3 Total Cache com Redis como object cache é sólida e amplamente testada.

Primeiro, instale e inicie o Redis no servidor (Ubuntu 24.04 ou Debian 12):

sudo apt update && sudo apt install redis-server -y
sudo systemctl enable --now redis-server
redis-cli ping

PONG

No WordPress, instale o plugin W3 Total Cache pelo painel. Acesse Performance > General Settings e configure:

• Page Cache: ativar, método Disk: Enhanced
• Object Cache: ativar, método Redis
• Database Cache: ativar, método Redis
• Browser Cache: ativar

Em Performance > Object Cache, configure o host Redis como 127.0.0.1 e porta 6379. Salve e teste a conexão. Após ativar, rode novamente o curl de TTFB — em instalações típicas, o valor cai para abaixo de 200 ms em requisições cacheadas.

Se o seu ambiente usa LiteSpeed (comum em hospedagens compartilhadas), o LiteSpeed Cache oferece integração nativa e é mais simples de configurar. Ele detecta automaticamente o servidor e ativa as otimizações corretas sem configuração manual de regras Nginx.

Banco de dados MySQL: otimizar tabelas e identificar queries lentas

O banco de dados é frequentemente o gargalo silencioso do WordPress. Tabelas fragmentadas, a tabela wp_options com autoload excessivo e ausência de índices são as causas mais comuns de lentidão relacionada ao MySQL.

Verifique o tamanho e o autoload da tabela wp_options via WP-CLI:

wp option list --autoload=yes --fields=option_name,option_value --format=table | head -50

Para ver o total de dados em autoload:

wp db query "SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';"

+-----------------+
| autoload_size   |
+-----------------+
| 2847392         |
+-----------------+

Valores acima de 800 KB de autoload causam lentidão perceptível em cada requisição PHP. Identifique e remova opções desnecessárias de plugins desinstalados:

wp db query "SELECT option_name, LENGTH(option_value) as size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Atenção: antes de deletar qualquer linha da tabela wp_options, faça um backup completo do banco de dados. Remover opções de plugins ativos pode quebrar funcionalidades.

Para otimizar todas as tabelas do banco de dados WordPress de uma vez:

wp db optimize

Success: Database optimized.

Ative o log de queries lentas no MySQL para identificar consultas problemáticas. Edite /etc/mysql/mysql.conf.d/mysqld.cnf:

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

Reinicie o MySQL e monitore o arquivo de log após alguns minutos de tráfego real:

sudo systemctl restart mysql
sudo tail -f /var/log/mysql/slow.log

Plugins e temas: como identificar o responsável pela lentidão

Plugins mal codificados são uma causa frequente de lentidão no WordPress, mas o número de plugins instalados importa menos do que a qualidade de cada um. Um único plugin com consulta SQL sem índice pode ser mais prejudicial do que 30 plugins bem escritos.

O método mais confiável para isolar o plugin problemático é usar o WP-CLI para desativar todos e reativar um a um, medindo o TTFB a cada etapa:

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

TTFB: 0.180s

Se o TTFB cair drasticamente com todos os plugins desativados, o problema está em um plugin específico. Reative-os em grupos de 5 e meça novamente até identificar o culpado. Com o Query Monitor ativo, você verá na aba Queries quais plugins estão executando mais consultas ao banco de dados.

Temas com page builders pesados (Elementor, Divi, WPBakery) também contribuem para lentidão. Verifique o número de requisições HTTP e o tamanho total da página no GTmetrix. Páginas acima de 3 MB ou com mais de 80 requisições HTTP precisam de otimização de assets — minificação de CSS/JS e carregamento assíncrono.

Imagens e assets: otimização que reduz o tempo de carregamento total

Imagens não otimizadas são a causa mais comum de páginas lentas no frontend do WordPress. O formato WebP reduz o tamanho dos arquivos em relação ao JPEG sem perda visual perceptível, e o atributo loading="lazy" nativo do HTML5 está disponível desde o WordPress 5.5.

Para converter imagens existentes para WebP em lote, use o plugin Imagify ou ShortPixel. Ambos processam o acervo existente e servem WebP automaticamente para navegadores compatíveis. Alternativamente, em servidores com acesso SSH, use o cwebp:

sudo apt install webp -y
find /var/www/html/wp-content/uploads -name "*.jpg" -exec cwebp -q 82 {} -o {}.webp \;

Para o Nginx servir WebP automaticamente quando o navegador suportar, adicione ao bloco server:

location ~* \.(jpg|jpeg|png)$ {
    add_header Vary Accept;
    try_files $uri.webp $uri =404;
}

Além das imagens, ative a compressão Gzip ou Brotli no servidor para reduzir o tamanho dos arquivos CSS, JS e HTML transferidos. No Nginx, adicione ao bloco http:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length 1024;
gzip_comp_level 5;

Se o seu site ainda usa HTTP, a migração para HTTPS com HTTP/2 também melhora a performance por permitir multiplexação de requisições. Veja como fazer isso em Como redirecionar um site http para https?.

Recursos do servidor: quando o problema não é o WordPress

Às vezes, todas as otimizações de software estão corretas, mas o servidor simplesmente não tem recursos suficientes para a carga do site. Em hospedagem compartilhada, o limite de memória PHP costuma ser 128 MB — insuficiente para WordPress com WooCommerce e múltiplos plugins ativos.

Verifique o limite de memória atual:

wp eval "echo WP_MEMORY_LIMIT;"

128M

Para aumentar o limite de memória, adicione ao wp-config.php:

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

Se o servidor não permitir aumentar o limite (comum em hospedagem compartilhada com restrições rígidas), considere migrar para um plano VPS onde você tem controle total sobre os recursos. Veja a comparação entre os tipos de hospedagem em Comparativo: Hospedagem de sites vs. VPS: qual é a melhor opção?.

Monitore o uso de CPU e memória em tempo real com:

top -b -n 1 | head -20

Se o processo php-fpm ou mysqld estiver constantemente acima de 80% de CPU, o problema é de capacidade, não de configuração. Nesse caso, escalar os recursos do servidor é a solução correta.

Problemas comuns e como resolver

Sintoma: TTFB alto mesmo com cache ativo

Causa: O cache pode não estar sendo servido para usuários logados, para páginas com parâmetros de URL dinâmicos (como ?utm_source=) ou para o carrinho do WooCommerce. Plugins de cache excluem essas URLs por padrão.
Solução: No W3 Total Cache, acesse Page Cache > Advanced e verifique as regras de exclusão. Para WooCommerce, certifique-se de que as páginas de carrinho, checkout e minha conta estão na lista de exclusão do cache (comportamento correto). Para URLs com parâmetros de rastreamento, ative a opção de ignorar parâmetros de query string irrelevantes.

Sintoma: Site lento apenas para usuários logados

Causa: Cache de página não é servido para usuários autenticados, então cada requisição executa o ciclo PHP completo. Se o object cache não estiver ativo, cada página carrega todas as queries do banco de dados sem reutilização.
Solução: Ative o Redis como object cache conforme descrito na seção anterior. O object cache beneficia tanto usuários anônimos quanto logados porque armazena resultados de queries em memória RAM, independentemente do cache de página.

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

Causa: O servidor está atingindo o limite de workers do PHP-FPM ou de conexões simultâneas ao MySQL. Em hospedagem compartilhada, isso é agravado por outros sites no mesmo servidor consumindo recursos.
Solução: Em servidores VPS com PHP-FPM, ajuste o pool em /etc/php/8.3/fpm/pool.d/www.conf: aumente pm.max_children proporcionalmente à RAM disponível (regra geral: 1 worker por 30-50 MB de RAM). Para MySQL, verifique max_connections com SHOW VARIABLES LIKE 'max_connections'; e ajuste conforme necessário.

Sintoma: Imagens carregando lentamente mesmo após otimização

Causa: As imagens estão sendo servidas pelo PHP em vez de diretamente pelo servidor web, ou o servidor não tem CDN configurado para distribuição geográfica.
Solução: Verifique se as imagens estão sendo servidas com o header correto usando curl -I https://seusite.com.br/wp-content/uploads/imagem.jpg. O header Server deve indicar Nginx ou Apache, não PHP. Para sites com audiência nacional, configure a Cloudflare como CDN gratuita — ela serve assets estáticos de pontos de presença no Brasil, reduzindo a latência.

Sintoma: WordPress lento após atualização de plugin ou tema

Causa: A atualização pode ter introduzido código ineficiente, conflito com outro plugin ou alterado configurações de cache.
Solução: Limpe todos os caches após qualquer atualização (W3 Total Cache: Performance > Purge All Caches). Use o Query Monitor para comparar o número de queries antes e depois da atualização. Se o problema persistir, desative o plugin/tema atualizado e verifique se há uma versão anterior disponível no repositório WordPress.

Perguntas frequentes sobre lentidão no WordPress

Por que o WordPress fica lento mesmo com poucos plugins?

A lentidão pode ocorrer mesmo com poucos plugins se o servidor tiver recursos insuficientes, PHP sem OPcache ativo, banco de dados com tabelas fragmentadas ou ausência de cache de página. O número de plugins importa menos do que a qualidade e configuração de cada um. Um plugin com consulta SQL sem índice ou que carrega scripts desnecessários em todas as páginas pode ser mais prejudicial do que dez plugins bem otimizados.

Qual plugin de cache é mais eficiente para WordPress em 2026?

W3 Total Cache, WP Super Cache e LiteSpeed Cache são os mais usados. O LiteSpeed Cache oferece integração nativa com servidores LiteSpeed e Redis, sendo o mais completo para ambientes VPS. Em servidores Nginx, o W3 Total Cache com Redis como object cache é uma combinação sólida. A escolha ideal depende do servidor web utilizado — verifique qual está rodando antes de instalar.

Como saber qual plugin está causando lentidão no WordPress?

Use o plugin Query Monitor para identificar consultas SQL lentas e hooks demorados. Desative plugins em lotes pelo painel ou via WP-CLI com wp plugin deactivate --all e reative um a um, medindo o TTFB a cada etapa com ferramentas como curl ou GTmetrix. Esse método isola o responsável com precisão, sem depender de suposições.

OPcache realmente melhora a velocidade do WordPress?

Sim. O OPcache armazena o bytecode compilado do PHP em memória, eliminando a necessidade de recompilar os arquivos PHP a cada requisição. Em instalações WordPress com muitos arquivos, o ganho de TTFB pode ser significativo. Verifique se está ativo com php -r "echo opcache_get_status()['opcache_enabled'];" — o retorno deve ser 1.

Vale a pena usar Redis como object cache no WordPress?

Sim, especialmente em sites com alto volume de consultas repetidas ao banco de dados, como lojas WooCommerce ou portais com login de usuários. O Redis armazena resultados de queries em memória RAM, reduzindo a carga no MySQL. É necessário instalar o daemon Redis no servidor e o plugin Redis Object Cache no WordPress. Em hospedagem compartilhada sem acesso SSH, verifique com o suporte se o Redis está disponível no plano.

Conclusão

• Meça antes de otimizar: use curl para medir TTFB e Query Monitor para identificar queries lentas — sem dados, qualquer ajuste é tentativa e erro.
• Priorize OPcache e cache de página: são as duas otimizações com maior impacto imediato e menor risco de quebrar funcionalidades existentes.
• Escale recursos quando necessário: se o servidor está consistentemente acima de 80% de CPU ou memória, otimizações de software têm retorno limitado — migrar para um plano com mais recursos é a solução definitiva.

Leia também

• Otimizar cache Redis para aplicações PHP no Ubuntu 22.04
• Solucionar lentidão no MySQL 8.0 antes que derrube sua aplicação
• Otimizar MySQL: como reduzir uso de memória e acelerar consultas

Precisa de ajuda com performance do WordPress?

Um ambiente de hospedagem bem dimensionado é a base para qualquer otimização de WordPress funcionar. Planos com PHP 8.3, OPcache configurado e suporte a Redis fazem diferença real no tempo de carregamento do seu site.

Conheça os planos de hospedagem WordPress da AviraHost