Was INP misst
Interaction to Next Paint misst die Zeit von einer Nutzerinteraktion bis zur nächsten sichtbaren Aktualisierung des Bildschirms. Berücksichtigt werden:
- Mausklicks
- Tippen auf Touchscreens
- Tastatureingaben
Nicht berücksichtigt werden Scrollen und Mausbewegungen ohne Klick.
Anders als der frühere Wert First Input Delay, der nur die erste Interaktion und nur die Wartezeit bis zum Beginn der Verarbeitung erfasste, betrachtet INP alle Interaktionen eines Besuchs und die gesamte Zeit bis zur sichtbaren Reaktion. Gemeldet wird im Wesentlichen die langsamste Interaktion, bei sehr vielen Interaktionen wird ein hoher Perzentilwert verwendet, um einzelne Ausreißer abzufedern.
| Bewertung | INP-Wert |
|---|---|
| gut | bis 200 Millisekunden |
| verbesserungswürdig | 200 bis 500 Millisekunden |
| schlecht | über 500 Millisekunden |
Die drei Phasen einer Interaktion
Jede Interaktion lässt sich in drei Abschnitte zerlegen:
| Phase | Was passiert | Typische Ursache für Verzögerung |
|---|---|---|
| Eingabeverzögerung (Input Delay) | Zeit, bis der Browser mit der Verarbeitung beginnen kann | Hauptthread ist mit anderen Aufgaben beschäftigt |
| Verarbeitungszeit (Processing Time) | Ausführung der Event-Handler | aufwendiger Code im Klick- oder Eingabehandler |
| Darstellungsverzögerung (Presentation Delay) | Berechnung von Layout und Neuzeichnen | große DOM-Änderungen, komplexes Layout |
Warum der Hauptthread entscheidend ist
Browser führen JavaScript, Layout-Berechnungen und das Zeichnen der Seite überwiegend auf einem einzigen Hauptthread aus. Solange dort eine Aufgabe läuft, kann der Browser nicht auf Eingaben reagieren. Aufgaben, die länger als 50 Millisekunden dauern, nennt man Long Tasks. Viele solcher Aufgaben während des Ladens oder nach einer Interaktion führen zu schlechten INP-Werten.
Typische Verursacher langer Aufgaben:
- große JavaScript-Bündel, die beim Laden ausgeführt werden
- Hydration von Frameworks, bei der die gesamte Seite auf einmal „belebt“ wird
- Tracking-, Marketing- und Analyse-Skripte
- Chat-Widgets, Bewertungs-Widgets, Social-Media-Einbettungen
- Page Builder mit umfangreichem Laufzeit-Code
- Consent-Management-Plattformen
- Event-Handler, die bei jedem Klick aufwendige Berechnungen oder große DOM-Änderungen auslösen
Langsame Interaktionen finden
Felddaten
Die Search Console und PageSpeed Insights zeigen, ob eine Seite oder Seitengruppe beim INP durchfällt. Sie zeigen nicht, welche Interaktion das Problem verursacht.
Messung bei echten Nutzern
Die Web-Vitals-Bibliothek von Google kann bei echten Besuchern erfassen, welches Element angeklickt wurde, wie lange die einzelnen Phasen dauerten und welche Skripte beteiligt waren. Diese Daten lassen sich an Google Analytics oder ein anderes Werkzeug senden. Das ist die zuverlässigste Methode, um die eigentlichen Ursachen zu finden.
Chrome DevTools
Im Bereich „Performance“ können Sie eine Aufnahme starten, die fragliche Interaktion ausführen und anschließend sehen, welche Aufgaben den Hauptthread blockiert haben. Mit gedrosselter CPU lassen sich schwächere Mobilgeräte simulieren – wichtig, weil schnelle Entwicklerrechner Probleme oft verdecken.
Lighthouse und Total Blocking Time
Im Labor lässt sich INP nicht direkt messen, weil keine echten Interaktionen stattfinden. Die Total Blocking Time (TBT) ist ein guter Anhaltspunkt: Sie misst, wie lange der Hauptthread während des Ladens blockiert ist.
Maßnahmen zur Verbesserung
Weniger JavaScript
Die wirksamste Maßnahme ist fast immer, weniger JavaScript auszuführen:
- nicht genutzte Plugins, Widgets und Bibliotheken entfernen
- Code aufteilen und nur laden, was auf der jeweiligen Seite gebraucht wird
- Drittanbieter-Skripte kritisch prüfen: Wird jedes Tracking-Tool wirklich genutzt?
- schwere Einbettungen erst bei Bedarf laden, etwa Karten oder Videos nach einem Klick auf ein Vorschaubild
Lange Aufgaben aufteilen
Wenn Code nötig ist, sollte er in kleineren Stücken laufen, damit der Browser zwischendurch auf Eingaben reagieren kann. Moderne Techniken dafür sind scheduler.yield() oder das Aufteilen mit setTimeout beziehungsweise requestIdleCallback. Wichtig ist das Prinzip: dem Browser regelmäßig Gelegenheit geben, andere Aufgaben zu erledigen.
Event-Handler schlank halten
In einem Klick-Handler sollte nur das Nötigste passieren, damit die sichtbare Reaktion sofort erfolgt. Aufwendige Arbeiten wie das Senden von Analysedaten oder das Nachladen von Inhalten können danach erfolgen.
button.addEventListener('click', async () => {
menu.classList.add('offen'); // sofort sichtbare Reaktion
await scheduler.yield?.(); // dem Browser Zeit zum Zeichnen geben
sendeAnalyseEreignis('menu_open'); // nicht sichtbare Arbeit danach
});
DOM klein halten
Sehr große Seiten mit Zehntausenden Elementen brauchen bei jeder Änderung lange für Layout und Zeichnen. Vereinfachte Vorlagen, weniger verschachtelte Container und das Nachladen großer Listen erst bei Bedarf helfen.
Hydration optimieren
Bei JavaScript-Frameworks verursacht die Hydration oft die größten Blockaden. Ansätze wie teilweise Hydration, Island-Architekturen oder Server Components reduzieren die Menge an JavaScript, die im Browser ausgeführt werden muss.
Consent-Banner und Tag Manager prüfen
Consent-Lösungen und Tag Manager laden oft zahlreiche weitere Skripte. Eine Bereinigung der Tags, das verzögerte Laden nicht kritischer Tags und eine schlanke Consent-Lösung bringen häufig deutliche Verbesserungen.
Ein Möbelhändler mit WordPress und einem umfangreichen Page Builder hatte auf Mobilgeräten einen INP von über 600 Millisekunden. Die Messung bei echten Nutzern zeigte, dass fast alle langsamen Interaktionen das Öffnen des Menüs und das Aufklappen von Filtern betrafen. Ursachen waren ein Slider-Plugin, das auf allen Seiten geladen wurde, ein Chat-Widget, das beim Laden über 300 Millisekunden blockierte, und neun Tracking-Tags. Nach dem Entfernen des Sliders auf Seiten ohne Slider, dem verzögerten Laden des Chats nach der ersten Interaktion und der Reduktion der Tags auf vier lag der INP nach vier Wochen bei 170 Millisekunden.
INP und Plattformen
| Plattform | Typische INP-Probleme |
|---|---|
| WordPress mit Page Builder | viele Skripte, große DOMs, Plugins auf allen Seiten |
| Shopify | Apps, die Skripte in jede Seite einfügen |
| Shopware, Magento | große Themes, viele Module |
| React-, Vue-, Angular-Anwendungen | Hydration, große Bündel |
| Websites mit viel Werbung | Werbeskripte und Auktionen |
Kurz beantwortet
Warum ist INP schlechter als früher FID?
INP ist strenger, weil alle Interaktionen und die gesamte Zeit bis zur Darstellung zählen. Viele Websites, die bei FID problemlos grün waren, fallen bei INP durch.
Beeinflusst INP das Ranking?
INP ist Teil der Core Web Vitals und damit der Signale für die Seitenerfahrung. Wie bei den anderen Kennzahlen gilt: Relevanz und Inhalt haben Vorrang, bei vergleichbaren Seiten kann die Seitenerfahrung den Ausschlag geben.
Kann ich INP ohne Programmierkenntnisse verbessern?
Teilweise. Das Entfernen überflüssiger Plugins, Apps und Tracking-Skripte ist ohne Programmierung möglich und bringt oft viel. Für tiefergehende Optimierungen am Code ist Entwicklerwissen nötig.