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, desplazarse, cargar) y te ayuda a definir objetivos de rendimiento para cada una de ellas.
RAIL representa cuatro aspectos distintos del ciclo de vida de las apps 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 en función del contexto y de la investigación sobre UX de cómo los usuarios perciben los retrasos.
Enfocadas en el usuario
Haz que los usuarios sean el punto focal de tu esfuerzo de rendimiento. En la siguiente tabla, se describen las métricas clave de cómo los usuarios perciben los retrasos en el rendimiento:
Percepción del usuario sobre los retrasos en el rendimiento| De 0 a 16 ms | Los usuarios son excepcionalmente buenos para seguir el movimiento y no les gusta cuando las animaciones no son fluidas. Perciben las animaciones como fluidas siempre que se rendericen 60 fotogramas nuevos por segundo. Eso equivale a 16 ms por fotograma, incluido el tiempo que tarda el navegador en pintar el fotograma nuevo en la pantalla, lo que deja a la app unos 10 ms para producir un fotograma. |
| De 0 a 100 ms | Si respondes a las acciones del usuario dentro de este período, los usuarios sentirán que el resultado es inmediato. Si tarda más, se rompe la conexión entre la acción y la reacción. |
| De 100 a 1,000 ms | Dentro de esta ventana, los elementos se sienten 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 de vista representa una tarea. |
| 1,000 ms o más | Después de 1,000 milisegundos (1 segundo), los usuarios pierden el enfoque en la tarea que están realizando. |
| 10,000 ms o más | Después de 10,000 milisegundos (10 segundos), los usuarios se frustran y es probable que abandonen las tareas. Es posible que regresen más tarde o que no lo hagan. |
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, el tiempo de respuesta al tacto es inferior a 100 milisegundos. Dado que la percepción humana es relativamente constante, es poco probable que estos objetivos cambien en el corto plazo.
Lineamientos. Son 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: Procesar eventos en menos de 50 ms
Objetivo: Completa una transición iniciada por la 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 arrastres o desplazamientos táctiles.
Aunque puede parecer contradictorio, no siempre es la decisión correcta responder a la entrada del usuario de inmediato. Puedes usar esta ventana de 100 ms para realizar otro trabajo costoso, pero ten cuidado de no bloquear al usuario. Si es posible, realiza el trabajo en segundo plano.
Para las acciones que tardan más de 50 ms en completarse, siempre proporciona comentarios.
¿50 ms o 100 ms?
El objetivo es responder a la entrada en menos de 100 ms, por lo que nuestro presupuesto es de solo 50 ms. Esto se debe a que, por lo general, se realiza otro trabajo además de la administración de entradas, y ese trabajo ocupa parte del tiempo disponible para una respuesta de entrada aceptable. Si una aplicación realiza un trabajo en los fragmentos recomendados de 50 ms durante el tiempo de inactividad, significa que la entrada se puede poner en cola durante un máximo de 50 ms si se produce durante uno de esos fragmentos de trabajo. Teniendo esto en cuenta, 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 el lineamiento es de 10 ms por fotograma.
Busca la fluidez visual. Los usuarios notan cuando varían las velocidades de fotogramas.
Lineamientos:
En puntos de alta presión, como las animaciones, la clave es no hacer nada donde puedas y hacer lo mínimo donde no puedas. Siempre que sea posible, aprovecha la respuesta de 100 ms para calcular previamente el trabajo costoso y, de esa manera, maximizar tus posibilidades de alcanzar los 60 FPS.
Consulta Rendimiento de la renderización para conocer varias estrategias de optimización de animaciones.
- Animaciones visuales, como entradas y salidas, interpolaciones e indicadores de carga
- Desplazamiento Esto incluye el deslizamiento rápido, que es cuando el usuario comienza a desplazarse, luego suelta la pantalla y la página sigue desplazándose.
- Arrastre. Las animaciones suelen seguir las interacciones del usuario, como el desplazamiento lateral por un mapa o el pellizco para hacer zoom.
Inactivo: Maximiza el tiempo de inactividad
Objetivo: Maximizar el tiempo de inactividad para aumentar las probabilidades de que la página responda a la entrada del usuario en un plazo de 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.
Realiza el trabajo durante el tiempo de inactividad en 50 ms o menos. Si tardas más, corres el riesgo de interferir en la capacidad de la app para responder a la entrada del usuario en un plazo de 50 ms.
Si un usuario interactúa con una página durante el trabajo en tiempo de inactividad, la interacción del usuario siempre debe tener la prioridad más alta y, además, interrumpir el trabajo en tiempo de inactividad.
Carga: Entrega contenido y haz que sea interactivo en menos de 5 segundos
Cuando las páginas se cargan con lentitud, la atención del usuario se dispersa y este percibe que la tarea está interrumpida. Los sitios que se cargan rápido 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 de red y dispositivo de tus usuarios. Actualmente, un buen objetivo para las primeras cargas es que la página se cargue y sea interactiva en 5 segundos o menos en dispositivos móviles de gama media 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 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 conexiones de tus usuarios. Si los datos no están disponibles para tu sitio, The Mobile Economy 2019 sugiere 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 un RTT de 400 ms y una velocidad de transferencia de 400 kbps). Esta combinación está disponible en WebPageTest.
Ten en cuenta que, aunque el dispositivo de tu usuario de dispositivos móviles típico puede indicar que está en una conexión 2G, 3G o 4G, en realidad, la velocidad de conexión efectiva suele ser mucho más lenta debido a la pérdida de paquetes y la variación de la red.
No es necesario que cargues todo en menos de 5 segundos para producir la percepción de una carga completa. Considera la posibilidad de cargar imágenes de forma diferida, dividir el código de los paquetes de JavaScript y realizar otras optimizaciones sugeridas en web.dev.
Herramientas para medir el modelo RAIL
Existen algunas herramientas que te ayudarán a automatizar tus mediciones de RAIL. La 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 se ejecuta tu página. Consulta Comienza a analizar el rendimiento del tiempo de ejecución para familiarizarte con la IU del panel de Rendimiento.
Las siguientes funciones de DevTools son especialmente relevantes:
Limita la CPU para simular un dispositivo menos potente.
Limita la red para simular conexiones más lentas.
Consulta la actividad del subproceso principal para ver todos los eventos que se produjeron en el subproceso principal mientras realizabas la grabación.
Consulta las actividades del subproceso principal en una tabla para ordenarlas según las que tardaron más tiempo.
Analiza los fotogramas por segundo (FPS) para medir si tus animaciones se ejecutan de forma fluida.
Supervisa el uso de CPU, el tamaño del montón de JS, los nodos del DOM, los diseños por segundo y más en tiempo real con el Monitor de rendimiento.
Visualiza las solicitudes de red que se produjeron mientras grababas con la sección Red.
Captura capturas de pantalla mientras grabas para reproducir exactamente cómo se veía la página mientras se cargaba, o bien cuando se activaba 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 activa un objeto de escucha potencialmente problemático.
Visualiza los eventos de pintura en tiempo real para identificar los eventos de pintura costosos que pueden perjudicar 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 en WebPageTest. Le proporcionas una URL, simula un dispositivo de gama media 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, así como sugerencias para mejorar.
Las siguientes auditorías son especialmente relevantes:
Respuesta
Retraso de primera entrada potencial máximo. Estima cuánto tiempo 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.
Tiempo de bloqueo total. Mide la cantidad total de tiempo que una página está bloqueada para responder a la entrada del usuario, como los clics del mouse, las presiones de pantalla o las presiones del teclado.
Tiempo para interactuar. Mide cuándo un usuario puede interactuar de forma coherente con todos los elementos de la página.
Carga
No registra un service worker que controle la página y start_url. Un service worker puede almacenar en caché recursos comunes en el dispositivo de un usuario, lo que reduce el tiempo que se dedica a recuperar recursos a través de la red.
La carga de página no es lo suficientemente rápida en las redes móviles.
Difiere las imágenes fuera de pantalla. Difiere la carga de las imágenes fuera de pantalla hasta que sean necesarias.
Usa un tamaño adecuado para las imágenes. No publiques imágenes que sean significativamente más grandes que el tamaño que se renderiza en el viewport para dispositivos móviles.
Evita un tamaño de DOM excesivo. Reduce los bytes de red enviando solo los 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 es una lente para observar la experiencia del usuario de un sitio web como un recorrido compuesto por distintas interacciones. Comprende cómo los usuarios perciben tu sitio para establecer objetivos de rendimiento que tengan el mayor impacto en la experiencia del usuario.
Enfocadas en el usuario
Responde a la entrada del usuario en menos de 100 ms.
Produce un fotograma en menos de 10 ms cuando se anima o se desplaza.
Maximiza el tiempo de inactividad del subproceso principal.
Carga contenido interactivo en menos de 5,000 ms.