---
title: "Varnish en WordPress: cómo mejorar el rendimiento con caché, CDN y Cloudflare"
description: "Varnish sigue siendo una de las formas más eficaces de reducir el trabajo que hace WordPress en cada visita , pero ya no tiene sentido presentarlo como un simple plugin que se instala y listo. En una..."
url: https://wpdirecto.com/mas-rendimiento-en-wordpress-con-varnish/
date: 2012-05-03
modified: 2026-09-11
author: "David Carrero Fernández-Baillo"
image: https://wpdirecto.com/wp-content/uploads/2026/09/varnish-cache-wordpress-rendimiento.png
categories: ["Rendimiento"]
tags: ["apache", "cache", "CDN", "Cloudflare", "nginx", "rendimiento WordPress", "varnish", "wpo"]
type: post
lang: es
---

# Varnish en WordPress: cómo mejorar el rendimiento con caché, CDN y Cloudflare

**Varnish sigue siendo una de las formas más eficaces de reducir el trabajo que hace WordPress en cada visita**, pero ya no tiene sentido presentarlo como un simple plugin que se instala y listo. En una web actual suele convivir con Nginx o Apache, una CDN, reglas de caché y, en algunos casos, servicios como Cloudflare. La clave está en que cada capa tenga una función clara y no se pisen entre ellas.

Este artículo recupera la idea del texto original y la pone al día para los servidores y sitios WordPress de hoy. Varnish puede servir páginas públicas sin volver a ejecutar PHP en cada petición, pero hay que excluir correctamente el área de administración, las sesiones de usuario, los formularios con respuestas personalizadas y las partes dinámicas de una tienda online.

## Las claves de esta guía

- Varnish es una caché HTTP inversa que se coloca delante del servidor que ejecuta WordPress.
- Funciona especialmente bien con páginas públicas que cambian poco entre visitantes.
- La caducidad, las cookies y la purga son tan importantes como instalar el servicio.
- Una CDN o Cloudflare pueden complementar a Varnish, pero no conviene duplicar reglas sin una política común.

## Qué es Varnish y qué hace realmente

Varnish es un proxy inverso especializado en HTTP. En lugar de enviar cada visita directamente a WordPress, recibe la petición, comprueba si ya tiene una respuesta válida en su caché y, cuando la encuentra, la devuelve sin volver a pedir a PHP que genere la página. Esa diferencia se nota sobre todo en sitios con muchas visitas anónimas y contenidos que no cambian a cada segundo.

El recorrido habitual se parece a esto: navegador, CDN opcional, Varnish, Nginx o Apache, PHP, WordPress y base de datos. Cuando Varnish tiene un *cache hit*, la cadena se corta antes de llegar a PHP. Cuando hay un *cache miss*, Varnish pasa la petición al servidor de origen, recibe la respuesta y puede guardarla para la siguiente visita. La caché no hace que el código de WordPress sea más eficiente; evita ejecutarlo tantas veces.

La documentación oficial de [Varnish](https://varnish-cache.org/docs/7.0/index.html) lo describe como un acelerador de aplicaciones web y un proxy de caché. Sus reglas se escriben en VCL, el lenguaje de configuración que permite decidir qué peticiones se almacenan, cuáles se sirven desde caché y cuáles deben pasar siempre al origen.

## Por qué puede acelerar tanto WordPress

Una página de WordPress suele implicar cargar el núcleo, ejecutar plugins, consultar opciones y contenidos en la base de datos, construir la plantilla y generar el HTML final. Aunque el servidor esté bien configurado, repetir todo ese proceso para cada visitante es innecesario cuando diez personas están viendo la misma entrada pública.

Varnish guarda la respuesta HTTP terminada y la sirve desde memoria o almacenamiento rápido. Eso reduce el tiempo de respuesta del servidor de origen, libera procesos de PHP y deja más margen para atender picos de tráfico. La mejora no se limita a la velocidad percibida: al bajar el trabajo del servidor también disminuye el riesgo de que una avalancha de visitas termine en errores 502, timeouts o una cola de procesos saturada.

El resultado depende del tipo de web. Un blog, un medio o una documentación con muchas visitas anónimas suele obtener bastante provecho. Un panel privado, una aplicación con contenido distinto para cada usuario o una tienda con precios y carritos personalizados necesitará muchas más excepciones y puede aprovechar mejor otras optimizaciones.

## Varnish, Nginx, Apache y Cloudflare no son lo mismo

| Capa | Función principal | Qué conviene recordar |
| --- | --- | --- |
| Varnish | Caché HTTP inversa | Sirve respuestas ya generadas y aplica reglas de caché. |
| Nginx o Apache | Servidor web | Reciben y enrutan peticiones, sirven archivos y conectan con PHP. |
| PHP y WordPress | Generación dinámica | Construyen la respuesta cuando no existe una copia válida. |
| CDN | Distribución geográfica | Acerca archivos y, según la configuración, páginas a los visitantes. |
| Cloudflare | Red perimetral y servicios web | Puede aportar CDN, seguridad y caché en el borde, con sus propias reglas. |

Nginx y Apache pueden tener sus propios mecanismos de caché y servir archivos estáticos, pero eso no los convierte automáticamente en un sustituto de Varnish. Cloudflare, por su parte, se coloca fuera del servidor y puede filtrar tráfico, terminar TLS, distribuir recursos estáticos o cachear HTML en sus nodos. Son piezas diferentes, aunque algunas funciones se solapen.

El problema aparece cuando se activan varias cachés de página sin saber cuál manda. Una capa puede conservar una versión vieja mientras otra ya ha purgado la suya. Antes de añadir Varnish a un alojamiento gestionado conviene preguntar si el proveedor ya usa caché de página completa y cómo se invalida. A veces la mejor mejora consiste en ajustar la solución que ya existe.

## Cuándo tiene sentido usar Varnish

Varnish encaja bien en publicaciones, webs corporativas, revistas y proyectos con una proporción alta de visitantes que no han iniciado sesión. En estos casos, una misma respuesta HTML puede servirse a muchas personas durante un intervalo controlado. También puede ser útil cuando una campaña o una portada muy visitada provoca picos que el servidor de origen no soporta con comodidad.

No es una solución universal para todas las consultas lentas. Si el problema está en una consulta pesada, un plugin que bloquea la carga, imágenes enormes o un servidor con pocos recursos, Varnish puede ocultar el fallo durante un tiempo, pero no lo arregla. Cuando la caché expire, el origen volverá a ejecutar el proceso lento.

En WooCommerce hay que ser especialmente prudente. La portada, las categorías y algunas fichas de producto pueden ser cacheables, pero el carrito, el pago, la cuenta y cualquier respuesta vinculada a la sesión deben quedar fuera. Una configuración demasiado agresiva puede mostrar el carrito de otra persona o impedir que un formulario funcione como espera el usuario.

## La configuración base debe empezar por las excepciones

Antes de decidir cuánto tiempo guardar una página, hay que decidir qué nunca debe guardarse. Como punto de partida, las reglas suelen excluir `/wp-admin/`, `/wp-login.php`, las previsualizaciones, las peticiones de usuarios identificados y cualquier URL que genere datos privados. En una tienda también se excluyen las rutas de carrito, finalizar compra y cuenta, además de las cookies que identifican una sesión o un carrito.

- Excluye peticiones con la cookie `wordpress_logged_in_` cuando el contenido pueda ser personalizado.
- Revisa formularios, búsquedas, filtros y páginas con parámetros antes de permitir su almacenamiento.
- Trata con cuidado las respuestas que envían cabeceras `Set-Cookie` o indican que no deben guardarse.
- Comprueba que el origen puede purgar una URL concreta y también vaciar la caché cuando se publica un cambio grande.

La cabecera `Cache-Control` es una de las referencias fundamentales. La guía de introducción de [Varnish](https://varnish-cache.org/docs/7.0/tutorial/introduction.html) explica que el sistema puede interpretar estas instrucciones para decidir si una respuesta se guarda y durante cuánto tiempo. No conviene ignorarlas sin motivo: si WordPress o una aplicación marca una respuesta como privada, hay que entender por qué antes de forzarla a la caché pública.

La caché también debe tener un tiempo de vida razonable. Cinco minutos pueden ser suficientes para una portada que cambia con frecuencia; varias horas pueden tener sentido para una documentación estable. No hay un número correcto para todas las webs. La elección debe tener en cuenta la frecuencia de publicación y la facilidad para purgar una entrada en cuanto se edita.

## Purgar la caché cuando WordPress cambia

El error más visible de una caché mal conectada es publicar una modificación y seguir viendo la versión antigua. Por eso Varnish necesita una estrategia de invalidación. Cuando se actualiza una entrada, no siempre basta con purgar su URL: también pueden cambiar la portada, los archivos de categoría, las etiquetas, los feeds y los bloques de contenido relacionado.

La purga puede gestionarse mediante la integración del servidor, un plugin compatible con el entorno de alojamiento o una llamada controlada desde el sistema de publicación. Lo importante es que el mecanismo sea conocido y esté probado. No es recomendable instalar un plugin antiguo solo porque aparezca en un tutorial de hace años: hay que comprobar que sigue mantenido, que es compatible con la versión de WordPress y que habla correctamente con la configuración actual de Varnish.

Después de conectar la purga, edita una entrada de prueba, limpia una imagen o un bloque y verifica el resultado desde una ventana privada. Comprueba también la cabecera de respuesta y repite la visita varias veces: la primera puede ser un fallo de caché y la segunda un acierto. Así se distingue un problema de invalidación de un problema del servidor de origen.

## Cómo combinar Varnish con una CDN o Cloudflare

Una CDN puede descargar del origen las imágenes, hojas de estilo, scripts y otros archivos estáticos. También puede servir páginas HTML desde el borde, pero eso ya es otra capa de caché de página completa. Si Varnish está en el servidor y Cloudflare cachea HTML delante de él, hay que decidir qué sistema controla la caducidad y qué sistema recibe la purga.

Una configuración sencilla puede dejar a Cloudflare como red perimetral y CDN, mientras Varnish se ocupa de las respuestas cacheables que llegan al origen. Otra opción es que Cloudflare gestione la caché HTML y el servidor mantenga únicamente cachés locales. Ambas pueden funcionar; lo que suele causar problemas es mezclar políticas incompatibles o hacer que cada capa tenga un tiempo de vida distinto sin una invalidación coordinada.

No actives una regla de “cachear todo” sin revisar antes el acceso de administración, el inicio de sesión, las cookies, los formularios y la tienda. Una página de WordPress puede parecer correcta para un visitante anónimo y fallar para un usuario registrado. Prueba los dos recorridos y revisa también móvil, idiomas, parámetros de campaña y páginas que incluyan contenido personalizado.

## Varnish no sustituye al resto de optimizaciones

La documentación de rendimiento de [WordPress](https://developer.wordpress.org/advanced-administration/performance/optimization/) incluye la caché entre las medidas de mayor impacto, pero también recomienda ocuparse de imágenes, consultas, caché de objetos persistente, código y recursos estáticos. Una web rápida necesita que el servidor responda bien cuando la caché no tiene la página y que el navegador no descargue más recursos de los necesarios.

- Mide antes y después con páginas representativas, no solo con la portada.
- Optimiza las imágenes y utiliza tamaños adecuados para cada dispositivo.
- Revisa plugins que añaden consultas, scripts o peticiones externas innecesarias.
- Comprueba el tiempo de respuesta sin caché para conocer la salud real del origen.
- Vigila errores 5xx, memoria, procesos PHP y conexiones a la base de datos.
- Mantén WordPress, el tema y los plugins actualizados y elimina componentes que ya no uses.

En WPdirecto puedes continuar con nuestros [consejos para mejorar el rendimiento de WordPress](https://wpdirecto.com/consejos-para-mejorar-el-rendimiento-de-wordpress/) y consultar la [guía de actualización de WordPress](https://wpdirecto.com/infografia-como-guia-sencilla-de-actualizacion-de-wordpress/). Si el proyecto maneja información sensible o recibe mucho tráfico, también conviene repasar las recomendaciones de [seguridad de WordPress](https://wpdirecto.com/10-consejos-para-mejorar-la-seguridad-de-wordpress/) antes de añadir capas de caché delante del acceso público.

## Lista de comprobación antes de ponerlo en producción

1. Haz una copia de seguridad y documenta qué capa gestiona cada tipo de caché.
2. Prueba una página pública, una página con formulario, el acceso de usuario y, si existe, una compra completa.
3. Verifica que las páginas excluidas nunca se sirven desde una respuesta pública reutilizada.
4. Publica una modificación y confirma que la entrada, la portada y los archivos relacionados se actualizan.
5. Mide el tiempo de respuesta con caché caliente y con caché vacía.
6. Deja anotado cómo purgar una URL, cómo vaciar todo y a quién avisar si la caché sirve contenido antiguo.

## Conclusión

Varnish sigue teniendo sentido para acelerar WordPress, sobre todo cuando muchas visitas solicitan las mismas páginas públicas. Su valor está en evitar trabajo repetido en el origen, no en reemplazar el servidor web, PHP, WordPress o una CDN. Bien configurado, puede mejorar la capacidad de respuesta y amortiguar picos de tráfico; mal configurado, puede mostrar datos antiguos o contenido privado a la persona equivocada.

La forma sensata de implantarlo es empezar por medir, definir excepciones, elegir una única política de caducidad y probar la purga. Después se pueden añadir CDN, reglas de borde y optimizaciones más específicas. La caché debe ser una pieza visible y comprobable de la arquitectura, no una caja negra que se añade esperando que resuelva por sí sola todos los problemas de rendimiento.

**Fuentes:** [documentación oficial de Varnish](https://varnish-cache.org/docs/7.0/index.html), [introducción a Varnish y sus políticas de caché](https://varnish-cache.org/docs/7.0/tutorial/introduction.html) y [documentación oficial de optimización de WordPress](https://developer.wordpress.org/advanced-administration/performance/optimization/).