¿Qué es un CDN y lo necesita tu web?

Un CDN (content delivery network o red de distribución de contenidos) es una red de servidores repartidos por muchas ubicaciones que guarda copias de los archivos de tu web y se las entrega a cada visitante desde un servidor cercano, en lugar de mandar todas las peticiones a tu hosting. Casi cualquier web pública con visitas desde más de una región, o con picos de tráfico, sale ganando con uno. Eso sí, un CDN no arregla por sí solo un código lento ni unas páginas pesadas, así que conviene entender qué hace exactamente antes de activarlo.

Cómo funciona un CDN

Sin CDN, cada visitante habla directamente con tu servidor de origen, la máquina de tu proveedor de hosting donde vive tu web. Si ese servidor está en Fráncfort y el visitante en Sídney, cada petición da la vuelta al mundo y regresa. Y si llegan mil personas a la vez, el origen tiene que responder a todas.

Con un CDN, los visitantes se dirigen a un servidor edge. El edge se sitúa entre el visitante y tu origen y funciona más o menos así:

1. Un visitante pide una página o un archivo.
2. El DNS lo envía a un servidor edge cercano.
3. Si el edge ya tiene una copia vigente, responde al instante. Esto es un cache hit (acierto de caché).
4. Si no, el edge pide el archivo a tu origen, lo entrega y se queda con una copia para el siguiente visitante. Esto es un cache miss (fallo de caché).

La primera petición de un archivo no es más rápida que antes. Todas las siguientes peticiones de ese mismo archivo, de cualquier persona cercana a ese edge, se pueden servir sin tocar tu origen. De ahí salen tanto la velocidad como el alivio para tu servidor.

Qué guarda en caché un CDN (y qué no debería)

Un CDN decide qué almacenar a partir de las cabeceras de respuesta de tu origen, sobre todo Cache-Control, y de las reglas que tú configures. La referencia de MDN sobre Cache-Control (en inglés) es el mejor sitio para consultar directivas como max-age, s-maxage, private y no-store.

Se puede cachear sin problema

• Imágenes, CSS, JavaScript y fuentes web
• Páginas HTML públicas que se ven igual para todo el mundo: artículos del blog, landing pages y, en la mayoría de tiendas, páginas de categoría y de producto
• Descargas como PDF

Tiene que saltarse la caché

• Carritos, checkout y páginas de pago
• Áreas de cliente y todo lo que se muestra a usuarios con sesión iniciada
• Páginas con datos personales, tokens de formulario o precios por usuario
• Zonas de administración como /wp-admin

Acertar con esta separación importa más que cualquier otro ajuste del CDN. Un CDN que cachea una página con sesión iniciada puede mostrar los datos de un cliente a otro. Los CMS y sistemas de tienda bien hechos marcan estas respuestas como privadas o ponen cookies que el CDN interpreta como señal para no cachear. Si tienes una tienda online, la guía para acelerar WooCommerce repasa qué páginas van en cada grupo.

Qué mejora un CDN

Time to First Byte

Cuando una página sale de la caché del edge, el visitante recibe el primer byte sin esperar a PHP, a una consulta a la base de datos ni a un hosting lento. Eso se nota en el TTFB (en inglés), para el que web.dev recomienda como referencia 0,8 segundos o menos. Nuestra guía para reducir el TTFB explica los ajustes en el servidor que complementan a un CDN.

Distancia y latencia

Cada ida y vuelta entre el navegador y el servidor cuesta tiempo, y la distancia física lo aumenta. Servir desde un edge cercano acorta cada viaje, y eso se acumula entre la consulta DNS, el handshake TLS y las muchas peticiones que hace una página.

Carga en tu origen

Los cache hits nunca llegan a tu servidor. Durante el envío de una newsletter, unas rebajas o una mención en redes sociales, tu hosting solo tiene que responder a los cache misses y a las peticiones dinámicas, así que es mucho menos probable que se ralentice en los picos de tráfico.

Seguridad y disponibilidad

Como todo el tráfico pasa por el edge, muchos CDN también filtran ataques allí, terminan el TLS y siguen sirviendo páginas cacheadas si el origen deja de responder un momento. Cuánto de esto obtienes depende del proveedor y del plan.

Qué no puede arreglar un CDN

Un CDN es una capa de entrega. Hace que las páginas buenas lleguen antes, pero no puede convertir una página pesada en una ligera.

• Páginas dinámicas lentas. El checkout, la búsqueda y las páginas con sesión iniciada se generan de nuevo cada vez. Si van lentas, la causa está en tu aplicación, tu base de datos o tu hosting.
• Front-ends pesados. Una imagen principal de 4 MB o un montón de scripts de terceros siguen pesando 4 MB y siguen teniendo que ejecutarse en el navegador. Esto se refleja en el LCP y el INP, no en el TTFB.
• Saltos de diseño. El CLS depende de cómo está construida la página, por ejemplo imágenes sin dimensiones o banners que cargan tarde.
• Una caché mal configurada. Si tu origen envía no-store en todo, o cada página crea una cookie de sesión, el CDN no cacheará nada y ganarás poco.

Si tu problema es uno de estos, la solución está en la página o en la aplicación. Un CDN sigue siendo útil en paralelo, pero no lo sustituye. La guía sobre las Core Web Vitals explica qué métrica apunta a qué causa.

¿Necesita tu web un CDN?

Un CDN suele merecer la pena si se cumple al menos uno de estos puntos:

• Tus visitantes llegan desde más de un país o continente.
• El TTFB de tus páginas públicas es alto, sobre todo lejos de tu hosting.
• Tu servidor sufre o se ralentiza en los picos de tráfico.
• Usas un CMS o una tienda donde la mayoría de visitas caen en páginas iguales para todos.
• Quieres tener la protección DDoS y el HTTPS resueltos por delante de tu hosting.

Importa menos si tu web es puramente local, muy pequeña, ya se sirve desde un hosting estático rápido cerca de tu público o es casi totalmente personalizada (por ejemplo, una herramienta interna detrás de un login). En esos casos, un hosting mejor o afinar la aplicación puede aportar más que un CDN.

Cómo comprobar que funciona

Antes de activar nada, mide. Pasa unas cuantas páginas públicas por corewebvitals.page y apunta el LCP y el resto de métricas, además de los datos de usuarios reales si Google tiene suficientes. La guía sobre cómo medir la velocidad de una web explica cómo montar una comparación justa de antes y después.

Cuando el CDN esté activo, revisa las cabeceras de respuesta de una página que debería estar en caché. Pídela dos veces:

curl -sI https://www.example.com/ | grep -i -E 'cache|age'

La primera petición suele ser un miss. La segunda debería mostrar un hit en la cabecera de caché del proveedor y una edad (age) que va aumentando. Si todas las peticiones siguen siendo miss o bypass, revisa Cache-Control y Set-Cookie en la respuesta del origen. Después repite tus mediciones desde varias ubicaciones y compara.

Cómo te ayuda fast.site

fast.site se coloca delante de tu hosting actual, así que mantienes tu proveedor y tu CMS. Añades tu dominio en el panel, cambias tus servidores de nombres a fast.site y lo verificas. La propagación se comprueba automáticamente y fast.site pasa a gestionar el DNS del dominio.

De la caché se encarga Fast Edge Cache™. En un miss, el edge pide la página a tu origen y guarda una copia; en un hit, responde sin contactar con tu servidor. La caducidad sigue las cabeceras Cache-Control de tu origen o tus propias reglas, y los carritos, el checkout y las sesiones iniciadas se saltan la caché. La cabecera de respuesta fs-cache muestra HIT, MISS o BYPASS, así que puedes comprobar cada página tú mismo. Puedes vaciar la caché por URL en el panel o mediante la API, y un cache warmer mantiene precargadas las páginas importantes.

GeoDNS dirige a los visitantes al edge disponible más cercano en Norteamérica, Europa, Asia-Pacífico o Sudamérica, según tu plan. Cada dominio incluye además detección automática de ataques DDoS de capa 7 y certificados SSL gratuitos que se renuevan solos. Encontrarás los detalles en la documentación de caché y en la página de funciones.

Mide tu propia web antes y después. Puedes empezar con una prueba gratuita de 7 días, sin tarjeta de crédito. Compara los planes en la página de precios.

Preguntas frecuentes

¿Un CDN sustituye a mi hosting?

No. Tu web sigue alojada en tu hosting, que continúa siendo el origen. El CDN se coloca delante y sirve copias en caché, pero todo lo dinámico, como el checkout, lo sigue generando tu servidor.

¿Un CDN es bueno para el SEO?

De forma indirecta, puede serlo. Google tiene en cuenta señales de experiencia de página como las Core Web Vitals, y un CDN puede mejorar los tiempos de carga, sobre todo el TTFB y, como consecuencia, a menudo el LCP. No garantiza mejores posiciones, porque el contenido y la relevancia pesan mucho más.

¿Un CDN puede hacer mi web más lenta?

Sí, si está mal configurado. Si el CDN deja pasar casi todas las peticiones sin cachear, cada una da un salto extra por el edge hasta tu origen. Revisa las cabeceras de caché después de la configuración y asegúrate de que las páginas públicas generan hits de verdad.

¿Necesito un CDN si todos mis visitantes están en un solo país?

Por la distancia no necesariamente, pero a menudo sí por la carga y la protección. Si tu hosting está cerca de tu público y aguanta bien los picos, la ganancia es menor. Si los picos de tráfico ralentizan tu servidor, la caché en el edge sigue ayudando.

¿Un CDN puede romper mi tienda o el login?

No, si las páginas dinámicas se saltan la caché. Los carritos, el checkout y las cuentas de cliente nunca deben cachearse para todos. Prueba estos flujos tras la configuración, con y sin sesión iniciada, y confirma que la cabecera de caché muestra un bypass en ellos.