Respostas a perguntas comuns sobre SPAs, Core Web Vitals e como as Core Web Vitals tratam esses elementos.
Publicado em 14 de setembro de 2021, atualizado pela última vez em 11 de agosto de 2026
Desde que apresentamos a 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 é provavelmente a questão 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), bem como 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 sutil. 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 afirmar 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 medem a experiência independente da tecnologia.
Perguntas frequentes
A seguir, algumas das perguntas mais comuns que recebemos sobre esse assunto. Aceitamos feedback para adicionar a estas perguntas frequentes no nosso grupo de feedback ou abrindo um problema.
As métricas Core Web Vitals incluem transições de rota de SPA?
Quando foram introduzidas pela primeira vez, cada uma das métricas Core Web Vitals foi medida em relação à navegação da página atual de nível superior. Se uma página carregasse dinamicamente um novo conteúdo e atualizasse o URL da página na barra de endereço, isso não afetaria a forma como as métricas Core Web Vitals são medidas.
Os valores das métricas não foram 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 de página.
O Chrome 151 introduziu novas APIs que permitem a medição das Core Web Vitals em transições de rota de SPA. No momento da redação (agosto de 2026), essas APIs estão começando a ser usadas em bibliotecas de medição, como web-vitals, soluções de RUM e ferramentas como o Chrome DevTools. O Chrome ainda não publicou prazos para integrar esses elementos ao Chrome User Experience Report (CrUX). Além disso, outros mecanismos de navegador ainda não oferecem suporte a essas novas APIs. Portanto, as Core Web Vitals só podem ser medidas em carregamentos de página inteira para esses navegadores.
Por que esse foi um problema difícil de resolver?
Não há uma maneira padronizada de criar um SPA hoje, e mesmo entre as bibliotecas de SPA e roteamento mais populares, a experiência do usuário pode ser bastante diferente de um app para outro:
- Alguns SPAs atualizam o URL somente 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 apenas 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).
- Alguns SPAs carregam conteúdo e atualizam o URL, enquanto outros atualizam o URL 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 de conteúdo de forma assíncrona em várias tarefas (sem um evento de término de transição claro).
- Alguns SPAs sempre carregam conteúdo da rede, enquanto outros pré-carregam todo o conteúdo para que as mudanças de rota sejam carregadas instantaneamente da memória.
Essas diferenças dificultam muito a definição e a identificação do que constitui uma mudança de rota de SPA ou até mesmo um SPA em escala.
Em alguns casos, uma mudança de rota de SPA é logicamente idêntica a um carregamento de página MPA. Nesses casos, seria ótimo se as métricas Core Web Vitals atuais pudessem ser aplicadas.
No entanto, sem heurísticas sólidas para identificar de forma confiável as mudanças de rota "reais" de todas as outras mudanças de URL, bem como indicadores claros que marcam o início e o fim dessas transições, a geração de relatórios de métricas Core Web Vitals nesses casos confundiria os dados e os tornaria menos úteis ou representativos da experiência real do usuário no site.
O trabalho de navegação suave forneceu uma solução para isso com duas novas APIs de performance:
PerformanceSoftNavigation, que mede quando uma interação do usuário leva a uma pintura e a uma mudança de URL. A combinação dessas três coisas fornece uma definição padronizada de uma "navegação suave", independente da estrutura usada e de algumas das diferenças mencionadas anteriormente. Isso permite dividir a linha do tempo de performance em "navegações" separadas, permitindo que o CLS e o INP sejam medidos para cada navegação.InteractionContentfulPaint, que mede "pinturas de conteúdo" após uma interação, permitindo que o FCP e o LCP sejam medidos para essas navegações suaves.
A combinação dessas duas APIs permite que as Core Web Vitals sejam medidas em carregamentos de página inteira e navegações suaves.
As mudanças de rota de SPA são iguais aos carregamentos de página inteira para as Core Web Vitals?
Não, ainda há muitas diferenças entre esses tipos de navegação, o que pode resultar em métricas Core Web Vitals diferentes.
Uma navegação suave tem conteúdo na página e está atualizando parte ou todo esse conteúdo para mostrar a nova "página". De muitas maneiras, isso é semelhante à diferença entre um carregamento de página inteira não armazenado em cache e um carregamento de página quando alguns ou todos os recursos da página são armazenados em cache, mas em um estado ainda mais extremo, já que alguns conteúdos podem permanecer renderizados.
Em teoria, a principal diferença será o potencial de navegações suaves serem muito mais rápidas. Mas há outras diferenças mais sutis.
As novas APIs de navegação suave consideram apenas o novo conteúdo. Portanto, uma página que atualiza o <h1> e o conteúdo de texto, mas deixa a mesma imagem principal entre as páginas, não considera a imagem principal como um candidato a LCP se ela não for repintada. Isso vai gerar diferenças nos elementos usados para calcular o tempo de LCP com base em se a mesma página é carregada como um carregamento de página inteira ou como uma navegação suave de outra página.
Da mesma forma, o INP pode ser menor para navegações suaves, já que muito do JavaScript necessário para executar o site já estará carregado. Da mesma forma, uma navegação suave pode ter menos (ou mais!) CLS se o mesmo conteúdo causar CLS em um carregamento de página inteira, mas não precisar ser carregado ou renderizado novamente em uma navegação suave.
Há também pequenas diferenças em quando as medições são feitas em carregamentos de página inteira (medidas após o processamento da interação de navegação) em comparação com navegações suaves (medidas a partir do tempo de início da interação).
Como já afirmamos, muitas dessas diferenças são semelhantes a páginas não armazenadas em cache versus armazenadas em cache, e o conceito do que as Core Web Vitals tentam medir ainda se aplica. No entanto, vale a pena entender essas sutilezas ao investigar problemas das Core Web Vitals.
É mais difícil para SPAs ter um bom desempenho nas Core Web Vitals do que MPAs?
Não há nada inerente à arquitetura de SPA que impeça uma página em um SPA de carregar tão rapidamente quanto uma página semelhante em um MPA e de ter uma pontuação tão boa em todas as métricas Core Web Vitals.
No entanto, as MPAs otimizadas corretamente têm algumas vantagens no atendimento aos limites das Core Web Vitals que os SPAs não têm. Isso foi amplamente atenuado com o trabalho de navegações suaves discutido anteriormente, mas ainda pode ser o caso quando essas novas APIs ainda não são usadas. O motivo é que, com a arquitetura 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 probabilidade 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 para uma MPA vai envolver alguns ou todos os sub-recursos armazenados em cache.
É claro que, para uma MPA ter um desempenho melhor nas métricas Core Web Vitals do que um SPA, algumas coisas precisam ser verdadeiras:
- A MPA precisa ter o armazenamento em cache de sub-recursos otimizado para garantir que os carregamentos de página da mesma origem sejam realmente mais rápidos do que os carregamentos de página entre origens no 75º percentil.
- Os usuários que visitam MPAs precisam acessar várias páginas para que o site receba os benefícios de 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 das visitas de página, ter mais visitas de página com bom desempenho no conjunto de dados vai aumentar a probabilidade de que a visita no 75º percentil da distribuição esteja dentro dos limites recomendados.
Um aspecto importante a ser considerado 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 seu site ou origem ou apenas carregamentos de página para um URL de página específico.
Ao agregar as pontuações de todas as páginas em uma origem, as páginas rápidas individuais podem melhorar o 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 uma MPA por página, os carregamentos rápidos de cache vistos na página de finalização da compra não vão melhorar as pontuações de carregamentos iniciais lentos na página de destino do site.
Você pode conferir 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áginas individuais e para toda a origem.
Outra maneira pela qual a arquitetura de SPA 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.
Com o trabalho de navegações suaves, acreditamos que não há desvantagens para SPAs em termos de como as Core Web Vitals podem ser medidas. No entanto, a integração completa dessas APIs em todas as ferramentas e soluções de relatórios vai levar tempo.
Se as arquiteturas de SPA melhoram a experiência do usuário, essa melhoria não deveria ser refletida nas métricas?
Sim, deveria. Quantificar o quanto a experiência melhorou era difícil de fazer em escala, considerando todas as maneiras diferentes de implementar SPAs na Web hoje. Agora temos uma solução para o problema de medição e, quando essas novas APIs são usadas, todas as melhorias da mudança para SPAs devem ser refletidas nas métricas.
A verdade é que o setor de performance da Web (incluindo o Google) historicamente 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 de página em si. Isso não acontece porque a performance 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.
Mas, mesmo agora que temos mais métricas pós-carregamento para medir a performance de SPA, não queremos ignorar a experiência de carregamento só porque a experiência pós-carregamento melhorou.
Um dos objetivos da iniciativa Web Vitals é promover e incentivar boas experiências do usuário em vários aspectos do carregamento e do uso de uma página da Web. Não queremos incentivar cenários em que experiências ruins sejam justificadas se você tiver experiências boas suficientes para compensá-las. Os usuários querem que as páginas carreguem rápido e façam a transição para um novo conteúdo rapidamente, e tentamos criar métricas que favoreçam esses tipos de experiências.
Mudamos nosso site de uma MPA para um SPA e nossas pontuações regrediram. Isso é esperado?
Depende. Há vários motivos para que suas pontuações mudem após uma migração de arquitetura importante, mas uma diminuição no número de carregamentos de cache quente pode explicar parte da mudança.
Uma maneira rápida de verificar isso é 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 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 uma MPA para ter uma pontuação melhor nas Core Web Vitals?
Provavelmente não. Você só deve mudar de um SPA para uma MPA se não estiver satisfeito com sua pilha de SPA e tiver motivos para acreditar que uma MPA vai oferecer uma experiência melhor ao usuário.
Com o trabalho de navegações suaves, acreditamos que resolvemos os problemas de medição. Portanto, mudar apenas por esse motivo não faz sentido.
No entanto, se você tiver motivos para mostrar que a performance vai melhorar, em vez de apenas as medições, esse pode ser um motivo para mudar de SPA para MPA (ou vice-versa).
Se as pontuações das Core Web Vitals só forem informadas 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?
As ferramentas do Google que informam dados de campo para a métrica Core Web Vitals (como o Search Console e o PageSpeed Insights) recebem os dados do Chrome User Experience Report (CrUX). O CrUX agrega dados por origem ou por URL da página (ou seja, o URL da página no momento do tempo de carregamento).
Estamos trabalhando para permitir que o CrUX inclua dados por rota de SPA nos dados agregados. No entanto, como proprietário do site, você já pode usar as novas APIs para medir as Core Web Vitals por rota de SPA antes disso para entender como suas pontuações podem mudar.
Para mais detalhes e práticas recomendadas sobre isso, consulte: Medir navegações suaves.
O que o Google está fazendo para garantir que as MPAs não tenham uma vantagem injusta em comparação com os SPAs?
Como mencionado anteriormente, com o trabalho de navegações suaves, acreditamos que o trabalho que realizamos agora significa que não há desvantagens para SPAs nesse sentido, embora a integração completa em todas as ferramentas e soluções de relatórios leve tempo.
Avaliar visitas de página entre origens e da mesma origem separadamente
Atualmente, as métricas Core Web Vitals agregam todas as visitas de página em um único bucket. Elas não diferenciam entre visitas novas e recorrentes ou páginas de destino e páginas de finalização de compra ou qualquer outro tipo de agregação em que o estado do cache possa afetar a performance.
Embora queiramos recompensar implementações de cache eficazes, não queremos que navegações rápidas no site possam encobrir carregamentos lentos de páginas 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 de página entre origens e da mesma origem, podemos garantir que ambos os tipos de experiências sejam importantes sem permitir que a popularidade relativa de um tipo em um determinado site distorça a distribuição de uma métrica específica.
Considerações finais
O Google está profundamente comprometido em melhorar as métricas Web Vitals e garantir que elas meçam e incentivem experiências de alta qualidade importantes para os usuários. Dito isso, reconhecemos que existem lacunas de medição hoje. As métricas agora podem cobrir transições de rota de SPA, o que resolve uma das principais lacunas.
Também acreditamos que essas novas APIs (principalmente InteractionContentfulPaint) têm outros usos e benefícios potenciais além da medição das Core Web Vitals para navegações suaves. Estamos muito animados para continuar a desenvolver esses elementos agora que o principal motivo da introdução deles foi resolvido.
Espero que esta postagem tenha ajudado a esclarecer esse assunto complexo e sutil. Como sempre, se você tiver feedback sobre as métricas Web Vitals atuais ou futuras, envie um e-mail para web-vitals-feedback@googlegroups.com.