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", ¿qué queremos decir específicamente?

Lo cierto 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 parece que uno 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 que se cargue rápidamente, pero luego responda con lentitud (o que directamente no) a la interacción del usuario.

Por lo tanto, cuando se habla de rendimiento, es importante ser preciso y referirse al rendimiento en términos de criterios objetivos que se pueden medir de forma cuantitativa. Estos criterios se conocen como metrics.

Sin embargo, el hecho de que una métrica se base en criterios objetivos y se pueda medir de forma cuantitativa no significa necesariamente que esas mediciones sean útiles.

Define las 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 y la visualización de cualquier elemento en la página hasta varios segundos después de que se activa el evento load. Si bien, técnicamente, una página de este tipo podría tener un tiempo de carga rápido, ese tiempo no correspondería a la manera en que un usuario experimenta en realidad 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 ni peor que la otra; de hecho, 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 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 reflejan necesariamente la forma en que todos los usuarios experimentan tu sitio en un entorno real.

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

Además, es posible que las cargas de páginas no sean deterministas. Por ejemplo, los sitios que cargan anuncios o contenido personalizados pueden tener características de rendimiento muy diferentes de un usuario a otro. En un análisis de lab, no se capturará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 interactúan con él. Este tipo de medición se conoce comúnmente como supervisión de usuarios reales o 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: Después de que se carga la página, indica qué tan rápido puede responder la página a la interacción del usuario.
  • Estabilidad visual: ¿Los elementos de la página cambian de maneras que los usuarios no esperan y que podrían 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 los tipos de métricas de rendimiento anteriores, 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): Mide el tiempo que transcurre desde que la página comienza a cargarse hasta que se renderiza en la pantalla cualquier parte de su contenido. (lab, campo)
  • Largest Contentful Paint (LCP): Mide 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)
  • Retraso de primera entrada (FID): Mide el tiempo que transcurre desde la primera vez que un usuario interactúa con tu sitio (cuando hace clic en un vínculo, presiona un botón o usa un control personalizado con JavaScript) hasta el momento en que el navegador puede responder a esa interacción. (campo)
  • Interacción a la siguiente pintura (INP): Mide la latencia de cada presión, clic o interacción con el teclado que se realiza con la página y, según la cantidad de interacciones, selecciona la latencia de interacción más grave de la página (o casi la más alta) como un valor único y representativo para describir la capacidad de respuesta general de la página. (lab, campo)
  • Tiempo de bloqueo total (TBT): Mide la cantidad de tiempo total entre FCP y TTI en el que el subproceso principal se bloqueó durante el tiempo suficiente para evitar la capacidad de respuesta de la entrada. (lab)
  • Cambio de diseño acumulado (CLS): Mide 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): Mide el tiempo que tarda la red en responder a una solicitud del usuario con el primer byte de un recurso. (lab, campo)

Si bien esta lista incluye métricas que miden muchos de los diversos aspectos del rendimiento relevantes para los usuarios, no incluye a todos los usuarios. Por ejemplo, por el momento, no se tratan la capacidad de respuesta y la fluidez del tiempo de ejecución.

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

Métricas personalizadas

Las métricas de rendimiento mencionadas anteriormente sirven 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, puede haber ocasiones en que un sitio específico sea único de alguna manera, lo que requiera 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 podría haber casos en los que el elemento más grande no sea 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 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 sobre 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.