INP — du klickst, und nichts passiert.

Was INP misst.

Die Zeit von einer Eingabe — Klick, Tippen, Tastendruck — bis zu dem Moment, in dem der Browser die nächste Bildaktualisierung zeichnet. Also: Wann sieht der Nutzer, dass etwas passiert ist?

Gemessen werden alle Interaktionen eines Besuchs, und bewertet wird im Wesentlichen die schlechteste. Das ist streng und richtig: Ein einziger Klick, nach dem die Seite eine Sekunde einfriert, ist genau das, was in Erinnerung bleibt.

Wichtig: Scrollen zählt nicht als Interaktion in diesem Sinn, Zoomen auch nicht. Es geht um Klicks, Tippen auf dem Touchscreen und Tastatureingaben.

Warum der alte Wert nicht reichte.

Früher wurde nur die erste Eingabe betrachtet, und auch nur deren Verzögerung bis zum Beginn der Verarbeitung. Das war großzügig: Eine Seite konnte beim ersten Klick schnell reagieren und danach bei jeder Filterauswahl eine halbe Sekunde stehen.

INP betrachtet die ganze Sitzung und die ganze Dauer bis zur sichtbaren Reaktion. Deshalb fallen seit der Umstellung Seiten durch, die vorher grün waren — besonders Shops und alles mit vielen interaktiven Elementen (Core Web Vitals).

Die drei Phasen.

Diese Aufteilung ist beim INP genauso wichtig wie beim LCP: Sie sagt, ob man das eigene Skript beschleunigen muss oder dafür sorgen, dass gar nicht erst etwas anderes im Weg ist.

Phase 1: Eingabeverzögerung.

Der Browser kann nur eines gleichzeitig: Entweder Code ausführen oder auf Eingaben reagieren. Läuft gerade eine lange Aufgabe, wartet der Klick, bis sie fertig ist.

Besonders schlimm ist das kurz nach dem Laden, wenn alle Skripte gleichzeitig anlaufen. Eine Seite, die optisch fertig aussieht, aber noch zehn Skripte abarbeitet, reagiert in dieser Zeit nicht — und genau dann klicken Besucher.

Gegenmittel: weniger Skripte, später laden, Arbeit aufteilen. Alles, was nicht sofort gebraucht wird, gehört nachrangig geladen (Blockierende Ressourcen).

Phase 2: Verarbeitung.

Hier läuft der Code, der auf den Klick reagiert. Typische Zeitfresser: eine große Liste neu aufbauen, viele Elemente gleichzeitig verändern, aufwendige Berechnungen, Daten nachladen und darauf warten.

Der wichtigste Grundsatz: Zeig sofort eine Reaktion, auch wenn die eigentliche Arbeit länger dauert. Ein Knopf, der nach dem Klick sofort den Zustand wechselt und dann im Hintergrund arbeitet, hat ein gutes INP. Einer, der erst nach Abschluss aller Arbeit reagiert, nicht.

Phase 3: Darstellung.

Der Browser muss das neue Bild berechnen. Teuer wird das, wenn sich durch die Änderung das Layout der ganzen Seite neu berechnen muss — etwa weil ein Element oben seine Höhe ändert.

Hilfreich ist, Änderungen lokal zu halten und für Animationen die Eigenschaften zu nutzen, die nur die Darstellung verändern und nicht das Layout. Das ist derselbe Rat wie beim CLS, und er zahlt hier doppelt ein (CLS).

Lange Aufgaben aufbrechen.

Das zentrale Werkzeug. Statt fünfhundert Elemente in einem Rutsch zu verarbeiten, verarbeitet man sie in Häppchen und gibt dem Browser dazwischen Gelegenheit, auf Eingaben zu reagieren.

Praktisch bedeutet das drei Dinge: Arbeit in Teile zerlegen, zwischen den Teilen die Kontrolle abgeben, und alles, was nicht sofort sichtbar sein muss, auf später verschieben. Moderne Browser bieten dafür eigene Mechanismen, mit denen sich Aufgaben nach Dringlichkeit einplanen lassen.

Als Faustregel gilt: Keine einzelne Aufgabe sollte länger als etwa fünfzig Millisekunden laufen. Alles darüber blockiert spürbar.

Skripte von Dritten.

Der unangenehmste Teil, weil du den Code nicht änderst. Übliche Verdächtige: Chat-Widgets, Bewertungseinbindungen, Werbung, Analyse- und Marketingwerkzeuge, Einwilligungsverwaltung, A/B-Test-Werkzeuge.

Was du tun kannst:

• Ehrlich aufräumen. Auf fast jeder Website laufen Skripte, die niemand mehr nutzt oder je ausgewertet hat.
• Später laden, alles, was nicht sofort gebraucht wird — ein Chat-Widget darf erscheinen, wenn die Seite steht.
• Auf Interaktion laden: Das Widget wird erst geladen, wenn jemand darauf klickt; davor steht nur ein Platzhalter.
• Serverseitig erfassen, wo das möglich ist, statt im Browser.
• Beim Anbieter nachfragen — manche bieten eine schlankere Einbindung an.

Der dritte Punkt ist bei Chat- und Videoeinbindungen oft die größte Einzelverbesserung überhaupt und kostet nichts an Funktion (Einbettungen).

Typische Fälle im Shop.

Die letzte Zeile ist ein Klassiker: Eine Suche, die bei jedem Buchstaben eine Anfrage stellt, blockiert das Tippen. Richtig ist, kurz abzuwarten und erst dann zu fragen — das reduziert die Last um ein Vielfaches und fühlt sich besser an (Shop-Suche, Filter).

Die Übeltäter finden.

INP entsteht im Feld, nicht im Labor — ein Testlauf klickt nirgends hin und misst deshalb gar nichts. Das macht die Suche schwieriger als bei den anderen Werten.

1. Felddaten ansehen: Welche Seitengruppen sind betroffen?
2. Die Seite selbst bedienen mit geöffneten Entwicklerwerkzeugen und Leistungsaufzeichnung.
3. Prozessorleistung drosseln, damit das Problem sichtbar wird — ein schneller Rechner verdeckt alles.
4. Lange Aufgaben suchen in der Aufzeichnung und zuordnen, zu welchem Skript sie gehören.
5. Testweise Skripte abschalten und erneut messen.
6. Im Feld messen, wenn möglich mit einer eigenen Erfassung, die das betroffene Element mitprotokolliert.

Punkt drei ist der wichtigste Kniff. Auf einem aktuellen Rechner liegt INP fast immer im grünen Bereich — die schlechten Werte entstehen auf drei Jahre alten Mittelklasse-Handys (Mobil).

Was hilft.

1. Skripte reduzieren. Jedes entfernte Skript hilft sofort.
2. Auf Interaktion laden, was nicht sofort gebraucht wird.
3. Lange Aufgaben aufbrechen.
4. Sofort sichtbar reagieren, Rest im Hintergrund.
5. Eingaben entprellen, statt bei jedem Tastendruck zu arbeiten.
6. Layoutberechnungen begrenzen.
7. Page Builder prüfen — viele bringen erhebliche Skriptmengen mit (Builder).

Punkt eins und sieben hängen zusammen und sind bei WordPress oft der Kern: Eine Seite, die aus zwanzig Builder-Bausteinen besteht, lädt die Skripte von zwanzig Bausteinen — auch die der Bausteine, die auf dieser Seite gar nichts tun.

Wenn du nicht weiterkommst.

Wenn deine Seite auf Klicks träge reagiert und du nicht weißt, welches Skript schuld ist. Ich messe deine Seite mit echten Nutzerdaten statt mit einem einzelnen Test, sortiere die Befunde nach Wirkung und behebe die, die zählen: Ladezeit optimieren. Dauerhaft begleitet die WordPress-Wartung — damit neue Inhalte die Werte nicht wieder kaputt machen.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich mache Websites schneller — und zwar messbar, nicht gefühlt. Das heißt: erst messen, dann die zwei oder drei Stellen beheben, die tatsächlich den Unterschied machen, dann noch einmal messen.

Was ich nicht mache: eine Punktzahl schönrechnen. Es gibt Tricks, mit denen ein Testwerkzeug hundert Punkte zeigt, während die Seite für echte Besucher gleich langsam bleibt. Das ist Selbstbetrug, und ich sage dir, wenn jemand dir so etwas verkauft hat.

Ich arbeite mit dem, was du hast — Theme, Plugins, Hoster. Ein Neubau ist manchmal die ehrlichere Antwort, und dann sage ich das auch, statt monatelang an einer Seite zu optimieren, die grundsätzlich falsch gebaut ist.