Publicado em 4 de abril de 2025
Corrigir problemas de desempenho no mundo real significa preencher a lacuna entre o ambiente de desenvolvimento e as diversas experiências de desempenho dos usuários. Nesta postagem, vamos analisar os novos recursos do Chrome DevTools que ajudam você a basear mais suas decisões de depuração de desempenho em dados reais, em vez de suposições.
Como calibrar as expectativas
A partir do Chrome 134, o DevTools inclui a calibração de limitação de CPU, uma nova ferramenta para eliminar a incerteza de escolher o nível certo de limitação de CPU. Execute a calibração uma vez, e as ferramentas de desenvolvimento vão gerar predefinições de limitação de "dispositivos móveis de baixo custo" e "dispositivos móveis de custo médio" específicas para sua máquina de desenvolvimento.
Uma incompatibilidade comum no trabalho de desempenho da Web é que, como desenvolvedores, geralmente criamos sites em dispositivos de computador rápidos, enquanto muitos dos nossos usuários estão em dispositivos móveis mais modestos. Rastrear um problema de desempenho pode ser complicado quando ele só acontece em um dispositivo com uma CPU muito mais lenta.
O padrão ouro é a depuração remota em um dispositivo móvel real, mas, há quase uma década, o Chrome também oferece suporte a limitação de CPU para ciclos de iteração rápidos e leves durante o desenvolvimento.
Mas qual nível de limitação de CPU você deve escolher? 4x? 20x? Como saber qual corresponde melhor ao tipo de dispositivo que você sabe que visita seu site? E como a velocidade da sua máquina muda essa decisão, seja em uma estação de trabalho de última geração ou em um Chromebook de 8 anos em trânsito?
O processo de calibragem do limite
Quando o painel "Performance" é aberto, as configurações do ambiente têm um menu suspenso para definir o nível de limitação da CPU. Se você não tiver executado a calibração antes, duas opções desativadas vão aparecer em "Predefinições calibradas" no menu suspenso e uma opção Calibrar… na parte de baixo.
Ao selecionar essa opção, você vai acessar as predefinições de limitação da CPU nas Configurações. Também é possível acessar essa página diretamente.
- Clique no botão Calibrar.
- Clique em Continuar quando o aviso de que a página atual será fechada por um breve período aparecer.
- Uma comparação rápida será executada para medir a velocidade da máquina atual, e a calibração será concluída.
As opções de limitação agora serão preenchidas com as predefinições calibradas para dispositivos de nível baixo e médio.
Essas duas predefinições devem ser suficientes para a maioria dos casos de uso de desenvolvimento. Em geral, recomendamos a predefinição "nível intermediário" como correspondente a um dispositivo móvel "típico" encontrado na Web. Se você sabe que muitos dos seus usuários têm dispositivos ainda mais lentos ou que um problema de desempenho ocorre apenas com esses usuários, a opção de "nível baixo" precisa ser lenta o suficiente para capturar até mesmo a cauda longa de dispositivos mais simples.
Por fim, se você achar que algo deu errado na calibração ou que sua máquina local mudou de alguma forma, é possível recalibrar usando o menu suspenso de limitação ou nas configurações. Isso vai executar novamente o comparativo de mercado e atualizar as predefinições.
Como o estrangulamento da CPU funciona nas Ferramentas do desenvolvedor
Se você já teve curiosidade sobre como a limitação de CPU funciona no DevTools, a ideia é relativamente simples. Quando você ativa o throttling em uma guia, o Chrome inicia uma linha de execução de throttling separada que interrompe e suspende a linha de execução principal da guia para bursts curtos frequentes. O objetivo é suspender a linha de execução principal por tempo suficiente para que a duração de qualquer tarefa aumente pelo fator de limitação.
Por exemplo, com a redução de 4x da CPU, a linha de execução principal será suspensa aproximadamente 75% do tempo, o que faz com que qualquer trabalho da linha de execução principal demore quatro vezes mais para ser concluído.
A vantagem dessa abordagem é que ela é quase transparente para o restante do Chrome. Não é necessário usar um código especializado para desacelerar o JavaScript, o layout ou qualquer um dos muitos outros tipos de trabalho que um navegador precisa fazer. Todo o trabalho na linha de execução principal leva mais tempo porque a própria linha de execução só pode ser executada por uma fração do tempo.
Quando o estrangulamento da CPU age como um dispositivo móvel real
Como resultado, muitos tipos de trabalho de CPU de dispositivos móveis são bem simulados pelo estrangulamento da CPU. Se uma interação acionar o JavaScript e o layout, por exemplo, há uma boa chance de que ela seja executada de maneira muito semelhante à execução em um dispositivo móvel.
Considere uma tarefa acionada pelo clique em um botão, executando o JavaScript para adicionar novos elementos ao DOM, o que exige que o navegador execute cálculos de estilo e layout para posicionar o novo conteúdo:
Com a configuração predefinida de limitação de CPU "dispositivo móvel de nível intermediário" calibrada (3,7x nessa máquina de desenvolvimento), a interação parece muito semelhante, mas a duração aumenta significativamente, tornando-se uma tarefa longa:
Testar a mesma interação em um dispositivo real de nível intermediário usando a depuração remota gera um resultado notavelmente semelhante, tanto na forma quanto na duração do rastro da interação. Como essa tarefa é principalmente vinculada à CPU na linha de execução principal (executando o código JavaScript da página e o código de estilo e layout do Chrome), o throttling calibrado recria com precisão o desempenho real do dispositivo móvel:
Quando você ainda quiser testar em um dispositivo móvel real
Embora seja muito útil, o estrangulamento da CPU não pode simular todos os aspectos do hardware de dispositivos móveis. Em um smartphone, a velocidade do disco é mais lenta, a largura de banda da memória é mais limitada e o throttling térmico pode ser ativado a qualquer momento para reduzir a velocidade de execução.
Uma limitação comum de limitação envolve trabalho intensivo de GPU. As GPUs para dispositivos móveis e computadores são diferentes em termos de arquitetura, e o Chrome executa operações de GPU em um processo separado da linha de execução principal da página. Como resultado, o estrangulamento da CPU do DevTools não afeta o processo da GPU, o que é melhor, já que isso afetaria a capacidade de resposta do DevTools e do restante do navegador.
Pinturas, composições e estilos com muitos efeitos são problemas de desempenho comuns que podem parecer bons em uma máquina de desenvolvimento, mas são inesperados e lentos em dispositivos móveis. E pode ser difícil perceber que há um problema ao tentar recriar o problema na máquina de desenvolvimento.
Considere a mesma interação de antes (clicar e adicionar muitos elementos ao DOM), só que desta vez os novos elementos têm um estilo com um número excessivo de sombras de caixa pesadas para GPU e filtros de desfoque.
A forma inicial e a duração da interação parecem semelhantes, mas há uma nova pintura de linha principal longa no final para os efeitos adicionados:
Em um smartphone real de nível intermediário, a parte da linha de execução principal da interação parece muito semelhante à simulada, incluindo a pintura extra, mas um processo de GPU selvagem parece fazer uma quantidade enorme de trabalho antes que o resultado da interação apareça na tela:
O trabalho da GPU aumenta a interação em mais 300 milissegundos e é um trabalho que quase não existe para a GPU do laptop, mesmo com o estrangulamento da CPU (linha de execução principal) ativado.
Há outros casos que também têm desvantagens significativas de emulação, como carregamentos de página de dependência profunda, em que há uma interação entre limitação de rede simulada, comunicações entre processos e acesso a caches de disco e memória.
Sempre teste em dispositivos móveis reais. Se não for possível recriar um problema no laboratório no computador que os dados de campo mostram que está afetando os usuários de dispositivos móveis, tente a depuração remota com um dispositivo real para saber se há uma diferença que você não está vendo.
Mais melhorias na depuração baseada em dados
Recentemente, lançamos outros recursos para facilitar a tomada de decisões e a configuração de depuração com base nos usuários reais.
Se você tiver dados de campo ativados, o painel Performance vai dar sugestões sobre o limite de taxa com base na 75ª percentil de usuários, conforme medido pelo Relatório de experiência do usuário do Chrome (CrUX). A visualização de métricas em tempo real vai alertar você se as métricas medidas localmente divergirem dos dados de campo. Isso foi abordado em detalhes em uma postagem anterior sobre como trazer dados reais das Core Web Vitals para o DevTools.
Uma nova adição é que os insights do painel de desempenho na barra lateral agora também vão alertar você se as métricas medidas em um rastreamento não corresponderem ao que os usuários estão enfrentando no mundo real.
Ativar os dados de campo também vai permitir o uso das Core Web Vitals de 75º percentil para ajudar a classificar a ordem em que os insights são mostrados na barra lateral. Se, por exemplo, os usuários normalmente têm uma maior exibição de conteúdo (LCP), mas uma Interaction to Next Paint (INP) ruim, os insights que ajudam a melhorar a INP tendem a ficar no topo da lista.
Por fim, se você já mudou várias vezes entre vários rastros ou carregou rastros do disco, pode ser difícil lembrar exatamente quais configurações de emulação e limitação de dispositivos móveis você usou em cada rastro. A seleção de traços na parte de cima do painel Performance agora mostra informações de emulação para cada traço.
Parar, calibrar e ouvir
Precisamos basear nossas decisões de depuração no mundo real: começando com dados de campo de análises e relatórios de usuários para encontrar problemas e, em seguida, recriar essas experiências de usuário no laboratório para diagnóstico. Essas novas adições do DevTools ajudam a facilitar esse processo.
A calibração e os alertas de limitação de CPU em experiências divergentes de campo e laboratório ajudam a reduzir a incerteza sobre se você está ou não no caminho certo e permitem uma aproximação mais consistente da performance real. Ao eliminar as suposições da configuração e destacar possíveis discrepâncias, o DevTools tem como objetivo ajudar você a se concentrar em corrigir os problemas de desempenho reais que afetam seus usuários.
Tem ideias de melhorias ou sugestões de novos recursos? Conte para nós.