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

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

Desde o lançamento, a iniciativa Core Web Vitals busca medir a experiência real do usuário em um site, em vez de detalhes técnicos sobre como ele é criado ou carregado. As três métricas principais da Web 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 geralmente não estão relacionados à percepção dos usuários sobre o desempenho da página. Por isso, a tecnologia usada para criar o site não deve afetar a pontuação, desde que o site tenha um bom desempenho.

A realidade é sempre um pouco mais complicada do que o ideal, e a arquitetura de aplicativo de página única nunca teve suporte total das métricas 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ções suaves", em que o conteúdo da página é alterado por JavaScript. Nesses aplicativos, a ilusão de uma arquitetura convencional de página da Web é mantida alterando o URL e enviando URLs anteriores no histórico do navegador para permitir que os botões "Voltar" e "Avançar" funcionem como o usuário espera.

Muitos frameworks JavaScript usam esse modelo, mas cada um 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 está a linha a ser traçada entre uma interação na página atual e considerá-la como uma página nova?

A equipe do Chrome está considerando esse desafio há algum tempo e quer padronizar a definição de "navegação suave" e como as Core Web Vitals podem ser medidas para isso, de forma semelhante à medição de sites implementados na arquitetura convencional de várias páginas (MPA, na sigla em inglês). Ainda que ainda esteja nos estágios iniciais, a equipe já está pronta para disponibilizar o que já foi implementado para que os sites possam testar. Isso permitirá que os sites enviem feedback sobre a abordagem até agora.

O que é uma navegação suave?

Criamos a seguinte definição de navegação suave:

  • 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 uma mudança no histórico.
  • A navegação resulta em uma mudança no DOM.

Para alguns sites, essas heurísticas podem levar a falsos positivos (em que os usuários não consideram que uma "navegação" tenha ocorrido) ou falsos negativos (em que o usuário considera que uma "navegação" ocorreu, apesar de não atender a esses critérios). Envie seu feedback sobre as heurísticas no repositório de especificações de navegação suave.

Como o Chrome implementa navegações suaves?

Depois que as heurísticas de navegação suave forem ativadas (mais informações na próxima seção), o Chrome vai mudar a forma como informa algumas métricas de desempenho:

Essas mudanças vão permitir que as Core Web Vitals e algumas das métricas de diagnóstico associadas sejam medidas por navegação de página, mas há algumas nuances que precisam ser consideradas.

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

Confira algumas das mudanças que os proprietários de sites precisam considerar após ativar esse recurso:

  • Outros eventos de FP, FCP e LCP podem ser reemitidos para navegações suaves. O Chrome User Experience Report (CrUX) vai ignorar esses valores adicionais, mas isso pode afetar qualquer monitoramento de medição de usuários reais (RUM) no seu site. Se você tiver dúvidas se isso vai afetar essas medições, consulte seu provedor de RUM. Consulte a seção sobre como medir as Core Web Vitals para navegações suaves.
  • O novo (e opcional) atributo navigationID nas entradas de performance pode precisar ser considerado no código do aplicativo que usa essas entradas.
  • Somente navegadores baseados no Chromium vão oferecer suporte a 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 nos outros navegadores, e nem todos podem ter feito upgrade para a versão mais recente dos navegadores baseados no Chromium. Portanto, alguns usuários podem não informar as métricas de navegação suave.
  • Como um novo recurso experimental que não é ativado por padrão, os sites precisam testar esse recurso para garantir que não haja outros efeitos colaterais não intencionais.

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

Como faço para ativar as navegações suaves no Chrome?

A navegação suave não é ativada por padrão no Chrome, mas está disponível para experimentação se você ativar esse recurso explicitamente.

Para desenvolvedores, isso pode ser ativado ativando a flag Experimental Web Platform features 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 suave for ativado, as métricas vão ser informadas usando a API PerformanceObserver normalmente. No entanto, há algumas considerações extras que precisam ser levadas em consideração para essas métricas.

Informar navegações suaves

Você pode usar um PerformanceObserver para observar navegações suaves. Confira abaixo um exemplo de snippet de código que registra entradas de navegação suave no console, incluindo as navegações suaves 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 de ciclo de vida completo da navegação anterior.

Gerar relatórios sobre as métricas com o URL apropriado

Como as navegações suaves só podem ser vistas depois de ocorrerem, algumas métricas precisam ser finalizadas após esse evento e informadas para o URL anterior, já que o URL atual vai 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 deve ser usado para informar as métricas com o URL correto, em vez do URL atual que o usuário pode ter usado no passado.

Como acessar o startTime das navegações suaves

O horário de início da navegação pode ser encontrado 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 tempo da interação inicial (por exemplo, um clique no botão) que iniciou a navegação suave.

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

Medir as Core Web Vitals por navegação suave

Para incluir entradas de métricas de navegação suave, é necessário 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 para ativar o recurso de navegação suave no Chrome. Essa ativação explícita no nível do observador de desempenho serve para garantir que os observadores de desempenho existentes não sejam surpreendidos com essas entradas extras, já que algumas considerações adicionais precisam ser levadas em conta ao tentar medir as Core Web Vitals para navegações suaves.

Os tempos ainda serão retornados de acordo com o horário de início da navegação "fixo" original. Portanto, para calcular o LCP de uma navegação suave, por exemplo, você precisa pegar o tempo do LCP e subtrair o tempo de início da navegação suave apropriado, conforme detalhamos anteriormente, para obter um tempo relativo à navegação suave. 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});

Algumas métricas são medidas ao longo da vida da página: o LCP, por exemplo, pode mudar até que uma interação ocorra. A CLS e a INP podem ser atualizadas até que a página seja deixada. 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 suave ocorre. Isso significa que as métricas de navegação "fixas" iniciais 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, elas precisam ser "redefinidas" ou "reinicializadas" e tratadas como novas métricas, sem a memória dos valores definidos para as "páginas" anteriores.

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

As métricas FP, FCP e LCP para navegações suaves vão medir apenas as novas pinturas. Isso pode resultar em um LCP diferente, por exemplo, de um carregamento frio dessa navegação flexível para um carregamento flexível.

Por exemplo, considere 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 vai sinalizar a imagem do banner como o elemento da LCP e basear o tempo da LCP nisso. Para navegações suaves subsequentes, o texto abaixo será o elemento mais amplo pintado após a navegação suave e será o novo elemento da LCP. No entanto, se uma nova página for carregada com um link direto no URL da navegação suave, a imagem do banner será uma nova pintura e, portanto, poderá ser considerada como o elemento LCP.

Como mostra este exemplo, o elemento LCP para a navegação suave pode ser informado de maneira diferente, dependendo de como a página é carregada. Da mesma forma, carregar uma página com um link de âncora mais abaixo pode resultar em um elemento LCP diferente.

Como medir o TTFB?

O tempo até o primeiro byte (TTFB) de 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 outras solicitações? E se a solicitação for feita com antecedência usando um pré-carregamento? E se uma solicitação não estiver relacionada à navegação suave da perspectiva do usuário (por exemplo, se for uma solicitação de análise)?

Um método mais simples é informar um TTFB de 0 para navegações suaves, da mesma forma que recomendamos para restaurações de cache de avanço e retorno. Esse é o método que a biblioteca web-vitals usa para navegações suaves.

No futuro, poderemos oferecer suporte a maneiras mais precisas de saber qual solicitação é a "solicitação de navegação" da navegação suave e 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 a medir as Core Web Vitals da maneira atual, com base em navegações de página "difícil", para corresponder ao que o CrUX vai medir e informar como o conjunto de dados oficial da iniciativa das Core Web Vitals.

As navegações suaves precisam ser medidas além dessas para que você possa entender como elas podem ser medidas no futuro e para que você tenha a oportunidade de enviar feedback à equipe do Chrome sobre como essa implementação funciona na prática. Isso vai ajudar você e a equipe do Chrome a moldar a API no futuro.

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

Use a biblioteca web-vitals para medir as Core Web Vitals para 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 suave em um soft-navs branch separado (também disponível no npm e no 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 o URL correto conforme observado anteriormente.

A biblioteca web-vitals informa as seguintes métricas para navegações suaves:

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

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

Esse experimento de navegação suave é exatamente isso: um experimento. Queremos avaliar as heurísticas e verificar se elas refletem com mais precisão a experiência do usuário antes de tomar qualquer decisão sobre a integração delas à iniciativa das Principais métricas da Web. Estamos muito animados com a possibilidade desse experimento, mas não podemos garantir se ou quando ele vai substituir as medições atuais.

Valorizamos o feedback dos desenvolvedores da Web sobre o experimento, as heurísticas usadas e se você acha que ele reflete melhor a experiência. O repositório do GitHub sobre navegação suave é o melhor lugar para enviar esse feedback, mas bugs individuais com a implementação do Chrome devem ser informados no rastreador de problemas do Chrome.

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

Ainda não foi determinado como as navegações suaves serão relatadas no CrUX, caso o experimento seja bem-sucedido. Não é necessariamente certo que elas serão tratadas da mesma forma que as navegações "fixas" atuais.

Em algumas páginas da Web, as navegações suaves são quase idênticas aos carregamentos de página completa para o usuário, e o uso da tecnologia de aplicativo de página única é apenas um detalhe de implementação. Em outros, pode ser mais parecido com uma carga parcial de conteúdo adicional.

Portanto, podemos decidir informar essas navegações suaves separadamente no CrUX ou talvez 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 suave de carga parcial, à medida que a heurística evolui.

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

Feedback

Estamos buscando feedback sobre esse experimento nos seguintes lugares:

Registro de alterações

Como essa API está em fase de experimentação, várias mudanças estão acontecendo nela, mais do que nas APIs estáveis. Confira o registro de mudanças das heurísticas de navegação suave para mais detalhes.

Conclusão

O experimento de navegação suave é uma abordagem interessante de 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 esse experimento ainda esteja no início e tenha muito a ser feito, é importante disponibilizar o progresso até agora para que a comunidade da Web possa testar. A coleta de feedback é outra parte crucial do experimento. Por isso, recomendamos que as pessoas interessadas nesse desenvolvimento aproveitem a oportunidade para ajudar a moldar a API e garantir que ela seja representativa do que esperamos medir.

Agradecimentos

Imagem em miniatura de Jordan Madrid no Unsplash