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

O Interaction to Next Paint (INP) é um Core Web Vital que mede a rapidez com que uma página web responde a interações do utilizador, como cliques, toques e pressões de teclas. O INP regista a latência total desde a ação do utilizador, passando pelo processamento de JavaScript, até à atualização visual final no ecrã. Uma boa pontuação de INP é de 200 milissegundos ou menos no percentil 75. O INP substituiu o First Input Delay (FID) como Core Web Vital em março de 2024.

O que é o Interaction to Next Paint (INP)?

O INP é o Core Web Vital da capacidade de resposta. Avalia todas as interações durante uma visita e reporta um único valor para a página.

A cada clique, toque ou pressão de tecla, o browser mede o tempo desde o input até à frame seguinte no ecrã. A interação mais lenta torna-se o INP dessa visita. Em páginas com muitos cliques, o Chrome ignora um valor atípico por cada 50 interações, o que equivale sensivelmente ao percentil 98.

INP vs. FID: o que mudou e porquê

O INP substituiu oficialmente o First Input Delay (FID) como Core Web Vital em março de 2024. A Google descontinuou o FID porque este ignorava dois aspetos.

Primeiro, o FID media apenas a primeira interação na página. Se o primeiro clique do utilizador fosse rápido, mas as interações seguintes fossem lentas, o FID dava a página como aprovada, apesar da má experiência. O INP mede todas as interações durante a visita.

Segundo, o FID media apenas a fase de input delay, ou seja, registava o tempo que o browser passava à espera antes de começar a processar o evento. Ignorava o tempo gasto a executar os event handlers (processing time) e o tempo necessário para desenhar o resultado no ecrã (presentation delay). O INP mede as três fases.

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

Que interações mede o INP?

O INP mede apenas interações discretas: um clique, um toque ou uma pressão de tecla.

Interações que contam para o INP

• Cliques do rato (incluindo cliques em botões, links, checkboxes e controlos personalizados)
• Toques em ecrãs táteis (o equivalente a cliques em telemóveis)
• Pressões de teclas num teclado físico ou no ecrã (incluindo escrever em campos de formulário, premir Enter e usar atalhos de teclado)

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

• Scroll (ver abaixo)
• Hover (mouseover)
• Arrastar (drag), embora o pointerdown que inicia o movimento possa ser medido
• Transições e animações CSS executadas sem interação do utilizador

O scroll em si não conta. Ainda assim, o código associado ao scroll pode prejudicar o INP de duas formas. O clique num link de âncora que inicia uma animação de scroll em JavaScript é uma interação, e o código de scroll corre dentro dela. Além disso, os scroll handlers executados a cada evento de scroll mantêm a main thread ocupada, fazendo o clique seguinte ter de esperar. O scroll-behavior: smooth em CSS evita ambos os problemas.

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

Cada interação medida pelo INP tem três fases consecutivas (a Google chama-lhes subpartes). O valor do INP é a soma das três, e cada fase exige uma solução diferente.

1. Input delay

O input delay é o tempo entre o clique e o início dos event handlers. O clique tem de esperar por qualquer tarefa que esteja a correr na main thread nesse momento: um gestor de tags, o script de um banner de consentimento ou uma framework ainda a hidratar.

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

2. Processing time

O processing time é o tempo que os event handlers da interação demoram a executar: validação de formulários, atualização de estado ou uma chamada de analytics.

Se um event handler fizer operações pesadas no DOM, chamadas síncronas a APIs ou loops lentos, o processing time aumenta. Um clássico: um dataLayer.push() no handler do clique, fazendo com que todas as tags no gestor de tags corram antes do ecrã conseguir atualizar. A solução é fazer yield antes do push.

3. Presentation delay

O presentation delay é o tempo decorrido desde o final dos event handlers até à frame seguinte no ecrã: style, layout e paint.

Páginas com um DOM grande ou com muitos níveis de aninhamento demoram mais tempo a recalcular estilos e a executar o layout. Single page applications que voltam a renderizar árvores de componentes inteiras após uma mudança de estado têm frequentemente um presentation delay elevado.

O que são pontuações boas e más no INP?

Para passar, o INP das visitas à página tem de ser de 200 milissegundos ou menos no p75:

• Um INP igual ou inferior a 200 milissegundos significa que a página tem uma boa capacidade de resposta.
• Um INP entre 200 e 500 milissegundos significa que a capacidade de resposta da página precisa de melhorias.
• Um INP superior a 500 milissegundos significa que a página tem uma má capacidade de resposta.

O INP utiliza o percentil 75, pelo que 75% das visitas à página têm de ter um INP abaixo de 200 ms. Isto inclui visitantes com telemóveis lentos.

Como medir o Interaction to Next Paint (INP)

O INP precisa de visitantes reais a clicar, a tocar e a escrever, pelo que o INP que conta vem de field data. Um teste de lab data que apenas carrega a página não tem INP. O Lighthouse mostra antes o Total Blocking Time, que indica a ocupação da main thread durante o carregamento, mas não revela nada sobre o clique no menu de filtros.

Obter 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 um URL ou origin. O CrUX Vis mostra a sua evolução ao longo dos últimos meses, e o CrUX no BigQuery tem os dados mensais para cada origin.

O Google Search Console agrupa os URLs no relatório de Core Web Vitals. Um grupo com problemas surge como "Problema de INP: superior a 200 ms (telemóvel)" ou "Problema de INP: superior a 500 ms (telemóvel)", com URLs de exemplo. Como abrange os últimos 28 dias, duas semanas após colocar uma correção em produção, metade dos dados ainda reflete o site antigo.

Monitorizar o INP com Real User Monitoring

O CrUX indica que um grupo de páginas falha. Não diz que botão causou o problema. Para isso é necessário Real User Monitoring. No CoreDash, analiso primeiro o p75 do INP em telemóveis, dividido pelo elemento clicado e pelo estado de carregamento.

Medir o INP da sessão atual

Abra o painel Performance nas Chrome DevTools. Este mostra o INP da sessão atual à medida que clica na página, com um registo de cada interação e das suas três fases. Grave um trace enquanto clica para ver o que correu na main thread. A extensão Core Web Vitals Visualizer mostra o INP diretamente na página.

Para fazer debugging prático, utilize a biblioteca JavaScript Web Vitals da Google para registar interações individuais na consola:

Registar o INP na consola 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 ditar o INP de toda a visita, mesmo que todos os outros cliques sejam rápidos. Trabalhe as três fases.

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

1. Minimizar o input delay: evitar long tasks na main thread

A maior parte do trabalho da main thread acontece durante o arranque. Mantenha-a livre:

• Remova código não utilizado. O painel Coverage nas DevTools mostra que parte de cada script nunca chega a correr. O tree shaking e o code splitting tratam do resto.
• Carregue código não essencial quando o browser estiver livre. Precisa mesmo de um widget de chat nos primeiros 500 ms do carregamento da página? Agende scripts não críticos com requestIdleCallback() para correrem apenas quando o browser estiver inativo.
• Identifique a long task por trás do clique. Grave um trace no painel Performance enquanto clica durante o carregamento. A tarefa que estiver a correr no momento do clique é a primeira a corrigir.
• Use async e defer em tags de script para evitar que o JavaScript bloqueie o parser de HTML. Scripts de que ninguém precisa nos primeiros segundos podem esperar mais tempo: 14 métodos para adiar JavaScript.
• Ignore o conselho dos listeners passivos. O { passive: true } é frequentemente recomendado para o INP. Torna o scroll mais fluido. Para o INP, é indiferente.

Dividir long tasks com scheduler.yield()

O JavaScript corre na main thread do browser através de um modelo "run to completion": assim que uma tarefa começa, bloqueia a main thread até terminar. As long tasks (superiores a 50 ms) impedem o browser de responder às ações do utilizador. Com o scheduler.yield(), dá ao browser um momento para processar um clique em espera antes de o código continuar. Mais detalhes 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();
    }
  }
}

Adiar trabalho não crítico com requestIdleCallback

Use requestIdleCallback() para agendar tarefas não essenciais (analytics, telemetria, prefetching) para quando o browser estiver inativo. Desta forma, ficam fora do processing time 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. Minimizar o processing time: dar feedback imediato

Quando um visitante executa uma ação como submeter um formulário ou adicionar um artigo ao carrinho, não espere pela confirmação do servidor para atualizar a interface. Forneça feedback visual imediato ("A submeter o formulário...", "A adicionar ao carrinho...") e conclua a operação em segundo plano.

Além disso, faça yield para a main thread o mais depressa possível após a atualização visual crítica. Como o JavaScript segue um modelo "run to completion", bloqueia a main thread até que todo o código no callback seja executado. Pode criar manualmente um ponto de yield para o browser atualizar o layout antes de continuar 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. Minimizar o presentation delay: manter tudo simples

Quando a página precisa de atualizar após uma interação, o browser tem de recalcular estilos, efetuar o layout, pintar os píxeis alterados e compor o resultado. A complexidade e a dimensão do DOM determinam diretamente quanto tempo demora este trabalho de renderização.

Algumas single page applications voltam a renderizar metade da página após cada interação, mesmo quando mudou apenas um contador. As ferramentas React DevTools e React Scan mostram isso. Muitas vezes, um único context provider no topo da árvore volta a renderizar tudo o que está abaixo.

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

1. Mantenha o DOM pequeno e simples. Um DOM pequeno e plano renderiza mais depressa do que um DOM extenso e profundamente aninhado. O Lighthouse assinala páginas com mais de 1400 elementos no DOM ou com aninhamento superior a 32 níveis.
2. Use content-visibility para fazer lazy loading de conteúdo fora do ecrã. A propriedade CSS content-visibility: auto acelera a renderização inicial ao adiar a renderização do conteúdo fora do ecrã até o utilizador fazer scroll para perto dele.

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

Fazer debugging do INP com a Long Animation Frames (LoAF) API

A Long Animation Frames (LoAF) API fornece detalhes sobre frames que demoram mais de 50 ms a renderizar, incluindo que scripts correram durante esse período.

Ao contrário da antiga Long Tasks API, a LoAF regista tanto o tempo de renderização como o tempo de execução de scripts, o que a torna especialmente útil para diagnosticar problemas de presentation delay. Cada entrada indica a duração da frame e a duração do bloqueio. A lista de scripts mostra, para cada script, o URL de origem, o nome da função e durante quanto tempo esteve a correr.

// 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 de LoAF automaticamente, correlacionando long animation frames com interações específicas do utilizador para ver que script, em que página, torna determinada interação lenta.

INP e LCP: a relação com as long tasks

As long tasks na main thread afetam tanto o INP como o Largest Contentful Paint (LCP). Uma tarefa de JavaScript que bloqueie a main thread durante 200 ms atrasa o processamento de eventos (piorando o INP) e também atrasa a renderização do elemento LCP pelo browser (piorando o LCP). Quando otimiza a main thread dividindo long tasks, adiando JavaScript não crítico e reduzindo o tempo de execução de scripts, melhora ambas as métricas.

Casos de estudo: melhorias de INP em produção

redBus: INP desce 72%, vendas sobem 7%

A redBus, uma plataforma online de bilhetes de autocarro, encontrou interações lentas inesperadas nos seus dados de RUM. Na página de pesquisa, os scroll handlers disparavam a cada evento de scroll e mantinham a main thread ocupada, pelo que aplicaram debounce. Noutra página, cada alteração num campo de input executava o state reducer, pelo que 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%. (caso de estudo da redBus no web.dev)

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

A Preply, uma plataforma online de explicações de línguas em Next.js, reduziu o INP da sua página inicial de cerca de 250 ms para 185 ms e o da página de pesquisa para 175 ms. Fê-lo sem React Server Components. Virtualizou uma lista longa, aplicou debounce a eventos de teclado, memoizou componentes pesados, evitou que uma tooltip voltasse a renderizar a página inteira e corrigiu a gestão de estado do banner de privacidade. Antes de começar, calculou que colocar ambas as páginas abaixo de 200 ms poderia valer cerca de 200 mil dólares por ano em tráfego de pesquisa. (blogue de engenharia da Preply)

O que os dados do CoreDash mostram sobre o INP

A diferença de INP entre telemóveis e desktop

Nos dados do CoreDash, o INP em telemóveis (131 ms no p75) é 2,8 vezes superior ao INP em desktop (48 ms). Os telemóveis têm CPUs mais lentos. O mesmo JavaScript bloqueia a main thread durante mais tempo. Em desktop, 95,6% das interações são boas e em telemóveis 88,0%, tendo os telemóveis cinco vezes mais interações fracas (9,6% contra 1,9%).

Interações de teclado vs. pointer

Os dados do CoreDash mostram que as interações de teclado (75 ms no p75) são 56% mais lentas do que as interações de pointer (49 ms no p75). Os eventos de teclado também registam cerca de cinco vezes mais experiências fracas: 7,4% das interações de teclado resultam num INP fraco, em comparação com apenas 1,4% nas interações de pointer. Eventos de teclado, sobretudo em campos de formulário, costumam acionar validação, autocomplete e atualizações de estado.

Interações durante o carregamento vs. pós-carregamento

As interações durante o carregamento da página têm um INP muito mais elevado do que as interações após a página estar carregada. Os dados do CoreDash mostram que as interações durante a fase "loading" têm um INP de 132 ms no p75, em comparação com apenas 50 ms nas interações pós-carregamento. É uma diferença de 2,6 vezes. Mesmo as interações durante a fase "dom-content-loaded" (75 ms) apresentam um INP elevado, porque ainda há scripts assíncronos e sub-recursos a ser processados. A solução é reduzir o JavaScript durante o arranque: adie o que pode esperar.

O INP na web

No relatório do CrUX de agosto de 2026, 85,3% das origins tinham um bom INP, abaixo dos 87,2% em março. O INP caiu em todos os meses intermédios e é o único Core Web Vital que piorou face a agosto de 2025 (85,7%). A equipa do Chrome considera isto motivo de preocupação e ainda não tem uma explicação.

O Web Almanac de 2025 mostra a disparidade entre dispositivos: 97% das páginas em desktop têm um bom INP, contra 77% em telemóveis. Os 1000 principais sites foram os que mais melhoraram, passando de 53% para 63% de resultados bons em telemóveis. Entretanto, a mediana do Total Blocking Time em telemóveis subiu 58%, de 1209 para 1916 milissegundos.

Perguntas frequentes

Guias relacionados

Cada componente do INP tem o seu próprio guia:

• <strong>Identificar e corrigir problemas de INP</strong>: do relatório do Search Console à interação lenta, com dados de RUM e DevTools.
• <strong>Input delay no INP</strong>: long tasks que fazem o clique esperar.
• <strong>Processing time no INP</strong>: event handlers e o que pode correr após a atualização do ecrã.
• <strong>Presentation delay no INP</strong>: dimensão do DOM, layout thrashing e re-renders.

Guias relacionados de PageSpeed:

• Melhorar o INP: abandone o scroll com JavaScript
• Async vs. defer: estratégias de carregamento de JavaScript
• 14 métodos para adiar JavaScript
• Widget de chat com Core Web Vitals perfeitos
• Correção: evitar um tamanho excessivo do DOM