Em 30 segundos
O Google mexeu nos Core Web Vitals em 2026 em duas frentes. A primeira é a Soft Navigations API, apresentada no Google I/O, que vai permitir medir as métricas em Single Page Applications num próximo Chrome. A segunda é uma mudança em como o INP é medido — não em como ele é pontuado: em páginas com muita interação, a latência sustentada passa a pesar mais. No meio disso, os dados do CrUX de maio de 2026 mostram que só 55,9% das origens acompanhadas passam nas três métricas. Ou seja: a régua ficou mais realista e quase metade dos sites ainda está abaixo dela.
Eu acompanho esses anúncios do Google há alguns anos e confesso que a maioria passa sem mexer no meu dia a dia. Dessa vez foi diferente, porque as duas mudanças atacam exatamente os pontos onde eu mais desconfiava dos números que via nos relatórios.
SPAs finalmente entram na conta
Se você tem uma aplicação em React, Svelte ou Vue, sabe do problema: o usuário clica, a tela muda, mas para o navegador não houve navegação nenhuma. A URL troca por JavaScript e a página "nova" nunca existiu como documento. As Core Web Vitals sempre foram medidas por carregamento de página, então tudo o que acontece depois do primeiro carregamento de uma SPA ficava num limbo.
No balanço do Chrome no Google I/O 2026, o Google apresentou a Soft Navigations API justamente para isso: medir Core Web Vitals nessas navegações "suaves", em um próximo Chrome. Na prática, cada troca de tela dentro da SPA passa a gerar as próprias métricas, em vez de herdar as do carregamento inicial.
O que isso muda para quem mede? Muito. Aquele LCP bonito que você via era só a primeira tela. A segunda, a terceira e a tela de checkout — que é onde o cliente desiste — nunca entraram na conta. Agora entram.
INP: a medida mudou, a nota não
A parte que mais me interessou foi o INP, o Interaction to Next Paint. Segundo a análise do webvitals.tools e a cobertura da DualMedia, a atualização de 2026 mudou como o INP é medido, não como ele é pontuado. Os limites de "bom", "precisa melhorar" e "ruim" continuam os mesmos.
A diferença está no peso da latência sustentada: em páginas com muita interação, uma sequência de respostas lentas passa a contar mais do que antes. Antes dava para "passar" com uma página que respondia bem na média mas travava de vez em quando numa sessão longa. Agora esse travamento recorrente aparece na métrica.
Eu acho a mudança justa. Ninguém abandona um site porque um clique demorou uma vez. Abandona porque o formulário inteiro parecia atolado. É exatamente essa sensação que a medição antiga não capturava direito.
Os números do CrUX
O CrUX, o Chrome User Experience Report, é a base de dados públicos de usuários reais do Chrome — a mesma que o Google usa para a busca. Na versão de maio de 2026, publicada em 9 de junho de 2026, apenas 55,9% das origens acompanhadas passam nas três métricas ao mesmo tempo, segundo o levantamento da MonsterMegs.
Eu li esse número duas vezes. Depois de anos de artigos, ferramentas e alertas no Search Console, quase metade dos sites ainda não fecha as três ao mesmo tempo. E isso antes da mudança do INP começar a aparecer nos dados de campo.
O que isso muda no seu trabalho
O texto da IdeaFueled resume bem uma mudança de mentalidade que eu também venho vendo: as equipes passaram a tratar desempenho como parte da confiabilidade do sistema, com observabilidade contínua do que o usuário real vê — e não como uma auditoria feita de vez em quando no Lighthouse.
Se eu tivesse que reduzir tudo isso a uma lista curta para quem cuida de um frontend, seria esta:
- Pare de confiar só no laboratório. Lighthouse roda numa máquina limpa, com rede simulada. O INP sustentado só aparece com gente de verdade, em sessão longa, no celular de sempre.
- Meça cada tela da SPA. Quando a Soft Navigations API chegar no Chrome, as telas internas vão ter métrica própria. Vale começar a olhar para elas agora.
- Ligue a métrica ao erro. Uma interação lenta muitas vezes é uma requisição que falhou ou um script que estourou. Sem ver a sessão inteira, você otimiza o sintoma.
- Acompanhe todo dia. O CrUX é uma média de 28 dias. Quando o número cai lá, o problema já está em produção há semanas.
Desempenho parou de ser uma nota no relatório e virou um sinal de saúde do sistema, igual a taxa de erro ou tempo de resposta da API.
Como a gente encara isso no Nav Analytics
Foi essa a lógica que fez a gente construir o Nav Analytics do jeito que ele é. A mesma tag que captura erros de JavaScript e requisições com falha também coleta LCP, CLS e INP de usuários reais — e guarda tudo na linha do tempo da sessão. Quando um INP ruim aparece, dá para abrir a sessão e ver o clique, a requisição que demorou e o erro que veio junto, na ordem em que aconteceram.
Não é mágica nem promessa de "passar no Google". É só a diferença entre saber que a métrica piorou e saber por que ela piorou. Com a régua de 2026 pesando a latência sustentada e trazendo as SPAs para dentro da conta, essa diferença ficou bem menos opcional.
Fontes
- Chrome at Google I/O 2026 — Chrome for Developers
- Google Core Web Vitals Update 2026 — webvitals.tools
- Core Web Vitals 2026 — DualMedia
- Core Web Vitals Update — MonsterMegs
- Core Web Vitals 2026 Explained — IdeaFueled