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 diferentes 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 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 uma definição do que é uma "navegação suave" e como as Core Web Vitals podem ser medidas para isso, de forma semelhante à forma como os sites implementados na arquitetura convencional de várias páginas (MPA) são medidos. 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 (que os usuários realmente não considerariam uma "navegação") ou falsos negativos (quando 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ção de navegação suave.
Como o Chrome implementa as navegações simples?
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:
- Um evento
soft-navigationPerformanceTimingserá emitido após cada navegação suave ser detectada. - A API Performance vai fornecer acesso a uma entrada de tempo
soft-navigation, emitida pelo eventosoft-navigationPerformanceTiming. - As métricas First Paint (FP), First Contentful Paint (FCP) e Largest Contentful Paint (LCP) serão redefinidas e enviadas novamente nas próximas ocorrências adequadas. Observação: FP e FCP não foram implementados.
- Um atributo
navigationIdserá adicionado a cada tempo de performance (first-paint,first-contentful-paint,largest-contentful-paint,first-input-delay,eventelayout-shift) correspondente à entrada de navegação a que o evento estava relacionado, permitindo o cálculo de Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP).
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 reenviados para navegações suaves. 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. Se você tiver dúvidas se isso vai afetar essas medições, consulte seu provedor de RUM. Consulte a seção sobre como avaliar as Core Web Vitals para navegação simples.
- O novo (e opcional) atributo
navigationIDnas entradas de performance pode precisar ser considerado no código do aplicativo que usa essas entradas. - Somente os 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 em outros navegadores, e nem todos podem ter feito upgrade para a versão mais recente desses navegadores. 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 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 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 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.
Denunciar navegação suave
Você pode usar um PerformanceObserver para observar as 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 inteira referentes à 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.
Acessar o startTime das navegações simples
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 leve, são informados como um momento a partir do momento de navegação inicial da página "difícil". Portanto, o tempo de início da navegação suave é necessário para estabelecer a base dos 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 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});
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 LCP e basear o tempo de LCP nisso. Para navegações suaves subsequentes, o texto abaixo será o elemento mais longo 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 essa solicitação for feita com antecedência com uma pré-busca? 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 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çõ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 medindo 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 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 é 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 após uma interação ou quando a página estiver em segundo plano, porque só assim o INP poderá ser finalizado. 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 leve é 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 de navegação simples do GitHub é o melhor lugar para enviar esse feedback, mas bugs individuais na implementação do Chrome precisam ser informados no Issue Tracker 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 se trata, necessariamente, de que elas serão tratadas da mesma forma que as navegações "difíceis" atuais.
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, 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 recebendo feedback sobre esse experimento nos seguintes locais:
- As heurísticas e a padronização de navegação suave.
- Problemas de implementação do Chrome com essas heurísticas.
- Feedback geral sobre os Core Web Vitals em web-vitals-feedback@googlegrouops.com.
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 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 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