Respostas a perguntas comuns sobre SPAs, Core Web Vitals e o plano do Google para lidar com as limitações atuais de medição.
Desde o lançamento da iniciativa Web Vitals 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, que também é a pergunta mais difícil de responder, é como medir as Core Web Vitals em um aplicativo de página única (SPA) e como as arquiteturas de SPA afetam as pontuações das Core Web Vitals.
Essas perguntas são difíceis de responder porque o problema tem muitas nuances. Por isso, nesta postagem vamos fazer o possível para responder às perguntas mais comuns, fornecendo o máximo de detalhes e contexto possíveis.
Antes de entrar em detalhes, é importante declarar que o Google não tem preferência quanto à arquitetura ou tecnologia usada para criar um site. Acreditamos que os SPAs e os aplicativos de várias páginas (MPAs, na sigla em inglês) são capazes de oferecer experiências de alta qualidade aos usuários, e nossa intenção com a iniciativa Web Vitals é fornecer métricas que meçam a experiência independentemente da tecnologia. Embora isso não seja possível em todos os casos atualmente (devido a limitações na plataforma da Web), estamos trabalhando ativamente para preencher essas lacunas.
Perguntas frequentes
As métricas das Core Web Vitals incluem transições de rota do SPA?
Não. Cada uma das Core Web Vitals é medida em relação à navegação atual nas páginas de nível superior. Se uma página carregar um novo conteúdo dinamicamente e atualizar o URL da página na barra de endereço, isso não afetará como as Core Web Vitals são medidas. Os valores de métricas não são redefinidos, e o URL associado a cada medição de métrica é o URL para o qual o usuário acessou o carregamento de página.
As métricas das Core Web Vitals podem tratar as mudanças na rota do SPA da mesma forma que os carregamentos de página tradicionais?
Infelizmente, não. Ainda não.
Atualmente, não há uma maneira padronizada de criar um SPA. Mesmo entre as bibliotecas de roteamento e de SPA conhecidas, a experiência do usuário pode ser muito diferente de um app para outro:
- Alguns SPAs atualizam o URL somente ao carregar o novo conteúdo da página inteira, enquanto outros sites atualizam o URL para pequenas mudanças de conteúdo ou até mesmo apenas no estado da IU.
- Alguns SPAs atualizam o URL usando a API History, enquanto outros usam alterações de hash para oferecer suporte a navegadores mais antigos (e outros não atualizam o URL).
- Alguns SPAs carregam o conteúdo e depois atualizam o URL, enquanto outros o atualizam antes de carregar o conteúdo.
- Alguns SPAs carregam conteúdo de uma só vez, de forma síncrona, em uma única tarefa JavaScript, enquanto outros fazem a transição do conteúdo de forma assíncrona em várias tarefas (sem um evento final de transição claro).
- Alguns SPAs sempre carregam conteúdo da rede, enquanto outros pré-carregam todo o conteúdo antecipadamente para que as alterações de rota carreguem instantaneamente da memória.
Essas diferenças dificultam a definição e identificação do que constitui uma mudança de rota do SPA ou o próprio SPA em grande escala.
Em alguns casos, uma mudança de rota do SPA é logicamente idêntica a um carregamento de página da MPA. Nesses casos, seria ótimo se as métricas atuais das Core Web Vitals pudessem ser aplicadas.
No entanto, sem uma heurística sólida para identificar de maneira confiável mudanças de rota "reais" de todas as outras mudanças de URL, bem como sinais claros que marcam o início e o fim dessas transições, informar as métricas das Core Web Vitals nesses casos prejudicaria os dados e os tornaria menos úteis ou representativos da experiência real do usuário no site.
É mais difícil para os SPAs terem um bom desempenho nas Core Web Vitals do que para as MPAs?
Não há nada inerente à arquitetura de SPA que impeça o carregamento de uma página em um SPA com a mesma velocidade (e com uma pontuação tão boa em todas as Core Web Vitals) como uma página semelhante em uma MPA.
No entanto, as MPAs otimizadas têm algumas vantagens em atender aos limites do Core Web Vitals que os SPAs não têm atualmente. Isso acontece porque, com a arquitetura da MPA, cada "página" é carregada como uma navegação de página completa (em vez de buscar dinamicamente o conteúdo e inseri-lo na página existente). Isso significa que os usuários que visitam uma MPA são mais propensos a carregar mais de uma página do site, o que significa que uma porcentagem maior da distribuição de todos os carregamentos de página de uma MPA envolve alguns ou todos os sub-recursos que estão sendo armazenados em cache.
No entanto, para que uma MPA tenha um desempenho melhor nas Core Web Vitals do que um SPA, algumas coisas precisam ser atendidas:
- A MPA precisa ter otimizado o armazenamento em cache dos sub-recursos para garantir que os carregamentos de páginas de mesma origem sejam realmente mais rápidos que os de origem cruzada no 75o percentil.
- Os usuários que visitam as MPAs precisam visitar várias páginas para que o site tenha 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 75o percentil de visitas à página, ter mais visitas à página de bom desempenho no conjunto de dados aumentará a probabilidade de uma visita no 75o percentil da distribuição estar dentro dos limites recomendados.
Ao comparar as pontuações das Core Web Vitals, é importante considerar como os dados são agregados, ou seja, se o conjunto de dados na distribuição inclui todas as páginas do site ou da origem ou apenas carregamentos de página de um URL específico.
Ao agregar as pontuações de todas as páginas em uma origem, as páginas rápidas individuais podem melhorar o 75o percentil da origem como um todo. No entanto, ao agregar por páginas individuais, as pontuações de uma página não afetarão as da próxima. Em outras palavras, ao agregar as pontuações de uma MPA por página, os carregamentos de cache rápidos vistos na página de finalização da compra não melhoram as pontuações de carregamentos iniciais lentos na página de destino do site.
Verifique 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 pontuações para URLs de página individuais e para toda a origem.
Outra maneira pela qual a arquitetura de SPA pode afetar as pontuações das Core Web Vitals é em 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 acumuladas ao longo do tempo podem ser mais difíceis em SPAs do que as MPAs.
Em abril de 2021, anunciamos mudanças na métrica de CLS que solucionaram parcialmente esse problema. Anteriormente, a CLS acumulava-se durante toda a vida útil da página, mas agora ela só se acumula ao longo de uma janela específica. Essencialmente, é o pior burst de mudanças de layout em uma determinada página.
No entanto, mesmo com a nova definição de CLS, os SPAs ainda estão em desvantagem, porque o valor do CLS não é "redefinido" após a transição de uma rota, como acontece com o carregamento de página completa em uma MPA. Isso também pode causar confusão, porque as mudanças de layout que ocorrem após uma transição de trajeto são atribuídas ao URL da página quando ela foi carregada, não ao URL na barra de endereço no momento da mudança (mais detalhes abaixo).
Se as arquiteturas de SPA melhoram a experiência do usuário, essa melhoria não deve ser refletida nas métricas?
Sim. Conforme mencionado anteriormente, é difícil quantificar o quanto a experiência melhorou em grande escala, considerando todas as diferentes maneiras de implementar os SPAs na Web atualmente.
A verdade é que o setor de desempenho na Web (inclusive o Google) não costuma investir tanto tempo e esforço no desenvolvimento de métricas centradas no usuário quanto no carregamento da página após o carregamento. Isso não ocorre 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.
Mesmo que tivéssemos métricas pós-carregamento bem definidas para medir o desempenho do SPA, não seria bom ignorar a experiência de carregamento só porque ela ficou melhor.
Uma das metas da iniciativa das Métricas da Web é promover e incentivar boas experiências do usuário no maior número possível de aspectos do carregamento e do uso de uma página da Web. Não queremos incentivar cenários em que experiências ruins são justificadas se você pode ter experiências boas suficientes para compensá-las. Os usuários querem que as páginas carreguem rapidamente e façam a transição para novos conteúdos com rapidez, por isso tentamos projetar métricas que favorecem esses tipos de experiência.
Portanto, embora seja verdade que uma versão de MPA de um site pode ter um desempenho melhor nas métricas do Core Web Vitals no 75o percentil do que uma versão de SPA exatamente do mesmo site, a versão de SPA ainda precisa se esforçar para atingir o limite "bom". Se a versão do SPA não atingir o limite "bom" para a maioria dos usuários, a experiência de carregamento inicial provavelmente ainda não será considerada boa, mesmo que a experiência de navegação subsequente na página seja excelente.
No futuro, planejamos desenvolver métricas que incentivem ótimas experiências pós-carregamento, e acreditamos que esse é o melhor caminho para incentivar SPAs de alta qualidade de uma forma que não comprometa a experiência de carregamento inicial. Já enviamos uma nova métrica chamada Interação com a próxima exibição (INP, na sigla em inglês), que mede a latência da interação em todo o ciclo de vida da página. Também estamos trabalhando ativamente em outras métricas pós-carregamento, incluindo aquelas que medem as transições de rota do SPA (confira abaixo).
Mudamos nosso site de MPA para SPA, e nossas pontuações regrediram. Isso é esperado?
Depende. Há vários motivos pelos quais suas pontuações podem mudar após uma grande migração de arquitetura, mas uma redução no número de cargas de cache com estado salvo pode ser responsável por algumas das alterações.
Uma maneira rápida de verificar isso seria testar as versões de 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 das Core Web Vitals para a versão do SPA, é provável que a experiência de carregamento tenha piorado após a atualização.
Devo mudar meu site de SPA para MPA e ter uma melhor pontuação nas Core Web Vitals?
Provavelmente não. Só mude de SPA para MPA se a pilha de SPA não for satisfatória e se você tiver motivos para acreditar que a MPA vai proporcionar uma melhor experiência do usuário.
Com o tempo, à medida que as Core Web Vitals melhoram e abrangem mais da experiência de navegação completa, as equipes com SPAs bem elaborados que oferecem ótima UX devem esperar que as pontuações das Core Web Vitals reflitam isso.
Se as pontuações das Core Web Vitals forem informadas somente para as páginas de destino de um SPA, como posso depurar problemas que ocorrem em "páginas" após uma transição de trajeto?
As ferramentas do Google que informam dados de campo para as Core Web Vitals (como o Search Console e o PageSpeed Insights) recebem dados do Chrome User Experience Relatório (CrUX, na sigla em inglês). E o CrUX agrega dados por origem ou por URL da página (ou seja, o URL da página no momento do carregamento).
Por todos os motivos já listados acima, o CrUX não é capaz de agregar dados por rota de SPA. No entanto, como proprietário de um site familiarizado com sua própria arquitetura, é possível medir isso por conta própria. Muitas ferramentas de análise permitem sinalizar quando uma mudança de rota do SPA está ocorrendo e atualizar seus dados de medição de acordo com isso.
Ao medir as Métricas da Web com uma ferramenta de análise, avalie o URL da rota atual e o URL da página original. Isso permitirá depurar problemas individuais que ocorrem durante todo o ciclo de vida da página e agregar pelo URL da página original para corresponder à forma como as ferramentas do Google medem e informam sobre as métricas.
Para mais detalhes e práticas recomendadas sobre este tópico, consulte: Depurar o desempenho no campo.
O que o Google está fazendo para garantir que as MPAs não tenham uma vantagem injusta em relação às SPAs?
Como mencionado acima, uma MPA otimizada corretamente pode, em alguns casos, gerar melhores pontuações de Métricas da Web no 75o percentil devido ao fato de que 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 se alinham totalmente com os objetivos da iniciativa de Métricas da Web 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 à página de origem cruzada e da mesma origem separadamente.
- Criar novas APIs que melhorem a medição de SPA.
Avaliar as visitas a páginas de origem cruzada e da mesma origem separadamente
Atualmente, as Core Web Vitals agregam todas as visitas à página em um único bucket. Elas não diferenciam visitas novas e páginas de destino ou páginas de destino das páginas de finalização da compra ou qualquer outro tipo de agregação em que o estado do cache pode afetar o desempenho.
Uma maneira de normalizar as diferenças entre o desempenho de SPA e MPA é aplicar ponderação diferente a tipos de visitas distintos, possivelmente até mesmo com recomendações de limite completamente distintas.
Queremos recompensar implementações de cache eficazes, mas não queremos que as navegações rápidas dentro do site cubram os carregamentos lentos da página de destino. Também não queremos incentivar os sites a dividir páginas longas em um conjunto de páginas mais curtas apenas para melhorar a pontuação das métricas.
Ao avaliar separadamente as visitas a páginas de mesma origem e de origem cruzada, podemos ajudar a garantir que os dois tipos de experiências sejam importantes sem que a popularidade relativa de um tipo em um determinado site distorça a distribuição de uma métrica específica.
Criar novas APIs que melhorem a medição de SPA
Outra solução que está sendo desenvolvida ativamente (em paralelo ao tópico acima) é uma nova API App History, que ajudaria a padronizar os padrões atuais de SPA e facilitaria a medição e a compreensão do uso do SPA em escala.
A API App History introduz um novo evento navigate, que tem dois recursos principais específicos para a medição de SPA:
- Uma sinalização
userInitiated, que só será definida como verdadeira se a navegação tiver sido iniciada por um clique no link, envio de formulário ou interface de retorno ou encaminhamento do navegador. - Um método
transitionWhile(), que usa uma promessa que permite ao desenvolvedor sinalizar quando o trabalho iniciado para executar a navegação foi concluído.
A sinalização userInitiated pode ser usada para determinar um ponto de partida semântico para uma transição de rota SPA, indicando uma intent clara do usuário. A resolução da 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 exibição de conteúdo
relacionada a essa transição.
Com base na ideia apresentada na seção anterior, pode até ser possível agregar o tempo de transição da rota SPA no mesmo bucket que os carregamentos de página de mesma origem em um MPA. Isso é empolgante, porque permitiria que um site migrando de uma MPA para um SPA realmente comparasse o desempenho antes e depois.
Obviamente, são necessárias mais pesquisas antes de sabermos se podemos tomar 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á muito comprometido a melhorar as 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. Reconhecemos que existem lacunas na medição. No momento, as métricas não abrangem todos os aspectos da experiência do usuário, mas estamos trabalhando ativamente para eliminar essas lacunas.
Apesar das limitações atuais, acreditamos que as áreas que as métricas atuais capturam são essenciais para a integridade e o sucesso da Web. Além disso, na medida em que os sites (independentemente da arquitetura) não atendem aos limites recomendados, acreditamos que é possível melhorar.
Espero 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 das Métricas da Web, envie um e-mail para web-vitals-feedback@googlegroups.com.