Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

Publicado em: 6 de maio de 2022. Última atualização: 9 de setembro de 2025

Os dados de uso do Chrome mostram que 90% do tempo de um usuário em uma página é gasto depois que ela é carregada. Portanto, é importante medir cuidadosamente a capacidade de resposta durante todo o ciclo de vida da página. É isso que a métrica INP avalia.

Uma boa capacidade de resposta significa que uma página responde rapidamente às interações. Quando uma página responde a uma interação, o navegador apresenta feedback visual no próximo frame renderizado. O feedback visual informa se, por exemplo, um item adicionado a um carrinho de compras on-line está sendo adicionado, se um menu de navegação móvel foi aberto, se o conteúdo de um formulário de login está sendo autenticado pelo servidor e assim por diante.

Algumas interações naturalmente levam mais tempo do que outras, mas, para interações especialmente complexas, é importante apresentar rapidamente um feedback visual inicial para informar ao usuário que algo está acontecendo. O próximo frame que o navegador vai renderizar é a primeira oportunidade para fazer isso.

Portanto, o objetivo do INP não é medir todos os efeitos eventuais de uma interação, como buscas de rede e atualizações da interface de outras operações assíncronas, mas o tempo em que a próxima renderização está sendo bloqueada. Ao atrasar o feedback visual, os usuários podem ter a impressão de que a página não está respondendo rápido o suficiente. O INP foi desenvolvido para ajudar os desenvolvedores a medir essa parte da experiência do usuário.

No vídeo a seguir, o exemplo à direita dá um feedback visual imediato de que um acordeão está sendo aberto. A capacidade de resposta ruim é demonstrada no exemplo à esquerda e como ela pode criar experiências ruins para o usuário.

Este guia explica como a INP funciona, como medi-la e aponta recursos para melhorá-la.

O que é INP?

A INP é uma métrica que avalia a capacidade de resposta geral de uma página às interações do usuário, observando a latência de todas as interações de clique, toque e teclado que ocorrem durante a vida útil da visita de um usuário a uma página. O valor final da INP é a interação mais longa observada, ignorando os valores atípicos.

Uma interação é um grupo de manipuladores de eventos que são acionados durante o mesmo gesto lógico do usuário. Por exemplo, as interações de "toque" em um dispositivo touchscreen incluem vários eventos, como pointerup, pointerdown e click. Uma interação pode ser impulsionada por JavaScript, CSS, controles integrados do navegador (como elementos de formulário) ou uma combinação deles.

A latência de uma interação consiste na duração mais longa de um grupo de manipuladores de eventos que impulsionam a interação, desde o momento em que o usuário inicia a interação até o momento em que o navegador pode renderizar um frame. Em casos raros, pode não haver um frame para renderizar, mas a interação termina quando o navegador consegue renderizar um frame.

O que é uma boa pontuação de INP?

É difícil fixar rótulos como "boa" ou "ruim" em uma métrica de capacidade de resposta. Por um lado, você quer incentivar práticas de desenvolvimento que priorizem uma boa capacidade de resposta. Por outro lado, é preciso considerar que há uma variabilidade considerável nos recursos dos dispositivos que as pessoas usam para definir expectativas de desenvolvimento alcançáveis.

Para garantir que você esteja oferecendo experiências do usuário com boa capacidade de resposta, um bom limite para medir é o 75º percentil de carregamentos de página registrados no campo, segmentados em dispositivos móveis e computadores:

• Uma INP abaixo ou em 200 milissegundos significa que uma página tem boa capacidade de resposta.
• Um INP acima de 200 milissegundos e abaixo ou em 500 milissegundos significa que a capacidade de resposta de uma página precisa ser melhorada.
• Um INP acima de 500 milissegundos significa que uma página tem baixa capacidade de resposta.

O que há em uma interação?

O principal fator de interatividade geralmente é o JavaScript, embora os navegadores ofereçam interatividade por controles não alimentados por JavaScript, como caixas de seleção, botões de opção e controles alimentados por CSS.

Como o objetivo da INP é medir a capacidade de resposta, apenas os seguintes tipos de interação são observados:

• Clicar com um mouse.
• Tocar em um dispositivo com tela touchscreen.
• Pressionar uma tecla em um teclado físico ou na tela.

As interações acontecem no documento principal ou em iframes incorporados a ele, por exemplo, ao clicar em "Reproduzir" em um vídeo incorporado. Os usuários finais não sabem o que está em um iframe ou não. Portanto, o INP em iframes é necessário para medir a experiência do usuário na página de nível superior. Como as APIs da Web JavaScript não têm acesso ao conteúdo dos iframes, isso pode aparecer como uma diferença entre o CrUX e o RUM.

As interações podem consistir em vários eventos. Por exemplo, uma ação de pressionar uma tecla inclui os eventos keydown, keypress e keyup. As interações de toque contêm eventos pointerup e pointerdown. O evento com a maior duração na interação é o que contribui para a latência total dela.

Conforme mostrado no diagrama, a duração do processamento do INP inclui todos os callbacks do manipulador de eventos nesse frame. Isso faz com que o atraso de entrada seja o tempo antes de qualquer callback de uma interação ser processado, a duração do processamento seja o tempo para todos os callbacks serem executados e o atraso de apresentação seja o tempo após a execução dos callbacks até que o frame seja apresentado na tela do usuário.

O INP da página é calculado quando o usuário sai dela. O resultado é um único valor que representa a capacidade de resposta geral da página durante todo o ciclo de vida dela. Um INP baixo significa que uma página respondeu de forma confiável à entrada do usuário.

Como o INP é diferente do First Input Delay (FID)?

A INP é a métrica sucessora da First Input Delay (FID). Embora ambas sejam métricas de capacidade de resposta, a FID mede apenas o atraso de entrada da primeira interação em uma página. A INP melhora a FID ao observar todas as interações em uma página, desde o atraso de entrada até o tempo necessário para executar os manipuladores de eventos e, finalmente, até que o navegador pinte o próximo frame.

Essas diferenças significam que o INP e o FID são tipos diferentes de métricas de capacidade de resposta. Enquanto o FID era uma métrica de capacidade de resposta de carregamento projetada para avaliar a primeira impressão da página no usuário, o INP é um indicador mais confiável da capacidade de resposta geral, independentemente de quando as interações ocorrem na vida de uma página.

E se nenhum valor de INP for informado?

É possível que uma página não retorne um valor de INP. Isso pode acontecer por vários motivos, incluindo:

• A página foi carregada, mas o usuário nunca clicou, tocou ou pressionou uma tecla no teclado.
• A página foi carregada, mas o usuário interagiu com ela usando gestos que não são medidos, como rolar ou passar o cursor sobre elementos.
• A página está sendo acessada por um bot, como um rastreador de pesquisa ou um navegador sem interface gráfica, que não foi programado para interagir com ela.

Como medir o INP

A INP pode ser medida tanto no campo quanto no laboratório, na medida em que você pode simular interações realistas do usuário.

No campo

O ideal é que sua jornada de otimização do INP comece com dados de campo. No melhor cenário, os dados de campo do monitoramento de usuários reais (RUM, na sigla em inglês) fornecem não apenas o valor de INP de uma página, mas também dados contextuais que destacam qual interação específica foi responsável pelo valor de INP, se a interação ocorreu durante ou após o carregamento da página, o tipo de interação (clique, pressionamento de tecla ou toque) e outros tempos valiosos que podem ajudar a identificar qual parte da interação estava afetando a capacidade de resposta.

Se o site se qualificar para inclusão no Chrome User Experience Report (CrUX), você poderá receber rapidamente dados de campo para o INP pelo CrUX no PageSpeed Insights (e outras Core Web Vitals). No mínimo, você pode ter uma visão geral da INP do seu site no nível da origem, mas, em alguns casos, também é possível receber dados no nível do URL.

No entanto, embora a CrUX possa informar se há um problema, ela não pode dizer o que o causou. Uma solução de RUM pode ajudar você a descobrir mais detalhes sobre páginas, usuários ou interações que estão com problemas de capacidade de resposta. A capacidade de atribuir o INP a interações individuais evita suposições e desperdício de esforço.

No laboratório

O ideal é começar a testar no laboratório quando você tiver dados de campo que sugerem que uma página tem interações lentas. Os dados de campo vão facilitar muito a reprodução de interações problemáticas no laboratório.

No entanto, é possível que você não tenha dados de campo. Embora a INP possa ser medida em algumas ferramentas de laboratório, o valor resultante para uma página durante o teste de laboratório depende das interações realizadas durante o período de medição. Os comportamentos dos usuários podem ser imprevisíveis e altamente variáveis. Isso significa que os testes no laboratório podem não revelar interações problemáticas da mesma forma que os dados de campo. Além disso, algumas ferramentas de laboratório não informam o INP de uma página porque observam apenas o carregamento dela, sem interações. Nesses casos, o Tempo total de bloqueio (TBT) pode ser uma métrica de proxy razoável para o INP, mas não é um substituto para o INP por si só.

Embora haja limitações nas ferramentas de laboratório ao avaliar o INP de uma página, existem algumas estratégias para reproduzir interações lentas no laboratório. As estratégias incluem seguir fluxos de usuários comuns e testar interações ao longo do caminho, além de interagir com a página enquanto ela carrega (quando a linha de execução principal está mais ocupada) para identificar interações lentas durante essa parte crucial da experiência do usuário.

Medir o INP em JavaScript

Para medir o INP em JavaScript, é necessário medir os tempos de eventos de todas as interações e, em seguida, usar o 98º percentil em todas essas interações no descarregamento da página. Consulte o código-fonte da biblioteca JavaScript web vitals, que contém uma implementação de referência sobre como o INP é calculado.

Na maioria dos casos, o valor atual do INP no momento em que a página está sendo descarregada é o valor final do INP para essa página. No entanto, há algumas exceções importantes, conforme observado na próxima seção. A biblioteca JavaScript web vitals considera esses fatores o máximo possível, dentro das limitações das APIs da Web.

Diferenças entre a métrica e a API

• As entradas event abaixo de 104 milissegundos não são informadas por padrão usando observadores de performance. Esse padrão pode ser alterado quando um observador de performance é registrado usando o parâmetro durationThreshold, mas mesmo assim tem um valor mínimo de 16 milissegundos. Por isso, recomendamos observar também a entrada first-input, que também é uma entrada de tempo de evento, mas tem garantia de ser observável mesmo quando a duração é menor que durationThreshold. Isso ajuda a garantir que as páginas com interações sempre informem algum valor de INP.
• Para calcular percentis com perfeição, é preciso manter todas as amostras na memória, o que pode ser caro. Mas é possível aproximar percentis, especialmente os muito altos, como p98, mantendo apenas uma pequena lista das N piores interações. 10 é uma escolha comum.
• Se uma página for restaurada do cache de avanço e retorno, o valor de INP dela será redefinido como zero, já que os usuários consideram isso como uma visita distinta à página.
• A API não informa entradas event para interações que ocorrem em iframes, mas a métrica faz isso porque elas fazem parte da experiência do usuário na página. Isso pode aparecer como uma diferença entre a CrUX e o RUM. Para medir corretamente o INP, considere esses pontos. Os subframes podem usar a API para informar as entradas de event-timing ao frame principal.

Além dessas exceções, a INP tem uma complexidade extra porque mede todo o ciclo de vida de uma página:

• Os usuários podem manter uma guia aberta por um período muito longo: dias, semanas ou meses. Na verdade, um usuário pode nunca fechar uma guia.
• Em sistemas operacionais móveis, os navegadores geralmente não executam callbacks de descarregamento de página para guias em segundo plano, o que dificulta a geração de relatórios com o valor "final".

Para lidar com esses casos, o INP precisa ser informado sempre que uma página é colocada em segundo plano, além de sempre que ela é descarregada. O evento visibilitychange abrange os dois cenários. Os sistemas de análise que recebem esses dados precisam calcular o valor final do INP no back-end.

Em vez de memorizar e lidar com todos esses casos, os desenvolvedores podem usar a biblioteca JavaScript web-vitals para medir o INP, que considera tudo o que foi mencionado anteriormente, exceto o caso do iframe:

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

Como melhorar o INP

Uma coleção de guias sobre como otimizar o INP está disponível para orientar você no processo de identificação de interações lentas em campo e no uso de dados de laboratório para identificar causas e otimizá-las.

Registro de alterações

Às vezes, bugs são descobertos nas APIs usadas para medir métricas e, às vezes, nas próprias definições das métricas. Como resultado, às vezes é necessário fazer mudanças, que podem aparecer como melhorias ou regressões nos seus relatórios e painéis internos.

Para ajudar você a gerenciar isso, todas as mudanças na implementação ou na definição dessas métricas vão aparecer neste Registro de alterações.

Se você tiver feedback sobre essas métricas, envie no grupo do Google web-vitals-feedback.

Teste seus conhecimentos