INP optimieren: Interaktivität messen und verbessern

Warum INP fuer technisches SEO im DACH-Raum zaehlt

Interaction to Next Paint (INP) misst, wie schnell eine Website auf Nutzerinteraktionen reagiert. Klicks, Taps und Tastatureingaben loesen einen Verarbeitungsprozess aus, an dessen Ende das naechste sichtbare Bild (Paint) steht. INP erfasst die Verzoegerung ueber den gesamten Seitenbesuch hinweg und nicht nur bei der ersten Eingabe. Seit dem 12. Maerz 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.

Fuer B2B-Anbieter in Oesterreich ist das doppelt relevant. Erstens ist Reaktivitaet ein Geschaeftsfaktor: Eine Analyse von vier E-Commerce-Sites zeigte eine durchgaengig negative Korrelation zwischen INP und Conversion-Rate, wobei Conversions teils schon bei 100 ms litten, also innerhalb des "guten" Bereichs. Zweitens ist der oesterreichische Markt mobil gepraegt: 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 ueber einen erheblichen Teil der Sichtbarkeit.

Die Huerde ist real. International halten mobil nur 64,9 Prozent der Websites einen guten INP, waehrend CLS mit 76,9 Prozent deutlich leichter zu bestehen ist. Der Geraete-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 ausfuehren kann. Ein durch JavaScript blockierter Thread verlaengert diese Phase. Processing Time: die Ausfuehrung der Event-Handler selbst, also Ihre Geschaeftslogik, Framework-Updates und Berechnungen. Presentation Delay: die Zeit, bis der Browser das Ergebnis rendert und den naechsten Frame zeichnet.

Der zentrale Unterschied zu First Input Delay liegt im Messumfang. FID erfasste nur die Verzoegerung der ersten Eingabe und ignorierte die Verarbeitungs- sowie Darstellungszeit. INP betrachtet alle Interaktionen einer Sitzung und meldet (vereinfacht) den hoechsten relevanten Wert. Eine Website kann also einen perfekten FID gehabt haben und trotzdem einen schlechten INP aufweisen, weil spaetere Interaktionen wie das Oeffnen eines Menues, 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 ueberlasteter Hauptthread. Lange Tasks blockieren ihn und verzoegern jede neue Eingabe. Aufgaben ueber 50 ms gelten als Long Tasks. Die Datenlage ist eindeutig: Die mediane mobile Seite verbringt 2.366 ms in Long Tasks gegenueber nur 329 ms auf dem Desktop, bei 14 statt 3 langen Tasks im Median. Total Blocking Time, der gaengige Labor-Proxy fuer INP, liegt mobil im Median bei 1.208 ms gegenueber 67 ms auf dem Desktop, also rund 18-mal hoeher.

INP messen: Felddaten schlagen Labordaten

Fuer eine belastbare Diagnose muessen Sie Feld- und Labordaten trennen.

Felddaten (massgeblich): Sie stammen von echten Nutzern. Der Chrome User Experience Report (CrUX) speist PageSpeed Insights und die Search Console. Fuer kontinuierliche Ueberwachung integrieren Sie die web-vitals-JavaScript-Bibliothek oder eine Real-User-Monitoring-Loesung (RUM). Nur Felddaten spiegeln reale Geraete, Netzqualitaet und Interaktionsmuster wider. Genau hier zeigt sich der mobile Nachteil aus echter Rechenleistung und Netzqualitaet.

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

Die Konsequenz: Optimieren Sie nicht blind gegen einen Lighthouse-Score. Priorisieren Sie nach Perzentil. Der INP-Wert wird vom langsamen Ende der Verteilung bestimmt, also vom 75. Perzentil aufwaerts. Eine Interaktion, die im Schnitt schnell ist, aber bei zehn Prozent der Nutzer 600 ms braucht, ist Ihr eigentliches Problem.

Best Practices: Hauptthread entlasten und Interaktionen beschleunigen

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

Lange Tasks aufbrechen: Zerlegen Sie Arbeit in kleinere Einheiten und geben Sie die Kontrolle an den Hauptthread zurueck, bevor 50 ms ueberschritten werden. scheduler.yield() gibt nach laufender Arbeit ab und setzt sie priorisiert fort. scheduler.postTask() erlaubt explizite Prioritaeten. setTimeout dient als breiter unterstuetzter Fallback. isInputPending() prueft, ob eine Eingabe wartet, sodass Sie zugunsten der Reaktivitaet unterbrechen koennen.

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. Laden Sie nur, was die jeweilige Seite braucht, und verschieben Sie nicht-kritische Logik.

Event-Handler optimieren: Drosseln Sie haeufige Events. Debouncing fuer Eingaben und Throttling fuer Scroll- oder Resize-Handler verhindern unnoetige Arbeit. Die redBus-Fallstudie belegt das praezise: Durch Debouncing des Scroll-Handlers und lokales State-Management mit verzoegerter Redux-Synchronisierung sank der INP der Suchseite um 72 Prozent bei einem Umsatzplus von 7 Prozent. Vermeiden Sie teure Re-Renders, nutzen Sie requestAnimationFrame fuer visuelle Updates, setzen Sie CSS statt JavaScript fuer Animationen ein und entlasten Sie das Rendering mit content-visibility.

Third-Party- und Consent-Skripte zaehmen: Tracking-, Tag-Manager- und Consent-Skripte laufen oft auf dem Hauptthread und blockieren ihn genau dann, wenn der Nutzer interagieren will. Laden Sie sie verzoegert, nach der ersten Interaktion oder in einem Web Worker. Pruefen Sie, welche Skripte wirklich kritisch sind.

Next.js-Architektur fuer 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 Interaktivitaet 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 Abspruenge und 43 Prozent mehr Seitenaufrufe.

Streaming und Suspense: Mit <Suspense> streamen Sie Teile der Seite, sobald sie bereit sind, statt auf alles zu warten. Das verkuerzt die Zeit bis zur Interaktivitaet sichtbarer Bereiche.

Selektive Hydration und dynamische Importe: Markieren Sie nur interaktive Inseln als Client-Komponenten ("use client"). Schwere Client-Komponenten laden Sie ueber next/dynamic, idealerweise erst bei Bedarf. So vermeiden Sie grosse Client-Bundles, die den Hauptthread frueh blockieren.

Haeufige Fehler bei der INP-Optimierung

Nur auf den Lighthouse-Score schauen: Ein gruener Laborwert garantiert keinen guten INP im Feld. Labordaten kennen keine echten Interaktionen ueber die Zeit. Ohne Felddaten und Perzentil-Betrachtung optimieren Sie am Problem vorbei.

Den langsamsten Fall ignorieren: Wer Durchschnitte betrachtet, uebersieht das 75. Perzentil. Genau dort wird INP gemessen. Identifizieren Sie die langsamste Interaktion gezielt.

Consent- und Tracking-Skripte unangetastet lassen: Banner-Skripte erscheinen frueh und blockieren oft genau die erste Interaktion. Ohne verzoegertes oder ausgelagertes Laden bleibt der Effekt sichtbar, gerade unter den realen Bedingungen mobiler Geraete.

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

JavaScript ungeprueft akkumulieren: Wenn 44 Prozent des ausgelieferten JavaScripts ungenutzt sind, ist das toter Ballast. Pruefen Sie regelmaessig die Coverage und entfernen Sie ungenutzten Code.

Metriken, Debugging und Priorisierung in der Praxis

Fuer das gezielte Debuggen stehen heute praezise Werkzeuge bereit.

Long Animation Frames (LoAF) API: Sie liefert detaillierte Daten zu langen Frames inklusive verursachender Skripte und blockierender Quelle. Damit identifizieren Sie 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 sehen Sie, welche der drei Phasen dominiert, und richten 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-Loesung erfassen Sie pro Nutzer die schlimmste Interaktion samt Kontext. Priorisieren Sie nach Haeufigkeit und Schwere am 75. Perzentil.

Zielwerte fuer DACH ableiten: Setzen Sie 200 ms als harte Obergrenze, planen Sie aber Puffer ein, da Conversions laut SpeedCurve teils schon bei 100 ms leiden. Definieren Sie getrennte Budgets fuer Mobil und Desktop. Da Oesterreich mit 42,4 Prozent mobilem Traffic und nahezu flaechendeckendem 3G/4G/5G-Breitband (99,5 Prozent) stark mobil ist, sollte das mobile Budget Ihre primaere Steuergroesse sein.

Weiterfuehrendes: INP, KI-Crawler und DSGVO-Consent

INP wirkt nicht isoliert. Generative-Engine-Optimization (GEO) und klassische KI-Crawler bewerten primaer 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 zuverlaessiger erfassen und Nutzer schneller bedienen koennen.

Der DSGVO-Consent ist der haeufigste blinde Fleck. Consent-Management-Plattformen laden frueh, rendern Overlays und triggern bei Zustimmung eine Kaskade von Drittanbieter-Skripten, die alle den Hauptthread beanspruchen. Drei Massnahmen helfen, ohne die Rechtskonformitaet zu gefaehrden: Laden Sie Tracking-Skripte erst nach erteiltem Consent und verzoegert. Verlagern Sie nicht-essentielle Skripte serverseitig oder in einen Web Worker. Und halten Sie das Consent-Skript selbst so schlank wie moeglich, 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.