WordPress lento en un VPS (2026): PHP-FPM, OPcache, Redis, caché de Nginx y optimización de consultas lentas

No empieces instalando un plugin de caché. Primero distingue qué parte va lenta.

Hay cuatro formas comunes de lentitud:

1. Primer byte lento (TTFB alto): la página empieza a responder despacio; suele ser un problema de PHP, base de datos o caché;
2. Panel de administración lento: wp-admin abre despacio; suele ser por plugins, base de datos, peticiones externas o procesos PHP insuficientes;
3. Recursos de front-end lentos: el HTML es rápido, pero las imágenes, CSS y JS lo frenan;
4. Lentitud repentina en horas punta: normal la mayor parte del tiempo, pero en cuanto llega tráfico se disparan CPU, memoria y MySQL.

Primero mide el primer byte en local:

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/

Si time_starttransfer es alto, por ejemplo 1 segundo, 2 segundos o más, céntrate en PHP, la base de datos y la caché.

Luego revisa los recursos del servidor:

top
free -h
df -h
iostat -xz 1

Si la CPU está al 100% durante mucho tiempo, consulta:

• ¿CPU del VPS al 100%? Guía de diagnóstico y optimización de rendimiento

Si la memoria se agota con frecuencia, consulta:

• Cómo optimizar un VPS con poca memoria usando ZRAM y Swap

Primero localiza, luego optimiza. De lo contrario es fácil acabar con "cinco plugins de caché instalados y el sitio aún más lento".

WordPress, en esencia, ejecuta PHP para una gran parte de las peticiones. Nginx es rápido, pero si el pool de procesos PHP-FPM no es suficiente, el sitio seguirá yendo lento.

Primero localiza el archivo de configuración de PHP-FPM. Según el sistema puede estar en:

/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

Los parámetros clave son:

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 no es mejor cuanto más grande. Cada proceso hijo de PHP-FPM consume memoria. Primero mira cuánto ocupa aproximadamente un solo proceso:

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

O:

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

Estimación aproximada:

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

Por ejemplo, en un VPS de 2GB, tras reservar una parte para el sistema, Nginx, MySQL y Redis, puede que solo queden 700MB para PHP. Si un proceso PHP consume de media 80MB, configurar pm.max_children en 8-10 es más o menos lo adecuado. Si lo fuerzas a 50, solo llevarás la máquina al swap.

Tras cambiarlo, comprueba y recarga:

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

Si antes has tenido 502/504, también puedes leer:

• ¿Qué hacer ante 502 / 504 Bad Gateway en un VPS?

OPcache es uno de los elementos más infravalorados en la optimización del rendimiento de WordPress. Almacena en caché el bytecode compilado de PHP para evitar volver a analizar los archivos PHP en cada petición.

Comprueba si está activado:

php -i | grep -i opcache.enable

También puedes crear un archivo PHP temporal para ver phpinfo(), pero bórralo inmediatamente después de verlo; no lo dejes expuesto a largo plazo.

Archivos de configuración habituales:

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

Un sitio WordPress pequeño puede empezar así:

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

Algunas aclaraciones:

• memory_consumption=128 es suficiente para la mayoría de sitios pequeños y medianos;
• con muchos plugins y un tema pesado se puede subir a 192 o 256;
• max_accelerated_files no debe ser demasiado pequeño; WordPress tiene muchos archivos de plugins;
• validate_timestamps=1 es más seguro para sitios normales, ya que no se cachea fácilmente código antiguo tras actualizar plugins.

Tras cambiarlo, reinicia PHP-FPM:

sudo systemctl restart php8.2-fpm

Sin OPcache, muchos plugins de caché tampoco pueden arreglar un panel lento.

La caché de páginas de WordPress hace que el front-end vaya rápido, pero el panel, los usuarios conectados, los carritos de compra y las páginas dinámicas siguen consultando la base de datos con frecuencia. Ahí es donde Redis Object Cache aporta valor.

Escenarios adecuados para Redis:

• El panel va lento;
• Muchos plugins;
• WooCommerce;
• Muchos artículos y categorías;
• Muchas consultas a la base de datos;
• La CPU o el I/O de MySQL suelen estar altos.

Instala Redis:

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

Comprueba:

redis-cli ping

Devuelve:

PONG

En el lado de WordPress puedes instalar el plugin Redis Object Cache y luego añadir en wp-config.php:

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

Si varios sitios WordPress comparten un mismo Redis, WP_CACHE_KEY_SALT debe ser distinto, de lo contrario las claves de caché pueden contaminarse entre sí.

No expongas Redis directamente a Internet. En un artículo anterior explicamos por qué los servicios de tipo base de datos no deben abrirse a Internet:

• No expongas las bases de datos del VPS directamente a Internet

Comprueba la escucha de Redis:

ss -lntp | grep 6379

Debería escuchar solo en 127.0.0.1:6379 o en una dirección interna; nunca dejarlo desnudo en Internet.

Si tu sitio es principalmente un blog, un sitio corporativo o un sitio de documentación, y el contenido de las páginas es básicamente el mismo para usuarios no conectados, entonces Nginx FastCGI Cache es muy eficaz.

Su función: cachear en la capa de Nginx el HTML generado por PHP. La próxima vez que un usuario anónimo visite la misma página, Nginx la devuelve directamente sin pasar por PHP ni MySQL.

Idea 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";

En el location de 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;

Luego define qué peticiones no deben cachearse:

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;
}

Nota: WooCommerce, sitios de membresía, foros y sistemas de aprendizaje no pueden cachearse a ciegas en todo el sitio. El carrito, el checkout y el área de usuario deben saltarse la caché.

Prueba si la caché acierta:

curl -I https://example.com/

Mira las cabeceras de respuesta:

X-FastCGI-Cache: HIT

Si siempre es MISS o BYPASS, hay un problema con las reglas de exclusión, las cookies o la ruta de caché.

El ecosistema de plugins de WordPress es potente, pero también puede desordenar el rendimiento.

Errores comunes:

• Instalar varios plugins de caché de páginas a la vez;
• Que la caché del plugin y Nginx FastCGI Cache cacheen la misma capa a la vez;
• Activar Redis Object Cache e instalar además otro plugin de caché de objetos;
• Que un plugin de caché genere automáticamente un .htaccess complejo, pero tú uses Nginx;
• Que un plugin de optimización de páginas combine CSS/JS hasta romperlo.

Principios recomendados:

• Caché de páginas: Nginx FastCGI Cache o un plugin de caché maduro, elige uno;
• Caché de objetos: con un Redis Object Cache basta;
• Optimización de recursos estáticos: compresión de imágenes, carga diferida, CSS crítico; no combines en exceso;
• CDN: Cloudflare se encarga de los recursos estáticos y la caché de borde; no dejes que choque con las reglas del origen.

Si ya has configurado Cloudflare, también puedes leer:

• Configuración de aceleración con Cloudflare CDN: mejora gratis la velocidad de acceso global

Un WordPress lento muchas veces no es PHP lento, sino una base de datos ralentizada por los plugins.

Activa el registro de consultas lentas de MySQL:

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

Consulta la ubicación del registro de consultas lentas:

SHOW VARIABLES LIKE 'slow_query_log_file';

También puedes persistirlo en el archivo de configuración:

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

No dejes log_queries_not_using_indexes=1 activado a largo plazo; puede hacer que los registros crezcan desmesuradamente. Actívalo durante el diagnóstico y desactívalo tras localizar el problema.

Fuentes comunes de consultas lentas en WordPress:

• Plugins que meten grandes cantidades de datos autoload en wp_options;
• Constructores de páginas que generan demasiadas consultas de meta;
• Demasiados datos históricos en las tablas de pedidos de WooCommerce;
• Plugins de búsqueda, estadísticas y artículos relacionados que hacen escaneos de gran alcance;
• Consultas wp_postmeta sin índices adecuados;
• Base de datos y PHP compitiendo por recursos en el mismo VPS de poca memoria.

Consulta el tamaño de autoload:

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

Si los datos autoload son de decenas de MB, es normal que el panel vaya lento.

Consulta los mayores elementos autoload:

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

No borres solo porque veas un campo grande. Primero confirma de qué plugin viene, haz copia de seguridad y luego procésalo.

El mayor riesgo al ajustar MySQL en un VPS pequeño es copiar configuraciones de servidores de 16GB/32GB.

Para un sitio WordPress en 1C2G o 2C4G, céntrate en:

[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

Esto es solo un punto de partida, no una plantilla universal.

innodb_buffer_pool_size es el parámetro central. Si es demasiado pequeño, la base de datos lee del disco con frecuencia; si es demasiado grande, PHP y el sistema se quedan sin memoria. En un WordPress de una sola máquina, normalmente no dejes que MySQL consuma hasta que el sistema se quede sin margen.

Si es 1C1G:

• No seas codicioso con el buffer pool de MySQL;
• PHP-FPM max_children debe ser conservador;
• Redis se puede añadir, pero limita su memoria;
• Añade ZRAM/Swap si es necesario;
• Contén el número de plugins.

Si es 2C4G:

• Puedes empezar con MySQL en torno a 1G;
• Los procesos hijos de PHP-FPM pueden ser más holgados;
• Redis de 128-256MB es suficiente para muchos sitios;
• Cuando FastCGI Cache acierta, la presión baja notablemente.

Un WordPress lento muchas veces no es "WordPress va lento", sino "algún plugin va lento".

Tipos de plugins de alto riesgo habituales:

• Constructores de páginas;
• Plugins de estadísticas y analítica;
• Plugins de artículos relacionados;
• Plugins de búsqueda interna;
• Plugins de escaneo de seguridad;
• Plugins de copia de seguridad;
• Plugins adicionales de WooCommerce;
• Plugins que hacen peticiones a APIs externas.

Método de diagnóstico:

1. Haz copia de seguridad primero;
2. Desactiva uno a uno los plugins sospechosos en horas de baja actividad;
3. Observa TTFB, la carga del panel y el registro de consultas lentas;
4. Usa Query Monitor para ver consultas lentas y hooks;
5. Si se puede resolver en la capa del servidor, no dependas solo de plugins.

Si tras desactivar un plugin la velocidad se recupera claramente, el cuello de botella no está en el VPS sino en la capa de aplicación.

Cuando WordPress tiene muchas imágenes, el disco local del VPS, el ancho de banda y PHP sufren presión.

Recomendaciones:

• Comprime las imágenes antes de subirlas;
• Usa WebP/AVIF;
• Activa lazy loading;
• No generes demasiados tamaños de miniatura;
• Sirve los recursos estáticos por CDN;
• Considera el almacenamiento de objetos para grandes cantidades de archivos multimedia.

Cuándo considerar el almacenamiento de objetos, consulta:

• ¿Necesita un VPS almacenamiento de objetos? Qué archivos poner en disco en la nube y cuáles en almacenamiento de objetos

Si es un blog personal, Cloudflare + disco local suele ser suficiente. Si es un sitio de imágenes, de descargas o de recursos, mantener grandes cantidades de archivos a largo plazo en el disco del sistema del VPS hará que ampliar, hacer copias de seguridad y migrar sea problemático más adelante.

Si tu WordPress ya va lento, hazlo en este orden:

1. Usa curl para medir el TTFB y confirmar si va lento el backend o los recursos estáticos;
2. Usa top/free/iostat para ver CPU, memoria e I/O;
3. Comprueba si PHP-FPM pm.max_children es demasiado pequeño o demasiado grande;
4. Confirma que OPcache está activado;
5. Instala Redis Object Cache;
6. Añade Nginx FastCGI Cache o un plugin de caché maduro para las páginas anónimas;
7. Activa el registro de consultas lentas de MySQL para encontrar problemas de plugins y consultas;
8. Limpia las opciones autoload demasiado grandes;
9. Reduce plugins pesados, lentos y plugins de caché duplicados;
10. Compresión de imágenes, CDN y almacenamiento de objetos si es necesario;
11. Si los recursos siguen al máximo de forma sostenida, entonces amplía el VPS.

La ventaja de este orden: arreglar primero los problemas más baratos, más comunes y más seguros. No amplíes la máquina de entrada ni instales diez plugins de entrada.

Si todavía estás eligiendo máquina, consulta:

• ¿Qué VPS elegir para montar un sitio? Recomendaciones de VPS para WordPress

Que WordPress vaya lento en un VPS normalmente no se resuelve con un solo interruptor, sino que es el resultado combinado de PHP, caché, base de datos, plugins y recursos estáticos.

La ruta más eficaz es: primero usa TTFB y las métricas del servidor para confirmar el cuello de botella, luego revisa PHP-FPM y OPcache, añade Redis Object Cache, configura FastCGI Cache para las páginas anónimas y, por último, usa el registro de consultas lentas y el diagnóstico de plugins para encontrar lo que realmente ralentiza el sitio.

Cuando hayas hecho todo esto, si la CPU, la memoria y el I/O de disco siguen al máximo de forma sostenida, entonces amplía el VPS. Así el dinero gastado resuelve un cuello de botella real en lugar de pagar por una mala configuración.