WordPress lento em VPS (2026): PHP-FPM, OPcache, Redis, cache do Nginx e otimização de consultas lentas

Não comece instalando um plugin de cache. Primeiro identifique qual parte está lenta.

Existem quatro tipos comuns de lentidão:

1. Primeiro byte lento (TTFB alto): a página começa a responder devagar; geralmente é problema de PHP, banco de dados ou cache;
2. Painel administrativo lento: o wp-admin abre devagar; geralmente é por plugins, banco de dados, requisições externas ou processos PHP insuficientes;
3. Recursos de front-end lentos: o HTML é rápido, mas imagens, CSS e JS atrapalham;
4. Lentidão repentina em horário de pico: normal na maior parte do tempo, mas assim que chega tráfego, CPU, memória e MySQL disparam.

Primeiro meça o primeiro byte localmente:

curl -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' https://example.com/

Se time_starttransfer estiver alto, por exemplo 1 segundo, 2 segundos ou mais, foque em PHP, banco de dados e cache.

Depois verifique os recursos do servidor:

top
free -h
df -h
iostat -xz 1

Se a CPU ficar em 100% por muito tempo, consulte:

• CPU do VPS em 100%? Guia de diagnóstico e otimização de desempenho

Se a memória for esgotada com frequência, consulte:

• Como otimizar VPS com pouca memória usando ZRAM e Swap

Primeiro localize, depois otimize. Caso contrário, é fácil acabar com "cinco plugins de cache instalados e o site ainda mais lento".

O WordPress, essencialmente, executa PHP em grande parte das requisições. O Nginx é rápido, mas se o pool de processos do PHP-FPM não for suficiente, o site continua lento.

Primeiro localize o arquivo de configuração do PHP-FPM. Dependendo do sistema, pode ser:

/etc/php/8.2/fpm/pool.d/www.conf
/etc/php/8.3/fpm/pool.d/www.conf
/etc/php/8.4/fpm/pool.d/www.conf

Os parâmetros principais são:

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

pm.max_children não é melhor quanto maior. Cada processo filho do PHP-FPM consome memória. Primeiro veja quanto um único processo ocupa aproximadamente:

ps -ylC php-fpm8.2 --sort:rss

Ou:

ps aux | grep 'php-fpm' | grep -v grep

Estimativa aproximada:

可给 PHP 的内存 / 单个 PHP-FPM 进程平均内存 = max_children

Por exemplo, em um VPS de 2GB, depois de reservar uma parte para o sistema, Nginx, MySQL e Redis, talvez sobrem apenas 700MB para o PHP. Se um processo PHP consome em média 80MB, configurar pm.max_children em 8-10 é mais ou menos o adequado. Forçar para 50 só vai levar a máquina ao swap.

Depois de alterar, verifique e recarregue:

php-fpm8.2 -t
sudo systemctl reload php8.2-fpm

Se você já teve 502/504 antes, também pode ler:

• O que fazer quando aparece 502 / 504 Bad Gateway no VPS

O OPcache é um dos itens mais subestimados na otimização de desempenho do WordPress. Ele armazena em cache o bytecode compilado do PHP, evitando que os arquivos PHP sejam reprocessados a cada requisição.

Verifique se está ativado:

php -i | grep -i opcache.enable

Você também pode criar um arquivo PHP temporário para ver phpinfo(), mas apague-o imediatamente depois de ver; não o deixe exposto por muito tempo.

Arquivos de configuração comuns:

/etc/php/8.2/fpm/conf.d/10-opcache.ini

Um site WordPress pequeno pode começar assim:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1

Algumas observações:

• memory_consumption=128 é suficiente para a maioria dos sites pequenos e médios;
• com muitos plugins e um tema pesado, pode subir para 192 ou 256;
• max_accelerated_files não deve ser pequeno demais; o WordPress tem muitos arquivos de plugins;
• validate_timestamps=1 é mais seguro para sites comuns, pois não é fácil cachear código antigo após atualizar plugins.

Depois de alterar, reinicie o PHP-FPM:

sudo systemctl restart php8.2-fpm

Sem OPcache, muitos plugins de cache também não resolvem o painel lento.

O cache de páginas do WordPress deixa o front-end rápido, mas o painel, os usuários logados, os carrinhos de compra e as páginas dinâmicas continuam consultando o banco de dados com frequência. É aí que o Redis Object Cache faz diferença.

Cenários adequados para Redis:

• O painel está lento;
• Muitos plugins;
• WooCommerce;
• Muitos posts e categorias;
• Muitas consultas ao banco de dados;
• CPU ou I/O do MySQL frequentemente altos.

Instale o Redis:

sudo apt update
sudo apt install redis-server
sudo systemctl enable --now redis-server

Verifique:

redis-cli ping

Retorna:

PONG

No lado do WordPress, você pode instalar o plugin Redis Object Cache e depois adicionar em wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE_KEY_SALT', 'example.com:');

Se vários sites WordPress compartilharem um mesmo Redis, WP_CACHE_KEY_SALT deve ser diferente, caso contrário as chaves de cache podem se contaminar mutuamente.

Não exponha o Redis diretamente à internet pública. Um artigo anterior explicou por que serviços do tipo banco de dados não devem ser abertos à internet pública:

• Não exponha os bancos de dados do VPS diretamente à internet pública

Verifique a escuta do Redis:

ss -lntp | grep 6379

Ele deve escutar apenas em 127.0.0.1:6379 ou em um endereço interno; nunca deixe exposto na internet pública.

Se o seu site é principalmente um blog, site empresarial ou site de documentação, e o conteúdo das páginas é basicamente o mesmo para usuários não logados, então o Nginx FastCGI Cache é muito eficaz.

A função dele: armazenar em cache, na camada do Nginx, o HTML gerado pelo PHP. Na próxima vez que um usuário anônimo visitar a mesma página, o Nginx a retorna diretamente, sem passar por PHP e MySQL.

Ideia básica:

fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

No location do PHP:

fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;

Depois defina quais requisições não devem ser cacheadas:

set $skip_cache 0;

if ($request_method = POST) {
    set $skip_cache 1;
}

if ($query_string != "") {
    set $skip_cache 1;
}

if ($request_uri ~* "/wp-admin/|/wp-login.php|/cart|/checkout|/my-account") {
    set $skip_cache 1;
}

if ($http_cookie ~* "wordpress_logged_in_|comment_author|woocommerce_items_in_cart|wp_woocommerce_session") {
    set $skip_cache 1;
}

Atenção: WooCommerce, sites de membros, fóruns e sistemas de aprendizado não podem ser cacheados cegamente no site inteiro. Carrinho de compras, checkout e área do usuário devem ignorar o cache.

Teste se o cache está acertando:

curl -I https://example.com/

Veja os cabeçalhos de resposta:

X-FastCGI-Cache: HIT

Se estiver sempre MISS ou BYPASS, há problema nas regras de exclusão, nos cookies ou no caminho do cache.

O ecossistema de plugins do WordPress é poderoso, mas também pode bagunçar o desempenho.

Erros comuns:

• Instalar vários plugins de cache de páginas ao mesmo tempo;
• O cache do plugin e o Nginx FastCGI Cache cachearem a mesma camada ao mesmo tempo;
• Ativar o Redis Object Cache e também instalar outro plugin de cache de objetos;
• Um plugin de cache gerar automaticamente um .htaccess complexo, mas você usar Nginx;
• Um plugin de otimização de páginas combinar CSS/JS até quebrar.

Princípios recomendados:

• Cache de páginas: Nginx FastCGI Cache ou um plugin de cache maduro, escolha um;
• Cache de objetos: um Redis Object Cache já basta;
• Otimização de recursos estáticos: compressão de imagens, lazy loading, CSS crítico; não combine em excesso;
• CDN: o Cloudflare cuida dos recursos estáticos e do cache de borda; não deixe brigar com as regras da origem.

Se você já configurou o Cloudflare, também pode ler:

• Configuração de aceleração com Cloudflare CDN: melhore gratuitamente a velocidade de acesso global

Um WordPress lento muitas vezes não é PHP lento, mas um banco de dados arrastado pelos plugins.

Ative o log de consultas lentas do MySQL:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 'ON';

Veja o local do log de consultas lentas:

SHOW VARIABLES LIKE 'slow_query_log_file';

Você também pode persistir no arquivo de configuração:

[mysqld]
slow_query_log=1
long_query_time=1
log_queries_not_using_indexes=0

Não deixe log_queries_not_using_indexes=1 ativado por muito tempo; ele pode fazer os logs crescerem descontroladamente. Ative durante o diagnóstico e desative após localizar o problema.

Fontes comuns de consultas lentas no WordPress:

• Plugins que colocam grandes quantidades de dados autoload em wp_options;
• Construtores de páginas que geram consultas de meta demais;
• Dados históricos demais nas tabelas de pedidos do WooCommerce;
• Plugins de busca, estatísticas e posts relacionados fazendo varreduras de grande alcance;
• Consultas wp_postmeta sem índices adequados;
• Banco de dados e PHP disputando recursos no mesmo VPS de pouca memória.

Veja o tamanho do autoload:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';

Se os dados autoload forem de dezenas de MB, é normal que o painel fique lento.

Veja os maiores itens autoload:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Não apague só porque viu um campo grande. Primeiro confirme de qual plugin ele vem, faça backup e depois trate.

O maior risco ao ajustar o MySQL em um VPS pequeno é copiar configurações de servidores de 16GB/32GB.

Para um site WordPress em 1C2G ou 2C4G, foque em:

[mysqld]
innodb_buffer_pool_size=512M
innodb_log_file_size=128M
max_connections=50
table_open_cache=2000
tmp_table_size=64M
max_heap_table_size=64M

Isto é apenas um ponto de partida, não um modelo universal.

innodb_buffer_pool_size é o parâmetro central. Se for pequeno demais, o banco de dados lê do disco com frequência; se for grande demais, PHP e sistema ficam sem memória. Em um WordPress de máquina única, normalmente não deixe o MySQL consumir até o sistema ficar sem margem.

Se for 1C1G:

• Não seja ganancioso com o buffer pool do MySQL;
• O max_children do PHP-FPM deve ser conservador;
• O Redis pode ser adicionado, mas limite a memória;
• Adicione ZRAM/Swap se necessário;
• Contenha o número de plugins.

Se for 2C4G:

• Você pode começar o MySQL em torno de 1G;
• Os processos filhos do PHP-FPM podem ser mais folgados;
• Redis de 128-256MB é suficiente para muitos sites;
• Quando o FastCGI Cache acerta, a pressão cai visivelmente.

Um WordPress lento muitas vezes não é "o WordPress está lento", mas "algum plugin está lento".

Tipos de plugins de alto risco comuns:

• Construtores de páginas;
• Plugins de estatísticas e análise;
• Plugins de posts relacionados;
• Plugins de busca interna;
• Plugins de varredura de segurança;
• Plugins de backup;
• Plugins adicionais do WooCommerce;
• Plugins que fazem requisições a APIs externas.

Método de diagnóstico:

1. Faça backup primeiro;
2. Desative um a um os plugins suspeitos em horário de baixo movimento;
3. Observe TTFB, carregamento do painel e o log de consultas lentas;
4. Use o Query Monitor para ver consultas lentas e hooks;
5. Se puder resolver na camada do servidor, não dependa só de plugins.

Se a velocidade se recuperar claramente após desativar um plugin, o gargalo não está no VPS, mas na camada de aplicação.

Quando o WordPress tem muitas imagens, o disco local do VPS, a largura de banda e o PHP sofrem pressão.

Recomendações:

• Comprima as imagens antes de enviar;
• Use WebP/AVIF;
• Ative o lazy loading;
• Não gere tamanhos de miniatura demais;
• Sirva os recursos estáticos via CDN;
• Considere armazenamento de objetos para grandes quantidades de arquivos de mídia.

Quando considerar armazenamento de objetos, veja:

• O VPS precisa de armazenamento de objetos? Quais arquivos colocar em disco na nuvem e quais em armazenamento de objetos

Se for um blog pessoal, Cloudflare + disco local geralmente basta. Se for um site de imagens, de downloads ou de recursos, manter grandes quantidades de arquivos por muito tempo no disco do sistema do VPS vai dificultar expansão, backup e migração mais adiante.

Se o seu WordPress já está lento, faça nesta ordem:

1. Use curl para medir o TTFB e confirmar se o lento é o backend ou os recursos estáticos;
2. Use top/free/iostat para ver CPU, memória e I/O;
3. Verifique se o PHP-FPM pm.max_children está pequeno ou grande demais;
4. Confirme que o OPcache está ativado;
5. Instale o Redis Object Cache;
6. Adicione Nginx FastCGI Cache ou um plugin de cache maduro para as páginas anônimas;
7. Ative o log de consultas lentas do MySQL para encontrar problemas de plugins e consultas;
8. Limpe as opções autoload grandes demais;
9. Reduza plugins pesados, lentos e plugins de cache duplicados;
10. Compressão de imagens, CDN e armazenamento de objetos se necessário;
11. Se os recursos continuarem no máximo de forma sustentada, então faça upgrade do VPS.

A vantagem desta ordem: corrigir primeiro os problemas mais baratos, mais comuns e mais certos. Não faça upgrade da máquina logo de cara nem instale dez plugins logo de cara.

Se você ainda está escolhendo a máquina, consulte:

• Qual VPS escolher para montar um site? Recomendações de VPS para WordPress

Um WordPress lento em VPS normalmente não se resolve com um único interruptor, mas é o resultado combinado de PHP, cache, banco de dados, plugins e recursos estáticos.

O caminho mais eficaz é: primeiro use TTFB e as métricas do servidor para confirmar o gargalo, depois verifique PHP-FPM e OPcache, adicione o Redis Object Cache, configure o FastCGI Cache para as páginas anônimas e, por fim, use o log de consultas lentas e o diagnóstico de plugins para encontrar o que realmente deixa o site lento.

Depois de fazer tudo isso, se CPU, memória e I/O de disco continuarem no máximo de forma sustentada, então faça upgrade do VPS. Assim o dinheiro gasto resolve um gargalo real em vez de pagar por uma configuração errada.