Agregué una caché CDN y se puso más lento. Aquí está la matemática que debería haber hecho primero.

Agregué una caché CDN y se puso más lento. Aquí está la matemática que debería haber hecho primero.

La semana pasada, hice lo que parecía una optimización obvia. Agregué una capa de caché de Content Delivery Network (CDN) delante de mi sitio estático, esperando la historia habitual: tiempos de carga más rápidos, usuarios más felices, mejores puntuaciones SEO. En cambio, mejoré lo opuesto. Mi sitio se volvió notablemente más lento. No sutilmente: un rastreador independiente que antes reportaba tiempos de carga de 38 segundos comenzó a reportar 52 segundos. Ay.

Esto no es la primera vez que las optimizaciones de infraestructura salen mal, pero fue un recordatorio humilde de que las capas de caché tienen su propio carga de rendimiento. Antes de colocar ciegamente una CDN en tu pila, aquí está la matemática que desearía haber hecho primero.

Por qué la caché puede fallar

A primera vista, las CDN parecen ganar-ganar. Mueves assets estáticos más cerca de los usuarios, reduces la carga del servidor e improvisas la latencia global. Pero cada caché introduce sobrecarga:

1. **Latencia de decisiones de caché**: ¿Esta solicitud está en caché? ¿Debo revalidar? ¿Qué encabezados aplican?
2. **Saltos de red**: Incluso los nodos edge no están infinitamente cerca de los usuarios
3. **Fallos de caché**: Cuando las cachés expiran o se purgan, los usuarios pagan la latencia completa del origen más el retraso de procesamiento de la CDN
4. **Compresión y transformación**: Muchas CDN comprimen o modifican contenido, añadiendo tiempo de procesamiento

En mi caso, el culpable no era la CDN en sí, sino la *configuración de la caché*. Por defecto, muchas configuraciones de CDN cachean agresivamente archivos pequeños mientras dejan los grandes sin cachear, creando una experiencia inconsistente.

Los números que importan

Antes de implementar cualquier solución de caché, ejecuta estos cálculos:

Proporción de aciertos de caché
```
Proporción de aciertos = Aciertos / (Aciertos + Fallos)
```

Si solo estás en caché 60% de las veces, estás pagando por la sobrecarga de la CDN el 40% de las veces sin beneficio. Quieres más del 85%.

Latencia efectiva
```
Latencia efectiva = (Tasa de acierto × Latencia edge) + (Tasa de fallo × (Latencia edge + origen))
```

Ejemplo:
Latencia edge: 50ms
Latencia origen: 300ms
Tasa de acierto: 90%
Latencia efectiva: (0.9 × 50) + (0.1 × 350) = 80ms

Comparado con origen directo: 300ms. La CDN gana.

Pero si la tasa de acierto cae al 60%:
Latencia efectiva: (0.6 × 50) + (0.4 × 350) = 170ms
Sigue siendo más rápido, pero apenas vale la complejidad.

Optimización de TTL (Time-to-Live)
TTLs cortos (< 30 segundos) significan más búsquedas al origen. TTLs largos (> 24 horas) significan contenido desactualizado. Encuentra el equilibrio basado en la frecuencia de actualización.

Escenarios reales donde saltaría la CDN

1. Audiencia principalmente local
Si el 90% de tu tráfico viene de una región geográfica, una CDN puede añadir complejidad innecesaria. Un servidor de origen bien configurado podría rendir mejor.

Ejemplo: Un sitio web de un restaurante local que sirve principalmente a clientes cercanos no se beneficia significativamente de la caché edge global.

2. Contenido altamente dinámico
Para sitios donde el contenido se actualiza cada pocos minutos (como dashboards de noticias), los TTL cortos forzas una revalidación constante. La caché se convierte en una carga más que en un activo.

Ejemplo: Mi dashboard de analíticas obtiene datos en vivo cada 30 segundos. La caché aquí mostraría información desactualizada o requeriría lógica compleja de invalidación.

3. Tamaños de archivo pequeños
Las CDN optimizan proximidad de red, pero si tus archivos son pequeños (menos de 10KB), la sobrecarga de enrutar a través de una CDN puede superar el ahorro en tiempo de transferencia.

Ejemplo: Las respuestas de API JSON de menos de 5KB a menudo cargan más rápido directamente del origen que a través del procesamiento edge de una CDN.

Herramientas para diagnosticar rendimiento

Antes de asumir que CDN = mejora, mide el rendimiento base usando:

- **WebPageTest.org**: Gráficas de cascada detalladas mostrando dónde se gasta el tiempo
- **Lighthouse CI**: Auditorías de rendimiento automatizadas en tu pipeline de despliegue
- **Monitoreo de usuarios reales (RUM)**: Herramientas como [PostHog](https://posthog.com/) o [Plausible](https://plausible.io/) que muestran la experiencia real del usuario

Ejecuta pruebas desde múltiples ubicaciones geográficas para entender la verdadera experiencia de tu audiencia.

Corrigiendo mi propio error

Después de diagnosticar el problema, ajusté mi enfoque:

1. Aumenté el TTL de caché de 30 segundos a 6 horas para assets estáticos
2. Implementé etiquetas de caché adecuadas para invalidación dinámica
3. Añadí lógica de pre-calentamiento para endpoints populares
4. Monité continuamente las proporciones de aciertos usando [Cloudflare Analytics](https://www.cloudflare.com/analytics/)

Resultado? Los tiempos de carga cayeron de 52 segundos a 1.2 segundos globalmente.

La conclusión

Las CDN no son soluciones mágicas. Son herramientas sofisticadas que requieren ajuste cuidadoso. Siempre establece métricas base antes de optimizar, y nunca asumas que la configuración por defecto funcionará para tu caso específico.

Prueba a fondo, mide el impacto y recuerda: a veces eliminar complejidad supera a añadirla.

Preguntas frecuentes

¿Siempre debería usar una CDN?
No necesariamente. Evalúa basado en la geografía de la audiencia, tipo de contenido y frecuencia de actualización. Audiencias locales con archivos pequeños podrían no ver beneficio.

¿Cuál es una proporción de aciertos de caché aceptable?
Apunta al 85% o más. Por debajo del 70%, reconsidera si la sobrecarga de la CDN vale la pena.

¿Cuánto tiempo debería cachear assets estáticos?
Para assets versionados (con nombres de archivo con hash), cachea indefinidamente. Para otros, de 1 a 24 horas dependiendo de la frecuencia de actualización.

¿Pueden las CDN dañar el SEO?
Sí, si aumentan los tiempos de carga o sirven contenido inconsistente. Google considera la velocidad de carga en los rankings, así que monitorea los Core Web Vitals de cerca.