Capítulo 8: CDN y Caché¶
Diagramas del capítulo¶
D-041 - CDN mundial
D-042 - Cache Hit
D-043 - Cache Miss
Cómo Internet entrega contenido en milisegundos¶
Objetivos del capítulo¶
Al finalizar este capítulo, serás capaz de:
- Explicar qué es una CDN, cómo funciona y por qué el 82% de los sitios web del mundo la utilizan en 2026.
- Comprender el problema físico de la latencia y cómo las redes de distribución de contenido lo resuelven mediante PoPs y Anycast.
- Configurar correctamente los headers
Cache-Controlpara distintos tipos de recursos: estáticos versionados, HTML dinámico, APIs, credenciales y datos de sesión. - Distinguir entre los diferentes tipos de caché (navegador, DNS, HTTP, CDN, servidor, aplicación, base de datos) y saber cuándo usar cada uno.
- Implementar estrategias de caché en Cloudflare usando Cache Rules, Smart Tiered Cache y Cache Reserve.
- Elegir entre compresión Gzip y Brotli según el tipo de contenido y el contexto de uso.
- Diseñar una estrategia completa de caché y CDN para una plataforma educativa real como elprofe.org.
Introducción¶
Imagina que abres una tienda de pizza en la Ciudad de México. Tu pizza es extraordinaria: ingredientes frescos, masa perfecta, horneada al instante. El problema es que tienes un solo local, en Reforma y Juárez. Un cliente en Monterrey quiere tu pizza. Puede pedirla, claro, pero llegará fría, aplastada y después de dos horas de camino. Otro cliente en Madrid la pide también. Para cuando llegue a Europa, ya no será pizza: será un recuerdo arqueológico de lo que alguna vez fue masa con queso.
La solución no es magia ni teletransportación. Es abrir sucursales. Prepararás la receta una vez, la distribuirás a sucursales estratégicas en Monterrey, Miami, Madrid, Tokio, y cada cliente recibirá su pizza fresca, caliente, en minutos. Eso, exactamente, es lo que hace una CDN.
Hasta este punto del libro has aprendido cómo los paquetes de datos viajan por Internet (capítulo 1), cómo el DNS convierte nombres de dominio en direcciones IP (capítulo 4), cómo el servidor web recibe y responde peticiones HTTP (capítulo 5), qué sucede dentro de una conversación HTTP (capítulo 6) y cómo TLS cifra esa conversación para que nadie pueda espiarla (capítulo 7). Has construido, ladrillo a ladrillo, la comprensión de cómo una solicitud viaja desde el navegador del usuario hasta tu servidor y regresa.
Ahora viene la pregunta que todo desarrollador termina haciéndose cuando su proyecto comienza a crecer: ¿por qué mi sitio tarda tanto para usuarios que están lejos? Y la respuesta, molesta pero honesta, es física. La información viaja a la velocidad de la luz, pero la velocidad de la luz en un cable de fibra óptica no es tan rápida como suena cuando hay miles de kilómetros de distancia.
En este capítulo vamos a resolver ese problema. Vamos a construir, conceptualmente, la infraestructura que hace posible que un estudiante en Guadalajara, otro en Buenos Aires y un tercero en Barcelona experimenten exactamente la misma velocidad al acceder a elprofe.org. Vamos a entender por qué Cloudflare tiene una presencia tan dominante —74.7% del mercado CDN mundial en junio de 2026— y qué significa eso para ti como desarrollador independiente, emprendedor o docente que construye sus propias plataformas.
Pero la CDN es solo una parte de la historia. La otra parte es la caché: la idea de no pedir algo dos veces si ya lo tienes cerca. La caché es una de las ideas más antiguas y poderosas de la informática. Está en tu procesador, en tu sistema operativo, en tu navegador, en el servidor DNS, en el servidor web, en el CDN, en la base de datos. Está en todas partes. Y cuando la configuras mal, el daño puede ser enorme: desde usuarios viendo páginas desactualizadas hasta credenciales personales sirviendo a usuarios equivocados.
Este capítulo es largo, intencionalmente. Porque la caché y las CDN son temas que muchos desarrolladores aprenden de forma fragmentada —aquí un header, allá una opción en el dashboard— y nunca terminan de entender del todo. Cuando termines este capítulo, vas a entender el sistema completo. Desde la física de la latencia hasta la configuración de Cache Rules en Cloudflare. Desde el algoritmo de compresión Brotli hasta el cálculo de ahorro en ancho de banda para una plataforma con 5,000 usuarios al mes.
Empecemos por el principio: el problema que motivó que existiera todo esto.
1. El problema de la distancia¶
Hay una verdad incómoda sobre Internet que la industria tecnológica prefiere no mencionar en sus presentaciones de marketing: la información no viaja instantáneamente. Viaja a aproximadamente dos tercios de la velocidad de la luz, limitada por la física del vidrio y el silicio a unos 200,000 kilómetros por segundo en fibra óptica.
Eso suena increíblemente rápido. Y lo es, hasta que calculas las distancias.
La distancia en línea recta desde Ciudad de México hasta Madrid es aproximadamente 9,000 kilómetros. Un fotón viajando por fibra óptica recorrería esa distancia en unos 45 milisegundos. Pero los cables no van en línea recta: rodean océanos, suben montañas, pasan por nodos intermedios. La ruta real de datos entre México y España, a través de cables submarinos del Atlántico, tiene una latencia de propagación pura de 120 a 150 milisegundos. Solo de ida.
Una conversación HTTP requiere múltiples viajes de ida y vuelta: el handshake TCP, el handshake TLS (capítulo 7), la petición HTTP, la respuesta. Con HTTP/1.1 clásico, una página simple con 20 recursos puede requerir decenas de viajes. Con HTTP/2 mejora mucho gracias al multiplexing (capítulo 6), pero la latencia base de propagación no desaparece.
Compáralo con un servidor ubicado en la Ciudad de México sirviendo a un usuario también en CDMX: latencia de 5 a 10 milisegundos. La diferencia no es de décimas: es de 10 a 30 veces.
┌─────────────────────────────────────────────────────────────────────────────┐
│ LATENCIA APROXIMADA DESDE CDMX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ CDMX ──────────────── Guadalajara ~8ms (fibra nacional) │
│ CDMX ──────────────── Monterrey ~12ms (fibra nacional) │
│ CDMX ──────────────── Bogotá ~45ms (cable submarino) │
│ CDMX ──────────────── Buenos Aires ~90ms (cable submarino) │
│ CDMX ──────────────── Nueva York ~55ms (cable atlántico norte) │
│ CDMX ──────────────── Londres ~130ms (cable atlántico) │
│ CDMX ──────────────── Madrid ~140ms (cable atlántico) │
│ CDMX ──────────────── Tokio ~170ms (cable transpacífico) │
│ CDMX ──────────────── Sídney ~210ms (cable transpacífico) │
│ │
│ Solo PROPAGACIÓN física. Sin contar: procesamiento, TCP, TLS, DNS. │
└─────────────────────────────────────────────────────────────────────────────┘
El backbone de Internet¶
La infraestructura que conecta continentes se llama backbone o red troncal de Internet. Está compuesta por:
- Cables submarinos: fibras ópticas tendidas en el fondo del océano. Hay más de 400 cables submarinos activos en el mundo, algunos de ellos propiedad de Google, Meta o Microsoft. El cable MAREA, por ejemplo, conecta Virginia Beach (EE.UU.) con Bilbao (España) y tiene una capacidad de 200 terabits por segundo.
- IXPs (Internet Exchange Points): puntos donde múltiples redes se conectan e intercambian tráfico directamente. Los principales en Latinoamérica son el CABASE-IXP en Buenos Aires, el PTT-Metro São Paulo y el Neutral Internet Exchange de México (NIX.mx). En Europa, el DE-CIX en Fráncfort es el más grande del mundo.
- Cables terrestres: fibra óptica enterrada que conecta ciudades dentro de un mismo país o región.
El problema de la distancia no es solo filosófico. Para un estudiante de elprofe.org que vive en Mérida, Yucatán, y accede desde su teléfono en una conexión 4G, la latencia hasta un servidor en la Ciudad de México es manejable. Para ese mismo estudiante accediendo desde un café en Barcelona durante un Erasmus, la experiencia puede ser degradada significativamente si el servidor origin está solo en México.
La analogía del mensajero¶
Piensa en el sistema postal vs. un mensajero local. Si necesitas enviarle un documento a alguien en tu colonia, usas un mensajero en bicicleta: llega en 15 minutos. Si esa persona se mudó a Tokio, el mensajero en bicicleta ya no sirve. Necesitas DHL, avión, una cadena completa de intermediarios. Y aun así, tardará días.
Ahora imagina que alguien tuviera la previsión de colocar copias de ese documento en bodegas estratégicas alrededor del mundo, actualizadas regularmente. Cuando la persona en Tokio lo pide, no va hasta tu oficina en México: va a la bodega más cercana en Osaka. El documento llega en 15 minutos.
Esas bodegas son los PoPs (Points of Presence) de una CDN.
2. ¿Qué es un CDN?¶
Una CDN (Content Delivery Network, o Red de Distribución de Contenido) es una red de servidores distribuidos geográficamente que almacenan y sirven copias del contenido de tu sitio web. En lugar de que todos los usuarios del mundo conecten a tu servidor de origen en un solo datacenter, conectan al servidor CDN más cercano a ellos.
Un poco de historia¶
La idea nació en 1998 en el MIT. Los profesores Tom Leighton y su estudiante Danny Lewin se encontraron con un problema que estaba por volverse crítico: Internet estaba creciendo exponencialmente y los servidores centralizados no iban a poder aguantar la demanda. Fundaron Akamai Technologies, la primera CDN comercial del mundo. Su primera gran prueba fue la transmisión en vivo del discurso del presidente Clinton en 1998. Funcionó.
Lewin, trágicamente, murió el 11 de septiembre de 2001 en el vuelo American Airlines 11, el primero en impactar las Torres Gemelas. Era el único pasajero que intentó resistir a los secuestradores. Su historia y la de Akamai son parte esencial de la historia de Internet.
Desde 1998, la industria CDN ha evolucionado en tres generaciones:
- CDN v1 (1998-2005): Principalmente para imágenes y archivos estáticos. Akamai dominaba, los precios eran altísimos, solo grandes empresas podían pagarlo.
- CDN v2 (2005-2015): Streaming de video (YouTube, Netflix), descarga de archivos grandes, expansión global. CloudFront de AWS entró al mercado en 2008, democratizando el acceso.
- CDN v3 (2015-presente): Edge computing, seguridad integrada (WAF, DDoS), sin egress fees. Cloudflare revolucionó el mercado ofreciendo CDN gratuita con protección DDoS incluida.
El mercado hoy¶
En junio de 2026, el mercado global de CDN vale $25,587 millones de dólares (creciendo desde $20,826 millones en 2025). El 82% de todos los sitios web del mundo usa al menos un CDN. Y la distribución de ese mercado es clara:
| Proveedor | Market Share (CDN) |
|---|---|
| Cloudflare | 74.7% |
| Amazon CloudFront | 16.3% |
| Fastly | 6.7% |
| Akamai | 3.5% |
(Fuente: wmtips.com, junio 2026)
Cloudflare no solo domina el CDN: es también el servidor web más utilizado del mundo (23.4% de todos los sitios) y controla el 83.5% del mercado de reverse proxy. Para el desarrollador independiente que construye proyectos como elprofe.org, Cloudflare es, en la práctica, la opción obvia y gratuita.
Los beneficios concretos¶
Una CDN resuelve cuatro problemas al mismo tiempo:
- Velocidad: El contenido viene del PoP más cercano al usuario, no del origen. Un usuario en Madrid ve elprofe.org desde un datacenter en Madrid, no desde México.
- Disponibilidad: Si el servidor de origen cae, el CDN puede seguir sirviendo contenido cacheado. Tu sitio sigue "vivo" aunque tu servidor esté caído.
- Reducción de carga: El 80-90% de las peticiones pueden responderse desde caché sin tocar tu servidor de origen. Tu servidor procesa solo lo que realmente necesita procesarse.
- Seguridad: Cloudflare absorbe ataques DDoS (hasta 405 Tbps de capacidad) antes de que lleguen a tu servidor. Nadie sabe la IP real de tu servidor de origen.
3. Cómo funciona un CDN¶
Entender el flujo completo de una petición a través de un CDN es fundamental para configurarlo correctamente. No es magia: es una secuencia lógica y predecible de pasos.
Cuando un usuario escribe https://elprofe.org en su navegador en Guadalajara, esto es lo que sucede:
Paso 1: Resolución DNS con Anycast¶
El navegador hace una consulta DNS para elprofe.org. El servidor DNS (gestionado por Cloudflare, como vimos en el capítulo 4) responde con una dirección IP. Pero no cualquier IP: una IP Anycast de Cloudflare. Como veremos en la sección 5, múltiples servidores Cloudflare en el mundo comparten esa misma IP. El router BGP del proveedor de Internet en Guadalajara selecciona automáticamente el camino más corto hacia esa IP, que llevará al usuario al PoP de Cloudflare más cercano: probablemente Guadalajara o CDMX.
Paso 2: Conexión al PoP más cercano¶
El navegador establece la conexión TCP y TLS directamente con el PoP de Cloudflare en Guadalajara, no con tu servidor en CDMX (o donde sea que esté). La latencia es de ~5ms, no de ~140ms. El handshake TLS (capítulo 7) ocurre con el PoP local.
Paso 3: ¿Cache HIT o Cache MISS?¶
El PoP de Cloudflare revisa su caché local. ¿Tiene una copia válida del recurso solicitado?
- Si sí (Cache HIT): responde directamente desde caché. El servidor de origen nunca se entera de la petición. La respuesta incluye el header
CF-Cache-Status: HIT. - Si no (Cache MISS): necesita obtener el recurso. Pero antes de ir directo al origen, primero consulta al Upper Tier (caché de nivel superior regional). Si el Upper Tier tiene el recurso, lo devuelve al PoP local y lo cachea allí también. Solo si el Upper Tier tampoco lo tiene, la petición llega al servidor de origen.
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ FLUJO COMPLETO DE UNA PETICIÓN CDN │
└────────────────────────────────────────────────────────────────────────────────────────┘
Usuario (Guadalajara)
│
│ DNS → IP Anycast (Cloudflare)
│
▼
┌───────────────┐
│ PoP Local │ ← Guadalajara / CDMX
│ Cloudflare │
└───────┬───────┘
│
├──────────────────────────────────────────────────┐
│ │
Cache HIT? Cache MISS
│ │
YES │
│ ▼
│ ┌────────────────────┐
│ │ Upper Tier │
│ │ (PoP Regional) │
│ └─────────┬──────────┘
│ │
│ ┌───────────┴───────────┐
│ Cache HIT? Cache MISS
│ │ │
│ YES ▼
│ │ ┌─────────────────────┐
│ │ │ Servidor Origen │
│ │ │ (tu servidor) │
│ │ └──────────┬──────────┘
│ │ │
│ │ Respuesta + Headers Cache
│ │ Cachear en Upper Tier
│ │ Cachear en PoP Local
│ │ │
└────────────────────────────────────┴───────────────────────┘
│
Respuesta al Usuario
CF-Cache-Status: HIT / MISS / EXPIRED / BYPASS
El lenguaje de Cloudflare: CF-Cache-Status¶
Cloudflare devuelve en cada respuesta un header diagnóstico que te dice exactamente qué pasó con la caché:
| Valor | Significado |
|---|---|
HIT |
Respondido desde caché del PoP local. El mejor resultado posible. |
MISS |
No estaba en caché. Se fue al origen (o al Upper Tier, que tampoco lo tenía). |
EXPIRED |
Estaba en caché pero el TTL expiró. Se fue a revalidar al origen. |
BYPASS |
La regla de caché indicó no cachear este recurso (ej: API endpoints). |
REVALIDATED |
Estaba en caché expirado, se validó con ETag, el origen confirmó que sigue igual (304). |
DYNAMIC |
El recurso se generó dinámicamente y no se puede cachear. |
Para verificar qué está pasando con tu sitio, puedes usar curl:
HTTP/2 200
server: cloudflare
cf-cache-status: HIT
cf-ray: 8a3d2f1b0e5c4a2d-GDL
age: 3847
cache-control: public, max-age=31536000, immutable
content-type: image/png
content-encoding: br
El age: 3847 te dice que este recurso lleva 3,847 segundos (casi 64 minutos) en caché. El cf-ray incluye el código del datacenter: GDL es Guadalajara.
¿Cuándo va al origen y cuándo no?¶
Por defecto, Cloudflare cachea automáticamente archivos con estas extensiones: .css, .js, .png, .jpg, .jpeg, .gif, .ico, .svg, .woff, .woff2, .ttf, .eot, .pdf, .zip. Todo lo demás —HTML, respuestas de API, contenido con cookies de sesión— lo deja pasar al origen por defecto.
Esto es configurable. Y en la sección de Cache Rules veremos exactamente cómo.
4. PoP — Point of Presence¶
Un PoP (Point of Presence) es una ubicación física donde una CDN tiene servidores instalados. Piénsalo como una sucursal de la CDN: un datacenter, o parte de uno, donde los servidores de la CDN están co-localizados con los routers de proveedores de Internet locales.
La proximidad de un PoP a los usuarios finales es lo que determina la latencia. Y Cloudflare ha invertido masivamente en esta cobertura.
La red de Cloudflare en 2026¶
- 330+ ciudades en todo el mundo
- 120+ países
- 12,500+ operadores de red conectados directamente (peering)
- 405 Tbps de capacidad total de red (para mitigación DDoS)
- 95% de la población mundial vive a menos de 50ms de un PoP de Cloudflare
- 60 millones de peticiones HTTP procesadas por segundo en picos
Para comparar: Amazon CloudFront tiene 700+ PoPs (incluyendo PoPs embebidos en ISPs), y Akamai lidera en número absoluto con ~1,500 PoPs pero en un mercado de nicho enterprise.
PoPs de Cloudflare en México¶
México es un mercado estratégico para Cloudflare. Los PoPs conocidos incluyen:
┌──────────────────────────────────────────────────────────────────┐
│ CLOUDFLARE PoPs EN MÉXICO (2026) │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ● Ciudad de México (MEX) — Principal, alta capacidad │
│ ● Guadalajara (GDL) — 2do nodo más importante │
│ ● Monterrey (MTY) — Importante para norte de México │
│ ● Querétaro (QRO) — Centro del país, en crecimiento │
│ │
│ Conectados peer-to-peer con: │
│ TELMEX, Megacable, Axtel, Alestra, IZZI, TotalPlay, KIO │
│ │
└──────────────────────────────────────────────────────────────────┘
Esto significa que un usuario de Telmex en Guadalajara que accede a elprofe.org (con Cloudflare activado) conecta directamente al PoP de Cloudflare en Guadalajara sin salir de la red de Telmex. La latencia puede ser tan baja como 2-5ms.
La métrica que importa: TTFB¶
El TTFB (Time To First Byte) es el tiempo que pasa desde que el navegador hace la petición hasta que recibe el primer byte de respuesta. Es la métrica más directamente afectada por la latencia de red y la ubicación del servidor.
- Sin CDN, servidor en CDMX, usuario en Madrid: TTFB ~300-400ms
- Con Cloudflare, usuario en Madrid, Cache HIT: TTFB 28ms (mediana de Cloudflare)
- Con CloudFront, usuario en Madrid, Cache HIT: TTFB ~35ms
Esos 28ms de Cloudflare vs 35ms de CloudFront no parecen mucho, pero en acumulación sobre muchos recursos de una página, la diferencia es perceptible.
5. Anycast: cómo el tráfico llega al PoP correcto¶
Cuando Cloudflare dice que tiene 330+ PoPs alrededor del mundo compartiendo las mismas direcciones IP, suena imposible. ¿Cómo puede 1.1.1.1 ser la dirección de un servidor en Tokio y al mismo tiempo de un servidor en São Paulo y otro en Londres?
La respuesta es Anycast, y es uno de los mecanismos de enrutamiento más elegantes de Internet.
Unicast vs Anycast¶
En el modelo tradicional Unicast, cada servidor tiene una dirección IP única. Si quieres conectarte a ese servidor, esa IP tiene un único destino posible en el mundo. Sencillo, pero no escala bien globalmente.
┌─────────────────────────────────────────────────────────────────────┐
│ UNICAST vs ANYCAST │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ UNICAST: │
│ │
│ Usuario México ──────────────────────────────► Servidor 1.2.3.4 │
│ Usuario España ─────────────────────────────────────────────────► │
│ Usuario Japón ─────────────────────────────────────────────────► │
│ (todos van al mismo servidor) │
│ │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ANYCAST: │
│ │
│ Usuario México ────► PoP CDMX (IP: 104.16.0.0) │
│ Usuario España ────► PoP Madrid (IP: 104.16.0.0) ← misma IP! │
│ Usuario Japón ────► PoP Tokio (IP: 104.16.0.0) ← misma IP! │
│ │
│ BGP selecciona automáticamente el camino más corto. │
│ │
└─────────────────────────────────────────────────────────────────────┘
Cómo funciona BGP con Anycast¶
BGP (Border Gateway Protocol) es el protocolo de enrutamiento que mantiene la "tabla de rutas" de Internet. Cada router en Internet sabe cómo llegar a cada bloque de IPs del mundo a través de BGP.
En Anycast, Cloudflare anuncia el mismo bloque de IPs (por ejemplo, 104.16.0.0/12) desde todos sus PoPs simultáneamente. Cuando un router en Guadalajara recibe una petición hacia esa IP, BGP calcula que el camino más corto (menos "hops") es el PoP de Cloudflare en Guadalajara o CDMX, no en Madrid. Así que enruta el tráfico allí.
Si el PoP de Guadalajara cayera, BGP automáticamente recalcularía y enviaría el tráfico al siguiente PoP más cercano disponible, en milisegundos. Sin intervención humana. Sin cambios en la configuración del cliente. Esto es lo que hace a Anycast tan poderoso para resiliencia y failover.
Beneficios concretos para elprofe.org¶
- Latencia mínima automática: Cada usuario conecta al PoP más cercano sin ninguna configuración adicional.
- Failover automático: Si un PoP falla, el tráfico se redirige automáticamente.
- Absorción de DDoS distribuida: Un ataque DDoS que envía tráfico hacia la IP de Cloudflare se distribuye entre cientos de PoPs, en lugar de saturar un solo servidor. Con 405 Tbps de capacidad total, Cloudflare puede absorber los ataques DDoS más grandes registrados.
- Opacidad del origen: La IP real de tu servidor nunca se expone al mundo exterior (con el Orange Cloud activado). Nadie puede atacar directamente tu origen.
6. Edge Computing¶
Hasta ahora hemos hablado de la CDN como un sistema de almacenamiento y entrega: copias del contenido distribuidas cerca del usuario. Pero las CDN modernas han evolucionado para hacer algo mucho más poderoso: ejecutar código en el edge.
CDN clásica vs Edge Computing¶
Piensa en la diferencia entre un guardarropa de librería y un empleado inteligente. La CDN clásica es el guardarropa: guarda libros (archivos) y los entrega cuando los pides. Pero no puede hacer nada con esos libros más allá de guardarlos y entregarlos.
El Edge Computing agrega un empleado al guardarropa. Ese empleado puede leer el libro, modificar páginas, añadir marcadores personalizados, aplicar descuentos, verificar si tienes permiso para llevártelo, y devolverte una versión personalizada. Todo esto sin que la petición jamás llegue al almacén central.
En Cloudflare, ese empleado se llama Cloudflare Workers: funciones JavaScript (o WebAssembly) que se ejecutan directamente en los PoPs de Cloudflare, a centímetros del usuario (en términos de latencia). Lo mencionamos brevemente en el capítulo 5 al hablar de servidores web modernos.
Qué puede hacer un Worker en el edge¶
- Personalización: Cambiar el contenido de una página según el país del usuario, idioma, o tipo de dispositivo, sin tocar el servidor de origen.
- Autenticación: Verificar un JWT en el edge y bloquear peticiones no autorizadas antes de que lleguen al origen.
- A/B Testing: Servir diferentes versiones de una página a diferentes usuarios.
- Reescritura de URLs: Redirigir
/blog/2024/*a un nuevo servidor de blog sin tocar DNS. - Transformación de respuestas: Comprimir, modificar headers, añadir watermarks a imágenes.
Para elprofe.org, un Worker podría verificar si el token JWT del estudiante es válido antes de que la petición llegue al servidor de Firebase, reduciendo la carga en el origen y mejorando la seguridad. Otro Worker podría inyectar cabeceras de seguridad personalizadas (Content-Security-Policy, HSTS) en todas las respuestas, sin modificar el código de la aplicación.
El edge computing borra la línea entre "CDN para archivos estáticos" y "servidor de aplicaciones". En 2026, para muchos casos de uso, la lógica de negocio vive directamente en el edge.
7. ¿Qué es la caché?¶
La caché es, en su esencia más simple, una estrategia para no hacer el mismo trabajo dos veces. Si ya calculaste algo, guardas el resultado. La próxima vez que necesites ese resultado, lo tomas de donde lo guardaste en lugar de recalcularlo.
Piensa en una fotocopiadora. Si tienes que distribuir 100 copias de un documento de 50 páginas, no vas a la fuente original cada vez: sacas una fotocopia y luego fotocopias la fotocopia. La caché funciona igual: la primera vez pagas el costo de obtener el recurso original; las siguientes veces usas la copia.
Por qué la caché importa tanto¶
En el contexto web, "hacer el mismo trabajo" puede significar muchas cosas costosas:
- Hacer una consulta SQL a la base de datos para obtener los últimos artículos del blog.
- Renderizar una plantilla HTML combinando datos de múltiples fuentes.
- Comprimir una imagen de 5MB a un formato optimizado.
- Establecer una nueva conexión TCP+TLS con el servidor de origen.
- Transferir 200KB de JavaScript por la red.
Si todos esos pasos ocurren en cada petición de cada usuario, el costo acumulado es enorme. La caché permite hacer cada uno de esos pasos una sola vez y reutilizar el resultado múltiples veces.
El problema de la caché: staleness¶
Pero la caché tiene un talón de Aquiles: el contenido puede quedar desactualizado (stale). Si cacheas los artículos del blog por 24 horas y publicas un artículo nuevo, los usuarios verán la versión antigua durante hasta 24 horas.
La gestión de caché es, fundamentalmente, un balance entre dos objetivos en tensión:
- Performance: cuanto más tiempo cacheas, más rápido y menos costoso es el sistema.
- Frescura: cuanto menos tiempo cacheas, más actualizado está el contenido.
No existe una respuesta universal. La estrategia correcta depende de qué tan frecuentemente cambia el contenido y cuánto importa que el usuario vea la versión más reciente.
La invalidación de caché —saber cuándo y cómo borrar el caché para forzar que se obtenga contenido nuevo— es uno de los problemas más famosos de la informática. Phil Karlton, uno de los arquitectos originales de Netscape, lo formuló así: "Hay solo dos problemas difíciles en ciencias de la computación: invalidación de caché y nombrar cosas."
8. Tipos de caché¶
La caché no es un concepto de una sola capa. Desde que presionas Enter en el navegador hasta que la base de datos devuelve un resultado, hay al menos siete capas donde el caché puede operar. Entender cada una es crucial para depurar problemas y optimizar correctamente.
┌──────────────────────────────────────────────────────────────────────────┐
│ LAS 7 CAPAS DE CACHÉ EN UNA APLICACIÓN WEB │
│ (del usuario al servidor) │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. NAVEGADOR [ CSS, JS, imágenes en disco local ] │
│ │ │
│ 2. DNS CACHE [ IP del dominio, TTL 300-3600s ] │
│ │ │
│ 3. CDN (Cloudflare) [ Archivos estáticos en PoPs ] │
│ │ │
│ 4. REVERSE PROXY [ Nginx proxy_cache, Varnish ] │
│ │ │
│ 5. APLICACIÓN [ Redis, Memcached: objetos y datos ] │
│ │ │
│ 6. QUERY CACHE [ MySQL query cache, PostgreSQL ] │
│ │ │
│ 7. BASE DE DATOS [ Índices en memoria (InnoDB buffer)] │
│ │
└──────────────────────────────────────────────────────────────────────────┘
1. Caché del navegador¶
Es la caché más cercana al usuario: archivos guardados en el disco duro o SSD del dispositivo. Cuando visitas elprofe.org por primera vez, el navegador descarga el logo, los estilos CSS, el JavaScript. La segunda vez que visitas, el navegador verifica: ¿sigue siendo válido este archivo? Si el Cache-Control dice max-age=31536000 (1 año), simplemente lo carga desde disco sin hacer ninguna petición de red.
Puedes ver esta caché en acción en Chrome/Firefox: abre DevTools → Network → marca "Disable cache" desactivado → recarga la página. Los recursos con (disk cache) o (memory cache) en la columna Size son los que se sirvieron desde caché local.
2. Caché DNS¶
Como aprendimos en el capítulo 4, cada registro DNS tiene un TTL (Time To Live). Cuando tu resolver DNS obtiene la IP de elprofe.org, guarda esa IP en caché por el tiempo que indique el TTL. Valores típicos: 300 segundos (5 minutos) para dominios que pueden cambiar; 3600 segundos (1 hora) para dominios estables.
La caché DNS existe en múltiples niveles: el resolver del proveedor de Internet, el sistema operativo del usuario, y el propio navegador. Esto significa que cuando cambias los DNS de un dominio (por ejemplo, al activar Cloudflare), puede tomar tiempo —hasta el TTL máximo— para que todos los usuarios vean el cambio.
3. Caché HTTP (Cache-Control)¶
Esta es la caché controlada por los headers HTTP que veremos en detalle en la sección 10. Opera entre el navegador y el CDN, guiada por las directivas del header Cache-Control que el servidor envía en cada respuesta.
4. Caché del CDN (caché compartida)¶
La caché del CDN —Cloudflare, CloudFront, Fastly— es una caché compartida: múltiples usuarios se benefician de ella. Cuando el primer usuario en Guadalajara solicita un recurso y genera un cache MISS, Cloudflare lo guarda en el PoP de Guadalajara. El segundo usuario en Guadalajara que solicita el mismo recurso obtiene un cache HIT instantáneo.
5. Caché del servidor (reverse proxy)¶
Antes de que los CDN fueran tan ubicuos, muchas aplicaciones usaban Nginx o Varnish como reverse proxy con caché local en el servidor. Nginx puede configurarse con proxy_cache para guardar respuestas del backend upstream:
proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=elprofe_cache:10m max_size=1g;
proxy_cache_key "$host$request_uri";
proxy_cache_valid 200 5m;
Varnish es un caché HTTP especializado, extremadamente rápido y configurable con su lenguaje VCL. Todavía tiene sentido en aplicaciones de alto tráfico con patrones de acceso complejos.
6. Caché de aplicación (Redis / Memcached)¶
Redis y Memcached son almacenes de datos en memoria que se usan para cachear objetos de aplicación: resultados de consultas SQL, objetos serializados, sesiones de usuario, respuestas de APIs externas.
En elprofe.org, por ejemplo, los modelos de inteligencia artificial (embeddings, índices vectoriales) y los resultados de consultas frecuentes a la base de datos de cursos se cachean en Redis. Una consulta SQL que tarda 200ms en ejecutarse puede servirse desde Redis en menos de 1ms.
7. Caché de base de datos¶
Las propias bases de datos tienen cachés internas. MySQL y PostgreSQL mantienen en memoria los índices y páginas de datos más frecuentemente accedidos (InnoDB Buffer Pool en MySQL). Esto no es algo que el desarrollador configure directamente en el día a día, pero es parte de la arquitectura de caché total.
9. TTL — Time To Live¶
El TTL (Time To Live) en el contexto de caché es el tiempo que un recurso se considera válido antes de necesitar ser refrescado o revalidado. Cuando el TTL expira, la copia en caché se considera "stale" (rancia) y debe verificarse o reemplazarse con una versión fresca.
No confundas este TTL con el TTL de DNS (capítulo 4), aunque comparten el concepto: en DNS, el TTL indica cuánto tiempo los resolvers pueden guardar en caché un registro DNS antes de consultarlo de nuevo al servidor autoritativo. En HTTP, el TTL (expresado como max-age en segundos) indica cuánto tiempo el navegador o CDN puede usar una copia cacheada sin verificarla.
La regla de oro del TTL¶
La elección del TTL correcto depende de una pregunta fundamental: ¿con qué frecuencia cambia este contenido, y cuánto importa que el usuario vea la versión más reciente?
┌─────────────────────────────────────────────────────────────────────────────────┐
│ TABLA DE TTL RECOMENDADOS POR TIPO DE RECURSO │
├──────────────────────────────┬──────────────┬──────────────────────────────── │
│ Tipo de recurso │ TTL │ Justificación │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ JS/CSS con hash en nombre │ 1 año │ Hash cambia al cambiar contenido │
│ /assets/main.a3f8bc.js │ (31536000s) │ + immutable evita revalidación │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Imágenes estáticas (logos, │ 30 días │ Raramente cambian, sin versión │
│ iconos, fondos fijos) │ (2592000s) │ │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Videos educativos │ 7 días │ Grandes, costosos de re-servir │
│ │ (604800s) │ │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Artículos de blog HTML │ 5-15 min │ Pueden actualizarse con erratas │
│ │ (300-900s) │ │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Página principal HTML │ 0-300s │ Puede personalizarse o cambiar │
│ │ │ frecuentemente │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Respuestas de API pública │ 60-3600s │ Depende de cuánto cambian datos │
│ (cotizaciones, estadísticas) │ │ │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Respuestas de API privada │ 0 │ Datos de usuario, no compartir │
│ (perfil, progreso) │ (no-store) │ en ningún caché │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Credenciales digitales (PDF) │ 0 │ Documento personal, nunca cachear│
│ │ (no-store) │ │
├──────────────────────────────┼──────────────┼──────────────────────────────────┤
│ Páginas de pago/checkout │ 0 │ Nunca cachear transacciones │
│ │ (no-store) │ │
└──────────────────────────────┴──────────────┴──────────────────────────────────┘
El truco del versionado (cache busting)¶
Para recursos estáticos como JavaScript y CSS, la técnica más efectiva es incluir un hash del contenido en el nombre del archivo. La mayoría de los bundlers modernos (Webpack, Vite, Parcel) hacen esto automáticamente:
Con esta técnica, el nombre del archivo cambia automáticamente cuando cambia el contenido. Esto permite que cachees estos archivos por 1 año con immutable, sabiendo que nunca habrá desactualización: si cambias el código, el hash cambia, el nombre del archivo cambia, y el navegador/CDN solicita el nuevo archivo automáticamente. Los archivos viejos simplemente expiran y se eliminan del caché eventualmente.
10. Cache-Control¶
Cache-Control es el header HTTP más importante para gestionar el comportamiento de caché. Fue definido originalmente en HTTP/1.1 y su especificación más reciente es el RFC 9111 (junio 2022), que reemplazó al RFC 7234. Este header puede aparecer tanto en respuestas del servidor (diciéndole al cliente cómo cachear) como en peticiones del cliente (instrucciones al proxy).
Las directivas fundamentales¶
public: Cualquier intermediario puede cachear esta respuesta: el CDN, el proxy del proveedor de Internet, el navegador. Indica que el contenido no es específico del usuario.
private: Solo el navegador del usuario puede cachear esta respuesta. Los CDNs y proxies intermedios no pueden almacenarla. Úsala para contenido personalizado por usuario.
no-cache: Confusión común: no-cache no significa "no cachear". Significa "almacena, pero valida antes de usar". El navegador/CDN puede guardar la copia, pero antes de servirla a un nuevo usuario, debe preguntarle al servidor: "¿sigue siendo válida?" (mediante ETag o Last-Modified). Si el servidor dice que sí (304 Not Modified), sirve la copia en caché. Si cambió, obtiene la versión nueva.
no-store: Esto sí significa "no cachear nada". Ni el navegador ni ningún intermediario puede almacenar ninguna copia de esta respuesta. Úsalo para datos verdaderamente sensibles: contraseñas, tokens, documentos personales.
max-age=N: El recurso es válido por N segundos desde el momento en que fue obtenido. Aplica al navegador y a cualquier caché que respete la directiva public.
s-maxage=N: Igual que max-age, pero aplica solo a caches compartidas (CDN, proxy). Sobreescribe max-age para el CDN, pero el navegador usa el max-age original. Esto es extremadamente útil: puedes decirle al CDN que cachee por 5 minutos y al navegador que no cachee (para asegurarte de que el usuario siempre tenga datos frescos, pero el CDN absorba el tráfico).
must-revalidate: Una vez que el TTL expira, el recurso no puede usarse bajo ninguna circunstancia sin revalidar con el servidor. Evita que caches sirvan contenido expirado en condiciones de error de red.
immutable: Una promesa fuerte: este recurso nunca cambiará mientras el max-age sea válido. Los navegadores modernos normalmente hacen una petición condicional (revalidación) cuando el usuario recarga la página, incluso si el TTL no ha expirado. Con immutable, el navegador sabe que esa revalidación es innecesaria y la omite. Perfecto para archivos con hash en el nombre.
stale-while-revalidate=N: Una de las directivas más poderosas y menos conocidas. Permite servir contenido "rancio" (expirado) mientras el caché actualiza en segundo plano. El usuario recibe una respuesta instantánea (aunque sea de hace 5 minutos), y el caché se actualiza silenciosamente para la siguiente petición.
En este ejemplo: el CDN sirve la respuesta en caché por 60 segundos (fresh). Una vez que esos 60 segundos pasan, sigue sirviendo la versión "rancia" por hasta 300 segundos más, mientras en background hace una petición al origen para actualizar el caché. El usuario nunca experimenta lentitud por revalidación.
Ejemplos reales para elprofe.org¶
Imagen de logo o asset estático con hash:
1 año. El hash garantiza que si cambia el archivo, cambia la URL. Nadie verá contenido desactualizado.HTML de página principal (dinámico/personalizado):
Puede guardarse pero siempre debe revalidarse. Si el contenido no ha cambiado, 304 Not Modified. Si cambió, versión nueva.API pública de estadísticas (analytics del curso):
CDN cachea 1 minuto. Entre 60s y 300s, sirve versión rancia mientras actualiza. El usuario siempre tiene respuesta rápida.Datos de perfil del usuario (API autenticada):
Datos personales. Nunca en caché compartida, nunca en disco.PDF de credencial digital:
Documento personal irrepetible. Cero caché. Siempre desde origen.El flujo de validación ETag en Cache-Control¶
Cuando un recurso tiene no-cache o su max-age ha expirado, el navegador no descarta la copia cacheada: la usa para hacer una petición condicional. Esto se explora en la siguiente sección.
┌──────────────────────────────────────────────────────────────────────────┐
│ FLUJO Cache-Control: s-maxage=60, stale-while-revalidate=300│
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ t=0s Usuario A → CDN: MISS → Origen: respuesta → CDN cachea 60s │
│ │
│ t=30s Usuario B → CDN: HIT (fresco) │
│ │
│ t=75s Usuario C → CDN: stale-while-revalidate activo │
│ ├── Devuelve inmediatamente versión de t=0 (rancia) │
│ └── En background: petición al origen → actualiza caché │
│ │
│ t=76s Caché actualizado con respuesta de t=75s del origen │
│ │
│ t=80s Usuario D → CDN: HIT (versión fresca de t=75s) │
│ │
└──────────────────────────────────────────────────────────────────────────┘
11. ETag y validación condicional¶
Los ETags resuelven el problema de la revalidación eficiente. En lugar de descargar siempre el recurso completo para verificar si cambió, el servidor y el cliente tienen una conversación más inteligente.
¿Qué es un ETag?¶
Un ETag (Entity Tag) es como una huella dactilar del contenido de un recurso. Es un identificador único —típicamente un hash del contenido— que el servidor incluye en la respuesta:
HTTP/2 200 OK
content-type: text/css
cache-control: no-cache
etag: "33a64df551425fcc55e4d42a148795d9f25f89d"
content-length: 23142
El flujo completo de revalidación con ETag¶
┌────────────────────────────────────────────────────────────────────────────┐
│ FLUJO ETag / 304 NOT MODIFIED │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ PRIMERA PETICIÓN: │
│ │
│ Navegador → GET /styles.css │
│ Servidor → 200 OK + ETag: "33a64df5..." + body (23KB) │
│ Navegador guarda: archivo + ETag │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ SEGUNDA PETICIÓN (TTL expirado o no-cache): │
│ │
│ Navegador → GET /styles.css │
│ If-None-Match: "33a64df5..." ← ETag guardado │
│ │
│ Servidor compara ETag con versión actual: │
│ │
│ ┌─ ¿Igual? ──────── SÍ ─────────────────────────────────────────────┐ │
│ │ Servidor → 304 Not Modified (sin body) │ │
│ │ Ahorro: 23KB de transferencia │ │
│ └──────────── NO ──────────────────────────────────────────────────┘ │
│ Servidor → 200 OK + nuevo ETag + nuevo body │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Last-Modified como alternativa¶
Si el servidor no implementa ETags, puede usar el header Last-Modified + If-Modified-Since:
```http
Respuesta del servidor:¶
Petición posterior del cliente:¶
Via API de Cloudflare:¶
HTML principal¶
Justificación: contiene referencias a chunks de JS con hash.¶
Con no-cache, si cambió el HTML (nuevo deploy), el usuario obtiene¶
la versión nueva. Con ETag, si no cambió, 304 Not Modified.¶
JS/CSS con hash en filename (generados por Vite)¶
1 año. El hash en el nombre garantiza unicidad.¶
HTML del artículo¶
CDN cachea 5 minutos. Stale-while-revalidate permite servir la¶
versión rancia por hasta 24 horas mientras actualiza en background.¶
El usuario siempre obtiene respuesta rápida.¶
30 días. Las imágenes de los artículos raramente cambian.¶
Con Cloudflare Polish (Pro), automáticamente servidas en WebP.¶
Nunca cachear en CDN. Cada petición al servidor de origen.¶
Cache Rules en Cloudflare: bypass para /api/*¶
Absolutamente ningún caché. Son documentos personales¶
con nombre, apellido, fecha y firma digital del alumno.¶
Si dos personas con el mismo apellido acceden al mismo URL¶
y hay caché de por medio, podría ocurrir una filtración.¶
Los endpoints SSE (Server-Sent Events) no se pueden cachear:¶
Cloudflare Cache Rule: bypass para /ai/ y /stream/¶
Cada shortlink puede cambiar (si el usuario edita la URL destino).¶
Además, cada redirect necesita registrarse en analytics.¶
Nunca cachear.¶
Datos del usuario: clicks, links creados, estadísticas.¶
Nunca en caché compartida.¶
Las estadísticas pueden tener 1 minuto de retraso sin problema.¶
El usuario ve datos "casi en tiempo real" con excelente performance.¶
La landing no cambia frecuentemente. 1 hora es razonable.¶
5 minutos en CDN. Stale por hasta 1 hora.¶
Los artículos recientes pueden actualizarse varias veces al día.¶
1 día en CDN. Los artículos de análisis raramente se editan¶
después de publicados. Si se edita, purge manual por URL.¶
Los precios de mercado cambian cada segundo.¶
No hay ningún escenario donde se deba cachear esto.¶
Incluso 1 segundo de caché puede mostrar un precio incorrecto.¶
1 semana. Los reportes tienen fecha y no se modifican.¶
Imágenes y documentos:¶
Directorio de maestros y página "Contacto":¶
Documentos descargables (circulares, formatos):¶
Primer request (debería ser MISS):¶
Resultado esperado:¶
HTTP/2 200¶
cf-cache-status: MISS¶
server: cloudflare¶
Segundo request (debería ser HIT):¶
Resultado esperado:¶
HTTP/2 200¶
cf-cache-status: HIT¶
age: 23¶
server: cloudflare¶
cf-ray: 8a3d2f1b0e5c4a2d-GDL¶
Resultado esperado:¶
cf-cache-status: BYPASS¶
cache-control: private, no-store¶
Resultado esperado:¶
content-encoding: br¶
29. Lo que viene en el Capítulo 9¶
Has construido en este capítulo la columna vertebral de performance de tu infraestructura web: CDN global, caché inteligente, compresión optimizada, distribución geográfica. Tu sitio es ahora rápido en cualquier parte del mundo.
Pero velocidad no es todo. Internet está llena de actores maliciosos: bots que intentan adivinar contraseñas, scripts que buscan vulnerabilidades, ataques automatizados que intentan inyectar código en tu base de datos, grupos que quieren dejar tu servicio fuera de línea con un ataque masivo.
En el Capítulo 9: Seguridad Web — Protegiendo tu aplicación de amenazas reales, vamos a construir las defensas. Comenzaremos con el OWASP Top 10, el mapa de las vulnerabilidades más comunes y devastadoras: SQL injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), broken authentication, y más. No como conceptos teóricos, sino con ejemplos reales de código vulnerable y su corrección.
Luego pasaremos a la infraestructura de defensa: el WAF (Web Application Firewall) de Cloudflare y cómo configurarlo para bloquear ataques conocidos automáticamente. Las cabeceras de seguridad HTTP —Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy— que el servidor envía para instruir al navegador a proteger al usuario. El rate limiting para evitar fuerza bruta y abuso de APIs. Y la autenticación segura: por qué las contraseñas sin sal son un desastre esperando ocurrir, cómo implementar 2FA, y qué hace que un sistema de sesiones sea verdaderamente seguro.
Al igual que este capítulo te enseñó que el contenido bien distribuido llega en 28ms en lugar de 350ms, el próximo te enseñará que la seguridad bien implementada puede detener el 99% de los ataques automatizados antes de que toquen tu código.
30. Referencias bibliográficas¶
-
RFC 9111 — HTTP Caching (junio 2022): https://httpwg.org/specs/rfc9111.html
-
RFC 9110 — HTTP Semantics (junio 2022): https://www.rfc-editor.org/rfc/rfc9110
-
Cloudflare Cache documentation: https://developers.cloudflare.com/cache/
-
Cloudflare Cache Rules settings (actualizado 27 junio 2026): https://developers.cloudflare.com/cache/how-to/cache-rules/settings/
-
Cloudflare Smart Tiered Cache: https://developers.cloudflare.com/cache/how-to/tiered-cache/
-
Cloudflare Cache Reserve: https://developers.cloudflare.com/cache/advanced-configuration/cache-reserve/
-
Cloudflare Polish — Image Optimization: https://developers.cloudflare.com/images/polish/
-
Cloudflare Anycast Network: https://www.cloudflare.com/learning/cdn/glossary/anycast-network/
-
W3Techs CDN statistics (28 junio 2026): https://w3techs.com/technologies/comparison/cn-akamai,cn-cloudflare,cn-fastly
-
wmtips.com CDN market share (28 junio 2026): https://www.wmtips.com/technologies/cdn/
-
Cloudflare network statistics (wmtips.com, junio 2026): https://www.wmtips.com/technologies/cdn/cloudflare/
-
HTTP Archive CDN chapter: https://almanac.httparchive.org/en/2025/cdn
-
Brotli vs Gzip benchmarks (Panelica): https://panelica.com/blog/gzip-vs-brotli-compression-configuration-and-benchmarks
-
Cloudflare R2 pricing: https://developers.cloudflare.com/r2/pricing/
-
Cloudflare vs CloudFront comparison 2026 (Tech Insider): https://tech-insider.org/cloudflare-vs-cloudfront-2026/
-
Cache-Control header — MDN Web Docs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control
-
CDN market share 2026 (dataresearchtools.com): https://dataresearchtools.com/cdn-market-share-2026/
-
Brotli compression benchmarks 2026 (XICTRON): https://www.xictron.com/en/blog/brotli-asset-compression-shop-performance-2026/
Capítulo 8 de "Arquitectura Web Moderna — De cero a una infraestructura profesional para Internet" © 2026. Todos los derechos reservados.