Was ist Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) ist ein Google Core Web Vital, der die Reaktionsfähigkeit einer Webseite misst. Er erfasst die längste Verzögerung zwischen einer Benutzerinteraktion (Klick, Tap, Tastendruck) und der nächsten sichtbaren Aktualisierung während des gesamten Seitenbesuchs und meldet das 75. Perzentil über alle realen Nutzersitzungen. INP wurde am 12. März 2024 offizieller Core Web Vital und Ranking-Signal und ersetzte First Input Delay (FID), die seit 2020 die ursprüngliche Responsiveness-Metrik war. Ein guter INP-Wert liegt bei 200 Millisekunden oder weniger. Über 500 ms wirkt die Seite spürbar träge. INP wird von echten Chrome-Nutzern gemessen (Chrome User Experience Report, CrUX-Dataset) und in der Google Search Console unter Core Web Vitals, in PageSpeed Insights, im Chrome DevTools Performance Panel und über die web-vitals JavaScript-Library ausgewiesen. INP belohnt Seiten mit wenig JavaScript, kleinen Event-Handlern, Server-Side-Rendering und sauberem Task Scheduling. Es bestraft schwere React-Rerenders, blockierende Analytics beim Klick, synchrone Drittanbieter-Skripte und ungebrochene Long Tasks über 50 ms.

Wie wird INP gemessen?

Für jede Interaktion auf einer Seite (Klick, Tap, Tastendruck, manche Drags in Formularen) misst der Browser drei Phasen:

1. Input Delay: Zeit von der Interaktion bis zum Start des zugehörigen Event-Handlers. Lange Input Delays bedeuten, dass der Main Thread mit einer anderen Aufgabe beschäftigt war.
2. Processing Time: wie lange der Event-Handler (und alle weiteren registrierten Listener) läuft.
3. Presentation Delay: Zeit vom Ende der Verarbeitung bis das nächste Bild auf dem Bildschirm gerendert wird.

Die Summe ergibt die Interaktions-Latenz. INP meldet die längste beobachtete Latenz im Besuch (mit kleiner Toleranz: bei sehr vielen Interaktionen wird ein Ausreißer pro 50 ignoriert). Der Wert wird beim Page Unload abgeschlossen und über die Performance Observer API gemeldet.

Welche INP-Schwellen gelten?

Google sieht die Core-Web-Vitals-Schwelle als bestanden, wenn das 75. Perzentil auf Mobile und Desktop unter 200 ms bleibt. Stand Februar 2025 bestehen weltweit etwa 65 Prozent der mobilen URLs im CrUX-Dataset die INP-Schwelle, gegenüber 55 Prozent zum Start im März 2024.

Warum hat INP FID abgelöst?

First Input Delay maß nur die Verzögerung vor der ersten Interaktion. Zwei wichtige Probleme blieben unbeachtet:

• FID ignorierte alle Interaktionen nach der ersten. Eine Seite konnte beim ersten Klick schnell wirken und bei jedem weiteren langsam sein.
• FID enthielt weder Processing- noch Rendering-Zeit. Ein Handler, der 800 ms nach kurzer Input Delay lief, bekam trotzdem einen Top-FID-Wert.

INP löst beides: er beobachtet jede Interaktion und schließt den gesamten Weg bis zum nächsten Paint ein.

Was verursacht schlechten INP?

• Long Tasks auf dem Main Thread: jedes JavaScript, das länger als 50 ms ohne Yield läuft, blockiert die nächste Interaktion. Häufige Verursacher: große React/Vue-Rerenders, Framework-Hydration, Analytics-Initialisierung (Google Tag Manager mit vielen Tags, Hotjar, Segment), Werbe-Libraries.
• Synchrone Drittanbieter-Skripte: Chat-Widget, Cookie-Consent oder A/B-Test, der den Main Thread beim Klick blockiert.
• Schwere Event-Handler: ein Click-Handler, der 10000 Tabellenzeilen clientseitig filtert oder große JSON-Payloads parst.
• Layout Thrashing: abwechselndes Lesen und Schreiben von Layoutwerten erzwingt synchrones Reflow.
• Langsame Framework-Rerenders: Tippen in ein Input, das einen kompletten App-Rerender auslöst.
• Animationen auf dem Main Thread: JS-Animationen, die CSS-Animationen auf dem Compositor sein sollten.
• Langsame CSS-Recalcs: Seiten mit hunderttausenden DOM-Knoten, die bei jeder Interaktion neu berechnet werden.

Wie messe ich INP?

• PageSpeed Insights auf pagespeed.web.dev: zeigt Lab-INP aus Lighthouse und Field-INP aus CrUX (echte Nutzer der letzten 28 Tage).
• Search Console » Core-Web-Vitals-Bericht: gruppiert INP nach URL-Mustern.
• Chrome DevTools Performance Panel: ab Chrome 121 hebt es lange Interaktionen mit ihren drei Phasen hervor.
• web-vitals Library von Google (npm install web-vitals): sendet echten INP der Nutzer an die eigene Analyse:

  import { onINP } from 'web-vitals';
  onINP(metric => {
    fetch('/api/vitals', {
      method: 'POST',
      body: JSON.stringify(metric),
      keepalive: true,
    });
  });

• RUM-Anbieter: Cloudflare Web Analytics, Vercel Speed Insights, SpeedCurve, Calibre, DebugBear, Sentry Performance.
• CrUX Dashboard auf BigQuery: für Trends über Monate hinweg.

Wie optimiere ich INP?

1. Long Tasks in Chunks zerlegen. scheduler.yield() (Chrome 129, Oktober 2024) nutzen oder auf setTimeout(fn, 0) bzw. requestIdleCallback zurückfallen.
2. Nicht-kritisches JavaScript verzögern. defer oder async auf Script-Tags, Analytics und Chat per requestIdleCallback oder nach erstem Input laden.
3. Keine Full-Page-Hydration. Partial Hydration (Astro Islands, React Server Components, Qwik) nutzen, sodass nur interaktive Teile booten.
4. React-Komponenten memoizen mit React.memo, useMemo, useCallback.
5. CSS-Animationen statt JS-Animationen. transform und opacity laufen auf dem Compositor Thread.
6. Teure Handler debouncen. Suche bei Eingabe um 200 bis 300 ms debouncen oder in einen Web Worker auslagern.
7. Schwere Arbeit auf Web Worker verschieben. JSON-Parsing, Bildverarbeitung, Suchindexierung.
8. DOM verkleinern. 5000 Knoten rechnen schneller als 50000.
9. content-visibility: auto bei abgeschnittenen Sektionen.
10. Drittanbieter-Skripte prüfen. Schwere Widgets durch leichte Varianten ersetzen.

Wie verbessere ich INP in WordPress?

• jQuery deaktivieren, falls weder Theme noch Plugin es braucht. WordPress Core entfernt jQuery schrittweise.
• Schnelles Theme: GeneratePress, Astra, Kadence, Blocksy. Schwergewichtige Multi-Purpose-Themes wie Avada oder Bridge mit allen Demos vermeiden.
• Schwere Page Builder vermeiden: Elementor und Divi erzeugen oft 200 KB+ CSS und JS und komplexe DOM-Strukturen. Gutenberg mit nativen Blöcken schneidet besser ab.
• Google Tag Manager und Analytics verzögert laden. WP Rocket Delay JavaScript, FlyingPress, Perfmatters.
• Seiten cachen.
• WooCommerce optimieren: Warenkorb und Checkout sind jQuery-lastig. CartFlows, Cart Pro oder Headless.
• Chat-Widgets begrenzen: Crisp, Intercom, Drift, LiveChat bringen 100 bis 400 KB JavaScript. Erst nach erster Interaktion oder nur auf Kontaktseiten laden.
• Mit Site Kit by Google messen, das INP aus CrUX direkt im WordPress-Dashboard anzeigt.

Verbreitete INP-Mythen

• "Mein Lighthouse-Score ist 100, also passt der INP." Lighthouse misst im Labor. Realer INP aus CrUX zählt für das Ranking und kann deutlich abweichen.
• "Weniger JavaScript ist immer besser für INP." Nur wenn blockierendes JavaScript entfernt wird. Lazy geladenes JavaScript schadet INP nicht.
• "INP zählt nur mobil." INP wird auf Mobile und Desktop getrennt gemessen, beide müssen bestehen.
• "INP ist dasselbe wie TBT." TBT ist eine Lab-Metrik beim Laden. INP misst echte Interaktionen im Feld.

Wie hilft InspectWP bei INP?

InspectWP analysiert die geladene JavaScript-Größe, die Anzahl synchroner Drittanbieter-Skripte und den Einsatz gängiger Performance-Plugins (WP Rocket, LiteSpeed Cache, Perfmatters). Der Report markiert Seiten, die jQuery im Frontend laden, große blockierende Analytics-Skripte einbinden oder bekannte langsame Page Builder verwenden.