INP optimieren: Interaktivität messen und verbessern

Warum INP für technisches SEO im DACH-Raum zählt

Interaction to Next Paint (INP) misst, wie schnell eine Website auf Nutzerinteraktionen reagiert. Klicks, Taps und Tastatureingaben lösen einen Verarbeitungsprozess aus, an dessen Ende das nächste sichtbare Bild (Paint) steht. INP erfasst die Verzögerung über den gesamten Seitenbesuch hinweg und nicht nur bei der ersten Eingabe. Seit dem 12. März 2024 ist INP ein stabiles Core Web Vital und ersetzt First Input Delay. Damit ist die Metrik Teil der Page-Experience-Signale, die laut Google-Dokumentation mit den Core-Ranking-Systemen abgestimmt sind.

Für B2B-Anbieter in Österreich ist das doppelt relevant. Erstens ist Reaktivität ein Geschäftsfaktor: Eine Analyse von vier E-Commerce-Sites zeigte eine durchgängig negative Korrelation zwischen INP und Conversion-Rate, wobei Conversions teils schon bei 100 ms litten, also innerhalb des "guten" Bereichs. Zweitens ist der österreichische Markt mobil geprägt: Laut StatCounter teilen sich 57,6 Prozent Desktop und 42,4 Prozent Mobil den Zugriff (Mai 2026). Bei 8,69 Millionen Internetnutzern und 95,3 Prozent Penetration (Oktober 2025) entscheidet die mobile Performance über einen erheblichen Teil der Sichtbarkeit.

Die Hürde ist real. International halten mobil nur 64,9 Prozent der Websites einen guten INP, während CLS mit 76,9 Prozent deutlich leichter zu bestehen ist. Der Geräte-Gap ist gross: 2024 hatten 74 Prozent der mobilen, aber 97 Prozent der Desktop-Sites guten INP.

Wie INP funktioniert: drei Phasen und der entscheidende Unterschied zu FID

INP zerlegt jede Interaktion in drei Phasen. Input Delay: die Zeit, bis der Hauptthread frei wird und den Event-Handler ausführen kann. Ein durch JavaScript blockierter Thread verlängert diese Phase. Processing Time: die Ausführung der Event-Handler selbst, also deine Geschäftslogik, Framework-Updates und Berechnungen. Presentation Delay: die Zeit, bis der Browser das Ergebnis rendert und den nächsten Frame zeichnet.

Der zentrale Unterschied zu First Input Delay liegt im Messumfang. FID erfasste nur die Verzögerung der ersten Eingabe und ignorierte die Verarbeitungs- sowie Darstellungszeit. INP betrachtet alle Interaktionen einer Sitzung und meldet (vereinfacht) den höchsten relevanten Wert. Eine Website kann also einen perfekten FID gehabt haben und trotzdem einen schlechten INP aufweisen, weil spätere Interaktionen wie das Öffnen eines Menüs, das Filtern einer Liste oder das Absenden eines Formulars langsam sind. Der Schwellenwert: Mindestens 75 Prozent der Interaktionen sollten unter 200 Millisekunden reagieren.

Die Hauptursache schlechter Werte ist ein überlasteter Hauptthread. Lange Tasks blockieren ihn und verzögern jede neue Eingabe. Aufgaben über 50 ms gelten als Long Tasks. Die Datenlage ist eindeutig: Die mediane mobile Seite verbringt 2.366 ms in Long Tasks gegenüber nur 329 ms auf dem Desktop, bei 14 statt 3 langen Tasks im Median. Total Blocking Time, der gängige Labor-Proxy für INP, liegt mobil im Median bei 1.208 ms gegenüber 67 ms auf dem Desktop, also rund 18-mal höher.

INP messen: Felddaten schlagen Labordaten

Für eine belastbare Diagnose musst du Feld- und Labordaten trennen.

Felddaten (massgeblich): Sie stammen von echten Nutzern. Der Chrome User Experience Report (CrUX) speist PageSpeed Insights und die Search Console. Für kontinuierliche Überwachung integrierst du die web-vitals-JavaScript-Bibliothek oder eine Real-User-Monitoring-Lösung (RUM). Nur Felddaten spiegeln reale Geräte, Netzqualität und Interaktionsmuster wider. Genau hier zeigt sich der mobile Nachteil aus echter Rechenleistung und Netzqualität.

Labordaten (diagnostisch): Lighthouse und die Chrome DevTools liefern reproduzierbare Werte in einer kontrollierten Umgebung. INP selbst lässt sich im Labor nicht direkt messen, da es Interaktionen über die Zeit braucht. Stattdessen dient Total Blocking Time als Proxy: Sie zeigt, wie stark der Hauptthread während des Ladens blockiert ist. Labordaten eignen sich zum Debuggen und für Regressionstests in der CI-Pipeline, ersetzen aber niemals die Bewertung im Feld.

Die Konsequenz: Optimiere nicht blind gegen einen Lighthouse-Score. Priorisiere nach Perzentil. Der INP-Wert wird vom langsamen Ende der Verteilung bestimmt, also vom 75. Perzentil aufwärts. Eine Interaktion, die im Schnitt schnell ist, aber bei zehn Prozent der Nutzer 600 ms braucht, ist dein eigentliches Problem.

Best Practices: Hauptthread entlasten und Interaktionen beschleunigen

Die wirksamsten Hebel reduzieren JavaScript-Arbeit oder verteilen sie zeitlich.

Lange Tasks aufbrechen: Zerlege Arbeit in kleinere Einheiten und gib die Kontrolle an den Hauptthread zurück, bevor 50 ms überschritten werden. scheduler.yield() gibt nach laufender Arbeit ab und setzt sie priorisiert fort. scheduler.postTask() erlaubt explizite Prioritäten. setTimeout dient als breiter unterstützter Fallback. isInputPending() prüft, ob eine Eingabe wartet, sodass du zugunsten der Reaktivität unterbrechen kannst.

JavaScript-Last senken: Im Median werden mobil 558 KB JavaScript ausgeliefert, davon rund 206 KB ungenutzt also 44 Prozent. Code-Splitting, Tree-Shaking und das Entfernen toten Codes wirken direkt auf Input Delay und Processing Time. Lade nur, was die jeweilige Seite braucht, und verschiebe nicht-kritische Logik.

Event-Handler optimieren: Drossle häufige Events. Debouncing für Eingaben und Throttling für Scroll- oder Resize-Handler verhindern unnötige Arbeit. Die redBus-Fallstudie belegt das präzise: Durch Debouncing des Scroll-Handlers und lokales State-Management mit verzögerter Redux-Synchronisierung sank der INP der Suchseite um 72 Prozent bei einem Umsatzplus von 7 Prozent. Vermeide teure Re-Renders, nutze requestAnimationFrame für visuelle Updates, setze CSS statt JavaScript für Animationen ein und entlaste das Rendering mit content-visibility.

Third-Party- und Consent-Skripte zähmen: Tracking-, Tag-Manager- und Consent-Skripte laufen oft auf dem Hauptthread und blockieren ihn genau dann, wenn der Nutzer interagieren will. Lade sie verzögert, nach der ersten Interaktion oder in einem Web Worker. Prüfe, welche Skripte wirklich kritisch sind.

Next.js-Architektur für niedrige INP-Werte

Bei Next.js entsteht ein grosser Teil der INP-Last aus der Hydration: Der Browser muss serverseitig gerenderten HTML mit Client-JavaScript "wiederbeleben", was den Hauptthread belastet.

React Server Components: Komponenten ohne Interaktivität rendern serverseitig und senden kein Client-JavaScript. Das reduziert das Bundle und damit Hydration-Kosten an der Wurzel. Die Wirkung ist in der Praxis dokumentiert: Economic Times senkte die Total Blocking Time von 3.260 ms auf 120 ms und den INP von rund 1.000 ms auf 257 ms, unter anderem durch die Migration auf Next.js. Das Ergebnis: 50 Prozent weniger Absprünge und 43 Prozent mehr Seitenaufrufe.

Streaming und Suspense: Mit <Suspense> streamst du Teile der Seite, sobald sie bereit sind, statt auf alles zu warten. Das verkürzt die Zeit bis zur Interaktivität sichtbarer Bereiche.

Selektive Hydration und dynamische Importe: Markiere nur interaktive Inseln als Client-Komponenten ("use client"). Schwere Client-Komponenten lädst du über next/dynamic, idealerweise erst bei Bedarf. So vermeidest du grosse Client-Bundles, die den Hauptthread früh blockieren.

Häufige Fehler bei der INP-Optimierung

Nur auf den Lighthouse-Score schauen: Ein grüner Laborwert garantiert keinen guten INP im Feld. Labordaten kennen keine echten Interaktionen über die Zeit. Ohne Felddaten und Perzentil-Betrachtung optimierst du am Problem vorbei.

Den langsamsten Fall ignorieren: Wer Durchschnitte betrachtet, übersieht das 75. Perzentil. Genau dort wird INP gemessen. Identifiziere die langsamste Interaktion gezielt.

Consent- und Tracking-Skripte unangetastet lassen: Banner-Skripte erscheinen früh und blockieren oft genau die erste Interaktion. Ohne verzögertes oder ausgelagertes Laden bleibt der Effekt sichtbar, gerade unter den realen Bedingungen mobiler Geräte.

Mobile- und Desktop-Budget gleichsetzen: Mobile Geräte haben weniger Rechenleistung. Mit 1.208 ms mediane TBT mobil gegenüber 67 ms Desktop braucht Mobil ein strengeres JavaScript-Budget. Ein auf dem Desktop akzeptables Bundle kann mobil den Schwellenwert sprengen.

JavaScript ungeprüft akkumulieren: Wenn 44 Prozent des ausgelieferten JavaScripts ungenutzt sind, ist das toter Ballast. Prüfe regelmäßig die Coverage und entferne ungenutzten Code.

Metriken, Debugging und Priorisierung in der Praxis

Für das gezielte Debuggen stehen heute präzise Werkzeuge bereit.

Long Animation Frames (LoAF) API: Sie liefert detaillierte Daten zu langen Frames inklusive verursachender Skripte und blockierender Quelle. Damit identifizierst du nicht nur, dass ein Frame lang war, sondern welcher Code ihn verursacht hat.

Performance-Panel in Chrome DevTools: Es zeigt die Interaktions-Spur mit Input Delay, Processing Time und Presentation Delay. So siehst du, welche der drei Phasen dominiert, und richtest die Massnahme entsprechend aus: Input Delay deutet auf Hauptthread-Blockaden, lange Processing Time auf teure Handler, hoher Presentation Delay auf Rendering- oder Layout-Kosten.

Attribution der langsamsten Interaktion: Mit der web-vitals-Bibliothek im Attribution-Modus oder einer RUM-Lösung erfasst du pro Nutzer die schlimmste Interaktion samt Kontext. Priorisiere nach Häufigkeit und Schwere am 75. Perzentil.

Zielwerte für DACH ableiten: Setze 200 ms als harte Obergrenze, plane aber Puffer ein, da Conversions laut SpeedCurve teils schon bei 100 ms leiden. Definiere getrennte Budgets für Mobil und Desktop. Da Österreich mit 42,4 Prozent mobilem Traffic und nahezu flächendeckendem 3G/4G/5G-Breitband (99,5 Prozent) stark mobil ist, sollte das mobile Budget deine primäre Steuergröße sein.

Weiterführendes: INP, KI-Crawler und DSGVO-Consent

INP wirkt nicht isoliert. Generative-Engine-Optimization (GEO) und klassische KI-Crawler bewerten primär den ausgelieferten Inhalt, doch eine schlanke, serverseitig gerenderte Architektur kommt beidem zugute: Server Components reduzieren Client-JavaScript und liefern Inhalte robust im initialen HTML, was Crawler zuverlässiger erfassen und Nutzer schneller bedienen können.

Der DSGVO-Consent ist der häufigste blinde Fleck. Consent-Management-Plattformen laden früh, rendern Overlays und triggern bei Zustimmung eine Kaskade von Drittanbieter-Skripten, die alle den Hauptthread beanspruchen. Drei Massnahmen helfen, ohne die Rechtskonformität zu gefährden: Lade Tracking-Skripte erst nach erteiltem Consent und verzögert. Verlagere nicht-essentielle Skripte serverseitig oder in einen Web Worker. Und halte das Consent-Skript selbst so schlank wie möglich, da es per Definition vor der ersten Interaktion erscheint. So bleibt der Hauptthread frei, wenn der Nutzer den Banner wegklickt, und genau diese erste Interaktion fliesst in den INP ein.