¿Qué es una CDN?

Una CDN es una red de servidores distribuidos que guarda contenido en caché cerca de los usuarios, para que páginas y archivos carguen rápido donde sea. El problema que resuelve es la física: una solicitud de São Paulo a un servidor en Frankfurt paga el viaje de ida y vuelta en latencia, todas las veces. Con una CDN, la respuesta sale desde São Paulo — y una aclaración ahorra confusión sin fin: complementa tu hosting, nunca lo reemplaza.

Puntos clave

Los controles que hacen que funcione

El contrato completo de caché cabe en un solo header HTTP — y es justo la pieza menos explicada de toda guía sobre CDN:

# La instrucción del origen para todo caché entre él y el usuario:
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600

  public                  → cualquier caché puede almacenar esto
  max-age=300             → navegadores: fresco por 5 minutos
  s-maxage=86400          → edges de la CDN: fresco por 24 horas
  stale-while-revalidate  → sirve lo stale al instante, refresca en segundo plano

# La otra estrategia: nunca expirar, nunca purgar — versiona el nombre del archivo
/_assets/app.3f9c1b.css   → caché "para siempre"; un build nuevo significa una URL nueva

De dónde salen los archivos en tu app también importa — en un backend gestionado, una subida devuelve una URL lista para la entrega, con la historia de caché ya sensata de fábrica:

// JavaScript / Node.js — Back4app JS SDK
// Upload once; the returned URL serves from edge cache worldwide
const file = new Parse.File('hero.webp', { base64: imageData });
await file.save();
console.log(file.url()); // CDN-backed, cache-friendly URL

// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL

// iOS / Swift — Back4app Swift SDK
let file = ParseFile(name: "hero.webp", data: imageData)
file.save { result in
  if case .success(let saved) = result {
    print(saved.url ?? "") // CDN-backed, cache-friendly URL
  }
}

// Android / Kotlin — Back4app Android SDK
val file = ParseFile("hero.webp", imageBytes)
file.saveInBackground { e ->
  if (e == null) Log.d("CDN", file.url) // CDN-backed, cache-friendly URL
}

Anatomía de una solicitud

El vocabulario de una sola pasada: el origen es tu servidor de verdad — la fuente de la verdad. Un PoP (punto de presencia) es una ubicación de data center de la CDN; los servidores de edge son las máquinas de caché dentro de él. El cache-hit ratio — la fracción de solicitudes respondidas sin tocar el origen — es la métrica que todo el ejercicio optimiza, y las palancas son los headers de arriba. Lo que mejora para el usuario es el TTFB (tiempo hasta el primer byte) y, cuando las páginas completas se cachean en el edge, las métricas de carga que se desprenden de él.

CDN vs. hosting web vs. edge computing

La definición de MDN agrega la salvedad que las páginas de proveedores omiten: los scripts de CDN de terceros son una dependencia de supply chain (los atributos de integrity existen por algo), y un lookup extra de DNS hacia la CDN puede incluso costar tiempo en la primera visita — palanca, no magia.

Casos de uso comunes

• Assets estáticos a escala. CSS, JavaScript, fuentes, imágenes — nombres de archivo con fingerprint más TTLs largos convierten las visitas repetidas en tráfico puro de edge.
• Media y descargas. Segmentos de video y archivos grandes, donde el ancho de banda del origen sería la factura y el cuello de botella.
• Audiencias globales. La misma página servida en menos de 100 ms en cuatro continentes, sin operar servidores en cuatro continentes.
• Picos de tráfico y lanzamientos. El edge absorbe la ola; el origen ve una fracción de ella.
• Postura de seguridad. Origen escondido detrás de un reverse proxy, TLS terminado en el edge, ataques volumétricos disipados por la red.

¿Necesitas una CDN? Matriz de decisión

La fila honesta que nadie imprime: en un sitio de poco tráfico, las copias en caché expiran entre un visitante y otro, cada solicitud es un miss, y la CDN agrega un salto por nada. Distancia y volumen son los insumos; sin ninguno de los dos, arregla otra cosa primero.

Limitaciones y trade-offs

• El contenido viejo es la falla por defecto. TTLs largos significan el archivo de ayer servido con confianza hoy; la cura es el purge (lento, varía por CDN) o los nombres de archivo versionados (mejor).
• La invalidación de caché es genuinamente difícil. Es uno de los dos famosos problemas difíciles por algo — diseña las URLs para que rara vez la necesites.
• El contenido dinámico se resiste al caché. Las respuestas por usuario no pueden compartirse; la aceleración y la lógica de edge ayudan, pero el origen sigue haciendo el trabajo.
• Una dependencia en el camino crítico. Las caídas de CDN son eventos de clima de internet; cuando el edge se cae, “tu” sitio se cae.
• Depurar gana una capa. ¿Qué caché sirvió esto? ¿Con qué headers? Los headers de cache-status y el comportamiento por edge pasan a ser parte de tu superficie de observabilidad.

CDNs en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La historia de CDN viene integrada en la capa de archivos: sube por cualquier SDK (las pestañas de arriba) y la URL devuelta ya está lista para la entrega — estable, cacheable e independiente del tráfico dinámico de tu API, lo que mantiene las mitades cacheable y no cacheable de tu app limpiamente separadas. Los frontends web alojados en Back4app Containers se asientan con naturalidad detrás de cualquier CDN, con el patrón clásico — assets con fingerprint de vida larga, HTML de vida corta — configurado en un solo header.