Experimento com a medição de navegações suaves

Barry Pollard

Yoav Weiss

Atualização de agosto de 2024:a segunda trilha de origem da navegação simples terminou em 29 de maio. A equipe do Chrome vai analisar o feedback do experimento e considerar as próximas etapas relacionadas a essa API. Queremos resolver alguns problemas de precisão e acreditamos que outro teste de origem será necessário antes que o recurso fique pronto para o progresso. Enquanto isso, os desenvolvedores ainda podem testar o recurso ativando chrome://flags/#enable-experimental-web-platform-features.

Desde o lançamento, a iniciativa Core Web Vitals procura medir a experiência real do usuário em um site, e não os detalhes técnicos por trás da criação ou do carregamento de um site. As três Core Web Vitals foram criadas como métricas centradas no usuário, uma evolução das métricas técnicas atuais, como DOMContentLoaded ou load, que medem tempos que muitas vezes não estão relacionados à forma como os usuários percebem o desempenho da página. Por causa disso, a tecnologia usada para criar o site não deve afetar a pontuação, porque o site tem um bom desempenho.

A realidade é sempre um pouco mais complicada do que o ideal, e a famosa arquitetura de aplicativo de página única nunca foi totalmente compatível com as métricas das Core Web Vitals. Em vez de carregar páginas da Web distintas e individuais à medida que o usuário navega pelo site, esses aplicativos da Web usam as chamadas "navegação simples", em que o conteúdo da página é alterado pelo JavaScript. Nesses aplicativos, a ilusão de uma arquitetura de página da Web convencional é mantida alterando o URL e enviando URLs anteriores no histórico do navegador para permitir que os botões voltar e avançar funcionem conforme o esperado pelo usuário.

Muitas estruturas JavaScript usam esse modelo, mas cada uma de uma maneira diferente. Como isso está fora do que o navegador entende tradicionalmente como uma "página", medir isso sempre foi difícil: onde fica a linha a ser desenhada entre uma interação na página atual em vez de considerar isso como uma nova página?

A equipe do Chrome já vem considerando esse desafio há algum tempo e quer padronizar uma definição do que é uma "navegação leve" e como as Core Web Vitals podem ser medidas em relação a isso, de forma semelhante aos sites implementados na arquitetura convencional de várias páginas (MPA, na sigla em inglês). Ainda nos estágios iniciais, a equipe agora está pronta para disponibilizar mais amplamente o que já foi implementado para que os sites possam fazer experiências. Assim, os sites vão poder enviar feedback sobre a abordagem até o momento.

O que é uma navegação suave?

Criamos a seguinte definição de navegação flexível:

• A navegação é iniciada por uma ação do usuário.
• A navegação resulta em uma mudança de URL visível para o usuário e em uma alteração do histórico.
• A navegação resulta em uma mudança do DOM.

Para alguns sites, essas heurísticas podem levar a falsos positivos (os usuários realmente não considerariam que uma "navegação" aconteceu) ou falsos negativos (quando o usuário considera que uma "navegação" ocorreu apesar de não atender a esses critérios). Agradecemos o feedback no repositório de especificações de navegação simples sobre heurística.

Como o Chrome implementa as navegações simples?

Depois que a heurística de navegação simples estiver ativada (falaremos mais sobre isso na próxima seção), o Chrome vai mudar a forma como gera relatórios de algumas métricas de desempenho:

• Um evento soft-navigation PerformanceTiming é emitido após cada navegação em segundo plano ser detectada.
• A API de desempenho fornecerá acesso a uma entrada de tempo soft-navigation, conforme emitida pelo evento soft-navigation PerformanceTiming.
• As métricas First Paint (FP), First Contentful Paint (FCP) e Largest Contentful Paint (LCP) serão redefinidas e emitidas novamente nas próximas ocorrências apropriadas. Observação: FP e FCP não estão implementados.
• Um atributo navigationId será adicionado a cada tempo de performance (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event e layout-shift) correspondente à entrada de navegação a que o evento estava relacionado. Isso vai permitir que a Cumulative Layout Shift (CLS) e a Interaction to Next Paint (INP) sejam calculadas.

Com essas mudanças, as Core Web Vitals e algumas métricas de diagnóstico associadas podem ser medidas por navegação nas páginas, embora haja algumas nuances que precisam ser consideradas.

Quais são as implicações de ativar as navegações simples no Chrome?

Veja a seguir algumas das mudanças que os proprietários de sites precisam considerar depois de ativar esse recurso:

• Eventos adicionais de FP, FCP e LCP podem ser reemitidos para navegação simples. O Chrome User Experience Report (CrUX, na sigla em inglês) ignorará esses valores adicionais, mas isso poderá afetar qualquer monitoramento de medição real do usuário (RUM, na sigla em inglês) no seu site. Entre em contato com seu provedor de RUM caso tenha dúvidas se isso afetará essas medições. Consulte a seção sobre como avaliar as Core Web Vitals para navegação simples.
• O novo atributo navigationID (e opcional) nas entradas de desempenho precisa ser considerado no código do aplicativo usando essas entradas.
• Somente os navegadores baseados no Chromium serão compatíveis com esse novo modo. Embora muitas das métricas mais recentes estejam disponíveis apenas em navegadores baseados no Chromium, algumas (FCP, LCP) estão disponíveis em outros navegadores, e nem todos podem ter feito upgrade para a versão mais recente desses navegadores. Portanto, esteja ciente de que alguns usuários podem não informar métricas de navegação flexível.
• Por ser um novo recurso experimental que não é ativado por padrão, os sites precisam testá-lo para garantir que não haja efeitos colaterais não intencionais.

Para mais informações sobre como medir as métricas de navegação simples, consulte a seção Como medir as Core Web Vitals por navegação simples.

Como faço para ativar a navegação simples no Chrome?

As navegações simples não são ativadas por padrão no Chrome, mas estão disponíveis para testes ao ativar explicitamente esse recurso.

Para desenvolvedores, isso pode ser ativado ativando a flag de recursos experimentais da plataforma da Web em chrome://flags/#enable-experimental-web-platform-features ou usando o argumento de linha de comando --enable-experimental-web-platform-features ao iniciar o Chrome.

Como posso medir as navegações suaves?

Depois que o experimento de navegação simples for ativado, as métricas vão gerar relatórios usando a API PerformanceObserver normalmente. No entanto, há algumas considerações extras que precisam ser consideradas para essas métricas.

Observação: FP e FCP ainda não são informados para navegação simples.

Denunciar navegação suave

Você pode usar um PerformanceObserver para observar as navegações suaves. Veja a seguir um exemplo de snippet de código que registra entradas de navegação simples no console, incluindo as navegações simples anteriores nesta página usando a opção buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Isso pode ser usado para finalizar as métricas de página inteira referentes à navegação anterior.

Informar as métricas em relação ao URL apropriado

Como as navegações simples só podem ser vistas depois da ocorrência, algumas métricas precisam ser finalizadas neste evento e informadas para o URL anterior, já que o URL atual agora refletirá o URL atualizado da nova página.

O atributo navigationId do PerformanceEntry apropriado pode ser usado para vincular o evento ao URL correto. Isso pode ser pesquisado com a API PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Esse pageUrl precisa ser usado para informar as métricas em relação ao URL correto, e não ao URL atual que elas possam ter usado no passado.

Acessar o startTime das navegações simples

O horário de início da navegação pode ser obtido de maneira semelhante:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

O startTime é o momento da interação inicial (por exemplo, o clique de um botão) que iniciou a navegação suave.

Todos os tempos de desempenho, incluindo aqueles para navegação suave, são informados como um momento a partir do momento inicial o tempo de navegação na página. Portanto, o tempo de início da navegação simples é necessário para definir os tempos da métrica de carregamento dessa navegação simples (por exemplo, LCP) em relação a esse tempo.

Medir as Core Web Vitals por navegação simples

Para incluir entradas de métricas de navegação simples, você precisa incluir includeSoftNavigationObservations: true na chamada observe do observador de desempenho.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

A flag includeSoftNavigationObservations extra no método observe é necessária, além de ativar o recurso de navegação simples no Chrome. Essa ativação explícita no nível do observador de desempenho serve para garantir que os observadores de desempenho atuais não sejam surpresos com essas entradas extras, já que algumas considerações adicionais precisam ser consideradas ao tentar medir as Core Web Vitals para navegação suave.

Os tempos ainda serão retornados em relação ao "difícil" original o horário de início da navegação. Portanto, para calcular a LCP de uma navegação simples, por exemplo, é necessário subtrair o tempo de início da navegação simples, conforme detalhado anteriormente, para ter uma marcação de tempo relativa à navegação simples. Por exemplo, para LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Tradicionalmente, algumas métricas são medidas ao longo da vida útil da página, como a LCP, pode mudar até que ocorra uma interação. A CLS e a INP podem ser atualizadas até que o usuário saia da página. Portanto, cada "navegação" (incluindo a navegação original) pode precisar finalizar as métricas da página anterior à medida que cada nova navegação flexível ocorre. Isso significa que a parte "difícil" inicial métricas de navegação podem ser finalizadas antes do normal.

Da mesma forma, ao começar a medir as métricas para a nova navegação flexível dessas métricas de longa duração, será necessário "redefinir" as métricas ou "reinicializado" e tratados como novas métricas, sem memória dos valores definidos para "páginas" anteriores.

Como o conteúdo que permanece o mesmo entre as navegações deve ser tratado?

FP, FCP e LCP para navegação suave vão medir apenas novas tintas. Isso pode resultar em um LCP diferente, por exemplo, de um carregamento a frio dessa navegação simples para um carregamento leve.

Por exemplo, vamos considerar uma página que inclui uma imagem de banner grande que é o elemento LCP, mas o texto abaixo dela muda a cada navegação suave. O carregamento inicial da página sinalizará a imagem do banner como o elemento da LCP e terá como base o tempo da LCP. Para as próximas navegações simples, o texto abaixo será o maior elemento pintado após a navegação simples e será o novo elemento da LCP. No entanto, se uma nova página for carregada com um link direto para o URL de navegação simples, a imagem do banner terá uma nova pintura e, portanto, estará qualificada para ser considerada como o elemento da LCP.

Como esse exemplo mostra, o elemento de LCP da navegação simples pode ser informado de maneira diferente, dependendo de como a página é carregada, da mesma forma que o carregamento de uma página com um link âncora na parte inferior da página pode resultar em um elemento LCP diferente.

Como medir o TTFB?

O Tempo até o primeiro byte (TTFB, na sigla em inglês) para um carregamento de página convencional representa o tempo em que os primeiros bytes da solicitação original são retornados.

Para uma navegação suave, essa é uma pergunta mais complicada. Devemos medir a primeira solicitação feita para a nova página? E se todo o conteúdo já existir no app e não houver solicitações adicionais? E se essa solicitação for feita com antecedência com uma pré-busca? E se uma solicitação não relacionada à navegação simples do ponto de vista do usuário (por exemplo, for de análise)?

Um método mais simples é informar TTFB de 0 para navegação simples, de forma semelhante à recomendada para restaurações de cache de avanço e retorno. Esse é o método que a biblioteca web-vitals usa para navegação simples.

No futuro, poderemos oferecer suporte a maneiras mais precisas de saber qual solicitação é a "solicitação de navegação" da navegação flexível e poderão ter medições de TTFB mais precisas. Mas isso não faz parte do experimento atual.

Como medir o antigo e o novo?

Durante esse experimento, recomendamos que você continue medindo suas Core Web Vitals da maneira atual, com base em fatores "difíceis". navegações em páginas para corresponder ao que o CrUX vai medir e informar como o conjunto de dados oficial da iniciativa Core Web Vitals.

Além dessas, também é preciso avaliar as navegações leves para que você possa conferir como elas podem ser medidas no futuro e enviar feedback à equipe do Chrome sobre como essa implementação funciona na prática. Isso ajudará você e a equipe do Chrome a moldar a API no futuro.

Para medir ambos, você precisa estar ciente dos novos eventos que podem ser emitidos no modo de navegação simples (por exemplo, vários eventos FCP e outros eventos de LCP) e processá-los adequadamente finalizando essas métricas no momento adequado, além de ignorar eventos futuros que se aplicam apenas a navegações simples.

Usar a biblioteca web-vitals para medir as Core Web Vitals em relação a navegações suaves

A maneira mais fácil de considerar todas as nuances é usar a biblioteca JavaScript web-vitals, que tem suporte experimental para navegação simples em um soft-navs branch separado (que também está disponível em npm e unpkg). Isso pode ser medido da seguinte maneira (substituindo doTraditionalProcessing e doSoftNavProcessing, conforme apropriado):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Verifique se as métricas são informadas com base no URL correto, conforme indicado anteriormente.

A biblioteca web-vitals informa as seguintes métricas para navegação simples:

Métrica	Detalhes
TTFB	Informado como 0.
First Contentful Paint (FCP)	Somente a primeira FCP da página é informada.
LCP	É o horário da próxima maior exibição de conteúdo, em relação ao horário de início da navegação suave. As tintas atuais da navegação anterior não são consideradas. Portanto, a LCP será >= 0. Como de costume, isso será informado após uma interação ou quando a página estiver em segundo plano, porque só assim a LCP poderá ser finalizada.
CLS	A maior janela de mudanças entre os tempos de navegação. Como de costume, isso é necessário quando a página está em segundo plano, porque só assim a CLS pode ser finalizada. Um valor 0 será informado se não houver mudanças.
INP	O INP entre os tempos de navegação. Como de costume, isso será informado em uma interação ou quando a página estiver em segundo plano, porque só então o INP pode ser finalizado. Um valor 0 não será informado se não houver interações.

Aviso:a implementação de web-vitals está em desenvolvimento ativo e sujeita a mudanças com a publicação de novas mudanças nessa ramificação. Ele não é compatível com a FCP em navegação simples, porque isso exige mais trabalho subjacente no Chrome. Quem usa a biblioteca JavaScript web-vitals precisa estar ciente disso se quiser usar essa biblioteca em sites de produção. É necessário fazer uma cópia local, testar essa versão e monitorar a ramificação em busca de mudanças.

Essas mudanças serão parte das medições das Core Web Vitals?

Esse experimento de navegação simples é exatamente isso: um experimento. Queremos avaliar a heurística e ver se ela reflete com mais precisão a experiência do usuário antes de decidir se ela será integrada à iniciativa Core Web Vitals. Estamos muito entusiasmados com a possibilidade desse experimento, mas não podemos oferecer garantias sobre se ou quando isso substituirá as medições atuais.

Valorizamos os desenvolvedores Web feedback sobre o experimento, a heurística usada e se você acha que ela reflete a experiência com mais precisão. O repositório de navegação simples do GitHub é o melhor lugar para enviar esse feedback. No entanto, bugs individuais na implementação do Chrome precisam ser mencionados no Issue Tracker do Chrome.

Como as navegações simples serão informadas no CrUX?

Ainda não é preciso determinar exatamente como as navegações flexíveis serão informadas no CrUX, caso o experimento seja bem-sucedido. Não se trata necessariamente de que serão tratados da mesma forma que a "difícil" atual as navegações são tratadas.

Em algumas páginas da Web, as navegações flexíveis são quase idênticas aos carregamentos de página inteira no que diz respeito ao usuário, e o uso da tecnologia de aplicativo de página única é apenas um detalhe de implementação. Em outros, podem ser mais semelhantes a uma carga parcial de conteúdo adicional.

Portanto, podemos decidir relatar essas navegações flexíveis separadamente no CrUX ou ponderá-las ao calcular as Core Web Vitals para uma determinada página ou grupo de páginas. Também podemos excluir completamente a navegação flexível de carregamento parcial, à medida que a heurística evolui.

A equipe está se concentrando na implementação heurística e técnica, o que nos permitirá julgar o sucesso desse experimento. Portanto, nenhuma decisão foi tomada sobre essas frentes.

Feedback

Estamos recebendo feedback sobre esse experimento nos seguintes locais:

• A heurística e a padronização das navegações suaves (em inglês).
• problemas de implementação do Chrome dessas heurísticas;
• Envie seu feedback sobre as Core Web Vitals em [e-mail].

Registro de alterações

Como essa API está em fase de testes, muitas mudanças estão acontecendo nela, mais do que nas APIs estáveis. Consulte o Registro de alterações da heurística de navegação flexível para saber mais detalhes.

Conclusão

O experimento de navegação simples é uma abordagem interessante para mostrar como a iniciativa das Core Web Vitals pode evoluir para medir um padrão comum na Web moderna que está faltando nas nossas métricas. Embora o experimento ainda esteja nos primeiros dias e ainda haja muito a ser feito, disponibilizar esse progresso para a comunidade mais ampla da Web é uma etapa importante. A coleta de feedback é outra parte essencial do experimento. Por isso, recomendamos que os interessados nesse desenvolvimento usem essa oportunidade para ajudar a moldar a API e garantir que ela represente o que esperamos ser capaz de medir com isso.

Agradecimentos

Imagem em miniatura de Jordan Madrid no Unsplash