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.
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 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 nos estágios iniciais, a equipe agora está pronta para disponibilizar mais amplamente o que já foi implementado para que os sites possam fazer experimentos. 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 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). Agradecemos o feedback no repositório de especificações de navegação simples sobre heurística.
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:
- Um evento
soft-navigation
PerformanceTiming
será emitido após cada navegação suave ser detectada. - A API de desempenho fornecerá acesso a uma entrada de tempo
soft-navigation
, conforme emitida pelo eventosoft-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 foram implementados.
- Um atributo
navigationId
será adicionado a cada um dos tempos de execução (first-paint
,first-contentful-paint
,largest-contentful-paint
,first-input-delay
,event
elayout-shift
) correspondentes à entrada de navegação relacionada ao evento, permitindo que o Shift de layout cumulativo (CLS) e a Interação para a próxima pintura (INP) sejam calculados.
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?
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
navigationID
nas 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 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?
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 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.
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.
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 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 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});
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 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?
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 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 esse exemplo mostra, o elemento de LCP da navegação simples pode ser informado de forma diferente, dependendo de como a página é carregada, da mesma forma que o carregamento de uma página com um link âncora mais abaixo na 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 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 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 simples 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, é recomendável continuar avaliando suas Core Web Vitals da maneira atual, com base em navegações "difíceis" na página para corresponder ao que o CrUX medir e informar como o conjunto de dados oficial da iniciativa 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 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çõ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 a LCP poderá ser finalizada. |
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 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 leve é 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 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, embora bugs individuais com a implementação do Chrome devam ser informados no rastreador de problemas do Chrome.
Como as navegações suaves 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 é 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 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 informar 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 buscando feedback sobre esse experimento nos seguintes lugares:
- 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. 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 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 os interessados nesse desenvolvimento aproveitem essa oportunidade para ajudar a moldar a API e garantir que ela represente o que esperamos ser capaz de medir com ela.
Agradecimentos
Imagem em miniatura de Jordan Madrid no Unsplash