Acelerar WordPress con object cache y nginx FastCGI cache

📅 Publicado el 26 de octubre, 2026 · Por Equipo RedServicio

Reducir los tiempos de carga de WordPress con object cache es una de esas estrategias que da más de sí de lo que parece: no hace falta cambiar de servidor ni pagar más cada mes. La idea es sencilla. Combinar dos capas de caché que se complementan —el object cache con Redis y el FastCGI cache de nginx— puede bajar las respuestas por debajo de los 100 milisegundos, incluso cuando el sitio recibe mucho tráfico.

¿Qué son el object cache y el FastCGI cache y por qué marcan la diferencia en WordPress?

WordPress, de fábrica, guarda casi todo lo que consulta (opciones, resultados de queries, objetos de usuarios) en la base de datos MySQL o MariaDB. Cada visita que pide información dinámica lanza consultas repetidas. Y esas consultas se cobran peaje: recursos de PHP, recursos de la base de datos. El object cache ataja el problema guardando esos objetos en memoria RAM mediante Redis o Memcached, así la segunda vez que se piden los mismos datos la respuesta llega en microsegundos, sin tocar la base de datos.

El FastCGI cache actúa una capa más arriba. nginx guarda la respuesta HTML completa que generó PHP-FPM y se la entrega directamente a las siguientes peticiones. Sin ejecutar PHP. Sin consultar la base de datos. Es decir:

• FastCGI cache: cachea la página HTML final. Pensado para visitantes anónimos.
• Object cache: cachea objetos y consultas internas. Aquí es donde brilla en usuarios autenticados, WooCommerce y esas zonas dinámicas que no pueden cachearse a nivel de página.

¿La combinación de ambas? Es lo que hace que un WordPress saturado pase de tardar 2-3 segundos a responder en décimas.

Cómo acelerar WordPress con object cache: instalación y configuración de Redis paso a paso

Para implementar object cache en WordPress, Redis es la opción más extendida. Estos son los pasos sobre un servidor Linux (Ubuntu/Debian):

1. Instala Redis: sudo apt install redis-server php-redis.
2. Comprueba que está activo con redis-cli ping; debe responder PONG.
3. Reinicia PHP-FPM: sudo systemctl restart php8.2-fpm (ajusta la versión a la tuya).
4. Instala el plugin Redis Object Cache desde el repositorio oficial de WordPress.
5. Activa la caché con el comando WP-CLI: wp redis enable.

¿Prefieres hacerlo a mano? Añade estas líneas en wp-config.php, justo antes del comentario /* That’s all, stop editing! */:

define(‘WP_REDIS_HOST’, ‘127.0.0.1’);
define(‘WP_REDIS_PORT’, ‘6379’);
define(‘WP_REDIS_MAXTTL’, 86400);

En un WordPress con WooCommerce, esta configuración puede recortar las consultas a la base de datos en un 80-90%, ya que carritos, sesiones y tarifas de envío se sirven desde memoria.

Configurar nginx FastCGI cache para WordPress: ejemplo de configuración completa

Para activar el FastCGI cache en nginx, lo primero es definir la zona de caché en el bloque http de tu configuración (por ejemplo en /etc/nginx/nginx.conf):

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

Luego, dentro del bloque location ~ \.php$ de tu virtual host, añade:

• fastcgi_cache WORDPRESS;
• fastcgi_cache_valid 200 301 302 60m;
• fastcgi_cache_use_stale error timeout updating;
• fastcgi_cache_bypass $skip_cache; y fastcgi_no_cache $skip_cache;

Falta definir la variable que evita cachear zonas sensibles:

set $skip_cache 0;
if ($request_uri ~* «/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap») { set $skip_cache 1; }
if ($http_cookie ~* «comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|woocommerce_cart») { set $skip_cache 1; }

Con esto, los visitantes anónimos reciben HTML pre-generado en milisegundos, mientras que los usuarios logueados y los procesos de administración siguen viendo contenido dinámico sin riesgo. Eso sí, si tu hosting actual no te deja ajustar nginx a este nivel, en RedServicio dispones de servidores optimizados con soporte 24/7 que pueden ayudarte a aplicar esta configuración de principio a fin.

Cómo comprobar que tu caché funciona: herramientas y pruebas de rendimiento

Configurar la caché sin verificarla es solo la mitad del trabajo. De nada sirve presumir de TTFB si luego no sabes si la caché está respondiendo. La forma más rápida de comprobar si nginx FastCGI cache está activo es inspeccionar las cabeceras HTTP de la respuesta. Abre las herramientas de desarrollador del navegador (pestaña Red) o lanza curl desde la terminal:

curl -I https://tudominio.com

Si todo está bien configurado, deberías ver cabeceras como X-Cache-Status: HIT o X-Fastcgi-Cache: HIT. Un MISS indica que la página no estaba cacheada en esa petición (normal la primera vez), mientras que un BYPASS confirma que las exclusiones para usuarios logueados están haciendo su trabajo. Si ves MISS repetido en la misma URL, algo no va bien. Ahí empezar a investigar.

Para el object cache, instala el plugin Query Monitor y revisa el panel de consultas a base de datos. Aparecerá una línea indicando cuántas consultas se sirven desde Redis o Memcached. Si el hit ratio supera el 90%, tu object cache está funcionando de forma óptima. También puedes verificarlo directamente desde la CLI:

redis-cli info stats | grep keyspace_hits

En cuanto al rendimiento medible, apóyate en estas herramientas:

• GTmetrix y PageSpeed Insights: miden el Time to First Byte (TTFB), el indicador más sensible a la caché de servidor. Un TTFB por debajo de 200 ms con caché activa es una buena referencia.
• Apache Benchmark: ejecuta ab -n 1000 -c 100 https://tudominio.com/ para simular 1000 peticiones con 100 concurrentes y compara resultados antes y después.
• WebPageTest: permite hacer pruebas desde distintas ubicaciones geográficas, útil para confirmar que la mejora es consistente y no solo un suicerto local.

Haz siempre una medición previa (baseline) y otra posterior. Sin ese antes, es imposible cuantificar la mejora real. En configuraciones bien ajustadas, es habitual bajar el TTFB entre un 50% y un 80%. No prometas esos números a ciegas, porque dependen del sitio, pero sí es el rango que se ve con frecuencia.

Errores comunes al acelerar WordPress con caché y cómo evitarlos

Muchos webmasters aplican estas configuraciones y se llevan sorpresas desagradables. Estos son los fallos más frecuentes y cómo prevenirlos:

1. Cachear páginas de usuario logueado o del carrito. Si no excluyes /wp-admin, /cart, /checkout y /mi-cuenta en WooCommerce, los usuarios verán datos de otros visitantes. Gravedad máxima. Revisa con lupa tu bloque de excepciones en nginx.
2. No purgar la caché al publicar contenido. Actualizas una entrada y los visitantes siguen viendo la versión antigua. Frustrante. Necesitas un mecanismo de invalidación: el plugin Nginx Helper de Routzee permite purgar automáticamente el FastCGI cache al guardar o al recibir un comentario.
3. Cachear cookies dinámicas. Si tu sitio usa cookies personalizadas (pop-ups, geolocalización), incluye esa cookie en fastcgi_cache_bypass para evitar servir contenido incorrecto.
4. Claves de caché sin hostname. En multisitios, omitir $scheme$host en fastcgi_cache_key hace que un sitio sirva el contenido de otro. La clave debe incluir siempre dominio, método de petición y URI. Parece obvio, pero se olvida más de lo que cabría imaginar.
5. Objetos en Redis que nunca expiran. Configura una caducidad razonable (por ejemplo, 3600 segundos con wp redis set-default-ttl) para evitar que datos obsoletos persistan indefinidamente.
6. Olvidar recargar nginx tras editar. Después de cualquier cambio, ejecuta nginx -t para validar la sintaxis y luego systemctl reload nginx. Un reload sin test previo puede dejar el servidor caído. Con tráfico en hora punta, es un susto que no deseas a nadie.

Conclusión: una web más rápida con object cache y FastCGI cache

Acelerar WordPress con object cache y FastCGI cache no son técnicas excluyentes, sino complementarias. La primera optimiza la capa interna de la aplicación reduciendo consultas a MySQL; la segunda evita ejecutar PHP por completo en las peticiones de usuarios anónimos. Juntas pueden transformar un sitio lento en otro que responde en milisegundos, con mejoras directas en SEO, conversión y experiencia de usuario.

Eso sí: el proceso exige acceso al servidor, criterio para definir exclusiones y pruebas rigurosas antes y después de cada cambio. El retorno de la inversión compensa, sobre todo en sitios con tráfico medio o alto. Ahora bien, si prefieres no complicarte con la administración del servidor, en RedServicio te lo ponemos fácil: nuestro hosting con nginx preconfigurado, soporte técnico 24/7 y optimizaciones listas para producción te permite disfrutar de estas velocidades sin tocar una sola línea de configuración. Empieza hoy a servir tu web a la velocidad que tus visitantes merecen.