Edge computing y CDN: reduce la latencia en tu web

Cómo implementar una estrategia de edge computing y optimización CDN para reducir la latencia en tu aplicación web

Un usuario en Madrid hace clic en tu aplicacion web. La peticion viaja hasta un servidor en Virginia, cruza el Atlantico, procesa la solicitud y recorre el camino de vuelta. Son 150-200 milisegundos solo en latencia de red. Multiplica eso por cada recurso que carga la pagina y tienes una experiencia lenta. Y en la web de hoy, "lenta" significa que se van a la competencia.

El edge computing resuelve este problema moviendo la logica y los datos lo mas cerca posible del usuario final. La computacion se distribuye en cientos de puntos de presencia (PoPs) repartidos por el mundo, bajando tiempos de respuesta de 200 ms a 20-40 ms. Vamos a ver como implementar esto con decisiones tecnicas concretas y metricas que puedas medir de verdad.

Que significa edge computing en el contexto de aplicaciones web

En su forma mas basica, un CDN (Content Delivery Network) ya es edge computing: almacena copias de archivos estaticos en servidores distribuidos geograficamente. Lo que ha cambiado es que ahora podemos ejecutar logica de negocio en esos mismos nodos. Las edge functions permiten correr codigo en los puntos de presencia del CDN con latencias de un solo digito en milisegundos.

Personalizacion por geolocalizacion, autenticacion sin ir al origen, transformacion de imagenes, A/B testing, redirecciones inteligentes, renderizado de paginas. Atencion a la diferencia clave: el codigo edge se ejecuta en un entorno limitado. Sin sistema de archivos persistente, restricciones en conexiones a bases de datos, y tiempo de ejecucion acotado (entre 10 ms y 30 segundos segun el proveedor). El edge es para operaciones rapidas y ligeras.

Arquitectura CDN: las tres capas que necesitas entender

Una implementacion CDN moderna tiene tres capas principales. Los errores de configuracion suelen venir de confundir en cual estas actuando.

Capa de origen

Tu servidor de origen es donde reside la aplicacion completa. El CDN lo consulta cuando no tiene una copia valida del recurso. Error tipico: pensar que con un CDN delante ya no necesitas optimizar el origen. Los cache misses deben resolverse rapido, y en picos de trafico el origen recibe mas golpes de los que imaginas.

Capa de escudo (shield / mid-tier cache)

Entre los nodos edge y el origen, muchos CDN interponen una capa que consolida peticiones. Si 50 nodos edge piden simultaneamente el mismo recurso, el shield reduce esas peticiones a una sola hacia el origen. Cloudflare lo llama Tiered Cache, Fastly usa Shielding, AWS CloudFront ofrece Origin Shield. Activar esta capa es casi siempre buena idea.

Capa edge (PoPs)

Los puntos de presencia son los nodos mas cercanos al usuario. Los principales proveedores tienen entre 200 y 300 PoPs. En Espana, Cloudflare opera en Madrid y Barcelona; AWS CloudFront en Madrid; Fastly en Madrid y Barcelona. Y aqui van los numeros que de verdad importan: 2-5 ms de latencia desde Madrid para un usuario en Madrid, 25-35 ms desde Frankfurt, 90-120 ms desde Virginia.

Edge functions: que plataforma elegir y por que

Las tres plataformas principales tienen diferencias tecnicas reales. Cuidado con elegir solo por precio.

Cloudflare Workers

Utiliza el runtime V8 Isolates, que arranca instancias en menos de 5 ms (frente a los 50-200 ms de un cold start serverless convencional). Soporta JavaScript, TypeScript, Rust (via WebAssembly) y Python. Tiene acceso a KV (key-value store en el edge), R2 (almacenamiento de objetos), D1 (base de datos SQLite distribuida) y Durable Objects (estado con consistencia fuerte). Limite de CPU: 10 ms en plan gratuito, 30 ms en el de pago. Para la mayoria de casos de uso web, sobra.

Vercel Edge Functions

Basadas tambien en V8 Isolates, se integran nativamente con Next.js a traves de middleware y route handlers con export const runtime = 'edge'. Un middleware edge puede interceptar cada peticion antes de que llegue a la pagina: autenticacion, geolocalizacion, reescritura de rutas. Atencion: no soportan todas las APIs de Node.js (sin fs, child_process ni net). Si tu logica depende de alguna, te vas a encontrar con errores en produccion que no viste en local.

AWS Lambda@Edge y CloudFront Functions

AWS ofrece dos niveles. CloudFront Functions se ejecutan en todos los PoPs con latencia sub-milisegundo, pero son muy limitadas: solo JavaScript puro, sin acceso a red, maximo 10 KB de codigo. Lambda@Edge ofrece mas potencia (hasta 5 segundos, hasta 3 GB de memoria, acceso a red) pero solo en PoPs regionales, con cold starts de 100-500 ms. Empieza con CloudFront Functions para lo simple y sube a Lambda@Edge solo cuando lo necesites.

Cache estatica vs cache dinamica: donde esta el verdadero ahorro

Muchas respuestas que parecen dinamicas son personalizaciones sobre una base estatica cacheable. Identificar estas oportunidades es donde se gana la partida.

Cache de recursos estaticos

Archivos CSS, JavaScript, imagenes y fuentes deben servirse desde el CDN con cabeceras de cache agresivas. Para assets con hash en el nombre:

Cache-Control: public, max-age=31536000, immutable

Un ano de cache sin revalidacion. Si cambia el recurso, el hash del nombre sera diferente y listo. Para el HTML principal, la estrategia cambia:

Cache-Control: public, max-age=0, s-maxage=3600, stale-while-revalidate=86400

El navegador siempre revalida (max-age=0), el CDN cachea una hora (s-maxage=3600), y si el contenido esta obsoleto, sirve la version en cache mientras revalida en segundo plano. Este patron funciona muy bien en la practica.

Cache de respuestas dinamicas

Muchas respuestas de APIs pueden cachearse en el edge. Una peticion GET a /api/productos?categoria=electronica&pagina=1 puede cachearse 5 minutos si el catalogo no cambia con frecuencia. Las Vary headers (Vary: Accept-Language, Accept-Encoding) permiten cachear versiones distintas del mismo recurso, pero ojo: cada combinacion es una entrada adicional en la cache. Limita las variaciones o tu hit ratio se desplomara.

Invalidacion de cache: el problema que nunca desaparece

Phil Karlton dijo que las dos cosas mas dificiles en informatica son nombrar cosas y la invalidacion de cache. Tenia razon. Una estrategia de invalidacion mal disenada provoca desde usuarios viendo contenido obsoleto hasta picos de carga en el origen por invalidaciones masivas. No es agradable.

Invalidacion por TTL: el recurso expira tras un tiempo predefinido. Funciona para contenido que cambia de forma predecible (catalogos diarios, feeds cada hora).

Invalidacion por purge: el sistema de publicacion envia una peticion de purga al CDN cuando el contenido cambia. La purga por URL es casi instantanea; la purga completa puede tardar minutos y genera un pico de peticiones al origen. No dispares purgas completas desde un deploy automatico.

Invalidacion por tags: Fastly y Cloudflare permiten etiquetar recursos con tags arbitrarios y purgar por tag (por ejemplo, product-12345) sin conocer las URLs exactas. Es la opcion mas flexible para aplicaciones complejas.

Stale-while-revalidate: sirve contenido obsoleto mientras se actualiza en segundo plano. El usuario nunca espera a la revalidacion. Combinado con TTLs cortos, es un patron muy potente.

Optimizacion de imagenes en el edge

Las imagenes suponen entre el 40% y el 70% del peso total de una pagina web. Optimizarlas en el edge elimina la necesidad de generar y almacenar multiples versiones en tu servidor.

Servicios como Cloudflare Images, Vercel Image Optimization, imgix y Cloudinary transforman imagenes al vuelo en el edge: redimensionan, comprimen y convierten a formatos modernos (WebP, AVIF) segun los parametros de la URL.

<img src="/cdn-cgi/image/width=800,format=auto,quality=80/images/producto.jpg">

El parametro format=auto detecta que formatos soporta el navegador y sirve AVIF si es posible, WebP como segunda opcion, y JPEG como fallback. La reduccion de tamano puede alcanzar el 30-60% respecto a un JPEG tradicional. Sube siempre la imagen original a maxima resolucion, deja que el edge genere variantes bajo demanda, y usa srcset y sizes para que el navegador solicite el tamano adecuado.

Geo-routing y Edge Side Includes

El geo-routing dirige peticiones al contenido mas apropiado segun la ubicacion del usuario. Las edge functions acceden a datos de geolocalizacion (pais, ciudad) sin consultar servicios externos. Esto te permite servir precios en moneda local, mostrar avisos legales especificos por pais (RGPD en la UE), seleccionar el idioma por defecto o redirigir a versiones regionales de la aplicacion.

Los Edge Side Includes (ESI) permiten componer paginas a partir de fragmentos cacheados de forma independiente. Una pagina de producto puede tener el header cacheado un dia, el contenido del producto una hora y la seccion de stock un minuto:

<esi:include src="/fragments/header" />
<esi:include src="/fragments/producto/12345" />
<esi:include src="/fragments/stock/12345" ttl="60" />

Fastly soporta ESI nativamente. Cloudflare ofrece funcionalidad similar mediante Workers con HTMLRewriter. Con ESI puedes cachear el 95% de la pagina y solo ir al origen por el fragmento que realmente cambia.

Metricas de rendimiento: mide o estas adivinando

Implementar edge computing sin medir su impacto es ir a ciegas. Estas son las metricas que tienes que monitorizar si o si:

TTFB (Time to First Byte): tiempo hasta que el navegador recibe el primer byte de respuesta. Con edge bien configurado, deberia estar por debajo de 50 ms para el 90% de los usuarios en contenido cacheado. Si no llegas, algo falla.

LCP (Largest Contentful Paint): tiempo hasta que el mayor elemento visible se renderiza. Google lo usa como Core Web Vital. El edge impacta en LCP a traves de la reduccion del TTFB y la optimizacion de imagenes. Por debajo de 2.5 segundos se considera bueno.

Cache Hit Ratio: porcentaje de peticiones servidas desde cache. Por debajo del 80% indica que la estrategia necesita revision. Aplicaciones bien configuradas alcanzan 90-98% en recursos estaticos. Por debajo del 80%, revisa tus cabeceras antes de tocar otra cosa.

Latencia por percentiles (P50, P95, P99): la media oculta problemas. Si tu P50 es 30 ms pero tu P99 es 800 ms, tienes un problema real que la media no muestra. Percentiles siempre, medias nunca.

Las decisiones deben basarse en datos de campo (usuarios reales), no solo en datos de laboratorio. Herramientas como Cloudflare Analytics, WebPageTest y RUM (Datadog, New Relic) proporcionan estas metricas.

Mejoras de latencia reales: que esperar

Estos son rangos de mejora reales al implementar estrategias de edge:

• Paginas estaticas servidas desde CDN: TTFB pasa de 150-300 ms (servidor centralizado) a 10-30 ms (edge). Mejora del 80-95%.
• APIs con cache en el edge: latencia de 200-500 ms reducida a 20-60 ms para peticiones cacheadas.
• Imagenes optimizadas en el edge: reduccion del peso de pagina entre 30% y 60%, con impacto directo en LCP.
• Edge functions para personalizacion: latencia adicional de 5-15 ms frente a los 100-200 ms de una funcion serverless centralizada con cold start.

Estas mejoras son consistentes para usuarios distantes del servidor de origen. Para usuarios cercanos al datacenter, la mejora es menor pero existe gracias a la optimizacion de la cache.

Costes: ojo que el edge no siempre sale mas barato

La tarificacion del edge se basa en peticiones y ancho de banda. Cloudflare Workers incluye 100.000 peticiones diarias gratuitas ($0.50/millon adicional) y ancho de banda ilimitado. AWS CloudFront cobra entre $0.085 y $0.020 por GB segun volumen. AWS Lambda@Edge tiene un coste significativamente mayor que Lambda estandar.

Para aplicaciones con trafico moderado (menos de 10 millones de peticiones mensuales), el edge suele ser mas barato que servidores dedicados con capacidad para picos. Pero atencion: con trafico masivo y mucho contenido dinamico no cacheable, los costes pueden escalar rapidamente. Las facturas se pueden triplicar en un mes si no controlas esto.

Cuando NO usar edge computing

El edge no resuelve todos los problemas de rendimiento. Meter edge donde no toca anade complejidad gratis:

• Aplicaciones internas con usuarios en una sola ubicacion. Si todos estan en Madrid y tu servidor esta en Madrid, el edge no aporta nada.
• Procesamiento pesado: tareas que requieren segundos de CPU (procesamiento de video, calculos complejos) no encajan en los limites del edge.
• Operaciones transaccionales complejas: si cada peticion necesita leer y escribir en una base de datos relacional con garantias ACID, la conexion sigue yendo al datacenter central.
• Aplicaciones con estado pesado: el edge es stateless por naturaleza. Migrar requiere redisenar la gestion del estado.

Hoja de ruta: por donde empezar sin liarla

Una implementacion pragmatica sigue esta secuencia:

1. Auditar los recursos actuales y su cacheabilidad. Un CDN basico con cabeceras correctas cubre el 80% del beneficio.
2. Implementar optimizacion de imagenes en el edge.
3. Mover la logica de redirecciones y reescrituras a edge functions.
4. Cachear respuestas de API que sean candidatas (GET requests con baja frecuencia de cambio).
5. Implementar personalizacion ligera en el edge (geolocalizacion, A/B testing).
6. Evaluar si el renderizado en el edge (SSR en el edge) aporta valor medible para tu caso.

Cada paso debe validarse con metricas antes de avanzar al siguiente. No tiene sentido implementar SSR en el edge si aun no has configurado correctamente las cabeceras de cache de tus archivos estaticos. Primero los cimientos, luego el tejado.

Si necesitas ayuda para disenar una estrategia de edge computing adaptada a tu aplicacion web, o quieres auditar tu configuracion CDN actual para detectar oportunidades de mejora, contacta con Tangram Consulting. Trabajamos con los principales proveedores de CDN y edge computing para que tu aplicacion responda desde donde estan tus usuarios, no desde donde esta tu servidor.