Métricas de rendimiento centradas en el usuario

Todos hemos escuchado lo importante que es el rendimiento. Pero cuando hablamos del 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), pero lento para otro (en una red lenta con un dispositivo de gama baja).
  • Es posible que dos sitios terminen de cargarse en el mismo tiempo, pero uno puede parecer que se carga más rápido si carga contenido de forma progresiva, en lugar de esperar hasta el final para mostrar algo.
  • Es posible que un sitio parezca cargarse rápidamente, pero después responder con lentitud o no responder a la interacción del usuario.

Cuando se habla de rendimiento, es importante ser preciso y consultarlo en términos de metrics, criterios objetivos que se pueden medir de forma cuantitativa. Sin embargo, también es importante asegurarse de que las métricas que mides sean útiles.

Métricas

Históricamente, el rendimiento web se midió con el evento load. Sin embargo, aunque load es un momento bien definido del ciclo de vida de una página, ese momento no necesariamente corresponde a nada 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 aplaza la recuperación de contenido o la visualización de cualquier elemento en la página hasta varios segundos después de que se activa el evento load. Técnicamente, esta página tiene un tiempo de carga rápido, pero ese tiempo no corresponde a la manera en que un usuario experimenta la carga de la página.

Durante los últimos años, los miembros del equipo de Chrome, en colaboración con el Grupo de trabajo de rendimiento web de W3C, trabajaron para estandarizar un conjunto de nuevas APIs y métricas que miden con mayor precisión la forma en que los usuarios experimentan el rendimiento de una página web.

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

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

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: Uso de herramientas para simular la carga de una página en un entorno coherente y controlado.
  • En el campo: Cuando usuarios reales realmente cargan la página e interactúan con ella.

Ninguna de estas opciones es necesariamente mejor o peor que la otra. De hecho, es recomendable usar ambos para garantizar un buen rendimiento.

En el laboratorio

Probar el rendimiento en el lab es fundamental para desarrollar funciones nuevas. Antes de que se lancen las funciones 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 regresiones de rendimiento.

En el campo

Por otro lado, si bien las pruebas en el lab son un proxy razonable para el rendimiento, no siempre reflejan la experiencia de todos los usuarios en tu sitio.

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

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

La única forma de conocer realmente el rendimiento de tu sitio para los usuarios es medirlo a medida que esos usuarios lo cargan y se interactúan con él. Por lo general, este tipo de medición se denomina supervisión de usuarios reales (RUM).

Tipos de métricas

Existen otros tipos de métricas que son relevantes para la percepción del rendimiento por parte de los usuarios:

  • Velocidad de carga percibida: Es la velocidad con la que una página puede cargar y renderizar todos sus elementos visuales en la pantalla.
  • Capacidad de respuesta de carga: Es la velocidad 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 en tiempo de ejecución: Es la rapidez con la que una página puede responder a la interacción del usuario después de que se carga.
  • Estabilidad visual: ¿Los elementos de la página cambian de manera que los usuarios no esperan, lo que podría interferir en sus interacciones?
  • Suavidad: ¿Las transiciones y animaciones se renderizan a una velocidad de fotogramas constante y fluyen de un estado a otro?

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

Métricas importantes para medir

Primer procesamiento de imagen con contenido (FCP)
El tiempo que transcurre desde que comienza a cargarse la página hasta que se renderiza en la pantalla cualquier parte de su contenido. (lab, campo)
Procesamiento de imagen con contenido más grande (LCP)
El tiempo que transcurre desde que la página comienza a cargarse hasta que se renderiza en la pantalla el bloque de texto o el elemento de imagen más grandes. (lab, campo)
Interaction to Next Paint (INP)
La latencia de cada presión, clic o interacción del teclado que se realiza con la página. Según la cantidad de interacciones, esta métrica selecciona la latencia de interacción más grave (o cercana a la peor) de la página como un valor único y representativo para describir la capacidad de respuesta general de una página. (lab, campo)
Tiempo de bloqueo total (TBT)
Es la cantidad total de tiempo entre FCP y el tiempo para ser interactivo (TTI) durante el cual se bloqueó el subproceso principal durante el tiempo suficiente para evitar la respuesta de la entrada. (lab)
Cambio de diseño acumulado (CLS)
Es la puntuación acumulada de todos los cambios de diseño inesperados que ocurren entre el momento en que la página comienza a cargarse y el estado de ciclo de vida cambia a oculto. (lab, campo)
Tiempo hasta el primer byte (TTFB)
Es el tiempo que tarda la red en responder a una solicitud del usuario con el primer byte de un recurso. (lab, campo)

Esta lista incluye métricas que miden muchos de los diversos aspectos de rendimiento relevantes para los usuarios, pero no incluye todos los aspectos. Por ejemplo, no se aborda la capacidad de respuesta ni la fluidez del tiempo de ejecución.

En algunos casos, se agregarán métricas nuevas para cubrir las áreas faltantes, pero, en otros, las mejores métricas son aquellas diseñadas específicamente para tu sitio.

Métricas personalizadas

Las métricas de rendimiento que se enumeran aquí son útiles para obtener una comprensión general de las características de rendimiento de la mayoría de los sitios de la Web. También son útiles porque tienen un conjunto común de métricas para que los sitios comparen su rendimiento con el de la competencia.

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

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

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