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 Métricas da Web, em maio de 2020, da equipe do Chrome receberam muitas perguntas e comentários excelentes sobre os neste programa.
Talvez o tópico que mais recebemos perguntas, que também seja provavelmente a pergunta mais difícil de responder é como medir as Core Web Vitals aplicativo de página única (SPA), além de como as arquiteturas de SPA afetam as pontuações das Core Web Vitals.
Essas perguntas são difíceis de responder porque o problema é bastante variado, então, 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 têm nenhuma preferência quanto à arquitetura ou tecnologia usada para construir site. Acreditamos que SPAs e aplicativos de várias páginas (MPAs) são capazes de de proporcionar experiências de alta qualidade aos usuários, e nossa intenção com a iniciativa do Android vitals é fornecer métricas que meçam a experiência de forma independente da tecnologia. Embora isso não seja possível em todos os casos atualmente (devido a limitações na plataforma web), estamos trabalhando ativamente para eliminar 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 nas páginas de nível superior. Se uma página carregar dinamicamente novas conteúdo e atualiza o URL da página na barra de endereço, ele não terá o efeito na forma como as Core Web Vitals são medidas. Os valores de métrica não são redefinido, e o URL associado a cada medição da métrica é o URL que o usuário e navegar até ele que iniciou o carregamento da página.
As Core Web Vitals podem tratar as alterações nas rotas de SPA da mesma forma que os carregamentos de página tradicionais?
Infelizmente, não. De qualquer forma, ainda não.
Atualmente, não há um modo padronizado de criar um SPA, e até mesmo entre os SPA populares e bibliotecas de roteamento, a experiência do usuário pode ser bem diferente de app para app:
- Alguns SPAs atualizam o URL somente ao carregar uma nova "página inteira" conteúdo, enquanto Outros sites atualizam o URL para pequenas mudanças de conteúdo ou até mesmo apenas o estado da interface mudanças.
- Alguns SPAs atualizam o URL usando a API History, enquanto outros usam hash alterações para suportar navegadores mais antigos (e outros não atualizam o URL de maneira alguma).
- 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 maneira síncrona, em um único JavaScript tarefa, enquanto outros fazem a transição de conteúdo, de maneira assíncrona, em vários tarefas (sem evento claro de término da transição).
- Alguns SPAs sempre carregam conteúdo da rede, enquanto outros pré-carregam tudo o conteúdo antecipadamente para que as alterações de rota sejam carregadas instantaneamente da memória.
Essas diferenças tornam a definição e a identificação do que constitui uma rota de SPA mudança ou até mesmo o próprio SPA, muito difícil de fazer em grande escala.
Em alguns casos, uma alteração na rota do SPA é logicamente idêntica ao carregamento de uma página da MPA, Nesses casos, seria ótimo se as atuais métricas das Core Web Vitals poderiam ser aplicadas.
No entanto, sem uma heurística sólida para identificar os elementos “reais” de forma confiável mudanças de trajeto de todas as outras alterações de URL, bem como sinais claros que marcam o início e o fim da essas transições. A geração de relatórios sobre as Core Web Vitals nesses casos seria confuso os dados e torná-los 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 os MPAs?
Não há nada inerente à arquitetura do SPA que impeça uma página um SPA seja carregado com a mesma rapidez e seja bem classificado em todos os Métricas da Web, como uma página semelhante em uma MPA.
No entanto, as MPAs adequadamente otimizadas têm algumas vantagens em atender ao Core Web Limites de métricas que os SPAs não têm atualmente. O motivo é que, com a MPA, arquitetura, cada "página" é carregada como uma navegação de página inteira (e não buscar o conteúdo dinamicamente e inseri-lo na página existente), o que significa que os usuários que visitam uma MPA têm mais chances de carregar mais de uma página da site, o que, por sua vez, significa que uma porcentagem maior da distribuição de todos os carregamentos de página de uma MPA envolverão alguns ou todos os sub-recursos armazenadas em cache.
concedida, para uma MPA ter um desempenho melhor nas Core Web Vitals do que um SPA exige que algumas coisas sejam verdadeiras:
- A MPA precisa ter armazenamento em cache de sub-recursos otimizado para garantir os carregamentos de página de mesma origem são realmente mais rápidos do que os carregamentos de página de origem cruzada no 75o percentil.
- Os usuários que visitam as MPAs precisam visitar várias páginas para que o site recebem 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 a 75a percentil da página visitas, ter mais visitas de página com bom desempenho no conjunto de dados aumentará a probabilidade de que a visita no 75o percentil da distribuição seja dentro dos limites recomendados.
É importante considerar isso ao comparar as pontuações das Core Web Vitals. é 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 determinado URL da página.
Ao agregar as pontuações de todas as páginas de 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 pontuações das a seguir. Em outras palavras, ao agregar as pontuações de uma MPA por página, o cache rápido os carregamentos vistos na página de finalização da compra não vão melhorar os resultados de carregamento na página de destino página.
Você pode verificar a pontuação do seu site para diferentes métodos de agregação usando: PageSpeed Insights ou o Chrome User Experience Report API, que informa pontuações para URLs de páginas individuais e para toda a origem.
Outra maneira como a arquitetura do SPA pode afetar as pontuações das Core Web Vitals é para que consideram a vida útil completa de uma página. Como os usuários que visitam SPAs tendem a ficar na mesma "página" para toda a sessão, as métricas que acumulam ao longo do tempo pode ser mais severa com SPAs do que com as MPAs.
Em abril de 2021, anunciamos mudanças na métrica de CLS que resolveu parcialmente esse problema. Anteriormente, a CLS se acumularia ao longo do a vida útil inteira da página, enquanto que agora ela só se acumula em uma janela específica de tempo, essencialmente a pior explosão de trocas de layout em uma determinada página.
No entanto, mesmo com a nova definição do CLS, os SPAs ainda estão em desvantagem porque o valor de CLS não "redefine" após as transições de rota, como acontece com carregamentos de página inteira em uma MPA. Isso também pode causar confusão porque o layout as mudanças que ocorrem após uma transição de rota serão atribuídas ao URL do página quando foi carregado, não o URL na barra de endereço no momento da mudança (mais detalhes abaixo).
Se as arquiteturas de SPA melhorarem a experiência do usuário, essa melhoria não deveria ser refletida nas métricas?
Sim. Conforme mencionado anteriormente, quantificar o quanto as melhorar a experiência do usuário é difícil de fazer em grande escala, dadas as diferentes como os SPAs são implementados na Web atualmente.
A verdade é que o setor de desempenho da Web (inclusive o Google) nunca historicamente que investiram quase o mesmo tempo e esforço no desenvolvimento de aplicativos voltados métricas para o desempenho pós-carregamento de um da mesma forma que para o carregamento da página. Não é porque o pós-carregamento o desempenho não é importante, mas a UX e as interações pós-carregamento são muito muito mais variadas e menos bem definidas, dificultando a criação de métricas para para resolvê-los com rapidez.
Mas mesmo se tivéssemos métricas de pós-carregamento bem definidas para medir o SPA desempenho, não queremos ignorar a experiência de carregamento só porque a experiência pós-carregamento ficou melhor.
Um dos objetivos da iniciativa de Métricas da Web é promover e incentivar experiências do usuário em todos os aspectos do carregamento e uso de uma página sempre que possível. Não queremos incentivar cenários em que experiências ruins são se você consegue ter experiências boas o suficiente para compensá-las. Usuários querem que as páginas carreguem rapidamente e façam uma transição rápida para novos conteúdos, e tentamos métricas de design que favorecem esses tipos de experiência.
Portanto, embora seja verdade que a versão MPA de um site pode ter uma performance melhor na Web métricas vitais no 75o percentil do que uma versão do SPA exatamente igual site, a versão do SPA ainda deve se esforçar para atender ao o limite mínimo. Se o A versão do SPA não atende ao requisito "boa" para a maioria dos usuários, o valor inicial do usuário provavelmente ainda não será considerada boa, mesmo que as mudanças experiência de navegação na página é excelente.
No futuro, planejamos desenvolver métricas que incentivem ótimas respostas experiências de alta qualidade. Acreditamos que esse é o melhor caminho para incentivar SPAs de uma forma que não comprometa a experiência de carregamento inicial. Temos já entregamos uma nova métrica chamada Interaction to Next Paint (INP), que mede a latência de interação durante todo o ciclo de vida da página, e estamos trabalhando ativamente em outras métricas de pós-carregamento também, incluindo métricas que medem as transições de rotas de SPA Confira abaixo.
Mudamos nosso site de um MPA para um SPA, e nossas pontuações regrediram. Isso é esperado?
Depende. Há vários motivos pelos quais suas pontuações podem mudar após um migração principal da arquitetura, mas uma diminuição no número de cargas de cache quentes pode explicar parte da mudança.
Uma maneira rápida de verificar isso é testar a versão MPA e o SPA de um dos seus páginas de destino com Farol. Se o A pontuação do Lighthouse é menor em qualquer uma das Core Web Vitals para o SPA é provável que a experiência de carregamento tenha piorado após a atualizar.
Devo mudar meu site de um SPA para um MPA para melhorar a pontuação nas Core Web Vitals?
Provavelmente não. Você só deve mudar de um SPA para um MPA se não estiver satisfeito com sua pilha de SPA e tiver motivos para acreditar que uma MPA proporcionará uma abordagem experiência do usuário.
Com o tempo, à medida que as Core Web Vitals melhoram e abrangem mais experiência de navegação, as equipes com SPAs bem elaborados que oferecem ótima UX devem esperam 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 em "páginas"? após uma transição de rota?
Ferramentas do Google que informam dados de campo para a métrica Core Web Vitals (como a Pesquisa Console e PageSpeed Insights) obtém dados da experiência do usuário do Chrome Relatório (CrUX, na sigla em inglês). Já o CrUX agrega dados por origem ou URL da página (ou seja, URL da página no momento de carregamento).
Por todos os motivos listados acima, o CrUX não pode agregar dados usando Rota do SPA. No entanto, como proprietário de site familiarizado com sua própria arquitetura, é possível medir isso por conta própria, e muitas ferramentas de análise permitem que você sinalizar quando uma mudança na rota do SPA estiver acontecendo e atualizar sua medição os dados de modo adequado.
Ao avaliar as métricas das Métricas da Web com uma ferramenta de análise, confira se você está medir o URL da rota atual e o URL da página original. Isso vai permitem que você depure problemas individuais que ocorrem na página bem como agregar por URL da página original para corresponder à forma como o que as ferramentas medem e relatam as métricas.
Para mais detalhes e práticas recomendadas sobre esse assunto, consulte: Depurar o desempenho no .
O que o Google está fazendo para garantir que as MPAs não tenham uma vantagem injusta em relação aos SPAs?
Como mencionado acima, uma MPA otimizada adequadamente pode, em alguns casos, relatar melhor as pontuações das Métricas da Web no 75o percentil porque provavelmente têm uma porcentagem maior de visitas à página em cache. Por outro lado, melhorias reais a experiência do usuário em SPAs otimizados adequadamente não estão sendo capturadas no momento de acordo com as Core Web Vitals.
No Google, sabemos que isso cria incentivos que não estão totalmente alinhados com as metas da iniciativa de Métricas da Web. Além disso, estamos analisando formas para corrigir isso. No momento, estamos analisando duas possíveis soluções, uma de curto prazo e um de longo prazo:
- Avalie as visitas à página com e com a mesma origem separadamente.
- Projetar novas APIs que permitem uma melhor medição de SPA.
Avaliar as visitas à página com origens diferentes e com a mesma origem separadamente
Atualmente, as Core Web Vitals agregam todas as visitas à página em um único público, elas não diferenciam entre visitas novas e recorrentes ou páginas de destino em comparação a páginas de finalização de 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 do SPA e da MPA seria aplicar ponderações diferentes a tipos diferentes de visitas, potencialmente até mesmo com um limite totalmente diferente e recomendações.
Queremos recompensar implementações eficazes de cache, mas não que a navegação rápida no site seja capaz de cobrir páginas de destino lentas carregar. Também não queremos incentivar os sites a dividir páginas longas em um conjunto de páginas mais curtas apenas para melhorar as pontuações das métricas.
Ao avaliar separadamente as visitas a páginas com e sem a mesma origem, podemos ajudar garantem que ambos os tipos de experiências sejam importantes sem deixar que a parte relativa A popularidade de um tipo em determinado site distorce a distribuição de um determinado métrica.
Criar novas APIs que permitem uma melhor medição de SPA
Outra solução em que estamos trabalhando (em paralelo à anterior) é uma nova API App History, que ajuda a padronizar os processos padrões de SPA e facilitar a medição e compreensão do uso de SPA em escala.
A API App History apresenta uma nova
evento navigate, que
tem dois recursos principais específicos da medição de SPA:
- Um
userInitiated, que só será definido como verdadeiro se a navegação tiver sido iniciada por meio de um clique no link, envio de formulário ou a interface de usuário de retorno ou encaminhamento do navegador. - Um
transitionWhile(), que aceita 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 a fim de determinar um ponto de partida semântico para
uma transição de rota de SPA, indicando clara intenção do usuário. O transitionWhile()
a resolução de promessas pode ajudar o navegador a correlacionar pinturas com a rota específica
transição, para poder determinar a maior exibição de conteúdo
relacionadas a essa transição.
Com base na ideia apresentada na seção anterior, pode ser possível agregar o tempo de transição da rota do SPA no mesmo bucket carregamento de página de mesma origem em uma MPA. Isso é muito bom porque permite que um site migrar de uma MPA para um SPA para realmente comparar o desempenho anterior e depois.
É claro que mais pesquisas são necessárias para sabermos se podemos usar fazer essas determinações. Se você tiver sugestões ou feedback sobre propostas, envie um e-mail web-vitals-feedback@googlegroups.com.
Considerações finais
O Google está muito comprometido em melhorar as métricas das Web Vitals e garantir medem e incentivam experiências de alta qualidade que são importantes para usuários. Dito isso, reconhecemos que existem lacunas na medição atualmente. A atualmente não cobrem todos os aspectos da experiência do usuário, mas estamos trabalhando ativamente para fechar essas lacunas.
Apesar das limitações atuais, acreditamos que as áreas nas quais as métricas existentes capturadas são fundamentais para a integridade e o sucesso da Web e na medida que os sites (independentemente da arquitetura) não atendam aos limites recomendados, acreditamos que podemos melhorar.
Espero que a postagem tenha ajudado você a entender esse assunto complexo e cheio de nuances. Como sempre, se você tiver feedback sobre as métricas atuais ou futuras das Web Vitals, envie um e-mail web-vitals-feedback@googlegroups.com.