Si hay nodos CDN en Sudamérica, ¿por qué el sitio web sigue cargando lento?

Se ha implementado un CDN en Sudamérica, pero el sitio web sigue siendo lento. Por lo general, hay que revisar tres aspectos: si los visitantes se conectan a un nodo adecuado, si las solicitudes se atienden desde la caché y si la conexión con el servidor de origen funciona correctamente cuando no hay una coincidencia en caché. Que el mapa de distribución de nodos muestre puntos de presencia en Sudamérica solo indica que existe capacidad para prestar el servicio; no demuestra que una visita concreta haya recibido una aceleración efectiva.

Al investigar el problema, primero conserve la página específica, la hora de acceso, la ciudad y el operador de red; después, revise las solicitudes de red del navegador. Basarse únicamente en que «un cliente de Brasil dice que va lento» o en los resultados de una prueba de velocidad realizada en China dificulta distinguir entre problemas de la ruta de red, del tiempo de respuesta del servidor o del rendimiento de la propia página.

Primero, distinga si la lentitud está en la conexión, en el primer byte o en la visualización de la página

Abra el panel Network de las herramientas para desarrolladores del navegador, desactive la caché del navegador y vuelva a cargar la página. Observe sobre todo el documento de la página, la imagen principal de la primera pantalla y los scripts principales. Así será más fácil distinguir el efecto de la caché local del navegador del de la caché del CDN.

• El tiempo de DNS, conexión o TLS es considerable: revise primero la resolución del dominio, la selección del nodo y la ruta de acceso.
• El tiempo de espera hasta el primer byte es prolongado: puede deberse al procesamiento en el borde, a una falta de coincidencia en la caché, a la red de retorno al origen o al procesamiento del servidor de origen; no debe atribuirse directamente al rendimiento del servidor.
• El documento carga rápido, pero el contenido tarda en aparecer: revise las imágenes grandes, los scripts que bloquean la representación, las fuentes y los componentes de terceros.

Por ejemplo, si el texto de una página de producto ya aparece, pero la imagen principal tarda en cargarse, revise la solicitud de la imagen en lugar de seguir modificando la caché del documento de la página web. Si toda la página espera la primera respuesta, investigue la ruta entre el CDN y el servidor de origen.

Que haya nodos en Sudamérica no significa que las solicitudes lleguen al lugar adecuado

La interconexión de red varía entre los distintos países, ciudades y operadores de Sudamérica. Que un nodo esté geográficamente más cerca no significa que la ruta de acceso sea necesariamente mejor; algunas redes pueden desviarse por otras regiones. La selección del nodo también puede verse afectada por el DNS recursivo, la interconexión entre operadores y la carga de los nodos.

Primero, confirme en la consola del CDN que el dominio del servicio está habilitado para la región de destino. Después, revise la configuración del DNS autoritativo y compruebe que los resultados de resolución obtenidos localmente cumplan los requisitos del proveedor. Si utiliza CNAME para la conexión, asegúrese de que el registro no siga apuntando a la plataforma anterior o al servidor de origen.

A continuación, combine el identificador del nodo en los encabezados de respuesta, los registros del CDN y las pruebas locales para confirmar desde dónde se procesó realmente la solicitud. El significado del identificador varía según la plataforma: no se base únicamente en una base de datos de geolocalización de IP ni considere que una prueba de ping representa la experiencia completa de navegación.

Las pruebas deben abarcar las principales ciudades y redes donde se encuentran los clientes. Si la misma página funciona con normalidad en una conexión fija, pero va lenta en una red móvil, conviene investigar más a fondo la ruta del operador. Si IPv6 está habilitado, compare también IPv4 e IPv6 por separado para evitar que un problema en una de las rutas quede oculto por los valores promedio generales.

Una tasa de aciertos de caché alta no significa que esta página haya sido atendida desde la caché

La tasa global de aciertos que muestra la consola puede verse elevada por un gran número de imágenes pequeñas, mientras que las páginas de destino de anuncios y los detalles de productos siguen recurriendo con frecuencia al servidor de origen. Consulte el estado de caché de las solicitudes lentas concretas. Algunos indicadores habituales son Cache-Control, Age y los indicadores de acierto que proporciona la plataforma; deben interpretarse conforme a las reglas de cada plataforma.

Entre las situaciones que provocan solicitudes repetidas al servidor de origen se incluyen las siguientes: el servidor de origen devuelve private o no-store; las solicitudes que incluyen Cookie activan una regla de omisión de caché; los parámetros de la URL forman parte de la clave de caché; o las versiones multilingües y móviles se dividen en demasiadas copias en caché. Las páginas con poco tráfico también pueden volver a solicitarse al origen si la caché caduca o se elimina.

En las campañas de marketing para el comercio exterior, preste especial atención a los parámetros de seguimiento de anuncios. Si una misma página de destino con parámetros distintos genera una caché independiente para cada URL, disminuye la tasa real de reutilización. Puede ajustar la clave de caché para excluir parámetros de seguimiento que se haya confirmado que no afectan al contenido, pero no ignore los parámetros que determinan el idioma, la moneda, las especificaciones o la identidad del usuario.

Antes de optimizar la caché, defina claramente los límites del contenido. Las imágenes, hojas de estilo y scripts públicos suelen admitir tiempos de caché más largos; el envío de consultas, el carrito de compra, el estado de inicio de sesión y los precios personalizados deben configurarse por separado. Forzar la caché de todas las solicitudes puede provocar que se mezclen datos o que los envíos fallen.

Si las solicitudes atendidas desde la caché son rápidas y las demás son lentas, siga investigando la ruta hacia el origen

Realice varias solicitudes del mismo recurso desde la misma región y en momentos similares, y compare los tiempos junto con el estado de acierto de la caché. Si las solicitudes sin acierto tardan claramente más y las atendidas desde la caché vuelven a la normalidad, centre la investigación en el acceso al servidor de origen. La lentitud de la primera visita también puede deberse a la resolución DNS o al establecimiento de la conexión, por lo que no conviene sacar conclusiones basándose únicamente en la sensación de dos cargas.

Analice por separado el tiempo de acceso al origen: ¿el nodo perimetral tarda en conectarse al servidor de origen o el servidor tarda en generar el contenido después de recibir la solicitud? En el primer caso, revise la región del servidor de origen, la red entre regiones, la reutilización de conexiones y el cortafuegos del servidor de origen. En el segundo, consulte los registros de la aplicación y las consultas a la base de datos, y compruebe si la página llama de forma síncrona a otras interfaces.

Si el servidor de origen está en Asia y la mayoría de los clientes se encuentra en Sudamérica, las solicitudes dinámicas pueden seguir soportando una latencia prolongada en las comunicaciones entre regiones. Añadir caché para contenido estático no elimina esta espera. Según las necesidades del negocio, se pueden evaluar servidores de origen regionales, caché en capas u optimización de rutas dinámicas; sin embargo, al migrar servidores también hay que tener en cuenta otros mercados, la sincronización de datos y los costes operativos.

La página puede abrirse, pero los componentes de marketing aún pueden ralentizar la experiencia

Cuando la creación de sitios web, el SEO, la publicidad y la captación en redes sociales utilizan el mismo sitio, es posible que el chat de atención al cliente, los vídeos incrustados, los scripts de análisis, las fuentes y las interfaces de formularios provengan de distintos dominios. Conectar el sitio principal a un CDN no acelera automáticamente estas solicitudes externas.

Use el gráfico de cascada de solicitudes para identificar las dependencias de la primera pantalla. Priorice la compresión de la imagen principal, la publicación de imágenes adaptadas al tamaño de la pantalla y la carga diferida de componentes no esenciales. No elimine los códigos de seguimiento solo para mejorar la puntuación de velocidad: compruebe que, tras los cambios, sigan funcionando correctamente la atribución de anuncios, los formularios de consulta y el proceso de compra.

Conserve una comparación de antes y después de cada modificación: use la misma región, red y página, registre el rendimiento tanto con aciertos como sin aciertos de caché y compruebe también el envío de formularios y la actualización del contenido clave. Al pedir ayuda al proveedor de servicios, incluya la hora de acceso, la URL solicitada, el identificador del nodo, el estado de la caché y el número de seguimiento de la solicitud para que el problema pueda localizarse más rápidamente en el punto concreto.

Solo hay motivos claros para cambiar de CDN cuando las pruebas demuestran que la red de los principales clientes sigue dirigiéndose a nodos inadecuados o que no es posible mejorar la calidad de la interconexión local. Si el cuello de botella está en las interfaces dinámicas, las reglas de caché o los scripts de terceros, primero corrija el componente correspondiente y, después, evalúe si la cobertura de nodos es suficiente.