O RAIL é um modelo de desempenho centrado no usuário que fornece uma estrutura para pensar sobre o desempenho. O modelo divide a experiência do usuário em ações importantes (por exemplo, tocar, rolar, carregar) e ajuda a definir metas de performance para cada uma delas.
RAIL significa quatro aspectos distintos do ciclo de vida do 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 performance são definidas com base no contexto e na pesquisa de UX sobre como os usuários percebem atrasos.
Foco no usuário
Faça dos usuários o ponto focal do seu esforço de performance. A tabela abaixo descreve as principais métricas de como os usuários percebem os atrasos de desempenho:
Percepção do usuário sobre atrasos no desempenho| 0 a 16 ms | Os usuários são excepcionalmente bons em rastrear movimentos e não gostam quando as animações não são suaves. As animações são percebidas como suaves desde que 60 novos frames sejam renderizados por segundo. Isso significa 16 ms por frame, incluindo o tempo que o navegador leva para pintar 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 desse período para que ele sinta que o resultado é imediato. Se demorar mais, 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. |
| 1.000 ms ou mais | Após 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 vão abandonar as tarefas. Eles 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: as 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 atingir metas. Elas podem ser específicas para as condições atuais de hardware e conexão de rede e, portanto, podem mudar ao longo do tempo.
Resposta: processar eventos em menos de 50 ms
Meta: concluir uma transição iniciada pela entrada do usuário em até 100 ms para que as interações pareçam instantâneas.
Diretrizes:
Para garantir uma resposta visível em até 100 ms, processe os 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 ou rolar com o toque.
Embora possa parecer contra-intuitivo, nem sempre é a decisão certa responder imediatamente à entrada do usuário. Você pode usar essa janela de 100 ms para fazer outros trabalhos caros, mas tome 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. Então, por que nosso orçamento é de apenas 50 ms? Isso ocorre 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 trabalho nos blocos recomendados de 50 ms durante o tempo de inatividade, isso significa que a entrada pode ser colocada em fila 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 de entrada real. Esse efeito é visualizado no diagrama abaixo, que mostra como a entrada recebida durante uma tarefa inativa é colocada em fila, 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 quadros por segundo ≈ 16 ms), mas os navegadores precisam de cerca de 6 ms para renderizar cada frame, daí a diretriz de 10 ms por frame.
Busque suavidade visual. Os usuários percebem quando as taxas de frames variam.
Diretrizes:
Em pontos de alta pressão, como animações, o segredo é 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 o trabalho pesado e maximizar as chances de atingir 60 qps.
Consulte Desempenho de renderização para ver várias estratégias de otimização de animação.
- Animações visuais, como entradas e saídas, tweens e indicadores de carregamento.
- Rolando. Isso inclui o movimento de deslizar, que é quando o usuário começa a rolar, solta e a página continua rolando.
- Arrastar. As animações geralmente seguem as interações do usuário, como deslocar um mapa ou fazer um gesto de pinça para aumentar o zoom.
Inativo: maximizar o tempo de inatividade
Meta: maximizar o tempo de inatividade 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 de inatividade em 50 ms ou menos. Se demorar mais, 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 precisa sempre ter a prioridade mais alta e interromper o trabalho em tempo ocioso.
Carregamento: entregar conteúdo e se tornar interativo em menos de 5 segundos
Quando o carregamento de página é lento, 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 de dispositivo e rede dos usuários. Atualmente, uma boa meta para os primeiros carregamentos é carregar a página e ser interativa em 5 segundos ou menos em dispositivos móveis de médio porte com conexões 3G lentas.
Para carregamentos subsequentes, uma boa meta é 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 comuns entre os usuários. Use o Chrome User Experience Report para descobrir a distribuição de conexão dos seus usuários. Se os dados não estiverem disponíveis para seu site, The Mobile Economy 2019 sugere que uma boa referência global é um smartphone Android de médio alcance, como um Moto G4, e uma rede 3G lenta (definida como RTT de 400 ms e velocidade de transferência de 400 kbps). Essa combinação está disponível no WebPageTest.
Lembre-se de que, embora o dispositivo do usuário de dispositivo móvel típico possa alegar 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 é necessário carregar tudo em menos de 5 segundos para produzir a percepção de um carregamento completo. Considere o carregamento lento de imagens, a divisão de código de pacotes JavaScript e outras otimizações sugeridas no web.dev.
Ferramentas para medir o RAIL
Existem 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 tipo de fluxo de trabalho que prefere.
Chrome DevTools
O Chrome DevTools oferece uma análise detalhada de tudo o que acontece enquanto a página é carregada ou executada. Consulte Introdução à análise de desempenho de tempo de execução para se familiarizar com 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.
Atividade da linha de execução principal para ver todos os eventos que ocorreram na linha de execução principal durante a gravação.
Confira 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 de JS, os nós do DOM, os layouts por segundo e muito mais em tempo real com o Monitor de desempenho.
Visualize as solicitações de rede que ocorreram durante a gravação com a seção Rede.
Capture capturas de tela durante a gravação para reproduzir exatamente como a página estava durante o carregamento de página, ou uma animação disparada, e assim por diante.
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 for acionado.
Veja eventos de pintura em tempo real para identificar eventos de pintura caros que podem estar prejudicando 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, em seguida, fornece um relatório sobre o desempenho de carregamento, além de sugestões de melhoria.
As seguintes auditorias são especialmente relevantes:
Resposta
Possível latência máxima na primeira entrada. Estima quanto tempo o app vai levar para responder à entrada do usuário, com base no tempo de inatividade da linha de execução principal.
Não usa listeners passivos para melhorar o desempenho de rolagem.
Total Blocking Time. Mede o tempo total em que uma página é impedida de responder à entrada do usuário, como cliques do mouse, toques na tela ou pressionamentos de teclado.
Time to Interactive. 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 para buscar recursos na rede.
O carregamento de página não é rápido o suficiente em redes móveis.
Adiar o carregamento 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 com um tamanho grande demais. 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 desempenho 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 configurá-lo para incluir uma auditoria do Lighthouse.
Resumo
O RAIL é uma lente para analisar a experiência do usuário de um site como uma jornada composta por 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.
Responda à entrada do usuário em menos de 100 ms.
Produza um frame em menos de 10 ms ao animar ou rolar.
Maximize o tempo de inatividade da linha de execução principal.
Carregar conteúdo interativo em menos de 5.000 ms.