Una CDN guarda copias de tus archivos en muchos sitios y sirve a cada visitante desde el más cercano. Eso elimina la distancia, y la distancia es real: una petición desde El Cairo a un servidor en Alemania cuesta unos 60 ms antes de que se calcule nada, y eso en cada archivo.

Lo que arregla de verdad

  • La latencia de los archivos estáticos —imágenes, CSS, JavaScript, tipografías— para los visitantes lejanos a tu servidor.
  • Los picos de ancho de banda, porque el origen sirve cada archivo una vez en lugar de una vez por visitante.
  • Un escudo tosco pero eficaz frente a las avalanchas de tráfico.
  • La negociación TLS, que ocurre cerca del visitante en lugar de al otro lado de un océano.

Lo que no arregla

  • Una consulta lenta. El HTML sigue viniendo de tu servidor, y sigue siendo lento.
  • Una página que no se puede cachear porque es personal de cada visitante.
  • Una primera visita a un nodo frío, que paga el viaje completo de todas formas.

Lo que esconde

Esta es la parte que le cuesta tiempo a la gente. Con una CDN delante, tus propias pruebas salen rápidas porque siempre das con una copia en caché, mientras que un cliente con sesión iniciada en una página no cacheable recibe la respuesta real, la lenta. Mide el origen directamente cuando busques un cuello de botella.

curl -sS -o /dev/null -w 'origin ttfb %{time_starttransfer}\
' \
     --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com/

Dos cosas que hay que dejar bien desde el primer día

  • La IP real del visitante. Todos los registros y todos los límites de peticiones ven la CDN mientras no lo configures: consulta Cloudflare y la IP real del visitante.
  • El purgado. Aprende a limpiar un solo archivo y a limpiarlo todo antes de que un despliegue lo necesite.
No pongas una CDN delante de un panel de administración ni de una API que se autentica por cabecera. Cachear ahí es una fuga de datos, no una ganancia de velocidad.