Resposta rápida

INP (Interaction to Next Paint) mede a demora entre o clique ou toque do usuário e a próxima atualização visual. Para ficar na faixa boa, a meta é abaixo de 200 ms no percentil 75. A causa mais comum é uma long task de JavaScript bloqueando a thread principal, muitas vezes vinda de script de terceiro. A correção passa por dividir tarefas, adiar scripts e reduzir o trabalho no event handler.

INP (Interaction to Next Paint) substituiu o FID como métrica de interatividade nas Core Web Vitals em março de 2024. É a mais difícil das três de otimizar porque mede a responsividade durante toda a sessão - não só a primeira interação.

Meta: abaixo de 200ms.

Para entender como o INP se relaciona com LCP e CLS, veja o guia completo de performance e Core Web Vitals.

O que o INP mede

Quando o usuário clica, toca ou usa o teclado, o navegador precisa:

  1. Receber o evento
  2. Executar os event handlers (JavaScript)
  3. Calcular as mudanças visuais
  4. Renderizar a próxima frame

INP mede o tempo entre o evento do usuário e a próxima frame renderizada. Se esse processo demora, o site parece “travado” ou “lento para responder”.

A causa raiz: long tasks na thread principal

O JavaScript em browsers roda em uma única thread (a main thread). Se uma tarefa JavaScript demora mais de 50ms (uma “long task”), ela bloqueia todas as outras tarefas - incluindo responder a interações do usuário.

INP alto = alguma task JavaScript está bloqueando a thread principal. O caminho principal de correção é a otimização de JavaScript.

Como identificar o problema

Chrome DevTools - Performance Panel:

  1. Abra F12 > aba Performance
  2. Clique em “Record”
  3. Interaja com a página (clique nos elementos que parecem lentos)
  4. Pare a gravação
  5. Procure blocos vermelhos no flame chart - essas são long tasks

Long tasks acima de 50ms: atenção
Long tasks acima de 200ms: crítico para INP

PerformanceObserver no console:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long task:', entry.duration, 'ms', entry);
  }
});
observer.observe({ type: 'longtask', buffered: true });

Como medir o INP no mundo real

O DevTools mostra o que acontece na sua máquina, com a sua conexão. O INP oficial é calculado com dados de usuários reais, no percentil 75 - ou seja, 75% das interações precisam ficar abaixo de 200 ms.

Onde encontrar os dados de campo:

  • PageSpeed Insights: a seção “Dados do usuário real” mostra o INP do domínio inteiro, agregado pelo CrUX. Não serve para isolar uma página específica.
  • Search Console: o relatório de Core Web Vitals agrupa URLs com o mesmo problema e ajuda a priorizar o que corrigir primeiro.
  • Biblioteca web-vitals: permite enviar o INP de cada visitante para o seu analytics, o que dá visibilidade por página e por tipo de dispositivo.

Uma diferença importante: o INP pode parecer bom no laboratório e ruim no campo porque o aparelho do visitante é mais lento e a rede é pior. Sempre valide a correção com dados reais antes de considerar o problema resolvido.

Técnicas para melhorar INP

1. Identificar e eliminar long tasks

Break up long tasks: tarefas longas podem ser quebradas em partes menores usando setTimeout(fn, 0) para ceder o controle para o navegador entre partes:

function processarItemsEmLotes(items) {
  let index = 0;
  
  function processarProximoLote() {
    const limite = Math.min(index + 50, items.length);
    for (; index < limite; index++) {
      processar(items[index]);
    }
    if (index < items.length) {
      setTimeout(processarProximoLote, 0); // cede a thread
    }
  }
  
  processarProximoLote();
}

2. Deferir JavaScript não crítico

Use requestIdleCallback para tarefas não urgentes que podem esperar o navegador estar “livre”:

requestIdleCallback(() => {
  // Tarefas de baixa prioridade: analytics, prefetch, etc.
  inicializarAnalytics();
});

3. Reduzir scripts de terceiros

Scripts de terceiros (chat, heatmap, analytics avançado, redes sociais) frequentemente são as maiores fontes de long tasks. Para cada script de terceiro:

  • É realmente necessário?
  • Pode ser carregado depois do carregamento inicial (defer/async)?
  • Pode ser substituído por alternativa mais leve?

4. Otimizar event handlers

Event handlers pesados bloqueiam a thread:

// RUIM: faz tudo no evento
document.addEventListener('click', () => {
  // 300ms de processamento
  processarTudoSincrono();
});

// MELHOR: faz o mínimo no evento, o restante de forma assíncrona
document.addEventListener('click', () => {
  // Atualiza UI imediatamente (< 50ms)
  atualizarUIImediato();
  
  // Processamento pesado é adiado
  setTimeout(() => processarEmBackground(), 0);
});

5. Web Workers para processamento pesado

Web Workers permitem rodar JavaScript em thread separada, sem bloquear a main thread:

// Cria worker
const worker = new Worker('processamento-pesado.js');

// Envia dados para o worker
worker.postMessage({ dados: meusDados });

// Recebe resultado sem bloquear a main thread
worker.onmessage = (e) => {
  atualizarUI(e.data.resultado);
};

Scripts de terceiros e INP

Scripts de terceiros que mais impactam o INP:

  • Chat ao vivo (Intercom, Zendesk, LiveChat): carregam muitos scripts
  • Heatmap tools (Hotjar, FullStory): gravam todas as interações
  • Pixel de rastreamento (Facebook Pixel, Google Tag Manager com muitas tags)
  • Widgets de redes sociais (embeds do Instagram, Twitter)

Abordagem: carregue scripts de terceiros somente após o carregamento inicial. Use setTimeout de 3-5 segundos para o load de scripts não críticos.

Erros comuns ao otimizar INP

  • Medir só no DevTools e ignorar os dados de campo
  • Colocar tudo em setTimeout sem critério e criar tarefas ainda maiores
  • Otimizar a primeira interação e esquecer as seguintes
  • Instalar mais um script de “otimização” que também roda na thread principal
  • Ignorar o custo de scripts de terceiros no celular
  • Corrigir o INP e piorar LCP ou CLS ao mesmo tempo

Uma otimização de INP bem feita reduz trabalho na thread principal; ela não troca um problema por outro. Se o site já sofre com carregamento lento, comece pelo LCP e depois volte para a responsividade.

Performance Web

Seu site responde rápido quando o usuário interagir?

Analisamos e otimizamos o INP do seu site - identificamos long tasks e scripts que bloqueiam a resposta ao usuário.

Melhorar performance do meu site

Fontes e referências

FAQ

INP é difícil de medir comparado a LCP e CLS?

Sim. LCP e CLS aparecem claramente no PageSpeed Insights e Lighthouse. INP só aparece em dados de campo (usuários reais) no PageSpeed Insights e Search Console - não em dados de laboratório. Isso torna o diagnóstico mais complexo.

INP ruim pode ser causado só por scripts de terceiros?

Sim, e é um dos casos mais comuns. Um único script de analytics ou chat pesado pode causar INP acima de 500ms. Teste desabilitando scripts de terceiros temporariamente para isolar a causa.

O que é a diferença entre FID e INP?

FID (First Input Delay) media apenas a primeira interação do usuário. INP mede todas as interações ao longo da sessão e reporta a pior (ou próxima da pior). INP é mais difícil de passar porque uma única interação lenta em qualquer momento da visita afeta o score.

Qual o impacto do INP no ranking do Google?

O Google confirma que Core Web Vitals são sinais de ranking, mas não especifica o peso individual de cada métrica. INP passou a fazer parte das Core Web Vitals em março de 2024, substituindo o FID. Veja como as Core Web Vitals afetam o SEO na prática. Como o FID era mais fácil de passar, muitos sites que tinham boa pontuação antes podem ter piorado com a transição para INP.