Core Web Vitals 2024: O Google mudou as regras e você provavelmente ainda está otimizando errado

Em março de 2024, o Google fez uma mudança silenciosa que deveria ter acordado todo PM e dev que trabalha com performance web: o First Input Delay (FID) deixou de existir como Core Web Vital. No lugar dele, entrou o Interaction to Next Paint (INP).

A mudança não foi novidade para quem acompanha. O Google avisou com um ano de antecedência. Mas na prática, é comum encontrar times que ainda mencionam FID em reuniões de performance ou usam dashboards configurados para uma métrica que o Google nem considera mais.

Isso não é só desatualização técnica. É desperdício de esforço em otimizações que não movem mais a agulha do ranqueamento.

O que realmente mudou nos Core Web Vitals

Os Core Web Vitals são três métricas que o Google usa como sinais de experiência do usuário para ranqueamento. Antes de março de 2024, eram:

• LCP (Largest Contentful Paint): tempo até o maior elemento visível carregar
• FID (First Input Delay): tempo entre a primeira interação e a resposta do navegador
• CLS (Cumulative Layout Shift): estabilidade visual da página

Agora são:

• LCP — continua igual
• INP (Interaction to Next Paint) — substitui o FID
• CLS — continua igual

A diferença entre FID e INP parece sutil, mas muda completamente o que você precisa otimizar.

Por que o FID era uma métrica fraca

O FID media apenas a primeira interação do usuário. Clicou em um botão? O FID registrava o delay até o navegador começar a processar esse clique.

O problema: a maioria dos sites passava no FID com folga. Dados do Google mostravam que 93% das páginas já atingiam o threshold de “bom” (abaixo de 100ms). Era uma métrica fácil demais de passar.

Pense em um e-commerce: o usuário carrega a página (LCP ok), clica no primeiro produto (FID ok), mas quando tenta adicionar ao carrinho, filtrar por preço ou navegar entre páginas, tudo trava. O FID não via nada disso.

O que o INP mede de diferente

O INP (Interaction to Next Paint) considera todas as interações do usuário durante a sessão, não só a primeira. E mede o tempo até o próximo frame visual ser renderizado — ou seja, até o usuário ver uma resposta na tela.

O threshold mudou:

• Bom: até 200ms
• Precisa melhorar: 200ms a 500ms
• Ruim: acima de 500ms

Parece mais generoso que os 100ms do FID, mas na prática é muito mais difícil de atingir. Porque agora você precisa garantir responsividade consistente em toda a jornada, não só no primeiro clique.

FID (aposentado)

• Mede só a primeira interação
• Threshold de 100ms
• 93% dos sites já passavam
• Ignorava travamentos subsequentes
• Fácil de otimizar pontualmente

INP (atual)

• Mede todas as interações
• Threshold de 200ms
• Muito menos sites passam
• Captura a experiência completa
• Exige performance consistente

O impacto real para sites brasileiros

Nos projetos que audito, o padrão é claro: sites que passavam tranquilamente no FID estão falhando no INP.

Os culpados mais comuns:

JavaScript pesado em interações secundárias. O script de analytics carregava depois da primeira interação, então não afetava o FID. Mas quando o usuário clica em outros elementos, esse script já está competindo por recursos. O INP pega isso.

Frameworks client-side mal configurados. React, Vue, Angular — qualquer SPA que não gerencia bem hidratação e re-renders vai sofrer com INP. O primeiro render pode ser ok, mas cada interação subsequente dispara reconciliação de estado que bloqueia a main thread.

Third-party scripts acumulados. Chat widgets, pixels de remarketing, ferramentas de A/B testing. Cada um sozinho parece inofensivo. Juntos, criam um backlog de tarefas que o navegador precisa processar a cada interação.

Animações e transições não otimizadas. CSS transitions que forçam layout recalculation. Carrosséis que não usam will-change. Modais que bloqueiam a thread principal ao abrir.

Como diagnosticar se você tem problema com INP

Antes de sair otimizando, você precisa saber se tem um problema real. E onde ele está.

• Verifique o relatório de Core Web Vitals no Search Console — os dados são de usuários reais
• Use o PageSpeed Insights com URL de páginas de alto tráfego, não só a home
• Instale a extensão Web Vitals do Chrome e navegue pelo site como um usuário faria
• Analise o Chrome DevTools > Performance para identificar long tasks durante interações
• Confira se seu RUM (Real User Monitoring) está capturando INP, não só FID

O Search Console é a fonte mais confiável porque usa dados de campo (usuários reais), não dados de laboratório (testes automatizados). Muitos sites passam no Lighthouse mas falham no INP de campo porque os testes sintéticos não simulam a diversidade de dispositivos e conexões do Brasil.

O que otimizar primeiro

Se você descobriu que tem problema com INP, a priorização importa. Não é sobre fazer tudo — é sobre fazer o que move o número.

1. Identifique as interações problemáticas

Use o DevTools para gravar uma sessão de uso real. Procure por “long tasks” (tarefas acima de 50ms) que acontecem durante cliques e toques. O INP é determinado pelo pior caso (ou próximo dele), então você precisa achar os outliers.

2. Quebre tarefas longas de JavaScript

Se uma função roda por 300ms, o navegador não consegue responder a nada nesse tempo. A solução é quebrar em chunks menores usando requestIdleCallback, setTimeout ou a API Scheduler do navegador. O usuário não precisa que tudo termine — precisa ver que algo está acontecendo.

3. Reduza o impacto de third-party scripts

Carregue scripts não essenciais com defer ou async. Considere carregar alguns apenas após a primeira interação. Widgets de chat, por exemplo, raramente precisam estar prontos no primeiro segundo.

4. Otimize event handlers

Handlers que fazem muito trabalho síncrono são os principais vilões. Mova lógica pesada para web workers quando possível. Use debounce em eventos de scroll e resize. Evite forçar layout synchronization (ler propriedades de layout logo depois de modificar o DOM).

5. Revise sua estratégia de hidratação

Se usa SSR com frameworks como Next.js ou Nuxt, a hidratação pode estar bloqueando interações. Técnicas como partial hydration, progressive hydration ou island architecture reduzem drasticamente o INP em SPAs.

O erro de otimizar para Lighthouse em vez de usuários reais

É comum ver times comemorando score 100 no Lighthouse enquanto o Search Console mostra INP vermelho.

Dados de laboratório (Lighthouse, PageSpeed Insights em modo lab) são úteis para desenvolvimento. Mas o Google usa dados de campo (CrUX - Chrome User Experience Report) para ranqueamento. São coisas diferentes.

Se você só olha Lighthouse, está otimizando para um cenário que não representa seus usuários.

Quando INP não deveria ser sua prioridade

Performance é importante, mas contexto importa mais.

Se seu site é majoritariamente conteúdo estático (blog, institucional, documentação), o INP provavelmente já está bom. Não há muitas interações complexas para medir. Seu esforço rende mais em LCP e CLS.

Se você está em um mercado onde concorrentes também têm INP ruim, a vantagem competitiva pode estar em outro lugar. O Google usa Core Web Vitals como critério de desempate, não como fator dominante. Conteúdo relevante ainda ganha de página rápida com conteúdo fraco.

Se seu tráfego vem majoritariamente de canais que não são busca orgânica (paid, social, email), otimizar INP para SEO pode não ser a alavanca certa.

Não estou dizendo para ignorar performance. Estou dizendo para priorizar com base no seu contexto, não em boas práticas genéricas.

O que muda na sua estratégia

A substituição do FID pelo INP não é só uma troca de métrica. É uma mudança de mentalidade sobre o que significa performance.

Com FID, a pergunta era: “a página carrega rápido?” Com INP, a pergunta é: “a página responde rápido em toda a jornada?”

Isso tem implicações práticas:

• Code splitting se torna mais importante que bundle size total
• Lazy loading precisa ser mais inteligente para não causar delays em interações
• Third-party scripts precisam de auditoria contínua, não só na implementação inicial
• Testes de performance precisam simular jornadas completas, não só page load
• Monitoramento precisa capturar métricas de campo, não só checks sintéticos

Próximos passos concretos

Se você leu até aqui e percebeu que seu time ainda usa FID como referência, aqui está o que fazer amanhã:

1. Atualize seus dashboards e relatórios para mostrar INP no lugar de FID
2. Verifique o Search Console para entender seu INP atual em dados de campo
3. Identifique as 3 páginas de maior tráfego que estão com INP ruim
4. Para cada uma, rode o DevTools Performance em uma interação típica
5. Priorize as long tasks mais impactantes e crie tickets específicos

Não tente resolver tudo de uma vez. O INP é sobre consistência, não perfeição. Melhorar de “ruim” para “precisa melhorar” já tem impacto. Melhorar de “precisa melhorar” para “bom” é o objetivo, mas não precisa acontecer na primeira sprint.