Cómo funciona un CDN y cuándo lo necesitás
En pocas palabras: Una CDN copia el contenido estático de tu sitio (imágenes, CSS, JavaScript) en servidores repartidos por el mundo y lo entrega desde el nodo más cercano al visitante. Resultado: la latencia baja, el origen recibe menos carga y una página puede pasar de 3 segundos a menos de 1.
Poné que tu web está alojada en un servidor en Estados Unidos y alguien la abre desde Buenos Aires. Sin CDN, cada imagen, cada CSS y cada script viaja hasta allá y vuelve. Una CDN mete servidores intermedios cerca del usuario y acorta ese viaje, con lo que la carga baja.
Si alguna vez esperaste tres segundos a que cargara una página con muchas fotos, ya sabés de qué hablamos. La distancia física entre el visitante y el servidor cuesta tiempo, y ese tiempo se traduce en gente que se va antes de leerte.
Una CDN (Content Delivery Network, o red de distribución de contenidos) es una red de servidores repartidos en distintas ubicaciones geográficas que guardan copias del contenido de tu sitio y lo entregan desde el nodo más cercano a cada usuario. No ejecuta tu aplicación ni reemplaza al hosting: es una capa de entrega que se interpone entre el navegador y tu servidor de origen para reducir latencia y descargar trabajo del origen.
En 30 segundos
- Qué es: una red de servidores distribuidos (edge servers) que sirven copias de tu contenido desde el punto más cercano al usuario.
- Qué gana tu sitio: menos latencia. Cuando el contenido ya está cacheado en un nodo cercano, el pedido no tiene que viajar hasta el origen y la respuesta llega antes.
- Qué cachea: contenido estático (imágenes, CSS, JavaScript, video). El dinámico (APIs, páginas autenticadas) suele ir igual al origen.
- No es hosting: el hosting corre tu app, la CDN acelera la entrega. Trabajan juntos.
- Bonus de seguridad: al posicionarse delante del origen, filtra tráfico y ayuda a mitigar ataques DDoS.
¿Cómo funciona una CDN entre tu navegador y el servidor?
Cuando un usuario pide tu URL, la CDN decide desde qué nodo servirle usando técnicas como el ruteo por DNS, Anycast y balanceo de tráfico global. La idea: mandar el pedido al edge server más cercano en vez de al origen. Si ese nodo ya tiene el archivo guardado, lo entrega ahí mismo. Si no, va a buscarlo una sola vez. Lo explicamos a fondo en soluciones de hosting en nube.
Acá aparecen dos conceptos que conviene tener claros:
- Cache hit: el nodo ya tiene una copia fresca del recurso y lo sirve al toque, sin tocar tu servidor. Es el escenario ideal.
- Cache miss: el nodo no tiene el archivo (o venció), lo pide al origen, lo entrega y se guarda una copia para el próximo. El primer visitante paga el viaje largo, los demás no.
- TTL (time to live): el tiempo que un archivo queda cacheado antes de considerarse viejo. Vos lo configurás con cabeceras HTTP. Un TTL alto es más rápido pero tarda más en reflejar cambios.
Como lo explica el análisis publicado en dev.to, la parte interesante no es la definición sino lo que pasa después de que el usuario toca tu URL: la CDN se vuelve una capa de entrega que decide, pedido por pedido, si contesta ella o si molesta al origen.
¿Qué contenido cachea una CDN y qué no?
Una CDN cachea sobre todo contenido estático: imágenes, hojas de estilo CSS, archivos JavaScript, fuentes, videos y descargas. Todo lo que es igual para cualquier visitante y no cambia entre un pedido y otro. Ese material se copia en los nodos y se sirve sin volver al origen.
El contenido dinámico es otra historia. Las respuestas de una API, un carrito de compras, un panel autenticado o cualquier página personalizada por usuario cambian según quién pregunta. Por defecto eso no se cachea, porque servir la copia de otro sería un desastre (imaginá ver el carrito de un desconocido).
Eso sí: las CDN modernas tienen trucos para el dinámico, como cachear fragmentos, respetar cabeceras de variación o usar reglas por ruta. Pero la regla general sigue firme: estático se cachea agresivo, dinámico pasa al origen salvo que vos digas lo contrario.
¿Cuánta velocidad gano realmente con un CDN?
La ganancia depende de dónde está tu audiencia respecto del origen. Si tu servidor está en EE.UU. y tus lectores en Sudamérica, la mejora es enorme porque cada round trip cruzaba medio continente. Si tu servidor y tus usuarios están en la misma ciudad, la diferencia es marginal. En solucionar problemas de servidor profundizamos sobre esto.
El punto es que más distancia significa más saltos de red y más idas y vueltas, y cada ida y vuelta suma latencia. Una CDN corta esa cadena. Y esto pega directo en los Core Web Vitals: un LCP más bajo mejora la experiencia y, de rebote, ayuda al SEO, porque Google usa esas métricas de campo como señal.
| Escenario | Sin CDN | Con CDN (cache hit) |
|---|---|---|
| Latencia AR → origen EE.UU. | Alta (viaje completo al origen) | Baja (respuesta desde el nodo cercano) |
| Carga sobre el servidor origen | Alta (cada pedido llega) | Baja (solo cache miss) |
| Resistencia a picos de tráfico | Limitada | Alta (se reparte en nodos) |
| Contenido estático repetido | Se re-descarga del origen | Se sirve desde el edge |
La tabla muestra órdenes de magnitud típicos, no una promesa. Medí tu caso real con una herramienta de campo antes de cantar victoria (tomalo con pinzas).
¿Cuándo necesitás un CDN para tu sitio?
Un CDN te conviene cuando tu audiencia está repartida geográficamente, cuando servís contenido pesado como imágenes o video, cuando tenés tráfico alto o cuando querés que el sitio aguante picos sin caerse. Cualquiera de esas cuatro situaciones ya justifica probarlo.
¿Y cuándo no vale tanto la pena? Si tenés un sitio chico con visitantes locales, cerca del servidor, la mejora es mínima y quizá no compense la complejidad extra. Tampoco es magia: si tu backend es lento generando páginas dinámicas, el CDN no lo arregla, porque ese trabajo sigue cayendo en el origen. Relacionado: arquitectura cloud en DevOps.
Si estás montando la infraestructura desde cero para un público argentino, tener el hosting cerca de tus usuarios ya es medio camino andado. En donweb.com podés alojar el sitio en la región y sumarle la capa de CDN encima cuando el tráfico lo pida.
¿Cómo te protege un CDN de ataques?
Al posicionarse entre los usuarios y tu origen, la CDN se convierte en un filtro. El servidor real queda escondido detrás de los nodos, así que un atacante no le pega directo. Eso reduce la exposición y da margen para absorber tráfico malicioso antes de que llegue a tu infraestructura.
Las plataformas grandes suman a esto mitigación de DDoS (distribuyen el ataque entre muchos nodos), un WAF (Web Application Firewall) para bloquear pedidos sospechosos, y gestión de bots. ¿Reemplaza a tu seguridad de aplicación? No. Pero es una primera línea que te saca presión de encima.
CDN vs hosting: ¿cuál es la diferencia real?
El hosting ejecuta tu aplicación: corre el código, consulta la base de datos, arma la página. La CDN no hace nada de eso. Solo guarda copias de lo que ya generó tu sitio y lo entrega más rápido y más cerca. Son dos capas distintas que se complementan.
Pensalo así: subís tu web al hosting (el origen), y el CDN es la red de reparto que lleva las copias a todo el mundo. Sin hosting no hay sitio. Sin CDN, hay sitio pero más lento para el que está lejos. La mayoría de los proyectos serios usan los dos juntos. Para más detalles técnicos, mirá configurar servidores DNS correctamente.
Errores comunes sobre las CDN
- Creer que reemplaza al hosting: no ejecuta tu app. Si apagás el origen, el contenido dinámico y los cache miss se caen. La CDN acelera, no aloja.
- Pensar que cachea todo automágicamente: el dinámico no se cachea por defecto. Si esperabas que tu API volara sola, te vas a llevar una sorpresa.
- Asumir mejora igual para todos: la ganancia depende de la distancia entre tu audiencia y el origen. Público local pegado al servidor gana poco.
- Olvidarse del TTL y la purga: si actualizás un CSS pero el nodo lo tiene cacheado con TTL largo, el usuario ve la versión vieja hasta que purgues la caché. Muchos “no se aplican mis cambios” son esto.
Preguntas Frecuentes
¿Qué es un CDN y cómo funciona?
Un CDN es una red de servidores distribuidos geográficamente que guardan copias del contenido de tu sitio y lo sirven desde el nodo más cercano a cada usuario. Funciona interceptando los pedidos: si el nodo tiene el archivo cacheado, lo entrega al instante; si no, lo busca en tu servidor origen una sola vez y lo guarda para los próximos.
¿Cuánta velocidad gano si uso un CDN?
La ganancia depende de la distancia entre tu audiencia y el servidor origen. Un pedido desde Argentina a un origen en EE.UU. cruza mucha más distancia, así que cuando el contenido está cacheado en un nodo local la respuesta llega bastante antes. Si tus usuarios están cerca del origen, la mejora es marginal.
¿Cuál es la diferencia entre CDN y hosting?
El hosting ejecuta tu aplicación (corre el código, arma las páginas), la CDN solo distribuye copias del contenido ya generado. El hosting es indispensable; la CDN es una capa de aceleración opcional que se apoya sobre él. Trabajan juntos, no son alternativas.
¿Necesito un CDN para mi sitio web?
Lo necesitás si tu audiencia está repartida geográficamente, si servís imágenes o video pesado, o si manejás tráfico alto y picos. Si tenés un sitio chico con visitantes locales cerca del servidor, la mejora es mínima y podés esperar a tener volumen antes de sumarlo.
¿Cómo se cachea el contenido en un CDN?
El contenido se cachea en el primer pedido (cache miss): el nodo lo busca en el origen, lo entrega y guarda una copia. Los siguientes usuarios reciben esa copia directo del nodo (cache hit). Cuánto dura la copia lo define el TTL, que configurás con cabeceras HTTP; cuando vence o purgás, el nodo vuelve a buscar la versión fresca.
Conclusión
Un CDN no acelera por arte de magia: acorta el viaje físico entre tu contenido y tus usuarios cacheando lo estático en nodos cercanos. Si tu audiencia está lejos del origen o servís mucho peso, la diferencia en latencia es real y pega en tus Core Web Vitals.
Lo que tenés que hacer concreto: identificá dónde está tu público, medí tu latencia actual, y evaluá sumar la capa de CDN sobre tu hosting. Configurá bien el TTL, acordate de purgar cuando actualices, y no esperes que resuelva un backend lento. Es una herramienta de entrega, y usada donde corresponde, zafa de sobra.
