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 procura medir a experiência do usuário real em vez dos 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 em relação às métricas técnicas existentes, como DOMContentLoaded ou load, que medem os tempos que geralmente não estão relacionados à maneira como os usuários percebem o desempenho da página. Por isso, a tecnologia usada para criar o site não deve afetar a pontuação se o site tiver um bom desempenho.

A realidade é sempre um pouco mais complicada do que o ideal, e a famosa arquitetura do 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 individuais e distintas à medida que o usuário navega pelo site, esses aplicativos 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 com a alteração do URL e o envio de 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 de JavaScript usam esse modelo, mas cada uma de uma maneira diferente. Como isso não faz parte do que o navegador tradicionalmente entende como uma "página", sempre foi difícil medir isso: onde seria preciso traçar uma linha entre uma interação na página atual ou uma nova página?

A equipe do Chrome está considerando esse desafio há algum tempo e quer padronizar uma definição do que é uma "navegação flexível", e como as Core Web Vitals podem ser medidas para isso, de maneira semelhante à medição de sites implementados na arquitetura convencional de várias páginas (MPA, na sigla em inglês). Ainda nas etapas iniciais, a equipe agora está pronta para disponibilizar o que já foi implementado em sites para experimentação. Isso permitirá que os sites forneçam feedback sobre a abordagem até o momento.

O que é uma navegação suave?

Chegamos à 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 visível do URL para o usuário e uma alteração no histórico.
  • A navegação resulta em uma mudança no DOM.

Para alguns sites, essas heurísticas podem levar a falsos positivos (os usuários não considerariam que uma "navegação" tenha acontecido) ou falsos negativos (quando o usuário considera que uma "navegação" ocorreu mesmo que não tenha atendido a esses critérios). Agradecemos feedback sobre heurística no repositório de especificações de navegação (link em inglês).

Como o Chrome implementa navegações suaves?

Depois que a heurística de navegação flexível for ativada (mais sobre isso 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 nas páginas, embora existam algumas nuances que precisam ser consideradas.

Quais são as implicações de permitir navegações suaves no Chrome?

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

  • Eventos adicionais FP, FCP e LCP podem ser reemitidos para navegações flexíveis. O Chrome User Experience Report (CrUX, na sigla em inglês) ignora esses valores adicionais, mas isso pode afetar os monitoramentos de medição de usuários reais (RUM, na sigla em inglês) no seu site. Consulte seu provedor de RUM se tiver alguma dúvida se isso afetará essas medições. Consulte a seção sobre como avaliar as Core Web Vitals para navegações flexíveis.
  • O novo atributo navigationID (opcional) nas entradas de desempenho pode precisar ser considerado no código do aplicativo usando essas entradas.
  • Apenas navegadores baseados no Chromium serão compatíveis com esse novo modo. Embora muitas das métricas mais recentes só estejam disponíveis 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 talvez não informem as métricas de navegação flexível.
  • Por ser um novo recurso experimental que não está ativado por padrão, os sites precisam testá-lo para garantir que não haja outros efeitos colaterais indesejados.

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

Como faço para ativar as navegações flexíveis no Chrome?

As navegações suaves não são ativadas por padrão no Chrome, mas estão disponíveis para experimentação no Chrome 110 com a ativação explícita desse recurso.

Para desenvolvedores, esse recurso pode ser ativado ativando a flag Recursos experimentais da Plataforma 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.

Para um site que quiser ativar esse recurso para que todos os visitantes vejam o impacto, há um teste de origem em execução no Chrome 117. Para ativá-lo, inscreva-se no teste e inclua um elemento meta com o token do teste de origem no cabeçalho HTML ou HTTP. Saiba mais na postagem Primeiros passos com testes de origem.

Os proprietários de sites podem incluir o teste nas páginas para todos ou apenas um subconjunto de usuários. Esteja ciente da seção de implicações anterior sobre como isso muda a forma como suas métricas podem ser informadas, especialmente se você ativar esse teste de origem para uma grande proporção de usuários. O CrUX vai continuar relatando as métricas da maneira atual, independentemente da configuração de navegação suave, portanto, ele não é afetado por essas implicações. Além disso, os testes de origem também se limitam à ativação de recursos experimentais em até 0,5% de todos os carregamentos de página do Chrome como uma mediana ao longo de 14 dias.No entanto, isso só será um problema em sites muito grandes.

Como posso medir navegações suaves?

Depois que o experimento de navegação flexível for ativado, as métricas passarão a usar a API PerformanceObserver normalmente. No entanto, há algumas considerações extras que precisam ser levadas em conta para essas métricas.

Informar navegações flexíveis

Você pode usar um PerformanceObserver para observar navegações suaves. Confira a seguir um snippet de código de exemplo que registra entradas de navegação flexível no console, incluindo navegações flexíveis 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 métricas da página de vida completa para a navegação anterior.

Relatar as métricas de acordo com o URL apropriado

Como as navegações flexíveis só podem ser vistas depois que ocorrerem, algumas métricas precisarão ser finalizadas nesse evento e informadas para o URL anterior, pois 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 gerar relatórios sobre as métricas com o URL correto, em vez do URL atual que foi usado anteriormente.

Como acessar o startTime de navegações suaves

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, um clique de botão) que iniciou a navegação suave.

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

Medir as Core Web Vitals por navegação suave

Para incluir entradas de métrica de navegação flexível, é 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 sinalização includeSoftNavigationObservations extra no método observe é necessária, além de ativar o recurso de navegação flexível no Chrome. Essa ativação explícita no nível do observador de desempenho é para garantir que os observadores de desempenho atuais não se surpreendam com essas entradas extras, já que algumas considerações extras precisam ser consideradas ao tentar medir as Core Web Vitals para navegações flexíveis.

Os horários ainda serão retornados em relação ao horário de início da navegação "discreto" original. Portanto, para calcular a LCP de uma navegação flexível, por exemplo, será necessário subtrair o tempo da LCP e o horário de início adequado, conforme detalhado anteriormente, para ter um tempo em relação à navegação flexível. 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 tradicionalmente ao longo da vida útil da página: a LCP, por exemplo, pode mudar até que ocorra uma interação. As informações de CLS e INP podem ser atualizadas até que o usuário saia da página. Portanto, cada "navegação" (incluindo a navegação original) talvez precise finalizar as métricas da página anterior à medida que ocorre cada nova navegação flexível. Isso significa que as métricas iniciais de navegação difíceis 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 precisarão ser "redefinidas" ou "reinicializadas" e tratadas como novas, sem memória dos valores definidos para "páginas" anteriores.

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

FP, FCP e LCP para navegações suaves medirão apenas novas pinturas. Isso pode resultar em uma LCP diferente, por exemplo, de um carregamento a frio dessa navegação suave para um carregamento leve.

Por exemplo, considere uma página que inclua uma imagem grande de banner que é o elemento da LCP, mas o texto abaixo dela muda a cada navegação flexível. O carregamento inicial da página sinalizará a imagem do banner como o elemento da LCP e baseará o tempo da LCP nisso. Nas navegações suaves subsequentes, o texto abaixo será o maior elemento pintado após a navegação flexível e o novo elemento da LCP. No entanto, se uma nova página for carregada com um link direto no URL de navegação flexível, 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 da LCP para a navegação flexível pode ser informado de maneiras diferentes, dependendo de como a página é carregada. Da mesma forma, o carregamento de uma página com um link fixo mais abaixo na página pode resultar em um elemento LCP diferente.

Como medir o TTFB?

O tempo para primeiro byte (TTFB, na sigla em inglês) 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 essa solicitação for feita com antecedência com uma pré-busca? E se uma solicitação não relacionada à navegação flexível do ponto de vista do usuário (por exemplo, for uma solicitação de análise)?

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

No futuro, poderemos oferecer suporte a formas mais precisas de saber qual solicitação é a "solicitação de navegação" da navegação flexível e poderemos 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 navegações difíceis nas páginas para corresponder ao que o CrUX vai medir e relatar como o conjunto de dados oficial da iniciativa Core Web Vitals.

Além disso, as navegações discretas devem ser avaliadas para permitir que você veja como elas podem ser medidas no futuro e para dar a você a oportunidade de fornecer 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 daqui para frente.

Para medir ambos, você precisa conhecer os novos eventos que podem ser emitidos no modo de navegação suave (por exemplo, vários eventos FCP e LCP adicionais) e lidar adequadamente com a finalização dessas métricas no momento adequado, enquanto também ignora eventos futuros que se aplicam somente a navegações suaves.

Use a biblioteca web-vitals para medir as Core Web Vitals para navegação suave

A maneira mais fácil de considerar todas as nuances é usar a biblioteca JavaScript web-vitals, que tem suporte experimental para navegações flexíveis 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 para o URL correto, conforme observado anteriormente.

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

Métrica Detalhes
TTFB Informado como 0.
First Contentful Paint (FCP) No momento, apenas a primeira FCP da página é informada pela biblioteca web-vitals.
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 pinturas atuais da navegação anterior não são consideradas. Portanto, a LCP será >= 0. Como de costume, isso será relatado após uma interação ou quando a página estiver em segundo plano, pois só então a LCP pode ser finalizada.
CLS A maior janela de mudanças entre os tempos de navegação. Como de costume, isso quando a página está em segundo plano, porque só então 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á relatado após uma interação ou quando a página estiver em segundo plano, pois só então o INP pode ser finalizado. O valor 0 não é informado quando não há interações.

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

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

Valorizamos o feedback dos desenvolvedores da Web sobre o experimento, a heurística usada e se você acha que ele reflete a experiência com mais precisão. O repositório de navegação simples do GitHub (link em inglês) é o melhor lugar para enviar esse feedback. No entanto, bugs individuais com a implementação do Chrome precisam ser informados no Issue Tracker do Chrome.

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

A forma exata de como as navegações suaves serão relatadas no CrUX, caso esse experimento seja bem-sucedido, também ainda vai ser determinada. Não significa necessariamente que elas serão tratadas da mesma forma que as navegações "mais difíceis" atuais.

Em algumas páginas da Web, a navegação leve é quase idêntica 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, eles podem ser mais semelhantes a um carregamento parcial de conteúdo adicional.

Portanto, podemos informar essas navegações leves 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 totalmente a navegação flexível de carregamento parcial à medida que a heurística evolui.

No momento, 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 em relação a essas frentes.

Feedback

Queremos receber feedback sobre esse experimento nos seguintes locais:

Registro de alterações

Como essa API está em fase de testes, várias mudanças estão acontecendo com ela, mais do que nas APIs estáveis. Consulte o registro de alterações da heurística de navegação flexível (em inglês) para mais detalhes.

Conclusão

O experimento de navegação suave é uma abordagem interessante na forma 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 ainda há muito a ser feito, disponibilizar o progresso até o momento para a comunidade da Web como um todo é uma etapa importante. A coleta do feedback desse experimento é outra parte crucial do experimento. Por isso, recomendamos que os interessados nesse desenvolvimento usem essa oportunidade para ajudar a moldar a API e garantir que ela seja representativa do que esperamos conseguir medir com isso.

Agradecimentos

Imagem em miniatura de Jordan Madrid no Unsplash