INP‑fokussierte Bildauslieferung 2025 — decode/priority/Skript‑Koordination für spürbare Performance

Einführung

LCP steht oft im Fokus, doch 2024–2025 wird INP (Interaction to Next Paint) leicht übersehen. Schwere Bilddekodierung oder Main‑Thread‑Initialisierung direkt um die erste Interaktion verschlechtern die Reaktionszeit. Treffen „Lazy‑Load‑Burst“, Dekodierung und Skript‑Init unmittelbar nach dem ersten Scroll/Klick zusammen, fallen Frames aus und Eingaben wirken träge.

Dieser Leitfaden stellt „Overserving aus dem Layout entfernen“ an den Anfang und ordnet Maßnahmen, die INP schützen: Dekodierung/Priorität steuern, Lazy Loading dosieren und Skripte zeitlich koordinieren. Wir zeigen Rollenverteilung zwischen Hero und nachgelagerten Bildern, den Einsatz von Next.js (App Router) und Browser‑APIs sowie Verifikation mit RUM.

TL;DR

• Overserving zuerst abstellen (sizes/srcset aus dem Layout ableiten)
• priority/fetchPriority="high" nur fr LCP‑Kandidaten; Nicht‑LCP mit decoding="async" + Lazy
• Keine Rennen zwischen Bildladen/Dekodierung/Skriptinit kurz vor/nach der Eingabe
• Platzhalter ohne CLS (z. B. LQIP/BlurHash)

Weiterführend: Responsive Bildgestaltung 2025 — Praxisleitfaden zu srcset/sizes und Resize‑Workflows 2025 — Vom Layout rückwärts 30–70 % Verschwendung streichen.

Warum Bilder INP verschlechtern können (Modell)

Der Browser arbeitet „Netzwerk → Dekodierung → Layout/Render“. INP misst „Eingabe bis nächster Paint“. Läuft schwere Dekodierung oder Relayout direkt an der Eingabe vorbei, steigt INP.

Muster, die INP verschlechtern

• Dekodierung übergroßer Bilder parallel zur Eingabeverarbeitung
• Burst von Lazy‑Loads unmittelbar nach der ersten Interaktion
• Aufwändige Initialisierung (Canvas/Filter/Animation) blockiert den Main‑Thread

Gegenmuster (Kurzüberblick)

• rootMargin nutzen (200–400px) und Laden staffeln
• priority strikt nur am Hero/LCP; sonst loading="lazy"/decoding="async"
• Schwere Initialisierung via requestIdleCallback oder (wo möglich) scheduler.postTask zeitlich absetzen

Next.js‑Muster (App Router)

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

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

Hinweise:

• Nur LCP‑Kandidaten verwenden sync/priority/high
• Korrektes sizes ermöglicht optimale Quellauswahl; Overserving schadet LCP/INP

Lazy‑Granularität und Koordination

• 300–500 ms rund um Eingaben keine schweren Dekodierungen/Initialisierungen
• IntersectionObserver: knapp vor Sichtbarkeit vorladen, Kollisionen vermeiden
• Lange Inits (Canvas/Filter) per Idle/Scheduler schieben

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());
}

Platzhalter und CLS

Breite/Höhe oder aspect‑ratio definieren, leichte LQIP/BlurHash einsetzen. Siehe Platzhalter-Design LQIP/SQIP/BlurHash — Praxis 2025.

Messung

• RUM (web‑vitals) für INP sammeln
• Long Tasks nach Eingaben beobachten
• Lighthouse‑Timespan für Interaktionsszenarien

Zusammenfassung

INP schützen Sie mit den drei Hebeln „Overserving beenden“, „Priorität korrekt vergeben“ und „schwere Arbeiten vom Eingabefenster fernhalten“. Ergänzen Sie LCP‑Maßnahmen um Zeitkoordinierung, beobachten Sie mit RUM und verbieten Sie priority außerhalb des Heros per Lint/CI.