INP verbessern: Wenn die Website träge auf Klicks reagiert
Kurz gesagt: INP (Interaction to Next Paint) misst, wie lange es dauert, bis eine Seite nach einem Klick, einem Tippen oder einem Tastendruck sichtbar reagiert. Laut web.dev gilt ein Wert bis 200 Millisekunden als gut, über 500 Millisekunden als schlecht. Bei kleinen Firmenwebsites liegt die Ursache fast immer bei zu viel JavaScript, das den Browser im falschen Moment beschäftigt, oft von eingebundenen Fremddiensten.
Ein schlechter INP fühlt sich für Besucher so an: Das Menü auf dem Handy klappt mit Verzögerung auf, ein Filter reagiert erst beim zweiten Tippen, das Formularfeld zeigt den Buchstaben nach einer kleinen Pause. Viele tippen dann noch einmal, und plötzlich passiert alles doppelt. Die gute Nachricht: INP lässt sich gezielt untersuchen, wenn man in der richtigen Reihenfolge vorgeht.
Messen: Wo ist die Seite wirklich langsam?
Was genau gezählt wird
Laut web.dev erfasst INP die Latenz aller Klicks, Berührungen und Tastaturinteraktionen während eines Seitenbesuchs. Gemeldet wird im Wesentlichen die langsamste Interaktion (bei sehr vielen Interaktionen wird je 50 Interaktionen der höchste Wert als Ausreißer ignoriert). Bewertet wird das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Scrollen und reines Darüberfahren mit der Maus zählen nicht.
Die Grenzwerte laut web.dev (abgerufen November 2026):
| INP-Wert | Bewertung |
|---|---|
| bis 200 ms | gut |
| über 200 bis 500 ms | verbesserungswürdig |
| über 500 ms | schlecht |
Felddaten zuerst
INP ist ein Wert aus echten Besuchen. Wenn Ihre Website genug Besucher hat, zeigt PageSpeed Insights oben die Felddaten aus dem Chrome User Experience Report (CrUX), oft nur für die gesamte Domain, manchmal für einzelne URLs. web.dev empfiehlt diesen Weg ausdrücklich, wenn Sie kein eigenes Messwerkzeug für echte Nutzer haben. Die Search Console fasst ähnliche Seiten im Bericht „Core Web Vitals“ zu Gruppen zusammen.
Kleine Websites haben oft zu wenig Besuche für Felddaten. Dann bleibt nur der Selbsttest.
Selbst nachstellen
Öffnen Sie die betroffene Seite auf einem eher günstigen Android-Handy, nicht auf dem neuesten iPhone, und probieren Sie die typischen Aktionen: Menü öffnen, Akkordeon aufklappen, Formular ausfüllen, Cookie-Banner wegklicken, Filter wählen. Wo es hakt, wissen Sie danach meist ohne Werkzeug. Entwickler können dieselben Klicks im Leistungsbereich der Chrome-Entwicklertools mit gedrosselter CPU aufzeichnen und sehen dort, welches Skript gerade läuft.
Ursachen: Warum der Browser nicht sofort antwortet
web.dev teilt jede Interaktion in drei Abschnitte. Daran lässt sich die Ursache gut zuordnen.
1. Eingabeverzögerung
Der Browser ist gerade mit etwas anderem beschäftigt, wenn jemand tippt. Er kann nur eine Aufgabe zur gleichen Zeit erledigen; web.dev nennt jede Aufgabe über 50 Millisekunden eine „Long Task“. Typische Auslöser auf Firmenwebsites:
- Chat-Widgets, Bewertungs-Widgets, Karten oder Social-Media-Einbettungen, die beim Laden viel Code ausführen.
- Tracking- und Marketing-Skripte, die sich an jeden Klick hängen.
- Der Cookie-Banner selbst, wenn er schwer gebaut ist.
2. Verarbeitungsdauer
Der Code, der auf den Klick reagieren soll, braucht zu lange. Beispiel: Ein Filter im Shop rechnet alle Produkte neu und baut die komplette Liste auf einmal neu auf. Oder ein Page-Builder-Menü löst eine Kette von Animationen und Berechnungen aus.
3. Präsentationsverzögerung
Die Antwort ist fertig, aber der Browser braucht lange, um sie zu zeichnen. Ein Grund dafür ist ein sehr großes DOM, also sehr viele HTML-Elemente auf der Seite. web.dev verweist auf Lighthouse: Ab 800 Knoten gibt es eine Warnung, ab 1.400 gilt die Größe als zu groß. Page-Builder mit vielen verschachtelten Containern, lange Seiten mit versteckten Inhalten für jede Bildschirmgröße und Mega-Menüs treiben die Zahl schnell nach oben.
Fixes: Was bei kleinen Websites am meisten bringt
Die Reihenfolge folgt dem Aufwand, nicht der Theorie.
1. Fremdskripte ausmisten. Prüfen Sie jedes eingebundene Tool: Wird es noch genutzt? Muss es auf jeder Seite laden? Kann es erst nach einer Nutzeraktion starten, etwa der Chat erst beim Klick auf die Sprechblase? Wie Sie dabei systematisch vorgehen, steht im Beitrag zum Aufräumen von Drittanbieter-Skripten.
2. Einbettungen erst bei Bedarf laden. Karten, Videos und Social-Feeds zuerst als statisches Vorschaubild zeigen und erst beim Klick das echte Element laden. Das entlastet den Browser genau in der Phase, in der Besucher zu tippen beginnen.
3. Schwere Plugins und Effekte ersetzen. Ein Slider mit vielen Optionen, Parallax-Effekte, Animationsbibliotheken für einen einzigen Effekt: Oft reicht schlichtes CSS. Bei WordPress lohnt der Blick, welche Plugins auf jeder Seite Skripte laden.
4. Lange Aufgaben aufteilen (Entwicklerarbeit). web.dev beschreibt, wie Code lange Arbeit in kleinere Häppchen zerlegt und dem Browser dazwischen Luft lässt, etwa mit setTimeout() oder neueren Planungsfunktionen. Wichtig ist, zuerst die sichtbare Reaktion zu zeigen (Menü öffnet sich) und Nebenarbeit (Tracking, Speichern) danach zu erledigen.
5. Das DOM verkleinern. Weniger verschachtelte Container, keine doppelten Inhalte für Handy und Desktop, lange Listen seitenweise statt alles auf einmal.
6. Erneut messen. Die Search Console wertet laut eigener Hilfe die Seitenaufrufe der letzten 28 Tage aus. Nach einer Änderung dauert es also Wochen, bis sich der Wert dort vollständig bewegt; der eigene Test am Handy zeigt die Verbesserung sofort.
Häufige Fragen
Ist INP für das Google-Ranking wichtig?
INP gehört laut web.dev zu den stabilen Core Web Vitals. Für Ihre Besucher ist eine träge Seite aber in jedem Fall ärgerlich, auch unabhängig von der Suche. Behandeln Sie INP deshalb in erster Linie als Nutzbarkeitsproblem.
Warum ist mein INP auf dem Handy viel schlechter als am Computer?
Handys, besonders günstige Modelle, haben deutlich weniger Rechenleistung. Dasselbe Skript, das am Laptop kaum auffällt, blockiert auf dem Handy spürbar. Deshalb wird INP getrennt nach Geräten bewertet.
PageSpeed Insights zeigt keinen INP-Wert. Was heißt das?
Dann fehlen für Ihre Seite genug Felddaten aus echten Chrome-Besuchen. Die Laborwerte darunter enthalten keinen INP, weil dafür echte Interaktionen nötig sind. Testen Sie dann selbst am Handy.
Hilft ein schnelleres Hosting gegen schlechten INP?
Kaum. INP entsteht im Browser des Besuchers, nicht auf dem Server. Ein schnellerer Server verbessert die Ladezeit, aber nicht die Reaktion auf Klicks.
Falls Sie den Verdacht haben, dass ein bestimmtes Plugin oder Widget Ihre Seite bremst, schicken Sie uns die Adresse, und ich sage Ihnen, wo ich zuerst nachsehen würde.