Core/Dash Dimension: Navigation Type

Dimensão: Navigation Type (nt)

Cada visualização de página nos seus dados do CrUX traz um tipo de navegação. Ele diz como o navegador carregou a página, o que determina quais sistemas do navegador foram envolvidos: a pilha de rede, o back/forward cache, o pipeline de prerender ou uma restauração de sessão. O CoreDash expõe isso como a dimensão nt para que você possa filtrar e comparar os Core Web Vitals em cada contexto de navegação separadamente.

Os dados vêm da API PerformanceNavigationTiming, especificamente da propriedade type. Você a lê com performance.getEntriesByType("navigation")[0].type. O Chrome relata esse valor junto com cada medição de web vitals enviada ao CrUX, e o CoreDash o armazena e indexa para que você possa segmentar sem escrever nenhuma instrumentação personalizada.

Por que o Navigation Type importa

Agregar o LCP ou o INP de todos os tipos de navegação produz um número tecnicamente correto, mas enganoso na prática. Um hit do back/forward cache é concluído em milissegundos. Uma navegação fria espera por DNS, TCP, TLS e TTFB. Se 20% das suas sessões forem hits de bfcache, eles puxam o seu LCP de p75 para baixo e tornam um problema real em novas navegações mais difícil de ver.

O inverso também é verdadeiro. Se o bfcache estiver quebrado no seu site, as sessões de back/forward terão uma performance tão ruim quanto a de novas navegações. Sem segmentar por tipo de navegação, você nunca notará, porque o agregado permanece estável.

O prerender é o caso mais dramático. Uma página pré-renderizada corretamente deve mostrar um LCP próximo de zero, porque a renderização terminou antes mesmo de o usuário clicar no link. Se suas páginas pré-renderizadas mostram números normais de LCP, a configuração de Speculation Rules está errada e o prerender não está sendo acionado ou está sendo descartado antes do uso.

Os tipos de navegação

navigate

Uma navegação padrão: o usuário digitou uma URL, clicou em um link de outro site ou seguiu um redirecionamento. Este é um carregamento de página completo, sem atalhos de cache. O navegador passa por todo o pipeline de requisição, incluindo resolução de DNS, estabelecimento de conexão e carregamento completo de recursos. Nos dados do CoreDash, o navigate responde por cerca de 65% das sessões. Ele é a sua linha de base. Todos os outros tipos de navegação devem ser avaliados com base em como se comparam ao navigate.

reload

O usuário pressionou F5, clicou no botão de recarregar do navegador ou seu código chamou location.reload(). O navegador envia requisições de revalidação para recursos em cache, o que significa que o TTFB costuma parecer pior do que em um navigate, apesar de o usuário estar na mesma página. Se o TTFB de reload for drasticamente maior do que o de navigate, seus cabeçalhos de cache estão acionando a revalidação a cada reload em vez de servir conteúdo obsoleto. Aproximadamente 10% das sessões são reloads no tráfego típico do CoreDash.

back_forward

O usuário pressionou o botão de voltar ou avançar do navegador. Se o back/forward cache (bfcache) estiver funcionando, este é o tipo de navegação mais rápido possível. O navegador restaura a página a partir da memória, sem nenhuma requisição de rede. O LCP para um hit de bfcache é efetivamente o tempo de paint a partir da memória, o que é quase instantâneo.

Se suas métricas de back_forward forem semelhantes às de navigate, o bfcache não está funcionando. As causas mais comuns são manipuladores de eventos unload, cabeçalhos de resposta Cache-Control: no-store e conexões IndexedDB abertas que não foram fechadas antes da navegação. Os dados do CoreDash colocam o back/forward em cerca de 20% das sessões, tornando esta uma correção de alto impacto.

prerender

A página foi carregada em segundo plano usando a Speculation Rules API antes de o usuário clicar no link. Quando o usuário clica, o documento pré-renderizado é ativado instantaneamente. O LCP para um prerender ativado corretamente é próximo de zero porque todo o trabalho de renderização terminou antes do evento de navegação.

Se o seu LCP de prerender parecer normal, uma de três coisas aconteceu: o prerender foi descartado antes da ativação, a regra de especulação apontou para as URLs erradas ou a página usa cabeçalhos ou JavaScript que impedem o prerender. Aproximadamente 3% das sessões do CoreDash são ativações de prerender, mas essa fatia aumenta rapidamente assim que as Speculation Rules são implantadas.

restore

A aba foi restaurada após o navegador ser fechado ou a aba travar. O navegador recarrega a página do zero, mas a sessão é considerada um restore em vez de um novo navigate. A performance é semelhante à de um navigate frio. Isso responde por cerca de 2% das sessões e raramente é o foco do trabalho de otimização, mas vale a pena monitorar se você tiver usuários com sessões de navegador instáveis.

Fluxo de depuração

1. Compare o LCP de navigate com a sua meta geral de LCP. Esta é a sua referência real para a performance de novos carregamentos. Se o navigate já estiver passando, seu problema está em outro lugar.
2. Compare o back_forward com o navigate. Se eles estiverem próximos, o bfcache está quebrado. Abra o Chrome DevTools, vá para o painel Application e execute o teste de bfcache. A saída do DevTools listará exatamente quais recursos ou cabeçalhos estão bloqueando a elegibilidade do bfcache.
3. Verifique o LCP de prerender. Se estiver acima de 200 ms, o pipeline de prerender não está funcionando. Verifique se o JSON de Speculation Rules é válido, certifique-se de que as páginas de destino não retornam lógica de bloqueio e confirme se as ativações estão sendo contabilizadas no Chrome DevTools sob Speculation Rules.

Regra geral de engenharia

• navigate: Deve atingir o seu limite de LCP por meio de otimização normal: TTFB rápido, fetchpriority="high" na imagem do LCP, sem recursos render blocking.
• back_forward: Deve ser de 10 a 20 vezes mais rápido que o navigate. Se não for, o bfcache está quebrado.
• prerender: Deve mostrar LCP abaixo de 200 ms. Se não, suas Speculation Rules estão desconfiguradas.
• reload: O TTFB não deve ser drasticamente pior que o navigate. Se for, corrija seus cabeçalhos de revalidação de cache.

O Navigation Type é a dimensão que separa "qual é a performance da minha página?" de "qual é a performance da minha página sob cada estratégia de carregamento do navegador?" Essa distinção é a diferença entre adivinhar e depurar.