Métricas de rendimiento centradas en el usuario

Todos hemos escuchado lo importante que es el rendimiento. Pero cuando hablamos de rendimiento y de hacer que los sitios web sean "rápidos", ¿a qué nos referimos específicamente?

La verdad es que el rendimiento es relativo:

  • Un sitio puede ser rápido para un usuario (en una red rápida con un dispositivo potente) y lento para otro usuario (en una red lenta con un dispositivo de gama baja).
  • Es posible que dos sitios terminen de cargarse en exactamente el mismo tiempo, pero es posible que uno parece cargarse más rápido (si carga el contenido de forma progresiva en lugar de esperar hasta el final para que se muestre algún elemento).
  • Es posible que un sitio parezca cargarse rápidamente, pero que luego responda con lentitud (o no responda) a la interacción del usuario.

Cuando se habla de rendimiento, es importante ser preciso y referirse al rendimiento en términos de metrics. Son criterios objetivos que pueden medirse de manera cuantitativa, pero también es importante asegurarse de que las métricas que mides sean útiles.

Definición de métricas

Históricamente, el rendimiento web se midió con el evento load. Sin embargo, aunque load es un momento bien definido en el ciclo de vida de una página, ese momento no necesariamente se corresponde con algo que le interese al usuario.

Por ejemplo, un servidor podría responder con una página mínima que se "carga" de inmediato, pero luego aplazar la recuperación de contenido o la visualización de algo en la página hasta varios segundos después de que se active el evento load. Técnicamente, esta página tiene un tiempo de carga rápido, pero ese tiempo no corresponde a cómo experimenta un usuario la carga de la página.

Durante los últimos años, los miembros del equipo de Chrome, en colaboración con el W3C Web Performance Working Group, han estado trabajando para estandarizar un conjunto de nuevas APIs y métricas que midan de manera más precisa la experiencia de los usuarios con el rendimiento de una página web.

Para garantizar que las métricas sean relevantes para los usuarios, las planteamos en torno a algunas preguntas clave:

¿Está sucediendo? ¿La navegación se inició correctamente? ¿El servidor respondió?
¿Es útil? ¿Genera suficiente contenido para que los usuarios puedan interactuar con él?
¿Es utilizable? ¿Los usuarios pueden interactuar con la página o está ocupada?
¿Es agradable? ¿Las interacciones son fluidas y naturales, sin demoras?

Cómo se miden las métricas

En general, las métricas de rendimiento se miden de una de estas dos maneras:

  • En el lab: Usa herramientas para simular una carga de página en un entorno coherente y controlado.
  • En el campo: Cuando los usuarios reales cargan la página y, luego, interactúan con ella.

Ninguna de estas opciones es necesariamente mejor o peor que la otra; de hecho, por lo general, es recomendable usar ambas para garantizar un buen rendimiento.

En el laboratorio

Probar el rendimiento en el lab es fundamental para desarrollar funciones nuevas. Antes de que las funciones se lancen en producción, es imposible medir sus características de rendimiento en usuarios reales, por lo que probarlas en el lab antes del lanzamiento de la función es la mejor manera de evitar las regresiones de rendimiento.

En el campo

Por otro lado, si bien las pruebas en el lab son un indicador razonable del rendimiento, no reflejan necesariamente la experiencia de los usuarios reales con tu sitio.

El rendimiento de un sitio puede variar considerablemente según las capacidades del dispositivo del usuario y las condiciones de la red. También puede variar en función de si un usuario interactúa con la página (o cómo).

Además, las cargas de página no siempre son deterministas. Por ejemplo, los sitios que cargan contenido o anuncios personalizados pueden experimentar características de rendimiento muy diferentes de un usuario a otro. Una prueba de laboratorio no captará esas diferencias.

La única manera de saber realmente el rendimiento de tu sitio para los usuarios es medir su rendimiento a medida que esos usuarios lo cargan e interactúan con él. Este tipo de medición se denomina comúnmente supervisión de usuarios reales (RUM).

Tipos de métricas

Existen muchos otros tipos de métricas que son relevantes para la forma en que los usuarios perciben el rendimiento.

  • Velocidad de carga percibida: Es la rapidez con la que una página puede cargar y renderizar todos sus elementos visuales en la pantalla.
  • Capacidad de respuesta de carga: Es la rapidez con la que una página puede cargar y ejecutar cualquier código JavaScript necesario para que los componentes respondan rápidamente a la interacción del usuario.
  • Capacidad de respuesta del tiempo de ejecución: Después de que se carga la página, la rapidez con la que esta puede responder a la interacción del usuario.
  • Estabilidad visual: ¿Los elementos de la página cambian de una forma que los usuarios no esperan y podría interferir en sus interacciones?
  • Suavidad: ¿Las transiciones y las animaciones se renderizan a una velocidad de fotogramas constante y fluyen con fluidez de un estado al siguiente?

Con todos estos tipos de métricas de rendimiento, queda claro que ninguna métrica es suficiente para capturar todas las características de rendimiento de una página.

Métricas importantes para medir

En algunos casos, se incluirán métricas nuevas para abarcar las áreas faltantes, pero, en otros casos, las mejores métricas serán aquellas adaptadas específicamente a tu sitio.

Métricas personalizadas

Las métricas de rendimiento que mencionamos anteriormente sirven para obtener una comprensión general de las características de rendimiento de la mayoría de los sitios en la Web. También son buenas por tener un conjunto común de métricas para que los sitios comparen su rendimiento con el de la competencia.

Sin embargo, puede haber ocasiones en las que un sitio específico sea único de alguna manera que requiera métricas adicionales para capturar el panorama completo del rendimiento. Por ejemplo, la métrica de LCP está diseñada para medir cuándo termina de cargarse el contenido principal de una página, pero podría haber casos en los que el elemento más grande no forme parte del contenido principal de la página y, por lo tanto, el LCP podría no ser relevante.

Para abordar estos casos, el Grupo de trabajo sobre el rendimiento web también estandarizó APIs de nivel inferior que pueden ser útiles para implementar tus propias métricas personalizadas:

Consulta la guía sobre las métricas personalizadas para obtener información sobre cómo usar estas APIs para medir las características de rendimiento específicas de tu sitio.