Como otimizei o INP de uma página em produção para passar no Core Web Vitals

O INP (Interaction to Next Paint) é métrica estável do Core Web Vitals desde 2024 e substituiu o antigo FID. A diferença prática é dura: enquanto o FID media só o atraso da primeira interação, o INP observa todas as interações (cliques, toques e teclas) ao longo da vida da página e reporta um valor único que cobre a grande maioria delas. Segundo a documentação do web.dev, 90% do tempo do usuário numa página acontece depois do carregamento, então é aí que a responsividade↳Design responsivo4 conteúdosDicas de Front-End para usabilidade, acessibilidade, performance e responsividadeProduto & UX · fev 2025Tipos de layouts e suas diferençasProduto & UX · jan 2025Dica de ouro: Saiba como fazer uma navbar responsivaDev (Back & Front) · jun 2025Ver tudo em Produto & UX → importa de verdade.

Os limiares que você precisa bater, medidos no percentil 75 de campo, separados por mobile e desktop:

• Bom: INP ≤ 200 ms
• Precisa melhorar: entre 200 ms e 500 ms
• Ruim: acima de 500 ms

Uma página com INP de 380 ms no mobile foi o caso que me trouxe até este tutorial. Vou mostrar o caminho inteiro que fiz: medir, reproduzir, corrigir e validar.

Passo 1: medir o INP real com a biblioteca web-vitals

O INP é composto de três partes: input delay (tempo até o event handler começar a rodar), processing duration (tempo executando os callbacks) e presentation delay (tempo até o próximo frame ser pintado). Medir isso na unha, respeitando percentis, back/forward cache e a diferença entre a API de Event Timing e a métrica, é trabalhoso. Por isso usei a biblioteca oficial web-vitals.

npm install web-vitals

O ponto que me pegou de início: o console.log cru não me dizia qual interação estava lenta. A biblioteca resolve isso com a build de atribuição:

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const attr = metric.attribution;
  navigator.sendBeacon('/rum', JSON.stringify({
    inp: metric.value,
    rating: metric.rating,
    target: attr.interactionTarget,     // seletor do elemento
    type: attr.interactionType,          // 'pointer' ou 'keyboard'
    inputDelay: attr.inputDelay,
    processingDuration: attr.processingDuration,
    presentationDelay: attr.presentationDelay,
  }));
}, { reportAllChanges: false });

Um detalhe importante da documentação: entradas de evento abaixo de 104 ms não são reportadas por padrão pelos performance observers, e o INP só é finalizado quando a página vai para segundo plano ou é descarregada. A web-vitals já escuta o evento visibilitychange por baixo dos panos, então você não perde o valor final em abas de mobile que nunca disparam unload. Deixe o backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → calcular o p75 depois.

Enquanto o RUM não acumula dados, dá para ter um retrato rápido com o CrUX via PageSpeed Insights. O CrUX te diz se existe problema (e em qual dispositivo), mas não o que o causou. Foi o que confirmou meu 380 ms no mobile, sempre no clique de um filtro de listagem.

Passo 2: reproduzir o gargalo no Chrome DevTools

Com o alvo em mãos (o seletor vindo da atribuição), abri o painel Performance do DevTools. O truque para reproduzir INP fielmente:

1. Ative o CPU throttling em 4x slowdown (simula celular de entrada, onde o Brasil sente mais).
2. Comece a gravar, execute a interação problemática, pare a gravação.
3. Na trilha Interactions, o DevTools marca a interação e sua duração. Isso apareceu em vermelho no meu caso.

Abaixo, na trilha Main, apareciam as long tasks: qualquer tarefa acima de 50 ms no main thread, sinalizada com o triângulo vermelho no canto. No meu clique, o handler disparava uma re-renderização síncrona de 300+ itens da lista, tudo numa única task de ~290 ms. O main thread ficava travado e o navegador não conseguia pintar o frame de feedback, exatamente o que o vídeo do web.dev ilustra com o acordeão que abre e fecha sozinho porque o usuário clica várias vezes.

Um segundo vilão apareceu: um script de terceiros (tag de analytics) executando dentro do mesmo frame por conta de um listener global de click. Na trilha Main dá para ver a URL do arquivo e o nome da função no bottom-up.

Passo 3: aplicar as correções

Ataquei o processing duration, que era a maior fatia. Três técnicas resolveram.

Yield ao main thread. Em vez de processar tudo de uma vez, quebrei a tarefa e cedi o controle ao navegador para ele pintar o feedback primeiro:

function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }
  return new Promise((r) => setTimeout(r, 0));
}

async function handleFilterClick(items) {
  updateButtonState();      // feedback visual imediato
  await yieldToMain();      // deixa o browser pintar
  await renderInChunks(items);
}

O scheduler.yield() é preferível ao setTimeout(0) porque não manda a continuação para o fim da fila (não perde a vez para outras tasks). Onde não há suporte, o fallback com setTimeout já resolve o essencial.

Renderização em blocos. A lista passou a ser processada em pedaços de 50 itens, com await yieldToMain() entre eles. Nenhuma task individual passou de 50 ms.

Debounce no input. Havia também um campo de busca que disparava filtragem a cada tecla. Um debounce simples cortou o processing duration em digitação:

let t;
input.addEventListener('input', (e) => {
  clearTimeout(t);
  t = setTimeout(() => filtrar(e.target.value), 150);
});

Para o script de terceiros, movi a inicialização dele para depois da primeira interação relevante e adicionei { passive: true } onde cabia. Terceiros que você não controla, coloque para carregar via requestIdleCallback ou defira com a estratégia de facade quando possível.

Passo 4: validar a melhora antes e depois

Repeti a gravação no Performance com o mesmo throttling. A long task de 290 ms virou uma sequência de tarefas curtas, e a interação na trilha Interactions caiu para faixa verde. No lab, o INP simulado ficou em torno de 140 ms.

Mas lab não substitui campo. O ciclo honesto foi:

1. RUM em produção: o p75 do INP começou a cair já nas primeiras 48 horas de tráfego, medido pelos beacons da web-vitals.
2. Search Console: o relatório de Core Web Vitals consolida dados do CrUX e leva ~28 dias para refletir a janela móvel. A URL saiu de "Precisa melhorar" para "Bom" cerca de um mês depois. Não adianta olhar no dia seguinte: o CrUX é uma média corrida de 28 dias.
3. PageSpeed Insights: confirma o dado de origem e, quando há volume, dá o dado por URL.

O que ficou em aberto

Um ponto que a própria documentação alerta e que me mordeu: interações dentro de iframes contam para o INP real (e para o CrUX), mas a API JavaScript não enxerga o conteúdo deles. Se sua página tem vídeo embutido ou widget em iframe, pode haver divergência entre o que seu RUM mostra e o que o CrUX reporta. A saída é o sub-frame reportar seus próprios event-timing para o frame pai, algo que ainda estou implementando.

A lição de engenharia: INP não se conserta com truque, se conserta cedendo o main thread na hora certa e medindo o p75 real de campo antes e depois. O lab acelera o diagnóstico, mas quem assina o veredito é o CrUX.

Fonte: web.dev — Interaction to Next Paint (INP)