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.
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:
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:
Optimiza el rendimiento de carga rápida en relación con las capacidades del dispositivo y la red de tus usuarios. Actualmente, un buen objetivo para las primeras cargas es cargar la página y ser interactiva en 5 segundos o menos en dispositivos móviles de rango medio con conexiones 3G lentas.
Para las cargas posteriores, un buen objetivo es cargar la página en menos de 2 segundos.
Lineamientos:
Prueba el rendimiento de la carga en los dispositivos móviles y las conexiones de red que son comunes entre tus usuarios. Puedes usar el Informe sobre la experiencia del usuario en Chrome para conocer la distribución de las conexiones de tus usuarios. Si los datos no están disponibles para tu sitio, en La economía móvil de 2019 se indica que un buen modelo de referencia global es un teléfono Android de gama media, como un Moto G4, y una red 3G lenta (definida como 400 ms de RTT y 400 Kbps de velocidad de transferencia). Esta combinación está disponible en WebPageTest.
Ten en cuenta que, aunque el dispositivo de un usuario móvil típico podría afirmar que está conectado a una red 2G, 3G o 4G, en realidad, la velocidad de conexión real suele ser mucho más lenta, debido a la pérdida de paquetes y la variación de la red.
No tienes que cargar todo en menos de 5 segundos para producir la percepción de una carga completa. Considera usar imágenes de carga diferida, paquetes de JavaScript de división de código y otras optimizaciones sugeridas en web.dev.
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:
Limita tu CPU para simular un dispositivo menos potente.
Limita la red para simular conexiones más lentas.
Ver la actividad del subproceso principal: Permite ver todos los eventos que ocurrieron en el subproceso principal mientras grababas.
Visualiza las actividades de subprocesos principales en una tabla para ordenar las actividades en función de las que ocuparon más tiempo.
Analizar fotogramas por segundo (FPS) para medir si las animaciones realmente se ejecutan sin problemas
Supervisa el uso de la CPU, el tamaño del montón de JS, los nodos del DOM, los diseños por segundo y mucho más en tiempo real con el Monitor de rendimiento.
En la sección Red, visualiza las solicitudes de red que se produjeron mientras se realizaba la grabación.
Toma capturas de pantalla mientras grabas para reproducir exactamente cómo se veía la página mientras se cargaba o se activó una animación, etcétera.
Consulta las interacciones para identificar rápidamente lo que sucedió en una página después de que un usuario interactuó con ella.
Encuentra problemas de rendimiento de desplazamiento en tiempo real destacando la página cada vez que se active un objeto de escucha potencialmente problemático.
Visualiza los eventos de pintura en tiempo real para identificar eventos de pintura costosos que puedan afectar el rendimiento de tus animaciones.
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
Máx. posible retraso de primera entrada. Estima el tiempo que tardará tu app en responder a la entrada del usuario, según el tiempo de inactividad del subproceso principal.
No usa objetos de escucha pasivos para mejorar el rendimiento del desplazamiento.
Total Blocking Time (Tiempo de bloqueo total). Mide la cantidad total de tiempo que una página no puede responder a las entradas del usuario, como clics del mouse, presiones de la pantalla o presiones del teclado.
Time To Interactive (Tiempo para la interacción). Mide cuándo un usuario puede interactuar de manera coherente con todos los elementos de la página.
Carga
No registra un service worker que controle start_url y page. Un service worker puede almacenar en caché recursos comunes del dispositivo de un usuario, lo que reduce el tiempo dedicado a recuperar recursos en la red.
La carga de la página no es lo suficientemente rápida en redes móviles.
Aplaza las imágenes fuera de pantalla. Aplaza la carga de imágenes fuera de pantalla hasta que sean necesarias.
Usa el tamaño adecuado para las imágenes. No entregues imágenes que sean mucho más grandes que el tamaño renderizado en el viewport para dispositivos móviles.
Evita un tamaño excesivo del DOM. Para reducir los bytes de red, envía solo nodos del DOM que se necesitan para renderizar la página.
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.