Interaction to Next Paint (INP): Reaktionszeit verbessern

Warum das wichtig ist

Du tippst auf "In den Warenkorb", und nichts passiert. Also tippst du nochmal. Dann liegt das Produkt zweimal im Korb, oder du gehst. Genau dieses Gefühl misst INP: die Zeit von der Eingabe bis zum nächsten Bild, das der Browser zeichnet.

Der Vorgänger FID (First Input Delay) hat nur die Wartezeit bei der allerersten Eingabe gemessen und war fast immer grün. INP schaut auf alle Interaktionen während des Besuchs und meldet ungefähr die langsamste. Viele Seiten, die bei FID gut dastanden, sehen bei INP schlechter aus.

Die Ursache ist fast immer JavaScript. Solange der Browser mit einer langen Aufgabe beschäftigt ist, etwa einem Tracking-Skript, das gerade startet, kann er auf deinen Klick nicht reagieren. Auf schwachen Handys merkt man das besonders.

So prüfst du es selbst

INP ist ein Feldwert. Er stammt aus dem Chrome UX Report, also von echten Chrome-Besuchern der letzten 28 Tage. In PageSpeed Insights steht er oben im Block mit den Daten echter Nutzer, in der Google Search Console im Bericht zu den Core Web Vitals.

Das hat eine ehrliche Grenze: Hat deine Seite zu wenig Besucher, gibt es keine Felddaten und damit keinen INP-Wert. Die Labormessung von Lighthouse kann INP nicht erfassen, weil dort niemand klickt. Als Ersatz dient die Total Blocking Time, die zeigt, wie lange JavaScript den Browser beim Laden blockiert. Eine hohe Total Blocking Time ist ein gutes Warnzeichen für schlechten INP.

Nachstellen kannst du es in den Chrome-Entwicklertools. Schalte im Bereich Performance die CPU-Drosselung ein, damit dein Rechner ungefähr so langsam rechnet wie ein Handy, und klick dich dann durch die Seite. Chrome zeigt den INP deiner Interaktionen live an, langsame Klicks fallen sofort auf.

Im kostenlosen Check von checkfrei lesen wir INP aus den Felddaten des Chrome-Nutzerberichts. Bis 200 Millisekunden ist gut, bis 500 gibt es eine Warnung, darüber einen Fehler. Fehlen die Daten, zeigen wir nur einen Hinweis.

So behebst du es

Zuerst die fremden Skripte. Chat-Widgets, Tag Manager mit vielen Tags, Werbung und Heatmap-Tools laufen auf demselben Hauptthread wie deine Seite. Was nicht gebraucht wird, fliegt raus (externe Skripte), der Rest lädt später.

Dann der eigene Code. Die Regel: Nach einer Eingabe sofort etwas Sichtbares tun, etwa den Knopf ändern oder eine Ladeanzeige zeigen, und die teure Arbeit danach erledigen. Lange Aufgaben teilst du auf und gibst dem Browser zwischendurch Gelegenheit zu zeichnen.

Auch die Größe der Seite spielt mit. Viele tausend HTML-Elemente, wie sie manche Page-Builder erzeugen, machen jedes Neuzeichnen langsamer.

// Gibt dem Browser Gelegenheit zu zeichnen, bevor es weitergeht
function kurzePause() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

knopf.addEventListener("click", async () => {
  knopf.textContent = "Wird geladen ...";  // sofort sichtbare Reaktion
  await kurzePause();
  filterProdukte();                         // teure Arbeit danach
});