Was ist INP – und warum es 2026 wichtiger ist als “nur Ladezeit”
Viele optimieren nur “Speed” (LCP), aber Nutzer merken vor allem, ob eine Seite schnell reagiert: Klick → passiert sofort etwas oder hängt die UI?
INP (Interaction to Next Paint) misst, wie schnell die Seite auf echte Interaktionen reagiert (z. B. Klicks, Tap, Tastatur) und wann danach ein visuelles Update sichtbar wird.
Gute INP-Werte bedeuten: weniger Frust, bessere Usability, höhere Conversion – und häufig auch bessere organische Performance, weil Nutzer länger bleiben und weniger abspringen.
Wichtig: INP ist oft ein JavaScript-Problem (Main-Thread-Blocker) – nicht primär ein “Server ist langsam”-Problem.
Typische Ursachen für schlechte INP (die du fast immer findest)
Zu viel JavaScript auf der Seite: große Bundles, unnötige Libraries, zu viele UI-Komponenten auf einmal.
Main-Thread-Blocker: lange Tasks (z. B. Rendering, Rehydration, komplexe Berechnungen) blockieren Interaktionen.
Third-Party-Skripte (Chat, Consent, Tracking, A/B-Tools): häufige Ursache für Ruckler und Input-Lag.
Schwere UI-Updates: wenn ein Klick eine große Re-Render-Kaskade auslöst (z. B. globale State-Updates).
Schlechte Event-Strategie: unnötige Listener, zu viel Arbeit im Handler, fehlendes Debounce/Throttle.
So misst du INP richtig (und nicht nur im “Lab”)
Unterscheide zwischen Lab-Tests (Lighthouse/PageSpeed) und Field-Daten (echte Nutzer). Lab ist gut zum Debuggen – Field zeigt die Wahrheit.
Nutze reale Nutzer-Messung (RUM): Tracke INP (und LCP/CLS) live, um Problemseiten und Gerätetypen zu identifizieren.
Wenn du “nur Lighthouse” optimierst, kannst du echte Probleme übersehen (z. B. Third-Party-Skripte, die in der echten Nutzung stärker zuschlagen).
Pragmatisch: Starte mit Lighthouse für Hypothesen, bestätige mit Feld-Daten, priorisiere dann nach Impact und Aufwand.
Quick Wins: 8 Maßnahmen, die INP oft sofort verbessern
1) Third-Party-Skripte reduzieren: Alles raus, was nicht direkt Umsatz/Leads bringt. Jeder zusätzliche Tag kann Interaktionen verschlechtern.
2) Skripte verzögert laden: Nicht alles “oben” laden – Consent/Tracking/Chat so steuern, dass die UI zuerst stabil reagiert.
3) Große Komponenten splitten: Code-Splitting, Lazy Loading, dynamische Imports für selten genutzte UI.
4) Bilder & Medien optimieren: Weniger Render-Work, weniger Layout-Stress, weniger Nebenwirkungen bei Interaktionen.
5) Lange Tasks finden und brechen: Arbeit in kleinere Einheiten aufteilen, keine schweren Berechnungen im Event-Handler.
6) Formulare entschlacken: weniger Validierungen “on type”, sinnvoller Debounce, serverseitige Validierung ergänzen.
7) UI-Updates reduzieren: nicht jedes kleine State-Update global machen – lokal halten, Memoization nutzen.
8) Fonts & CSS stabilisieren: weniger Layout-Sprünge helfen indirekt, weil weniger Re-Renders passieren.
Next.js: INP verbessern mit weniger JS, weniger Hydration, besseren Boundaries
In Next.js entsteht INP-Schmerz oft durch zu viel Client-JS (Hydration/Rehydration) und große UI-Bibliotheken.
Setze konsequent auf Server Components, wo möglich: Je weniger Client Components, desto weniger JS und weniger Main-Thread-Work.
Nutze dynamische Imports für schwere Komponenten (z. B. Karten, Charts, große UI-Widgets), die nicht sofort benötigt werden.
Achte auf State-Design: Globaler State (z. B. große Stores) kann bei kleinen Interaktionen riesige Re-Render-Ketten auslösen.
Halte Interaktionen “lokal”: Komponenten klein schneiden, Memoization sinnvoll einsetzen, Listen virtualisieren, wenn sie groß werden.
Script-Strategie: Alles, was nicht nötig ist, nach hinten (z. B. nach Consent oder nach erster Interaktion).
Astro: Warum Islands oft “gratis INP” bringen – und wie du es ausreizt
Astro ist für INP häufig ein Vorteil, weil du Standard-Content ohne Client-JS ausliefern kannst.
Nutze Islands-Architektur bewusst: Interaktivität nur dort, wo sie wirklich gebraucht wird (z. B. Formular, Filter, Slider).
Wähle die passende Hydration: “client:visible” oder “client:idle” statt “client:load”, wenn es möglich ist.
Vermeide große “All-in-one”-Islands: Lieber mehrere kleine Islands mit klarer Verantwortung als ein UI-Monolith.
Achte auf Third-Party: Auch in Astro kann ein schweres Tracking-/Consent-Setup deinen Main Thread blockieren.
Third-Party-Skripte: Der INP-Killer Nr. 1 (und wie du ihn zähmst)
Mach eine Inventur: Welche Skripte sind wirklich nötig? (Tracking, Chat, A/B, Heatmaps, Widgets)
Priorisiere “Business-Value”: Wenn ein Skript keinen klaren Nutzen bringt, raus damit.
Lade Skripte erst nach Consent bzw. erst nach stabiler Initial-UI. Viele Tools lassen sich so konfigurieren, dass sie später starten.
Nutze Partytown/Web Worker-Ansätze dort, wo es sinnvoll ist, um Third-Party-JS vom Main Thread fernzuhalten.
Teste nach jeder Änderung: INP kann sich durch ein einziges Tool massiv verändern – positiv wie negativ.
Checkliste: Was du konkret tun kannst (in der richtigen Reihenfolge)
1) Messen: INP in Feld-Daten identifizieren (welche Seiten, welche Geräte, welche Interaktionen).
2) Third-Party reduzieren/verschieben (größter Hebel).
3) JS-Bundle verkleinern: Code-Splitting, dynamische Imports, Libraries prüfen.
4) Hydration reduzieren: In Next.js weniger Client Components; in Astro Islands klein & gezielt.
5) Lange Tasks debuggen und brechen: Event-Handler, Rendering, schwere Berechnungen.
6) UI-Architektur verbessern: State lokal halten, Re-Renders minimieren.
7) Regression verhindern: Performance-Budget + regelmäßiger Audit in CI oder per Monitoring.
8) Nach Launch beobachten: echte Nutzer zeigen dir, ob es wirklich besser wurde.
Fazit: INP ist kein “Feinschliff” – sondern ein echter Conversion-Hebel
Wenn deine Website schnell reagiert, fühlt sie sich hochwertig an – und Nutzer gehen den nächsten Schritt eher mit.
Gerade bei Next.js-Projekten entscheidet die Menge an Client-JS oft über “butterweich” vs. “ruckelig”.
Astro kann dir eine starke Basis geben – aber nur, wenn du Interaktivität bewusst als Islands planst.
Wenn du willst, prüfen wir deine wichtigsten Seiten, finden die echten INP-Bremsen und liefern dir eine priorisierte To-do-Liste, die schnell Wirkung zeigt.
Du willst bessere Core Web Vitals (und eine schnellere Website, die mehr Anfragen bringt)? Wir machen ein Performance-Audit inkl. Maßnahmenplan für Next.js/Astro – priorisiert nach Impact.
