Decide qué debe entregar la CDN
Comienza con un inventario. Separa los activos versionados como imágenes, hojas de estilo, scripts, fuentes y descargas del HTML, las APIs, las páginas de cuenta, el checkout y la administración. Las CDN suelen llenar una caché bajo demanda: la primera solicitud puede llegar al origen, mientras que solicitudes que coincidan después pueden servir desde el edge. Un edge cercano y un acierto de caché son beneficios distintos.
Registra el host, la aplicación, el bucket de almacenamiento o el balanceador de carga que suministra cada ruta; debe responder a un cache miss.
Empieza con activos idénticos para todos los visitantes que puedan permanecer disponibles de forma segura hasta que venza su tiempo de vida declarado.
No compartas paneles personalizados, páginas vinculadas a sesión o datos de clientes a menos que un ingeniero cualificado haya diseñado y probado la separación.
Define la política de caché a partir del comportamiento del contenido
Las cabeceras de respuesta HTTP (por ejemplo, Cache-Control) expresan el comportamiento de caché. Cache-Control indica si una respuesta puede almacenarse y cuánto tiempo permanece fresca; un time to live, o TTL, es ese periodo de frescura. Un navegador es una caché privada, mientras que una CDN suele ser compartida. Usa cabeceras explícitas. El estándar HTTP permite que s-maxage fije la vida útil de caché compartida por separado de max-age.
Publica una URL nueva cuando el contenido cambie, por ejemplo un nombre de archivo con hash de contenido, y da a la versión inmutable una larga vida útil documentada.
Elige una vida útil corta o un comportamiento de validación según el coste del contenido obsoleto; no reutilices una regla de activo para precios, inventario o estado de cuenta.
Usa private para respuestas destinadas a un solo usuario. Una cookie por sí sola no hace que una respuesta sea segura para una caché compartida.
Haz que la invalidación sea una excepción, no el plan de lanzamiento
La invalidación, o purga, dice a una CDN gestionada que elimine objetos almacenados seleccionados antes del vencimiento normal. Úsala para correcciones, no en cada despliegue. Confirma que el origen ya devuelve el reemplazo antes de purgar; de lo contrario, un refill puede preservar la respuesta mala. Las cachés del navegador están fuera del control de purga de la CDN, así que el versionado de URL sigue siendo confiable para archivos cambiantes.
Prefiere una ruta específica, un grupo de lanzamiento o una etiqueta de caché soportada por el proveedor en lugar de una purga de todo el sitio; los misses amplios pueden cargar repentinamente el origen.
Una purga distribuida puede no alcanzar todos los edge al mismo tiempo. Revisa la semántica de finalización del proveedor y prueba una URL representativa.
Registra la URL antigua y la nueva, la regla de caché, el alcance de la purga, el resultado esperado y el paso de reversión.
Mantén el origen detrás de la capa de entrega
El acceso directo al origen puede evitar el cacheo de la CDN y los controles del edge. Restringe el acceso para que la CDN, y solo las rutas previstas, puedan alcanzarlo. Dependiendo de tu stack, usa control de acceso de origen en la nube, reglas de firewall con rangos de egress del CDN documentados, redes privadas, solicitudes firmadas al origen o mutual TLS (mTLS), donde ambos lados se autentican con certificados.
Desde una ubicación de prueba autorizada, confirma que el origen rechaza solicitudes públicas mientras el hostname de la CDN funciona.
Limit a las comprobaciones de salud, herramientas de despliegue y accesos internos por identidad y red en lugar de una regla pública amplia.
La autenticación al origen difiere según CDN y origen. Usa la guía de configuración actual del proveedor y una revisión de seguridad.
Trata TLS como dos conexiones
HTTPS en el edge protege la conexión visitante→CDN, pero la conexión CDN→origen también necesita protección. Exige cifrado en ambas piernas, valida el certificado del origen según el modo del CDN y asigna la propiedad del hostname y la renovación. OWASP recomienda TLS 1.3 por defecto y permite TLS 1.2 para compatibilidad; indica que TLS 1.0 y 1.1 deben deshabilitarse. Obtén revisión cualificada para datos regulados, flujos de pago o compatibilidades de cliente inusuales.
Lista los propietarios de certificados del edge y del origen, rutas de renovación y la respuesta ante fallo.
Prueba HTTP→HTTPS, canonical-host y redirecciones profundas para detectar bucles o pérdida de rutas.
El cifrado no hace que una respuesta sea segura para cachear; configura reglas de caché por separado para páginas autenticadas, personales y relacionadas con pagos.
Prueba la ruta real de entrega antes de cambiar el tráfico
Comienza en un hostname de staging o en una ruta de producción estrecha, y luego prueba el hostname de la CDN, no solo el origen. Chrome DevTools Network muestra estado, dominio, tiempos, tamaño y cabeceras de la solicitud. Haz una recarga completa con caché vacío para aproximar una primera visita, luego una visita repetida para inspeccionar la reutilización. Compara cabeceras y contenido esperados, no solo una página que parezca más rápida. Repite desde regiones representativas cuando la audiencia esté distribuida.
Inspecciona Cache-Control y las cabeceras cache-status del proveedor. Confirma que los activos públicos se reusan y que las páginas sensibles no se comparten inesperadamente.
Ejercita un miss, corrección de contenido obsoleto, error de origen y reversión de un activo o ruta antes de un lanzamiento amplio.
Guarda URLs probadas, capturas de cabeceras, versión de la regla de ruta y tiempos antes/después con el registro de cambios.
Elige una CDN según necesidades operativas y luego pruébala
No elijas una CDN únicamente por el número de puntos de presencia o una afirmación genérica de velocidad. El rendimiento varía con geografía, hora, distribución del tráfico, enrutamiento y ratio de aciertos de caché. Compara candidatos en rutas, activos y regiones representativas. Pregunta si cada uno soporta tus controles de caché necesarios, invalidación dirigida, restricción de origen, flujo de certificados, logs, roles de acceso, precios, soporte y proceso de cambio.
Usa cabeceras de caché idénticas, comportamiento del origen y páginas iguales para los candidatos; registra resultados de primera visita y de visita repetida por separado.
Revisa costes de petición, transferencia, invalidación, logging y soporte, además de un pico por cache-miss. Precios y controles varían por plan.
Exige configuración exportable, principio de menor privilegio, reversión probada y propiedad clara antes de cubrir rutas críticas.