INP optimieren: Interaktivität und Reaktionszeit verbessern

Der Interaction to Next Paint (INP) ist seit März 2024 eine offizielle Core Web Vitals Metrik von Google. Er bewertet die allgemeine Reaktionsfähigkeit einer Webseite. INP misst die Zeitspanne, die zwischen einer Benutzerinteraktion (z. B. dem Klicken auf einen Button, dem Tippen auf dem Smartphone oder einer Tastatureingabe) und der nächsten sichtbaren Aktualisierung der Benutzeroberfläche (Next Paint) vergeht. Ein INP-Wert von unter 200 Millisekunden gilt als optimal.

Während der LCP misst, wie schnell eine Seite lädt, bewertet der INP, wie schnell sie auf Eingaben reagiert. Der wichtigste Hebel dabei ist fast immer das Reduzieren von JavaScript, da blockierende Skripte den Haupt-Thread belegen und so jede Interaktion verzögern.

Die drei Phasen der Interaktionsverzögerung

Die gemessene Gesamtzeit einer Interaktion setzt sich aus drei Phasen zusammen, die alle optimiert werden können:

  [Benutzer klickt] ────► [1. Input Delay] ────► [2. Processing Time] ────► [3. Presentation Delay] ────► [Bild aktualisiert]

1. Input Delay (Eingabeverzögerung): Die Zeit zwischen dem Klick des Nutzers und dem Moment, in dem der Event-Handler gestartet wird. Diese Verzögerung entsteht meist, weil der Haupt-Thread (Main Thread) des Browsers mit dem Laden und Ausführen anderer JavaScript-Dateien blockiert ist.
2. Processing Time (Verarbeitungszeit): Die Zeit, die das JavaScript benötigt, um die Event-Handler-Funktionen auszuführen.
3. Presentation Delay (Präsentationsverzögerung): Die Zeit, die der Browser benötigt, um nach der Code-Ausführung das Layout neu zu berechnen, die Styles anzuwenden und das geänderte Bild auf den Bildschirm zu zeichnen.

---

Strategien zur INP-Optimierung

Der Schlüssel zu einem guten INP-Wert liegt in der Entlastung des Haupt-Threads des Browsers.

1. Long Tasks aufteilen (Yielding to the Main Thread)

Blockiert ein Skript den Thread für mehr als 50 ms, fühlt sich die Seite zäh an. Entwickler sollten komplexe JavaScript-Berechnungen in kleinere Einzelschritte zerlegen.

• Nutzen Sie APIs wie scheduler.yield() (sofern vom Browser unterstützt) oder klassische Fallbacks wie setTimeout(..., 0) zur Unterbrechung langer Schleifen. Dies gibt dem Browser die Möglichkeit, zwischen den Rechenschritten auf Klicks des Nutzers zu reagieren.

2. Layout Thrashing vermeiden

Ändern Sie im JavaScript nicht abwechselnd CSS-Eigenschaften und lesen Sie diese direkt danach wieder aus. Dies zwingt den Browser zu wiederholten, langsamen Layout-Neuberechnungen innerhalb desselben Frames (Layout Thrashing).

• Best Practice: Erst alle Werte auslesen (Read), danach alle Änderungen ins DOM schreiben (Write).

3. DOM-Grösse reduzieren

Ein riesiges HTML-Dokument mit Zehntausenden Elementen (DOM-Knoten) verlangsamt jede Bildaktualisierung, da der Browser bei jeder Änderung das gesamte Layout neu berechnen muss.

• Halten Sie das DOM kompakt (Ziel: unter 1000 Elemente pro Seite).

4. Non-Blocking Frameworks nutzen

Moderne Frameworks (wie das von uns genutzte Svelte 5 für interaktive Inseln) nutzen hocheffiziente Reaktivitätssysteme und minimalen JS-Overhead, wodurch die Verarbeitungszeit im Vergleich zu schweren Legacy-Systemen auf ein Minimum schrumpft.

---

INP-Schwellenwerte im Überblick

Google teilt die gemessenen Werte in drei Bereiche ein. Entscheidend ist immer das 75. Perzentil der realen Nutzerinteraktionen:

Bewertung	INP-Wert	Bedeutung
Gut	≤ 200 ms	Seite fühlt sich unmittelbar reaktiv an
Verbesserung nötig	200–500 ms	Spürbare, aber tolerierbare Verzögerung
Schlecht	> 500 ms	Seite wirkt träge und hakelig

---

Die drei Phasen als Optimierungs-Landkarte

Jede der drei Verzögerungsphasen wird durch andere Ursachen ausgelöst und braucht andere Gegenmittel:

Phase	Typische Ursache	Wirksamstes Gegenmittel
Input Delay	Haupt-Thread durch Skript-Laden blockiert	JavaScript aufteilen, defer nutzen
Processing Time	Schwere Event-Handler-Logik	Long Tasks zerlegen, debouncen
Presentation Delay	Grosses DOM, teure Layout-Neuberechnung	DOM verkleinern, Layout Thrashing vermeiden

Die Diagnose beginnt also stets mit der Frage: In welcher Phase entsteht die Verzögerung? Erst danach wählt man die passende Massnahme.

---

Vorher/Nachher: ein hakeliger Filter-Button

Ein Online-Shop hatte auf der Kategorieseite einen INP von 480 ms – jeder Klick auf einen Filter fühlte sich träge an. Ursache war ein Event-Handler, der synchron alle Produkte neu sortierte und das DOM mehrfach las und schrieb.

Vorher (blockierend):

button.addEventListener('click', () => {
  const items = teureSortierung(alleProdukte); // Long Task > 200 ms
  render(items);
});

Nachher (entlastet den Haupt-Thread):

button.addEventListener('click', async () => {
  await scheduler.yield();          // dem Browser Luft geben
  const items = teureSortierung(alleProdukte);
  requestAnimationFrame(() => render(items)); // Schreiben gebündelt
});

Nach dem Aufteilen der Long Task und dem Bündeln der DOM-Schreibzugriffe sank der INP auf 140 ms – der Filter reagierte wieder unmittelbar. Solche Optimierungen wirken sich direkt auf die Core Web Vitals und damit auf das Ranking aus.

[!TIP] Ein schlechter INP-Wert frustriert mobile Nutzer besonders, da die Seite träge auf Berührungen reagiert. Diagnostizieren Sie Ihre Interaktionszeiten und finden Sie blockierende Skripte mit dem PageSpeed Check auf balou.tools.