A performance do tempo de execução é a performance da página quando ela está em execução, e não durante o carregamento. Este tutorial ensina a usar o painel de desempenho do Chrome DevTools para analisar o desempenho no tempo de execução. Em termos do modelo RAIL, as habilidades aprendidas neste tutorial são úteis para analisar as fases de resposta, animação e inatividade da página.
Primeiros passos
Neste tutorial, você vai abrir o DevTools em uma página ativa e usar o painel "Performance" para encontrar um gargalo de desempenho na página.
- Abra o Google Chrome no modo de navegação anônima. O modo de navegação anônima garante que o Chrome seja executado em um estado limpo. Por exemplo, se você tem muitas extensões instaladas, elas podem criar ruído nas suas medições de performance.
Carregue a página a seguir na sua janela anônima. Esta é a demonstração da qual você criará o perfil. A página mostra um monte de quadrados azuis se movendo para cima e para baixo.
https://googlechrome.github.io/devtools-samples/jank/
Pressione Command + Option + I (Mac) ou Control + Shift + I (Windows e Linux) para abrir o DevTools.
Figura 1. A demonstração à esquerda e DevTools à direita
Simular uma CPU móvel
Os dispositivos móveis têm muito menos energia de CPU do que desktops e laptops. Sempre que você criar um perfil para uma página, use a limitação de CPU para simular o desempenho da página em dispositivos móveis.
- No DevTools, clique na guia Performance.
- Verifique se a caixa de seleção Capturas de tela está marcada.
- Clique em Capture Settings . O DevTools revela as configurações relacionadas à captura de métricas de desempenho.
Em CPU, selecione 2x lentidão. O DevTools limita a CPU para que fique duas vezes mais lenta do que o normal.
Figura 2. Limitação da CPU destacada em azul
Configurar a demonstração
É difícil criar uma demonstração de desempenho do ambiente de execução que funcione de maneira consistente para todos os leitores deste site. Esta seção permite personalizar a demonstração para garantir que sua experiência seja relativamente consistente com as capturas de tela e descrições mostradas neste tutorial, independente da configuração específica.
- Continue clicando em Add 10 até que os quadrados azuis se movam visivelmente mais lentamente do que antes. Em uma máquina de última geração, o processo pode levar cerca de 20 cliques.
Clique em Otimizar. Os quadrados azuis devem se mover mais rápido e suavemente.
Clique em Cancelar otimização. Os quadrados azuis se movem mais lentamente e com mais instabilidade novamente.
Gravar desempenho em tempo de execução
Quando você executou a versão otimizada da página, os quadrados azuis se movem mais rápido. Por quê? Ambas as versões precisam mover cada quadrado com a mesma quantidade de espaço no mesmo período. Faça uma gravação no painel "Performance" para aprender a detectar o gargalo na versão não otimizada.
No DevTools, clique em Record . Ele captura métricas de desempenho conforme a página é executada.
Figura 3: criação de perfil da página
Aguarde alguns segundos.
Clique em Stop. O DevTools interrompe a gravação, processa os dados e exibe os resultados no painel "Performance".
Figura 4: resultados do perfil
Uau, é uma quantidade incrível de dados. Não se preocupe, tudo fará mais sentido em breve.
Analisar os resultados
Depois de registrar o desempenho da página, você pode avaliar a qualidade dela e descobrir as causas.
Analisar quadros por segundo
A métrica principal para medir o desempenho de uma animação são os quadros por segundo (QPS). Os usuários ficam felizes quando as animações são executadas a 60 QPS.
Consulte o gráfico QPS. Sempre que você vê uma barra vermelha acima de QPS, significa que o frame rate caiu tão baixo que provavelmente está prejudicando a experiência do usuário. Em geral, quanto maior a barra verde, maior o QPS.
Figura 5: o gráfico de QPS, destacado em azul
Abaixo do gráfico QPS, está o gráfico de CPU. As cores no gráfico de CPU correspondem às cores na guia Summary, na parte inferior do painel "Performance". O fato de o gráfico de CPU estar cheio de cores significa que a CPU atingiu o limite máximo durante a gravação. Sempre que a CPU estiver esgotada por longos períodos, você precisará encontrar maneiras de fazer menos trabalho.
Figura 6: o gráfico da CPU e a guia "Resumo", destacados em azul
Passe o cursor sobre os gráficos FPS, CPU ou NET. O DevTools mostra uma captura de tela da página nesse momento. Mova o mouse para a esquerda e para a direita para reproduzir a gravação. Isso é chamado de limpeza e é útil para analisar manualmente a progressão das animações.
Figura 7: visualização de uma captura de tela da página perto da marca de 2.000 ms da gravação.
Na seção Frames, passe o cursor do mouse sobre um dos quadrados verdes. O DevTools mostra o QPS desse frame específico. É provável que cada frame esteja bem abaixo da meta de 60 QPS.
Figura 8: passar o cursor sobre um frame
Com essa demonstração, fica bem óbvio que a página não está tendo um bom desempenho. Mas, em cenários reais, pode não ficar tão claro. Ter todas essas ferramentas para fazer medições é útil.
Bônus: abrir o medidor de QPS
Outra ferramenta útil é o medidor de QPS, que fornece estimativas em tempo real de QPS durante a execução da página.
- Pressione Command+Shift+P (Mac) ou Control+Shift+P (Windows e Linux) para abrir o Menu de comando.
- Comece a digitar
Rendering
no menu de comando e selecione Show Renderer. Na guia Renderização, ative a opção Limite de QPS. Uma nova sobreposição aparece no canto superior direito da janela de visualização.
Figura 9: o medidor de QPS
Desative o medidor de QPS e pressione Esc para fechar a guia Renderização. Você não o usará neste tutorial.
Encontre o gargalo
Agora que você mediu e verificou que a animação não está tendo um bom desempenho, a próxima pergunta a ser respondida é: por quê?
Observe a guia Resumo. Quando não há eventos selecionados, essa guia mostra os detalhes das atividades. A página passou a maior parte do tempo renderizado. Como o desempenho é a arte de fazer menos trabalho, seu objetivo é reduzir o tempo gasto no trabalho de renderização.
Figura 10: a guia "Resumo" destacada em azul
Expanda a seção Main. O DevTools mostra um Flame Chart da atividade na linha de execução principal ao longo do tempo. O eixo x representa a gravação ao longo do tempo. Cada barra representa um evento. Uma barra mais larga significa que o evento levou mais tempo. O eixo y representa a pilha de chamadas. Quando você vê eventos empilhados uns sobre os outros, isso significa que os eventos superiores causaram os inferiores.
Figura 11: seção principal destacada em azul
Há muitos dados na gravação. Aumente o zoom em um único evento Animation Frame Fired clicando, mantendo e arrastando o mouse sobre Overview, que é a seção que inclui os gráficos FPS, CPU e NET. A seção Main e a guia Summary exibem apenas informações para a parte selecionada da gravação.
Figura 12: zoom aumentado em um único evento de frame de animação disparado
Observe o triângulo vermelho no canto superior direito do evento Animation Frame Fired. Sempre que você vir um triângulo vermelho, é um aviso de que pode haver um problema relacionado ao evento.
Clique no evento Frame de animação disparado. A guia Resumo agora mostra informações sobre esse evento. Observe o link revelar. Um clique nessa opção faz com que o DevTools destaque o evento que iniciou o evento Animation Frame Fired. Observe também o link app.js:94. Clique nele para acessar a linha relevante no código-fonte.
Figura 13: mais informações sobre o evento disparado por frame de animação
No evento app.update, há vários eventos roxos. Se eles fossem mais largos, parece que cada um pode ter um triângulo vermelho nele. Clique em um dos eventos roxos de Layout agora. O DevTools fornece mais informações sobre o evento na guia Summary. De fato, há um aviso sobre reflows forçados, outra palavra para layout.
Na guia Resumo, clique no link app.js:70 em Layout forçado. O DevTools leva você à linha de código que forçou o layout.
Figura 13: a linha de código que causou o layout forçado
Ufa. Isso foi muito para absorver, mas agora você tem uma base sólida no fluxo de trabalho básico para analisar o desempenho no momento da execução. Bom trabalho!
Bônus: analise a versão otimizada
Usando os fluxos de trabalho e as ferramentas que você acabou de aprender, clique em Otimizar na demonstração para ativar o código otimizado, fazer outra gravação de desempenho e analisar os resultados. Desde a melhoria do frame rate até a redução de eventos no Flame Chart da seção Main, é possível notar que a versão otimizada do app faz muito menos trabalho, resultando em um melhor desempenho.
Próximas etapas
A base para entender o desempenho é o modelo RAIL. Esse modelo ensina as métricas de desempenho mais importantes para os usuários. Consulte Medir o desempenho com o modelo RAIL para saber mais.
Para se sentir mais confortável com o painel de desempenho, a prática leva à perfeição. Tente criar o perfil de suas próprias
páginas e analisar os resultados. Se você tiver alguma dúvida sobre seus resultados, abra uma pergunta do Stack
Overflow marcada com google-chrome-devtools
(link em inglês). Se possível, inclua capturas de tela ou links para páginas reproduzíveis.
Para se especializar em desempenho no momento da execução, você precisa aprender como o navegador converte HTML, CSS e JS em pixels na tela. O melhor lugar para começar é a Visão geral do desempenho de renderização. A anatomia de um frame traz ainda mais detalhes.
Por fim, há muitas maneiras de melhorar o desempenho do ambiente de execução. Este tutorial se concentrou em um gargalo de animação específico para apresentar um tour pelo painel "Desempenho", mas é apenas um dos muitos gargalos que você pode encontrar. O restante da série sobre o desempenho de renderização tem muitas dicas boas para melhorar vários aspectos do desempenho no momento da execução, como:
- Como otimizar a execução de JS
- Reduzir o escopo e a complexidade dos cálculos de estilo
- Evitar layouts grandes e complexos e a troca frequente de layouts
- Simplificar a complexidade da pintura e reduzir as áreas de pintura
- Usar apenas propriedades do compositor e gerenciar o número de camadas
- Rejeição de ruído nos gerenciadores de entrada