¿Cómo investigar por qué los clientes de México tardan más de 5 segundos en acceder al sitio web?

Si un cliente en México informa que el sitio web tarda más de 5 segundos en abrirse, no significa necesariamente que el servidor tenga un rendimiento insuficiente. También puede deberse a la red internacional, a que no se encuentre el contenido en la caché o a que los scripts publicitarios ralenticen la página. Al atender una incidencia posventa, el paso que más fácilmente puede llevar por el camino equivocado es cambiar directamente de servidor: si el tiempo se consume en descargar imágenes o ejecutar scripts en el navegador del cliente, la migración quizá no resuelva el problema. Primero confirme «dónde se produce la lentitud» y después decida qué cambiar.

Convierta los «5 segundos» que menciona el cliente en un problema reproducible

Para determinar por qué el sitio web tarda más de 5 segundos en cargarse para un cliente en México, normalmente hay que tener en cuenta la página concreta y las condiciones de acceso. Cuando el cliente dice que la página ha terminado de cargar, puede referirse a que ya ve la primera pantalla o a que ya se han mostrado todas las imágenes y la ventana de chat. Cada caso requiere una línea de investigación distinta. Pida al cliente la URL, la hora en que ocurrió el problema, la ciudad donde se encuentra, el modelo del dispositivo, el navegador, el tipo de conexión y si se queda en una pantalla en blanco o si el contenido de la primera pantalla tarda en aparecer completo. Si es posible, una grabación de pantalla resulta más útil que decir simplemente «el sitio va muy lento».

A continuación, pruebe la misma URL en la página de inicio, la página de producto indicada por el cliente o la página de destino del anuncio, y distinga entre la primera visita y las visitas posteriores. En la medida de lo posible, incluya pruebas con redes móviles y fijas locales. Si solo puede realizar una simulación remota, registre también el nodo de prueba y las condiciones de red; no dé por sentado que una medición hecha en la oficina en China refleja la experiencia real de un cliente en México.

Compruebe también si la URL de prueba contiene parámetros publicitarios, una ruta de idioma o redireccionamientos. El enlace real tras hacer clic en un anuncio puede ser distinto de la página de inicio introducida directamente. Pasar por alto este detalle suele dar lugar a casos en los que «las pruebas del servicio posventa salen bien, pero el acceso del cliente sigue siendo lento». Si hay información de cuentas o datos personales de clientes, anonimice primero las capturas de pantalla y los registros.

Analice la ruta de acceso por partes: ¿la conexión es lenta o lo es la representación de la página?

Abra el panel de red de las herramientas para desarrolladores del navegador, borre la caché y vuelva a cargar la página. Examine el gráfico de cascada de solicitudes. Empiece por la resolución del dominio, el establecimiento de la conexión y la solicitud del primer documento; después, revise los recursos, como las imágenes y los scripts. Comparar el tiempo de cada etapa facilita más la identificación de lo que hay que corregir que fijarse únicamente en el tiempo total de carga.

La respuesta del primer documento es lenta: Revise la resolución del dominio, la conexión, los redireccionamientos y el tiempo de procesamiento del servidor. El tiempo hasta el primer byte, es decir, TTFB, refleja la espera desde que se inicia la solicitud hasta que se recibe el primer byte de la respuesta. Sin embargo, puede incluir tanto el tiempo de red como el del servidor, por lo que este dato por sí solo no permite concluir que la base de datos sea lenta. Continúe desglosando los tiempos con los registros del servidor, el tiempo de respuesta de la aplicación y los resultados de pruebas realizadas desde distintas regiones.

La respuesta del documento es normal, pero el contenido de la primera pantalla sigue tardando en aparecer: Revise las imágenes grandes de la primera pantalla, las hojas de estilo, las fuentes y los scripts que bloquean la representación. Por ejemplo, si un sitio web de equipos para comercio exterior utiliza directamente como banner una imagen de producto sin comprimir, el teléfono móvil tendrá que descargar un archivo grande y, además, decodificarlo para mostrarlo. Que la página se abra no significa que el cliente ya pueda ver el contenido principal.

La primera pantalla ya aparece, pero la página sigue indicando que está cargando: Compruebe si alguna herramienta de análisis de terceros, código de conversión de anuncios, servicio de atención al cliente en línea o solicitud de vídeo tarda demasiado en completarse. Observe también si se pueden usar los botones y los formularios: que el icono de carga siga girando no siempre significa que el cliente no pueda navegar, pero si la ejecución de scripts ocupa todo el hilo principal, es posible que la página se vea pero no responda a los clics.

Si el acceso desde México es lento, compruebe primero estos puntos

La ruta de red internacional es un aspecto habitual que conviene investigar, pero no se debe atribuir el problema simplemente a la «distancia». La ubicación del servidor de origen, las rutas de los operadores, la selección de nodos y la red que utiliza el cliente en ese momento pueden afectar al resultado. Si las pruebas realizadas desde varios puntos de México muestran tiempos largos durante la conexión o la descarga, mientras que en otras regiones el rendimiento es relativamente normal, compruebe si la red de distribución de contenidos (CDN) cubre la región de acceso objetivo, si el dominio está configurado correctamente y cuál es el estado de la caché indicado en los encabezados de respuesta. Los indicadores del estado de la caché pueden variar según el proveedor; consulte su documentación.

No se limite a confirmar que «la CDN está activada». Es posible que las imágenes de producto estén en caché, pero que las páginas HTML vuelvan al servidor de origen en cada visita. Los enlaces publicitarios con parámetros de consulta también pueden dar resultados distintos según las reglas de caché. Al revisar la configuración, distinga entre recursos estáticos y páginas dinámicas: las imágenes y las hojas de estilo suelen poder almacenarse en caché de acuerdo con una política de actualización, mientras que el contenido que incluye el estado de inicio de sesión, el carrito de compra o los datos del cliente no debe almacenarse en una caché pública sin más. Antes de hacer cambios, confirme la clave de caché, el método de invalidación y las reglas de acceso al servidor de origen.

En cuanto a los recursos de la página, empiece por los archivos que, según el gráfico de cascada, sean grandes, se carguen pronto y afecten a la primera pantalla, en lugar de comprimir indiscriminadamente todas las imágenes. Genere imágenes según el tamaño en que se mostrarán y active la carga diferida para las imágenes que no estén en la primera pantalla. Por lo general, no conviene aplicar la carga diferida sin criterio a la imagen principal de la primera pantalla, ya que esto puede retrasar la aparición del contenido principal. Como alternativa, se puede sustituir el fondo de vídeo por una imagen de portada y cargar el vídeo cuando el usuario interactúe, una opción especialmente adecuada para páginas de destino de anuncios en dispositivos móviles.

En los sitios web multilingües, compruebe también los redireccionamientos de idioma. Si un visitante de México llega primero a la página de inicio en el idioma predeterminado y, tras la detección de la región, se le redirige a la página en español, los redireccionamientos adicionales aumentan el tiempo de espera. Una opción más fiable es hacer que los enlaces de anuncios y redes sociales apunten directamente a la página de destino en el idioma correspondiente, y mantener a la vez una opción clara para cambiar de idioma. Si las rutas existentes afectan a la indexación en buscadores o a los enlaces de campañas, compruebe los redireccionamientos y la configuración del seguimiento antes de modificarlas.

Evite que la optimización afecte también a las consultas comerciales y a la atribución de anuncios

El desarrollo del sitio web, el SEO y la publicidad suelen estar a cargo de personas distintas, por lo que los problemas con los scripts pueden repetirse fácilmente. Un caso habitual es que una página de destino acumule varias herramientas de análisis, etiquetas de conversión publicitaria y complementos de atención al cliente en línea. Cada elemento puede tener una función por separado, pero en conjunto pueden ralentizar la primera pantalla. Antes de actuar, enumere quién es responsable de cada script y cuál es su función. Elimine primero los códigos que se haya confirmado que están en desuso o duplicados y después valore cuáles se pueden cargar de forma diferida.

Retrasar la ejecución no está exento de consecuencias: si se carga demasiado tarde, es posible que no se registren conversiones o que se vean afectados los formularios y las funciones de atención al cliente. Se recomienda hacer los cambios uno por uno en un entorno de prueba. Tras la publicación, compruebe que se conservan los parámetros publicitarios, que se pueden enviar los formularios, que llegan las notificaciones de consultas comerciales y que los eventos de conversión se activan según lo previsto. En proyectos que utilizan plataformas integradas de creación de sitios web y marketing, como 易营宝, confirme también si la configuración correspondiente la gestiona la plataforma o el cliente, para evitar cambios duplicados o la eliminación accidental de códigos de seguimiento.

Tras la corrección, vuelva a probar en las mismas condiciones y conserve las pruebas

En las pruebas posteriores a la corrección, procure usar la misma página, región, dispositivo y condiciones de red que en la prueba original, y registre por separado el rendimiento de la primera visita y el de las visitas en las que se utiliza la caché. Además del tiempo total de carga, compare el tiempo hasta el primer byte, el momento en que aparece el contenido principal de la primera pantalla y la posibilidad de hacer clic y enviar formularios. Una sola prueba solo refleja lo ocurrido en ese momento. Si los resultados varían mucho, repita las pruebas en distintos horarios y conserve el gráfico de cascada de solicitudes y los encabezados de respuesta relevantes.

Si solo algunos clientes experimentan lentitud en una red específica y otras redes locales funcionan con normalidad, pídales que comprueben el acceso alternando entre una red móvil y una fija. Después, envíe los resultados de resolución y la información sobre las solicitudes fallidas al proveedor de servicios de red para que los investigue. Si el problema se reproduce de forma persistente en varios puntos de acceso, asigne cada caso al equipo responsable del servidor, del sitio web o de la publicidad según las pruebas disponibles. Un ticket que indique claramente la URL afectada, la hora, las condiciones de prueba y los aspectos ya descartados suele facilitar más el seguimiento que una solicitud imprecisa para «acelerar el sitio web».