INP verbessern heißt: Du findest zuerst die Interaktionen, die in echten Besuchen langsam sind, und kürzt dann gezielt die Phase, in der die Zeit verloren geht: die Wartezeit bis zum Start deines Codes, die Laufzeit der Event-Handler oder das Zeichnen der sichtbaren Änderung. Das Ziel von Google liegt bei höchstens 200 Millisekunden, gemessen am 75. Perzentil der Seitenaufrufe. Meist hilft es am meisten, lange JavaScript-Aufgaben aufzuteilen, weniger Arbeit direkt im Klick-Handler zu erledigen und das DOM schlank zu halten.
Diese Anleitung zeigt dir, wie du INP misst, die Ursache einer trägen Interaktion eingrenzt und welche Maßnahmen zu welcher Phase passen. Allgemeine Tipps zu Bildern, Caching und Plugins findest du im Beitrag Wie machst du deine WordPress-Website schneller? – hier geht es gezielt um die Reaktionszeit auf Klicks, Taps und Tastatureingaben.
Was misst INP genau?
Interaction to Next Paint (INP) bewertet, wie schnell eine Seite sichtbar auf Eingaben reagiert. Gemessen wird laut Erklärung von INP auf web.dev die Zeit vom Beginn einer Interaktion bis zu dem Moment, in dem der Browser den nächsten Frame mit der Reaktion darstellt. Berücksichtigt werden Klicks, Taps und Tastatureingaben. Hovern, Zoomen und Scrollen zählen nicht.
Anders als der frühere Messwert First Input Delay (FID) schaut INP nicht nur auf die erste Eingabe, sondern auf alle Interaktionen eines Seitenbesuchs. Berichtet wird im Kern die langsamste Interaktion; bei sehr vielen Interaktionen wird je 50 Interaktionen der höchste Wert als Ausreißer ignoriert. INP ist seit dem 12. März 2024 offiziell Core Web Vital und hat FID abgelöst, wie die Ankündigung zum Wechsel von FID zu INP festhält.
| Bewertung | INP (75. Perzentil) |
|---|---|
| Gut | bis 200 ms |
| Verbesserungswürdig | über 200 bis 500 ms |
| Schlecht | über 500 ms |
Für die Google-Suche gilt: Google empfiehlt in der Search-Central-Dokumentation zu Core Web Vitals ausdrücklich gute Werte, weil sie zu dem passen, was die Ranking-Systeme belohnen wollen. INP ist dabei ein Signal unter vielen – ein schneller Klick ersetzt keinen hilfreichen Inhalt, eine träge Seite frustriert aber Besucher unabhängig von der Suche.
Aus welchen drei Phasen besteht eine Interaktion?
Jede Interaktion lässt sich in drei Abschnitte zerlegen. Wenn du weißt, welcher Abschnitt lang ist, weißt du auch, wo du ansetzen musst.
- Eingabeverzögerung (Input Delay): die Zeit, bis dein Event-Handler überhaupt starten kann. Sie wird lang, wenn der Hauptthread gerade mit anderer Arbeit beschäftigt ist, etwa mit dem Auswerten großer Skripte.
- Verarbeitungsdauer (Processing Duration): die Laufzeit aller Event-Handler, die auf die Eingabe reagieren.
- Darstellungsverzögerung (Presentation Delay): die Zeit, die der Browser anschließend für Stilberechnung, Layout und Zeichnen braucht, bis die Änderung sichtbar ist.
INP verbessern: Schritt für Schritt
1. Felddaten prüfen
Starte mit Daten echter Besucher, nicht mit einem einzelnen Labortest. INP entsteht erst durch Interaktionen – ein automatischer Seitentest ohne Klicks kann den Wert nicht abbilden. Die wichtigsten Quellen:
- Google Search Console: Der Bericht „Core Web Vitals“ gruppiert URLs mit ähnlichen Problemen, getrennt nach Mobilgeräten und Desktop.
- PageSpeed Insights: zeigt im oberen Bereich Felddaten aus dem Chrome UX Report (CrUX), sofern für die URL oder den Ursprung genug Daten vorliegen.
- Eigenes Real User Monitoring: Mit der JavaScript-Bibliothek
web-vitalsund der FunktiononINP()kannst du INP selbst erfassen – einschließlich der Information, welches Element die langsame Interaktion ausgelöst hat. Beachte dabei, dass eine eigene Messung datenschutzrechtlich sauber eingebunden sein muss.
Notiere dir die betroffenen Seitentypen, zum Beispiel Produktseiten, Filterseiten oder Beitragsseiten mit Kommentarformular. Mobile Werte sind oft schlechter, weil Smartphones weniger Rechenleistung haben.
2. Langsame Interaktionen im Labor nachstellen
Öffne die betroffene Seite in Chrome, starte die Entwicklertools und wechsle in den Bereich „Performance“. Dort zeigt Chrome laut Dokumentation des Chrome-Performance-Panels lokale Werte für LCP, CLS und INP live an, sobald du mit der Seite interagierst. Im Reiter für Interaktionen siehst du das auslösende Element, die Dauer und die Aufteilung auf die drei Phasen.
- Aktiviere eine CPU-Drosselung, um schwächere Smartphones nachzustellen. Auf einem schnellen Rechner wirken viele Probleme sonst harmlos.
- Klicke genau die Elemente an, die im Feld auffallen: Menü-Button, Filter, Akkordeon, „In den Warenkorb“, Cookie-Banner.
- Verbinde optional die CrUX-Felddaten im Panel, um lokale und echte Werte nebeneinander zu sehen.
- Zeichne für eine auffällige Interaktion eine Performance-Aufnahme auf und suche im Hauptthread nach langen Aufgaben.
3. Eingabeverzögerung senken
Eine lange Eingabeverzögerung bedeutet: Als der Nutzer geklickt hat, lief bereits eine andere Aufgabe. Nach der Anleitung zu langen Aufgaben auf web.dev gilt jede Aufgabe über 50 Millisekunden als lange Aufgabe. Solange sie läuft, bleibt die Eingabe in der Warteschlange.
- Lade nur Skripte, die auf der jeweiligen Seite wirklich gebraucht werden. Ein Slider-Skript auf Seiten ohne Slider kostet Rechenzeit ohne Nutzen.
- Prüfe Drittanbieter-Skripte wie Chat-Widgets, Tag-Manager-Container und eingebettete Inhalte. Sie laufen im selben Hauptthread wie dein eigener Code.
- Vermeide wiederkehrende Timer oder Animationen per JavaScript, die ständig im Hintergrund arbeiten.
4. Verarbeitungsdauer verkürzen
Der Event-Handler sollte nur das erledigen, was für die sichtbare Reaktion nötig ist. Alles andere – Tracking, Speichern, Nachladen weiterer Daten – kann später laufen. Die Anleitung zur INP-Optimierung auf web.dev empfiehlt dafür, die Arbeit aufzuteilen und dem Browser zwischendurch den Hauptthread zurückzugeben („Yielding“).
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
menu.classList.toggle('is-open'); // sichtbare Reaktion zuerst
await yieldToMain();
sendTrackingEvent(); // nicht kritische Arbeit danach
});scheduler.yield() ist speziell für diesen Zweck gedacht und setzt die unterbrochene Aufgabe bevorzugt fort. Die Methode ist laut MDN-Referenz zu scheduler.yield() jedoch noch nicht in allen verbreiteten Browsern verfügbar – Safari unterstützt sie derzeit nicht. Deshalb gehört eine Funktionsprüfung mit Rückfall auf setTimeout() dazu, wie im Beispiel oben.
Achte außerdem auf sogenanntes Layout Thrashing: Wenn dein Code abwechselnd Stile ändert und direkt danach Größen oder Positionen ausliest, muss der Browser das Layout mehrfach synchron berechnen. Lies Werte gesammelt aus und schreibe Änderungen danach gebündelt.
5. Darstellungsverzögerung reduzieren
Auch wenn dein Code schnell ist, muss der Browser die Änderung noch berechnen und zeichnen. Je größer das DOM, desto mehr Arbeit fällt dabei an. Der Beitrag zur DOM-Größe und Interaktivität auf web.dev nennt die Lighthouse-Grenzen: Ab 800 DOM-Knoten gibt es eine Warnung, ab 1.400 Knoten gilt das DOM als übermäßig groß.
- Entferne überflüssige Verschachtelungen. Page Builder erzeugen schnell mehrere Container-Ebenen, wo eine genügen würde.
- Rendere lange Listen, Mega-Menüs oder versteckte Inhalte erst bei Bedarf, statt sie vollständig ins HTML zu schreiben.
- Nutze die CSS-Eigenschaft
content-visibility: autofür große Bereiche außerhalb des sichtbaren Ausschnitts, damit der Browser deren Darstellung aufschiebt. - Halte CSS-Selektoren einfach. Komplexe Selektoren verteuern jede Stilberechnung nach einer Änderung.
Welche Maßnahme passt zu welcher Phase?
| Auffällige Phase | Typische Ursache | Passende Maßnahme |
|---|---|---|
| Eingabeverzögerung | Lange Aufgaben durch Skripte, Drittanbieter, Timer | Skripte seitengenau laden, Drittanbieter prüfen, lange Aufgaben aufteilen |
| Verarbeitungsdauer | Zu viel Arbeit im Event-Handler | Sichtbare Reaktion zuerst, Rest nach Yielding; Layout Thrashing vermeiden |
| Darstellungsverzögerung | Großes DOM, aufwendige Stilberechnung | DOM verkleinern, Inhalte bei Bedarf rendern, content-visibility nutzen |
Was bedeutet das für WordPress-Websites?
Bei WordPress stammen viele lange Aufgaben aus Plugins und Theme-Funktionen, die auf allen Seiten JavaScript laden. Prüfe in der Performance-Aufnahme, zu welcher Datei eine lange Aufgabe gehört – der Dateipfad verrät meist das Plugin. Frage dann: Wird diese Funktion auf dieser Seite gebraucht? Viele Plugins und Performance-Werkzeuge erlauben es, Skripte nur auf bestimmten Seiten zu laden.
Typische Kandidaten sind interaktive Elemente wie mobile Menüs, Filter in Onlineshops, Formulare mit Live-Validierung und Cookie-Banner. Wie du ein mobiles Menü in Bricks sauber aufbaust, zeigt der Beitrag zum mobilen Offcanvas-Menü in Bricks. Die Serverantwortzeit spielt für INP eine kleinere Rolle als für Ladezeitwerte wie LCP, denn die drei Phasen einer Interaktion laufen im Browser ab – es sei denn, eine Interaktion wartet auf eine Serverantwort, bevor sich sichtbar etwas ändert.
Checkliste: INP verbessern
- Search Console und PageSpeed Insights auf INP-Werte für Mobil und Desktop geprüft
- Betroffene Seitentypen und auslösende Elemente notiert
- Interaktion im Chrome-Performance-Panel mit CPU-Drosselung nachgestellt
- Längste Phase bestimmt: Eingabeverzögerung, Verarbeitung oder Darstellung
- Lange Aufgaben über 50 ms und ihre Skriptdateien identifiziert
- Sichtbare Reaktion im Handler vorgezogen, nicht kritische Arbeit nach Yielding verschoben
scheduler.yield()nur mit Funktionsprüfung und Rückfall eingesetzt- DOM-Größe geprüft und unnötige Verschachtelung entfernt
- Nach der Änderung erneut gemessen und die Entwicklung der Felddaten über mehrere Wochen beobachtet
Häufige Fragen zu INP
Warum zeigt Lighthouse keinen INP-Wert?
Ein normaler Lighthouse-Test lädt die Seite, klickt aber nichts an. Ohne Interaktion gibt es keinen INP-Wert. Als Laborhinweis dient die Total Blocking Time (TBT), die lange Aufgaben während des Ladens erfasst. Den eigentlichen INP-Wert liefern Felddaten oder deine eigenen Klicks im Performance-Panel.
Wie schnell sehe ich eine Verbesserung in der Search Console?
Die Felddaten beruhen auf einem gleitenden Zeitraum echter Besuche. Eine Verbesserung wird deshalb erst nach und nach sichtbar. Prüfe deine Änderung zuerst im Labor und beobachte die Felddaten danach über mehrere Wochen.
Ist ein guter INP-Wert ein Ranking-Garant?
Nein. Google empfiehlt gute Core Web Vitals, bewertet aber in erster Linie die Relevanz und Qualität der Inhalte. Ein guter INP-Wert ist vor allem ein Gewinn für deine Besucher, weil Menüs, Filter und Formulare ohne spürbare Verzögerung reagieren.
Was ist der Unterschied zwischen INP und FID?
FID hat nur die Verzögerung bis zum Start der ersten Interaktion gemessen. INP betrachtet alle Interaktionen eines Besuchs und die gesamte Zeit bis zur sichtbaren Reaktion – einschließlich Verarbeitung und Darstellung. Einen Überblick zum Wechsel bietet auch der Beitrag von Seokratie zu INP als Nachfolger von FID.
