Entrega de imágenes enfocada en INP 2025 — Proteger la performance percibida con coordinación de decode/priority/scripts

Introducción

Mejorar LCP es clave, pero en 2024–2025 muchos equipos pasan por alto INP (Interaction to Next Paint). La decodificación de imágenes pesadas o la inicialización en el hilo principal justo alrededor de la primera interacción puede retrasar la respuesta. Cuando se acumulan “ráfagas de lazy‑load”, decodificación e inicialización de scripts justo después del primer toque/desplazamiento, caen los frames y se siente lentitud.

Esta guía pone primero “eliminar la sobre‑entrega desde el layout” y luego organiza prácticas que protegen INP en decode/priority/lazy y coordinación con scripts. Mostramos cómo dividir roles entre la imagen hero y las de debajo del pliegue, cómo usar Next.js (App Router) y APIs del navegador, y cómo verificar con RUM.

TL;DR

• Corta la sobre‑entrega primero (diseña sizes/srcset desde el layout)
• Usa priority/fetchPriority="high" solo para candidatos a LCP; para no‑LCP, decoding="async" + lazy
• Evita que carga/decodificación/inicialización compitan alrededor de la primera entrada (coordina el tiempo)
• El placeholder no debe causar CLS (LQIP/BlurHash, etc.)

Para sizes/srcset y redimensionado en detalle, ve a Diseño de imágenes responsivas 2025 — Guía práctica de srcset/sizes y Arquitectura de redimensionamiento en 2025 — Reducir un 30–70% el desperdicio partiendo del layout.

Por qué las imágenes pueden empeorar INP (modelo mental)

El navegador hace “descarga → decodifica → layout/pintado”. INP mide de entrada al siguiente paint. Si una decodificación pesada o un re‑layout cae justo antes/después del manejo de entrada, INP empeora.

• Si los lazy‑loads se disparan en masa tras la primera interacción, el hilo principal se llena de decode/layout y los eventos se retrasan
• Imágenes sobredimensionadas tardan más en decodificar (la sobre‑entrega daña LCP e INP)
• Inicialización de scripts (parallax, filtros, Canvas) colisiona con la decodificación

El remedio es triple: “talla correcta”, “prioridad selectiva” y “separación temporal (coordinación)”.

Patrones que dañan INP

• Decodificación de imágenes sobredimensionadas junto con el procesamiento de entrada
• Ráfaga de lazy‑loads inmediatamente después de la primera interacción
• Inicialización costosa (Canvas/filtros/animaciones) bloquea el hilo principal

Más que el peso bruto, el problema es la colisión temporal.

Antipatrones y arreglos rápidos

• Convertir muchas offscreen a eager justo al empezar a desplazar → usa rootMargin y escalona 200–400px antes
• Abusar de priority fuera del hero en dispositivos lentos → limítalo estrictamente al LCP
• Decodificar muchas imágenes mientras corren animaciones/CSS/Canvas → aplaza el trabajo con idle/scheduler

Patrones en Next.js (App Router)

// Hero: candidato a LCP (en vista en render inicial)
<Image
  src="/hero-1536.avif"
  alt="Imagen principal del producto"
  fill
  sizes="(max-width: 768px) 100vw, 768px"
  priority
  fetchPriority="high"
  decoding="sync"
/>

// Debajo del pliegue: no‑LCP (poco antes de entrar en vista)
<Image
  src="/gallery-640.webp"
  alt="Galería"
  width={640}
  height={360}
  sizes="(max-width: 768px) 100vw, 768px"
  loading="lazy"
  decoding="async"
/>

Notas:

• Solo los LCP usan sync/priority/high; el resto permanece lazy/async
• Con sizes correcto, el navegador elige la fuente óptima (evitas sobre‑entrega)

Granularidad de lazy y coordinación con scripts

• Evita decodificación/inicialización pesada en la ventana de 300–500ms alrededor de la entrada
• IntersectionObserver: precarga un poco antes de la visibilidad, sin choques justo tras la entrada
• Largas inits (Canvas/filtros) via requestIdleCallback o scheduler.postTask

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 y CLS

Especifica dimensiones (width/height o aspect‑ratio) para evitar CLS; usa LQIP/BlurHash. Ver Diseño de placeholders LQIP/SQIP/BlurHash — Guía práctica 2025.

Medición

• RUM (web‑vitals) para INP
• Long Tasks tras la entrada
• Lighthouse Timespan para escenarios de interacción

Resumen

Protege INP con tres palancas: “eliminar sobre‑entrega”, “asignar prioridad correctamente” y “mantener trabajo pesado lejos de la ventana de entrada”. Añade coordinación temporal a tu trabajo de LCP, monitorea con RUM y prohíbe priority fuera del hero con lint/CI.