Un sitio alojado en Madrid tarda más en responder a un visitante de Buenos Aires o de Singapur que a uno de Sevilla: la distancia añade latencia a cada ida y vuelta. El CDN coloca servidores llamados perimetrales (edge) en muchas ciudades y les confía copias de los archivos. El visitante se dirige al más cercano, casi siempre gracias al DNS: el nombre del sitio apunta a la red del CDN y ya no directamente a tu servidor.
Cómo funciona un CDN
El CDN actúa como una caché compartida situada entre los visitantes y tu servidor, al que entonces se llama origen. En cada petición, el servidor perimetral comprueba si tiene una copia válida. Si la tiene, la devuelve sin contactar con el origen; si no, la pide, la entrega y la conserva para los siguientes visitantes.
El tiempo de conservación lo marcan las cabeceras HTTP que envía el origen. La documentación de MDN clasifica los CDN entre las cachés compartidas, que almacenan una sola respuesta y la sirven a muchos usuarios: Cache-Control: public, max-age=… permite guardarla, s-maxage fija una duración propia para las cachés compartidas, y private y no-store lo impiden. Cloudflare, por ejemplo, indica el resultado de cada petición en la cabecera cf-cache-status: HIT (servido desde la caché), MISS (no estaba, se pidió al origen), EXPIRED (copia caducada), BYPASS o DYNAMIC (no se guarda en caché).
Qué guarda realmente un CDN en caché
Hay un punto que sorprende a menudo: la documentación de Cloudflare precisa que su CDN no guarda en caché el HTML ni el JSON por defecto. Conserva los archivos estáticos que reconoce por su extensión (imágenes, CSS, JavaScript, fuentes, PDF, vídeos), mientras que las páginas de WordPress las sigue generando tu servidor en cada visita. También se pueden cachear las páginas con reglas específicas, siempre que excluyas todo lo personalizado: administración, carrito, cuenta de cliente y páginas de acceso.
Ventajas y límites
- Velocidad: menos distancia para los archivos pesados y, a menudo, protocolos recientes como HTTP/2 y HTTP/3 activados en el perímetro.
- Menos carga: cada archivo servido desde la caché es una petición menos para tu hosting.
- Protección: un CDN en modo proxy absorbe parte de los ataques volumétricos y suele ofrecer un cortafuegos de aplicaciones, opcional o incluido.
- Límites: una caché obsoleta muestra versiones antiguas tras un cambio, así que hay que saber purgarla; y tu servidor ya no ve la dirección IP de los visitantes, sino la del CDN.
Para WordPress
- Dos familias: el CDN en modo proxy (Cloudflare, por ejemplo), que se coloca delante de todo el sitio tras cambiar los servidores DNS, y el CDN de archivos, en el que un plugin reescribe las direcciones de los medios hacia un subdominio del CDN.
- Recupera la IP real de los visitantes; si no, la limitación de accesos, los registros y los bloqueos apuntan a los servidores del CDN. Nuestra guía Cloudflare delante de WordPress detalla los ajustes del servidor; WP Masquerade Pro también lee la cabecera de Cloudflare, pero solo cuando la conexión llega desde un rango oficial de Cloudflare, como explica la página sobre la compatibilidad con Cloudflare.
- Purga la caché tras cada actualización del tema o de los plugins, y comprueba que tu plugin de caché y el CDN no se contradicen.
- Protege el origen: si tu servidor sigue siendo accesible directamente por su IP, un atacante puede saltarse el CDN y su cortafuegos.
Las imágenes servidas desde la caché del CDN ya no llegan a tu servidor: la protección contra el hotlinking tiene que configurarse entonces en el propio CDN.