Meça o desempenho com o modelo RAIL
RAIL é um modelo de desempenho centrado no usuário que fornece uma estrutura para analisar o desempenho. O modelo divide a experiência do usuário em ações-chave (por exemplo, tocar, rolar, carregar) e ajuda a definir metas de desempenho para cada uma delas.
RAIL representa quatro aspectos distintos do ciclo de vida do aplicativo da web: resposta, animação, inatividade e carregamento. Os usuários têm expectativas de desempenho diferentes para cada um desses contextos. Portanto, as metas de desempenho são definidas com base no contexto e na pesquisa de UX sobre como os usuários percebem os atrasos.
Foco no usuário #
Faça dos usuários o ponto central de seu esforço de desempenho. A tabela abaixo descreve as principais métricas de como os usuários percebem 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. Eles percebem as animações como suaves, desde que 60 novos quadros sejam renderizados a cada segundo. São 16 ms por quadro, incluindo o tempo que leva para o navegador pintar o novo quadro na tela, deixando um aplicativo de cerca de 10 ms para produzir um quadro. |
| 0 a 100 ms | Responda às ações do usuário dentro dessa janela de tempo e eles sentirão que o resultado é imediato. Se levar mais tempo, a conexão entre ação e reação é quebrada. |
| 100 a 1000 ms | Dentro desta janela, as coisas parecem ser parte de uma progressão natural e contínua de tarefas. Para a maioria dos usuários da web, carregar páginas ou alterar visualizações representa uma tarefa. |
| 1000 ms ou mais | Além de 1000 milissegundos (1 segundo), os usuários perdem o foco na tarefa que estão executando. |
| 10.000 ms ou mais | Além de 10.000 milissegundos (10 segundos), os usuários ficam frustrados e tendem a abandonar as tarefas. Eles podem ou não voltar mais tarde. |
Metas e diretrizes #
No contexto do RAIL, os termos objetivos e diretrizes têm significados específicos:
Objetivos. Principais métricas de desempenho 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 esses objetivos mudem tão cedo.
Diretrizes. Recomendações que ajudam o usuário a atingir objetivos. Podem ser específicas para o hardware atual e as condições de conexão de rede e, portanto, mudar com o tempo.
Resposta: processar eventos em menos de 50 ms #
Objetivo : concluir uma transição iniciada pela entrada do usuário em 100 ms, para que sintam que as interações são instantâneas.
Diretrizes:
Para garantir uma resposta visível em 100 ms, processe os eventos de entrada do usuário em 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 por toque.
Embora possa parecer contra-intuitivo, nem sempre é a chamada certa para responder à entrada do usuário imediatamente. Você pode usar essa janela de 100 ms para fazer outro trabalho caro, 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? #
O objetivo é responder à entrada em menos de 100 ms, então por que a nossa reserva é de apenas 50 ms? Isso ocorre porque geralmente há outro trabalho sendo feito, além do tratamento de entrada, e ele ocupa parte do tempo disponível para obter uma resposta de entrada aceitável. Se um aplicativo estiver executando o trabalho nos blocos recomendados de 50 ms durante o tempo ocioso, isso significa que a entrada pode ser enfileirada por até 50 ms se ocorrer durante um desses blocos de trabalho. Levando em conta isso, é seguro presumir que apenas os 50 ms restantes estão disponíveis para o tratamento de entrada real. Este efeito é visualizado 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 quadro em 10 ms #
Objetivos :
Produza cada quadro de uma animação em 10 ms ou menos. Tecnicamente, a reserva máxima para cada quadro é de 16 ms (1000 ms/60 quadros por segundo ≈ 16 ms), mas os navegadores precisam de cerca de 6 ms para renderizar cada quadro, por isso a diretriz de 10 ms por quadro.
Procure suavidade visual. Os usuários percebem quando as taxas de quadros variam.
Diretrizes :
Em pontos de alta pressão, como animações, a chave é não fazer nada em que você pode e o mínimo absoluto em que você não pode. Sempre que possível, use a resposta de 100 ms para pré-calcular o trabalho caro, de modo que você maximize suas chances de atingir 60 fps.
Consulte Desempenho de renderização para obter várias estratégias de otimização de animação.
Inativo: maximizar o tempo ocioso #
Objetivo: maximizar o tempo ocioso para aumentar as chances de que a página responda à entrada do usuário em 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, em seguida, use o tempo ocioso para carregar o restante.
Execute o trabalho durante o tempo ocioso em 50 ms ou menos. Ao demorar mais, você corre o risco de interferir na capacidade do aplicativo 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 deve sempre ter a prioridade mais alta e interromper o trabalho em tempo ocioso.
Carregar: entregue conteúdo e torne-se interativo em menos de 5 segundos #
Quando as páginas carregam lentamente, a atenção do usuário se dispersa e os usuários percebem 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 do anúncio.
Objetivos:
Otimize para obter desempenho de carregamento rápido em relação aos recursos do dispositivo e da rede de seus usuários. Atualmente, um bom objetivo para os primeiros carregamentos é carregar a página e ser interativo em 5 segundos ou menos a partir de dispositivos móveis de médio alcance com conexões 3G lentas.
Para os próximos carregamentos, uma boa meta é carregar a página em menos de 2 segundos.
Diretrizes:
Teste seu desempenho de carregamento nos dispositivos móveis e conexões de rede comuns entre seus usuários. Você pode usar o Relatório de experiência do usuário do Chrome para descobrir a distribuição de conexão de seus usuários. Se os dados não estiverem disponíveis para seu site, The Mobile Economy 2019 sugere que uma boa linha de base global é um telefone Android de médio alcance, como um Moto G4 e uma rede 3G lenta (definida como 400 ms RTT e velocidade de transferência de 400 kbps). Essa combinação está disponível em WebPageTest.
Lembre-se de que, embora o dispositivo de um usuário móvel típico possa alegar que está em uma conexão 2G, 3G ou 4G, na realidade a velocidade efetiva da conexão costuma ser significativamente mais lenta, devido à perda de pacotes e à variação da rede.
Você não precisa carregar tudo em menos de 5 segundos para causar a impressão de um carregamento completo. Considere imagens de carregamento lento, pacotes JavaScript de divisão de código e outras otimizações sugeridas em web.dev.
Ferramentas para medir RAIL #
Existem algumas ferramentas para ajudá-lo a automatizar as medições do RAIL. Qual você usa depende do tipo de informação de que você precisa e de qual tipo de fluxo de trabalho você prefere.
Chrome DevTools #
O Chrome DevTools fornece análises detalhadas sobre tudo o que acontece enquanto sua página é carregada ou executada. Consulte Introdução à análise do desempenho do tempo de execução para se familiarizar com a IU do painel Desempenho.
Os seguintes recursos do DevTools são especialmente relevantes:
Acelere sua CPU para simular um dispositivo menos potente.
Acelere a rede para simular conexões mais lentas.
Visualize a atividade da thread principal para ver todos os eventos que ocorreram na thread principal enquanto você estava gravando.
Visualize as principais atividades da thread em uma tabela para classificar as atividades com base naquelas que ocupam mais tempo.
Analise quadros por segundo (FPS) para medir se suas animações realmente funcionam sem problemas.
Monitore o uso da CPU, tamanho de heap JS, nós DOM, layouts por segundo e muito mais em tempo real com o Monitor de Desempenho.
Visualize solicitações de rede que ocorreram enquanto você estava gravando com a seção Rede.
Capture screenshots durante a gravação para reproduzir exatamente como a página parecia enquanto a página era carregada ou uma animação era disparada e assim por diante.
Visualize 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 ouvinte potencialmente problemático for acionado.
Visualize eventos de pintura em tempo real para identificar eventos de pintura custosos que podem prejudicar o desempenho de suas animações.
Lighthouse #
O Lighthouse está disponível no Chrome DevTools, em web.dev/measure, como uma extensão do Chrome, como um módulo Node.js e dentro do WebPageTest. Você fornece uma URL, ele simula um dispositivo de médio alcance 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 como melhorar.
As seguintes auditorias são especialmente relevantes:
Resposta
Atraso de entrada com potencial máximo. Estima quanto tempo seu aplicativo levará para responder à entrada do usuário, com base no tempo ocioso da thread principal.
Não usa ouvintes passivos para melhorar o desempenho de rolagem.
Tempo total de bloqueio. Mede a quantidade total de tempo que uma página fica bloqueada para responder à entrada do usuário, como cliques do mouse, toques na tela ou pressionamentos de teclado.
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 trabalho de serviço que controla a página e start_url. Um trabalho de serviço pode armazenar em cache recursos comuns no dispositivo de um usuário, reduzindo o tempo gasto na busca de recursos na rede.
O carregamento da página não é rápido o suficiente em redes móveis.
Adie imagens fora da tela. Adie o carregamento de imagens fora da tela até que sejam necessárias.
Tamanho adequado das imagens. Não exiba imagens significativamente maiores do que o tamanho renderizado na janela de visualização móvel.
Evite um tamanho excessivo de DOM. Reduza os bytes da rede enviando apenas nós 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 e coletar métricas de tempo. Insira uma URL em webpagetest.org/easy para obter um relatório detalhado sobre o desempenho de carregamento da página em um dispositivo Moto G4 real com uma conexão 3G lenta. Você também pode configurar para incluir uma auditoria do Lighthouse.
Resumo #
RAIL é uma lente para olhar 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 desempenho com maior impacto na experiência do usuário.
Concentre-se no usuário.
Responda à entrada do usuário em menos de 100 ms.
Produza um quadro em menos de 10 ms ao animar ou rolar.
Maximize o tempo ocioso da thread principal.
Carregue conteúdo interativo em menos de 5000 ms.