Mide el rendimiento con el modelo RAIL

RAIL es un modelo de rendimiento centrado en el usuario que proporciona una estructura para pensar en el rendimiento. El modelo desglosa la experiencia del usuario en acciones clave (por ejemplo, presionar, desplazar, cargar) y te ayuda a definir objetivos de rendimiento para cada una de ellas.

RAIL significa cuatro aspectos distintos del ciclo de vida de la aplicación web: respuesta, animación, inactividad y carga. Los usuarios tienen diferentes expectativas de rendimiento para cada uno de estos contextos, por lo que los objetivos de rendimiento se definen según el contexto y la investigación de UX sobre cómo los usuarios perciben los retrasos.

Las 4 partes del modelo de rendimiento RAIL: respuesta, animación, inactividad y carga
Las 4 partes del modelo de rendimiento RAIL

Enfocadas en el usuario

Haga que los usuarios sean el punto central de su esfuerzo de rendimiento. En la siguiente tabla, se describen las métricas clave sobre cómo los usuarios perciben los retrasos en el rendimiento:

Percepción de los usuarios sobre las demoras en el rendimiento
0 a 16 ms Los usuarios son excepcionalmente buenos para rastrear movimiento, y no les gusta que las animaciones no sean fluidas. Perciben las animaciones como fluidas, siempre que se rendericen 60 fotogramas nuevos por segundo. Es decir, 16 ms por fotograma, incluido el tiempo que tarda el navegador en pintar el nuevo fotograma en la pantalla, lo que deja a una app unos 10 ms para producir un fotograma.
0 a 100 ms Responde a las acciones de los usuarios dentro de esta ventana de tiempo y los usuarios sentirán que el resultado es inmediato. Si transcurre más tiempo, la conexión entre acción y reacción se rompe.
100 a 1,000 ms Dentro de esta ventana, las cosas parecen parte de una progresión natural y continua de tareas. Para la mayoría de los usuarios de la Web, cargar páginas o cambiar las vistas representa una tarea.
1,000 ms o más Después de los 1,000 milisegundos (1 segundo), los usuarios pierden la concentración en la tarea que están realizando.
10,000 ms o más Después de los 10.000 milisegundos (10 segundos), los usuarios se sienten frustrados y es probable que abandonen tareas. Es posible que regresen más tarde o no.

Objetivos y lineamientos

En el contexto de RAIL, los términos objetivos y lineamientos tienen significados específicos:

  • Objetivos: Son las métricas de rendimiento clave relacionadas con la experiencia del usuario. Por ejemplo, presiona para pintar en menos de 100 milisegundos. Dado que la percepción humana es relativamente constante, es poco probable que estos objetivos cambien en un futuro cercano.

  • Lineamientos. Recomendaciones que te ayudan a alcanzar objetivos (pueden ser específicas para las condiciones actuales de hardware y conexión de red) y, por lo tanto, pueden cambiar con el tiempo.

Respuesta: Procesa eventos en menos de 50 ms

Objetivo: Completar una transición iniciada por una entrada del usuario en un plazo de 100 ms para que los usuarios sientan que las interacciones son instantáneas.

Lineamientos:

  • Para garantizar una respuesta visible en un plazo de 100 ms, procesa los eventos de entrada del usuario en un plazo de 50 ms. Esto se aplica a la mayoría de las entradas, como hacer clic en botones, activar o desactivar controles de formularios o iniciar animaciones. Esto no se aplica a los desplazamientos táctiles ni a los desplazamientos.

  • Aunque pueda sonar contradictorio, no siempre es la llamada adecuada para responder de inmediato a la entrada del usuario. Puedes usar esta ventana de 100 ms para hacer otro trabajo costoso, pero ten cuidado de no bloquear al usuario. Si es posible, haz trabajo en segundo plano.

  • En el caso de las acciones que tardan más de 50 ms en completarse, siempre proporciona comentarios.

¿50 ms o 100 ms?

El objetivo es responder a las entradas en menos de 100 ms. Entonces, ¿por qué nuestro presupuesto es de solo 50 ms? Esto se debe a que, por lo general, se realiza otro trabajo además del control de entradas, y ese trabajo ocupa parte del tiempo disponible para obtener una respuesta de entrada aceptable. Si una aplicación está realizando tareas en los fragmentos recomendados de 50 ms durante el tiempo de inactividad, eso significa que la entrada se puede poner en cola hasta 50 ms si ocurre durante uno de esos períodos de trabajo. Si tenemos en cuenta esto, es seguro suponer que solo los 50 ms restantes están disponibles para el control de entrada real. Este efecto se visualiza en el siguiente diagrama, que muestra cómo se pone en cola la entrada recibida durante una tarea inactiva, lo que reduce el tiempo de procesamiento disponible:

Diagrama que muestra cómo se pone en cola la entrada recibida durante una tarea inactiva, lo que reduce el tiempo de procesamiento de entrada disponible a 50 ms
Cómo afectan las tareas inactivas al presupuesto de respuesta de entrada.

Animación: Produce un fotograma en 10 ms

Objetivos:

  • Produce cada fotograma de una animación en 10 ms o menos. Técnicamente, el presupuesto máximo para cada fotograma es de 16 ms (1,000 ms / 60 fotogramas por segundo ⋅ 16 ms), pero los navegadores necesitan alrededor de 6 ms para renderizar cada fotograma, por lo que se recomienda usar 10 ms por fotograma.

  • Apunta a la fluidez visual. Los usuarios notan cuando varían las velocidades de fotogramas.

Lineamientos:

  • En puntos de presión altos, como animaciones, la clave es no hacer nada donde puedas y lo mínimo donde no puedes. Siempre que sea posible, usa la respuesta de 100 ms para calcular previamente el trabajo costoso a fin de maximizar las posibilidades de alcanzar los 60 FPS.

  • Consulta Rendimiento de la renderización para ver varias estrategias de optimización de animación.

  • Animaciones visuales, como entradas y salidas, indicadores de carga y preadolescentes
  • Desplazamiento. Esto incluye arrastrar y soltar, que es cuando el usuario comienza a desplazarse, luego lo suelta y la página continúa desplazándose.
  • Arrastrando Las animaciones suelen seguir las interacciones del usuario, como el desplazamiento lateral de un mapa o el pellizcar para hacer zoom.

Inactivo: Maximiza el tiempo de inactividad.

Objetivo: Maximiza el tiempo de inactividad para aumentar las probabilidades de que la página responda a una entrada del usuario en 50 ms.

Lineamientos:

  • Usa el tiempo de inactividad para completar el trabajo diferido. Por ejemplo, para la carga inicial de la página, carga la menor cantidad de datos posible y, luego, usa el tiempo de inactividad para cargar el resto.

  • Realizar el trabajo durante el tiempo de inactividad en 50 ms o menos Si transcurre más tiempo, corres el riesgo de interferir en la capacidad de la app de responder a la entrada del usuario en un plazo de 50 ms.

  • Si un usuario interactúa con una página durante el tiempo de inactividad, la interacción del usuario siempre debe tener la máxima prioridad e interrumpir ese proceso.

Carga: Publica contenido y pasa a ser interactivo en menos de 5 segundos.

Cuando las páginas se cargan lentamente, la atención del usuario se dispersa y los usuarios perciben la tarea como incorrecta. Los sitios que se cargan rápidamente tienen sesiones promedio más largas, porcentajes de rebote más bajos y una mayor visibilidad de los anuncios.

Objetivos:

Lineamientos:

Herramientas para medir RAIL

Existen algunas herramientas para ayudarte a automatizar tus mediciones de RAIL. La opción que uses dependerá del tipo de información que necesites y del tipo de flujo de trabajo que prefieras.

Herramientas para desarrolladores de Chrome

Las herramientas para desarrolladores de Chrome proporcionan un análisis detallado de todo lo que sucede mientras se carga o ejecuta tu página. Consulta Cómo comenzar a analizar el rendimiento del entorno de ejecución para familiarizarte con la IU del panel Rendimiento.

Las siguientes funciones de Herramientas para desarrolladores son especialmente relevantes:

Faro

Lighthouse está disponible en las Herramientas para desarrolladores de Chrome, en PageSpeed Insights, como una extensión de Chrome, como un módulo de Node.js y dentro de WebPageTest. Le proporcionas una URL, simula un dispositivo de rango medio con una conexión 3G lenta, ejecuta una serie de auditorías en la página y, luego, te brinda un informe sobre el rendimiento de la carga y sugerencias para mejorar.

Las siguientes auditorías son particularmente relevantes:

Respuesta

Carga

WebPageTest

WebPageTest es una herramienta de rendimiento web que usa navegadores reales para acceder a páginas web y recopilar métricas de tiempo. Ingresa una URL en webpagetest.org/easy para obtener un informe detallado sobre el rendimiento de carga de la página en un dispositivo Moto G4 real con una conexión 3G lenta. También puedes configurarlo para que incluya una auditoría de Lighthouse.

Resumen

RAIL permite ver la experiencia del usuario de un sitio web como un recorrido compuesto por interacciones distintas. Comprende cómo los usuarios perciben tu sitio para establecer objetivos de rendimiento con el mayor impacto en la experiencia del usuario.

  • Enfocadas en el usuario

  • Responde a las entradas del usuario en menos de 100 ms.

  • Produce un fotograma en menos de 10 ms durante la animación o el desplazamiento.

  • Maximiza el tiempo de inactividad del subproceso principal.

  • Carga contenido interactivo en menos de 5,000 ms.