INP optimieren: Interaction to Next Paint verbessern
Seit März 2024 ist Interaction to Next Paint (INP) offizieller Core Web Vital und hat First Input Delay (FID) vollständig abgelöst (Google web.dev, 2024). Während FID nur die Verzögerung der allerersten Interaktion gemessen hat, bewertet INP jede einzelne Nutzeraktion über den gesamten Seitenbesuch hinweg. Für viele Websites ist das die mit Abstand schwierigste der drei Core-Web-Vitals-Metriken, weil sie direkt von der JavaScript-Ausführung auf dem Main Thread abhängt. Dieser Artikel erklärt, wie INP technisch funktioniert, woran sich schlechte Werte erkennen lassen und mit welchen konkreten Maßnahmen Sie die Latenz unter die 200-Millisekunden-Schwelle bringen – von Long Tasks über Event-Handler bis hin zu Drittanbieter-Skripten.
Was INP misst und warum es so schwer zu optimieren ist
INP misst die Reaktionsfähigkeit einer Website über die gesamte Sitzung hinweg. Bei jeder Interaktion – Klick, Tippen auf dem Touchscreen oder Tastendruck – erfasst der Browser die Zeit zwischen der Eingabe und dem nächsten sichtbaren Bildschirm-Update. Am Ende des Besuchs wird die langsamste (genauer: nahezu langsamste) Interaktion als INP-Wert berichtet. Der Schwellenwert von 200 Millisekunden gilt als gut, bis 500 Millisekunden als verbesserungsbedürftig und alles darüber als schlecht (Google web.dev, 2024). Anders als bei FID reicht es also nicht, dass die erste Aktion schnell ist – jede Filteränderung, jedes Öffnen eines Menüs und jeder Klick auf den Warenkorb-Button zählt.
Genau das macht INP zur anspruchsvollsten Metrik. Laut Auswertungen des HTTP Archive Web Almanac (2024) erreichen rund drei Viertel der mobilen Websites einen guten INP-Wert, während die Quote bei der Vorgängermetrik FID nahe 100 Prozent lag (HTTP Archive Web Almanac, 2024). Der Sprung in der Schwierigkeit ist kein Zufall: INP deckt strukturelle Probleme der JavaScript-Architektur auf, die FID systematisch übersehen hat. Wer die Frontend-Optimierung ernst nimmt, muss die Arbeit auf dem Main Thread grundlegend neu denken.
Der zentrale Engpass ist der Main Thread – der einzige Thread im Browser, der gleichzeitig JavaScript ausführt, das Layout berechnet und das Rendering anstößt. Ist dieser Thread durch eine langlaufende Aufgabe belegt, kann der Browser eine wartende Nutzerinteraktion nicht verarbeiten. Die Eingabe landet in einer Warteschlange und wird erst abgearbeitet, wenn der Thread wieder frei ist. Genau diese Wartezeit fließt als Input Delay in den INP-Wert ein. INP zu optimieren bedeutet daher vor allem, den Main Thread frei und reaktionsbereit zu halten.
Die drei Phasen einer Interaktion verstehen
Jede Interaktion zerfällt in drei messbare Phasen, deren Summe den INP-Wert ergibt. Wer optimieren will, muss zuerst wissen, in welcher Phase die Zeit verloren geht – denn die Gegenmaßnahmen unterscheiden sich grundlegend. Die Input Delay ist die Zeit zwischen der Nutzeraktion und dem Start des zugehörigen Event-Handlers. Sie entsteht fast immer, weil der Main Thread im Moment der Eingabe noch mit einer anderen Aufgabe beschäftigt ist. Die Processing Time ist die reine Ausführungsdauer der Event-Handler. Die Presentation Delay ist die Zeit, die der Browser nach dem Handler benötigt, um Stil, Layout und Paint des nächsten Frames zu berechnen.
Input Delay
Der Main Thread ist durch eine laufende Aufgabe blockiert, wenn die Eingabe eintrifft. Lösung: Long Tasks aufbrechen, Skript-Ausführung beim initialen Laden zeitlich entzerren, weniger Arbeit beim Start einplanen.
Processing Time
Der Event-Handler selbst läuft zu lange. Lösung: nur das visuell Notwendige sofort erledigen, schwere Berechnungen verschieben oder in Web Worker auslagern, teure Layout-Lesezugriffe vermeiden.
Presentation Delay
Das Rendering des nächsten Frames dauert. Lösung: DOM-Updates klein halten, content-visibility für Offscreen-Bereiche nutzen, große synchrone Layout-Berechnungen vermeiden.
Diese Aufschlüsselung ist der wichtigste diagnostische Hebel. Eine hohe Input Delay deutet auf Probleme beim initialen Laden hin – typischerweise große JavaScript-Bundles, die den Thread beim Hydrieren blockieren. Eine hohe Processing Time verweist auf schwere Event-Handler, etwa synchrone Datenverarbeitung oder umfangreiche DOM-Manipulationen direkt im Klick-Handler. Eine hohe Presentation Delay schließlich entsteht durch teures Rendering, etwa wenn ein einzelner Klick eine vollständige Neuberechnung des Layouts über tausende DOM-Knoten auslöst. Erst wenn klar ist, welche Phase dominiert, lässt sich gezielt optimieren.
INP korrekt messen: Feld vor Labor
INP lässt sich – anders als LCP – nicht zuverlässig im Labor messen. Lighthouse und synthetische Tests führen keine echten Nutzerinteraktionen aus, weshalb ihre INP-Schätzungen erheblich von der Realität abweichen können. Google verwendet ausschließlich Felddaten aus dem Chrome UX Report (CrUX) für die Bewertung, aggregiert über das 75. Perzentil aller Nutzer (Google web.dev, 2024). Das bedeutet: Die Optimierung muss an echten Nutzerdaten ausgerichtet werden, nicht an einem isolierten Laborwert. PageSpeed Insights zeigt sowohl die CrUX-Felddaten als auch die Lab-Diagnose und ist damit der erste Anlaufpunkt für eine Standortbestimmung.
Für die laufende Überwachung im echten Betrieb empfiehlt sich Real User Monitoring (RUM). Die quelloffene Bibliothek web-vitals.js von Google erfasst INP direkt im Browser jedes Besuchers und liefert pro Interaktion das Zielelement sowie die Aufschlüsselung in die drei Phasen (Google web.dev, 2024). Seit 2023 steht zusätzlich die Long Animation Frames API (LoAF) zur Verfügung, die einzelne langlaufende Frames inklusive der verursachenden Skripte aufschlüsselt (W3C, 2024). In Kombination ermöglichen diese Werkzeuge eine seitengenaue Zuordnung: Welche Interaktion auf welcher Vorlage ist langsam, und welches Skript ist verantwortlich? Genau diese Zuordnung steht am Anfang jeder strukturierten Performance-Analyse.
Praxistipp: INP im Feld debuggen
Long Tasks aufbrechen: der wirkungsvollste Hebel
Ein Long Task ist jede JavaScript-Ausführung, die den Main Thread länger als 50 Millisekunden am Stück blockiert (W3C Long Tasks Specification). Während eines Long Tasks kann der Browser keine Eingaben verarbeiten – jede Interaktion in diesem Fenster startet mit einer entsprechenden Input Delay. Long Tasks sind damit die häufigste Einzelursache schlechter INP-Werte. Die Lösung besteht nicht darin, die Arbeit zu eliminieren, sondern sie in kleinere Häppchen zu zerlegen und dem Browser zwischendurch die Kontrolle zurückzugeben (Yielding).
Das moderne Mittel der Wahl ist die scheduler.yield()-API, die seit Chrome 129 in stabilen Versionen verfügbar ist (Google web.dev, 2024). Sie unterbricht einen laufenden Task, lässt wartende Interaktionen vor und setzt die Arbeit anschließend mit hoher Priorität fort – im Gegensatz zum klassischen setTimeout(0), das die Fortsetzung ans Ende der Warteschlange stellt. Wo scheduler.yield() noch nicht verfügbar ist, dient ein Aufruf von setTimeout als Fallback. Wichtig ist, an natürlichen Grenzen zu unterbrechen: nach jedem verarbeiteten Element einer langen Schleife oder zwischen logisch abgeschlossenen Arbeitsschritten.
// Lange Verarbeitung in Chunks zerlegen und dem Browser
// regelmaessig die Kontrolle zurückgeben (Yielding).
async function yieldToMain() {
if ('scheduler' in window && 'yield' in scheduler) {
return scheduler.yield();
}
// Fallback für Browser ohne scheduler.yield()
return new Promise((resolve) => setTimeout(resolve, 0));
}
async function processItems(items) {
let lastYield = performance.now();
for (const item of items) {
handleItem(item); // teure Einzelverarbeitung
// Nach mehr als 50ms ununterbrochener Arbeit unterbrechen
if (performance.now() - lastYield > 50) {
await yieldToMain();
lastYield = performance.now();
}
}
}Das Beispiel zeigt das Grundmuster: Statt eine lange Schleife in einem Rutsch abzuarbeiten, misst der Code die verstrichene Zeit und gibt nach jeweils rund 50 Millisekunden die Kontrolle ab. Eine Nutzerinteraktion, die in dieser Zeit eintrifft, wird sofort verarbeitet, statt bis zum Ende der gesamten Schleife zu warten. Für die Praxis lassen sich zwei weitere Strategien kombinieren: nicht dringende Arbeit über requestIdleCallback in die Leerlaufphasen des Browsers verlegen und das Sichtbare zuerst rendern, bevor unsichtbare Bereiche verarbeitet werden. Diese Priorisierung nach Sichtbarkeit reduziert die wahrgenommene Latenz spürbar.
Event-Handler entschlacken und Arbeit verschieben
Die zweite Phase – die Processing Time – wird direkt von der Arbeit im Event-Handler bestimmt. Eine verbreitete Fehlannahme lautet, dass der Handler bei einem Klick alles sofort erledigen muss. Tatsächlich genügt es, das visuelle Feedback unmittelbar zu liefern und alle übrigen Aufgaben aufzuschieben. Wer einen Button drückt, erwartet, dass sich der Button sofort verändert – ob im Hintergrund ein Tracking-Event versendet oder ein Datensatz neu berechnet wird, ist für die wahrgenommene Reaktionsfähigkeit zweitrangig und gehört in den Kern jeder Frontend-Optimierung. Die Aufteilung in "sofort sichtbar" und "kann warten" ist der Schlüssel zu kurzen Handlern.
Konkret heißt das: Im Handler wird nur die unmittelbare DOM-Änderung vorgenommen, danach folgt ein Yield, und erst anschließend laufen Analytics, Persistierung oder Folgeberechnungen. Rechenintensive Operationen ohne DOM-Bezug – Sortierung großer Listen, Datenparsing, Bildverarbeitung, Verschlüsselung – gehören in einen Web Worker, der in einem eigenen Thread läuft und den Main Thread vollständig entlastet. Bei Eingabefeldern und Scroll-Ereignissen verhindern Debouncing und Throttling, dass jeder Tastendruck eine teure Verarbeitung auslöst. Diese Techniken zahlen direkt auf die Processing Time ein.
| INP-Problem | Typische Ursache | Phase | Wirksame Gegenmaßnahme |
|---|---|---|---|
| Erste Klicks reagieren träge | Großes JS-Bundle blockiert beim Hydrieren | Input Delay | Code-Splitting, weniger JS beim Start, Yielding |
| Filter und Sortierung hängen | Synchrone Neuberechnung im Handler | Processing Time | Web Worker, Debouncing, inkrementelles Rendern |
| Menüs öffnen verzögert | JavaScript-Animation statt CSS | Presentation Delay | CSS-Transitions, transform statt Layout-Properties |
| Tippen im Suchfeld ruckelt | Verarbeitung bei jedem Tastendruck | Processing Time | Debouncing, requestIdleCallback |
| Klick auf langer Liste langsam | Layout-Neuberechnung über viele Knoten | Presentation Delay | content-visibility, Virtualisierung |
| Reaktion nach Seitenaufruf stockt | Drittanbieter-Skripte belasten Thread | Input Delay | async/defer, Lazy Load bei Interaktion |
Die Tabelle macht deutlich, dass dasselbe Symptom – eine träge Interaktion – sehr unterschiedliche Ursachen haben kann. Ohne die Phasen-Diagnose aus den Felddaten besteht die Gefahr, an der falschen Stelle zu optimieren. Ein Team, das Wochen in das Verschlanken von Event-Handlern investiert, obwohl das eigentliche Problem ein blockierendes Drittanbieter-Skript beim Laden ist, verbessert den INP-Wert kaum. Deshalb steht die Messung immer am Anfang, bevor eine einzige Codezeile geändert wird.
Drittanbieter-Skripte: der unterschätzte INP-Killer
Analytics-Tags, Consent-Manager, Chat-Widgets, A/B-Testing-Tools und Social-Media-Embeds laufen auf demselben Main Thread wie der eigene Anwendungscode. Sie sind eine der häufigsten Ursachen für schlechte INP-Werte, weil sie Arbeit ausführen, auf die der Betreiber nur begrenzten Einfluss hat. Besonders problematisch sind Skripte, die globale Event-Listener registrieren und bei jeder Interaktion mitlaufen – etwa Heatmap- und Session-Recording-Werkzeuge, die jeden Klick und jede Mausbewegung erfassen. Diese unsichtbare Last summiert sich über den Besuch und drückt den INP-Wert nach oben.
Die wirksamste Maßnahme ist eine konsequente Ladestrategie. Skripte, die nicht für die erste Bildschirmdarstellung nötig sind, werden mit async oder defer geladen, idealerweise erst nach der ersten Nutzerinteraktion oder beim Eintritt in den sichtbaren Bereich (Intersection Observer). Ein Chat-Widget muss nicht beim Seitenaufruf vollständig geladen sein – es genügt, einen leichten Platzhalter anzuzeigen und das eigentliche Widget beim ersten Klick nachzuladen. Für Tracking lohnt sich der Blick auf serverseitige Lösungen und einen First-Party-Proxy, der die Last vom Browser des Nutzers nimmt.
- Jedes Drittanbieter-Skript einzeln auf seinen INP-Impact prüfen, nicht pauschal vertrauen
- Nicht kritische Skripte erst nach der ersten Interaktion oder beim Scrollen laden
- Chat-Widgets und schwere Embeds per Klick lazy laden statt beim Seitenaufruf
- Globale Event-Listener von Tracking-Tools auf das Nötigste begrenzen
- Consent-Manager schlank halten und nicht das gesamte Rendering blockieren lassen
- Tracking-Events über requestIdleCallback statt synchron im Klick-Handler senden
Reaktionsfähigkeit ist Conversion-relevant
Rendering und Presentation Delay verkürzen
Die dritte Phase – die Presentation Delay – wird oft übersehen, kann aber erheblich zum INP-Wert beitragen. Sie entsteht, wenn der Browser nach dem Event-Handler viel Arbeit für den nächsten Frame leisten muss: Stilberechnung, Layout und Paint über einen großen Teil des Dokuments. Ein klassischer Auslöser ist eine DOM-Änderung, die ein Layout Thrashing verursacht – das wiederholte Lesen und Schreiben von Layout-Eigenschaften im Wechsel, das den Browser zu mehrfachen synchronen Neuberechnungen zwingt. Die Lösung besteht darin, alle Lesezugriffe zu bündeln und erst danach alle Schreibzugriffe auszuführen.
Die CSS-Eigenschaft content-visibility: auto erlaubt es dem Browser, Offscreen-Bereiche zunächst vom Rendering auszunehmen und erst zu berechnen, wenn sie in den Sichtbereich gelangen (Google web.dev). Das reduziert die Menge an Layout-Arbeit pro Frame deutlich, besonders bei langen Seiten mit vielen Sektionen. Für Animationen gilt die Faustregel, ausschließlich die Eigenschaften transform und opacity zu animieren, die der Browser auf einer eigenen Compositing-Ebene ohne Layout-Neuberechnung verarbeiten kann. Animationen über Properties wie width, height oder top hingegen erzwingen teure Layout-Durchläufe und verlängern die Presentation Delay.
INP zwingt uns, ehrlich zu sein: Eine Seite ist nicht schnell, weil sie schnell lädt, sondern weil sie auf jede Aktion des Nutzers sofort antwortet. Die erste Sekunde gehört dem Laden – jede weitere gehört der Reaktionsfähigkeit.
Ein typischer INP-Optimierungspfad in der Praxis
Ein wiederkehrendes Muster aus der Praxis zeigt, wie die Maßnahmen ineinandergreifen. Ausgangslage: Ein Online-Shop auf Basis von Shopware CE meldet im Chrome UX Report einen INP-Wert im verbesserungsbedürftigen Bereich, deutlich über 200 Millisekunden – ein häufiges Szenario in der Shopware-Performance-Optimierung. Die Felddaten weisen die Produktlistenseite mit ihren Filtern als größten Verursacher aus. Die Phasen-Diagnose über die Long Animation Frames API zeigt, dass der Großteil der Latenz in der Processing Time entsteht – bei jeder Filteränderung wird die gesamte Produktliste synchron neu berechnet und neu gerendert (Projekterfahrung).
Der Optimierungspfad setzt an drei Punkten an. Erstens wird die Neuberechnung der Filter aus dem synchronen Klick-Handler gelöst und mit Yielding in kleinere Schritte zerlegt, sodass die Liste schrittweise aktualisiert wird, ohne den Thread zu blockieren. Zweitens werden zwei Tracking-Skripte, die bislang synchron im Filter-Handler ihre Events senden, auf requestIdleCallback umgestellt. Drittens reduziert content-visibility die Rendering-Last für die zahlreichen Produktkacheln unterhalb des sichtbaren Bereichs. In der Summe rückt der INP-Wert in den guten Bereich – ohne dass eine einzige Funktion entfernt wurde (Projekterfahrung). Vergleichbare Ausgangslagen begegnen uns in vielen Projekten quer durch Branchen und Vorlagen-Typen.
Wichtig ist die abschließende Validierung im Feld. Da CrUX-Daten als rollierender 28-Tage-Durchschnitt aktualisiert werden, zeigt sich die Wirkung einer Optimierung erst mit einigen Wochen Verzögerung in den offiziellen Werten. Bis dahin liefert das eigene Real User Monitoring den schnelleren Rückkanal. Genau diese Kombination aus Diagnose, gezielter Maßnahme und Feld-Validierung steht im Zentrum jeder Core-Web-Vitals-Optimierung, die wir für Shops und Unternehmenswebsites umsetzen.
INP dauerhaft halten: Monitoring und Budgets
Ein guter INP-Wert ist kein Endzustand, sondern muss aktiv gehalten werden. Jedes neue Drittanbieter-Skript, jedes Plugin-Update und jede zusätzliche Funktion kann den Main Thread zusätzlich belasten. Deshalb gehört INP in ein kontinuierliches Monitoring mit Schwellenwert-Alerts, das eine Verschlechterung meldet, bevor sie sich auf das Ranking auswirkt. Auf Vorlagen-Ebene zu überwachen ist dabei entscheidend: Die Origin-Bewertung in CrUX kann gut sein, während eine einzelne stark frequentierte Vorlage – etwa der Checkout – schlechte Werte liefert und so unbemerkt Umsatz kostet.
Ergänzend bewähren sich Performance-Budgets im Entwicklungsprozess. Eine Obergrenze für die JavaScript-Menge, die beim initialen Laden ausgeführt wird, verhindert, dass die Input Delay durch wachsende Bundles schleichend ansteigt. Tools für die kontinuierliche Integration prüfen diese Budgets bei jedem Deployment und schlagen an, sobald eine Grenze überschritten wird – noch bevor die Änderung live geht. So bleibt die mühsam erreichte Reaktionsfähigkeit auch über viele Releases hinweg erhalten. Die Verbindung aus Felddaten-Monitoring und Budget-Kontrolle ist fester Bestandteil unserer Performance-Leistungen – für eine erste Einschätzung Ihrer INP-Werte vereinbaren Sie ein unverbindliches Erstgespräch.
INP im Zusammenspiel mit den übrigen Vitals
Ein Blick auf die Transportebene lohnt sich ebenfalls: Eine schnellere Auslieferung der Ressourcen verkürzt das Zeitfenster, in dem der Main Thread mit dem initialen Laden beschäftigt ist, und reduziert damit indirekt die Input Delay. Wie moderne Protokolle hier wirken, erläutern wir im Beitrag zu HTTP/3 und QUIC für die Shop-Performance. In Kombination mit den hier beschriebenen Main-Thread-Maßnahmen entsteht ein Gesamtbild, in dem sich Lade- und Interaktionsgeschwindigkeit gegenseitig verstärken.