Respostas para perguntas comuns sobre SPAs, Core Web Vitals e o plano do Google de resolver as limitações atuais de medição.
Desde o lançamento da iniciativa Principais métricas da Web, em maio de 2020, a equipe do Chrome recebeu muitas perguntas e feedback sobre o programa.
Talvez o tópico sobre o qual recebemos mais perguntas, e que provavelmente é a pergunta mais difícil de responder, seja como medir as Core Web Vitals em um aplicativo de página única (SPA, na sigla em inglês) e como as arquiteturas de SPA afetam as notas das Core Web Vitals.
Essas perguntas são difíceis de responder porque o problema é bastante complexo. Por isso, nesta postagem, vamos fazer o possível para responder às perguntas mais comuns, fornecendo o máximo de detalhes e contexto possível.
Antes de entrar em detalhes, é importante declarar que o Google não tem preferência por nenhuma arquitetura ou tecnologia usada para criar um site. Acreditamos que os SPAs e os aplicativos multipáginas (MPAs) são capazes de oferecer experiências de alta qualidade aos usuários. Nossa intenção com a iniciativa das Web Vitals é fornecer métricas que medem a experiência independente da tecnologia. Embora isso não seja possível em todos os casos hoje (devido a limitações na plataforma da Web), estamos trabalhando ativamente para preencher essas lacunas.
Perguntas frequentes
As métricas do Core Web Vitals incluem transições de rota do SPA?
Não. Cada uma das métricas Core Web Vitals é medida em relação à navegação atual de nível superior da página. Se uma página carregar conteúdo novo dinamicamente e atualizar o URL dela na barra de endereço, isso não vai afetar a forma como as métricas das Core Web Vitals são medidas. Os valores da métrica não são redefinidos, e o URL associado a cada medição de métrica é o URL para o qual o usuário navegou e que iniciou o carregamento da página.
As métricas Core Web Vitals podem tratar as mudanças de rota de SPA da mesma forma que os carregamentos de página tradicionais?
Infelizmente, não. Ainda não.
Não há uma maneira padronizada de criar um SPA atualmente, e mesmo entre as bibliotecas de roteamento e SPAs conhecidas, a experiência do usuário pode ser bastante diferente de um app para outro:
- Alguns SPAs atualizam o URL apenas ao carregar um novo conteúdo de "página inteira", enquanto outros sites atualizam o URL para pequenas mudanças de conteúdo ou até mesmo mudanças de estado da interface.
- Alguns SPAs atualizam o URL usando a API History, enquanto outros usam mudanças de hash para oferecer suporte a navegadores mais antigos (e outros não atualizam o URL de jeito nenhum).
- Alguns SPAs carregam o conteúdo e atualizam o URL, enquanto outros atualizam o URL antes de carregar o conteúdo.
- Alguns SPAs carregam o conteúdo de uma só vez, de forma síncrona, em uma única tarefa do JavaScript, enquanto outros fazem a transição do conteúdo de forma assíncrona em várias tarefas (sem um evento de fim de transição claro).
- Alguns SPAs sempre carregam conteúdo da rede, enquanto outros pré-carregam todo o conteúdo com antecedência para que as mudanças de rota sejam carregadas instantaneamente da memória.
Essas diferenças dificultam a definição e a identificação do que constitui uma mudança de rota de SPA ou até mesmo um SPA, em grande escala.
Em alguns casos, uma mudança de rota de SPA é logicamente idêntica a um carregamento de página de MPA. Nesses casos, seria ótimo se as métricas atuais das Core Web Vitals pudessem ser aplicadas.
No entanto, sem heurísticas sólidas para identificar com segurança as mudanças de rota "reais" de todas as outras mudanças de URL, além de indicadores claros que marcam o início e o fim dessas transições, o relatório das métricas das Principais métricas da Web nesses casos iria confundir os dados e torná-los menos úteis ou representativos da experiência real do usuário no site.
É mais difícil para SPAs se saírem bem nas Core Web Vitals do que para MPAs?
Não há nada inerente na arquitetura de SPA que impeça que uma página em um SPA carregue tão rapidamente e tenha uma pontuação tão boa em todas as métricas das Core Web Vitals quanto uma página semelhante em um MPA.
No entanto, os MPAs otimizados corretamente têm algumas vantagens para atender aos limites de Core Web Vitals que os SPAs não têm no momento. Isso acontece porque, com a arquitetura de MPA, cada "página" é carregada como uma navegação de página inteira (em vez de buscar conteúdo dinamicamente e inseri-lo na página atual), o que significa que os usuários que visitam uma MPA têm mais chances de carregar mais de uma página do site, o que, por sua vez, significa que uma porcentagem maior da distribuição de todos os carregamentos de página de uma MPA vai envolver alguns ou todos os subrecursos armazenados em cache.
Para que uma MPA tenha um desempenho melhor nas métricas das Core Web Vitals do que uma SPA, é necessário que algumas coisas sejam verdadeiras:
- O MPA precisa ter o armazenamento em cache de subrecursos otimizado para garantir que as páginas da mesma origem sejam carregadas mais rapidamente do que as páginas de origem cruzada no percentil 75.
- Os usuários que acessam MPAs precisam visitar várias páginas para que o site receba os benefícios do armazenamento em cache, que resultam em carregamentos de página mais rápidos.
Como as avaliações das Core Web Vitals consideram o 75º percentil de visitas à página, ter mais visitas com bom desempenho no conjunto de dados aumenta a probabilidade de que a visita no 75º percentil da distribuição esteja dentro dos limites recomendados.
É importante considerar a forma como os dados são agregados ao comparar as pontuações das Core Web Vitals. Ou seja, se o conjunto de dados na distribuição inclui todas as páginas do seu site ou origem ou apenas as páginas carregadas para um URL de página específico.
Ao agregar as pontuações de todas as páginas em uma origem, páginas rápidas individuais podem melhorar a 75ª percentil da origem como um todo. No entanto, ao agregar por páginas individuais, as pontuações de uma página não afetam as pontuações da próxima. Em outras palavras, ao agregar as pontuações de um MPA por página, os carregamentos rápidos de cache na página de finalização de compra não vão melhorar as pontuações de carregamentos iniciais lentos na página de destino do site.
É possível verificar a pontuação do seu site para diferentes métodos de agregação usando o PageSpeed Insights ou a API Chrome User Experience Report, que informa as pontuações dos URLs de páginas individuais e de toda a origem.
A arquitetura de SPA também pode afetar as pontuações das Core Web Vitals para métricas que consideram a vida útil completa de uma página. Como os usuários que visitam SPAs tendem a permanecer na mesma "página" durante toda a sessão, as métricas que se acumulam ao longo do tempo podem ser mais severas em SPAs do que em MPAs.
Em abril de 2021, anunciamos mudanças na métrica CLS que resolveram parcialmente esse problema. Antes, o CLS se acumulava durante toda a vida útil da página, mas agora ele só se acumula em uma janela de tempo específica, ou seja, o pior pico de mudanças de layout em uma determinada página.
No entanto, mesmo com a nova definição de CLS, as SPAs ainda têm uma desvantagem, porque o valor de CLS não "reinicia" após uma transição de rota, como acontece com carregamentos de página completos em uma MPA. Isso também pode causar confusão, porque os deslocamentos de layout que ocorrem após uma transição de rota são atribuídos ao URL da página quando ela foi carregada, não ao URL na barra de endereço no momento do deslocamento (mais detalhes abaixo).
Se as arquiteturas de SPA melhoram a experiência do usuário, essa melhoria não deveria ser refletida nas métricas?
Sim, deve. No entanto, como mencionado anteriormente, é difícil quantificar o quanto a experiência melhorou em grande escala, considerando todas as diferentes maneiras de implementação de SPAs na Web atualmente.
A verdade é que a indústria de desempenho da Web (incluindo o Google) não investiu tanto tempo e esforço no desenvolvimento de métricas centradas no usuário para o desempenho pós-carregamento de uma página quanto para o carregamento em si. Isso não acontece porque o desempenho pós-carregamento não é importante, mas porque a UX e as interações pós-carregamento são muito mais variadas e menos bem definidas, o que dificulta a criação de métricas para elas.
No entanto, mesmo que tivéssemos métricas pós-carregamento bem definidas para medir o desempenho do SPA, não iríamos ignorar a experiência de carregamento só porque a experiência pós-carregamento melhorou.
Uma das metas da iniciativa das Métricas da Web é promover e incentivar boas experiências do usuário em tantos aspectos de carregamento e uso de uma página da Web quanto possível. Não queremos incentivar cenários em que experiências ruins são justificadas se você pode ter experiências boas suficientes para compensar. Os usuários querem que as páginas carreguem rápido e façam a transição para o novo conteúdo rapidamente. Tentamos criar métricas que favoreçam esses tipos de experiências.
Embora seja verdade que uma versão MPA de um site possa se sair melhor nas métricas das Principais métricas da Web no percentil 75 do que uma versão SPA do mesmo site, a versão SPA ainda precisa se esforçar para atender ao limite "bom". Se a versão do SPA não atender ao limite "bom" para a maioria dos usuários, a experiência inicial de carregamento provavelmente ainda não será percebida como boa, mesmo que a experiência de navegação na página seja excelente.
No futuro, planejamos desenvolver métricas que incentivem experiências ótimas após o carregamento, e acreditamos que esse é o melhor caminho para incentivar SPAs de alta qualidade sem comprometer a experiência de carregamento inicial. Já lançamos uma nova métrica chamada Interaction to Next Paint (INP), que mede a latência de interação em todo o ciclo de vida da página. Também estamos trabalhando em outras métricas pós-carregamento, incluindo as que medem as transições de rota do SPA (confira abaixo).
Mudamos nosso site de MPA para SPA, e nossas pontuações pioraram. Isso é normal?
Depende. Há vários motivos para as pontuações mudarem após uma migração de arquitetura importante, mas uma diminuição no número de cargas de cache aquecidas pode ser responsável por parte da mudança.
Uma maneira rápida de verificar seria testar uma versão MPA e SPA de uma das suas páginas de destino com o Lighthouse. Se a pontuação do Lighthouse for menor em qualquer uma das métricas do Core Web Vitals para a versão SPA, é provável que a experiência de carregamento tenha piorado após a atualização.
Devo mudar meu site de um SPA para um MPA para ter uma pontuação melhor nas Core Web Vitals?
Provavelmente não. Só mude de um SPA para um MPA se você não estiver satisfeito com a pilha do SPA e tiver motivos para acreditar que um MPA vai oferecer uma experiência melhor ao usuário.
Com o tempo, à medida que as métricas das Core Web Vitals melhoram e abrangem mais da experiência de navegação, as equipes com SPAs bem criados que oferecem uma ótima UX devem esperar que as pontuações das Core Web Vitals reflitam isso.
Se as pontuações das Core Web Vitals forem informadas apenas para as páginas de destino de um SPA, como posso depurar problemas que ocorrem nas "páginas" após uma transição de rota?
As ferramentas do Google que informam dados de campo para a métrica Core Web Vitals (como o Search Console e o PageSpeed Insights) usam dados do relatório de experiência do usuário do Chrome (CrUX). O CrUX agrega dados por origem ou pelo URL da página (ou seja, o URL da página no momento do carregamento).
Por todos os motivos listados acima, o CrUX não pode agregar dados pela rota do SPA. No entanto, como proprietário do site, você conhece sua própria arquitetura. É possível medir isso por conta própria, e muitas ferramentas de análise permitem indicar quando uma mudança de rota do SPA está ocorrendo e atualizar seus dados de medição de acordo.
Ao medir as métricas das Core Web Vitals com uma ferramenta de análise, verifique se você está medindo o URL de rota atual e o URL da página original. Isso permite depurar problemas individuais que ocorrem ao longo do ciclo de vida da página, além de agregar por URL da página original para corresponder à forma como as ferramentas do Google medem e relatam as métricas.
Para mais detalhes e práticas recomendadas sobre esse assunto, consulte: Depurar a performance no campo.
O que o Google está fazendo para garantir que as MPAs não tenham uma vantagem injusta em comparação com as SPAs?
Como mencionado acima, em alguns casos, um MPA otimizado corretamente pode informar melhores pontuações do Core Web Vitals na 75ª percentila, porque provavelmente terá uma porcentagem maior de visitas à página em cache. Por outro lado, melhorias reais na experiência do usuário em SPAs otimizados corretamente não estão sendo capturadas por nenhuma das métricas das Core Web Vitals.
No Google, reconhecemos que isso cria incentivos que não estão totalmente alinhados com as metas da iniciativa Web Vitals, e estamos procurando ativamente maneiras de corrigir isso. No momento, estamos analisando duas possíveis soluções, uma de curto prazo e outra de longo prazo:
- Avalie as visitas de páginas de origem cruzada e de mesma origem separadamente.
- Projete novas APIs que permitam uma medição melhor de SPAs.
Avalie as visitas de páginas de origem cruzada e de mesma origem separadamente
Atualmente, as métricas das Core Web Vitals agregam todas as visitas a páginas em um único grupo. Elas não diferenciam visitas novas de recorrentes ou páginas de destino de páginas de finalização de compra ou qualquer outro tipo de agregação em que o estado do cache possa afetar a performance.
Uma maneira de normalizar as diferenças entre a performance da SPA e da MPA é aplicar pesos diferentes a diferentes tipos de visitas, possivelmente até mesmo com recomendações de limite completamente diferentes.
Embora queiramos recompensar as implementações de cache eficazes, não queremos que as navegações rápidas no site sejam capazes de cobrir as cargas lentas da página de destino. Também não queremos incentivar os sites a dividir páginas longas em uma coleção de páginas mais curtas apenas para melhorar as pontuações das métricas.
Ao avaliar separadamente as visitas a páginas de origem cruzada e de mesma origem, podemos ajudar a garantir que os dois tipos de experiências sejam importantes sem deixar que a popularidade relativa de um tipo em um determinado site distorça a distribuição de qualquer métrica específica.
Projetar novas APIs que permitam uma medição melhor do SPA
Outra solução que está sendo desenvolvida (em paralelo à anterior) é uma nova API App History, que ajudaria a padronizar os padrões de SPA atuais e facilitaria a medição e o entendimento do uso de SPA em escala.
A API App History apresenta um novo evento
navigate, que
tem dois recursos principais específicos para medição de SPA:
- Uma flag
userInitiated, que só será definida como verdadeira se a navegação tiver sido iniciada por um clique no link, envio de formulário ou a interface de volta ou para frente do navegador. - Um método
transitionWhile(), que usa uma promessa que permite ao desenvolvedor sinalizar quando o trabalho iniciado para realizar a navegação for concluído.
A flag userInitiated pode ser usada para determinar um ponto de partida semântico para
uma transição de rota de SPA, indicando a intenção clara do usuário. A resolução de promessa transitionWhile()
pode ajudar o navegador a correlacionar as pinturas com a transição de rota
específica, para que ele possa determinar a maior pintura de conteúdo
relacionada a essa transição.
Com base na ideia apresentada na seção anterior, talvez seja possível agregar o tempo de transição da rota do SPA ao mesmo bucket que carrega a página de mesma origem em um MPA. Isso é interessante porque permite que um site migre de um MPA para um SPA para comparar a performance antes e depois.
É claro que mais pesquisas são necessárias antes de sabermos se podemos fazer essas determinações com precisão. Se você tiver sugestões ou feedback sobre essas propostas, envie um e-mail para web-vitals-feedback@googlegroups.com.
Considerações finais
O Google está totalmente comprometido em melhorar as métricas das Métricas da Web e garantir que elas meçam e incentivem experiências de alta qualidade que são importantes para os usuários. No entanto, reconhecemos que há lacunas de medição atualmente. No momento, as métricas não abrangem todos os aspectos da experiência do usuário, mas estamos trabalhando ativamente para preencher essas lacunas.
Apesar das limitações atuais, acreditamos que as áreas capturadas pelas métricas atuais são essenciais para a saúde e o sucesso da Web. Na medida em que os sites (independentemente da arquitetura) não atendem aos limites recomendados, acreditamos que há espaço para melhorias.
Esperamos que esta postagem tenha ajudado a esclarecer esse assunto complexo e cheio de nuances. Como sempre, se você tiver feedback sobre as métricas atuais ou futuras do Core Web Vitals, envie um e-mail para web-vitals-feedback@googlegroups.com.