Quien administra WordPress a escala lo sabe: el problema ya no es solo el PHP o la base de datos, sino llevar contenido rápido a usuarios repartidos por medio planeta… sin que la factura de la CDN comercial se dispare ni tu infraestructura se convierta en una caja negra.
En los últimos años muchos proyectos han pasado de usar “un plugin de caché + CDN externa” a plantearse algo más ambicioso: montar su propia CDN, apoyándose en tecnologías abiertas como Varnish Cache o Nginx. No se trata de reinventar la rueda, sino de recuperar control: dónde se cachea, qué se cachea, cuánto tiempo y a qué coste.
Este artículo está pensado para una web de administradores de sistemas que gestionan uno o varios WordPress con tráfico serio (medios, e-commerce, SaaS, portales corporativos) y quieren entender cómo plantear una CDN propia con herramientas conocidas.
El patrón típico que llega a manos de un sysadmin suele ser:
/wp-content/uploads/, CSS, JS) a un dominio de CDN.Ventajas:
Inconvenientes cuando se escala:
En casi cualquier stack de WordPress medianamente serio ya están estos ingredientes:
La idea de una CDN propia no es montar 100 PoPs como un hiperescala, sino:
Una arquitectura razonable para una CDN propia orientada a WordPress podría ser algo así:
proxy_cache.Ambas herramientas son válidas. No se trata de una guerra de religiones, sino de usar lo que más encaje en cada capa.
| Aspecto | Varnish Cache | Nginx (reverse proxy + proxy_cache) |
|---|---|---|
| Enfoque principal | Acelerador HTTP puro, diseñado para caché | Servidor web + proxy inverso con caché integrada |
| Configuración de caché | Lenguaje VCL muy flexible | Directivas en bloques (location, proxy_cache_*) |
| Soporte de TLS | Tradicionalmente delante (Nginx/HAProxy) o módulos | Integrado, muy maduro |
| Integración con WordPress | Vía headers, cookies y VCL a medida | Vía headers, cookies y map/if/location |
| Curva de aprendizaje | Algo más técnica (VCL) | Más familiar para quien ya usa Nginx |
| Uso típico en CDNs propias | Capa principal de caché/edge | TLS + caché simple, o solución todo-en-uno en PoPs |
En muchos despliegues se combinan: Nginx para TLS y como backend de Varnish; en otros, Nginx hace de proxy caché directamente en los PoPs y Varnish se reserva para el origen. Depende de tu experiencia y de cuánta lógica quieras meter en el edge.
Antes de tocar servidores, compensa responder a:
Esto marcará:
Para un administrador de sistemas, la primera decisión real es de infraestructura:
Criterios prácticos:
No hace falta empezar con 10 PoPs. A menudo, 2–3 bien situados aportan más que un despliegue excesivo que luego no se mantiene.
El origin shield es el punto donde tiene sentido invertir más tiempo en lógica:
Ejemplo simplificado con Varnish:
vcl 4.1;
backend wp_backend {
.host = "10.0.0.10";
.port = "8080";
}
sub vcl_recv {
# No cachear admin ni login
if (req.url ~ "^/wp-admin/" ||
req.url ~ "^/wp-login\.php") {
return (pass);
}
# No cachear usuarios autenticados ni carritos
if (req.http.Cookie ~ "wordpress_logged_in_" ||
req.http.Cookie ~ "woocommerce_cart_hash" ||
req.http.Cookie ~ "woocommerce_items_in_cart") {
return (pass);
}
# Solo cachear GET/HEAD
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
return (hash);
}
sub vcl_backend_response {
# TTL por defecto para HTML
set beresp.ttl = 120s;
# Más TTL para estáticos
if (bereq.url ~ "\.(css|js|jpe?g|png|webp|svg|woff2?)$") {
set beresp.ttl = 1h;
}
# Grace para servir contenido aunque el backend esté lento
set beresp.grace = 5m;
}
Lenguaje del código: PHP (php)El equivalente con Nginx usaría proxy_cache, proxy_cache_key, proxy_cache_valid, etc., y la lógica de cookies se puede tratar con map y if en los bloques location.
Lo importante es:
Cada PoP actúa como un mini reverse proxy cerca del usuario:
cdn.midominio.com, static.midominio.com o incluso el dominio principal si te atreves a cachear HTML agresivamente.Con Nginx, por ejemplo:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:500m max_size=50g inactive=60m use_temp_path=off;
server {
listen 80;
server_name static.midominio.com;
location / {
proxy_pass http://origin-shield;
proxy_cache WORDPRESS;
proxy_cache_valid 200 301 302 1h;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
add_header X-Cache-Status $upstream_cache_status;
}
}
Lenguaje del código: PHP (php)A nivel de DNS / routing:
static.midominio.com a la IP del PoP más cercano.La filosofía es simple: cuanto más cerca esté la caché del usuario, menos latencia y menos carga en origen.
Montar cachés sin pensar en el flujo editorial es la receta perfecta para que la CDN acabe desactivada “porque no vemos los cambios”.
La clave está en cómo y cuándo se purga:
Opciones:
save_post, transition_post_status, etc.).Ejemplo de purga simple por URL:
curl -X PURGE "https://cdn.midominio.com/ruta/de/la/entrada/"
Lenguaje del código: JavaScript (javascript)O, en Nginx, usando un método especial que invalide el objeto en proxy_cache si se configura así.
Combinando:
…se consigue un equilibrio razonable entre frescura y rendimiento sin que los editores o el equipo de contenido noten “retardos misteriosos”.
Montar una CDN propia no obliga a renunciar a todo lo anterior. Muchos equipos optan por:
La ventaja de tener tu propia red de PoPs es que la decisión deja de ser binaria:
Para un administrador de sistemas, una CDN propia basada en Varnish o Nginx es, sobre todo, coherencia técnica:
curl, tcpdump, journalctl o lo que ya usas cada día.No es una solución mágica ni gratuita en términos de tiempo, pero cuando WordPress deja de ser “una web” para convertirse en un pilar del negocio, tener el edge bajo tu control se vuelve una ventaja competitiva muy real.
1. ¿Tiene sentido montar una CDN propia si ya uso Cloudflare o similar?
Sí, especialmente si gestionas varios WordPress con mucho tráfico o requisitos específicos (compliance, residencia de datos, reglas complejas de caché). Puedes mantener Cloudflare para DNS, WAF o ciertas regiones y usar tu CDN propia como primera capa de caché y control.
2. ¿Qué es más recomendable para empezar, Varnish o Nginx?
Depende de tu stack y equipo. Si ya dominas Nginx y quieres algo sencillo, proxy_cache puede ser un buen punto de partida. Si necesitas reglas de caché muy potentes y más flexibilidad, Varnish Cache encaja mejor como motor principal, dejando Nginx para TLS y backend.
3. ¿Es obligatorio cachear el HTML de WordPress en la CDN?
No. Puedes empezar cacheando solo contenidos estáticos (CSS, JS, imágenes) y, cuando tengas confianza en las reglas de purga e invalidación, extender la caché al HTML. Cada paso que acerques al edge reduce carga en el backend y mejora tiempos de respuesta.
4. ¿Qué herramientas recomiendan para monitorizar una CDN propia?
Lo habitual en entornos de sysadmin:
varnishstat) o Nginx (stub_status, vts, etc.) enviadas a Prometheus.hit ratio, latencias, errores 5xx y uso de caché.
