Performance

INP em 2026: a métrica que está a destruir scores e como recuperar

Em março de 2024, o Google substituiu o FID pelo INP como Core Web Vital. O efeito foi imediato e brutal: sites que tinham scores verdes durante anos passaram a amarelo ou vermelho da noite para o dia — sem mudar uma linha de código. Em 2026, INP continua a ser a métrica que mais separa sites bem feitos dos que parecem rápidos mas não respondem.

Este guia explica o que INP mede mesmo, porque é que o teu site falha sem aviso, e os passos concretos para recuperar.

O que INP mede (sem jargão)

INP — Interaction to Next Paint — mede o tempo entre o utilizador interagir com a página e o ecrã atualizar a mostrar o resultado.

Tipos de interação contabilizadas:

  • Clicks em botões e links.
  • Toques em ecrã táctil.
  • Pressões de tecla (em inputs, áreas editáveis).

Não conta: hover, scroll.

O navegador mede todas as interações durante a visita e regista o pior caso (ou perto disso — usa percentil 75 para sites com muitas interações). É essa pior interação que é reportada.

Para o Google:

  • Bom: < 200 ms.
  • Precisa melhoria: 200-500 ms.
  • Mau: > 500 ms.

Porque é que o FID era falso (e o INP é honesto)

O FID (First Input Delay) só media o tempo de espera entre clique e o navegador começar a processar. Não media quanto tempo o processamento demorava, nem quanto tempo até o utilizador ver o resultado.

Resultado: um site com botão que demora 800ms a responder mas começava a processar em 30ms tinha FID excelente. Mau para o utilizador, ótimo para a métrica.

O INP mede o ciclo completo: clique → handler → render. Não engana. É por isso que tantos sites "rápidos" caíram.

As causas mais comuns de INP mau

Em auditorias a sites de PME portuguesa, os culpados repetem-se:

1. JavaScript de terceiros a competir pela main thread

Tag Manager + Meta Pixel + chat widget + Hotjar — cada um corre handlers próprios. Quando o utilizador clica num botão, a main thread já está ocupada com os scripts deles. O click espera.

Tratamento: gated por consentimento, defer/async, lazy load. Ver javascript pesado no site.

2. Event handlers pesados

onClick que faz validação síncrona de 1MB de dados, ou que processa array de 10.000 itens. Comum em filtros de loja online mal feitos.

Tratamento: requestIdleCallback, setTimeout(fn, 0) para diferir, ou Web Workers para processamento pesado.

3. Re-renders desnecessários

Em React/Next.js, um setState que dispara re-render de toda a árvore quando só um botão devia atualizar. Em WordPress + Elementor, é o mesmo problema multiplicado.

Tratamento: memoização (useMemo, React.memo), separar componentes, atualizar só o que mudou.

4. Animações CSS pesadas durante interação

Hover effects com box-shadow ou filter: blur em grandes áreas. Cada repaint força recálculo. Em mobile, INP sobe a 600ms.

Tratamento: animar transform e opacity (compostos por GPU), evitar width/height/box-shadow em animação.

5. Layout thrashing

JavaScript lê o DOM, modifica, lê outra vez, modifica outra vez — força o navegador a recalcular layout várias vezes por frame.

Tratamento: separar reads e writes. Usar requestAnimationFrame.

6. Plugins WordPress que adicionam handlers globais

Plugins de "cookies", popups, ou newsletter que injetam handler em document.body a escutar todos os clicks. Bom para tracking deles, mau para o teu INP.

Como medir INP do teu site

Dados de campo (real)

  • PageSpeed Insights — mostra INP do CrUX (dados de Chrome agregados dos últimos 28 dias). É o que o Google usa para rankear.
  • Search Console → Core Web Vitals — relatório por grupo de páginas.
  • web-vitals.js — biblioteca que mede INP de visitantes reais e envia para Analytics.

Sem dados de campo, voas às cegas. Os dados de laboratório (Lighthouse) não calculam INP porque não há interação real.

Dados de laboratório (simulação)

  • Chrome DevTools → Performance → Insights — interage com a página enquanto gravas. Mostra "Long Animation Frames" — INP por proxy.
  • Chrome DevTools → Performance → Throttle — simula CPU 4x slower (mobile médio) e Slow 3G.

A diferença entre desktop e mobile no INP é dramática. Sempre testa com throttle mobile.

Passos práticos para reduzir INP

Passo 1 — gated tracking

Move GTM, Meta Pixel, Hotjar para carregamento gated por consentimento de cookies + defer. Ganho típico: -100 ms de INP.

Passo 2 — auditar e cortar plugins

Para WordPress: identifica plugins que adicionam JS a todas as páginas. Desativa esquecidos. Substitui pesados. Ganho típico: -50 a -150 ms.

Passo 3 — adiar trabalho não-crítico

Para handlers complexos:

button.addEventListener('click', () => {
  // Atualiza UI imediatamente (rápido)
  showLoadingState();

  // Adia trabalho pesado para depois do paint
  requestIdleCallback(() => {
    doExpensiveWork();
  });
});

Ganho: utilizador vê resposta em <50ms. Trabalho de fundo continua sem prejudicar INP.

Passo 4 — yield to the main thread

Para tarefas longas (>50ms), parte em chunks:

async function processItems(items) {
  for (const item of items) {
    await scheduler.yield(); // permite ao navegador atualizar
    process(item);
  }
}

scheduler.yield() é a API moderna (Chrome 129+). Para compatibilidade, setTimeout(fn, 0) funciona.

Passo 5 — animação por transform

Substituir:

/* Mau: causa layout + paint */
.button:hover { width: 110%; box-shadow: 0 0 20px ...; }

por:

/* Bom: GPU compositing */
.button:hover { transform: scale(1.1); }

Exemplos de WordPress: o que arranjar primeiro

Para um site WordPress típico (tema + 20 plugins + GTM):

  1. Ativar consentimento de cookies real, com tracking gated. Reduz INP ~100-150ms em mobile.
  2. Substituir Contact Form 7 + add-ons por form leve (Fluent Forms Lite ou similar). -30 a -80ms.
  3. Desativar chat widget e carregar on interação. -100ms.
  4. Substituir slider Revolution por algo leve (Swiper). -50ms.
  5. Adicionar defer ao tema e plugins (via plugin Async JavaScript). -50 a -100ms.

Total típico: passar de INP 600ms a 200ms em 4-8 horas de trabalho.

Exemplos de Next.js: o que vigiar

Sites Next.js bem feitos arrancam em INP <100ms. Quando ficam piores:

  • Componentes client gigantes ("use client" no layout raiz é gatilho).
  • Bibliotecas de animação pesadas (Framer Motion sem code split).
  • Tracking via tag manager em vez de next/script com strategy="afterInteractive".
  • State management global a disparar re-renders em árvore.

Casos reais comuns

Caso 1 — loja WooCommerce com filtro de produtos lento. Filtro AJAX dispara request a cada toggle de checkbox. Cada request bloqueia main thread 400-800ms até responder. Tratamento: debounce de 300ms antes de disparar; loading state imediato; mover trabalho para Web Worker. Resultado: INP de 700ms para 180ms.

Caso 2 — site institucional com Elementor + chat Tawk. Tawk carrega em head, bloqueia interação durante 500ms-1s. Tratamento: lazy load do Tawk para depois de primeira interação. Resultado: INP de 450ms para 150ms.

Caso 3 — blog WordPress com tema lento. Tema injeta jQuery 3.6 + Slick Carousel + Magnific Popup em todas as páginas. Tratamento: dequeue de bibliotecas onde não são usadas (via hook wp_enqueue_scripts). Resultado: INP de 380ms para 190ms.

Os padrões repetem-se. Reconhecer o teu caso poupa horas de diagnóstico.

Diferença entre INP do site e INP por página

O Search Console agrupa páginas com URL similar e reporta INP por grupo. Erro comum: ler "site tem INP mau" e otimizar a homepage. Mas o problema é só na página de checkout ou na página de pesquisa interna.

Boa prática: olhar para cada grupo de URLs separadamente no Search Console. Otimizar onde dói.

INP e conversão — o número que vende a otimização

Estudos da web.dev e da Google sobre Core Web Vitals mostram correlação entre INP e abandono:

  • Sites que passaram de INP "mau" para "bom": +10 a +18% em taxa de conversão.
  • Sites de e-commerce: cada 100ms a menos no INP de uma página de produto correlaciona com +1.5% de adds-to-cart.

Não é causal direto, mas o sinal é forte. Para CEO, traduz-se em: "investir uma semana a baixar INP paga-se em 2 meses se a loja faz 5.000€/mês."

O ganho em SEO

INP é Core Web Vital. Faz parte do ranking factor "Page Experience". Sites que passam de "mau" a "bom" em INP veem subida no Search Console em 2-6 semanas — não dramática (o INP é só um dos sinais), mas mensurável.

Mais importante: INP correlaciona com conversão. Uma loja com INP 500ms tem mais 15-25% de abandono de carrinho do que uma com INP 200ms. O Google rankeia isso indiretamente, mas o teu negócio sente direto.

Em resumo

INP em 2026 é a métrica honesta de Core Web Vitals — mede o ciclo completo de interação, não só o início. Os culpados típicos são JavaScript de terceiros sem gated por consentimento, plugins WordPress excessivos, event handlers pesados, e animações CSS mal feitas. Diagnostica com Search Console (campo real) + DevTools Performance (simulação). Resolves a maioria com 4-8 horas de trabalho: tracking gated, cortar plugins esquecidos, defer no que sobra, e adiar trabalho não-crítico para depois do paint. Alvo: INP <200ms para mobile. Quem chega lá nota dois efeitos — sobe no Google, e cai abandono na própria loja.

No sitesfixe.pt construímos sites e lojas com INP <200ms à partida — tracking gated, plugins auditados, sem bibliotecas de animação a competir por main thread. Se o teu site falhou Core Web Vitals em INP, fala connosco. Sites desde 1.500€. Lojas online desde 3.500€.

Lê também:

Fontes

Precisas de um site ou loja online?

Agência digital portuguesa. Sites e lojas online rápidos, otimizados para o Google e feitos para resultado.

Pedir orçamento