O RAIL é um modelo de desempenho centrado no usuário. Todo aplicativo web tem estes quatro aspectos distintos no seu ciclo de vida, e o desempenho se relaciona com eles de maneiras muito diferentes:
TL;DR
- Foco no usuário, o objetivo final não é fazer o site ser rápido em dispositivos específicos, é deixar os usuários satisfeitos.
- Responder aos usuários imediatamente. Reconhecer o comando do usuário em menos de 100 ms.
- Durante animação ou rolagem, produzir um quadro em menos de 10 ms.
- Maximizar o tempo de ociosidade do encadeamento principal.
- Manter os usuários envolvidos, fornecer conteúdo interativo em menos de 1000 ms.
Foco no usuário
Torne os usuários o ponto central das suas iniciativas de desempenho. A maior parte do tempo que os usuários gastam no seu site não é esperando-o carregar, mas esperando a resposta enquanto o usam. Saiba como os usuários percebem a lentidão:
| Lentidão & Reação do usuário | |
|---|---|
| 0–16 ms | As pessoas são muito boas em acompanhar movimentos e não gostam quando as animações não são fluidas. Os usuários consideram animações fluidas desde que 60 novos quadros sejam renderizados por segundo. Isso significa 16 ms por quadro, incluindo o tempo necessário para o navegador exibir o novo quadro na tela, deixando o aplicativo com cerca de 10 ms para produzi-lo. |
| 0–100 ms | Responda a uma ação do usuário dentro dessa janela de tempo e os usuários sentirão que a resposta foi imediata. Qualquer tempo a mais faz com que a conexão entre ação e reação seja rompida. |
| 100–300 ms | Os usuários notam um atraso leve. |
| 300–1000 ms | Nesta janela, as coisas são percebidas como parte de uma progressão natural e contínua de tarefas. Para a maioria dos usuários da web, carregar páginas ou trocar vistas representa uma tarefa. |
| Mais de 1000 ms | Após 1 segundo, o usuário perde o foco na tarefa que está realizando. |
| Mais de 10.000 ms | O usuário fica frustrado e provavelmente abandona a tarefa. Pode ou não retornar no futuro. |
Resposta: responda em menos de 100 ms
Você tem 100 ms para responder à interação do usuário antes de ele perceber uma lentidão. Isso se aplica à maioria das interações, como clicar em botões, ativar ou desativar controles de formulário ou iniciar animações. Essa regra não se aplica a rolagem de toque ou convencional.
Se você não responder, a conexão entre ação e reação será rompida. Os usuários percebem.
Embora pareça óbvio que responder às ações do usuário de forma imediata é o ideal, nem sempre é a decisão mais certa. Use essa janela de 100 ms para fazer outros trabalhos pesados, mas tome cuidado para não parar o usuário. Se possível, faça o trabalho em segundo plano.
Para ações que precisam de mais de 500 ms para serem concluídas, sempre forneça feedback.
Animação: produza um quadro em 10ms
As animações não são simplesmente efeitos de IU sofisticados. Por exemplo, rolagem e rolagem de toque são tipos de animação.
Os usuários percebem quando a taxa de quadros da animação varia. Seu objetivo é produzir 60 quadros por segundo, e todo quadro tem que passar pelas seguintes etapas:
De um ponto de vista puramente matemático, todo quadro tem um "orçamento" de cerca de 16 ms (1000 ms/60 quadros por segundo = 16,66 ms por quadro). Porém, como os navegadores precisam de algum tempo para exibir o novo quadro na tela, o seu código deve finalizar a execução em até 10 ms.
Em pontos de alta pressão, como as animações, a chave é não fazer nada onde for possível e absolutamente o mínimo onde não for possível não fazer nada. Sempre que der, use a resposta de 100 ms para pré-calcular trabalhos demorados para maximizar suas chances de atingir 60 fps.
Para saber mais, acesse Desempenho de renderização.
Ociosidade: maximize o tempo de ociosidade
Use o tempo de ociosidade para concluir trabalhos adiados. Por exemplo, mantenha um mínimo de dados pré-carregados para que o aplicativo carregue rapidamente, e use o tempo de ociosidade para carregar os demais dados.
Os trabalhos adiados devem ser agrupados em blocos de cerca de 50 ms. Caso um usuário comece a interagir, a prioridade é responder a isso.
Para tornar possível uma <resposta de 100 ms, o aplicativo deve devolver o controle ao encadeamento principal a cada <50 ms, de forma que ele possa executar o funil de pixels, reagir à interação do usuário e outros.
Trabalhar com blocos de 50 ms permite tanto que a tarefa seja finalizada quanto resposta instantânea.
Carregamento: entregue conteúdo em menos de 1000 ms
Carregue o site em menos de 1 segundo. Caso contrário, o usuário se dispersa e a percepção dele de lidar com a tarefa é quebrada.
Concentre-se em otimizar o caminho crítico de renderização para desobstruir a renderização.
Você não precisa carregar tudo em menos de 1 segundo para produzir a percepção de um carregamento completo. Use a renderização progressiva e faça algumas coisas em segundo plano. Adie carregamentos não essenciais a períodos de tempo ocioso (veja mais sobre isso no curso de otimização do desempenho de sites do Udacity).
Resumo das principais métricas do RAIL
Para avaliar o seu site com base nas métricas do RAIL, use a ferramenta "Timeline" do Chrome DevTools para registrar as ações dos usuários. Em seguida, compare os tempos de registro da "Timeline" com as principais métricas do RAIL:
| Etapa do RAIL | Métrica | Ações do usuário |
|---|---|---|
| Resposta | Latência da interação (do toque à gravação) de menos de 100 ms. | O usuário toca em um botão (por exemplo, abre o navegador). |
| Animação | O trabalho de cada quadro (do JS à gravação) é concluído em menos de 16ms. | O usuário rola a página, arrasta o dedo (para abrir um menu, por exemplo) ou vê uma animação. Ao arrastar, a resposta do aplicativo é vinculada à posição do dedo, como puxar para atualizar ou arrastar um carrossel. Essa métrica se aplica somente à fase contínua de arrastos, não ao início. |
| Ociosidade | Trabalho de JS do encadeamento principal dividido em partes não superiores a 50 ms. | O usuário não está interagindo com a página, mas o encadeamento principal deve estar suficientemente disponível para lidar com a próxima interação do usuário. |
| Carregamento | Página considerada pronta para uso em 1000 ms. | O usuário carrega a página e vê o conteúdo do caminho crítico. |