📘 Este artículo forma parte de nuestra Guía Completa de Redes 2026 y complementa a Beneficios del uso de CDN para la seguridad y rendimiento de aplicaciones web. Si quieres dominar la infraestructura web, esas guías son tu punto de partida.
Introducción
Cada vez que abres una web moderna —Netflix, Amazon, Spotify, YouTube, o prácticamente cualquier sitio grande— hay un sistema invisible trabajando a toda velocidad para servirte el contenido en milisegundos. Ese sistema es la CDN (Content Delivery Network), y su componente clave es el caché de contenido.
Una CDN bien configurada puede reducir el tiempo de carga de una web un 60-80%, disminuir la carga del servidor origen un 90%, y proteger contra ataques DDoS masivos. En 2026, usar una CDN ya no es opcional: es estándar.
En esta guía completa vas a aprender:
- Qué es una CDN y qué problema resuelve.
- Cómo funciona el caché por dentro.
- Qué se puede cachear (y qué no).
- Tipos de caché (browser, proxy, edge, origin).
- Headers HTTP de caché (
Cache-Control,ETag,Expires). - Estrategias de caché (TTL, invalidación, cache busting).
- Cómo configurar una CDN paso a paso.
- Optimización para máximo rendimiento.
- Solución de problemas comunes.
- FAQ con las preguntas más frecuentes.
Si quieres ver los beneficios de seguridad y rendimiento, consulta Beneficios del uso de CDN. Para configuración avanzada de servidores, nuestra Guía Completa de Servidores.
Índice de contenidos
- Qué es una CDN
- El problema que resuelve
- Cómo funciona el caché por dentro
- Tipos de caché
- Qué se puede cachear (y qué no)
- Headers HTTP de caché
- Estrategias de caché
- Cómo configurar una CDN
- Optimización avanzada
- Solución de problemas
- FAQ
- Conclusión
1. Qué es una CDN
Una CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente que sirven contenido estático (y a veces dinámico) a los usuarios desde el servidor más cercano a su ubicación.
1.1 Características principales
- Distribución geográfica: servidores en múltiples regiones.
- Caché: contenido almacenado temporalmente en cada servidor.
- Anycast: la misma IP sirve desde distintas ubicaciones.
- Edge computing: procesamiento cerca del usuario.
- Failover: si un servidor falla, otro toma el relevo.
1.2 PoPs (Points of Presence)
Cada CDN tiene PoPs (Puntos de Presencia) distribuidos por el mundo.
| CDN | PoPs aproximados |
|---|---|
| Cloudflare | 330+ |
| Akamai | 4.000+ |
| AWS CloudFront | 600+ |
| Fastly | 300+ |
| Bunny CDN | 120+ |
1.3 Cómo decide el usuario más cercano
Anycast: múltiples servidores comparten la misma IP. El enrutamiento de internet lleva al usuario al más cercano.
GeoDNS: el DNS resuelve a la IP del PoP más cercano al usuario.
Ambos combinados en CDNs modernas.
1.4 Historia breve
- 1995: Akamai inventa la CDN.
- 2000s: CDNs se popularizan (Netflix, YouTube).
- 2010s: Cloudflare democratiza el acceso.
- 2020s: CDN + Edge Computing + WAF.
- 2026: estándar absoluto.
Consulta Guía Completa de Redes para el contexto general.
2. El problema que resuelve
2.1 Latencia
Latencia: tiempo que tarda la información en viajar.
Ejemplo sin CDN:
- Servidor origen en Madrid.
- Usuario en Tokio.
- Distancia: ~10.000 km.
- Latencia mínima: ~150 ms por paquete.
- Página con 100 recursos: 15 segundos solo en latencia.
Con CDN:
- PoP de la CDN en Tokio.
- Latencia: ~5-20 ms.
- Página con 100 recursos: 1-2 segundos.
2.2 Carga del servidor
Sin CDN:
- Todos los usuarios van al servidor origen.
- Saturación con tráfico alto.
- Escalado vertical necesario (caro).
Con CDN:
- 80-95% de peticiones servidas desde caché.
- Servidor origen solo procesa lo no cacheado.
- Escalado horizontal (más barato).
2.3 Ataques DDoS
Sin CDN:
- El ataque llega directamente al servidor.
- Saturación de ancho de banda.
- Servicio caído.
Con CDN:
- La CDN absorbe el ataque.
- Distribuido entre cientos de PoPs.
- El origen nunca ve el ataque.
2.4 Disponibilidad
Sin CDN:
- Si el servidor cae, la web cae.
- Sin redundancia geográfica.
Con CDN:
- Contenido cacheado sigue sirviéndose.
- Failover automático entre PoPs.
- Alta disponibilidad.
2.5 Costes
Sin CDN:
- Servidor potente necesario.
- Ancho de banda caro.
- Escalado costoso.
Con CDN:
- Servidor más modesto.
- Ancho de banda distribuido.
- Coste predecible.
Consulta Beneficios del uso de CDN.
3. Cómo funciona el caché por dentro
3.1 El flujo de una petición
Usuario → DNS → PoP de CDN → ¿Está en caché?
│
├─ SÍ → Devuelve desde caché
│
└─ NO → Solicita al origen → Cachea → Devuelve3.2 Paso a paso
1. El usuario pide un recurso:
GET /style.css HTTP/1.1
Host: example.com2. DNS resuelve a la CDN:
La CDN tiene un PoP cercano al usuario.
3. La CDN comprueba su caché:
- ¿Tengo
/style.csscacheado? - ¿Está vigente (no expirado)?
4. Cache HIT:
- Si está cacheado y vigente → devuelve desde caché.
- Tiempo: 5-20 ms.
5. Cache MISS:
- Si no está → solicita al servidor origen.
- El origen devuelve el recurso.
- La CDN lo cachea.
- Lo devuelve al usuario.
- Tiempo: 100-500 ms (primera vez).
6. Peticiones posteriores:
- Otros usuarios del mismo PoP → cache HIT.
- Tiempo: 5-20 ms.
3.3 Cache Hit vs Cache Miss
Cache Hit Ratio (CHR): % de peticiones servidas desde caché.
- CDN bien configurada: 80-95%.
- CDN mal configurada: 40-60%.
Objetivo: maximizar CHR para reducir carga del origen.
3.4 TTL (Time To Live)
TTL: tiempo que un recurso permanece en caché antes de ser considerado obsoleto.
- TTL corto (1 min): contenido fresco pero más misses.
- TTL largo (1 año): más hits pero riesgo de contenido obsoleto.
Regla: TTL largo para recursos versionados (CSS, JS, imágenes).
3.5 Invalidación
Si cambias un recurso, hay que invalidar la caché.
Métodos:
- Purge manual: pide a la CDN borrar un recurso.
- Cache busting: cambia el nombre del recurso (
style.v2.css). - TTL corto: espera a que expire.
Consulta Cómo funciona un sistema de caché de contenido CDN (este mismo artículo).
4. Tipos de caché
4.1 Browser cache
Dónde: en el navegador del usuario.
Qué guarda: imágenes, CSS, JS, fuentes.
Controlado por: headers HTTP.
Ventaja: no hay petición al servidor.
Limitación: solo para ese usuario.
4.2 Proxy cache
Dónde: en el ISP o empresa.
Qué guarda: contenido popular.
Ventaja: sirve a múltiples usuarios.
Limitación: control limitado.
4.3 Edge cache (CDN)
Dónde: en los PoPs de la CDN.
Qué guarda: contenido estático y dinámico.
Ventaja: distribución geográfica, control total.
Limitación: coste de la CDN.
4.4 Origin cache
Dónde: en el servidor origen.
Qué guarda: respuestas dinámicas, bases de datos.
Herramientas:
- Varnish.
- Nginx con
proxy_cache. - Redis, Memcached.
Ventaja: reduce carga del backend.
Limitación: solo en el origen.
4.5 Application cache
Dónde: en la aplicación (backend).
Qué guarda: resultados de queries, sesiones, objetos.
Herramientas:
- Redis.
- Memcached.
- APCu.
Ventaja: muy rápido.
Limitación: requiere código.
4.6 Tabla resumen
| Tipo | Ubicación | Alcance | Control |
|---|---|---|---|
| Browser | Usuario | 1 usuario | Headers |
| Proxy | ISP/empresa | Múltiples usuarios | Limitado |
| Edge (CDN) | PoPs | Global | Total |
| Origin | Servidor | Servidor | Total |
| Application | Backend | App | Total |
5. Qué se puede cachear (y qué no)
5.1 Contenido estático (siempre cachear)
- Imágenes (jpg, png, webp, avif, svg).
- CSS (stylesheets).
- JavaScript (scripts).
- Fuentes (woff, woff2, ttf).
- Vídeos (mp4, webm).
- Audio (mp3, ogg).
- PDFs.
- Descargas.
TTL: largo (días, meses, año).
5.2 Contenido semi-estático (cachear con TTL medio)
- HTML de páginas estáticas.
- APIs con datos que cambian poco.
- Feeds RSS.
- Sitemaps.
TTL: medio (horas, días).
5.3 Contenido dinámico (cachear con cuidado)
- HTML personalizado.
- APIs con datos en tiempo real.
- Carritos de compra.
- Sesiones de usuario.
TTL: corto (segundos, minutos).
Regla: no cachear contenido personalizado sin Vary header.
5.4 Contenido NO cacheable
- Contenido autenticado (paneles de admin).
- Datos de usuario (perfil, configuración).
- Carritos de compra.
- Formularios con CSRF tokens.
- APIs de pago.
- Streaming en vivo.
Headers: Cache-Control: no-store.
5.5 Regla del 80/20
El 80% del tráfico web corresponde a contenido estático.
Cachear ese 80% reduce carga del origen drásticamente.
Consulta Cómo implementar HTTPS correctamente.
6. Headers HTTP de caché
6.1 Cache-Control
El header más importante. Define cómo cachear.
Directivas principales:
Cache-Control: max-age=3600max-age: segundos que el recurso es válido.
Cache-Control: publicpublic: cacheable por cualquier caché.
Cache-Control: privateprivate: solo cacheable por el navegador del usuario.
Cache-Control: no-cacheno-cache: revalidar antes de usar caché.
Cache-Control: no-storeno-store: no cachear en absoluto.
Cache-Control: must-revalidatemust-revalidate: revalidar cuando expire.
Combinaciones típicas:
# Estático, 1 año
Cache-Control: public, max-age=31536000, immutable
# Dinámico, 1 hora
Cache-Control: public, max-age=3600, must-revalidate
# No cachear
Cache-Control: no-store, no-cache, must-revalidate6.2 ETag
Identificador único del recurso.
ETag: "5d8c72a5-264"Uso: el navegador envía If-None-Match: "5d8c72a5-264" para preguntar si ha cambiado.
Respuesta:
- 304 Not Modified: no ha cambiado (usa caché).
- 200 OK: ha cambiado (envía nuevo).
Ventaja: eficiente, valida por contenido.
6.3 Last-Modified
Fecha de última modificación.
Last-Modified: Mon, 01 Jan 2026 12:00:00 GMTUso: el navegador envía If-Modified-Since.
Ventaja: simple.
Limitación: menos preciso que ETag.
6.4 Expires
Fecha absoluta de expiración.
Expires: Thu, 31 Dec 2026 23:59:59 GMTLimitación: si el reloj está mal, problemas.
Recomendación: usa Cache-Control: max-age (relativo) en lugar de Expires.
6.5 Vary
Define qué headers afectan al caché.
Vary: Accept-Encoding, User-AgentEjemplo: si sirves contenido diferente por User-Agent, incluye Vary: User-Agent.
⚠️ Cuidado: Vary: User-Agent puede reducir el hit ratio drásticamente.
6.6 Age
Tiempo que el recurso lleva en caché.
Age: 1800Uso: información para el cliente.
6.7 Ejemplos prácticos
Imagen estática:
Cache-Control: public, max-age=31536000, immutable
ETag: "abc123"HTML dinámico:
Cache-Control: public, max-age=300, must-revalidate
ETag: "def456"
Vary: Accept-EncodingAPI privada:
Cache-Control: private, no-storeConsulta Cómo implementar el protocolo HTTPS correctamente.
7. Estrategias de caché
7.1 TTL según tipo de contenido
| Tipo | TTL recomendado |
|---|---|
| Imágenes versionadas | 1 año |
| CSS/JS versionados | 1 año |
| Fuentes | 1 año |
| HTML estático | 1 hora – 1 día |
| APIs semi-estáticas | 5 min – 1 hora |
| HTML dinámico | 0 – 5 min |
| APIs dinámicas | 0 (o muy corto) |
| Contenido privado | No cachear |
7.2 Cache busting
Problema: si cambias style.css, los usuarios siguen viendo la versión antigua (cacheada).
Solución: cambiar el nombre del archivo.
Ejemplos:
style.css → style.v2.css
style.css → style.abc123.cssEn HTML:
<link rel="stylesheet" href="/style.css?v=abc123">En frameworks modernos:
- Webpack: hash en el nombre.
- Vite: hash automático.
- Next.js: hash en
_next/static.
Ventaja: TTL largo sin problemas de caché obsoleta.
7.3 Invalidación selectiva
Por URL:
# Cloudflare
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
-H "Authorization: Bearer TOKEN" \
-H "Content-Type: application/json" \
--data '{"files":["https://example.com/style.css"]}'Por tag (si la CDN lo soporta):
# Cloudflare Enterprise
--data '{"tags":["css","homepage"]}'Por todo:
--data '{"purge_everything":true}'7.4 Stale-While-Revalidate
Estrategia moderna: servir contenido obsoleto mientras se revalida.
Cache-Control: public, max-age=3600, stale-while-revalidate=86400Cómo funciona:
- Contenido expira.
- Usuario recibe versión obsoleta (rápido).
- En background, se revalida.
- Próximos usuarios reciben versión fresca.
Ventaja: rendimiento sin perder frescura.
7.5 Stale-If-Error
Si el origen falla, servir contenido obsoleto.
Cache-Control: public, max-age=3600, stale-if-error=86400Ventaja: alta disponibilidad.
7.6 Preload / Prefetch
Precargar contenido antes de que se necesite.
<link rel="preload" href="/style.css" as="style">
<link rel="prefetch" href="/next-page.html">En HTTP:
Link: </style.css>; rel=preload; as=style7.7 Configuración por tipo de archivo
Nginx ejemplo:
# CSS/JS: 1 año
location ~* \.(css|js)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# Imágenes: 1 año
location ~* \.(jpg|jpeg|png|gif|webp|svg|ico)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# Fuentes: 1 año
location ~* \.(woff|woff2|ttf|otf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# HTML: 1 hora
location ~* \.html$ {
expires 1h;
add_header Cache-Control "public, must-revalidate";
}8. Cómo configurar una CDN
8.1 Elegir una CDN
Opciones:
| CDN | Gratis | WAF | DDoS | Ideal para |
|---|---|---|---|---|
| Cloudflare | ✅ | ✅ | ✅ | Todos |
| CloudFront | ❌ | ✅ | ✅ | AWS |
| Fastly | ❌ | ✅ | ✅ | Medios |
| Bunny | ❌ | ✅ | ✅ | Pequeñas |
| Akamai | ❌ | ✅ | ✅ | Grandes |
Recomendación: Cloudflare para empezar (tier gratuito generoso).
8.2 Configurar Cloudflare (paso a paso)
1. Registrarse:
- Ir a https://www.cloudflare.com/
- Crear cuenta gratuita.
2. Añadir el dominio:
- Introducir tu dominio.
- Cloudflare escanea los DNS.
3. Cambiar nameservers:
- Cloudflare te da 2 nameservers.
- Cámbialos en tu registrador.
- Espera propagación (24-48h).
4. Configurar DNS:
- Los registros se importan automáticamente.
- Verifica cada uno.
- Activa el proxy (nube naranja) para los que quieras cachear.
5. Configurar SSL/TLS:
- SSL/TLS → Overview.
- Modo: Full (Strict).
- Habilitar HSTS.
6. Configurar caché:
- Caching → Configuration.
- Caching Level: Standard.
- Browser Cache TTL: según tipo de contenido.
- Always Online: activado.
7. Configurar Page Rules:
- Page Rules → Create Page Rule.
- Ejemplo: cachear todo
/static/*.
8. Configurar WAF:
- Security → WAF.
- Activar reglas gestionadas.
- Activar OWASP Core Ruleset.
9. Configurar DDoS:
- Activado por defecto.
- Ajustar sensibilidad si es necesario.
10. Verificar:
- Test de velocidad (GTmetrix, WebPageTest).
- Ver headers de caché:
curl -I https://tudominio.com/style.cssDeberías ver:
CF-Cache-Status: HIT
Cache-Control: public, max-age=315360008.3 Configurar AWS CloudFront
1. Crear distribución:
- CloudFront → Create Distribution.
- Origin: tu servidor.
- Behaviors: definir reglas.
2. Configurar caché:
- Cache Policy:
CachingOptimized. - TTL: 86400 (1 día).
3. Configurar SSL:
- Certificado ACM (gratuito).
- Redirigir HTTP → HTTPS.
4. Configurar WAF:
- AWS WAF → Web ACL.
- Reglas gestionadas.
5. Verificar:
- CloudFront → Distributions → Domain name.
- Test.
8.4 Configurar Fastly
1. Crear servicio:
- Fastly → Create Service.
- Origin: tu servidor.
2. Configurar VCL:
sub vcl_recv {
# Cachear todo excepto admin
if (req.url ~ "^/admin/") {
return (pass);
}
}
sub vcl_backend_response {
# TTL por tipo de archivo
if (bereq.url ~ "\.(css|js|jpg|png|gif|svg|woff2)$") {
set beresp.ttl = 365d;
set beresp.http.Cache-Control = "public, max-age=31536000, immutable";
}
}3. Configurar dominio.
4. Test.
8.5 Configurar caché en Nginx (origin)
Si quieres cachear en tu propio servidor:
# En http {}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
# En server {}
location / {
proxy_cache my_cache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://backend;
}Estados de X-Cache-Status:
- HIT: servido desde caché.
- MISS: no estaba en caché.
- EXPIRED: expirado, revalidado.
- STALE: obsoleto, servido por fallo.
9. Optimización avanzada
9.1 Maximizar el hit ratio
Objetivos:
- CHR > 90% para estáticos.
- CHR > 60% para semi-estáticos.
Técnicas:
- TTL largo para estáticos.
- Cache busting para actualizar.
- Reducir Vary headers.
- Normalizar URLs (mayúsculas/minúsculas, trailing slash).
- Cachear respuestas de API con TTL adecuado.
9.2 Compresión
Comprimir respuestas antes de enviar:
- gzip: universal.
- brotli: mejor compresión.
Nginx:
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length 1000;
gzip_comp_level 6;
# Brotli
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml;En Cloudflare:
- Speed → Optimization → Brotli: ON.
9.3 HTTP/2 y HTTP/3
HTTP/2: multiplexación, mejor rendimiento.
HTTP/3: sobre QUIC, aún mejor.
Cloudflare: HTTP/3 activable en Network.
9.4 Early Hints
Enviar hints tempranos al navegador:
Link: </style.css>; rel=preload; as=styleVentaja: el navegador empieza a cargar antes.
9.5 Imágenes optimizadas
- WebP/AVIF en lugar de JPG/PNG.
- Lazy loading.
- Responsive images (srcset).
- CDN con transformación (Cloudflare Images, Cloudinary).
9.6 Edge computing
Cloudflare Workers:
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
<em>// Lógica personalizada en el edge</em>
const response = await fetch(request);
<em>// Modificar respuesta</em>
return response;
}Ventaja: procesamiento cerca del usuario.
9.7 Monitorización
KPIs:
- Cache Hit Ratio (CHR).
- TTFB (Time To First Byte).
- Latencia por región.
- Ancho de banda servido.
Herramientas:
- Cloudflare Analytics.
- AWS CloudWatch.
- Grafana + Prometheus.
Consulta Las mejores herramientas de monitorización.
9.8 Costes
Factores:
- Ancho de banda servido.
- Requests.
- Transformaciones de imágenes.
- Regiones.
Optimización:
- Aumentar CHR (menos requests al origen).
- Comprimir contenido.
- Usar formatos modernos.
- Negociar tarifas con volumen.
10. Solución de problemas
10.1 «El contenido no se actualiza tras cambios»
Causas:
- Caché obsoleta.
- TTL muy largo.
- Cache busting mal implementado.
Solución:
- Purge el recurso en la CDN.
- Cambia el nombre del archivo (cache busting).
- Reduce el TTL para desarrollo.
10.2 «Cache HIT ratio bajo»
Causas:
Vary: User-Agentmal configurado.- TTL muy corto.
- Contenido dinámico cacheado.
Solución:
- Elimina
Vary: User-Agentsi no es necesario. - Aumenta TTL para estáticos.
- Revisa qué se cachea.
10.3 «El sitio va lento con CDN»
Causas:
- Origen lento.
- CDN mal configurada.
- DNS lento.
Solución:
- Optimiza el origen.
- Configura
stale-while-revalidate. - Usa DNS rápido (Cloudflare 1.1.1.1).
10.4 «Errores 522 / 524 con Cloudflare»
Causas:
- Origen no responde.
- Timeout.
Solución:
- Verifica el origen.
- Aumenta timeout en Cloudflare (Business+).
- Revisa firewall del origen.
10.5 «El certificado SSL falla»
Causas:
- Origen sin SSL.
- Modo SSL incorrecto.
Solución:
- Usa modo Full (Strict).
- Instala certificado en el origen (Let’s Encrypt).
- Configura Cloudflare Origin Certificate.
Consulta Guía completa para configurar SSL en Nginx.
10.6 «Cloudflare bloquea tráfico legítimo»
Causas:
- WAF demasiado agresivo.
- Rate limiting.
Solución:
- Ajusta reglas del WAF.
- Añade IPs a whitelist.
- Reduce sensibilidad.
10.7 «Los formularios no funcionan»
Causas:
- Caché de POST.
- CSRF tokens cacheados.
Solución:
- No cachear POST (por defecto).
- Cachear solo GET.
- Añadir
no-storea páginas con formularios.
10.8 «Contenido mixto (mixed content)»
Causas:
- Recursos HTTP en página HTTPS.
Solución:
- Usa HTTPS en todo.
- Activa Automatic HTTPS Rewrites en Cloudflare.
- Actualiza URLs en el HTML.
10.9 «Imágenes no se actualizan»
Causas:
- Mismo nombre de archivo.
- Caché agresiva.
Solución:
- Cambia el nombre (
imagen-v2.jpg). - Purga la caché.
- Usa transformaciones con versión.
10.10 «El sitio se rompe en algunos navegadores»
Causas:
- Contenido cacheado para otro User-Agent.
Solución:
- Revisa
Varyheaders. - Evita cachear por
User-Agent. - Test en múltiples navegadores.
10.11 «Cache poisoning»
Causas:
- Headers mal validados.
- Host header injection.
Solución:
- Valida el header
Host. - No caches respuestas con
Set-Cookie. - Configura el WAF.
Consulta Beneficios del uso de CDN para la seguridad.
10.12 «Coste elevado de CDN»
Causas:
- Mucho tráfico no cacheado.
- Transformaciones costosas.
- Regiones lejanas.
Solución:
- Aumenta CHR.
- Optimiza imágenes.
- Configura límites.
11. FAQ
¿Qué es una CDN y cómo funciona?
Una CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente que sirven contenido a los usuarios desde el servidor más cercano.
Funcionamiento:
- Usuario pide un recurso.
- La CDN busca en su caché.
- Si está (HIT), lo devuelve rápido.
- Si no (MISS), lo pide al origen, lo cachea y lo devuelve.
Resultado: carga más rápida, menos carga del origen, más seguridad.
¿Cuál es la diferencia entre caché y CDN?
- Caché: técnica de almacenar copias de contenido.
- CDN: red distribuida que usa caché para servir contenido.
Toda CDN usa caché, pero no todo caché es una CDN.
¿Qué se puede cachear en una CDN?
Sí, cacheable:
- Imágenes, CSS, JS, fuentes.
- Vídeos, audio, PDFs.
- HTML estático.
- APIs semi-estáticas.
No cacheable:
- Contenido autenticado.
- Carritos de compra.
- Datos de usuario.
- Formularios con tokens.
¿Qué es el TTL y cómo lo configuro?
TTL (Time To Live): tiempo que un recurso permanece en caché.
Recomendaciones:
- Imágenes/CSS/JS versionados: 1 año (31536000).
- HTML estático: 1 hora – 1 día.
- APIs semi-estáticas: 5 min – 1 hora.
- Contenido dinámico: 0 – 5 min.
Configuración:
Cache-Control: public, max-age=31536000, immutable¿Qué es un Cache HIT y un Cache MISS?
- HIT: el recurso está en caché, se devuelve rápido.
- MISS: no está, se pide al origen.
Objetivo: maximizar HITs (>90%).
¿Qué es el cache busting?
Técnica para forzar a los navegadores a descargar la nueva versión de un recurso.
Métodos:
- Cambiar nombre:
style.v2.css. - Query string:
style.css?v=abc123. - Hash en frameworks:
style.a1b2c3.css.
¿Qué headers HTTP controlan el caché?
Principales:
Cache-Control: directivas de caché.ETag: identificador del recurso.Last-Modified: fecha de modificación.Expires: fecha absoluta de expiración.Vary: headers que afectan al caché.
¿Qué diferencia hay entre no-cache y no-store?
no-cache: revalidar antes de usar caché. El recurso puede cachearse pero debe revalidarse.no-store: no cachear en absoluto. Ni en memoria ni en disco.
Uso:
no-cache: contenido que cambia frecuentemente.no-store: contenido sensible (banca, admin).
¿Qué es stale-while-revalidate?
Estrategia que sirve contenido obsoleto mientras revalida en background.
Cache-Control: public, max-age=3600, stale-while-revalidate=86400Ventaja: rendimiento sin perder frescura.
¿Cuánto cuesta una CDN?
Tier gratuito (Cloudflare):
- Ilimitado en plan Free.
- WAF básico.
- DDoS ilimitado.
Planes de pago:
- Cloudflare Pro: 20 €/mes.
- Cloudflare Business: 200 €/mes.
- Cloudflare Enterprise: desde ~2.000 €/mes.
- CloudFront: variable según uso (~0,085 $/GB).
Recomendación: empieza gratis con Cloudflare.
¿Qué CDN uso?
Recomendaciones:
- Cloudflare: la más popular, tier gratuito generoso.
- AWS CloudFront: si usas AWS.
- Fastly: para medios y rendimiento.
- Bunny CDN: económica y buena.
- Akamai: para grandes empresas.
Cloudflare es la apuesta segura.
¿La CDN afecta al SEO?
Sí, positivamente:
- Mejora velocidad (factor de ranking).
- Mejora Core Web Vitals.
- Aumenta disponibilidad.
- Protege contra DDoS.
No hay efectos negativos si está bien configurada.
¿Cómo sé si mi CDN funciona?
Test:
curl -I https://tudominio.com/style.cssBusca:
CF-Cache-Status: HIT(Cloudflare).X-Cache: Hit from cloudfront(CloudFront).X-Cache-Status: HIT(Nginx).
Herramientas:
- WebPageTest.
- GTmetrix.
- Pingdom.
¿Qué es el Cache Hit Ratio (CHR)?
% de peticiones servidas desde caché.
Objetivos:
- Estáticos: >90%.
- Semi-estáticos: >60%.
- Dinámicos: >30%.
Fórmula:
CHR = HITs / (HITs + MISSes) * 100¿Cómo limpio la caché de una CDN?
Cloudflare:
- Dashboard → Caching → Purge Cache.
- Purge Everything: limpia todo.
- Custom Purge: limpia URLs específicas.
CloudFront:
- Distribution → Invalidations.
- Crear invalidación (
/*para todo).
Fastly:
- Purge → Purge All o URL específica.
¿Qué es un PoP en una CDN?
PoP (Point of Presence): ubicación física donde la CDN tiene servidores.
Función: servir contenido desde el PoP más cercano al usuario.
Cantidad: desde 100 hasta 4.000+ según la CDN.
¿La CDN protege contra DDoS?
Sí, es una de sus funciones principales.
- Distribuye el ataque entre cientos de PoPs.
- Absorbe tráfico malicioso.
- Protege el origen.
Cloudflare: DDoS ilimitado en todos los planes.
Consulta Cómo mitigar un ataque DDoS paso a paso.
¿Qué es el edge computing?
Procesamiento de datos en el edge (cerca del usuario) en lugar del datacenter central.
Ventajas:
- Latencia mínima.
- Menos ancho de banda.
- Mejor privacidad.
Ejemplos: Cloudflare Workers, Lambda@Edge, Deno Deploy.
¿Cómo optimizo el caché para máximo rendimiento?
Estrategia:
- Cachea todo lo estático con TTL largo.
- Usa cache busting para actualizaciones.
- Reduce Vary headers al mínimo.
- Añade
stale-while-revalidate. - Comprime con gzip/brotli.
- Usa HTTP/3.
- Monitoriza CHR regularmente.
- Optimiza imágenes (WebP/AVIF).
Consulta Beneficios del uso de CDN.
12. Conclusión
Las CDNs con caché de contenido son imprescindibles en 2026. Ya no son un lujo para grandes empresas: cualquier web moderna —desde un blog personal hasta una plataforma de streaming— se beneficia enormemente de ellas.
Puntos clave:
- CDN = red distribuida con caché geográfico.
- Reduce latencia drásticamente.
- Descarga el servidor origen (90%+ de hits).
- Protege contra DDoS.
- Mejora disponibilidad y resiliencia.
- Reduce costes a largo plazo.
- Cacheable: estáticos, HTML, APIs semi-estáticas.
- NO cacheable: contenido privado, formularios.
- Headers clave:
Cache-Control,ETag,Vary. - Cloudflare es la mejor opción para empezar.
Recomendación:
- Configura Cloudflare (gratis).
- Ajusta TTL por tipo de contenido.
- Usa cache busting para actualizar.
- Monitoriza CHR.
- Optimiza con compresión y HTTP/3.
Si quieres profundizar:
- Beneficios del uso de CDN para la seguridad y rendimiento de aplicaciones web
- Guía Completa de Redes 2026
- Cómo mitigar un ataque DDoS paso a paso
- Cómo implementar el protocolo HTTPS correctamente
- Guía completa para configurar SSL en Nginx
- Las mejores herramientas de monitorización de servidores
- Cómo configurar un firewall en Linux
- El futuro de la computación en la nube






