Monitoreo de la velocidad web: ¿por qué es importante y cómo utilizarlo eficazmente?

De repente, algo no funciona. Las conversiones caen, los visitantes desaparecen, el sitio web se ralentiza, y no sabes por qué. No has realizado cambios significativos, así que, ¿dónde está el problema?

Quizás tu sitio web ha estado ralentizándose durante meses y no te has dado cuenta. Tal vez implementaste una nueva función la semana pasada que ralentizó páginas clave. O tal vez un código de terceros cambió sin que nadie te avisara. Sin monitoreo, no tienes manera de saber qué está pasando.

El monitoreo de la velocidad web te ofrece una visión general, control y la capacidad de resolver problemas antes de que afecten a tu negocio.

¿Qué encontrarás en este artículo?

1. ¿Por qué es crucial la velocidad del sitio web? Impacto en conversiones, SEO y la satisfacción general del usuario.
2. ¿Cómo te ahorra tiempo y dinero el monitoreo? Retorno de inversión y su impacto directo en el negocio.
3. ¿Qué tipo de monitoreo necesitas? La importancia de combinar diferentes tipos de monitoreo.
4. ¿Por qué los tests únicos no son suficientes? Diferencias entre PageSpeed Insights y el monitoreo continuo.
5. ¿Cómo configurar y usar el monitoreo? Nuestra metodología que ahorra tiempo, dinero y nervios.

Si deseas tener el control de la velocidad de tu sitio web, sigue leyendo.

¿Por qué tener monitoreo de la velocidad web? Negocio del sitio, alto retorno y prevención de desastres#

La velocidad del sitio web es crucial porque puede tener un impacto directo en las conversiones y el tráfico del sitio. Consideremos algunos ejemplos de nuestra experiencia:

• Ayudamos a uno de los mayores proveedores de resultados deportivos, Livesport, a mejorar sus posiciones en Google Ads, ahorrándoles una gran cantidad de presupuesto en PPC.
• Los estudios muestran que la velocidad de respuesta del backend correlaciona con la posición en los resultados de búsqueda de Google, mejorando así el SEO. Algunos de nuestros clientes han experimentado un aumento en el tráfico después de optimizar los Core Web Vitals.
• En un gran sitio de comercio electrónico, medimos que los usuarios cuyo tiempo de carga era alrededor de un segundo tenían 3,5 veces más conversiones que aquellos con un tiempo de carga de 2,5 segundos.

Veamos juntos un gráfico de correlación entre la velocidad (LCP, en amarillo) y la tasa de conversión (CR, en azul):

A menudo, cuanto más rápido carga el sitio para el usuario, más fácil es que se produzca una conversión.

En todos los casos, sin datos no se pueden lograr estos éxitos, ni medirlos. La falta de monitoreo a menudo te lleva a una situación en la que conoces el problema, pero no su causa.

Desastres derivados de la falta de monitoreo#

Quizás piensas que la velocidad de tu sitio web es estable porque no haces cambios que podrían afectarla. Sin embargo, usualmente lo contrario es cierto.

La velocidad del sitio web cambia constantemente, y desafortunadamente, generalmente hacia peor. Durante nuestra práctica de consultoría, a menudo somos testigos de que las métricas Core Web Vitals empeoran incluso con modificaciones aparentemente inocuas:

1. En un cliente nuestro, Innogy, el monitoreo detectó un extraño empeoramiento de la métrica INP tras implementar Server-Side GTM. Gracias a los datos del análisis técnico, pudimos guiar al cliente y sus proveedores analíticos hacia tareas específicas a resolver.
2. Con el monitoreo podemos advertir a nuestros clientes, como la tienda en línea Dr. Max. Por ejemplo, cuando la métrica de estabilidad del diseño (CLS) empeoró debido a un error en una de las páginas.
3. El monitoreo nos mostró un deterioro en la respuesta del servidor (TTFB) en los sitios de una gran plataforma de comercio electrónico, proporcionando a nuestros clientes datos exactos para comunicarse con el soporte.
4. En el podcast checo Fuckupy v IT se cuenta cómo, sin datos de monitoreo, un equipo evaluó incorrectamente la causa del problema y dedicó dos semanas a reescribir una aplicación. El problema, en realidad, era solo una línea de configuración.

Si el deterioro del TTFB es causado por el tráfico de robots, es útil tener una estrategia. Echa un vistazo a nuestro servicio Estrategias para Bots de IA.

Un buen monitoreo te proporciona también datos sobre las causas de los cambios y te guía hacia el lugar específico en el sitio.

La imagen muestra un ejemplo de informe de monitoreo PLUS de PageSpeed.ONE durante una implementación incorrecta de una imagen en la página principal del sitio de noticias iRozhlas.cz:

1. Los datos sintéticos de Watchdog indican un problema con la métrica LCP.
2. Mirando la descomposición de LCP por página, vemos un problema en la página principal en móvil.
3. El detalle de una ejecución específica de la prueba Lighthouse identifica una carga diferida mal configurada lazy loading en la primera imagen.

Sin monitoreo, no notarás los cambios. Sin datos del monitoreo, buscar la causa del deterioro será muy costoso y ralentizará tu trabajo en el desarrollo de nuevas funciones del sitio.

Medición puntual no es monitoreo#

Existen numerosas herramientas populares como nuestro test de velocidad web, PageSpeed Insights, Lighthouse o WebpageTest.org que te muestran resultados únicos de métricas y un análisis del estado técnico de la página.

No confundas las pruebas puntuales con el monitoreo. El monitoreo de velocidad se ejecuta automáticamente, al menos una vez al día, proporcionándote así datos sobre el período en el que no pensaste en realizar una prueba única de velocidad.

¿Por qué no basta con revisar la velocidad de vez en cuando en PageSpeed Insights?

• No sabrás de la mayoría de los problemas.
• No tienes un historial de datos para consultarlo cuando sea necesario.
• No ves patrones y tendencias que se forman en los datos.
• No tienes datos que te guíen hacia una solución fácil del problema.
• No puedes celebrar éxitos cuando hay una mejora.

Las pruebas puntuales en PageSpeed Insights, que realizas solo cuando te acuerdas, probablemente ocultarán problemas y pueden incluso llevarte erróneamente a pensar que la velocidad del sitio está mejorando.

No tienes el control de la velocidad del sitio, aunque pienses que sí#

Un sitio web rápido se logra, entre otras cosas, evitando activamente su ralentización.

Sin embargo, la disminución de la velocidad del sitio es un fenómeno común que tiene sus raíces en que los equipos de desarrollo del sitio generalmente tienen mucho menos control del que creen.

Deterioro inesperado en la respuesta del servidor (TTFB) de una gran plataforma de comercio electrónico centroeuropea. La sintética advierte a tiempo, CrUX proporciona una imagen más precisa del impacto en el usuario. Ahora imagina planificar una campaña para esos días y no tener esta información.

Veamos ahora algunos ejemplos de que el desarrollo moderno de sitios web es mucho más complejo de lo que quizás pienses:

• Los sitios web están compuestos por muchas partes (client-side, server-side) y componentes que a menudo son gestionados por diferentes equipos.
• La velocidad del sitio web a menudo puede ser afectada por el código JavaScript de terceros, que los analistas, comercializadores o UXers insertan a través de GTM. A menudo son proveedores externos.
• Los propios componentes de terceros (medición, publicidad, personalización...) se desarrollan sin tu control y pueden seguir deteriorando la velocidad del sitio durante su desarrollo.
• La velocidad del sitio puede verse afectada por una acción puntual, como una campaña de marketing exitosa o un ataque DDoS dirigido a tu proveedor de infraestructura.
• Los cambios en la velocidad pueden surgir de un cambio en la distribución de la base de usuarios. Tus campañas pueden atraer un nuevo grupo objetivo, como usuarios de dispositivos Android lentos, lo que puede deteriorar repentinamente las métricas de Core Web Vitals.
• Los sitios web, naturalmente, evolucionan con el tiempo y constantemente implementas nuevo contenido o características. Incluso aquellos que parecen inofensivos pueden afectar negativamente la velocidad.

Esta complejidad afecta hoy en día incluso a sitios web relativamente pequeños. El rendimiento web es un campo multidisciplinario que requiere comunicación y consenso entre muchas partes diferentes.

Desde nuestra experiencia, el monitoreo de la velocidad proporciona datos claros que evitan conflictos innecesarios en los equipos y señala problemas específicos.

El monitoreo tiene un excelente retorno de inversión (ROI)#

En nuestro trabajo de optimización de la velocidad web para clientes pequeños y grandes, requerimos la activación del monitoreo de velocidad como un primer paso esencial para iniciar la colaboración.

Pocas cosas en el campo de la velocidad web tienen un retorno de inversión (ROI) tan bueno como el monitoreo.

Por el costo de unos pocos dólares al mes, evitamos problemas complejos, búsquedas infructuosas y discusiones en el equipo, que pueden costar cientos y miles de dólares.

Diferentes tipos de monitoreo: necesitas disponibilidad, sintético y de usuario#

Nos encontramos con que las personas confunden varios tipos de monitoreo web entre sí.

Para el éxito operativo de un sitio web necesitas al menos tres tipos de monitoreo: de disponibilidad, sintético y de usuario.

Pongamos las cosas en orden:

Monitoreo de disponibilidad#

Responde a la pregunta: «¿Ve el robot si tu sitio web está funcionando?».

Gracias al monitoreo de disponibilidad, sabes si tu sitio realmente está funcionando cada hora, minuto y segundo durante el día. Este monitoreo se centra principalmente en indicadores técnicos y escanea el alojamiento y la infraestructura.

Este tipo de monitoreo lo ofrecen servicios como UptimeRobot o BetterStack.

Monitoreo de rendimiento sintético#

Responde a la pregunta: «¿Cómo ve el robot la velocidad de tu sitio web?».

Aquí ya estamos en el ámbito del monitoreo de velocidad. El monitoreo sintético prueba el sitio en intervalos de tiempo definidos, utilizando software como Lighthouse o WebpageTest. Te devuelve métricas de velocidad web, pero estas pueden no corresponder a la experiencia del usuario (métricas CLS e INP limitadas) o pueden mostrar valores sesgados de otras métricas.

Los usuarios pueden experimentar el sitio de manera diferente a como lo prueba la máquina. La ventaja del monitoreo sintético es la obtención de datos técnicos muy detallados. Además, la sintética permite realizar pruebas con relativa frecuencia, proporcionando así advertencias tempranas en caso de cambios en el sitio.

Este tipo de monitoreo lo proporcionan servicios como Pingdom o GTmetrix, aunque lamentablemente se enfocan en métricas técnicas ya obsoletas. Nuestro monitoreo PLUS también mide de forma sintética, pero se centra en métricas Core Web Vitals y añade una perspectiva de usuario.

Creemos que realmente cada sitio web necesita monitoreo de datos synth y CrUX sobre velocidad. RUM es importante, pero más bien para sitios más grandes.

Monitoreo de rendimiento de usuario#

Responde a la pregunta: «¿Cómo ven los usuarios la velocidad de tu sitio web?».

Las métricas Core Web Vitals y otras permiten ver la parte técnicamente medible de la experiencia del usuario (UX) en grandes volúmenes de datos.

Las mediciones de usuario son básicamente de dos tipos:

• Chrome UX Report (CrUX) – Google proporciona datos de todos los usuarios de Chrome para dominios o URL con suficiente tráfico. La desventaja es la acumulación de datos (siempre vemos el estado de los últimos 28 días) y, por lo tanto, un cierto retraso y falta de detalle. La ventaja es que Google proporciona estos datos de manera gratuita. Las métricas Core Web Vitals obtenidas de CrUX también determinan cómo Google evalúa tus dominios y URL para resultados de búsqueda (SERP) o Google Ads.
• Real User Monitoring (RUM) – las métricas se recopilan de todos los usuarios mediante mediciones propias en JavaScript. La ventaja es que la medición no está limitada al navegador Chrome, los datos están disponibles sin retraso y con el detalle que uno decida. El monitoreo RUM también se puede implementar en aplicaciones protegidas por inicio de sesión. La desventaja es la complejidad de los datos, la configuración de mediciones pesadas y, a menudo, el costo más alto de la solución.

Medir en usuarios es, por supuesto, ideal porque nos interesa la experiencia real. La desventaja de las mediciones de usuario es que no siempre están disponibles de inmediato y no siempre proporcionan suficiente detalle técnico. Por ello, en nuestro monitoreo PLUS combinamos datos de usuario con datos sintéticos.

Resumamos lo que hemos tratado en esta sección. El monitoreo de disponibilidad solo verifica si el sitio está funcionando. El monitoreo sintético de rendimiento mide la velocidad durante la carga por máquina. El monitoreo de rendimiento del usuario proporciona datos sobre la experiencia de usuarios reales. Lo ideal es tener todos estos tipos de monitoreo.

Monitoreo de velocidad según grupos objetivo#

Un aspecto interesante del monitoreo es que diferentes grupos objetivo necesitan diferentes datos de rendimiento:

• Desarrolladores – además del estado de la velocidad del sitio para los usuarios, necesitan alertas de cambios, datos de diagnóstico como por ejemplo métricas técnicas que les guíen hacia las causas de problemas y oportunidades de optimización. El monitoreo de disponibilidad también debería ser una obviedad.
• Propietarios de sitios, comercializadores, UXers y otros – necesitan ver el estado actual de la velocidad, recibir informes regulares y, posiblemente, también alertas de cambios. Lo ideal es ver también en la herramienta la relación de la velocidad con el negocio del sitio.
• Agencias de marketing y desarrollo – además de lo mencionado, necesitan poder gestionar accesos a múltiples proyectos, recibir informes regulares y ver el estado de varios proyectos en un solo lugar.

Exige siempre a tus herramientas de monitoreo lo que corresponda a tus objetivos.

Nuestra metodología: ¿cómo abordamos el monitoreo de rendimiento?#

Tenemos muchos años de experiencia en consultoría sobre velocidad web para clientes pequeños y grandes en la región de Europa Central. Durante ese tiempo, hemos desarrollado una metodología para configurar el monitoreo de velocidad que ahora te presentamos.

CrUX como base y la puntuación de velocidad (SPS) como indicador principal#

Consideramos que los Core Web Vitals son métricas de velocidad muy buenas y los datos del Chrome UX Report (CrUX) de los usuarios de Google un gran regalo para todos los operadores de sitios web.

Las métricas LCP, INP y CLS ciertamente no son perfectas, pero muestran bien diferentes partes de la experiencia del usuario. Los datos de CrUX tampoco son ideales para todos los casos de medición, pero son una base suficiente para cualquier sitio razonablemente grande.

Los Core Web Vitals del Chrome UX Report también tienen la ventaja de proporcionar datos para ambos motivos principales para optimizar la velocidad – la experiencia del usuario (UX) y el tráfico de Google (PPC, SEO).

En nuestro monitoreo, siempre mostramos primero a los clientes los números actuales de estas métricas:

Como se puede ver, nuestro monitoreo también proporciona información sobre la evolución de las métricas.

Hay tres métricas y es necesario seguirlas para dos dispositivos diferentes, por lo que los usuarios a menudo tienen que recordar seis métricas diferentes en muchos dominios diferentes.

Por eso, experimentalmente introdujimos en nuestro monitoreo una puntuación que unifica estos seis números en un solo valor, lo llamamos Puntuación PageSpeed.ONE (SPS):

La puntuación de velocidad (SPS) ayuda a resumir rápidamente el estado actual de la velocidad del sitio.

En sitios más pequeños, puede suceder que el dominio del cliente no tenga suficientes datos. Allí no queda más remedio que medir sintéticamente.

Mediciones sintéticas una vez al día#

Las pruebas sintéticas mediante Lighthouse son un complemento necesario de los datos CrUX de los usuarios. Los datos están disponibles prácticamente para todos los sitios y siempre obtenemos valores actuales de las métricas.

Probamos realizar pruebas más de una vez al día, pero finalmente nos decidimos por pruebas diarias con un ciclo de tres días para posibles advertencias de cambio mediante Watchdog.

La razón es que prácticamente todos nuestros clientes trabajan en la optimización de velocidad en intervalos semanales a mensuales. Las advertencias sobre fluctuaciones en horas o minutos siempre los abrumaban más de lo que deseaban. Hemos observado que todos trabajan en la velocidad del sitio de esta manera.

Las notificaciones de Watchdog no se envían en caso de una fluctuación única, sino después de tres días, cuando estamos seguros.

Para mediciones más detalladas en sitios más grandes o durante períodos de fluctuaciones de velocidad (Black Friday y otras temporadas), activamos temporalmente la medición RUM para los clientes.

Monitoreo RUM en clientes más grandes o durante optimizaciones#

Tener datos de todos los usuarios (RUM) suena tentador, pero como hemos insinuado, a menudo conduce a sobrecargar al cliente con datos y a la incapacidad de evaluarlos correctamente. La medición RUM no es fácil de configurar correctamente, especialmente en aplicaciones SPA, y tampoco es precisamente barata.

Ofrecemos a nuestros clientes ayuda con la implementación de SpeedCurve RUM y activamos estas mediciones en clientes más pequeños en caso de que estemos trabajando intensamente en optimizaciones o si hay una temporada que podría afectar el rendimiento del sitio.

También recomendamos la medición RUM a todos los que monitorean aplicaciones web no públicas, como SaaS (Software as a Service).

¿Dónde monitorear: servidor de producción, etapa...?#

A menudo abordamos la cuestión de dónde ejecutar el monitoreo. ¿Solo producción? ¿Etapa o servidores de prueba? ¿Localmente durante el desarrollo o en el pipeline CI/CD?

Idealmente, la respuesta es: monitorea la velocidad en todos los niveles.

Pero en la práctica, este estado ideal se enfrenta a muchos problemas. El primero es la inestabilidad del entorno de etapa, que a menudo ni siquiera corresponde al sitio real en términos de datos o configuración. En este sentido, un entorno pre-producción es mejor, pero no todas las empresas lo tienen.

Lo ideal es tener monitoreo en todas partes, pero en cualquier caso, siempre en sitios de producción.

El pipeline CI/CD o las pruebas en localhost también son importantes, pero los desarrolladores y testers no tienen disponibles datos de usuarios (CrUX o RUM) en esta parte del proceso. Además, nuevamente nos enfrentamos a la inestabilidad del localhost, por lo que incluso las pruebas sintéticas a menudo no proporcionan números comparables.

La respuesta pragmática a la pregunta de en qué parte tener monitoreo es: principalmente en el servidor de producción.

Sin embargo, ajusta tu ciclo de desarrollo para que puedas revertir rápidamente lanzamientos problemáticos o corregirlos mediante hotfixes.

Presta especial atención a las notificaciones#

Un buen monitoreo de rendimiento se distingue de uno malo en que el bueno sabe comunicarse bien contigo.

Las aplicaciones de monitoreo a menudo envían notificaciones sin sentido, mensajes falsos negativamente que llevan a lo que se conoce como alert fatique, es decir, fatiga de alertas y su posterior ignorancia.

Las aplicaciones de monitoreo de rendimiento también a menudo requieren configuraciones manuales de lo que se llaman Performance Budgets (valores límite para cada métrica de velocidad). Esto nuevamente requiere la atención y el tiempo de alguien del lado del cliente.

Las alertas de Watchdog se pueden recibir en Teams, Slack o por correo electrónico.

Construimos las alertas de nuestro Watchdog para eliminar ambos problemas. Así que solo enviamos notificaciones si el deterioro no es único.

Los límites para cada métrica los configuramos automáticamente según las mejores prácticas, a las que hemos llegado tras muchos años de consultoría sobre velocidad.

También proporcionamos a nuestros clientes el conocimiento sobre cómo evaluar las alertas de Watchdog, así como datos técnicos necesarios para encontrar la causa del cambio en las métricas.

Para concluir#

Quien no mide, no acelera. Esa es una frase que deberías recordar.

Si consideras que la velocidad del sitio web es importante, corre a activar algún monitoreo Core Web Vitals.

Te resultará rentable, ya que el costo anual de una herramienta que te ayuda a encontrar errores es una fracción del costo de detectar errores a ciegas y sin datos.

La optimización de la velocidad no es un sprint, es una maratón, un trabajo continuo para mejorar el UX del sitio o las posiciones en SEO o PPC. La optimización de la velocidad es una maratón en la que necesitarás un compañero con datos en el bolsillo, que es precisamente lo que puede ser el monitoreo de velocidad.

Estudio de caso del rediseño de Světla Svítidel#

Lee en el estudio de caso del rediseño de Světla Svítidel cómo los datos de medición ayudan realmente. En clientes con velocidad estable, medimos a largo plazo solo sintéticamente y con datos CrUX de Google usando el monitoreo PLUS. En caso de cambios importantes, sin embargo, realizamos mediciones detalladas de todos los usuarios (RUM), lo cual hicimos aquí poco antes del lanzamiento del rediseño y, gracias a eso, tuvimos datos en tiempo real.