🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Estrategias de Caché Distribuida con Redis y Varnish para WordPress

Actualizado el 24 de diciembre de 2025

Introducción: El Desafío de la Escalabilidad en WordPress

WordPress es el CMS más popular del mundo, pero su arquitectura monolítica y su naturaleza dinámica (generación de páginas con PHP y consultas a MySQL) lo convierten en un devorador de recursos cuando el tráfico crece. Cada visita a una página sin caché implica una cadena de procesos: ejecución de PHP, consultas a la base de datos, renderizado del tema y ejecución de plugins. Para un sitio con miles de visitas concurrentes, esto es insostenible.

Aquí es donde entra la caché distribuida. No basta con un solo servidor de caché; necesitas una arquitectura que reparta la carga, tolere fallos y ofrezca latencias mínimas. Combinar Redis y Varnish es la estrategia más potente para lograr una caché distribuida WordPress de alto rendimiento. Redis actúa como almacén de objetos y sesiones, mientras que Varnish se sitúa como proxy inverso para cachear páginas completas. Juntos, permiten escalar horizontalmente sin perder funcionalidad dinámica.

En este artículo, desglosaremos cómo implementar esta arquitectura, desde los fundamentos hasta la configuración práctica, asegurando que tu WordPress no solo aguante picos de tráfico, sino que ofrezca una experiencia ultrarrápida.

¿Por qué necesitas una estrategia de caché distribuida?

La caché tradicional (por ejemplo, un único servidor Redis o Varnish en un solo nodo) tiene un punto débil: el cuello de botella y el riesgo de fallo único. En un entorno de alta disponibilidad o con múltiples servidores web (balanceo de carga), necesitas que la caché sea compartida y consistente. Aquí es donde la caché distribuida WordPress marca la diferencia.

Beneficios clave

  • Escalabilidad horizontal: Puedes añadir más servidores web o nodos de caché sin reconfigurar todo el sistema. Redis Cluster o Varnish con sharding permiten distribuir la carga.
  • Tolerancia a fallos: Si un nodo de Redis cae, los datos se replican o se reequilibran. Varnish puede configurarse con varios backends y failover.
  • Sesiones distribuidas: WordPress usa sesiones PHP para carritos de compra, logins o formularios. Redis centraliza las sesiones, permitiendo que cualquier servidor web acceda a ellas, independientemente de qué nodo atendió al usuario inicialmente.
  • Reducción de latencia: Al cachear objetos (consultas SQL, transients, fragmentos de página) en Redis, y páginas completas en Varnish, el tiempo de respuesta baja de segundos a milisegundos.

Componentes de la solución: Redis y Varnish

Redis: El almacén de objetos y sesiones

Redis es una base de datos en memoria, de tipo clave-valor, extremadamente rápida. En el contexto de WordPress, se usa para:

  • Caché de objetos: Almacenar resultados de consultas SQL, opciones de tema, transients y fragmentos de HTML generados por plugins.
  • Sesiones distribuidas: Almacenar las sesiones de usuario (wp_session) para que sean accesibles desde cualquier servidor web.
  • Colas y contadores: Para tareas asíncronas (WP-Cron) o limitación de peticiones.

Varnish: El proxy inverso de páginas completas

Varnish es un acelerador HTTP que se sitúa delante del servidor web. Su función principal es cachear páginas HTML completas (o fragmentos) y servirlas sin necesidad de ejecutar PHP. Es ideal para contenido público (páginas, posts, feeds) que no varía por usuario.

  • Cacheo de página completa: Reduce drásticamente la carga en PHP y MySQL.
  • Purga selectiva: Al publicar un post, Varnish puede invalidar solo las URLs afectadas.
  • ESI (Edge Side Includes): Permite cachear partes de una página (sidebar, menú) mientras otras son dinámicas (carrito).

Configuración práctica de caché distribuida con Redis y Varnish

1. Instalación y configuración de Redis

Primero, instala Redis en un servidor dedicado o en el mismo nodo (si es pequeño). Para entornos distribuidos, usa Redis Sentinel o Cluster.

# Instalación en Ubuntu/Debian
sudo apt update && sudo apt install redis-server -y

# Configurar para escuchar en todas las interfaces (si es seguro)
sudo sed -i 's/bind 127.0.0.1/bind 0.0.0.0/' /etc/redis/redis.conf

# Configurar persistencia (RDB o AOF) según necesidad
sudo systemctl restart redis-server

Luego, conecta WordPress a Redis mediante el plugin Redis Object Cache.

# Instalar plugin desde WP-CLI
wp plugin install redis-cache --activate

Configura las constantes en wp-config.php:

define('WP_REDIS_HOST', '192.168.1.100'); // IP del servidor Redis
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Activa la caché desde el panel de administración o vía WP-CLI:

wp redis enable

[!TIP]
Para sesiones distribuidas, necesitas un plugin como WP Redis Sessions o configurar manualmente el manejador de sesiones de PHP para que use Redis.

2. Instalación y configuración de Varnish

Varnish se instala en un servidor separado o en el mismo frontend. La versión recomendada es Varnish Cache 6.x o 7.x.

# Instalación en Ubuntu
sudo apt install varnish -y

Configura el puerto de escucha (por defecto 80) y el backend (tu servidor web Apache/Nginx).

Archivo /etc/varnish/default.vcl:

vcl 4.1;

backend default {
    .host = "192.168.1.50";  # IP del servidor web
    .port = "8080";          # Puerto donde corre WordPress
}

sub vcl_recv {
    # No cachear peticiones de administración
    if (req.url ~ "^/wp-admin" || req.url ~ "^/wp-login") {
        return (pass);
    }
    # No cachear peticiones de usuarios autenticados (cookies)
    if (req.http.Cookie ~ "wordpress_logged_in" || req.http.Cookie ~ "wp-settings") {
        return (pass);
    }
    # Cachear todo lo demás
    return (hash);
}

sub vcl_backend_response {
    # Cachear páginas por 1 hora (3600 segundos)
    set beresp.ttl = 1h;
    # No cachear páginas con cookies de sesión
    if (beresp.http.Set-Cookie) {
        set beresp.ttl = 0s;
    }
}

sub vcl_deliver {
    # Añadir cabecera para depuración
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

[!WARNING]
No cachees páginas de administración ni de usuarios logueados. Si lo haces, podrías exponer datos privados o romper la funcionalidad.

3. Integración de Redis con Varnish

Para una caché distribuida WordPress completa, Redis y Varnish deben coordinarse. Varnish no sabe de objetos internos de WordPress, pero puede usar Redis para almacenar tokens de purga o información de sesión.

Una técnica avanzada es usar Varnish-Modules (vmod) como libvmod-redis para consultar Redis directamente desde VCL. Esto permite, por ejemplo, verificar si un usuario tiene una sesión activa antes de servir una página cacheada.

Ejemplo de VCL con consulta a Redis:

import redis;

sub vcl_recv {
    # Consultar Redis para ver si el usuario tiene sesión
    if (redis.exists("session:" + req.http.Cookie:session_id)) {
        return (pass);  # No cachear
    }
    # Si no tiene sesión, cachear
    return (hash);
}

Sin embargo, esto añade latencia. La mayoría de implementaciones optan por mantener Varnish para contenido público y Redis para objetos dinámicos y sesiones, sin mezclarlos en la misma capa.

Estrategias avanzadas para escalabilidad

1. Sesiones distribuidas con Redis

WordPress no maneja sesiones de forma nativa, pero plugins como WooCommerce o formularios las usan intensivamente. Para que las sesiones funcionen en un entorno multi-servidor, deben almacenarse en Redis.

Configura PHP para usar Redis como manejador de sesiones:

; En php.ini o en un archivo .user.ini
session.save_handler = redis
session.save_path = "tcp://192.168.1.100:6379?auth=tu_password"

Luego, instala un plugin como WP Redis Sessions o añade el siguiente código a wp-config.php:

// Forzar el uso de Redis para sesiones
add_filter('wp_session_manager', function() {
    return 'Redis_Session_Handler';
});

[!TIP]
Usa una base de datos Redis separada para sesiones (ej. db=1) para no mezclarlas con la caché de objetos.

2. Purga inteligente de Varnish desde WordPress

Cuando publicas o actualizas contenido, Varnish debe purgar las URLs afectadas. Puedes hacerlo manualmente con varnishadm o automáticamente con un plugin.

Plugin recomendado: Varnish HTTP Purge o WP Varnish.

Configura las constantes en wp-config.php:

define('VARNISH_IP', '192.168.1.200');
define('VARNISH_PORT', 80);
define('VARNISH_PURGE_KEY', 'tu_clave_secreta');

El plugin enviará una petición PURGE a Varnish cada vez que se publique un post.

3. Cacheo de fragmentos con ESI

Para contenido dinámico (carrito de compra, saludo personalizado), usa ESI en Varnish. Permite cachear la página completa pero marcar fragmentos como dinámicos.

Ejemplo en VCL:

sub vcl_backend_response {
    # Habilitar ESI
    set beresp.do_esi = true;
}

En WordPress, usa un shortcode o función que devuelva el contenido dinámico con etiquetas ESI:

function esi_carrito() {
    return '<esi:include src="/carrito/" />';
}
add_shortcode('esi_carrito', 'esi_carrito');

Monitoreo y ajuste fino

Herramientas esenciales

  • Redis CLI: redis-cli info stats para ver hits, misses y memoria usada.
  • Varnishstat: varnishstat -1 para métricas de caché, backend y errores.
  • WP-CLI: wp redis status y wp varnish purge para gestión remota.

Ajustes de rendimiento

  • Redis: Aumenta maxmemory y define una política de expulsión (ej. allkeys-lru). Usa save "" si no necesitas persistencia.
  • Varnish: Ajusta thread_pools y thread_pool_max según el número de CPUs. Usa param.set para tuning fino.
  • WordPress: Reduce el tiempo de expiración de transients (define WP_REDIS_MAX_TTL) y evita cachear demasiados objetos grandes.

Casos de uso reales

WooCommerce con alta concurrencia

Un ecommerce con miles de productos necesita:

  • Redis: Cachear consultas de productos, sesiones de carrito y precios dinámicos.
  • Varnish: Cachear páginas de categorías y productos (con ESI para el carrito).

Sitio de noticias con tráfico masivo

Un periódico digital usa:

  • Varnish: Cachear portada y artículos por minutos.
  • Redis: Almacenar transients de widgets, últimas noticias y sesiones de usuarios registrados.

Multisitio WordPress

En una red de sitios, Redis permite compartir la caché entre todos los subdominios, mientras Varnish cachea cada sitio por separado (usando req.http.host).

Conclusión

La combinación de Redis y Varnish para una caché distribuida WordPress es la estrategia más sólida para lograr escalabilidad, rendimiento y disponibilidad. Redis maneja los objetos dinámicos y las sesiones distribuidas, mientras Varnish acelera la entrega de contenido estático y público. Juntos, reducen la carga del servidor web y la base de datos, permitiendo que WordPress sirva millones de visitas sin despeinarse.

Implementar esta arquitectura requiere planificación: desde la configuración de Redis Cluster hasta la definición de políticas de purga en Varnish. Pero el resultado es un sitio ultrarrápido, tolerante a fallos y listo para escalar horizontalmente.

[!INFO]
No olvides probar en un entorno de staging antes de pasar a producción. Usa herramientas como ab (Apache Bench) o wrk para simular carga y verificar que la caché distribuida funciona como esperas.

¿Listo para transformar tu WordPress en una máquina de alto rendimiento? Empieza con Redis, añade Varnish y ajusta hasta que cada petición vuele.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel