Löwen Sites / Magazin / Artikel
Conversion

INP: Warum sich schnelle Seiten trotzdem träge anfühlen

Eine Seite kann in einer Sekunde geladen sein und sich trotzdem hängen anfühlen. Der Grund liegt nicht im Laden, sondern in dem, was danach passiert: Der Nutzer klickt, und die Oberfläche antwortet erst eine gefühlte Ewigkeit später.

Autor Julien MarschallVeröffentlicht 21.08.2026Lesezeit 7 Min.

Ladezeit-Kennzahlen beschreiben den ersten Eindruck. Interaction to Next Paint beschreibt die gesamte Nutzung danach. Gemessen wird die Zeit zwischen einer Eingabe — Klick, Tipp, Tastendruck — und dem Moment, in dem der Browser als Reaktion tatsächlich etwas Sichtbares zeichnet. Als Wert wird die schlechteste beziehungsweise nahezu schlechteste Interaktion eines Besuchs herangezogen, nicht der Durchschnitt. Ein einziger träger Klick prägt also die Bewertung einer gesamten Sitzung.

Die drei Anteile einer Interaktion

  • Eingabeverzögerung: Der Hauptprozess ist noch mit etwas anderem beschäftigt, wenn der Klick eintrifft. Die Reaktion wartet in der Schlange.
  • Verarbeitungsdauer: Der eigentliche Ereignisbehandler läuft — Zustand ändern, Daten holen, Komponenten neu berechnen.
  • Darstellungsverzögerung: Nach der Verarbeitung braucht der Browser Zeit, das Ergebnis tatsächlich zu zeichnen: Layout, Stil, Bildaufbau.

Für die Behebung ist die Aufteilung entscheidend. Wer den Ereignisbehandler optimiert, obwohl die Verzögerung vor dem Klick entsteht, verbessert nichts Messbares.

Die häufigste Ursache für schlechte Werte ist nicht der eigene Code, sondern Fremdskript: Tracking, Chat-Widgets, Consent-Werkzeuge, Testsysteme. Sie blockieren den Hauptprozess in genau dem Moment, in dem Besucher zum ersten Mal etwas anklicken.

Lange Aufgaben zerlegen

Der Hauptprozess kann immer nur eine Sache gleichzeitig tun. Läuft dort eine Aufgabe über mehrere hundert Millisekunden, sind alle Eingaben in dieser Zeit blockiert. Die Lösung besteht selten darin, Arbeit zu streichen — sie besteht darin, sie zu unterteilen und dem Browser zwischendurch die Gelegenheit zu geben, auf Eingaben zu reagieren.

Praktisch heißt das: Nach der sichtbaren Reaktion abgeben und den Rest verzögert erledigen. Ein Klick auf einen Filter sollte zuerst den Zustand des Knopfes ändern, den Nutzer also unmittelbar bestätigen, und erst danach die aufwendige Neuberechnung der Ergebnisliste anstoßen. Der wahrgenommene Unterschied ist erheblich, obwohl die Gesamtarbeit gleich bleibt.

Weniger Code zum Startzeitpunkt

Ein großer Teil schlechter Werte entsteht direkt nach dem Laden, wenn Skripte ausgewertet und Komponenten initialisiert werden. Genau in diese Phase fallen die ersten Klicks. Wirksam sind hier:

  • Skripte nur laden, wo sie gebraucht werden, statt global auf jeder Seite.
  • Nicht sofort benötigte Funktionalität nachladen, etwa erst bei Sichtbarkeit oder erster Nutzung.
  • Fremdskripte verzögert einbinden und regelmäßig prüfen, ob sie noch benötigt werden.
  • Schwere Berechnungen in einen Hintergrundprozess auslagern, sofern sie nicht auf die Oberfläche zugreifen müssen.

Die Darstellung nicht unterschätzen

Auch nach der Verarbeitung kann Zeit vergehen. Ursachen sind meist große, teure Neuberechnungen des Layouts: sehr viele Elemente gleichzeitig im Dokument, aufwendige Schatten und Filter, oder Änderungen, die eine Neuberechnung der gesamten Seite auslösen statt nur eines Bereichs. Wer beim Klick zwei Klassen tauscht statt eine komplette Liste neu aufzubauen, gewinnt hier ohne Änderung an der Logik.

Ein verwandter Fall sind Bilder, die erst beim Klick geladen werden und dabei das Layout verschieben. Feste Größenangaben und vorbereitete Formate lösen das mit — die Grundlagen dazu stehen im Beitrag zur Bildoptimierung.

Richtig messen

Werkzeuge, die eine Seite im Labor laden, sehen INP nicht — es gibt dort keine Nutzerinteraktion. Belastbar sind nur Felddaten aus echten Besuchen. Sinnvoll ist eine eigene Erhebung, die neben dem Wert auch festhält, welches Element angeklickt wurde und wie sich die Zeit auf die drei Anteile verteilt. Ohne diese Zuordnung bleibt jede Optimierung Raten.

Wichtig ist außerdem, nach Gerät zu unterscheiden. Auf leistungsfähigen Rechnern fällt kaum etwas auf. Die Probleme entstehen auf älteren Mobilgeräten — und dort findet ein erheblicher Teil des Umsatzes statt.

Warum das Conversion kostet

Eine träge Reaktion erzeugt Unsicherheit. Der Nutzer weiß nicht, ob sein Klick angekommen ist, und klickt erneut. Bei Filtern führt das zu doppelten Anfragen, bei Formularen zu doppelten Absendungen, bei Kaufknöpfen zu Abbrüchen. Der Effekt ist besonders unangenehm, weil er genau an den Stellen auftritt, an denen der Besucher bereits Kaufabsicht gezeigt hat.

Der wirksamste Sofortschritt kostet keine Entwicklung: eine sichtbare Rückmeldung innerhalb weniger Millisekunden nach jedem Klick — gedrückter Zustand, Ladeanzeige, deaktivierter Knopf. Das verbessert den gemessenen Wert und beseitigt gleichzeitig die Doppelklicks.

Websites, die gefunden werden

Wir bauen Seiten, bei denen Struktur, Technik und Conversion zusammenpassen — nicht drei Disziplinen, die sich gegenseitig behindern.

Projekt anfragen →

Häufige Fragen

Was ist ein guter INP-Wert?
Als gut gelten Werte bis etwa 200 Millisekunden, als verbesserungsbedürftig bis rund 500 Millisekunden, darüber als schlecht. Maßgeblich sind Felddaten echter Besuche, nicht Labormessungen, da INP eine tatsächliche Interaktion voraussetzt.
Warum zeigt mein Testwerkzeug keinen INP-Wert an?
Weil im Labortest niemand klickt. INP entsteht erst durch echte Nutzerinteraktionen und wird deshalb ausschließlich aus Felddaten oder einer eigenen Messung im Browser der Besucher ermittelt.