Qué compra realmente la aceleración en el borde: latencia, enrutado y aciertos de caché

Estas dos mitades se escribieron por separado, pero responden a la misma pregunta desde extremos opuestos: ¿qué cambia realmente un CDN? La primera es la distancia: qué nodo de borde te responde, cuánto mide ese camino y cuándo el número es en realidad culpa de tu propia red. La segunda es la necesidad: con un acierto la petición no llega al origen, con un fallo recorre más camino que una conexión directa. Solo juntas dicen si eso de la "aceleración global" es cierto para tu sitio.

Todo el mundo cita un número de ping y casi nadie sabe qué mide. Un tiempo de ida y vuelta solo significa algo junto a la ruta que tomó y al momento en que se midió.

1. La luz no viaja al instante

En fibra, la luz recorre unos 200 kilómetros por milisegundo. De Tokio a Fráncfort hay unos 9.300 km en línea recta, así que el suelo físico de un viaje de ida y vuelta ya ronda los 93 ms, antes de routers, colas y handshakes TLS. Cualquier cifra muy por debajo mide otra cosa.

2. Qué te dice el nodo de borde

Un CDN responde desde el punto de presencia más cercano, no desde el origen. Por eso el mismo sitio puede ir instantáneo en una ciudad y lento en otra: mides la distancia al borde, no al servidor que guarda los datos.

3. Qué medir junto a él

• Varianza, no solo la media. 120 ms estables se sienten mucho mejor que 60 ms con picos de 400.
• Pérdida de paquetes. Incluso el 1% provoca retransmisiones y hunde el rendimiento en TCP.
• El coste del primer byte: consulta DNS, handshake TCP y negociación TLS suman varios viajes antes de mover contenido.
• Franja horaria. La congestión sigue un patrón diario y la misma ruta empeora previsiblemente en hora punta.

4. Hacer tu propia comprobación

Toma varias muestras, consérvalas todas y compáralas con el nodo que te atendió. Si el nodo está cerca pero la latencia es alta, el cuello de botella es la última milla o tu red local. Si el nodo está lejos, el número es geografía, no un fallo.

5. Cuándo sospechar de tu propia red

Si el mismo nodo de borde varía por un factor de tres a lo largo del día, el CDN casi seguro no es el problema: la congestión de la tarde vive en la red de acceso y en la última milla. La prueba es simple: haz ping a tu propia puerta de enlace y a un destino público al mismo tiempo. Si la puerta también es inestable, es tu wifi o tu router. Si la puerta es estable y el destino público no, es congestión en la salida del operador. Esa distinción ahorra una conversación inútil con soporte.

Un detalle más: el número que reporta el navegador incluye resolución DNS, handshake TCP y negociación TLS. Mide solo el handshake con curl y compáralo con la cifra de la página: cuanto mayor sea la diferencia, más cuesta la primera visita y más vale la pena un preconnect.

Un equipo migra a un CDN, ve un 92% de aciertos en el panel y a la semana recibe quejas de que el sitio va más lento. Ambas cosas son ciertas y ninguna es el número que creen estar mirando.

6. Empieza por lo que sí es cacheable

Casi todos los CDN traen una regla por extensión: imágenes, fuentes, CSS y JS se cachean; el HTML no. Por eso un sitio puede lucir una tasa global sana mientras cada navegación sigue yendo al origen. El panel está promediando un millón de peticiones de favicon con mil documentos.

En Cloudflare el comportamiento por defecto es exactamente ese, así que el HTML vuelve como DYNAMIC salvo que una Cache Rule diga lo contrario. La solución es una regla acotada a la ruta del documento y un Cache-Control que declare la intención: public, un s-maxage corto y una ventana de stale-while-revalidate.

7. Lee la cabecera antes que el panel

Abre las herramientas de desarrollo, busca la petición y mira cf-cache-status. HIT vino del borde. MISS fue al origen y puede haberse guardado. EXPIRED estaba pero caducó. REVALIDATED se revalidó con el origen. BYPASS significa que algo se saltó la caché, normalmente una cookie, una regla o el método. DYNAMIC significa que la plataforma considera la respuesta no cacheable. Cuatro de esos seis estados significan "no fue un acierto", y solo uno es un fallo.

8. Cuatro cosas que desactivan la caché en silencio

• Un Set-Cookie en una respuesta cacheable. Casi todos los CDN se niegan a guardarla, porque filtraría la sesión de un usuario a otro. Basta una cookie de analítica en la plantilla del HTML.
• Vary: Cookie. Aunque no establezcas ninguna, declarar que la respuesta varía por ella convierte a cada visitante en una clave distinta.
• Una URL única por visita. Ids de sesión, marcas de tiempo anticaché o cada parámetro utm en la ruta convierten una página en miles de entradas que aciertan una vez cada una.
• Cache-Control: private o no-store, a menudo por un valor por defecto del framework o por una regla escrita durante un incidente y nunca retirada.

9. Una tasa alta no es el objetivo

Puedes llegar al 99% cacheando las páginas un día. También servirás los precios de ayer. La pregunta útil no es cuántas peticiones salieron de caché, sino cuántas salieron de caché y seguían siendo correctas. Un 70% con una ventana de revalidación sensata supera a un 99% que exige purgar a mano cada vez que alguien edita una página.

Mídelo por ruta, no por sitio. El índice del blog y un panel con sesión viven en el mismo número y no tienen nada que ver: promediados, esconden ambos problemas. Muestrea los registros por plantilla de ruta y mira las diez peores, no la media global.

10. La otra mitad de la latencia

Un acierto sigue costando un viaje de ida y vuelta al nodo de borde más cercano, y ese nodo lo elige anycast, no tu base de datos. Si tu origen está en una sola región, un fallo de caché desde el otro lado del mundo son dos viajes largos, no uno. Ahí es donde un CDN ayuda de verdad, y donde una caché bien configurada deja de ser una optimización y pasa a ser la diferencia entre 40 ms y 400 ms.

ipbox.one indica la ubicación de borde (colo) que respondió a tu petición, junto a las muestras de latencia, para que sepas si el número medido es tu última milla o un nodo al otro lado de un océano.