¿Qué es un CDN?

Un CDN, red de distribución de contenidos, es un conjunto de servidores repartidos por el mundo que guardan copias de los archivos de un sitio y los entregan desde el punto más cercano a quien los pide. En vez de traer cada imagen desde un único servidor, se sirve desde un nodo a unos kilómetros.

La ganancia es de distancia. Los datos viajan rápido pero no instantáneamente, y cada ida y vuelta entre continentes cuesta tiempo que se nota, sobre todo en el TTFB. Acortar el camino es la forma más directa de reducirlo.

Además de acercar archivos, casi todos los CDN hacen otras dos cosas: absorben picos de tráfico que tumbarían el servidor de origen, y filtran peticiones maliciosas antes de que lleguen. Para muchos sitios esa segunda función pesa tanto como la velocidad.

Conviene separarlo de dos cosas con las que se confunde. No es un alojamiento: el sitio sigue viviendo en un servidor de origen, y el CDN se pone delante. Y no es una copia de seguridad: si el origen desaparece, los nodos entregan lo que tengan guardado hasta que caduque, y después no hay nada.

Tampoco hace falta contratarlo como producto aparte. Muchos alojamientos lo incluyen, y algunos CMS lo activan con una casilla. Eso es cómodo y tiene una trampa: al no configurarlo uno mismo, es fácil no saber qué se está guardando ni durante cuánto tiempo, que son justo las dos preguntas que importan.

Aquí está el detalle que casi nunca se piensa: con un CDN delante, la respuesta ya no es una sola. Depende de desde dónde se pregunta, de si ese nodo tenía guardada una copia y de cuánto hace que la guardó.

Para el visitante eso suele ser bueno. Para quien mide, no siempre: el rastreador de Google pregunta desde otro sitio y en otro momento, así que puede recibir una versión distinta de la que ve tu clientela, más rápida o más lenta.

Google lo dice sin rodeos en su documentación sobre sitios multirregionales: la mayoría de sus rastreos salen de Estados Unidos y no varía la ubicación a propósito para detectar variaciones. Quien sirve contenido distinto según la región debe indicarlo con métodos explícitos, no confiar en que el buscador lo descubra.

Hay un tercer factor que cambia la respuesta y que no aparece en ningún panel: el momento. Un nodo que acaba de vaciar su copia responde lento a la primera petición y rápido a las siguientes, así que dos mediciones separadas por minutos pueden dar resultados opuestos sin que nada haya cambiado.

Por eso una sola comprobación no dice gran cosa. Los datos de campo de Search Console y de las herramientas de Core Web Vitals promedian visitas reales durante semanas, y por eso valen más aquí que cualquier prueba puntual hecha desde una sola ubicación.

Un CDN acelera lo que se puede guardar: imágenes, hojas de estilo, tipografías, archivos que no cambian entre visitantes. Eso mejora la parte de la carga que depende de la red, y con ella métricas como el LCP cuando el elemento grande es una imagen.

Lo que no acelera por sí solo es el tiempo que el servidor de origen tarda en construir una página. Si el HTML se genera de nuevo en cada petición, el CDN solo reenvía la pregunta y espera igual que esperaría el navegador. Por eso una tienda de e-commerce lenta por consultas pesadas no se arregla contratando un CDN.

Ahí está la confusión más extendida: se espera un efecto sobre los Core Web Vitals que solo llega si además se guarda el HTML en el propio nodo. Eso es posible y se hace, pero es una decisión aparte, con sus propias reglas sobre qué contenido puede compartirse entre visitantes y cuál no.

Merece la pena mirar también el lado móvil, porque es donde la distancia pesa más. En una conexión lenta, cada ida y vuelta cuesta bastante más que en fibra, así que acortar el camino se nota antes en móvil que en escritorio. Es un argumento a favor del CDN que casi nunca se menciona y suele ser el más sólido.

Y una precisión sobre las imágenes: muchos CDN las convierten y redimensionan al vuelo. Eso ayuda de verdad, pero es una función aparte de la distribución, y conviene comprobar que el resultado conserva el texto alternativo y las dimensiones declaradas en el HTML, porque si se pierden vuelve el salto de diseño que mide el CLS.

Lo primero es comprobar que las cabeceras sobreviven al paso por el nodo. Algunas configuraciones reenvían solo un conjunto conocido y descartan el resto, y entonces una instrucción como el X-Robots-Tag existe en el origen y no llega nunca al rastreador. Se comprueba pidiendo la URL pública, no la interna.

Lo segundo son los registros. Con un CDN delante, el servidor de origen deja de ver la mayoría de las peticiones, así que un análisis de logs hecho ahí queda incompleto; los registros útiles pasan a ser los del propio CDN.

Y lo tercero, las direcciones. Si los archivos estáticos pasan a servirse desde otro dominio, conviene mantener el certificado y las rutas estables, porque cada cambio de dominio arrastra referencias en el HTML antiguo, en enlaces externos y en el sitemap de imágenes.

Un cuarto punto que se olvida: las redirecciones. Muchos CDN permiten definirlas en el propio nodo, lo cual es rápido y cómodo, y con el tiempo produce dos listas de reglas —una en el CDN y otra en el origen— que nadie compara. Ahí nacen las cadenas de redirecciones más difíciles de encontrar, porque cada mitad parece correcta por separado.

Y un consejo sobre el orden de trabajo: documenta qué se guarda, durante cuánto tiempo y quién puede invalidarlo. Es una configuración que se toca una vez y se hereda durante años; sin esa nota, el siguiente que mire una página desactualizada buscará la causa en el CMS durante horas antes de sospechar del nodo.

El primero es contratarlo esperando que arregle una lentitud que no viene de la red. Si el origen tarda en responder, el CDN entrega antes las imágenes y el visitante sigue esperando el HTML.

El segundo es guardar lo que no debe guardarse. Una página con nombre de usuario, carrito o precios personalizados servida desde caché acaba mostrándole a alguien los datos de otra persona; es un fallo de privacidad, no de rendimiento, y ocurre más de lo que parece.

Y el tercero es olvidar la invalidación. Si el nodo conserva una versión antigua durante días, los cambios publicados no llegan ni a los visitantes ni al rastreador, y eso se diagnostica mal casi siempre: se busca la causa en el indexado cuando el contenido nuevo simplemente no se está entregando.

Un cuarto error es tratarlo como una decisión definitiva. Los nodos, las reglas y los planes cambian, y una configuración que era buena hace tres años puede estar guardando cosas que ya no debería. Merece una revisión anual, como cualquier otra pieza de infraestructura.

Y el último, el más silencioso de todos: no comprobar nunca desde fuera de la oficina. Todo el equipo trabaja desde la misma ciudad, con la misma conexión y probablemente con el mismo nodo caliente; la experiencia que se mide ahí es la mejor de todas las posibles. El tráfico real llega de sitios que nadie del equipo ha probado nunca.