¿Qué es un CDN (Content Delivery Network)? Cómo funciona

¿Qué es un CDN (Content Delivery Network)?

Una red de distribución de contenidos (CDN, por sus siglas en inglés) es un grupo de servidores repartidos en muchas ubicaciones que guardan copias de tu contenido y responden cada petición desde el punto más cercano al visitante. Acorta la distancia que recorren los datos, descarga a tu propio servidor y mantiene disponible el contenido popular cuando sube el tráfico.

Tu servidor sigue siendo la fuente de verdad y se llama servidor de origen. Los servidores del CDN que están delante se llaman servidores edge (de borde). MDN describe la idea igual: copias duplicadas de los datos, servidas por los servidores más cercanos a cada usuario.

Cómo funciona un CDN

1. El navegador pide una URL de tu dominio y el DNS lo dirige a un servidor edge del CDN cercano al visitante.
2. El edge consulta su caché. Si hay acierto (hit), responde al instante. Si falla (miss), pide el archivo al origen o a una caché intermedia, guarda una copia y responde.
3. Los siguientes visitantes de esa zona reciben la copia guardada hasta que caduca (su TTL) o la purgas.

El porcentaje de peticiones respondidas desde la caché es la tasa de aciertos de caché (cache hit ratio), el dato que indica si el CDN cumple su función. La misma idea se aplica un nivel más abajo, en el caché de APIs.

Qué cachear y qué dejar fuera

La cabecera de respuesta Cache-Control le dice al CDN qué puede guardar y durante cuánto tiempo.

Ojo con los nombres: no-cache no significa "no guardar", sino "consultar al origen antes de reutilizar". Lo que impide guardar es no-store. Todas las directivas están en la referencia de Cache-Control de MDN.

Por qué usar un CDN

• Menor latencia. La distancia influye en la latencia, y un servidor edge cercano está más cerca que tu origen para la mayor parte del mundo. Lo primero que mejora es el tiempo hasta el primer byte.
• Menos carga en el origen. Cada petición respondida en el edge es una que tus servidores nunca ven, así que puedes usar una infraestructura más pequeña para el mismo tráfico.
• Picos de tráfico. El contenido en caché se sigue sirviendo mientras tu origen, de otro modo, haría cola.
• Resiliencia. Si una ubicación edge tiene problemas, las peticiones pueden ir a otra. Las copias en caché pueden seguir respondiendo mientras el origen va lento.
• Protección y extras. Muchos proveedores terminan TLS, comprimen respuestas y filtran tráfico abusivo en el edge. Ayuda frente a inundaciones (ver cómo detener ataques DDoS), pero no sustituye los límites de tasa en tu propio origen.

Errores habituales con un CDN

• Archivos obsoletos tras un despliegue. Pon un hash en el nombre de los archivos estáticos para que cada versión tenga una URL nueva, y purga solo las pocas URLs que no pueden cambiar de nombre, como el HTML. Nuestro artículo sobre invalidación de caché y pruebas de rendimiento (en inglés) lo explica con más detalle.
• Cachear respuestas personalizadas. Olvidar private en una respuesta de un usuario puede hacer que una caché compartida se la entregue a otro. MDN avisa justo de eso.
• Una clave de caché demasiado específica. Si las cookies o parámetros aleatorios forman parte de la clave, el CDN guarda una copia por variante y la tasa de aciertos se desploma. Elimina lo que no cambie la respuesta.
• Cache stampede. Cuando caduca un objeto popular, muchos edges preguntan al origen a la vez. stale-while-revalidate o una capa de origin shield lo absorbe.
• Dar por hecho que un CDN siempre es más rápido. MDN señala que un host de terceros añade su propia consulta DNS y conexión. Si tu público está junto al origen, la mejora puede ser pequeña: mídela.
• No probar nunca un fallo de caché. Tras una purga o un despliegue, el origen debe aguantar toda la carga durante un rato.

CDN frente a edge computing

Un CDN guarda y sirve contenido. El edge computing ejecuta tu código en esas mismas ubicaciones, por ejemplo para reescribir una petición o personalizar una respuesta cerca del usuario. Muchos proveedores ofrecen ambas cosas, pero solo la primera es un CDN en sentido clásico.

Cómo probar y monitorizar un CDN

• Lee las cabeceras de respuesta. La cabecera Age indica cuánto tiempo estuvo el objeto en una caché proxy; un valor 0 suele significar que vino del origen. La mayoría de los proveedores añaden además su propia cabecera de estado de caché. La herramienta gratuita curl Online envía la misma petición desde seis regiones de AWS y muestra estado, cabeceras y tiempos, para que compares ubicaciones edge.
• Vigila la velocidad por región. La monitorización de velocidad de página ejecuta auditorías Lighthouse programadas desde 25 regiones cloud y muestra si el CDN ayuda en todas partes o solo cerca de tu origen. Haz el seguimiento junto con los Core Web Vitals.
• Prueba más allá de la caché. Una prueba de carga contra una URL en caché mide sobre todo el CDN. Prueba también con peticiones que eviten la caché para ver qué hace tu origen con la caché fría. Nuestro artículo sobre ubicaciones edge en pruebas cloud (en inglés) explica por qué importa dónde se prueba.

Preguntas frecuentes: CDN

¿Necesito un CDN para un sitio pequeño?

Si casi todos tus visitantes están en una región cercana a tu servidor, la mejora es pequeña. Si tus visitantes están repartidos por el mundo, o quieres un colchón para picos de tráfico, merece la pena. Muchos proveedores ofrecen un plan inicial gratuito o barato.

¿Puede un CDN cachear respuestas de una API?

Sí, con cuidado. Las respuestas GET de solo lectura que son iguales para todos se cachean bien. Los datos personales, como GET /me, deben marcarse como private o no-store. Usa Cache-Control y Vary de forma deliberada.

¿Cómo vacío la caché después de un despliegue?

Usa nombres de archivo versionados o con hash para los estáticos: cada versión tiene una URL nueva y no hay nada que vaciar. Para las URLs que mantienen su nombre, como las páginas HTML, llama a la API de purga de tu proveedor tras el despliegue.

¿Cómo sé si una respuesta vino de la caché del CDN?

Mira las cabeceras de respuesta. Una cabecera Age distinta de 0 indica que el objeto salió de una caché proxy, y la mayoría de los CDN añaden una cabecera propia que dice hit o miss. Repite la petición y compara.

¿Protege un CDN contra ataques DDoS?

Ayuda, porque las inundaciones se absorben en el edge antes de llegar a tu origen. No sustituye la limitación de tasa, un cortafuegos de aplicaciones web ni un plan para ataques de capa de aplicación contra endpoints dinámicos.

¿Afecta un CDN al SEO?

De forma indirecta. Cargar más rápido puede mejorar los Core Web Vitals, que Google recomienda cuidar para la búsqueda. Una caché mal configurada también puede servir títulos y metaetiquetas antiguos o bloquear rastreadores, así que revisa qué devuelve el CDN a Googlebot.