¿Se puede evaluar la cobertura global de una CDN solo por el número de nodos?

La cobertura global de CDN no debe evaluarse únicamente por el número de nodos. El número total de nodos indica la escala de la infraestructura, pero no permite saber directamente si los clientes objetivo podrán acceder al sitio web de forma estable y rápida. Al elegir una solución, resulta más útil determinar a qué ubicación se dirigirán los usuarios de los mercados objetivo, por qué redes circulará el tráfico y si la conexión con el servidor de origen será fluida cuando no haya contenido en caché.

Para evaluar una solución de CDN global, conviene desglosar la «cobertura global» en cobertura de las regiones objetivo, accesibilidad a través de los operadores y rendimiento medido en condiciones reales. Aunque dos proveedores anuncien un número de nodos similar, el acceso puede variar notablemente en una misma conexión de banda ancha fija o red móvil de un país.

Primero hay que unificar los criterios de recuento de nodos

El término «nodo» puede referirse, según el proveedor, a un centro de datos físico, un punto de presencia perimetral o varias unidades de despliegue dentro de una misma ciudad. Un punto de presencia (PoP) y el número de servidores no son el mismo indicador, por lo que las cifras calculadas con criterios distintos no se pueden comparar directamente.

También es importante confirmar si los recursos anunciados están disponibles para el plan y las funciones que se prevé contratar. Algunas ubicaciones ofrecen acceso al tráfico o protección de seguridad, pero no necesariamente las mismas capacidades de almacenamiento en caché; otras regiones pueden estar sujetas a cargos adicionales o requisitos de activación. Por ello, un mapa global de nodos solo sirve como punto de partida para la selección y no sustituye a una descripción del alcance de los servicios disponibles.

Es más útil pedir al proveedor las ubicaciones de acceso disponibles en los países y ciudades objetivo, las funciones compatibles y las limitaciones del plan que solicitar un número total de nodos más elevado. Si la actividad se concentra en Europa y Norteamérica, la densidad de nodos en otras regiones no debería otorgar puntos adicionales a una solución. Si los mercados prioritarios incluyen el Sudeste Asiático, Oriente Medio o América Latina, cada región debe verificarse por separado; una cobertura continental no basta para describir el rendimiento local.

Una distancia geográfica corta no significa una ruta de red corta

Entre el usuario y el nodo perimetral también intervienen las interconexiones entre operadores, la transmisión entre redes y las decisiones de enrutamiento. Aunque el nodo esté en una ciudad cercana, si el operador del usuario debe desviar el tráfico por otras regiones para llegar a él, el resultado puede ser peor que el de un nodo geográficamente más lejano con una interconexión más directa.

El mecanismo de enrutamiento también afecta a la calidad de la cobertura. El enrutamiento basado en DNS puede verse afectado por la ubicación del solucionador recursivo; Anycast utiliza el enrutamiento de red para dirigir las solicitudes a un punto de acceso, pero eso no significa que siempre se obtenga la latencia más baja. No se debe asumir que el acceso global será mejor únicamente porque se utilice una tecnología determinada.

Para determinar si la cobertura es adecuada, hay que comprobar qué punto de acceso reciben realmente las redes objetivo, así como el tiempo de conexión, la pérdida de paquetes y las fluctuaciones durante las horas punta. Si es necesario, se puede recurrir al seguimiento de rutas para ayudar a localizar el problema, pero la falta de respuesta de un router intermedio o la pérdida de paquetes en un salto no deben considerarse directamente un fallo del enlace del servicio. La evaluación final debe basarse en el resultado de extremo a extremo.

La velocidad de las solicitudes atendidas desde la caché no representa la velocidad de todo el sitio

En las demostraciones de CDN suele ser fácil mostrar la aceleración de archivos estáticos, pero los sitios web internacionales no constan únicamente de imágenes y hojas de estilo. Las páginas de detalles de productos, las páginas en varios idiomas, las búsquedas internas, los formularios de consulta y los carritos de compra pueden utilizar distintas políticas de caché o incluso requerir acceso en tiempo real al servidor de origen.

Cuando hay una coincidencia en la caché, la solicitud circula principalmente entre el usuario y el nodo perimetral. Cuando no la hay, también debe recorrer el trayecto entre el nodo perimetral y el servidor de origen. Si el servidor de origen está lejos de los principales mercados o la red de retorno es inestable, la primera visita y las páginas con poco tráfico seguirán siendo lentas. Añadir nodos tampoco garantiza que todo el contenido esté almacenado en caché en cada región ni elimina automáticamente los cuellos de botella en la conexión con el servidor de origen.

Las pruebas de selección deben distinguir entre caché caliente, caché fría y solicitudes dinámicas. La caché caliente permite comprobar la entrega desde el nodo perimetral; la caché fría permite observar la conexión con el servidor de origen. Las solicitudes dinámicas permiten verificar si la reutilización de conexiones y las optimizaciones de transmisión mejoran realmente el servicio. El almacenamiento en caché por niveles o la optimización de las conexiones con el servidor de origen pueden reducir algunas solicitudes repetidas, pero el resultado depende de la configuración y de las características del contenido; no debe darse por sentado.

También hay que verificar las reglas de gestión de las claves de caché, los parámetros de consulta, las cookies y las versiones por idioma. Una tasa de aciertos elevada no implica necesariamente una configuración correcta: si se comparte en caché por error contenido personalizado, la mejora de velocidad puede generar riesgos operativos o de seguridad de los datos.

Convertir las «promesas de cobertura» en pruebas reproducibles

Las ubicaciones de prueba deben seleccionarse según el tráfico real, la distribución de los clientes y las regiones en las que se prevé hacer campañas, e incluir conexiones de banda ancha fija y redes móviles representativas de cada zona. Los sondas alojadas en servidores en la nube facilitan la supervisión continua, pero no sustituyen por completo a las redes de los usuarios finales. Cuando sea posible, conviene complementarlas con mediciones de usuarios reales.

Al comparar distintas soluciones, mantén lo más constantes posible el servidor de origen, el contenido de los archivos, las reglas de caché y el horario de las pruebas, y registra la ubicación de acceso efectiva y el estado de la caché. No compares los resultados de caché caliente de un servicio con la primera solicitud de otro ni tomes decisiones basándote únicamente en una captura de una prueba de velocidad.

• Desglosar los tiempos: registra la resolución DNS, el establecimiento de la conexión, el protocolo de enlace TLS, el tiempo hasta el primer byte y el tiempo de descarga para evitar atribuir a una cobertura perimetral insuficiente la lentitud del procesamiento en el servidor de origen.
• Revisar el rendimiento en los extremos: además de la mediana, presta atención al P95, la tasa de solicitudes fallidas y la tasa de tiempo de espera, con estadísticas separadas por región y operador. El promedio global puede ocultar problemas en los mercados prioritarios.
• Usar recursos de negocio reales: prueba tanto recursos de página pequeños como imágenes grandes o documentos, además de las interfaces dinámicas que se utilizan realmente. Probar un único archivo pequeño no basta para evaluar todo el sitio.
• Probar el acceso continuado y las incidencias: repite las pruebas en distintos horarios, verifica el cambio a otro nodo o servidor de origen cuando se produzca una incidencia y comprueba si el proceso de recuperación genera errores apreciables.

La experiencia de página también debe evaluarse mediante indicadores del navegador, como LCP. Mejorar el tiempo hasta el primer byte no significa necesariamente que el contenido principal vaya a mostrarse antes. La ejecución de scripts, los componentes de terceros y las estrategias de carga de imágenes también pueden convertirse en cuellos de botella; no se deben atribuir todos los problemas a la CDN.

La elección final debe basarse en un rendimiento verificable en los mercados prioritarios

Los criterios de aceptación deben definirse según la actividad: qué mercados deben cumplir los requisitos, qué latencia y tasa de errores son aceptables y qué funciones dinámicas no deben verse afectadas. No se debe aplicar el mismo umbral en milisegundos a todos los sitios ni permitir que los buenos resultados en regiones no prioritarias compensen deficiencias evidentes en los principales mercados de captación.

También hay que confirmar si el proveedor ofrece registros o datos de supervisión consultables por región, código de estado y estado de la caché, así como mecanismos de diagnóstico y soporte ante incidencias regionales. Una garantía de disponibilidad basada únicamente en cifras generales, sin posibilidad de explicar los fallos en regiones concretas, no basta para evaluar la cobertura global.

El número de nodos es útil para una primera selección. Lo que realmente determina si una solución es adecuada es la estabilidad del acceso a través de los operadores objetivo, el rendimiento de la cadena completa con caché caliente y fría, y la capacidad de detectar y resolver problemas cuando se produce una incidencia. Si el proveedor solo puede mostrar un mapa global y no aporta estas pruebas, no conviene pagar un sobreprecio basándose únicamente en que tiene «más nodos».