A história dos Core Web Vitals

• Os Core Web Vitals, que medem o desempenho de sites, começaram a surgir em 2014 a partir de um esforço colaborativo entre várias equipes do Google para superar as limitações do projeto AMP e definir métricas abertas e padronizadas de desempenho aplicáveis a qualquer site
• Em maio de 2020, foram anunciadas oficialmente três métricas principais (LCP para velocidade de carregamento, FID para responsividade à interação e CLS para estabilidade visual), projetadas como métricas mensuráveis em campo que refletem a experiência real dos usuários
• Em 2021, elas foram introduzidas como fator de ranqueamento por meio da atualização Page Experience do Google Search, e a exigência exclusiva de AMP no Top Stories foi removida, criando um ambiente de competição na web aberta
• Com otimizações no navegador Chrome, melhorias em grandes CMS como o WordPress e colaboração com frameworks JavaScript, até 2023 foram economizados mais de 10 mil anos de tempo de espera dos usuários, e em 2024 o total chegou a 30 mil anos economizados
• Em 2024, o FID foi substituído pelo INP, e mudanças contínuas como a introdução da Soft Navigation API para SPAs mostram a evolução constante do ecossistema em direção a uma web rápida, estável e centrada no usuário

---

Contexto e motivação: do AMP para métricas da web aberta

• O Google destacou por anos a velocidade e a experiência do usuário como princípios centrais da web, mas muitos sites ainda ofereciam uma experiência lenta
• Em 2010, o Google Search começou a usar a velocidade do site como sinal de ranqueamento, numa das primeiras tentativas de incorporar desempenho ao SEO
• Por volta de 2015, foi introduzido o projeto AMP (Accelerated Mobile Pages), que oferecia páginas otimizadas para carregamento rápido, mas trouxe problemas de abertura e flexibilidade por funcionar como um ambiente fechado servido a partir do cache do Google
• Em 2018, com o Speed Update, a velocidade da página passou a influenciar o ranqueamento na busca mobile, e o Google Ads também passou a adotar pontuação de velocidade para páginas de destino mobile, reforçando que experiências mais rápidas trazem melhores taxas de conversão
• Para sair de uma abordagem voltada apenas ao AMP, as equipes do Chrome e do Search passaram a colaborar na definição de métricas abertas de desempenho da web aplicáveis a qualquer página sem exigir frameworks especiais
  • Analisaram milhões de páginas para definir um padrão público para páginas web rápidas e amigáveis ao usuário
  • Estabeleceram como objetivo métricas mensuráveis em campo que refletissem a experiência real dos usuários
  • Buscaram métricas com correlação com resultados como engajamento do usuário

Definição dos Core Web Vitals: os três pilares da experiência do usuário

• Em maio de 2020, o Google anunciou oficialmente a iniciativa Web Vitals, introduzindo os Core Web Vitals com foco em “aspectos essenciais da experiência do usuário aplicáveis a todas as páginas da web”

• Os Core Web Vitals iniciais eram compostos por três métricas principais

  • Largest Contentful Paint (LCP): uma métrica de velocidade de carregamento que mede o momento em que o conteúdo principal é renderizado, indo além do First Contentful Paint ou do onload e focando no instante em que o usuário realmente vê conteúdo significativo
  • First Input Delay (FID): uma métrica de responsividade à interação que mede o atraso entre a primeira interação do usuário e a resposta do navegador, capturando se a página reage imediatamente ou se há atraso por causa de scripts pesados
  • Cumulative Layout Shift (CLS): uma métrica de estabilidade visual que mede o quanto o layout da página se desloca durante o carregamento; ela soma mudanças inesperadas de layout, e um CLS baixo indica uma experiência estável e confortável

• A seleção das métricas foi baseada em ampla pesquisa e experimentação

  • Amar Sagoo, Annie Sullivan, Vivek Sekhar e outros identificaram, por meio de pesquisa em interação humano-computador, a correlação entre números objetivos de desempenho e a percepção dos usuários
  • O ideal seria tempo de carregamento em 2 a 3 segundos, resposta a entrada em até 100 ms e mínimo deslocamento de layout
  • Com base na análise de dados reais de usuários, foram definidos limiares práticos: LCP abaixo de 2,5 segundos, FID abaixo de 100 ms e CLS abaixo de 0,1 (no 75º percentil)
  • Páginas que atendem a esses limiares têm 24% menos probabilidade de abandono por parte dos usuários

• O Google se esforçou para tornar essas métricas padronizadas e abertas

  • Publicou rascunhos de especificações web por meio do WICG e de grupos de padrões de desempenho web
  • Implementou medições no Chrome e em outros navegadores por meio da API PerformanceObserver
  • Em maio de 2020, lançou a biblioteca JavaScript open source web-vitals, que desenvolvedores podem inserir em seus sites para medir LCP, FID e CLS de usuários reais
  • Addy Osmani desenvolveu a extensão Core Web Vitals, que exibe as métricas em tempo real
  • Isso reflete um esforço amplo para torná-las acessíveis e úteis em todo o ecossistema

Page Experience: Core Web Vitals no ranqueamento do Google Search

• A equipe do Google Search adotou rapidamente os Core Web Vitals como parte da atualização Page Experience

• Em 28 de maio de 2020, o Google Search Central anunciou que essas métricas seriam incluídas no algoritmo de ranqueamento

  • Quando duas páginas têm relevância de conteúdo semelhante, a página que oferece melhor experiência ao usuário pode ficar melhor posicionada
  • Os sinais de Page Experience combinam os Core Web Vitals com sinais de UX já existentes, como compatibilidade com dispositivos móveis, segurança HTTPS e ausência de intersticiais intrusivos
  • Conteúdo excelente continua sendo o fator mais importante, e um site rápido não supera um site mais relevante apenas por causa da velocidade
  • Em casos de empate ou diferenças pequenas, bons Web Vitals podem se tornar decisivos

• O anúncio mais notável foi a remoção da exigência de AMP no carrossel Top Stories

  • Antes, no mobile, o Google News/Top Stories exigia AMP, mas após a atualização Page Experience, páginas que não usam AMP também puderam ser incluídas se atendessem aos Core Web Vitals e a outros critérios
  • “O AMP não é mais obrigatório para o Top Stories no mobile, que passa a ficar aberto a qualquer página com boa experiência de página”
  • Isso demonstrou a confiança do Google em incentivar melhorias na web aberta sem depender de direcionar tudo para o framework AMP

• O Google deu aviso prévio suficiente ao ecossistema

  • Reconhecendo que 2020 foi um ano difícil por causa da pandemia de COVID-19, anunciou que a mudança de ranqueamento não seria aplicada até 2021, prometendo pelo menos seis meses de antecedência
  • Em uma atualização de novembro de 2020, informou que as mudanças de ranqueamento da Page Experience começariam em maio de 2021
  • No fim, a atualização Page Experience começou a ser implementada em meados de junho de 2021 e foi totalmente concluída até o fim de agosto (na busca mobile)
  • Uma atualização semelhante para a busca em desktop aconteceu entre fevereiro e março de 2022

• Com a aplicação da atualização, o algoritmo de ranqueamento do Google passou a usar os Core Web Vitals como um entre centenas de sinais

  • Páginas que atingem o limiar “bom” em todas as três métricas de CWV são consideradas como tendo boa experiência de página
  • O Google criou no Google Search Console um relatório de Page Experience, permitindo que donos de sites verifiquem, com dados do Chrome UX Report, a proporção de páginas que passam nos limiares
  • Isso ofereceu a webmasters e especialistas em SEO feedback direto sobre como seus sites estavam se saindo do ponto de vista dos sinais de experiência de página

• O Google considerou exibir um selo para páginas com boa experiência nos resultados de busca, mas nenhum ícone permanente foi adicionado

  • A recompensa veio principalmente na forma de ganho de ranqueamento, e não de um rótulo explícito
  • Durante algum tempo, o Google exibiu indicadores temporários de “Page Experience” no Search Console e em experimentos nos resultados de busca
  • Ponto principal: o Google vem incentivando publicamente desempenho e UX, e atingir bons Core Web Vitals não apenas satisfaz os usuários, como também pode melhorar a visibilidade da página na busca

Ferramentas e dados: Chrome UX Report e medição de desempenho

• O Google fez um grande investimento em ferramentas e dados para os Web Vitals

• O Chrome UX Report (CrUX) foi o núcleo desse esforço

  • Um conjunto de dados público de métricas de experiência real de usuários existente desde 2017, que coleta dados de desempenho anonimizados de milhões de sites a partir de milhões de usuários do Chrome
  • No lançamento dos Core Web Vitals, o CrUX começou imediatamente a reportar LCP, FID e CLS para todas as URLs de origem no conjunto de dados
  • Qualquer pessoa pode consultar dados de desempenho de campo
  • Após oferecer acesso via BigQuery, o Google lançou a CrUX API e o CrUX Dashboard, permitindo que desenvolvedores e profissionais de SEO verifiquem facilmente como seus sites (ou os de concorrentes) se saem nas métricas de CWV em campo
  • A introdução da CrUX History API passou a fornecer dados em série temporal dessas métricas, tornando possível acompanhar o progresso ao longo de vários meses

• No lado das ferramentas para desenvolvedores, a integração avançou rapidamente

  • Até o fim de 2020, a maioria das ferramentas de performance do Google foi atualizada para destacar os Core Web Vitals
  • O Lighthouse (ferramenta de auditoria open source usada no Chrome DevTools e no PageSpeed Insights) integrou diagnósticos e pontuações relacionados a CWV
    • Adicionou auditorias como “o Largest Contentful Paint foi de X segundos (meta <2,5 segundos)” e oferece sugestões de melhoria
  • O Chrome DevTools ganhou um painel de Core Web Vitals e marcadores na linha do tempo, permitindo ver o elemento de LCP ou mudanças de layout durante o carregamento da página
  • O PageSpeed Insights (PSI) foi totalmente reformulado para focar em CWV
    • Exibe com destaque no topo os dados de campo de LCP, FID (mais tarde INP) e CLS vindos do CrUX
  • O Google Search Console oferece um relatório dedicado de Core Web Vitals que agrupa páginas em categorias “bom”, “precisa de melhorias” e “ruim” para cada métrica, permitindo que proprietários de sites identifiquem com precisão as áreas problemáticas
  • O trabalho nas ferramentas foi liderado por Elizabeth Sweeny, Paul Irish, Addy Osmani e outros

• A comunidade de desenvolvimento web também respondeu com ferramentas de terceiros

  • Provedores de serviços de Real User Monitoring (RUM) integraram rapidamente os Core Web Vitals
  • mPulse da Akamai, Browser agent da New Relic, Dynatrace, Datadog, SpeedCurve e outros passaram a oferecer suporte imediato a LCP, FID e CLS como métricas de primeira classe
  • A Cloudflare também lançou o serviço Browser Insights, capaz de coletar Web Vitals por meio da inserção de script
  • Com a existência da biblioteca JS web-vitals, qualquer ferramenta de analytics pôde coletar essas métricas com facilidade
  • Em 2021, os Core Web Vitals já eram comuns nos dashboards de ferramentas de monitoramento de performance web
  • Essa ampla disponibilidade ampliou a conscientização e forneceu aos desenvolvedores dados para liderar melhorias de performance

• Os dados do Chrome User Experience Report também foram essenciais para acompanhar o progresso em toda a web

  • Ao longo de 2021 e 2022, a proporção de tráfego com CWV “bons” aumentou de forma constante
  • Isso foi frequentemente relatado no Web Almanac anual do HTTP Archive e em atualizações do próprio blog do Google
  • Ter métricas mensuráveis e publicamente visíveis criou uma espécie de competição virtuosa
  • Proprietários de sites e provedores de plataformas começaram a se esforçar para melhorar os Core Web Vitals e a se orgulhar disso

Impacto e melhorias: tornando a web mais rápida e estável

Otimização do navegador Chrome

• Depois que os Core Web Vitals se consolidaram, foi desencadeado um grande esforço multifacetado em todo o ecossistema web para melhorar essas métricas

• A equipe de engenharia do Google Chrome analisou o navegador em profundidade para otimizar a forma como o Chrome carrega e renderiza páginas da web

  • Considerando a enorme base de usuários do Chrome, mesmo pequenas melhorias no nível do navegador trazem benefício para toda a web
  • Isso inclui otimizações importantes lançadas no Chrome entre 2020 e 2023

• Priorização de conteúdo para LCP

  • O Chrome foi alterado para priorizar o carregamento de conteúdo importante
  • Ele identifica as primeiras imagens do HTML (muitas vezes incluindo a imagem de LCP) e atribui a elas maior prioridade de rede
  • Priorizar assim as cinco primeiras imagens melhorou o LCP em algumas páginas de 3,1 segundos para 2,5 segundos
  • Novos padrões da web, como o atributo fetchpriority (mecanismo Priority Hints), foram introduzidos para que desenvolvedores possam marcar imagens ou iframes com alta prioridade para LCP

• Back/Forward Cache (BFCache)

  • Historicamente, o Chrome não armazenava páginas completamente no BFCache devido à complexidade técnica, mas nos últimos anos passou a ativar o BFCache para muitas páginas
  • Até 2023, alcançou um aumento notável na taxa de acerto do BFCache tanto no desktop quanto no Android
  • Usuários que voltam para uma página com “voltar” conseguem vê-la instantaneamente (LCP zero, atraso de entrada zero, porque a página não foi descarregada)
  • Grandes plataformas como a Amazon se beneficiaram do BFCache do Chrome e, após melhorias do Chrome (versão M112), relataram um aumento de 22,7 p.p. no uso do cache de voltar/avançar

• Prerendering (NoState Prefetch/Prerender2)

  • O Chrome lançou um novo prerenderizador (Prerender2) que permite ao navegador carregar e renderizar completamente uma página em segundo plano e então trocá-la instantaneamente quando o usuário navega
  • Inicialmente, ele foi usado no Google Search (pré-renderização dos principais resultados) e na previsão de URLs digitadas, podendo reduzir o LCP de forma dramática
  • O Chrome informou que o pré-rendering de buscas na omnibox oferece uma melhoria mediana de 500~700 ms (cerca de 15~25%) no LCP nessas navegações
  • O Chrome está fazendo esse rollout com cuidado (para evitar previsões erradas ou problemas de privacidade)

• Otimizações de rede e agendamento

  • A equipe do Chrome identificou e resolveu vários pequenos atrasos na responsividade a entradas
  • Foi introduzido o recurso de pré-conexão no pointer down (ao iniciar um toque/clique, antes de soltar), reduzindo alguns milissegundos na configuração de conexão para navegação por links
  • Isso proporcionou um LCP em média cerca de 6~10 ms mais rápido em navegações entre origens diferentes
  • Também foi melhorada a forma como a thread principal do navegador processa tarefas quando várias abas estão abertas, reduzindo a contenção
  • Com ajustes no agendamento de tarefas e o uso de mecanismos como o EcoQOS do Windows 11 para abas em segundo plano, o Chrome melhorou o INP em cerca de 5% e o LCP em cerca de 2% em cenários de carga intensa

• Melhorias no mecanismo de renderização e JavaScript

  • A reformulação da arquitetura RenderingNG do Chrome (concluída por volta de 2021) tornou a renderização mais eficiente
  • Upgrades na prioridade de carregamento de imagens (para que imagens de LCP não fiquem bloqueadas atrás de outras tarefas menos importantes) e um timing mais inteligente para o garbage collection do V8 (executado durante períodos de ociosidade) garantiram uma experiência mais suave
  • Desenvolvedores do Chrome descobriram que a forma como o navegador multiprocessado acessava cookies causava jank
    • Toda chamada a document.cookie precisava ser buscada de forma síncrona em outro processo
    • Ao introduzir controle de versão de memória compartilhada para cookies, o Chrome otimizou o acesso a cookies e eliminou muitos saltos redundantes entre processos
    • Isso reduziu o atraso de entrada quando sites abusavam de leituras de cookies em toda interação

• Todas essas otimizações no Chrome trouxeram uma diferença mensurável

  • Até o fim de 2023, o Google relatou que o carregamento médio de páginas no Chrome está 166 ms mais rápido do que antes da existência dos Core Web Vitals
  • O impacto em toda a web foi enorme: somando o tempo economizado, a equipe do Chrome calculou que, só em 2023, as melhorias de velocidade pouparam aos usuários mais de 10.000 anos de espera pelo carregamento de páginas, além de mais 1.200 anos de espera para que as páginas respondessem à entrada
  • A proporção de tráfego que atende ao critério "bom" dos CWV também subiu bastante
  • Quando foram anunciados pela primeira vez, cerca de 1/3 dos carregamentos de página eram considerados bons pelos critérios dos CWV, mas em 2023 cerca de 68% das visitas a páginas no desktop e 64% no mobile no Chrome já atendiam aos três limites dos CWV

Melhorias amplas no ecossistema da web

• As melhorias não vieram apenas do lado do Google; a comunidade mais ampla de desenvolvedores web, frameworks e fornecedores de plataformas também entrou em ação para resolver os problemas de desempenho identificados pelos Core Web Vitals

• Otimização de imagens e lazy loading

  • Reconhecendo que as imagens costumam ser o maior conteúdo e uma causa comum de LCP, frameworks web e CMSs passaram a implementar padrões mais inteligentes por padrão
  • O loading="lazy" nativo do HTML para imagens fora da tela foi padronizado (com ajuda do Chrome e de contribuidores de padrões web como Yoav Weiss e Addy Osmani) e adotado pelo WordPress e outras plataformas, reduzindo drasticamente o carregamento desnecessário de imagens
  • Depois que o WordPress ativou o lazy loading de imagens por padrão em 2020, ele foi ajustado para não aplicar lazy loading à primeira imagem de banner, para que o LCP não fosse prejudicado
  • O novo atributo <img fetchpriority="high"> foi rapidamente aproveitado por frameworks para destacar a imagem principal e acelerar o carregamento

• WordPress Performance Team

  • Como o WordPress responde por cerca de 40% de todos os sites, seu desempenho tem um impacto enorme
  • No início, os sites em WordPress estavam ficando para trás nas pontuações de CWV, e um relatório de 2021 mostrou que a taxa de aprovação dos sites em WordPress era menor do que em alguns outros ecossistemas, o que soou o alerta
  • A comunidade respondeu criando uma Core Performance Team dedicada (com contribuidores do Google e de outras empresas) para melhorar sistematicamente a velocidade do núcleo do WordPress
  • O trabalho trouxe resultados nas versões mais recentes
    • O WordPress 6.3 (2023) incluiu inúmeras otimizações na renderização de temas e no carregamento de assets, oferecendo temas principais que carregam 27% mais rápido para temas de bloco e 18% mais rápido para temas clássicos em comparação com o WordPress 6.2, com base na métrica de LCP
    • Na prática, milhões de sites ficaram mais rápidos apenas ao atualizar o WordPress
  • A equipe do WordPress otimizou o processamento de imagens, adicionou cache para algumas tarefas particularmente custosas e passou a tratar desempenho com a mesma prioridade que novos recursos
  • Como resultado, a proporção de sites WordPress com boas pontuações de CWV aumentou drasticamente (alguns dados mostram que a proporção de sites WP que atendem a todos os CWV mais que quadruplicou entre 2020 e 2022)

• Wix e criadores de sites

  • Outras plataformas hospedadas de criação de sites, como Wix, Squarespace e Duda, também usaram os Core Web Vitals como gatilho para melhorar o desempenho
  • A Wix realizou grandes mudanças de infraestrutura (cache, servidores mais rápidos e código client-side melhor) e multiplicou a proporção de sites Wix que alcançam boas pontuações de CWV
  • Em um estudo de caso, a Wix relatou ter elevado a proporção de sites com CWV "bom" de 4% para mais de 33% em cerca de um ano
  • Isso demonstrou que uma mudança cultural orientada a desempenho em uma plataforma pode beneficiar um número enorme de usuários
  • Outros criadores, como a Duda, também costumam anunciar que a maioria dos sites de seus clientes atinge bons CWV, porque essas plataformas incorporaram boas práticas por padrão (imagens responsivas, entrega via CDN, templates eficientes etc.)
  • Essa pressão competitiva fez com que as plataformas impulsionassem melhorias internamente, mesmo que os proprietários individuais dos sites não fossem especialistas em desempenho

• Frameworks JavaScript (Chrome Aurora)

  • A equipe Chrome Aurora foi lançada em meados de 2020 como uma força-tarefa especial dentro do Chrome para colaborar com frameworks JavaScript populares
  • Membros da Aurora (Addy Osmani, Kara Erickson, Houssein Djirdeh e outros) trabalharam de perto com autores de frameworks como React/Next.js, Angular, Nuxt e Gatsby para identificar gargalos comuns e oferecer soluções
  • Dessa colaboração surgiram recursos como
    • o componente next/script do Next.js (para carregar scripts de terceiros com mais eficiência fora da main thread)
    • a diretiva embutida NgOptimizedImage do Angular (que aplica lazy loading automático em imagens e define tamanho e prioridade adequados)
    • o módulo de otimização do Google Fonts no Nuxt
  • O impacto foi significativo: em 2022, a pontuação mediana de Core Web Vitals de sites construídos com esses frameworks melhorou visivelmente
    • a taxa de aprovação em CWV de sites em Next.js foi de 20,4% para 27,3%
    • a do Angular foi de 7,6% para 13,2%
    • e a do Nuxt melhorou de 15,8% para 20,2%
  • Também houve muitos casos de sucesso individuais
    • o site de e-commerce Land's End obteve uma melhora de 40% no LCP em dispositivos móveis (em testes de laboratório) após adotar a otimização de imagens do Angular
    • a CareerKarma reduziu o LCP em 24% ao usar o carregamento de scripts aprimorado do Next.js

• Métricas reais de negócio

  • No fim das contas, Core Web Vitals melhores não servem apenas para agradar o Google, mas se correlacionam com satisfação real do usuário e resultados de negócio
  • Muitas empresas compartilharam estudos de caso ligando melhorias em CWV ao engajamento dos usuários
    • o site de notícias Economic Times otimizou o processamento de scripts, melhorou o INP e alcançou 42% mais pageviews e 49% menos taxa de rejeição
    • o site de reservas de viagem RedBus melhorou o INP e confirmou um aumento de 7% na taxa de conversão
    • o marketplace online indiano Meesho reduziu o LCP de 6,9 segundos para 2,5 segundos e conseguiu cerca de 17% menos taxa de rejeição e 3% mais conversão
  • Esses exemplos reforçam que desempenho não é apenas uma métrica técnica, mas algo que se traduz em usuários permanecendo mais tempo, lendo mais e comprando mais
  • Esses casos de sucesso motivaram ainda mais desenvolvedores e equipes de produto a priorizar os Web Vitals

Resultados das melhorias em todo o ecossistema

• O esforço combinado de equipes de navegadores, autores de frameworks, desenvolvedores de CMS e incontáveis desenvolvedores web individuais melhorou dramaticamente o estado da web
• Ao estabelecer métricas claras e acionáveis, os Core Web Vitals criaram um objetivo comum que todos podiam seguir
• Importante: isso foi alcançado usando padrões abertos e dados, sem prender o ecossistema a tecnologia proprietária
• Em 2023, cerca de 40% dos sites (e uma proporção muito maior entre sites comerciais e bem mantidos) já passavam em todos os limites dos Core Web Vitals, enquanto no começo de 2020 apenas uma minoria conseguia isso
• Mesmo os sites que ainda não passam completamente, em geral, já ficaram mais rápidos e mais suaves do que antes
• A cultura de conscientização sobre desempenho se espalhou: os desenvolvedores monitoram cada vez mais as métricas de CWV (segundo pesquisas, cerca de 51% dos desenvolvedores acompanham e otimizam ativamente os Web Vitals)
• O Google observou que, apesar de ter impulsionado essas melhorias de velocidade, a satisfação dos desenvolvedores com a plataforma web permaneceu alta
  • Isso indica que as diretrizes eram alcançáveis, em vez de levar os desenvolvedores ao desespero
  • Esse equilíbrio foi importante: se as metas de CWV fossem impossíveis ou as ferramentas fossem insuficientes, os desenvolvedores poderiam ter reagido negativamente, mas em vez disso a comunidade se uniu para tornar a web melhor

Evolução das métricas: INP, Soft Navigation etc.

• Desde o início, o Google reconheceu que os Core Web Vitals evoluiriam com o tempo
• O conjunto de três métricas de 2020 não foi pensado para ser estático nem completo
• Outros aspectos da experiência do usuário, como rolagem suave ou tarefas longas no fim da página, não foram abordados no início
• A equipe Chrome Web Platform continua pesquisando novas métricas e melhorias nas métricas existentes

Interaction to Next Paint (INP)

• A lacuna mais clara dos CWV originais era a interatividade além do primeiro clique
• O FID media apenas o atraso da primeira entrada, o que é importante para a primeira impressão, mas a página ainda podia deixar de responder depois, durante outras interações do usuário
• Para resolver isso, Googlers como Annie Sullivan e Michal Mocny propuseram o INP
  • observar todas (ou pelo menos muitas) as interações do usuário na página e reportar uma espécie de pior caso, ou o atraso no 98º percentil
  • fazendo a pergunta: "quanto tempo leva, quando o usuário interage com a página em qualquer momento, até que o próximo frame seja renderizado como resposta?", capturando a latência do processamento de eventos e da renderização
• O INP foi lançado em 2022 como uma métrica experimental de campo e passou a ser coletado no CrUX
• Até o começo de 2023, o Google descobriu que o INP previa melhor os problemas gerais de responsividade do que o FID
• Por isso, anunciou que, em março de 2024, o INP substituiria o FID como Core Web Vital
  • essa mudança foi comunicada aos desenvolvedores com bastante antecedência
  • ferramentas como Lighthouse e PageSpeed Insights passaram a exibir o INP (e marcá-lo como "em breve como CWV")
  • o Web.dev passou a fornecer orientações para melhorar o INP, o que muitas vezes resulta nas mesmas práticas gerais de desempenho: dividir tarefas longas, usar web workers para cálculos pesados etc.
• A transição de FID para INP destaca a filosofia da equipe de CWV de iterar nas métricas para cobrir melhor o que é mais importante
  • neste caso, garantir responsividade consistente ao longo de toda a visita do usuário, e não apenas no carregamento da página

Suavidade e animação

• Outro aspecto investigado pela equipe do Chrome é a suavidade visual, como taxa de quadros de animação e jank na rolagem
• Ainda não existe uma métrica CWV oficial para isso, mas há trabalho em andamento nessa área
• A equipe do Chrome forneceu às ferramentas de RUM uma métrica de Smoothness (às vezes reportada no CrUX como "Jankiness") para quantificar coisas como animações travando
• Heurísticas foram introduzidas no navegador para reduzir jank
  • por exemplo, ajustando a forma como eventos de toque são sincronizados com os frames da tela para dobrar a suavidade da rolagem do próprio Chrome no Android (explicado em detalhes no post Fast and Curious de agosto de 2023)
• No futuro, pode surgir um Web Vital oficial de "smoothness", ou o INP pode ser expandido para cobrir certos atrasos de animação
• O ponto principal é que o Google reconhece esses aspectos e está experimentando ativamente com eles

Soft Navigation (SPA)

• Uma limitação das definições iniciais de CWV era o foco em carregamentos completos de página (as chamadas "hard navigations")
• No entanto, aplicações modernas de página única (SPA) frequentemente carregam uma vez e depois atualizam conteúdo e rotas dinamicamente, sem recarregar tudo
• Essas soft navigations (quando clicar em um link altera o conteúdo via JavaScript sem realizar uma navegação completa do navegador) não eram capturadas pela medição de LCP ou CLS na implementação original
  • do ponto de vista do navegador, ainda era a mesma página, então uma grande atualização do DOM não disparava um novo LCP
• Isso significava que, no caso das SPAs, os desenvolvedores precisavam depender de medições personalizadas para avaliar as "transições de página" dentro do app, e os dados de campo do CrUX também ficavam cegos para essas navegações subsequentes (registrando apenas os CWV do carregamento inicial da página)
• Para corrigir isso, o Chrome propôs a Soft Navigation API
  • todo o mérito desse trabalho vai para Yoav Weiss
  • em meados de 2023, o Chrome começou experimentos para detectar navegações de SPA por heurística
  • até meados de 2025, foi lançado um origin trial para a Soft Navigations API
• Como explicam os engenheiros do Chrome Barry Pollard e Michal Mocny, uma soft navigation é "quando o JavaScript intercepta a navegação (por exemplo, via History API ou roteador do framework) e atualiza a URL com history.pushState sem recarregamento completo, enquanto atualiza o conteúdo da página existente"
• Com a nova API, o navegador (e os desenvolvedores) pode marcar esses eventos e, essencialmente, tratá-los como uma nova visualização de página
• De forma crucial, isso permite medir Core Web Vitals em SPAs como se essas mudanças de rota soft fossem carregamentos de página
• Com a API, métricas como LCP podem ser redefinidas em uma soft navigation e capturar o maior conteúdo da nova visualização (usando o conceito de entradas "interaction-to-next-paint" na Performance Timeline)
• Da mesma forma, o CLS pode ser dividido por navegação, e o INP pode ser associado à visualização atual
• Isso é um grande avanço para levar os CWV ao mundo dos apps com roteamento no lado do cliente, que são extremamente comuns
• No fim de 2025, a Soft Nav API ainda está em trial, e os desenvolvedores podem aderir e enviar feedback
• Com o tempo, espera-se que o Chrome ofereça suporte total às métricas de soft nav e que os dados de campo (CrUX) também as integrem
• Essa evolução reconhece que a jornada do usuário é composta por várias etapas, não apenas pelo carregamento da página de entrada, e que a plataforma web precisa medir e otimizar a jornada completa

Evolução futura

• O Google indicou que continuará melhorando as métricas todos os anos
• Podemos ver ajustes como novos limites
  • por exemplo, se a web ficar universalmente mais rápida, no futuro a meta de um LCP "bom" pode ficar mais rígida do que 2,5 segundos
  • ou métricas totalmente novas, se surgir uma lacuna evidente
• Todas as adições passam por um processo público (definição nos padrões de desempenho web, discussões com outros fornecedores de navegador etc.), como aconteceu com o INP
• O Google planeja integrar mais sinais de experiência de página ao longo do tempo
  • por exemplo, experimentos de privacidade e segurança, como mostrar um selo de "página rápida" no Chrome quando um site usa boas práticas
• Porém, no contexto de ranking da Busca, o Google simplificou recentemente sua mensagem
  • até 2023, afirmou que não haveria um reforço explícito de ranking de "experiência de página" além dos sinais individuais
  • essencialmente, integrou as considerações de experiência de página de forma mais sutil ao algoritmo principal de ranking
  • mas, da perspectiva dos proprietários de sites, nada muda
  • páginas rápidas, responsivas e estáveis continuam sendo fundamentalmente importantes tanto para a satisfação do usuário quanto para um bom SEO

Resumo

• A história dos Core Web Vitals é a história de como a plataforma web enfrentou o desafio
  • começou com a percepção de que a qualidade da experiência do usuário deveria ser mensurável e recompensada e se transformou em um movimento amplo que afetou métricas, navegadores, ranking de busca, ferramentas, frameworks e plataformas de hospedagem
  • em poucos anos, impulsionou melhorias significativas em todo o desempenho da web
  • a jornada continua: com inovações futuras, como a medição de soft navigation para SPAs e o refinamento contínuo das métricas, o compromisso do setor com experiências web rápidas e agradáveis segue forte
• Os Core Web Vitals provaram ser não apenas um conjunto de métricas, mas um catalisador para uma web mais saudável, mais rápida e centrada no usuário
  • um legado construído pela colaboração de muitas pessoas, e um legado que beneficiará todos que usam a web