Cuándo un CDN ayuda y cuándo no

El CDN es una de las mejores tecnologías que tiene la web. También es una de las que peor se explican en la publicidad, porque se vende como si fuera teletransportación: «ponle CDN y tu sitio queda cerca de todo el mundo».

No es eso. Un CDN acerca algunas cosas a tus visitantes. Otras siguen viajando exactamente la misma distancia que antes. Y saber cuáles son cuáles decide si tu inversión en velocidad va a servir de algo.

Metodología de todas las cifras de este artículo. Mediciones del 30 de agosto de 2026, desde Bogotá, sobre red INTERNEXA (AS18678), por ruta pública de internet. Para el ping, RTT mínimo; para el TTFB, el mejor de 3 a 5 intentos. Es el punto de vista de un visitante colombiano, no el de un servidor midiéndose desde dentro de un datacenter. La clasificación de dominios es un censo propio, hecho por el sistema autónomo que anuncia cada prefijo en BGP.

Qué hace un CDN, en una frase

Un CDN (content delivery network) guarda copias de tus archivos en muchos puntos de presencia repartidos por el mundo, y entrega cada petición desde el punto más conveniente para quien la pide.

La palabra clave es copias. Un CDN copia. Y solo se puede copiar lo que es igual para todos.

Lo que el CDN sí acelera

Todo lo que es idéntico para cualquier visitante y no cambia entre una visita y otra:

• Imágenes: fotos de producto, banners, logos, iconos.
• CSS y JavaScript: los archivos del tema y de los plugins.
• Tipografías.
• Video y descargas: PDFs, catálogos, instaladores.
• Páginas estáticas que no cambian por usuario: un artículo de blog, una página institucional, unos términos y condiciones.

En un sitio de contenido —un blog, un medio, una página de portafolio— eso puede ser la mayor parte de los bytes que viajan. Ahí el CDN es un negocio redondo: baja el peso que sale del origen, alivia el servidor y mejora la experiencia de visitantes en otros países.

Y hay un beneficio extra que no es de velocidad y sí de tranquilidad: el CDN absorbe picos y ataques. Si te llega una avalancha de tráfico, la aguanta él y no tu origen.

Lo que el CDN no acelera

Todo lo que es distinto para cada visitante, o lo que cambia en el momento. Eso no se puede copiar por adelantado, así que el CDN no tiene nada guardado y va a preguntarle a tu servidor de origen. Cada vez.

En un WordPress con tienda, esto es casi todo lo que importa:

• El login. El usuario y la contraseña van al origen, sí o sí.
• El carrito. Tu carrito no es el mío. No hay copia posible.
• La búsqueda interna. Cada consulta es distinta.
• El checkout completo: cálculo de envío, cupones, impuestos, pasarela de pago.
• El panel de administración. Cuando tú editas una entrada, estás hablando con el origen, con toda la latencia encima.
• Cualquier página con contenido personalizado: «Hola, Andrea», precios por cliente, inventario en vivo, un formulario con token de seguridad.

Y hay tres cosas que ni siquiera entran en la conversación del CDN, porque no viajan por él: la base de datos, el correo y el FTP. Esas hablan con el origen siempre.

En WooCommerce, además, hay una regla de comportamiento que conviene tener presente: en cuanto el visitante tiene una sesión abierta —porque agregó algo al carrito, o se autenticó— el sitio empieza a marcar sus respuestas como no cacheables. Y con razón: cachear la página de otro cliente sería una fuga de datos. Pero el efecto práctico es que entre más cerca está tu visitante de comprar, menos lo protege el CDN.

Cuenta de servilleta, marcada como tal: el número de viajes es un supuesto, no una medición. Si un checkout necesita doce idas y vueltas al origen, con el origen a 96,3 ms eso son 1,16 segundos de puro viaje; con el origen a 16,9 ms, 0,20 segundos. El CDN no cambia ninguno de los dos números, porque en ese tramo no está participando.

Un borde cercano no es un servidor cerca. Y está medido

Esta es la parte que casi nunca aparece en las comparativas, y es la que se puede comprobar en treinta segundos con curl.

El ping mide hasta el borde del CDN. El TTFB —tiempo hasta el primer byte del HTML— mide hasta donde de verdad se genera tu página. Cuando el HTML no se cachea, el segundo número es el que sufre tu cliente.

TTFB del HTML, mejor de 3 a 5 intentos, 30 de agosto de 2026, desde Bogotá:

Los tres de abajo tienen un borde de CDN que responde cerca. El HTML, aun así, tarda tres veces más.

Y hay una prueba que no depende de nuestra interpretación: uno de esos sitios devuelve en su propio HTML la cabecera cf-cache-status: DYNAMIC. Es el CDN declarando por sí mismo que no está sirviendo esa página desde caché. En la misma sesión, ese mismo sitio midió 65,3 ms de RTT hasta el borde y 338,9 ms de TTFB del servicio. El ping halaga; el servicio no.

De ahí la frase que resume el artículo entero:

Un borde cercano acelera las imágenes; no acerca el servidor.

Esto vale también para los casos que parecen excepciones. Hay proveedores internacionales cuya capa estática responde en Colombia tan rápido como un origen local — y eso no los convierte en infraestructura colombiana: su origen sigue estando afuera, y ahí es donde se arma tu checkout. Espejo cerca, origen lejos.

El dato colombiano que conviene verificar

Hay un supuesto extendido: «tengo CDN, entonces mi sitio se sirve desde Bogotá». Vale la pena comprobarlo, porque medido no es así.

El 95% de los sitios colombianos que usan Cloudflare se sirven desde el punto de presencia de Miami, no desde el de Bogotá. Miami midió alrededor de 69 ms desde Bogotá.

Setenta milisegundos es una mejora enorme frente a un origen en São Paulo (168–180 ms) o en Ashburn, Virginia (96,3 ms). El CDN está haciendo su trabajo y lo está haciendo bien. Pero 69 ms no es lo mismo que 16,9 ms, que es lo que mide un origen en Colombia desde Bogotá. El CDN reduce la penalización; no la borra.

Y conviene ser preciso sobre el porqué: que exista un punto de presencia en una ciudad no garantiza que tu tráfico caiga ahí. La asignación depende de cómo esté conectado tu operador, de las rutas anunciadas y del plan del servicio. Nosotros medimos el resultado, no las razones internas de un tercero. El resultado, en Colombia, es Miami en 95 de cada 100 casos.

Para dimensionarlo: de 1.352 dominios colombianos de nuestro censo, clasificados por el AS que anuncia cada prefijo, 559 están detrás de un CDN — y solo el 11% del total se sirve desde infraestructura físicamente colombiana. La mayoría de los sitios con nombre colombiano se atiende, en el mejor de los casos, desde Miami.

Cómo saber qué te está pasando a ti

Cinco comprobaciones, sin herramientas raras:

1. Mira la cabecera de caché. Abre las herramientas de desarrollador del navegador, pestaña Red. En la respuesta busca cf-cache-status (o el equivalente de tu CDN). HIT = lo entregó el CDN. MISS o DYNAMIC = fue hasta tu origen. Pruébalo primero en una imagen y después en el HTML de la portada: casi siempre no dicen lo mismo.
2. Mide el TTFB, no el ping. curl -o /dev/null -s -w "%{time_starttransfer}\n" https://tudominio.com. Compara la portada contra el carrito o el login. Si la diferencia es grande, ya sabes cuál de los dos está viajando.
3. Mira dónde te atienden. Muchos CDN publican una URL de diagnóstico que dice el código de aeropuerto del punto de presencia que te atendió. Si dice MIA, estás saliendo por Miami.
4. Repite con sesión iniciada. Es fácil probar el sitio sin haber entrado. Prueba logueado: ahí es donde vive tu cliente que compra.
5. Mide desde Colombia. Las herramientas públicas de velocidad suelen medir desde Norteamérica o Europa y te dan un número que tu cliente de Bucaramanga nunca va a ver.

La combinación que sí funciona

Esto no es «CDN o servidor cerca». Es CDN encima de un origen cerca, en ese orden:

• El origen define tu piso. Es el número que paga todo lo dinámico: login, carrito, búsqueda, checkout, administración, base de datos, correo, y cualquier MISS de caché. Ese piso solo se mueve moviendo el servidor.
• El CDN define tu techo de escala. Descarga lo estático, absorbe picos, te protege y le mejora la vida a los visitantes que están lejos.

Un origen en Colombia con CDN encima gana en las dos: lo estático sale del punto de presencia, y lo dinámico —que es donde ocurre la venta— hace un viaje de 16,9 ms en vez de 96,3 ms, o de 168–180 ms.

Un origen en São Paulo (168–180 ms) con CDN encima tiene un sitio de contenido que se siente rápido y un checkout que se siente pesado. Es el patrón previsible: la prueba de velocidad mide la portada, y la venta ocurre en el checkout.

Conclusión

El CDN es buena tecnología. No es teletransportación.

Acerca las copias. Lo único de tu sitio —tu carrito, tu sesión, tu inventario, tu venta— sigue yendo a buscar el origen, y el origen está donde tú lo pusiste.

Ponlo cerca. Y ponle el CDN encima.