Infraestrutura Web · Série Técnica GEO · Negócio no Mapa
Como otimizar INP: guia completo de Core Web Vitals 2026
INP ≤ 200ms é a métrica que decide se o Google considera sua página rápida o bastante em 2026. Aqui está o guia completo — o que causa INP ruim, como medir, e a mesma explicação técnica que uso em auditoria: main thread bloqueado é, estruturalmente, o mesmo gargalo que trava uma GPU esperando dado de memória.
Esta página é contextualização, não descoberta nova — pego um padrão que já expliquei em profundidade (o gargalo de memory bandwidth em GPU, nas duas páginas anteriores desta série) e mostro que o mesmo princípio estrutural aparece no lado completamente diferente da minha atuação: performance de site para SEO técnico.
Pra mim: registrar publicamente que o mesmo raciocínio de sistemas — recurso rápido esperando recurso lento — atravessa domínios que a maioria trata como desconexos. Pra Negócio no Mapa: uma auditoria técnica de SEO (já publicada nesta série) ganha vocabulário mais preciso quando “site lento” vira “main-thread bound”, não afirmação vaga. Pro mercado: a maior parte do conteúdo brasileiro sobre Core Web Vitals trata INP como checklist de ferramenta — aqui está o porquê estrutural, não só o “o quê corrigir”.
O paralelo, lado a lado
| Conceito | Infraestrutura de IA | SEO técnico / WebPerf |
|---|---|---|
| O gargalo | Memory bandwidth bound — GPU esperando dado da HBM | Main thread bound — navegador travado processando JS |
| O sintoma | Lentidão na geração de token | Atraso de clique, tela congelada (INP ruim) |
| A métrica | Tokens/segundo, GB/s de banda | Milissegundos — INP bom é ≤200ms |
| A solução | Quantização, FlashAttention, redução de I/O | Code-splitting, adiar script não essencial, reduzir Long Task |
A métrica INP substituiu o antigo FID (First Input Delay) como Core Web Vital oficial em março de 2024 — e mede algo mais completo: não só o atraso do primeiro clique, mas a latência de toda interação relevante durante a visita à página.
Impacto real em negócio, com fonte verificada
Números soltos de “aumento de conversão” circulam bastante em conteúdo de INP — vale usar só os que têm estudo de caso público e verificável por trás:
| Caso | Melhoria de INP | Resultado de negócio |
|---|---|---|
| QuintoAndar | 1.006ms → 216ms (-80%) | +36% conversões ano a ano |
| Economic Times | ~4x mais rápido | +43% pageviews, -50% bounce rate |
| Disney+ Hotstar | -61% | +100% visualizações de card (TV/sala) |
| redBus | 870-900ms → 350-370ms | ~7% aumento em vendas |
Vale a ressalva de método: todos esses são comparativos antes/depois de RUM (Real User Monitoring), não experimento controlado — sazonalidade e outras mudanças simultâneas podem ter contribuído, não é isolamento causal puro. Mesmo assim, a convergência de direção (INP melhor → métrica de negócio melhor) em casos de setores diferentes é evidência razoável, não prova definitiva.
Três APIs modernas para atacar o problema na origem
scheduler.yield()
API moderna de agendamento que devolve controle à main thread no meio de uma tarefa pesada, de forma mais previsível que setTimeout(0) — o navegador processa interações pendentes antes de retomar o trabalho.
requestAnimationFrame
Sincroniza atualização visual com o próximo repaint do navegador — usado para dar feedback visual imediato (ex: estado “pressionado” de um botão) antes de processar o resto da lógica da interação, o que o usuário percebe como resposta instantânea mesmo que o trabalho completo ainda não tenha terminado.
content-visibility: auto
Propriedade CSS que instrui o navegador a pular cálculo de layout e renderização de conteúdo fora da área visível, adiando esse trabalho até o elemento entrar em cena — reduz o custo de renderização inicial em páginas longas sem mudar a estrutura do HTML.
O culpado técnico: Long Tasks
Quando um script roda por mais de 50 milissegundos de uma vez, ele bloqueia a Main Thread — a única linha de execução que processa JavaScript, layout e pintura de tela na maioria dos navegadores. Enquanto essa tarefa não termina, nenhuma interação do usuário é processada, mesmo que o clique já tenha acontecido.
Yielding to the main thread
Técnica de fragmentar código para devolver controle à thread principal em intervalos curtos, permitindo que interações do usuário sejam processadas entre uma fatia de trabalho e outra.
Breaking up Long Tasks
Dividir uma tarefa longa (ex: processar um array grande) em pedaços menores que cabem sob o limite de 50ms — o análogo direto de dividir a matriz de atenção em blocos que cabem na SRAM, no FlashAttention.
Forced synchronous layout (layout thrashing)
Quando código força o navegador a recalcular o layout repetidamente — ler uma propriedade de layout logo depois de escrever no DOM força recálculo síncrono, multiplicando o tempo de trabalho da Main Thread.
O debate arquitetural: CSR vs. SSR
Sites inteiramente renderizados no cliente (SPAs pesadas em React ou Vue puro) transferem todo o custo de processamento para o dispositivo do visitante — inclusive dispositivos Android de entrada, com CPU limitada. Isso não afeta só o usuário: impacta diretamente o orçamento de rastreamento do Googlebot, já que renderizar JavaScript custa mais recurso computacional do robô do que ler HTML pronto — exatamente o mesmo processo de duas ondas de indexação que já detalhamos na página de metodologia de auditoria desta série.
O debate internacional de SSR vs. CSR e o debate de quantização de LLM resolvem o mesmo dilema de fundo: processar tudo de uma vez no cliente/GPU é simples de implementar, mas caro em runtime; pré-processar (SSR / pesos quantizados) custa mais na preparação, mas reduz drasticamente o custo em tempo real, quando importa de verdade.
O que auditar na prática
- 01 Meça Long Tasks antes de qualquer otimização de conteúdo. Um site com INP ruim compromete conversão independente de quão bem otimizado o texto está para GEO — sequência importa, como já vimos na metodologia de auditoria desta série.
- 02 Trate JavaScript de terceiro como suspeito primário. Scripts de tag manager, chat, pixel de anúncio — frequentemente são a origem de Long Task, não o código próprio do site.
- 03 Para site orientado a conteúdo (o caso mais comum em GEO), prefira SSR ou geração estática. Menos dependência de hidratação client-side reduz simultaneamente INP ruim para o usuário e custo de renderização para o robô — o mesmo benefício, dois lados.
Fontes: web.dev / Google Search Central, “Interaction to Next Paint (INP)” — métrica oficial desde março de
2024, substituindo First Input Delay (FID); W3C, “Long Tasks API” — limite de 50ms; casos reais publicados
em web.dev/case-studies: QuintoAndar, Economic Times, Disney+ Hotstar, redBus; MDN Web Docs, Scheduler API
(scheduler.yield()) e propriedade CSS content-visibility; documentação de
orçamento de rastreamento e custo de renderização (Web Rendering Service), já referenciada na página de
metodologia de auditoria técnica desta série. O número “14,3% de aumento de conversão”, presente em
material anterior e atribuído a “estudos de caso do web.dev”, não corresponde a nenhum caso publicado
localizável e foi substituído nesta versão pelos números reais acima.