INP verbessern: Interaktionen ohne Verzögerung

Eine Website, die auf Klicks und Taps nicht sofort reagiert, verliert Nutzer — besonders auf Mobilgeräten, wo die Mehrheit der Patienten heute Praxen und Therapeuten sucht. Interaction to Next Paint (INP) ist die Google-Kennzahl, die genau dieses Problem quantifiziert. Seit März 2024 ersetzt INP vollständig First Input Delay (FID) als Core Web Vital für Interaktionsreaktionsfähigkeit.

Der Zielwert liegt bei 200 Millisekunden oder weniger am 75. Perzentil. Praxiswebsites mit Terminbuchungswidgets, Kontaktformularen, Akkordeons für Leistungsbeschreibungen und Cookie-Bannern sind besonders betroffen, weil jede dieser Interaktionen den INP-Wert beeinflusst.

Was INP misst — und was nicht

INP erfasst die Latenz zwischen einer Nutzerinteraktion (Klick, Tap, Tastendruck) und dem nächsten Frame, den der Browser rendern kann. Gemessen wird die schlechteste Interaktion über den gesamten Seitenbesuch — nicht der Durchschnitt.

Das unterscheidet INP fundamental von FID, das nur die erste Interaktion maß. Eine Seite kann beim ersten Klick schnell reagieren, aber bei jedem weiteren Klick auf ein Akkordeon, einen Filter oder ein Formularfeld spürbar verzögern. INP deckt genau dieses Muster auf.

INP misst nicht die Dauer von Animationen oder Netzwerk-Requests nach der Interaktion. Es misst, wie schnell der Main Thread frei genug ist, um visuelles Feedback zu rendern. Ein Button, der nach 150 ms seine Farbe ändert, ist gut. Ein Button, der 400 ms lang nichts tut, verschlechtert INP — auch wenn danach alles schnell lädt.

Typische INP-Probleme auf Praxiswebsites

Überladene WordPress-Installationen mit 20 oder mehr Plugins laden JavaScript, das den Main Thread blockiert, bevor überhaupt eine Interaktion stattfindet. Page Builder erzeugen große DOM-Bäume, deren Manipulation bei jedem Klick teuer ist.

Eingebettete Third-Party-Widgets — Doctolib, Jameda, Cookie-Consent-Tools, Google Maps, Chat-Plugins — führen oft eigene Event-Handler ein und konkurrieren um Main-Thread-Zeit. Ein Cookie-Banner, das bei jedem Seitenaufruf schwere Consent-Logik ausführt, kann INP bereits beim ersten Klick verschlechtern.

Client-seitig gerenderte Kontaktformulare mit komplexer Validierungslogik, mehrstufige Buchungsassistenten und Filter-Interfaces auf Leistungsübersichten sind weitere häufige Ursachen. Auch scheinbar harmlose Elemente wie Smooth-Scroll-Handler oder Parallax-Effekte tragen bei, wenn sie bei Scroll-Events ohne Throttling laufen.

JavaScript reduzieren: Der effektivste Hebel

Der direkteste Weg zu besserem INP ist weniger JavaScript auf dem Main Thread. Bei Praxiswebsites mit überwiegend statischen Inhalten ist der Großteil der Interaktivität vermeidbar.

Navigation, Leistungsübersichten, Teamprofile und Blogartikel funktionieren als statisches HTML ohne Client-Rendering. JavaScript wird nur dort eingesetzt, wo echte Interaktivität nötig ist: ein Akkordeon für FAQ-Bereiche, ein Kontaktformular mit Echtzeit-Validierung, ein mobiles Hamburger-Menü.

Frameworks wie Astro setzen genau diesen Ansatz um: Islands Architecture lädt JavaScript nur für einzelne Komponenten, nicht für die gesamte Seite. Das reduziert die initiale JavaScript-Last und damit die Wahrscheinlichkeit, dass der Main Thread bei Interaktionen blockiert ist.

Ein JavaScript-Audit sollte folgende Fragen stellen: Welche Skripte sind für die Kernfunktion nötig? Können Analytics und Tracking verzögert geladen werden? Lässt sich das Kontaktformular serverseitig verarbeiten? Kann die Terminbuchung als Link statt als eingebettetes Widget erfolgen?

Event-Handler und DOM-Optimierung

Wenn JavaScript unvermeidlich ist, muss es effizient sein. Häufige Fehler: Event-Listener auf dem document- oder window-Objekt ohne Delegation, die bei jedem Klick den gesamten DOM durchsuchen. Schwere Berechnungen synchron im Click-Handler statt in requestIdleCallback oder Web Workers. DOM-Updates, die Layout Thrashing auslösen — erst lesen, dann schreiben, statt abwechselnd.

Best Practices: Event Delegation für Listen und wiederholte Elemente. Debouncing und Throttling für Scroll- und Resize-Handler. DocumentFragment für Batch-DOM-Updates. Virtualisierung für lange Listen. Code-Splitting, damit nur der Code geladen wird, der für die aktuelle Interaktion nötig ist.

Für Praxiswebsites mit einfacher Struktur reichen oft native HTML-Elemente: details/summary für Akkordeons statt JavaScript-Lösungen, CSS :target für einfache Tab-Navigation, native Formularvalidierung mit HTML5-Attributen als erste Verteidigungslinie.

Third-Party-Skripte kontrollieren

Jedes externe Skript ist ein INP-Risiko, weil Sie die Codequalität nicht kontrollieren. Strategien zur Eindämmung:

Facaded Loading: Statt Google Maps direkt einzubetten, ein statisches Kartenbild mit einem „Karte laden“-Button anzeigen. Das echte Maps-Widget wird erst nach Klick initialisiert. Dieselbe Technik funktioniert für Video-Embeds und Chat-Widgets.

Partytown oder ähnliche Ansätze verschieben Third-Party-Skripte in Web Workers, um den Main Thread zu entlasten. Nicht alle Skripte sind kompatibel, aber Analytics-Tools funktionieren häufig.

Consent-basiertes Laden: Tracking- und Marketing-Skripte erst nach expliziter Einwilligung laden. Das verbessert INP für alle Nutzer, die nicht zustimmen, und ist gleichzeitig DSGVO-konform.

INP messen und überwachen

Labormessungen in Lighthouse simulieren Interaktionen, spiegeln aber nicht immer reale Nutzermuster wider. PageSpeed Insights zeigt Felddaten aus CrUX, wenn genügend Traffic vorhanden ist.

Chrome DevTools → Performance: Seite laden, mit Elementen interagieren, Main-Thread-Aktivität analysieren. Lange Tasks über 50 ms identifizieren — sie sind der Hauptverursacher schlechten INP. Der Long Task API und Performance Observer helfen bei der automatisierten Erkennung in der Entwicklung.

Bei Praxiswebsites mit moderatem Traffic fehlen Felddaten oft. Dann Labormessungen als Proxy nutzen und nach Launch die Search Console auf INP-Berichte überwachen.

FAQ: INP in der Praxis

Unser Kontaktformular reagiert langsam — was tun? Validierung serverseitig verlagern, Client-JS minimieren, Formular als statisches HTML mit progressive enhancement aufbauen.

Das Buchungswidget ist langsam, aber wir brauchen es. Was tun? Als Facade implementieren: statischer Button, der das Widget erst nach Klick lädt. Alternativ direkt auf die Buchungsplattform verlinken.

Wir nutzen WordPress — können wir INP verbessern, ohne zu migrieren? Ja, begrenzt: Plugins reduzieren, Caching optimieren, schweres Theme wechseln, Third-Party-Skripte verzögern. Grundsätzliche Verbesserungen erfordern oft strukturelle Änderungen.

Wie schnell wirkt sich INP auf Rankings aus? Google nutzt 28-Tage-CrUX-Fenster. Verbesserungen zeigen sich typischerweise nach vier bis acht Wochen in den Felddaten.

Fazit

INP belohnt schlanke, durchdachte Websites und bestraft überladene Frontends mit unnötigem JavaScript. Für Praxiswebsites, deren Kernaufgabe Informationsvermittlung und Vertrauensbildung ist, lässt sich INP oft durch architektonische Entscheidungen lösen — weniger Client-Code, gezielte Interaktivität, kontrollierte Third-Party-Einbindung. Bei Monoworks optimieren wir Interaktionsreaktionsfähigkeit von Anfang an mit, weil eine schnell reagierende Praxiswebsite den Unterschied zwischen einem vergebenen Termin und einem abgebrochenen Besuch ausmacht.