¿Cómo investigar la carga lenta en algunas regiones según los comentarios de clientes internacionales? El personal de mantenimiento puede empezar midiendo la velocidad por región y, después, identificar gradualmente los posibles cuellos de botella en el DNS, la CDN y el servidor. Lo fundamental es comparar los datos de acceso de distintas regiones para determinar en qué etapa se produce la demora.
La lentitud en algunas regiones no siempre se debe a un rendimiento insuficiente del servidor; también puede estar relacionada con las rutas de los operadores locales, las tasas de aciertos de caché o los scripts de terceros. Primero, conserve las pruebas del incidente y, después, revise la ruta de acceso paso a paso para evitar cambios innecesarios y comunicaciones repetidas.
Se recomienda seguir el proceso «reproducir el problema, desglosar los tiempos, comprobar las hipótesis y volver a probar para cerrar el caso». En cada paso, registre la región de prueba, la red, la hora y la página para que los resultados puedan compararse y sea más fácil informar al cliente sobre los avances.
Primero, aclare «en qué región y de qué manera» se produce la lentitud
Cuando reciba un informe, recopile primero el país y la ciudad del cliente, el operador de red, la URL visitada, la hora del incidente y la zona horaria. Confirme también si utiliza un teléfono o un ordenador y una red móvil o de oficina, para evitar confundir un problema de una sola red con una incidencia regional.
Pida al cliente que describa lo que ocurre concretamente: si el dominio tarda mucho en responder, la página queda en blanco, el texto aparece primero y las imágenes tardan en cargarse, o el envío de un formulario se queda esperando. Cada síntoma apunta a una línea de investigación distinta; no basta con describirlo como «el sitio web carga lento».
Pruebe la misma página desde la región del cliente, desde otra ciudad de la misma región y desde una región donde no haya problemas. Dé prioridad a navegadores locales reales o a nodos de prueba regionales fiables, e indique el operador del nodo. No se base únicamente en el nombre del país para determinar la cobertura.
Repita la prueba de tres a cinco veces en cada nodo y registre por separado los resultados de la primera visita y de las visitas posteriores. Incluya la página de inicio, una página de detalles de producto y una página de consultas. Si el problema solo aparece en determinadas franjas horarias, realice nuevas mediciones dentro del horario indicado por el cliente.
Consulte el gráfico de cascada de carga para determinar dónde se consume el tiempo
Utilice el panel Red de las herramientas para desarrolladores del navegador, conserve el registro de solicitudes y observe cuánto tardan el documento principal y los recursos esenciales. Primero, distinga entre la resolución del dominio, el establecimiento de la conexión, la espera hasta el primer byte y la descarga de recursos; después, determine si la lentitud se debe a la ruta de red o a la propia página.
Si la resolución del dominio tarda mucho, revise primero el DNS. Si la conexión o el protocolo de enlace seguro tardan demasiado, compruebe las rutas, la pérdida de paquetes y la reutilización de conexiones. Si aumenta considerablemente la espera hasta el primer byte, investigue el tiempo de respuesta del CDN al servidor de origen, el procesamiento de la aplicación y la respuesta de la base de datos.
El tiempo hasta el primer byte incluye la latencia de red y la espera del servidor; un valor alto no demuestra por sí solo que la capacidad de procesamiento del servidor sea insuficiente. Si el documento principal carga rápido, pero la primera pantalla tarda en aparecer, compruebe especialmente las imágenes grandes, los scripts que bloquean la carga, las fuentes y la carga de renderizado del navegador.
Si dispone de una línea de comandos, puede usar curl para registrar los tiempos de resolución, conexión, protocolo de enlace TLS, primer byte y duración total. Algunos campos muestran el tiempo acumulado desde el inicio de la solicitud. Para evaluar el tiempo de cada etapa, calcule las diferencias; no los sume directamente como si fueran tiempos independientes.
Si solo algunas regiones presentan lentitud, revise primero el DNS y la CDN
Compare los resultados de resolución de las regiones afectadas con los de las regiones normales y compruebe si hay registros no válidos, enrutamiento geográfico incorrecto o una cadena de resolución demasiado larga. Que se devuelvan direcciones distintas según la región puede ser normal; evalúelo en función de la conectividad real y los tiempos de acceso.
Si se han modificado recientemente los registros DNS, compruebe los registros autoritativos, las cachés de los resolutores recursivos y el tiempo de propagación. No dé por hecho que el servicio se ha restablecido en todo el mundo solo porque ya puede acceder desde su ubicación local. Tampoco cambie los registros DNS repetidamente, ya que las diferencias entre cachés pueden dificultar aún más el diagnóstico.
Consulte en la consola de la CDN y en los encabezados de respuesta el nodo perimetral, el estado de la caché, la tasa de aciertos y el tiempo de respuesta del servidor de origen. Si los recursos estáticos de las zonas lentas no encuentran continuamente una coincidencia en la caché, compruebe si las reglas de caché, los parámetros de consulta, las cookies o los encabezados de respuesta del servidor de origen están afectando al almacenamiento en caché.
Si la lentitud solo afecta a determinados operadores, proporcione al proveedor de CDN la hora, la URL, la información del nodo y el identificador de la solicitud. El trazado de rutas puede ayudar a localizar el problema, pero que un nodo intermedio no responda o limite el tráfico de sondeo no significa que las solicitudes reales del servicio pierdan paquetes en ese punto.
¿Cómo distinguir entre la lentitud del servidor de origen y la de los recursos de la página?
Si el tiempo hasta el primer byte aumenta simultáneamente en varias regiones y también se incrementa el tiempo de respuesta de la CDN al servidor de origen, consulte los registros del servidor de origen para comprobar el tiempo de respuesta de la aplicación. Correlacione los registros de solicitudes del mismo intervalo con las API lentas, la tasa de errores, las consultas lentas a la base de datos y el uso del pool de conexiones.
Compruebe también si hay cuellos de botella persistentes en la CPU, la memoria, las operaciones de lectura y escritura del disco o el ancho de banda. No se base en el uso registrado en un único momento: compárelo con las tendencias durante el incidente y confirme si los cambios de carga guardan relación con campañas publicitarias, visitas de rastreadores o tareas por lotes.
Para comparar el acceso a través de la CDN con la respuesta del servidor de origen, el personal de mantenimiento debe trabajar en un entorno controlado y mantener iguales el dominio, el certificado y las condiciones de la solicitud. Los resultados obtenidos al omitir la CDN sirven únicamente como ayuda para el diagnóstico; no se deben pasar por alto las diferencias de caché ni el efecto de las políticas de seguridad sobre la respuesta.
Si el documento principal carga con normalidad, pero las imágenes tardan en descargarse, compruebe su tamaño, formato y dimensiones. Si los recursos ya se han descargado, pero la página sigue bloqueándose, revise la ejecución de los scripts y la carga del hilo principal. La imagen principal de la primera pantalla debe cargarse con prioridad; considere la carga diferida para las imágenes que aparecen más abajo.
No pase por alto las herramientas de chat, las fuentes y los scripts de marketing
Los sitios web de marketing internacional suelen integrar chat en línea, seguimiento publicitario, mapas, vídeos y servicios multilingües. Si el acceso a un dominio de terceros es inestable en una región, puede hacer que algunas funciones tarden en responder e incluso que un script síncrono bloquee la visualización de toda la página.
En un entorno de pruebas o de forma local en el navegador, bloquee una a una las solicitudes sospechosas y compare el tiempo de visualización de la primera pantalla y el de interacción. Si desactivar un servicio restablece el funcionamiento, compruebe si forma parte de la ruta de carga crítica antes de decidir si debe cargarse de forma asíncrona, con retraso o sustituirse.
Al optimizar los scripts de marketing, valide al mismo tiempo las estadísticas, las conversiones publicitarias y las funciones de consulta para evitar que la página cargue más rápido a costa de perder datos comerciales. En los formularios de consulta, pruebe también por separado la respuesta de la API y el mensaje de confirmación; no dé por concluida la investigación solo porque la página se abra.
Si utiliza plataformas de creación de sitios web y marketing como 易营宝, recopile la información del sitio, la página, la región y las solicitudes anómalas para enviársela al equipo de asistencia técnica. Aclare primero el ámbito de mantenimiento de la plataforma, la CDN, el proveedor del dominio y los plugins de terceros para facilitar la coordinación.
¿Cuándo se puede considerar resuelto el problema?
Modifique una sola variable principal cada vez y registre la hora del cambio, la configuración aplicada y el método para revertirlo. Después del cambio, vuelva a probar desde la misma región, red y página, y compare la mediana y los cambios en las solicitudes más lentas. Así evitará considerar una visita rápida aislada como prueba de que el problema se ha resuelto.
La validación debe incluir la visualización de la primera pantalla, la interacción con la página, la carga de imágenes y el envío de formularios. Pida al cliente que informó del problema que vuelva a comprobarlo. Si dispone de monitorización de usuarios reales, observe las tendencias por país, dispositivo y red para compensar las diferencias entre los nodos de prueba y el entorno real del cliente.
Para identificar la causa de la carga lenta en algunas regiones internacionales, lo fundamental es usar datos comparativos para acotar el problema al DNS, la ruta de red, la caché, el servidor de origen o los recursos de la página. Al cerrar el caso, informe de las pruebas del problema, las medidas adoptadas, los resultados de las nuevas pruebas y los aspectos que todavía deben vigilarse, para completar el ciclo de resolución de la incidencia.
