Medir o carregamento inicial de uma single-page application sempre contou só uma parte da história. O usuário abre a aplicação uma vez e depois passa vários minutos trocando de rota, filtrando dados e abrindo telas sem carregar um novo documento. Justamente essas transições, que concentram boa parte da experiência, eram difíceis de separar no painel Performance.
O Chrome DevTools agora oferece suporte completo a soft navigations no fluxo de análise de performance. Depois de aparecer em Live Metrics e nas traces no Chrome 152, a identificação dessas navegações chegou também a Insights. Na prática, uma mudança de rota dentro da SPA pode ser observada como uma unidade própria, em vez de ficar perdida no meio de uma sessão longa de JavaScript.
O que é uma soft navigation
Em uma navegação tradicional, o navegador solicita outro documento HTML. Esse evento cria uma fronteira clara: há um novo ciclo de carregamento, novas métricas e uma nova entrada no histórico. Em uma SPA, o JavaScript pode mudar a URL, buscar dados e substituir a interface sem descarregar o documento atual. Para o usuário, parece uma nova página; para boa parte das APIs antigas de performance, continua sendo a mesma.
Nem toda alteração de URL, clique ou atualização do DOM deve virar uma navegação. Um filtro pode mudar a query string sem trocar de tela; um botão pode abrir um painel grande sem tocar na URL; uma rota pode mudar enquanto quase nada é pintado. O trabalho de soft navigations procura uma definição consistente combinando interação do usuário, mudança de URL e uma atualização visual relevante.
Essa distinção é importante porque evita dividir a timeline arbitrariamente. Se qualquer pushState() virasse uma página nova, as métricas poderiam premiar ou punir comportamentos que o usuário nem percebeu como navegação.
O que chegou ao painel Performance
O anúncio de outubro do DevTools, publicado em 22 de setembro, informa que o painel Performance passou a oferecer análise de ponta a ponta. Isso significa que a soft navigation identificada na trace também participa dos Insights, onde o DevTools organiza os problemas mais prováveis daquela transição.
O fluxo básico é gravar uma sessão no painel Performance, executar uma troca de rota representativa e encerrar a captura. Em vez de olhar apenas para a navegação inicial, o desenvolvedor pode selecionar a transição interna e relacionar a interação aos requests, tarefas longas, renderização e pintura que aconteceram depois dela.
Isso ajuda a responder perguntas que um Lighthouse rodado apenas no login ou na home não alcança: a tabela demora porque a API é lenta, porque o bundle da rota chegou tarde ou porque o navegador ficou ocupado montando milhares de elementos? A tela apareceu rápido, mas continuou travando quando o usuário tentou interagir? Houve mudança de layout durante a transição?
Core Web Vitals em SPAs sempre tiveram uma fronteira estranha
As Core Web Vitals nasceram associadas à navegação principal do documento. Essa escolha é simples para uma aplicação com páginas tradicionais, mas pode condensar uma sessão inteira de SPA em uma única janela. Uma rota lenta aberta dez minutos depois fica difícil de relacionar a uma experiência específica, enquanto o carregamento inicial recebe atenção desproporcional.
O trabalho recente do Chrome introduziu APIs como PerformanceSoftNavigation para criar fronteiras mensuráveis nessas transições. A documentação do web.dev ressalta que essa adoção ainda está começando em bibliotecas de métricas, soluções de RUM e ferramentas. Portanto, o que aparece no DevTools local não significa que todos os navegadores e painéis de produção já interpretem soft navigations da mesma maneira.
Como usar isso sem cair no teste bonito demais
Uma transição gravada no notebook de desenvolvimento continua sendo um experimento de laboratório. Cache quente, máquina rápida e API local podem esconder exatamente o problema que aparece para o usuário. O próprio DevTools ganhou controles de nível de desempenho de CPU, úteis para repetir testes em perfis de hardware mais modestos.
- Grave rotas que representam tarefas reais, não apenas a tela mais simples.
- Teste a primeira visita e a navegação com assets já armazenados.
- Inclua respostas rápidas, lentas, vazias e com erro.
- Observe a interação que dispara a rota e o primeiro conteúdo útil que aparece depois dela.
- Compare a trace local com dados de usuários reais quando a aplicação tiver RUM.
Também vale capturar sequências. Uma dashboard pode ser rápida na primeira troca e degradar depois de dez rotas porque listeners, caches e componentes antigos continuam presos na memória. Uma trace longa fica mais fácil de investigar quando cada transição possui uma fronteira reconhecível.
A ferramenta mede a navegação, não conserta o roteador
O suporte do DevTools não resolve botão voltar, links diretos, restauração de scroll, foco para tecnologias assistivas ou estados que desaparecem no reload. Ele também não transforma toda SPA em uma experiência rápida. O recurso melhora a visibilidade sobre o que aconteceu depois de uma interação.
Essa diferença evita uma conclusão apressada. Se o DevTools mostra uma soft navigation de 120 milissegundos, ainda é possível que a URL não represente a tela, o back button surpreenda o usuário ou o foco permaneça em um elemento removido. Performance é parte da experiência de navegação, não um substituto para ela.
Mesmo assim, a mudança fecha um ponto cego antigo. SPAs vendem a promessa de transições instantâneas; agora fica mais fácil verificar essa promessa rota por rota, inclusive quando o problema aparece depois que a página inicial já recebeu sua nota verde.