Interaction to Next Paint (INP): O que é, como medir e melhorar

Interaction to Next Paint (INP) é um Core Web Vital que mede a rapidez com que uma página responde a interações do usuário, como cliques, toques e toques no teclado. O INP captura a latência total desde a entrada do usuário até a atualização visual final na tela, incluindo o processamento do JavaScript. Uma boa pontuação de INP é de 200 milissegundos ou menos no percentil 75. O INP substituiu o First Input Delay (FID) como um Core Web Vital em março de 2024.

O que é Interaction to Next Paint (INP)?

O INP é o Core Web Vital de responsividade. Ele avalia todas as interações durante uma visita e relata um único número para a página.

A cada clique, toque na tela ou no teclado, o navegador mede o tempo entre a entrada e o próximo quadro na tela. A interação mais lenta se torna o INP daquela visita. Em páginas com muitos cliques, o Chrome ignora um valor atípico a cada 50 interações. Isso equivale aproximadamente ao percentil 98.

INP vs FID: o que mudou e por quê

O INP substituiu oficialmente o First Input Delay (FID) como um Core Web Vital em março de 2024. O Google aposentou o FID porque ele ignorava duas coisas.

Primeiro, o FID media apenas a primeira interação na página. Se o primeiro clique do usuário fosse rápido, mas as interações seguintes fossem lentas, o FID reportava uma boa pontuação apesar da experiência ruim. O INP mede todas as interações durante a visita.

Segundo, o FID media apenas a fase de atraso de entrada (input delay). Ele capturava apenas o tempo que o navegador passava esperando antes de começar a processar o evento. Ele ignorava o tempo de execução dos manipuladores de eventos (tempo de processamento) e o tempo necessário para pintar o resultado na tela (atraso de apresentação). O INP mede os três.

Quase todos os sites passavam no FID. Muitos deles falham no INP, porque as interações posteriores, ou o trabalho após o primeiro clique, são lentos.

Quais interações o INP mede?

O INP mede apenas interações discretas: um clique, um toque na tela ou um toque no teclado.

Interações que contam para o INP

• Cliques do mouse (incluindo cliques em botões, links, caixas de seleção e controles personalizados)
• Toques em telas sensíveis ao toque (equivalente a cliques em dispositivos móveis)
• Toques no teclado físico ou virtual (incluindo digitação em campos de formulário, pressionar Enter, atalhos de teclado)

Interações que NÃO contam para o INP

• Rolagem (veja abaixo)
• Hover (passar o mouse)
• Arrastar, embora o pointerdown que inicia o arrasto possa ser medido
• Transições e animações CSS executadas sem entrada do usuário

A rolagem em si não conta. Mas o código de rolagem ainda pode prejudicar o INP de duas maneiras. Um clique em um link âncora que inicia uma animação de rolagem em JavaScript é uma interação, e o código de rolagem é executado dentro dela. E manipuladores de rolagem executados a cada evento de rolagem mantêm a main thread ocupada. Com isso, o próximo clique precisa esperar. O scroll-behavior: smooth no CSS evita ambos.

As três fases de uma interação INP

Toda interação medida pelo INP possui três fases consecutivas (o Google as chama de subpartes). O valor do INP é a soma das três. Cada fase exige uma correção diferente.

1. Atraso de entrada

O atraso de entrada é o tempo entre o clique e o início dos manipuladores de eventos. O clique precisa esperar a tarefa que estiver rodando na main thread naquele momento: um gerenciador de tags, um script de banner de consentimento ou um framework que ainda está hidratando.

O atraso de entrada é pior enquanto a página ainda está carregando. Nos dados do CoreDash, os cliques durante o carregamento são mais do que duas vezes mais lentos que os cliques após o carregamento (números mais abaixo).

2. Tempo de processamento

O tempo de processamento é o tempo que os manipuladores de eventos da interação levam para rodar: uma validação de formulário, uma atualização de estado, uma chamada de analytics.

Se um manipulador de eventos realiza trabalho pesado no DOM, chamadas de API síncronas ou loops lentos, o tempo de processamento sobe. Um clássico: um dataLayer.push() no manipulador de clique. Todas as tags no gerenciador de tags rodam antes que a tela possa ser atualizada. A correção é fazer um yield antes do push.

3. Atraso de apresentação

O atraso de apresentação é o tempo desde o fim dos manipuladores de eventos até o próximo quadro na tela: estilo, layout e pintura.

Páginas com um DOM grande ou profundamente aninhado levam mais tempo para recalcular estilos e processar o layout. Single page applications que renderizam novamente grandes árvores de componentes após uma mudança de estado costumam ter um alto atraso de apresentação.

O que são pontuações boas e ruins de INP?

Para passar, o INP das visitas da sua página deve ser 200 milissegundos ou menos no p75:

• Um INP em 200 milissegundos ou menos significa que sua página tem boa responsividade.
• Um INP entre 200 e 500 milissegundos significa que a responsividade da sua página precisa de melhorias.
• Um INP acima de 500 milissegundos significa que sua página tem baixa responsividade.

O INP usa o percentil 75. Isso significa que 75% das visitas à página precisam de um INP abaixo de 200ms. Isso inclui visitantes em celulares lentos.

Como medir o Interaction to Next Paint (INP)

O INP precisa de visitantes reais que clicam, tocam e digitam. Portanto, o INP que vale vem de field data. Um teste de laboratório que apenas carrega a página não possui INP. O Lighthouse exibe o Total Blocking Time. Ele informa o quão ocupada a main thread fica durante o carregamento, mas não diz nada sobre o clique no seu menu de filtros.

Obtenha as métricas oficiais de INP

O INP oficial vem do CrUX. O PageSpeed Insights mostra o percentil 75 dos últimos 28 dias de dados do Chrome para uma URL ou origem. O CrUX Vis mostra como ele mudou ao longo dos últimos meses. O CrUX no BigQuery possui os dados mensais para todas as origens.

O Google Search Console agrupa suas URLs no relatório de Core Web Vitals. Um grupo reprovado aparece como "Problema de INP: maior que 200ms (dispositivos móveis)" ou "Problema de INP: maior que 500ms (dispositivos móveis)", com URLs de exemplo. Ele abrange os últimos 28 dias. Assim, duas semanas após a publicação de uma correção, metade do que ele mostra ainda é o site antigo.

Acompanhe o INP com RUM

O CrUX indica que um grupo de páginas falha. Ele não informa qual botão. Para isso você precisa de RUM. No CoreDash, eu olho primeiro para o INP p75 em dispositivos móveis, dividido pelo elemento clicado e pelo estado de carregamento.

Meça o INP da sessão atual

Abra o painel Performance no Chrome DevTools. Ele mostra o INP da sua sessão atual conforme você clica, com um log de todas as interações e suas três fases. Grave um trace enquanto clica para ver o que rodou na main thread. A extensão Core Web Vitals Visualizer exibe o INP na própria página.

Para um debug prático, use a biblioteca Web Vitals JavaScript do Google para registrar interações individuais no console:

Registre o INP no console com a biblioteca JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@6/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Como melhorar o Interaction to Next Paint

Uma única interação lenta pode definir o INP para a visita inteira, mesmo quando todos os outros cliques são rápidos. Trabalhe nas três fases.

Dica do PageSpeed: registre o estado de carregamento da página em cada interação. Um clique lento durante o carregamento exige uma correção diferente de um clique lento em uma página já carregada.

1. Minimize o atraso de entrada: evite long tasks na main thread

A maior parte do trabalho na main thread ocorre durante a inicialização. Mantenha-a livre:

• Remova código não utilizado. O painel Coverage do DevTools mostra o quanto de cada script nunca é executado. Tree shaking e code splitting resolvem o resto.
• Carregue código não essencial no tempo ocioso do navegador. Você realmente precisa de um widget de chat nos primeiros 500ms do tempo de carregamento da página? Agende scripts não críticos com requestIdleCallback() para executarem apenas quando o navegador estiver ocioso.
• Encontre a long task sob o clique. Grave um trace no painel Performance enquanto você clica durante o carregamento. A tarefa que roda no momento em que o seu clique ocorre é a primeira que deve ser corrigida.
• Use async e defer em tags de script para evitar que o JavaScript bloqueie o analisador HTML. Scripts que ninguém precisa nos primeiros segundos podem esperar mais: 14 métodos para adiar o JavaScript.
• Ignore o conselho de ouvintes passivos. { passive: true } é muito recomendado para o INP. Ele torna a rolagem mais suave. O INP não liga para isso.

Quebre long tasks com scheduler.yield()

O JavaScript roda na main thread do navegador usando um modelo de "execução até a conclusão" (run to completion): assim que uma tarefa começa, ela bloqueia a main thread até terminar. Long tasks (acima de 50ms) impedem o navegador de responder à entrada do usuário. Com scheduler.yield() você dá ao navegador um momento para lidar com um clique em espera antes de o seu código continuar. Leia mais em yield para a main thread.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Adie trabalho não crítico com requestIdleCallback

Use requestIdleCallback() para agendar tarefas não essenciais (analytics, telemetria, prefetching) para quando o navegador estiver ocioso. Isso as mantém fora do tempo de processamento do clique.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

2. Minimize o tempo de processamento: forneça feedback imediato

Quando um visitante realiza uma ação como enviar um formulário ou adicionar um item ao carrinho, não espere pela confirmação do servidor antes de atualizar a UI. Forneça feedback visual imediato ("Enviando seu formulário...", "Adicionando item ao carrinho...") e conclua a operação em segundo plano.

Além disso, faça um yield para a main thread assim que possível após a atualização visual crítica. Como o JavaScript segue o modelo de "execução até a conclusão", ele bloqueia a main thread até que todo o código no callback termine de rodar. Você pode criar manualmente um ponto de yield. O navegador atualiza o layout e depois continua a executar o código não crítico restante.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run, 0);
});

3. Minimize o atraso de apresentação: mantenha as coisas simples

Quando a página precisa ser atualizada após uma interação, o navegador deve recalcular estilos, processar o layout, pintar os pixels alterados e compor o resultado. A complexidade e o tamanho do seu DOM determinam diretamente quanto tempo esse trabalho de renderização leva.

Algumas single page applications renderizam novamente metade da página após cada interação, quando apenas um contador mudou. O React DevTools e o React Scan mostram isso. Muitas vezes, um context provider no topo da árvore renderiza novamente tudo abaixo dele.

Duas regras para uma renderização mais rápida:

1. Mantenha o DOM pequeno e simples. Um DOM pequeno e plano é renderizado mais rapidamente que um grande e profundamente aninhado. O Lighthouse alerta sobre páginas com mais de 1.400 elementos no DOM ou com aninhamento superior a 32 níveis.
2. Use content-visibility para adiar a renderização do conteúdo fora da tela. A propriedade CSS content-visibility: auto acelera a renderização inicial ao adiar a renderização do conteúdo oculto até o usuário rolar a tela para perto dele.

/* Apply content-visibility to off-screen sections */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Depurando o INP com a Long Animation Frames (LoAF) API

A API Long Animation Frames (LoAF) fornece detalhes sobre quadros que levam mais de 50ms para renderizar, incluindo quais scripts foram executados neles.

Ao contrário da antiga API Long Tasks, a LoAF captura o tempo de renderização e o tempo de execução dos scripts. Isso a torna muito útil no diagnóstico de problemas de atraso de apresentação. Cada entrada possui a duração do quadro e a duração do bloqueio. Sua lista de scripts exibe a URL de origem, o nome da função e por quanto tempo o script foi executado.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Ferramentas de RUM como o CoreDash integram dados da LoAF automaticamente. Elas correlacionam long animation frames com interações específicas do usuário. Assim você consegue ver qual script em qual página torna determinada interação lenta.

INP e LCP: a conexão com long tasks

Long tasks na main thread afetam o INP e a Largest Contentful Paint (LCP). Uma tarefa JavaScript que bloqueia a main thread por 200ms atrasa o processamento de eventos (piorando o INP) e também atrasa o navegador na renderização do elemento LCP (piorando a LCP). Quando você otimiza a main thread quebrando long tasks, adiando JavaScript não crítico e reduzindo o tempo de execução de scripts, você melhora ambos.

Estudos de caso: melhorias de INP em produção

redBus: INP cai 72%, vendas sobem 7%

A redBus, uma plataforma online de passagens de ônibus, encontrou interações lentas nos seus dados de RUM que não esperava. Na página de busca, manipuladores de rolagem disparavam a cada evento de rolagem e mantinham a main thread ocupada. Então, eles aplicaram um debounce. Em outra página, cada mudança em um campo de entrada acionava o redutor de estado. Eles passaram a chamá-lo com menos frequência. O INP dessa página melhorou 72%, e a redBus viu as vendas aumentarem cerca de 7%. (Estudo de caso da redBus no web.dev)

Preply: INP de 250ms para 185ms em um site Next.js

A Preply, uma plataforma de tutoria de idiomas online em Next.js, baixou o INP de sua página inicial de cerca de 250ms para 185ms, e o da página de busca para 175ms. Eles fizeram isso sem React Server Components. Eles virtualizaram uma lista longa, aplicaram debounce em eventos de teclado, usaram memoization em componentes pesados, impediram que uma tooltip renderizasse novamente toda a página e corrigiram a manipulação de estado de seu banner de privacidade. Antes de começarem, eles estimaram que deixar ambas as páginas abaixo de 200ms poderia valer cerca de US$ 200 mil por ano em tráfego de busca. (Blog de engenharia da Preply)

O que os dados do CoreDash mostram sobre o INP

A diferença de INP entre mobile e desktop

Nos dados do CoreDash, o INP de dispositivos móveis (131ms no p75) é 2,8 vezes o INP do desktop (48ms). Os celulares têm processadores mais lentos. O mesmo JavaScript bloqueia a main thread por mais tempo. No desktop, 95,6% das interações são boas e em dispositivos móveis, 88,0%. Os celulares têm cinco vezes mais interações ruins (9,6% contra 1,9%).

Interações de teclado vs interações de ponteiro

Dados do CoreDash mostram que interações de teclado (75ms no p75) são 56% mais lentas que as de ponteiro (49ms no p75). Os eventos de teclado também possuem cerca de cinco vezes mais experiências ruins: 7,4% das interações de teclado resultam em um INP ruim, contra apenas 1,4% das interações de ponteiro. Eventos de teclado, especialmente em campos de formulário, frequentemente disparam validação, preenchimento automático e atualizações de estado.

Interações durante o carregamento vs após o carregamento

Interações durante o tempo de carregamento da página possuem um INP muito mais alto do que as interações após o carregamento. Os dados do CoreDash mostram que interações na fase "loading" têm um INP no p75 de 132ms, contra apenas 50ms nas interações pós-carregamento. Essa é uma diferença de 2,6 vezes. Mesmo as interações durante a fase "dom-content-loaded" (75ms) exibem um INP elevado, pois scripts assíncronos e sub-recursos ainda estão sendo processados. Menos JavaScript na inicialização é a solução: adie o que puder esperar.

O INP pela web

No relatório do CrUX de agosto de 2026, 85,3% das origens possuíam um INP bom. Em março esse número era de 87,2%. O INP caiu em todos os meses intermediários. Além disso, é a única Core Web Vital que piorou em relação a agosto de 2025 (85,7%). A equipe do Chrome diz que é motivo de preocupação e ainda não possui explicação.

O Web Almanac de 2025 mostra a diferença entre dispositivos: 97% das páginas em desktop possuem um INP bom, contra 77% nos dispositivos móveis. Os 1.000 sites principais apresentaram a maior melhora em dispositivos móveis, passando de 53% para 63% de avaliações boas. Enquanto isso, a mediana do Total Blocking Time em dispositivos móveis subiu 58%, de 1.209 para 1.916 milissegundos.

Perguntas frequentes

Guias relacionados

Cada parte do INP possui o seu próprio guia:

• <strong>Encontre e corrija problemas de INP</strong>: do relatório do Search Console à interação lenta, usando dados de RUM e DevTools.
• <strong>Atraso de entrada do INP</strong>: long tasks que fazem o clique esperar.
• <strong>Tempo de processamento do INP</strong>: manipuladores de eventos e o que pode rodar após a tela ser atualizada.
• <strong>Atraso de apresentação do INP</strong>: tamanho do DOM, layout thrashing e novas renderizações.

Guias relacionados sobre PageSpeed:

• Melhore o INP: abandone as rolagens em JavaScript
• Async vs Defer: estratégias de carregamento de JavaScript
• 14 métodos para adiar o JavaScript
• Widget de chat com Core Web Vitals perfeitas
• Correção: evite um tamanho excessivo de DOM