Varnish Cache para WordPress: Acelera tu Sitio Congelando Paginas

Varnish Cache es un reverse-proxy HTTP de alto rendimiento que se interpone entre el visitante y tu servidor web. A diferencia de los plugins de cache de WordPress —que operan dentro de PHP—, Varnish funciona en la capa 4 del modelo OSI, interceptando solicitudes antes de que lleguen a Apache, Nginx o incluso LiteSpeed. Eso significa que una pagina cacheada por Varnish se sirve en microsegundos, sin tocar la base de datos, sin ejecutar PHP, sin generar carga adicional en el servidor.

Imagina que tu WordPress es un restaurante. Sin Varnish, cada cliente que llega exige que el chef cocine su plato desde cero. Con Varnish, el chef prepara los platos mas pedidos una vez, los deja listos en la vitrina, y el mesero los entrega al instante. El resultado: tiempos de respuesta que pasan de 800 ms a menos de 50 ms en una solicitud cacheada.

Para sitios WordPress con trafico moderado o alto —portales de noticias, e-commerce con WooCommerce, directorios— Varnish puede reducir la carga del servidor hasta en un 80%. El servidor backend descansa y solo trabaja cuando Varnish decide que el contenido expiro o necesita regenerarse. En escenarios de pico de trafico, como un producto en oferta o una nota viral, esa descarga es la diferencia entre un sitio que responde y uno que cae de rodillas.

Eso si: Varnish no es magia Instantanea. Requiere configuracion, conocimiento de HTTP headers y acceso root al servidor. No es un plugin que instalas desde el panel de WordPress y activas con un clic. Es infraestructura.

Varnish vs LiteSpeed Cache: No Son lo Mismo

Esta es la confusion mas frecuente en foros de WordPress Chile: comparar Varnish con LiteSpeed Cache como si fueran opciones equivalentes. No lo son, y entender la diferencia es clave para tomar la decision correcta.

LiteSpeed Cache (LSCache) es un modulo del servidor LiteSpeed que funciona como plugin dentro del ecosistema WordPress. Se instala desde el directorio de plugins, se configura con una interfaz grafica, y maneja purga de cache de forma automatica al publicar o actualizar contenido. LSCache opera dentro del servidor web mismo —no hay capa intermedia— y gestiona HTTPS de forma nativa sin configuracion adicional.

Varnish, en cambio, es un servicio independiente que corre en un puerto distinto (tipicamente el 6081). Actua como reverse-proxy: recibe la solicitud, busca en su hashtable en RAM, y si encuentra la pagina la devuelve sin consultar el backend. Si no la encuentra, la pide al servidor web backend (Nginx, Apache o LiteSpeed en otro puerto), guarda una copia en RAM, y la entrega al visitante. Esa arquitectura lo hace extraordinariamente rapido, pero tambien mas complejo de mantener.

La regla practica: si estas en hosting compartido, Varnish no es para ti. No tienes acceso root ni puedes modificar la pila del servidor. LiteSpeed Cache, en cambio, funciona perfectamente en hosting compartido con LiteSpeed Enterprise. Para un analisis mas detallado de LiteSpeed Cache, consulta nuestra guia de configuracion de LiteSpeed Cache para WordPress.

Si tienes un VPS o servidor dedicado y necesitas el maximo rendimiento posible —estamos hablando de servir 10.000 req/s desde RAM— Varnish es el arma pesada. Pero trae costo operativo: configuracion VCL, gestion de SSL termination, purga manual o mediante plugins adicionales. La comparacion no es cual es mejor, sino cual es mejor para tu contexto tecnico.

Como Funciona Varnish: El Reverse-Proxy que Congela Paginas

El concepto central de Varnish se resume en una palabra: congelar. Cuando Varnish cachea una pagina, la guarda en memoria RAM tal como el servidor la genero —HTML completo, CSS inline, imagenes referenciadas— y la sirve identica a cada visitante subsiguiente hasta que el TTL (Time to Live) expira o se fuerza una purga.

El flujo es asi: el visitante solicita tudominio.cl/pagina/. La solicitud llega primero a Varnish (que escucha en el puerto 80 o el que configures). Varnish revisa su hashtable en RAM. Si encuentra una copia valida —un hit—, devuelve la respuesta sin tocar el backend. El Visitante recibe la pagina en menos de 50 ms. Si no la encuentra —un miss—, Varnish reenvia la solicitud al servidor web backend (Nginx, Apache o LiteSpeed en otro puerto), recibe la respuesta, la almacena en RAM, y la entrega al visitante.

Los headers HTTP que Varnish agrega a cada respuesta son tu brujula de diagnostico:

• X-Cache: HIT — la pagina fue servida desde cache. Rapido.
• X-Cache: MISS — la pagina no estaba en cache y se pidio al backend. Primera visita o TTL expirado.
• Age: 3600 —cuantos segundos lleva la copia almacenada en cache. Cuando Age alcanza el TTL configurado, la proxima solicitud sera un MISS.
• Via: 1.1 varnish (Varnish/7.x) — confirma que la respuesta paso por Varnish.

Estos headers son esenciales para confirmar que Varnish esta funcionando correctamente. Puedes verificarlos con curl -I tudominio.cl/pagina/ desde la terminal.

La configuracion de Varnish se escribe en VCL (Varnish Configuration Language), un lenguaje declarativo que define reglas de cache, purga y routing. La VCL es poderosa: permite excluir URLs especificas del cache (como /wp-admin/ o /cart/), definir TTLs diferentes segun tipo de contenido, y manejar grace periods para servir contenido expirado mientras se regenera en segundo plano.

El grace period es particularmente util: si un trafico de pico genera miles de solicitudes simultaneas a una pagina cuyo TTL acaba de expirar, Varnish sirve la copia expirada (grace) mientras una sola solicitud regenera el cache. Asi evitas la tormenta de peticiones que derribaria un servidor sin proteccion.

Cuando Varnish Tiene Sentido para tu WordPress Chile

No todos los sitios WordPress necesitan Varnish. De hecho, para la mayoria de los sitios pequenos y medianos en Chile, un buen plugin de cache como LiteSpeed Cache o WP Rocket con Nginx FastCGI cache es mas que suficiente. Pero hay escenarios donde Varnish marca una diferencia real:

1. Portales de noticias y blogs con trafico alto. Sitios como medios digitales chilenos que reciben decenas de miles de visitas por hora se benefician enormemente de Varnish. Las paginas de articulos son mayormente estaticas entre publicaciones, y Varnish las sirve desde RAM a velocidad constante sin importar el trafico.

2. E-commerce con WooCommerce en momentos de campaña. Durante CyberDay o Black Friday, un sitio de e-commerce puede multiplicar su trafico por 10. Varnish con grace periods puede mantener las paginas de categoria y producto servidas desde cache mientras el backend solo procesa el checkout —que debe excluirse del cache por razones obvias.

3. Sitios institucionales con contenido que cambia poco. Sitios de gobierno, universidades o empresas grandes que publican contenido esporadicamente. Para estos casos, configurar un TTL de 24 horas en Varnish resulta en un tasa de hit de cache superior al 95%.

Cuando NO tiene sentido Varnish: Hosting compartido sin acceso root, sitios con contenido totalmente personalizado por usuario (dashboards, areas privadas), o sitios con plugins que generan HTML dinamico en cada solicitud.

Configurar Varnish con WordPress: La Guia Paso a Paso

La configuracion de Varnish tiene tres partes: instalacion del servicio, configuracion de VCL, y purga de cache. Vamos paso a paso.

Instalar Varnish on Ubuntu/Debian

Instala Varnish desde los repositorios de tu distribucion:

sudo apt-get update
sudo apt-get install varnish

Por defecto, Varnish corre en el puerto 6081 y espera conexiones del puerto 80. Necesitas cambiar el orden: que Varnish escuche en el puerto 80 y reenvie al backend (Apache o Nginx) en otro puerto, digamos el 8080.

Edita el archivo /etc/varnish/default.vcl y configura tu backend:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

Ahora configura el puerto en /etc/default/varnish:

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Reinicia el servicio: sudo systemctl restart varnish. Verifica que esta corriendo con sudo systemctl status varnish.

Configurar VCL: Reglas de Cache para WordPress

El archivo VCL define las reglas de que cachear, por cuanto tiempo, y que excluir. Para WordPress, la VCL mas importante es excluir el admin y el carrito de WooCommerce:

sub vcl_recv {
    # No cachear wp-admin ni wp-login
    if (req.url ~ "wp-admin|wp-login") {
        return (pass);
    }
    # No cachear carrito y checkout de WooCommerce
    if (req.url ~ "cart|checkout|my-account") {
        return (pass);
    }
}

sub vcl_backend_response {
    # TTL por defecto: 2 horas
    set beresp.ttl = 2h;
    # No cachear respuestas con cookies de sesion
    if (beresp.http.Set-Cookie ~ "wordpress_logged_in") {
        set beresp.uncacheable = true;
        return (deliver);
    }
    # Cache para paginas estaticas: 24 horas
    if (bereq.url ~ "\.(png|jpg|jpeg|gif|css|js|woff|woff2)$") {
        set beresp.ttl = 24h;
    }
}

Esta VCL basica cachea todo menos las paginas de login, admin y checkout. Ajusta los TTLs segun la frecuencia de actualizacion de tu contenido.

Purga de Cache: Cuando y Como Invalidar

Varnish cachea por TTL pero tambien necesita purgas manuales cuando publicas contenido nuevo. Hay tres metodos:

1. Purga por URL (mas comun):

varnishadm 'ban.url /mi-articulo/'

Esto invalida la cache para esa URL especifica.

2. Purga completa:

varnishadm 'ban.url /'

Invalida toda la cache. Usalo despues de actualizaciones mayores.

3. Plugin WordPress: Varnish HTTP Purge. Este plugin purga automaticamente la URL modificada cuando editas o publicas un articulo. Instalalo desde el directorio de plugins de WordPress y activalo. No necesita configuracion — funciona out of the box.

Para WooCommerce, tambien existe WooCommerce Varnish Cache, que purga el carrito y paginas de producto cuando cambian.

Varnish y HTTPS: El Desafio del SSL Termination

Varnish no maneja HTTPS nativamente. Cuando un visitante conecta por HTTPS, necesitas un terminador SSL — Nginx o HAProxy — que descifre el trafico y se lo pase a Varnish en texto plano.

La arquitectura tipica es: Visitante (HTTPS) → Nginx (SSL termination, puerto 443) → Varnish (cache, puerto 80) → Backend (Apache/Nginx, puerto 8080).

Nginx recibe la solicitud HTTPS, la descifra, y la reenvia a Varnish en HTTP plano. Varnish sirve desde cache o pide al backend, y la respuesta vuelve por el mismo camino. Esta arquitectura es estandar en produccion de alto trafico.

Si tu hosting ya tiene SSL configurado con Let's Encrypt, probablemente ya tienes Nginx o Apache manejando HTTPS. Agregar Varnish en frente requiere reorganizar esa cadena, lo cual no es trivial en hosting compartido — otra razon mas por la que Varnish es principalmente para VPS y servidores dedicados.

Medir el Impacto: Antes y Despues con Lighthouse

Para medir si Varnish esta haciendo diferencia, usa Lighthouse de Google Chrome antes y despues. Las metricas que deberian mejorar:

• Time to First Byte (TTFB): de 500-800 ms a menos de 50 ms en cache hit
• First Contentful Paint (FCP): mejora proporcional al TTFB
• Largest Contentful Paint (LCP): mejora si tus assets estaticos estan cacheados

Ejecuta Lighthouse en modo incognito para evitar cache del navegador. Corre cinco mediciones con Varnish activo y cinco sin el, y promedia los resultados.

Tambien puedes verificar tasa de hits de Varnish con:

curl -I tudominio.cl/pagina/ | grep X-Cache

Un 90%+ de hits en paginas de alto trafico indica que Varnish esta funcionando correctamente.

Errores Comunes de Varnish en WordPress

Los problemas mas frecuentes al implementar Varnish con WordPress:

1. Paginas de admin lentas. Si el admin de WordPress esta lento, verifica que /wp-admin/ esta siendo passthrough (return pass). Si se cachea, vas a ver versiones obsoletas de paginas de editor.

2. Carrito de WooCommerce vacio. El carrito depende de cookies de sesion. Si Varnish cachea una pagina con carrito, el siguiente visitante ve el carrito del anterior. Exclui /cart/ y /checkout/ del cache.

3. Cambios no se ven. Si editas un articulo y no lo ves actualizado, la pagina esta cacheada. Usa el plugin Varnish HTTP Purge para purga automatica, o ejecuta varnishadm 'ban.url /articulo/' manualmente.

4. Certificado SSL roto. Si despues de instalar Varnish tu sitio muestra errores de certificado SSL, el problema es la cadena de SSL termination. Verifica que Nginx (o HAProxy) esta manejando HTTPS y pasando trafico a Varnish, no al reves.

Conclusion: Varnish = Cabecera de Primera Linea

Varnish Cache es una herramienta de infraestructura que puede transformar el rendimiento de un sitio WordPress con trafico alto. No es para todos — requiere acceso root, conocimiento de HTTP y disposicion a mantener la configuracion. Pero para portales, e-commerce y sitios que necesitan servir miles de solicitudes por segundo, es una de las inversiones de rendimiento mas solidas que puedes hacer.

La alternativa mas practica para la mayoria de los sitios WordPress en Chile sigue siendo LiteSpeed Cache, que ofrece mejoras de rendimiento significativas sin la complejidad operativa de Varnish. Si tu hosting tiene LiteSpeed (como Elevocloud), empezar por ahi es el camino mas directo.

Si tienes un VPS y quieres explorar Varnish, empieza con la configuracion basica de este articulo, mide el impacto con Lighthouse, e itera desde ahi. La recompensa en velocidad y capacidad de trafico vale la curva de aprendizaje.

Articulos relacionados: Configurar LiteSpeed Cache para WordPress · Core Web Vitals y Lighthouse para WordPress · Rendimiento web: como optimizar la velocidad de tu sitio