---
title: "Como melhorar o INP: guia com dados de campo e código"
description: "Melhore o Interaction to Next Paint passo a passo: dados de campo, atribuição com LoAF, código para ceder a thread principal e o INP por plataforma no Brasil."
url: "https://dardo.studio/pt/blog/melhorar-inp/"
language: "pt"
translations: {"en":"https://dardo.studio/en/blog/fix-inp/","es":"https://dardo.studio/es/blog/mejorar-inp/"}
updated: "2026-10-17T23:33:38.384Z"
---
[Blog](https://dardo.studio/pt/blog/)
# Como melhorar o INP (Interaction to Next Paint): encontre a interação lenta e o script que a causa
O INP é bom com até 200 ms em 75% das visitas. Encontre o toque lento e o script dele com dados de campo e corrija o carregamento, o código ou a renderização.
Por [Nicolás Cerón](https://dardo.studio/pt/nicolas-ceron/) ·17 de outubro de 2026
## Pontos-chave
- O INP é bom quando 75% das visitas respondem a cliques, toques e teclas em até 200 milissegundos, e ruim acima de 500; ele substituiu o FID como Core Web Vital em 12 de março de 2024.
- Cada interação se divide em atraso de entrada, processamento e atraso de apresentação, e a parte longa diz se é preciso corrigir os scripts do carregamento, os manipuladores ou a renderização.
- A versão de atribuição da web-vitals e a API Long Animation Frames apontam o elemento, a parte lenta e a URL do script, o que separa o seu código do de um fornecedor.
- Em setembro de 2026, só 55,3% dos sites medidos no Brasil tinham INP bom no celular, contra 87,3% nos EUA; Tray (91,0%) e Loja Integrada (89,4%) foram bem, Next.js (40,2%) não.
- Parte da queda do Brasil em 2026 é de composição: em julho entraram cerca de 30 mil sites com Vue.js, só 15,8% com INP bom; sem eles, o país foi de 72,0% para 65,8%.
## A resposta curta
O INP (Interaction to Next Paint) é bom quando 75% das visitas respondem a cliques, toques e teclas em até 200 milissegundos, e ruim acima de 500 milissegundos. Para melhorar, primeiro encontre a interação lenta e o script que a causa com dados de campo (a versão de atribuição da web-vitals e a API Long Animation Frames). Depois corrija a parte da interação que está longa: o atraso de entrada (outro trabalho bloqueando a thread principal, quase sempre durante o carregamento), o processamento (seus manipuladores de eventos) ou a apresentação (a renderização que vem depois).
Em sites de marketing, a maior parte do INP ruim vem de três lugares: tags de terceiros rodando bem na hora do toque, a hidratação de frameworks durante o carregamento e manipuladores que fazem tudo antes de o navegador conseguir pintar a tela. Quebrar as tarefas longas e ceder a thread principal resolve quase tudo.
No Brasil, o INP é o ponto mais fraco. Em setembro de 2026, 97,6% dos sites do mundo tinham INP bom no desktop, mas só 55,3% dos sites medidos no Brasil tinham INP bom no celular, contra 87,3% nos Estados Unidos (dados abaixo).
Este guia trata só do INP. Para as três Core Web Vitals e como confirmar uma correção nos dados de 28 dias do Google, veja nosso [guia para melhorar os Core Web Vitals](https://dardo.studio/pt/blog/melhorar-core-web-vitals/).
## O que o INP mede, e o que não mede
O INP observa todos os cliques, toques e teclas de uma visita e informa o mais lento, ignorando um valor fora da curva a cada 50 interações ([web.dev](https://web.dev/articles/inp)). Passar o mouse por cima, rolar a página e dar zoom não contam. Uma página com a qual ninguém interagiu não tem INP, por isso páginas com pouco para tocar muitas vezes aparecem sem dados de INP.
Os limites, medidos no percentil 75 das visitas, separadamente para celular e desktop:
| INP no percentil 75 | Classificação |
| ---------------------------- | ---------------- |
| Até 200 ms | Bom |
| Acima de 200 ms e até 500 ms | Precisa melhorar |
| Acima de 500 ms | Ruim |
O INP substituiu o First Input Delay (FID) como Core Web Vital em 12 de março de 2024 ([web.dev](https://web.dev/blog/inp-cwv-launch)). A diferença importa para o diagnóstico: o FID só media a espera até os manipuladores da primeira interação começarem. O INP mede todas, do toque até o próximo quadro pintado, em três partes:
| Parte | O que é | Causa comum | Primeira correção |
| ------------------------ | ------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Atraso de entrada | Do toque até seus manipuladores começarem | Tarefas longas em andamento: avaliação de scripts, hidratação, tags, timers | Quebrar e adiar o trabalho do carregamento |
| Duração do processamento | Seus manipuladores rodando | Manipuladores que fazem tudo de uma vez; layout forçado | Pintar primeiro a mudança visível, ceder e depois fazer o resto |
| Atraso de apresentação | Do fim dos manipuladores até o quadro ser pintado | DOM grande, recálculos de estilo e layout, HTML gerado no cliente | Atualizações menores, content-visibility, menos DOM |
Dois detalhes confundem muitas equipes. Interações dentro de iframes contam para o INP da página nos dados do Chrome, mas o JavaScript da página não as enxerga, então a sua medição e a do CrUX podem divergir ([web-vitals](https://github.com/GoogleChrome/web-vitals)). E uma tarefa longa é qualquer tarefa acima de 50 milissegundos: o navegador não responde a uma entrada até a tarefa atual terminar ([web.dev](https://web.dev/articles/optimize-long-tasks)).
## Como os sites se saem no INP no Brasil, por plataforma
Lemos a [API do relatório de tecnologias do HTTP Archive](https://cdn.httparchive.org/v1/cwv?technology=ALL&geo=ALL&rank=ALL&start=latest) em 17 de outubro de 2026. A edição mais recente, de setembro de 2026, vem do Chrome UX Report: é a parcela de sites (origens) de cada plataforma cujos visitantes reais no Chrome, pelo celular, tiveram INP bom. Nosso [relatório de velocidade por plataforma](https://dardo.studio/pt/ferramentas/velocidade-plataformas-web/) mostra esses dados para todas as plataformas e métricas, com atualização mensal.
| Plataforma (celular, INP bom) | Brasil | Sites medidos no Brasil | Estados Unidos |
| ----------------------------- | ------ | ----------------------- | -------------- |
| Tray | 91,0% | 6.248 | – |
| Loja Integrada | 89,4% | 4.331 | – |
| Wix | 83,9% | 8.363 | 96,6% |
| Nuvemshop | 80,5% | 10.435 | – |
| WordPress | 78,8% | 93.195 | 92,6% |
| WordPress com Elementor | 76,7% | 50.629 | 94,4% |
| Astro | 67,7% | 2.715 | 92,6% |
| Shopify | 64,8% | 6.913 | 95,1% |
| Webflow | 61,9% | 2.549 | 92,4% |
| Framer | 57,6% | 724 | 88,2% |
| HubSpot CMS | 55,5% | 357 | 92,4% |
| Todos os sites | 55,3% | 469.002 | 87,3% |
| VTEX | 40,5% | 1.611 | 57,3% |
| Next.js | 40,2% | 37.921 | 75,9% |
| Nuxt | 32,4% | 6.468 | 83,9% |
Fonte: relatório de tecnologias do HTTP Archive, edição de setembro de 2026 (dados de campo do Chrome UX Report), celular. «–»: menos de 100 sites medidos nos EUA.
O que a tabela mostra:
- **O INP é um problema de celular.** No desktop, 97,6% de todos os sites do mundo tinham INP bom; no celular, 79,4%. Os sites em Next.js caem de 94,2% no desktop para 59,7% no celular, no mundo todo. É o mesmo código em processadores mais lentos.
- **O país pesa mais que a plataforma.** Um site em Webflow ou Shopify tem INP bom em 92–95% dos casos nos Estados Unidos e em 62–65% no Brasil. Nosso [estudo de Core Web Vitals no Brasil](https://dardo.studio/pt/blog/core-web-vitals-brasil/) explica por quê: as mesmas páginas, em celulares Android intermediários.
- **As plataformas brasileiras de loja virtual vão bem.** Tray (91,0%), Loja Integrada (89,4%) e Nuvemshop (80,5%) ficam bem acima da média do país; VTEX fica em 40,5%.
- **Frameworks de JavaScript falham no INP; o WordPress falha em outra coisa.** No Brasil, 78,8% dos sites em WordPress têm INP bom, acima da média, então o problema deles é sobretudo o carregamento. Next.js (40,2%) e Nuxt (32,4%) ficam muito abaixo: ali, o INP é a métrica que reprova.
### Por que o número do Brasil caiu em 2026
O INP bom no celular no Brasil passou de 55,0% em março de 2024 para 65,1% em abril de 2026, e caiu para 55,3% em setembro de 2026. Parte da queda é de composição, não de sites piorando. Em julho de 2026, o número de sites brasileiros medidos subiu de 435.398 para 470.301, e os sites com Vue.js passaram de 62.789 para 93.353, com só 15,8% de INP bom. Pela nossa conta, subtraindo os sites com Vue.js do total, o INP bom no Brasil foi de 72,0% em abril para 65,8% em setembro: ainda uma queda, mas de cerca de 6 pontos, não de 10.
Essa queda restante se parece com a de outros países: na Colômbia e no México, o INP bom caiu cerca de 3 pontos no mesmo período. No Chrome 147, o navegador mudou a forma de registrar interações para perder menos no CrUX; o Chrome diz que isso não muda a duração de cada interação, mas aumenta a cobertura ([registro de mudanças do Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics%5Fchangelog/2026%5F02%5Finp.md)). Com estes dados, não dá para separar quanto cada fator explica. A plataforma também é uma correlação, não um veredito: o que decide são os dados do seu próprio template.
### Sites com tags de terceiros comuns
O mesmo relatório pode ser filtrado por tecnologias detectadas no site, incluindo tags. Esta é a parcela de sites com INP bom no celular, no Brasil, entre os que usam cada tag:
| Tag no site | Tipo | Sites medidos no Brasil | INP bom (celular) |
| ------------------ | ---------------------- | ----------------------- | ----------------- |
| Todos os sites | – | 469.002 | 55,3% |
| CookieYes | Banner de cookies | 7.698 | 80,1% |
| JivoChat | Chat | 1.863 | 74,8% |
| RD Station | Automação de marketing | 13.192 | 63,7% |
| Google Tag Manager | Gerenciador de tags | 167.924 | 58,2% |
| Cookiebot | Banner de cookies | 2.002 | 56,6% |
| Pixel do Facebook | Anúncios | 112.577 | 54,2% |
| Zendesk | Chat e suporte | 16.043 | 52,8% |
| Hotjar | Gravação de sessões | 18.180 | 49,0% |
| OneTrust | Banner de cookies | 9.307 | 48,6% |
| Microsoft Clarity | Gravação de sessões | 43.713 | 46,7% |
| Pixel do TikTok | Anúncios | 18.770 | 39,8% |
| Intercom | Chat e suporte | 1.759 | 37,6% |
| VWO | Testes A/B | 1.641 | 37,5% |
| Optimizely | Testes A/B | 682 | 37,2% |
Fonte: relatório de tecnologias do HTTP Archive, setembro de 2026, celular, Brasil.
Leia com cuidado: a tabela descreve os sites que usam uma tag, não o custo da tag em si. Sites com Optimizely ou Intercom costumam ser maiores e carregar mais de tudo. O que vale de qualquer forma: o guia do Google sobre tags relata uma correlação entre o tamanho dos gerenciadores de tags e pontuações de INP piores ([web.dev](https://web.dev/articles/tag-best-practices)), e testes A/B, chat e gravação de sessões executam código na página enquanto as pessoas a usam.
## Passo 1: confirme que o problema é o INP, e em qual template
Comece pelos dados de campo do Google, primeiro no celular:
- **O** [**relatório de Core Web Vitals do Search Console**](https://support.google.com/webmasters/answer/9205520) agrupa URLs parecidas e mostra o INP de cada grupo no percentil 75 dos últimos 28 dias. Os grupos são ordenados por impressões, então a primeira URL de exemplo indica qual template corrigir primeiro. Um grupo pode aparecer sem dados de INP, porque o Search Console só exige dados suficientes de LCP e CLS para listá-lo.
- **O PageSpeed Insights** mostra os mesmos dados do Chrome para uma URL, ou para a origem inteira quando a URL tem poucas visitas. Confira qual dos dois você está lendo.
- **Sem nenhum dado de campo**, quase sempre o site tem poucos visitantes no Chrome para entrar no conjunto. Aí a sua própria medição é o único dado de campo que você terá.
O Web Almanac dá uma pista útil: em 2025, 80% das páginas iniciais no celular tinham INP bom, contra só 69% das outras páginas ([HTTP Archive](https://almanac.httparchive.org/en/2025/performance)). Páginas de listagem, de produto e qualquer uma com filtros são onde procurar.
## Passo 2: encontre a interação e o script, em campo
O CrUX diz que o INP está ruim, não por quê. Para saber por quê, colete a atribuição de visitas reais. A biblioteca [web-vitals](https://github.com/GoogleChrome/web-vitals) (versão 6.2.3, publicada em 5 de outubro de 2026) tem uma versão de atribuição que, para a interação mais lenta de cada visita, informa o elemento, as três partes, se a página ainda estava carregando e o script mais longo que coincidiu com ela.
```js
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution: a}) => {
const script = a.longestScript?.entry;
navigator.sendBeacon('/rum', JSON.stringify({
page: location.pathname,
inp: Math.round(value),
rating,
target: a.interactionTarget, // qual elemento foi tocado
loadState: a.loadState, // a página ainda carregava?
inputDelay: Math.round(a.inputDelay),
processing: Math.round(a.processingDuration),
presentation: Math.round(a.presentationDelay),
scriptURL: script?.sourceURL, // seu bundle ou o de um fornecedor
scriptInvoker: script?.invoker, // ex.: BUTTON.onclick
scriptPart: a.longestScript?.subpart,
}));
});
```
Os campos do script vêm da [API Long Animation Frames](https://developer.chrome.com/docs/web-platform/long-animation-frames) (LoAF), disponível desde o Chrome 123. Ela informa os quadros atrasados em mais de 50 milissegundos e nomeia cada script que rodou mais de 5 milissegundos neles, com URL, nome da função e como foi chamado. É assim que você separa o seu código do de um fornecedor. Limites: não há atribuição para scripts dentro de iframes de outra origem, e ela só existe em navegadores baseados no Chromium.
Você também pode observar a LoAF diretamente enquanto testa:
```js
new PerformanceObserver((list) => {
for (const frame of list.getEntries()) {
if (frame.blockingDuration < 100) continue;
for (const s of frame.scripts) {
console.log(Math.round(s.duration), s.invokerType, s.invoker, s.sourceURL);
}
}
}).observe({type: 'long-animation-frame', buffered: true});
```
A medição já vai além do Chrome: o README da web-vitals indica que `onINP()` funciona no Chromium, no Firefox e no Safari, agora que esses dois últimos expõem os dados de interação de que ela precisa. Os números de INP do Google continuam vindo só de usuários do Chrome, mas você já consegue ver se quem entra pelo iPhone sofre com a mesma interação lenta.
Depois agrupe os dados por elemento, estado de carregamento e parte mais longa. O padrão aponta a correção:
| O que os dados mostram | Causa provável | Vá para |
| ---------------------------------------------------------------------------- | --------------------------------------------------------------- | -------------------------- |
| Atraso de entrada longo, loadState «dom-interactive» ou «dom-content-loaded» | Avaliação de scripts, hidratação ou tags durante o carregamento | Tarefas longas; hidratação |
| Atraso de entrada longo depois do carregamento, scriptURL de um fornecedor | Timers ou listeners de uma tag | Tags de terceiros |
| Processamento longo, scriptURL do seu bundle | O próprio manipulador | Manipuladores caros |
| Processamento longo com estilo e layout forçados | Ler o layout depois de mudar estilos | Layout thrashing |
| Atraso de apresentação longo | Muita coisa para renderizar de novo | DOM grande |
## Passo 3: reproduza no Chrome DevTools
Abra o [painel Performance](https://developer.chrome.com/docs/devtools/performance/overview). Sem gravar, ele mostra o seu INP local enquanto você clica e lista cada interação com o elemento e as três partes. Conectado aos dados de campo, ele compara seus números locais com os dos visitantes reais e sugere ajustes para chegar perto deles.
Reduza a CPU para imitar os celulares dos seus visitantes: o DevTools calibra perfis de CPU que se aproximam de aparelhos de entrada e intermediários. No Brasil isso faz diferença, porque a distância para os Estados Unidos está justamente no celular. Grave enquanto toca o elemento apontado pelos dados de campo, de preferência com a página ainda carregando, quando a thread principal está mais ocupada. Na gravação, encontre a interação na faixa Interactions e leia as tarefas da thread principal logo abaixo; as tarefas longas levam um triângulo vermelho ([web.dev](https://web.dev/articles/optimize-long-tasks)).
Um teste de carregamento do Lighthouse não toca em nada, então não mede o INP. O Google sugere o Total Blocking Time como aproximação do atraso de entrada durante o carregamento, não como substituto ([web.dev](https://web.dev/articles/inp)).
## Correções, por causa
### Tarefas longas: quebre e ceda a thread principal
O navegador não responde enquanto uma tarefa roda, então divida o trabalho longo e devolva a thread principal entre as partes. `scheduler.yield()` faz isso e retoma o seu código antes de outro trabalho na fila. Ele está no Chrome e no Edge 129 e no Firefox 142, mas não no Safari em outubro de 2026, então use com uma alternativa ([web.dev](https://web.dev/articles/optimize-long-tasks)):
```js
function yieldToMain() {
if (globalThis.scheduler?.yield) return scheduler.yield();
return new Promise((resolve) => setTimeout(resolve, 0));
}
filterButton.addEventListener('click', async () => {
showSpinner(); // a resposta visível
await yieldToMain(); // deixa o navegador pintar
renderResults(filterProducts(state));
await yieldToMain();
sendAnalytics('filter_applied');
});
```
Em loops com muitos itens, ceda só quando tiverem passado uns 50 milissegundos desde a última vez, para o custo de ceder não se acumular. Duas armadilhas: `forEach` não espera um `await`, então use `for…of`; e o Google não recomenda mais `isInputPending()`.
### Tags de terceiros
As tags prejudicam o INP de duas formas: seus scripts fazem a entrada esperar durante o carregamento, e seus listeners rodam quando as pessoas clicam.
- **O botão Aceitar do banner de cookies.** Aceitar costuma disparar todas as tags de uma vez. Uma ferramenta de consentimento pode ceder logo após o clique para o banner fechar no quadro seguinte; a PubTech relatou que isso reduziu o INP nos sites de seus clientes em até 64% ([caso no web.dev](https://web.dev/case-studies/pubconsent-inp)). Se o seu fornecedor não faz isso, peça.
- **Dispare as tags não essenciais depois de Window Loaded** no Google Tag Manager, e prefira tags de imagem e modelos às tags de HTML personalizado, que o Google aponta como o tipo mais caro ([web.dev](https://web.dev/articles/tag-best-practices)).
- **Tire o que ninguém olha.** Scripts de gravação de sessões, mapas de calor e testes A/B esquecidos de um projeto antigo são comuns. O QuintoAndar, a maior plataforma de moradia do Brasil, removeu pixels de terceiros como parte do trabalho que, segundo a empresa, reduziu seu INP em 80% e veio acompanhado de 36% mais conversões na comparação anual ([caso no web.dev](https://web.dev/case-studies/quintoandar-inp)).
Use o `sourceURL` da LoAF para identificar o fornecedor antes de remover qualquer coisa, para a decisão se apoiar em dados, não em suspeita.
### Hidratação de frameworks grandes
Páginas renderizadas no servidor parecem prontas antes de estarem: a página não consegue responder à entrada até os scripts dos componentes rodarem e os manipuladores de eventos serem conectados, e esse custo aparece no INP ([web.dev](https://web.dev/articles/rendering-on-the-web)). Isso bate com a tabela acima, em que as linhas de frameworks de JavaScript ficam no fim.
- **Envie menos JavaScript de componentes.** No Next.js, tudo o que um arquivo marcado com `'use client'` importa vai para o bundle do cliente ([documentação do Next.js](https://nextjs.org/docs/app/getting-started/server-and-client-components)), então mantenha essa fronteira o mais baixo possível na árvore, só em volta da parte interativa.
- **Hidrate depois, ou só o que é interativo.** O Astro gera HTML estático e hidrata só os componentes que você marca, quando você decide ([documentação do Astro](https://docs.astro.build/en/concepts/islands/)):
```html
```
- **Marque como transições as atualizações do React que não são urgentes** com `useTransition`, para digitar continuar fluido enquanto os resultados renderizam de novo. O QuintoAndar usou transições assim ([caso no web.dev](https://web.dev/case-studies/quintoandar-inp)):
```jsx
const [isPending, startTransition] = useTransition();
function onSearchChange(e) {
setQuery(e.target.value); // urgente: o campo
startTransition(() => setResultsFilter(e.target.value)); // pode esperar
}
```
Se um framework é a ferramenta errada para um site de marketing quase estático, nossa comparação entre [Astro e Next.js](https://dardo.studio/pt/blog/astro-vs-nextjs/) explica quando cada um faz sentido.
### Manipuladores de eventos caros
Dentro do manipulador, faça só o que o próximo quadro precisa e deixe o resto para depois da pintura. Aplique debounce a manipuladores que disparam muitas vezes, como scroll, input e resize. E observe quanto trabalho uma única interação dispara: o site de passagens de ônibus redBus relatou que buscar 10 resultados por carregamento em vez de 30 levou essas interações de 870–900 para 350–370 milissegundos ([caso no web.dev](https://web.dev/case-studies/redbus-inp)).
### Layout thrashing
Ler uma propriedade de layout (`offsetWidth`, `getBoundingClientRect()`, `scrollHeight`) depois de mudar estilos obriga o navegador a calcular o layout na hora. Dentro de um loop, ele faz isso a cada volta ([web.dev](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing)):
```js
// Força um layout a cada volta depois da primeira
for (const bar of bars) {
bar.style.width = container.offsetWidth * bar.dataset.share + 'px';
}
// Leia uma vez e depois escreva
const width = container.offsetWidth;
for (const bar of bars) {
bar.style.width = width * bar.dataset.share + 'px';
}
```
A LoAF informa isso como `forcedStyleAndLayoutDuration` em cada script, e o DevTools marca a tarefa de Layout ou Recalculate Style com um triângulo vermelho.
### DOM grande e atualizações pesadas
O trabalho de renderização cresce com o tamanho do DOM, então gere menus, abas e listas longas quando forem necessários, não tudo de saída. O Economic Times removeu cerca de 1.200 nós ao gerar o menu só quando ele é aberto, parte do trabalho que levou seu INP de mais de 1.000 para 257 milissegundos ([caso no web.dev](https://web.dev/case-studies/economic-times-inp)).
Em páginas longas, `content-visibility: auto` pula a renderização das seções longe da área visível; na demonstração do Google, a renderização inicial caiu de 232 para 30 milissegundos ([web.dev](https://web.dev/articles/content-visibility)). Dê a cada seção um tamanho reservado para a barra de rolagem não pular:
```css
.long-page section {
content-visibility: auto;
contain-intrinsic-size: auto 900px;
}
```
A mesma página do web.dev indica suporte no Chrome 85, no Firefox 125 e no Safari 18. O conteúdo fora da tela continua na árvore de acessibilidade e pode ser encontrado com Ctrl+F.
## Confirme a correção
A sua medição mostra uma correção em dias. Os dados do Google, não: o Search Console e o PageSpeed Insights leem uma janela móvel de 28 dias, então uma correção publicada hoje aparece por completo umas quatro semanas depois. Publique uma correção de INP por versão quando puder e anote a data, para saber qual mudança mexeu no número. Nosso [guia de Core Web Vitals](https://dardo.studio/pt/blog/melhorar-core-web-vitals/) explica a validação no Search Console passo a passo.
## Checklist de INP
| Etapa | Pronto quando |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Encontrar o template que reprova | O Search Console aponta o grupo de URLs com INP ruim no celular |
| Coletar atribuição | Os dados de campo mostram o elemento, a parte mais longa e o script das interações mais lentas |
| Reproduzir | A mesma interação fica lenta no DevTools com a CPU calibrada para um celular intermediário |
| Corrigir o atraso de entrada no carregamento | Nem tags nem hidratação criam tarefas longas onde as pessoas tocam primeiro |
| Corrigir os manipuladores | A mudança visível é pintada antes do resto do trabalho |
| Corrigir a renderização | Sem layouts forçados nos manipuladores; páginas longas usam content-visibility |
| Confirmar | Seus dados melhoram em dias; os do Google, umas quatro semanas depois da publicação |
## O que fazer agora
Veja como os sites da sua plataforma se saem no país dos seus visitantes no nosso [relatório de velocidade por plataforma](https://dardo.studio/pt/ferramentas/velocidade-plataformas-web/), depois adicione ao seu site o trecho de atribuição da web-vitals acima e deixe uma semana de dados se acumular. Se preferir entregar o diagnóstico e as correções, é isso que faz nosso serviço de [otimização de velocidade de sites](https://dardo.studio/pt/servicos/otimizacao-de-velocidade-de-sites/), e reconstruir interfaces lentas é trabalho de [desenvolvimento web](https://dardo.studio/pt/servicos/desenvolvimento-web/).
## Perguntas frequentes
**O que é um INP bom?**
Até 200 milissegundos no percentil 75 das visitas, medido separadamente no celular e no desktop. Entre 200 e 500 milissegundos precisa melhorar, e acima de 500 é ruim. As ferramentas do Google informam o valor em uma janela móvel de 28 dias.
**Qual a diferença entre INP e FID?**
O First Input Delay só media a espera até os manipuladores da primeira interação começarem. O INP mede todos os cliques, toques e teclas de uma visita, da entrada até o próximo quadro pintado, e informa o mais lento, ignorando um valor fora da curva a cada 50 interações. Ele substituiu o FID em 12 de março de 2024.
**Por que meu INP é ruim no celular e bom no desktop?**
Os celulares rodam o mesmo JavaScript com processadores mais lentos, então uma tarefa curta num notebook pode virar uma tarefa longa num Android intermediário. Em setembro de 2026, 97,6% dos sites do mundo tinham INP bom no desktop e 79,4% no celular; no Brasil, 55,3%. Teste com a CPU calibrada para um celular intermediário.
**Por que o PageSpeed Insights não mostra INP para minha página?**
O INP só existe quando os visitantes clicam, tocam ou digitam, e os dados do Chrome só cobrem páginas e sites com visitas suficientes. Uma página com pouca interação, ou um site pequeno, pode não ter dados de INP. Nesse caso, meça nas suas próprias visitas com a biblioteca web-vitals.
**O scheduler.yield() funciona em todos os navegadores?**
Não. Em outubro de 2026 ele funciona no Chrome e no Edge 129 ou posteriores e no Firefox 142 ou posteriores, mas não no Safari. Use uma função auxiliar que chame scheduler.yield() quando ele existir e, se não, use uma promise com setTimeout, para todos os navegadores cederem a thread principal.
**Um plugin resolve o INP?**
Raramente sozinho. Plugins de cache e de imagens aceleram o carregamento, mas o INP depende de quais scripts rodam quando alguém toca, de quanto trabalho cada manipulador faz e de quanto a página renderiza de novo. Isso está nos seus templates, componentes e configuração de tags, e é ali que se corrige.
## Fontes e leituras adicionais
Fontes desta página, com mais detalhes dos publicadores originais.
- [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp) · web.dev
- [web.dev: Interaction to Next Paint is officially a Core Web Vital](https://web.dev/blog/inp-cwv-launch) · web.dev
- [web.dev: Optimize long tasks](https://web.dev/articles/optimize-long-tasks) · web.dev
- [HTTP Archive: API do relatório de tecnologias, Core Web Vitals (edição de setembro de 2026)](https://cdn.httparchive.org/v1/cwv?technology=ALL&geo=ALL&rank=ALL&start=latest) · cdn.httparchive.org
- [Chromium: mudanças do INP no Chrome 147](https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics%5Fchangelog/2026%5F02%5Finp.md) · chromium.googlesource.com
- [web.dev: Best practices for tags and tag managers](https://web.dev/articles/tag-best-practices) · web.dev
- [Ajuda do Search Console: relatório de Core Web Vitals](https://support.google.com/webmasters/answer/9205520) · support.google.com
- [HTTP Archive: Web Almanac 2025, Performance](https://almanac.httparchive.org/en/2025/performance) · almanac.httparchive.org
- [GoogleChrome no GitHub: biblioteca web-vitals](https://github.com/GoogleChrome/web-vitals) · github.com
- [Chrome for Developers: Long Animation Frames API](https://developer.chrome.com/docs/web-platform/long-animation-frames) · developer.chrome.com
- [Chrome for Developers: painel Performance](https://developer.chrome.com/docs/devtools/performance/overview) · developer.chrome.com
- [web.dev: caso da PubTech e sua plataforma de consentimento](https://web.dev/case-studies/pubconsent-inp) · web.dev
- [web.dev: como o QuintoAndar reduziu o INP em 80%](https://web.dev/case-studies/quintoandar-inp) · web.dev
- [web.dev: Rendering on the web](https://web.dev/articles/rendering-on-the-web) · web.dev
- [Documentação do Next.js: Server and Client Components](https://nextjs.org/docs/app/getting-started/server-and-client-components) · nextjs.org
- [Documentação do Astro: arquitetura de ilhas](https://docs.astro.build/en/concepts/islands/) · docs.astro.build
- [web.dev: como o redBus melhorou o INP](https://web.dev/case-studies/redbus-inp) · web.dev
- [web.dev: Avoid large, complex layouts and layout thrashing](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing) · web.dev
- [web.dev: Economic Times quest for fixing INP](https://web.dev/case-studies/economic-times-inp) · web.dev
- [web.dev: content-visibility](https://web.dev/articles/content-visibility) · web.dev
[Nicolás Cerón](https://dardo.studio/pt/nicolas-ceron/)
Nicolás Cerón é o fundador da Dardo, um estúdio de marca, design e desenvolvimento web em Bogotá, na Colômbia.
## Artigos relacionados
- [**Como melhorar os Core Web Vitals: guia baseado em dados de campo para sites de marketing**Descubra qual métrica e template falham no Search Console, corrija LCP, INP e CLS pela causa e confirme o resultado nos dados de campo cerca de 28 dias depois.](https://dardo.studio/pt/blog/melhorar-core-web-vitals/)
- [**Core Web Vitals no Brasil e na América Latina: quantos sites são aprovados por país (dados 2026)**Em setembro de 2026, só 33,7% dos sites foram aprovados nas Core Web Vitals no celular no Brasil, contra 63,3% nos EUA. Os dados por país e o que fazer.](https://dardo.studio/pt/blog/core-web-vitals-brasil/)
- [**Checklist de redesign de site: o que fazer antes, durante e depois do lançamento, com SEO**Checklist de redesign de site por fase: o que exportar primeiro, o que construir, como manter o SEO, o que testar no lançamento e o que acompanhar por 90 dias.](https://dardo.studio/pt/blog/checklist-redesign-de-site/)
- [**Astro vs Next.js: qual escolher para um site de marketing ou um produto em 2026**Astro para sites iguais para todos os visitantes, Next.js para produtos com login: renderização, JavaScript, hospedagem e suporte comparados.](https://dardo.studio/pt/blog/astro-vs-nextjs/)
## Continue explorando.
- [Serviço · **Otimização de velocidade de sites e Core Web Vitals**](https://dardo.studio/pt/servicos/otimizacao-de-velocidade-de-sites/)
- [Seu projeto · **Vamos conversar**](https://dardo.studio/pt/contato/)