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.

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.

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 });

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.

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

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. 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.