O RAIL é um modelo de performance centrado no usuário que oferece uma estrutura para pensar sobre a performance. O modelo divide a experiência do usuário em ações principais (por exemplo, tocar, rolar, carregar) e ajuda você a definir metas de performance para cada uma delas.
RAIL significa quatro aspectos distintos do ciclo de vida de um app da Web: resposta, animação, inatividade e carregamento. Os usuários têm expectativas de desempenho diferentes para cada um desses contextos. Por isso, as metas de desempenho são definidas com base no contexto e na pesquisa de UX sobre como os usuários percebem atrasos.
Foco no usuário
Coloque os usuários no centro do seu esforço de performance. A tabela abaixo descreve as principais métricas de como os usuários percebem os atrasos de performance:
Percepção do usuário sobre atrasos no desempenho| 0 a 16 ms | Os usuários são muito bons em rastrear movimentos e não gostam quando as animações não são suaves. Eles percebem as animações como suaves desde que 60 novos frames sejam renderizados a cada segundo. Isso significa 16 ms por frame, incluindo o tempo necessário para o navegador renderizar o novo frame na tela, deixando cerca de 10 ms para o app produzir um frame. |
| 0 a 100 ms | Responda às ações do usuário dentro dessa janela de tempo para que ele sinta que o resultado é imediato. Se for mais longo, a conexão entre ação e reação será interrompida. |
| 100 a 1.000 ms | Nessa janela, as coisas parecem fazer parte de uma progressão natural e contínua de tarefas. Para a maioria dos usuários na Web, carregar páginas ou mudar de visualização representa uma tarefa. |
| 1000 ms ou mais | Depois de 1.000 milissegundos (1 segundo), os usuários perdem o foco na tarefa que estão realizando. |
| 10.000 ms ou mais | Acima de 10.000 milissegundos (10 segundos), os usuários ficam frustrados e provavelmente abandonam as tarefas. Elas podem ou não voltar mais tarde. |
Metas e diretrizes
No contexto do RAIL, os termos metas e diretrizes têm significados específicos:
Metas: principais métricas de performance relacionadas à experiência do usuário. Por exemplo, toque para pintar em menos de 100 milissegundos. Como a percepção humana é relativamente constante, é improvável que essas metas mudem em breve.
da marca. Recomendações que ajudam você a alcançar metas. Elas podem ser específicas para as condições atuais de hardware e conexão de rede e, portanto, podem mudar com o tempo.
Resposta: processe eventos em menos de 50 ms
Meta: concluir uma transição iniciada por entrada do usuário em até 100 ms para que os usuários sintam que as interações são instantâneas.
Diretrizes:
Para garantir uma resposta visível em até 100 ms, processe eventos de entrada do usuário em até 50 ms. Isso se aplica à maioria das entradas, como clicar em botões, alternar controles de formulário ou iniciar animações. Isso não se aplica a arrastar e rolar com o toque.
Embora possa parecer contraditório, nem sempre é a melhor opção responder imediatamente à entrada do usuário. Você pode usar essa janela de 100 ms para fazer outros trabalhos caros, mas tenha cuidado para não bloquear o usuário. Se possível, trabalhe em segundo plano.
Para ações que levam mais de 50 ms para serem concluídas, sempre forneça feedback.
50 ms ou 100 ms?
A meta é responder à entrada em menos de 100 ms. Por que nosso orçamento é de apenas 50 ms? Isso acontece porque geralmente há outro trabalho sendo feito além do processamento de entrada, e esse trabalho ocupa parte do tempo disponível para uma resposta de entrada aceitável. Se um aplicativo estiver realizando o trabalho nos blocos recomendados de 50 ms durante o tempo ocioso, isso significa que a entrada poderá ser enfileirada por até 50 ms se ocorrer durante um desses blocos de trabalho. Considerando isso, é seguro presumir que apenas os 50 ms restantes estão disponíveis para o processamento real de entrada. Esse efeito é mostrado no diagrama abaixo, que mostra como a entrada recebida durante uma tarefa ociosa é enfileirada, reduzindo o tempo de processamento disponível:
Animação: produzir um frame em 10 ms
Metas:
Produza cada frame em uma animação em 10 ms ou menos. Tecnicamente, o orçamento máximo para cada frame é de 16 ms (1.000 ms / 60 frames por segundo ≈ 16 ms), mas os navegadores precisam de cerca de 6 ms para renderizar cada frame. Por isso, a diretriz é de 10 ms por frame.
Busque uma aparência visual suave. Os usuários percebem quando as taxas de frames variam.
Diretrizes:
Em pontos de alta pressão, como animações, a chave é não fazer nada quando possível e o mínimo absoluto quando não for. Sempre que possível, use a resposta de 100 ms para pré-calcular trabalhos caros e maximizar suas chances de atingir 60 fps.
Consulte Desempenho de renderização para várias estratégias de otimização de animação.
- Animações visuais, como entradas e saídas, interpolações e indicadores de carregamento.
- Rolar. Isso inclui o movimento de deslizar, que acontece quando o usuário começa a rolar a tela, solta e a página continua rolando.
- Arrastando. As animações geralmente seguem as interações do usuário, como deslocar um mapa ou fazer um movimento de pinça para aumentar o zoom.
Inativo: maximizar o tempo de inatividade
Meta: maximizar o tempo ocioso para aumentar as chances de a página responder à entrada do usuário em até 50 ms.
Diretrizes:
Use o tempo ocioso para concluir o trabalho adiado. Por exemplo, para o carregamento inicial da página, carregue o mínimo de dados possível e use o tempo ocioso para carregar o restante.
Realize o trabalho durante o tempo ocioso em 50 ms ou menos. Se for mais longo, você corre o risco de interferir na capacidade do app de responder à entrada do usuário em 50 ms.
Se um usuário interagir com uma página durante o trabalho em tempo ocioso, a interação do usuário sempre terá a maior prioridade e vai interromper o trabalho em tempo ocioso.
Carregamento: entregar conteúdo e se tornar interativo em menos de 5 segundos
Quando as páginas carregam lentamente, a atenção do usuário se dispersa, e ele percebe a tarefa como interrompida. Sites que carregam rapidamente têm sessões médias mais longas, taxas de rejeição mais baixas e maior visibilidade de anúncios.
Metas:
Otimize para um desempenho de carregamento rápido em relação aos recursos do dispositivo e da rede dos seus usuários. Atualmente, um bom objetivo para os primeiros carregamentos é carregar a página e ser interativa em 5 segundos ou menos em dispositivos móveis intermediários com conexões 3G lentas.
Para carregamentos subsequentes, o ideal é carregar a página em menos de 2 segundos.
Diretrizes:
Teste o desempenho de carregamento nos dispositivos móveis e nas conexões de rede mais usados pelos seus usuários. Use o Chrome User Experience Report para descobrir a distribuição de conexões dos seus usuários. Se os dados não estiverem disponíveis para seu site, The Mobile Economy 2019 sugere que um bom valor de referência global é um smartphone Android de gama média, como um Moto G4, e uma rede 3G lenta (definida como 400 ms de RTT e 400 kbps de velocidade de transferência). Essa combinação está disponível no WebPageTest.
Embora o dispositivo do usuário móvel típico possa afirmar que está em uma conexão 2G, 3G ou 4G, na realidade, a velocidade de conexão efetiva costuma ser significativamente mais lenta devido à perda de pacotes e à variação da rede.
Não é preciso carregar tudo em menos de 5 segundos para produzir a percepção de um carregamento completo. Considere o carregamento lento de imagens, o JavaScript de divisão de código pacotes e outras otimizações sugeridas no web.dev.
Ferramentas para medir o RAIL
Há algumas ferramentas para ajudar você a automatizar as medições do RAIL. A escolha depende do tipo de informação que você precisa e do fluxo de trabalho que prefere.
Chrome DevTools
As Ferramentas para desenvolvedores do Chrome oferecem uma análise detalhada de tudo o que acontece enquanto a página é carregada ou executada. Consulte Introdução à análise de desempenho de execução para conhecer a interface do painel Desempenho.
Os seguintes recursos do DevTools são especialmente relevantes:
Limite a CPU para simular um dispositivo menos potente.
Limite a rede para simular conexões mais lentas.
Veja a atividade da linha de execução principal para conferir todos os eventos que ocorreram na linha de execução principal durante a gravação.
Veja as atividades da linha de execução principal em uma tabela para classificar as atividades com base nas que levaram mais tempo.
Analise os quadros por segundo (QPS) para medir se as animações realmente são executadas sem problemas.
Monitore o uso da CPU, o tamanho do heap JS, os nós DOM, os layouts por segundo e mais em tempo real com o Monitor de desempenho.
Visualize solicitações de rede que ocorreram durante a gravação com a seção Rede.
Faça capturas de tela durante a gravação para reproduzir exatamente como a página apareceu enquanto carregava ou uma animação era disparada etc.
Veja as interações para identificar rapidamente o que aconteceu em uma página depois que um usuário interagiu com ela.
Encontre problemas de desempenho de rolagem em tempo real destacando a página sempre que um listener potencialmente problemático é acionado.
Veja eventos de renderização em tempo real para identificar eventos de renderização caros que podem prejudicar o desempenho das suas animações.
Farol
O Lighthouse está disponível no Chrome DevTools, no PageSpeed Insights, como uma extensão do Chrome, como um módulo do Node.js e no WebPageTest. Você fornece um URL, ele simula um dispositivo intermediário com uma conexão 3G lenta, executa uma série de auditorias na página e gera um relatório sobre o desempenho do carregamento, além de sugestões de melhoria.
As seguintes auditorias são especialmente relevantes:
Resposta
Max Potential First Input Delay. Estima quanto tempo seu app vai levar para responder à ação do usuário, com base no tempo ocioso da linha de execução principal.
Não usa listeners passivos para melhorar o desempenho de rolagem.
Tempo total de bloqueio. Mede o tempo total em que uma página fica bloqueada e não responde à entrada do usuário, como cliques do mouse, toques na tela ou pressionamentos de teclas.
Tempo para interação. Mede quando um usuário pode interagir de forma consistente com todos os elementos da página.
Carregamento
Não registra um service worker que controla a página e start_url. Um service worker pode armazenar em cache recursos comuns no dispositivo de um usuário, reduzindo o tempo gasto na busca de recursos pela rede.
O carregamento de página não é rápido o suficiente em redes móveis.
Adie a exibição de imagens fora da tela. Adie o carregamento de imagens fora da tela até que elas sejam necessárias.
Defina um tamanho adequado para as imagens. Não veicule imagens significativamente maiores do que o tamanho renderizado na janela de visualização para dispositivos móveis.
Evite um DOM de tamanho excessivo. Reduza os bytes de rede enviando apenas os nós do DOM necessários para renderizar a página.
WebPageTest
O WebPageTest é uma ferramenta de performance da Web que usa navegadores reais para acessar páginas da Web e coletar métricas de tempo. Insira um URL em webpagetest.org/easy para receber um relatório detalhado sobre o desempenho de carregamento da página em um dispositivo Moto G4 real com uma conexão 3G lenta. Também é possível configurar para incluir uma auditoria do Lighthouse.
Resumo
O RAIL é uma forma de analisar a experiência do usuário de um site como uma jornada composta de interações distintas. Entenda como os usuários percebem seu site para definir metas de performance com o maior impacto na experiência do usuário.
Foco no usuário.
Responder à entrada do usuário em menos de 100 ms.
Produza um frame em menos de 10 ms ao animar ou rolar.
Maximize o tempo ocioso da linha de execução principal.
Carregue conteúdo interativo em menos de 5.000 ms.