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 de UX sobre cómo los usuarios perciben las demoras.
Enfocadas en el usuario
Haz que los usuarios sean el punto focal de tus esfuerzos de rendimiento. En la siguiente tabla, se describen las métricas clave sobre cómo los usuarios perciben las demoras en el rendimiento:
Percepción del usuario sobre las demoras en el rendimiento| De 0 a 16 ms | Los usuarios son muy 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. Esto equivale a 16 ms por fotograma, incluido el tiempo que tarda el navegador en pintar el nuevo fotograma en la pantalla, lo que deja a la app unos 10 ms para producir un fotograma. |
| De 0 a 100 ms | Responde a las acciones del usuario dentro de este período, y los usuarios sentirán que el resultado es inmediato. Si es más largo, se rompe la conexión entre la acción y la reacción. |
| De 100 a 1,000 ms | Dentro de esta ventana, las cosas 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 vuelvan más adelante. |
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, puedes pintar con un toque en menos de 100 milisegundos. Dado que la percepción humana es relativamente constante, es poco probable que estos objetivos cambien pronto.
Lineamientos. Recomendaciones que te ayudan a alcanzar tus objetivos. Estas pueden ser específicas para las condiciones actuales de hardware y conexión de red, por lo que pueden cambiar con el tiempo.
Respuesta: Procesar eventos en menos de 50 ms
Objetivo: Completar 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 ni a los desplazamientos táctiles.
Aunque pueda sonar contradictorio, no siempre es la mejor opción responder a la entrada del usuario de inmediato. Puedes usar este período 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, 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 procesamiento de entrada, y ese trabajo ocupa parte del tiempo disponible para una respuesta de entrada aceptable. Si una aplicación realiza trabajo en los fragmentos recomendados de 50 ms durante el tiempo de inactividad, significa que la entrada se puede poner en cola hasta por 50 ms si se produce durante uno de esos fragmentos de trabajo. Teniendo en cuenta esto, es seguro suponer que solo los 50 ms restantes están disponibles para el procesamiento 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:
Producir 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 la guía recomienda 10 ms por fotograma.
Busca la fluidez visual. Los usuarios notan cuando varían las frecuencias de fotogramas.
Lineamientos:
En los puntos de alta presión, como las animaciones, la clave es no hacer nada cuando se pueda y lo mínimo absoluto cuando no se pueda. Siempre que sea posible, aprovecha la respuesta de 100 ms para precalcular el trabajo costoso y, así, 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, animaciones intermedias e indicadores de carga
- Desplazamiento Esto incluye el lanzamiento, que se produce cuando el usuario comienza a desplazarse, luego suelta el dedo y la página sigue desplazándose.
- Arrastrar Las animaciones suelen seguir las interacciones del usuario, como desplazar un mapa o pellizcarlo para hacer zoom.
Inactividad: 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 es más largo, 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 debe interrumpir el trabajo en tiempo de inactividad.
Carga: Entrega contenido y se vuelve interactivo en menos de 5 segundos
Cuando las páginas se cargan lentamente, la atención de los usuarios se desvía y perciben la tarea como interrumpida. Los sitios que se cargan rápidamente tienen sesiones promedio más largas, porcentajes de rebote más bajos y mayor visibilidad de los anuncios.
Objetivos:
Optimiza el rendimiento de carga rápida en relación con las capacidades de red y dispositivos de tus usuarios. Actualmente, un buen objetivo para las primeras cargas es cargar la página y que 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 las conexiones de tus usuarios. Si los datos no están disponibles para tu sitio, The Mobile Economy 2019 sugiere que un buen valor 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, si bien el dispositivo de tu usuario móvil típico puede indicar que tiene 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 que se perciba una carga completa. Considera la carga diferida de imágenes, la división de código de paquetes de JavaScript y otras optimizaciones sugeridas en web.dev.
Herramientas para medir RAIL
Existen algunas herramientas que te ayudan a automatizar tus mediciones de RAIL. El 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 Primeros pasos con el análisis del 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.
Ver la actividad del subproceso principal para ver cada evento que ocurrió en el subproceso principal mientras grababas.
Consulta las actividades del subproceso principal en una tabla para ordenarlas según las que consumieron más tiempo.
Analiza los fotogramas por segundo (FPS) para medir si tus animaciones se ejecutan con fluidez.
Supervisa el uso de CPU, el tamaño de la pila de JS, los nodos DOM, los diseños por segundo y mucho 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 instantáneas mientras grabas para reproducir exactamente cómo se veía la página mientras se cargaba, o cuando se activaba una animación, etcétera.
Interacciones de vista para identificar rápidamente lo que sucedió en una página después de que un usuario interactuó con ella.
Encuentra problemas de rendimiento del desplazamiento en tiempo real destacando la página cada vez que se activa un objeto de escucha potencialmente problemático.
Consulta 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 extensión de Chrome, como módulo de Node.js y en 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, así como sugerencias para mejorarla.
Las siguientes auditorías son especialmente relevantes:
Respuesta
Máximo retraso de primera entrada posible. Estima cuánto tiempo tardará tu app en responder a las acciones 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 y no responde a la entrada del usuario, como clics del mouse, toques en la pantalla o presiones del teclado.
Time to Interactive. Mide el momento en que un usuario puede interactuar de forma constante 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 dedicado a recuperar recursos a través de la red.
La carga de la página no es lo suficientemente rápida en las redes móviles.
Difiere la carga de imágenes fuera de pantalla. Posponer la carga de imágenes fuera de la pantalla hasta que sean necesarias
Usa un tamaño adecuado para las imágenes. No publiques imágenes que sean mucho más grandes que el tamaño que se renderiza en el viewport para dispositivos móviles.
Evita un tamaño excesivo de DOM. Reduce los bytes de red enviando solo los nodos DOM necesarios 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 perspectiva para analizar la experiencia del usuario de un sitio web como un recorrido compuesto por interacciones distintas. Comprende cómo perciben los usuarios tu sitio para establecer objetivos de rendimiento que tengan el mayor impacto en la experiencia del usuario.
Enfocadas en el usuario
Responder a la entrada del usuario en menos de 100 ms
Producir un fotograma en menos de 10 ms cuando se desplaza o se anima
Maximiza el tiempo de inactividad del subproceso principal.
Carga contenido interactivo en menos de 5,000 ms.