Entrega de imagens focada em INP 2025 — Proteger a performance percebida com coordenação de decode/priority/scripts

Introdução

Melhorar o LCP é central, mas em 2024–2025 muitos ignoram o INP (Interaction to Next Paint). Decodificação pesada de imagens ou inicialização no main thread perto da primeira interação pode atrasar a resposta. Quando "rajadas de lazy‑load", decodificação e inicialização de scripts acontecem logo após o primeiro toque/rolagem, frames caem e o input fica lento.

Este guia prioriza “eliminar overserving a partir do layout” e organiza práticas que protegem o INP em decode/priority/lazy e coordenação com scripts. Mostramos como dividir papéis entre a imagem hero e as abaixo da dobra, como usar Next.js (App Router) e APIs do navegador, e como verificar com RUM.

TL;DR

• Corte o overserving primeiro (desenhe sizes/srcset a partir do layout)
• Use priority/fetchPriority="high" apenas para candidatos a LCP; para não‑LCP, decoding="async" + lazy
• Evite concorrência de carregamento/decodificação/inicialização ao redor da primeira entrada (coordenação de tempo)
• Placeholder não deve causar CLS (LQIP/BlurHash)

Para sizes/srcset e redimensionamento em detalhes, veja Imagens responsivas em 2025 — Guia prático de srcset/sizes e Workflows de redimensionamento em 2025 — Corte 30–70% de desperdício a partir do layout.

Por que as imagens podem piorar o INP (modelo mental)

O navegador faz “fetch → decode → layout/paint”. O INP mede da entrada até o próximo paint. Se houver decodificação pesada ou relayout logo antes/depois do processamento de entrada, o INP piora.

• Se vários lazy‑loads disparam após a entrada, o main thread enche (decode/layout) e os eventos atrasam
• Imagens superdimensionadas demoram mais para decodificar (overserving prejudica LCP e INP)
• Inicialização de scripts (parallax, filtros, Canvas) colide com a decodificação

Remédio em três frentes: “tamanho certo”, “prioridade seletiva” e “separação temporal (coordenação)”.

Padrões em Next.js (App Router)

<Image
  src="/hero-1536.avif"
  alt="Imagem hero do produto"
  fill
  sizes="(max-width: 768px) 100vw, 768px"
  priority
  fetchPriority="high"
  decoding="sync"
/>

<Image
  src="/gallery-640.webp"
  alt="Galeria"
  width={640}
  height={360}
  sizes="(max-width: 768px) 100vw, 768px"
  loading="lazy"
  decoding="async"
/>

Notas:

• Apenas LCP usa sync/priority/high; os demais ficam em lazy/async
• sizes correto permite a escolha ideal da fonte (evite overserving)

Lazy granular e coordenação de scripts

• Evite decodificação/inicialização pesada na janela de 300–500 ms ao redor da entrada
• IntersectionObserver: pré‑carregue um pouco antes da visibilidade, evitando colisões logo após a entrada
• Inits longas (Canvas/filtros) com idle/scheduler

let lastInput = 0;
['pointerdown','keydown','wheel','touchstart'].forEach((t) => {
  addEventListener(t, () => (lastInput = performance.now()), { passive: true });
});

export function scheduleAfterInput(task: () => void) {
  const dt = performance.now() - lastInput;
  if (dt < 300) setTimeout(task, 300 - dt);
  else requestIdleCallback(() => task());
}

Placeholders e CLS

Defina width/height ou aspect‑ratio e use LQIP/BlurHash. Veja Design de placeholders LQIP/SQIP/BlurHash — Guia prático 2025.

Medição

• RUM (web‑vitals) para INP
• Long Tasks depois da entrada
• Lighthouse Timespan para cenários de interação

Resumo

Proteja o INP com “eliminar overserving”, “atribuir prioridade corretamente” e “manter trabalhos pesados fora da janela de entrada”. Some coordenação temporal às iniciativas de LCP, monitore com RUM e proíba priority fora do hero via lint/CI.