Interaction to Next Paint

TL;DR — INP misst, wie schnell eine Seite auf Klicks, Tippen und Tastatureingaben reagiert. Der Browser erfasst während des gesamten Besuchs die Zeit bis zur nächsten sichtbaren Aktualisierung und berichtet annähernd die langsamste Interaktion. 200 ms oder weniger gelten als gut, mehr als 500 ms als schlecht. INP ersetzte 2024 den First Input Delay.

Was INP tatsächlich misst

Beim Klicken, Tippen oder Schreiben erwarten Menschen eine sichtbare Reaktion. Interaction to Next Paint (INP) misst die Zeit von der Interaktion bis zu dem Frame, in dem der Browser die Änderung darstellt.

INP betrachtet nicht nur eine Interaktion, sondern jeden Klick, jedes Tippen und jede Tastatureingabe des gesamten Besuchs und berichtet annähernd die langsamste. Eine einzelne stockende Suche kann deshalb den Gesamtwert verschlechtern.

Scrollen, Hover-Bewegungen und Zoomen zählen nicht. Gemessen werden nur Klicks, Tippen und Tastatureingaben.

Die Schwellenwerte

INP wird in Millisekunden angegeben und von Google in drei Bereiche eingeteilt:

• Gut – 200 ms oder weniger
• Verbesserungswürdig – mehr als 200 ms bis einschließlich 500 ms
• Schlecht – mehr als 500 ms

200 ms bieten wenig Spielraum: Sämtliche Reaktion des Codes auf einen Klick und das Zeichnen des Ergebnisses müssen in dieses Zeitfenster passen.

Warum INP den FID ersetzte

Der frühere First Input Delay (FID) maß nur die Wartezeit vor Beginn der ersten Interaktion. Verarbeitungsdauer und sichtbare Aktualisierung blieben unberücksichtigt.

INP behob all diese Einschränkungen. Die Metrik misst die vollständige Dauer vom Beginn bis zur sichtbaren Aktualisierung bei allen Interaktionen, nicht nur bei der ersten. Google vollzog den Wechsel offiziell am 12. März 2024; bis September 2024 war FID vollständig aus den Werkzeugen verschwunden.

Was schlechte INP-Werte verursacht

Fast immer belegt JavaScript den Hauptthread. Während ein Skript rechnet, kann der Browser weder die Eingabe behandeln noch eine sichtbare Reaktion zeichnen.

• Rechenintensive Arbeit direkt im Klick- oder Tipp-Handler.
• Große „lange Aufgaben“ in JavaScript, die alles andere blockieren.
• Drittanbieter-Skripte – Analytics, Cookie-Einwilligungsbanner, Chat-Widgets und Tag-Manager. Sie gehören selbst auf einfachen Inhaltsseiten zu den schlimmsten Verursachern.

Grundsätzlich sollten Interaktionen weniger Arbeit auslösen. Teilen Sie große Aufgaben auf, damit der Browser Eingaben und Frames dazwischen bearbeiten kann.

Die fortgeschrittene Fassung erklärt die drei Latenzphasen, das 75. Perzentil, konkrete Korrekturen und die SEO-Bedeutung.

TL;DR — INP ist der Core Web Vital für Reaktionsfähigkeit. Die Metrik beobachtet die Latenz aller Klick-, Tipp- und Tastaturinteraktionen eines Besuchs und berichtet den Wert beim 75. Perzentil (pro 50 Interaktionen wird ein Ausreißer verworfen) – nicht nur die erste Eingabe wie FID. Die Interaktionslatenz setzt sich aus Eingabeverzögerung + Verarbeitungsdauer + Darstellungsverzögerung zusammen. Gut sind höchstens 200 ms, schlecht sind mehr als 500 ms, jeweils anhand der Felddaten bei p75. INP ersetzte FID am 12. März 2024; bis September 2024 verschwand FID vollständig aus den Werkzeugen. Teilen Sie lange Aufgaben, geben Sie den Hauptthread mit scheduler.yield() frei, erledigen Sie weniger in Ereignis-Handlern, verkleinern Sie den DOM und verschieben Sie Drittanbieter-Skripte. INP ist eine Feldmetrik – Total Blocking Time dient im Labor nur als Näherung, und beide Werte stimmen nicht immer überein.

Was INP misst und wie es sich von FID unterscheidet

Google definiert INP präzise: “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (Übersetzung) INP bewertet die allgemeine Reaktionsfähigkeit einer Seite, indem die Latenz aller Klick-, Tipp- und Tastaturinteraktionen während des gesamten Besuchs beobachtet wird.

Die Formulierung „alle Interaktionen während des gesamten Besuchs“ ist entscheidend. INP ist eine Metrik auf Besuchsebene, keine Ladezeitmetrik. Google begründet das damit, dass der weitaus größte Teil der Verweildauer auf einer Seite nach dem Laden anfällt. Deshalb zählt die Reaktionsfähigkeit während der Nutzung stärker als nur der erste Eindruck.

Der Unterschied zum First Input Delay ist grundlegend: “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, through the time it takes to run event handlers, and finally up until the browser has painted the next frame.” (Übersetzung) FID maß nur die erste Eingabeverzögerung; INP beobachtet alle Interaktionen einschließlich Handler und nächstem Frame.

Eine wichtige Nuance, weil sich darum ein verbreiteter Irrtum hält: INP ist nicht buchstäblich die langsamste Interaktion. Damit eine Seite nicht wegen eines einzelnen zufälligen Ausschlags abgestraft wird, verwirft der Browser pro 50 Interaktionen einen Ausreißer und berichtet anschließend den Wert beim 75. Perzentil der Seitenaufrufe. Bei einem Besuch mit wenigen Interaktionen entspricht das der langsamsten Interaktion; bei einem interaktionsreichen Besuch werden zuerst einige Ausreißer ausgeschlossen.

Was als Interaktion zählt, ist ebenfalls enger gefasst, als viele annehmen. Gemessen werden nur Klicks, Tippen und Tastatureingaben. Scrollen, Hover-Bewegungen und Zoomen sind ausdrücklich ausgeschlossen. Eine einzelne Geste kann mehrere Ereignisse auslösen: Ein Tippen erzeugt pointerdown, pointerup und click. INP gruppiert diese Ereignisse zu einer Interaktion, nicht zu drei. Innerhalb der Gruppe zählt die längste einzelne Ereignisdauer, nicht deren Summe. Ein schnelles pointerdown neben einem langsamen click wird daher als eine Interaktion mit der Dauer des langsamen Ereignisses berichtet. Gibt es während eines Besuchs keine qualifizierende Interaktion, wird für ihn schlicht kein INP gemeldet.

Die drei Bestandteile der Interaktionslatenz

Jede Interaktion besteht aus drei aufeinanderfolgenden Phasen. Jede Phase weist auf eine andere Korrektur hin:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Eingabeverzögerung – Wartezeit, bevor Handler beginnen können, meist wegen einer laufenden langen Aufgabe.
2. Verarbeitungsdauer – Zeit für alle Ereignis-Callbacks der Interaktion.
3. Darstellungsverzögerung – Zeit vom Ende der Handler bis zum Layout und Zeichnen des nächsten Frames.

Der Attribution-Build von web-vitals stellt alle drei Werte bereit (inputDelay, processingDuration, presentationDelay), sodass die dominierende Phase pro Interaktion sichtbar wird.

Schwellenwerte und das 75. Perzentil im Feld

Google Search Central nennt das Ziel ausdrücklich: “an INP of less than 200 milliseconds” (Übersetzung) „ein INP unter 200 Millisekunden“. Außerdem heißt es: “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (Übersetzung) „Wir empfehlen Website-Betreibenden nachdrücklich, gute Core Web Vitals zu erreichen, um in der Suche erfolgreich zu sein.“ Das Budget von 200 ms ist tatsächlich knapp, wenn der Browser bei 60 fps ungefähr alle 16,7 ms einen Frame darstellen soll: Sämtliche Handler-Arbeit und die Darstellung müssen darin Platz finden.

Warum INP eine Feldmetrik ist

Ein grüner Lighthouse-Wert garantiert keinen guten INP. Die Aussage, Lighthouse könne INP nicht messen, muss jedoch in drei Fälle getrennt werden:

1. Ein normaler, nicht interaktiver Lighthouse-Lauf liefert keinen INP. Er beobachtet nur das Laden und verwendet Total Blocking Time als Labornäherung.
2. Eine manuell ausgeführte Laborinteraktion kann echte Interaktionslatenz messen. Sie ist reproduzierbar, bildet aber nur dieses Gerät und diese Interaktion ab.
3. Die Feldverteilung bleibt maßgeblich. CrUX und RUM erfassen viele reale Besuche; das 75. Perzentil entscheidet über den Core-Web-Vitals-Status.

Nutzen Sie das Labor zum Finden und Reproduzieren langsamer Interaktionen; bestätigen Sie im Feld, ob diese reale Besuche tatsächlich beeinträchtigen.

Warum der INP-Wert schlecht ist

Fast jedes INP-Problem entsteht, weil der Hauptthread bei einer Interaktion blockiert ist. Typische Ursachen sind:

• Lange Aufgaben. Jede Hauptthread-Aufgabe über 50 ms ist lang; der Anteil über 50 ms ist ihre Blockierungszeit.
• Zu viel synchrone Handler-Arbeit.
• Layout-Thrashing durch abwechselndes Lesen und Schreiben von Layoutwerten.
• Große DOM-Bäume, die Stilberechnung, Layout und Zeichnen verteuern.
• Drittanbieter-JavaScript, das mit eigenem Code um den Hauptthread konkurriert.

So verbessern Sie INP

Die Strategien ungefähr in der Reihenfolge ihrer Wirkung:

1. Lange Aufgaben aufteilen. Googles Kernaussage zu Handlern lautet: “do as little work as possible in them.” (Übersetzung) Führen Sie darin so wenig Arbeit wie möglich aus. Teilen Sie große Aufgaben, damit Eingaben dazwischen verarbeitet werden können.

2. Dem Hauptthread Zeit geben. Der moderne, empfohlene Weg ist scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() pausiert den Code, lässt den Browser ausstehende Arbeit erledigen und setzt ihn mit Priorität fort, sodass andere Aufgaben die Fortsetzung nicht überholen. Der klassische Rückfall ist setTimeout(..., 0). Er funktioniert weiterhin, stellt den Code aber ans Ende der Aufgabenwarteschlange; nach mehreren verschachtelten Aufrufen erzwingen Browser zudem mindestens 5 ms Wartezeit. isInputPending() sollten Sie dagegen nicht mehr einsetzen. Google sagt dazu: “we no longer recommend using this API.” (Übersetzung) „Wir empfehlen die Verwendung dieser API nicht mehr.“ Das Muster finden Sie im Tab Skripte.

3. In Ereignis-Handlern weniger tun und unkritische Arbeit verschieben. Führen Sie synchron nur die sichtbare Aktualisierung aus, die der nächste Frame benötigt. Verschieben Sie alles andere – Speichern, Rechtschreibprüfung, Analytics und Wortzählung – hinter requestAnimationFrame + setTimeout oder eine Freigabe. Die Reaktion wird sofort sichtbar; die Verwaltungsarbeit folgt danach.

4. Layout-Thrashing vermeiden. Bündeln Sie Layout-Lesevorgänge vor Schreibvorgängen, damit der Browser kein wiederholtes synchrones Layout erzwingen muss.

5. DOM verkleinern. Kleine Bäume werden schneller dargestellt. content-visibility kann Elemente außerhalb des sichtbaren Bereichs verzögert rendern.

6. Drittanbieter-Skripte prüfen und verschieben. Laden Sie Consent-, Tag- und Analytics-Skripte verzögert, begrenzen Sie Ausführung und entfernen Sie redundante Anbieter.

Beeinflusst INP Rankings?

Ja. INP gehört zu den drei Core Web Vitals und damit zu Googles Signalen für Seitenerfahrung. Es ist jedoch ein leicht gewichtetes Signal: Eine relevante Seite verliert nicht allein wegen eines mäßigen INP gegen irrelevante Inhalte.

Zwei praktische SEO-Punkte: Mobilgeräte sind entscheidend, weil sie wesentlich seltener bestehen als Desktopgeräte. Außerdem können langsame Interaktionen Konversionen und Nutzung direkt beeinträchtigen, unabhängig vom Ranking.

INP und FID im vollständigen Vergleich

FID wurde am Starttag von INP aus Search Console und bis September 2024 aus CrUX entfernt. Sein früherer guter Schwellenwert lag bei 100 ms. Verweist ein Werkzeug noch darauf, ist es veraltet.

Sonderfälle, die INP-Daten voneinander abweichen lassen

Die meisten Unterschiede zwischen RUM und CrUX entstehen durch einige Lebenszyklus-Eigenheiten:

• Keine Interaktion, kein INP. Ohne Klick, Tippen oder Tastendruck entsteht kein Wert.
• Iframe-Lücke. CrUX kann Interaktionen in Frames einbeziehen, Seiten-RUM sieht fremde Frames nicht.
• bfcache setzt die Messung zurück. Wiederhergestellte Seiten beginnen einen neuen Messzeitraum.
• Versteckte oder lange geöffnete Tabs. Die Bibliothek meldet bei Sichtbarkeitswechseln, unload und Seitenende Zwischenwerte.

Einordnung

INP ergänzt Largest Contentful Paint für Ladeleistung und Cumulative Layout Shift für visuelle Stabilität. Bei Leistungsproblemen sollte zuerst die schwächste reale Metrik optimiert werden.

KI-Zusammenfassung

Die Kernaussagen der fortgeschrittenen Fassung:

• INP ist der Core Web Vital für Reaktionsfähigkeit. Die Metrik beobachtet die Latenz aller Klick-, Tipp- und Tastaturinteraktionen eines gesamten Besuchs und berichtet den Wert beim 75. Perzentil; pro 50 Interaktionen wird ein Ausreißer verworfen. Anders als FID betrachtet INP nicht nur die erste Eingabe.
• Latenz = Eingabeverzögerung + Verarbeitungsdauer + Darstellungsverzögerung. Jede Phase weist auf eine andere Korrektur hin; bei der Verarbeitungsdauer liegt meist der größte Hebel.
• Schwellenwerte (Feld, p75): gut ≤ 200 ms, verbesserungsbedürftig ≤ 500 ms, schlecht

  500 ms.

• Nur Klicks, Tippen und Tastatureingaben zählen – Scrollen, Hover-Bewegungen und Zoomen sind ausgeschlossen; mehrere Ereignisse einer Geste werden zu einer Interaktion gruppiert.
• INP ersetzte FID am 12. März 2024; bis September 2024 war FID vollständig aus den Werkzeugen verschwunden. FID maß nur die Eingabeverzögerung der ersten Interaktion.
• INP ist eine Feldmetrik, und „Lighthouse kann sie nicht messen“ umfasst drei Fälle: Ein normaler, nicht interaktiver Lighthouse-Lauf meldet keinen INP und verwendet Total Blocking Time als Ladezeitnäherung. Eine manuell ausgeführte Laborinteraktion liefert die echte Latenz dieser einzelnen Interaktion, ersetzt aber nicht die Feldpopulation. Maßgeblich sind nur Felddaten aus CrUX, PageSpeed Insights oder Search Console.
• Ursachen: lange Aufgaben (>50 ms), aufwendige Ereignis-Handler, große DOMs und besonders Drittanbieter-Skripte wie Einwilligungsdienste, Tag-Manager, Analytics und Chat.
• Korrekturen: lange Aufgaben teilen, mit scheduler.yield() freigeben (setTimeout als Rückfall; isInputPending() wird nicht mehr empfohlen), in Handlern weniger tun, Layout-Thrashing vermeiden, den DOM verkleinern und Drittanbieter-Skripte verschieben.
• Sonderfälle: Ohne qualifizierende Interaktion gibt es keinen INP-Wert. Iframe-Interaktionen zählen zur Metrik, sind für ein Same-Origin-RUM-Skript aber nicht im Iframe sichtbar. Eine Wiederherstellung aus dem bfcache setzt INP zurück; lange geöffnete oder im Hintergrund liegende Tabs sollten beim Verbergen und nicht erst beim Entladen berichten.
• SEO: INP ist ein leicht gewichtetes Rankingsignal. Unter Mobile-first Indexing ist Mobil mit rund 74 % bestandenen Seiten gegenüber rund 97 % am Desktop maßgeblich; Seiten mit vielen Interaktionen sind am stärksten betroffen.

Offizielle Dokumentation

Primärquellen von Google und dem Chrome-Team.

web.dev – INP-Referenzen

• Interaction to Next Paint: INP erklärt – Definition, Latenzphasen, Interaktionstypen und Schwellenwerte.
• INP optimieren – Korrekturen für Handler, Layout, DOM und content-visibility.
• Interaction to Next Paint officially becomes a Core Web Vital – Einführung am 12. März 2024.
• First Input Delay (FID) – eingestellte Vorgängermetrik.
• Eine neue Reaktionsmetrik – Grenzen von FID.
• Lange Aufgaben optimieren – 50-ms-Definition, scheduler.yield(), setTimeout und isInputPending().
• Skriptauswertung und lange Aufgaben – TBT als Näherungswert.
• Langsame Interaktionen im Feld finden – Attribution mit web-vitals und Long Animation Frames.

Chrome / Google-Suche

• Performance features reference – Interaktionsspur, Live-Metriken und 200-ms-Warnung.
• CrUX release notes – Entfernung von FID im September 2024.
• Core Web Vitals & Google Search results – INP als Signal für Seitenerfahrung und Zielwert ≤ 200 ms.

Zitate aus den Quellen

Nachprüfbare Aussagen von Google und dem Chrome-Team. Jeder Link führt direkt zur zitierten Passage.

INP im Vergleich zu FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (Übersetzung) INP bewertet die Reaktionsfähigkeit anhand sämtlicher Klick-, Tipp- und Tastaturinteraktionen eines Besuchs. — web.dev, Interaction to Next Paint (INP). Zum Zitat
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (Übersetzung) FID maß nur die Verzögerung der ersten Eingabe; INP beobachtet sämtliche Interaktionen bis zur Handler-Ausführung. Zum Zitat
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (Übersetzung) FID ist kein Core Web Vital mehr und wurde durch INP ersetzt. — web.dev, First Input Delay (FID). Zum Zitat

Der Wechsel von FID zu INP

• “FID will be deprecated.” (Übersetzung) FID wird eingestellt. — Jeremy Wagner und Rick Viscomi, web.dev. Zum Zitat
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (Übersetzung) FID wird aus der Google Search Console entfernt, sobald INP am 12. März zum Core Web Vital wird. Zum Zitat

Lange Aufgaben als Hauptursache

• “Any task that takes longer than 50 milliseconds is a long task.” (Übersetzung) Jede Aufgabe über 50 Millisekunden ist eine lange Aufgabe. — web.dev, Optimize long tasks. Zum Zitat

Felddaten haben Vorrang

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (Übersetzung) Felddaten sind die beste Quelle, um problematische Interaktionen echter Nutzender zu verstehen. — web.dev, Find slow interactions in the field. Zum Zitat

Google-Suche

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (Übersetzung) Website-Betreibende sollten für den Erfolg in der Suche gute Core Web Vitals erreichen. — Google Search Central. Quelle

Checkliste zur INP-Verbesserung

Arbeiten Sie von oben nach unten; die ersten Punkte verändern den Wert meist am stärksten:

• Feld-INP aus PageSpeed Insights oder Search Console abrufen und Mobilgeräte getrennt prüfen.
• Langsame Interaktionen mit dem Attribution-Build von web-vitals oder der DevTools-Interaktionsspur bestimmen; sie markiert Werte über 200 ms.
• Lange Aufgaben über 50 ms finden und teilen.
• In langen Schleifen mit scheduler.yield() beziehungsweise setTimeout(..., 0) freigeben; isInputPending() nicht mehr verwenden.
• Im Handler nur die darstellungskritische Aktualisierung synchron ausführen; Folgearbeit hinter rAF und setTimeout verschieben.
• Layout-Thrashing durch gebündeltes Lesen und anschließendes Schreiben vermeiden.
• Drittanbieter-Skripte verzögern, bedarfsgerecht laden oder entfernen.
• DOM verkleinern und content-visibility für Bereiche außerhalb des Viewports einsetzen.
• Nicht kritisches JavaScript verzögert laden oder aufteilen.
• Nach der Bereitstellung im Feld erneut messen; CrUX nutzt ein rollierendes 28-Tage-Fenster.

INP und FID – Spickzettel

Kurzfakten

• Feldschwellen bei p75: Gut ≤ 200 ms · Verbesserungswürdig ≤ 500 ms · Schlecht > 500 ms.
• Gezählt werden Klicks, Tippen und Tastatur; ausgeschlossen sind Scrollen, Hover und Zoomen.
• Latenz = Eingabeverzögerung + Verarbeitung + Darstellung.
• Lange Aufgabe = Hauptthread-Aufgabe > 50 ms.
• Labornäherung: Total Blocking Time; maßgeblich bleiben CrUX-Felddaten.
• Mobile Bestehensquote rund 74 %, Desktop rund 97 %.

Dem Hauptthread Zeit geben

Bei langen Schleifen sollte der Browser regelmäßig die Kontrolle zurückerhalten, damit er wartende Interaktionen bedienen kann. Die moderne API ist scheduler.yield(); andernfalls dient setTimeout als Fallback.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Hinweise:

• scheduler.yield() gibt ein Promise für eine zukünftige Aufgabe zurück; die Fortsetzung wird priorisiert.
• setTimeout(..., 0) funktioniert breit, stellt die Fortsetzung aber ans Ende der Warteschlange.
• Google sagt zu isInputPending(): “no longer recommend[s] using this API.” (Übersetzung) Die Verwendung dieser API wird nicht mehr empfohlen.

Nicht kritische Arbeit im Handler verschieben

Führen Sie nur aus, was der nächste Frame benötigt; verschieben Sie alles Weitere bis nach dem Zeichnen.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Werkzeuge zum Messen und Verbessern von INP

Feldmessung – maßgeblich für Google

• PageSpeed Insights – CrUX-INP für URL oder Origin nach Mobilgerät und Desktop.
• Search Console – Core Web Vitals – feldbasierter INP-Status für URL-Gruppen.
• CrUX – zugrunde liegender Datensatz, auch per API und BigQuery.

Labor und Fehleranalyse

• Chrome DevTools – Performance – Interaktionsspur mit Eingabe-, Verarbeitungs- und Darstellungsdauer sowie Warnung über 200 ms.
• Lighthouse – misst INP nicht direkt und berichtet Total Blocking Time als Näherung.

Real User Monitoring

• Die JavaScript-Bibliothek web-vitals liefert mit onINP() den Wert. Der Attribution-Build web-vitals/attribution stellt inputDelay, processingDuration, presentationDelay, interactionTarget und LoAF-Einträge bereit. Dokumentieren Sie Stichprobenrate und Abdeckung; Seiten-RUM kann fremde Iframes nicht wie die aggregierte Metrik sehen.

Wie die Werkzeuge selbst abschneiden

Das folgende Live-Beispiel ordnet bekannte Geschwindigkeits- und Monitoring-Dienste nach ihrem mobilen Feld-INP aus dem Chrome UX Report ein:

INP-Korrekturen, die am Problem vorbeigehen

Nur die erste Interaktion optimieren

INP bewertet Interaktionen über den gesamten Besuch. Prüfen Sie Menüs, Suche, Filter, Formulare und wiederholte Bedienelemente.

Total Blocking Time als Ergebnis behandeln

TBT ist eine nützliche Labornäherung für lange Hauptthread-Aufgaben, aber kein Feld-INP. Nutzen Sie TBT zum Finden und Felddaten zur Bestätigung.

Sämtliche Arbeit in einen verzögerten Callback verschieben

Ein großer verzögerter Block verlagert das Einfrieren nur. Teilen Sie die Arbeit und geben Sie dem Browser zwischen Aufgaben Zeit zum Zeichnen.

Sichtbare Rückmeldung entfernen

Ein Bedienelement ohne sichtbare Reaktion wirkt weiterhin defekt. Stellen Sie den unmittelbaren Zustand zuerst dar und verschieben Sie Folgearbeit.

INP mit dem Drei-Phasen-Modell diagnostizieren

Jede langsame Interaktion bietet drei Ansatzpunkte:

1. Eingabeverzögerung: Frühere Hauptthread-Arbeit blockiert das Ereignis. Prüfen Sie lange Aufgaben und Drittanbieter-JavaScript.
2. Verarbeitungsdauer: Der Handler erledigt zu viel. Verringern Sie synchrone Arbeit und teilen Sie Schleifen.
3. Darstellungsverzögerung: Stil, Layout oder Zeichnen dauern zu lange. Verringern Sie DOM-Komplexität und erzwungene Layouts.

Beginnen Sie mit der größten Phase. Zeichnen Sie dieselbe Interaktion nach jeder Änderung erneut auf.

Nachweisen, dass eine INP-Änderung wirkt

Test der Handler-Freigabe

Test: Zielinteraktion vor und nach dem Teilen langer Arbeit aufzeichnen. Erwartung: Verarbeitungsabschnitt schrumpft oder wird durch einen Frame geteilt. Fehldeutung: Teure Arbeit liegt anderswo. Fenster: sofortige Wiederholungen. Rollback: Reihenfolge, Zustand oder Eingaben brechen.

Darstellungstest

Test: Stil-, Layout- und Zeichenarbeit nach dem Handler prüfen. Erwartung: Nächster Frame kommt früher. Fehldeutung: DOM oder erzwungenes Layout bleibt Engpass. Fenster: Laboraufzeichnungen. Rollback: Reaktion wird unvollständig oder instabil.

Feldbestätigung

Test: Attribution von onINP() nach Bereitstellung mit der Basis vergleichen. Erwartung: p75 verbessert sich und das Zielelement dominiert langsame Ereignisse nicht mehr. Fehldeutung: Laborfall war nicht repräsentativ. Fenster: RUM sofort, CrUX über 28 Tage. Rollback: Reaktionsfähigkeit oder Abschluss verschlechtern sich beständig.

Sinnvolle INP-Metriken

Realer INP beim 75. Perzentil

Metrik: p75-INP nach Vorlage und Geräteklasse. Aussage: Reaktionsfähigkeit typischer Besuche. Quelle: CrUX, PageSpeed Insights oder web-vitals-RUM. Ziel: höchstens 200 ms gut, über 500 ms schlecht. Rhythmus: nach JavaScript-Veröffentlichungen und monatlich.

Anteil langsamer Interaktionen

Metrik: Anteil gemessener Interaktionen über 200 ms nach Ziel. Aussage: Bedienelemente mit häufigen sichtbaren Verzögerungen. Quelle: Attribution-Build von web-vitals oder Event Timing im RUM. Ziel: Basis je Journey festlegen und häufigste Verursacher reduzieren. Rhythmus: wöchentlich.

Anteil der Latenzphasen

Metrik: Eingabe-, Verarbeitungs- und Darstellungsverzögerung langsamer Interaktionen. Aussage: Ob Planung, Handler oder Rendering begrenzen. Quelle: DevTools und INP-Attribution. Ziel: Phasen gegen ihre Basis und insgesamt gegen 200 ms vergleichen. Rhythmus: bei jeder gezielten Leistungsanalyse.

Empfehlenswerte Quellen

Google / Chrome

• Interaction to Next Paint (INP) – Einstieg.
• Optimize Interaction to Next Paint – Korrekturen.
• Optimize long tasks – Freigabe mit scheduler.yield().
• Find slow interactions in the field – LoAF und Attribution.
• INP becomes a Core Web Vital – Einführung am 12. März 2024.

Daten

• Web Almanac 2024 – Performance – reale Bestehensquoten und Teilmetriken.

Aus der Branche

• INP – MDN Web Docs – Browserunterstützung und Definition.
• Scheduler API: scheduler.yield() – MDN – Unterstützung und Spezifikation.
• PerformanceEventTiming – MDN – zugrunde liegende Browser-API.
• Long Animation Frames API – Chrome Platform Status – LoAF-Unterstützung.
• INP-Thema – Search Engine Land – Branchenberichte und Tests.

Zitierfähige Statistiken

• Rund 74 % Mobilgeräte gegenüber rund 97 % Desktop bestehen INP (2024). Web Almanac 2024
• Nur rund 53 % der tausend größten Websites bestehen INP. Web Almanac 2024
• Lange Aufgabe = > 50 ms. Der Anteil über 50 ms blockiert Reaktionen. web.dev – Optimize long tasks
• Mediane Teilwerte 2024: Darstellungsverzögerung liegt mit rund 36 ms häufig vorn; Eingabe und Verarbeitung folgen eng. Web Almanac 2024

Videos

• Google Chrome Developers auf YouTube – Erklärungen zu Core Web Vitals und INP sowie Diagnose langsamer Interaktionen in DevTools. Kanal

Testen Sie Ihr Wissen: Interaction to Next Paint

Fünf kurze Fragen zu Reaktionsfähigkeit und INP-Diagnose. Wählen Sie jeweils eine Antwort und prüfen Sie das Ergebnis.

Änderungsprotokoll