Interaction to Next Paint (INP): Was es ist, wie man es misst und verbessert

Interaction to Next Paint (INP) ist ein Core Web Vital, der misst, wie schnell eine Webseite auf Benutzerinteraktionen wie Klicks, Antippen und Tastatureingaben reagiert. INP erfasst die gesamte Latenz von der Benutzereingabe über die JavaScript-Verarbeitung bis zum endgültigen visuellen Update auf dem Bildschirm. Ein guter INP-Wert liegt bei 200 Millisekunden oder weniger am 75. Perzentil. INP hat First Input Delay (FID) im März 2024 als Core Web Vital abgelöst.

Was ist Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) ist eine Core Web Vital-Metrik, die die Reaktionsfähigkeit einer Webseite während des gesamten Besuchs eines Nutzers misst. Im Gegensatz zu seinem Vorgänger First Input Delay (FID), der nur die Verzögerung vor Beginn des Event-Handlers der ersten Interaktion maß, bewertet INP jede Interaktion, die ein Nutzer mit der Seite durchführt, und gibt einen einzelnen Wert aus, der die Gesamtreaktionsfähigkeit der Seite darstellt.

Jedes Mal, wenn ein Nutzer auf eine Schaltfläche klickt, einen Link antippt, eine Taste auf der Tastatur drückt oder mit einem benutzerdefinierten Steuerelement interagiert, misst der Browser die Gesamtzeit vom Moment der Eingabe bis zum Zeichnen des nächsten Frames auf dem Bildschirm. INP wählt eine der langsamsten dieser Interaktionen als Reaktionsfähigkeitswert der Seite aus. Bei Seiten mit weniger als 50 Gesamtinteraktionen gibt INP die einzelne schlechteste Interaktion aus. Bei Seiten mit vielen Interaktionen verwendet INP typischerweise das 98. Perzentil, um gelegentliche Ausreißer herauszufiltern.

Ein niedriger INP bedeutet, dass die Seite zuverlässig und zeitnah auf Benutzereingaben reagiert. Ein hoher INP bedeutet, dass sich die Seite träge, nicht reaktionsfähig oder "ruckelig" anfühlt, weil der Browser Interaktionen nicht schnell genug verarbeiten und den Bildschirm aktualisieren kann.

INP vs. FID: Was sich geändert hat und warum

INP hat First Input Delay (FID) im März 2024 offiziell als Core Web Vital abgelöst. Google hat FID eingestellt, weil es zwei grundlegende Einschränkungen hatte, die es zu einem unvollständigen Maß für die Seitenreaktionsfähigkeit machten.

Erstens maß FID nur die erste Interaktion auf einer Seite. Wenn der erste Klick eines Nutzers schnell war, aber nachfolgende Interaktionen langsam waren, hätte FID trotz der schlechten Erfahrung einen guten Wert gemeldet. INP misst alle Interaktionen während der gesamten Sitzung und liefert ein weitaus genaueres Bild der tatsächlichen Reaktionsfähigkeit.

Zweitens maß FID nur die Input-Delay-Phase, was bedeutet, dass es die Zeit erfasste, die der Browser mit Warten verbrachte, bevor er mit der Verarbeitung des Events begann. Es ignorierte vollständig die Zeit für die Ausführung des Event-Handler-Codes (Verarbeitungszeit) und die Zeit, die benötigt wurde, um das visuelle Ergebnis auf dem Bildschirm darzustellen (Darstellungsverzögerung). INP erfasst alle drei Phasen und gibt Entwicklern einen vollständigen Überblick über die Interaktionslatenz.

Der Übergang von FID zu INP verursachte laut dem HTTP Archive Web Almanac 2025 einen Rückgang der mobilen Core Web Vitals-Bestehensquoten um etwa 5 Prozentpunkte. Dies geschah, weil viele Seiten, die unter FID reaktionsfähig erschienen, langsame spätere Interaktionen hatten, die INP nun erfasst.

Welche Interaktionen misst INP?

INP misst nur Interaktionen, die diskrete Benutzereingaben beinhalten, die der Browser über Event-Handler beobachten kann. Das Verständnis, welche Interaktionen zählen, ist für ein genaues Debugging und eine effektive Optimierung unerlässlich.

Interaktionen, die für INP zählen

• Mausklicks (einschließlich Klicks auf Schaltflächen, Links, Kontrollkästchen und benutzerdefinierte Steuerelemente)
• Antippen auf Touchscreens (entspricht Klicks auf Mobilgeräten)
• Tastatureingaben auf einer physischen oder Bildschirmtastatur (einschließlich Tippen in Formularfeldern, Drücken der Eingabetaste, Verwenden von Tastaturkürzeln)

Interaktionen, die NICHT für INP zählen

• Scrollen zählt nicht, da es vom Compositor-Thread des Browsers verarbeitet wird und typischerweise den Hauptthread nicht blockiert
• Hovern (Mouseover) zählt nicht, da Hovern ein kontinuierlicher Zeigerzustand ist, keine diskrete Benutzerinteraktion
• Zieh-Gesten zählen nicht, obwohl das anfängliche Pointerdown, das ein Ziehen beginnt, einen INP-Eintrag auslösen kann
• CSS-Übergänge und Animationen, die ohne Benutzereingabe stattfinden, sind keine Interaktionen

Ein häufiges Missverständnis ist, dass Scrollen INP beeinflusst. Das ist nicht der Fall. Wenn Ihre Seite jedoch JavaScript-basiertes Scrollen anstelle von nativem Browser-Scrollen verwendet, können diese JavaScript-Scroll-Handler Event-Callbacks auslösen, die der Browser als Interaktionen misst. Dies ist ein Grund, warum natives CSS-Scrollen beim Thema Reaktionsfähigkeit JavaScript-Scrollen durchweg übertrifft.

Die drei Phasen einer INP-Interaktion

Jede von INP gemessene Interaktion besteht aus drei aufeinanderfolgenden Phasen. Der gesamte INP-Wert ist die Summe aller drei. Das Verständnis jeder Phase ist entscheidend, da die Optimierungsstrategie für jede unterschiedlich ist.

1. Input Delay

Der Input Delay ist die Zeit zwischen der Interaktion des Nutzers mit der Seite und dem Beginn der Ausführung der zugehörigen Event-Handler durch den Browser. Diese Verzögerung tritt auf, weil der Hauptthread des Browsers möglicherweise mit anderen Aufgaben beschäftigt ist, wie dem Parsen von JavaScript, dem Ausführen zuvor geplanter Tasks oder der Verarbeitung anderer Event-Callbacks.

Input Delay ist besonders problematisch während der Seitenladephase, wenn viele Skripte gleichzeitig geparst und ausgeführt werden. CoreDash-Daten zeigen, dass Interaktionen während der Ladephase ein p75 INP von 132ms haben, verglichen mit nur 50ms für Interaktionen nach Abschluss des Seitenladens. Das ist ein 2,6-facher Unterschied. Die Reduzierung der Hauptthread-Konkurrenz während des Seitenstarts ist eine der effektivsten Methoden zur Verbesserung von INP.

Im Median ist der Input Delay der kleinste INP-Teilwert. Aber am 90. Perzentil wird der Input Delay zum dominierenden Faktor, da lange Tasks auf dem Hauptthread die Event-Verarbeitung um Hunderte von Millisekunden verzögern können. Der HTTP Archive Web Almanac 2025 stellte fest, dass weniger als 25% der Websites die Task-Dauer unter dem empfohlenen Schwellenwert von 50ms halten.

2. Verarbeitungszeit

Die Verarbeitungszeit ist die Gesamtzeit, die der Browser mit der Ausführung aller Event-Handler-Callbacks verbringt, die mit der Interaktion verbunden sind. Dies umfasst jegliches JavaScript, das als Reaktion auf das Event ausgeführt wird, von der Formularvalidierung über Statusaktualisierungen bis hin zu Analytics-Tracking-Aufrufen.

Die Verarbeitungszeit macht einen erheblichen Teil des Gesamt-INP aus. Wenn ein Event-Handler aufwendige DOM-Operationen durchführt, synchrone API-Aufrufe tätigt oder ineffiziente Schleifen ausführt, bläht sich die Verarbeitungszeit auf. Ein häufiges Muster, das die Verarbeitungszeit aufbläht, ist das Ausführen von nicht wesentlichem Code (wie Analytics-Events oder Callbacks von Drittanbieter-Tags) innerhalb desselben Event-Handlers wie das kritische visuelle Update.

3. Darstellungsverzögerung

Die Darstellungsverzögerung ist die Zeit zwischen dem Abschluss aller Event-Handler und dem Zeitpunkt, an dem der Browser den nächsten Frame mit dem visuellen Update präsentiert. Diese Phase umfasst die Neuberechnung von Styles, Layout-Berechnung, Painting und Compositing.

Im Median ist die Darstellungsverzögerung der größte INP-Teilwert, da jede Interaktion mindestens einen Rendering-Durchgang erfordert. Seiten mit einem großen oder tief verschachtelten DOM benötigen länger für die Neuberechnung von Styles und das Layout. Single Page Applications, die nach Statusänderungen große Komponentenbäume neu rendern, sind besonders anfällig für hohe Darstellungsverzögerungen.

Was sind gute und schlechte INP-Werte?

Um die Core Web Vitals-Bewertung für die Interaction to Next Paint-Metrik zu bestehen, muss das 75. Perzentil aller im Feld aufgezeichneten Interaktionen unter 200 Millisekunden bleiben:

• Ein INP unter oder bei 200 Millisekunden bedeutet, dass Ihre Seite eine gute Reaktionsfähigkeit hat.
• Ein INP zwischen 200 und 500 Millisekunden bedeutet, dass die Reaktionsfähigkeit Ihrer Seite verbessert werden muss.
• Ein INP über 500 Millisekunden bedeutet, dass Ihre Seite eine schlechte Reaktionsfähigkeit hat.

Es ist wichtig zu verstehen, dass INP das 75. Perzentil verwendet, nicht den Durchschnitt. Das bedeutet, dass 75% Ihrer echten Nutzer Interaktionen schneller als 200ms erleben müssen. Die 75.-Perzentil-Methodik stellt sicher, dass die Metrik die Erfahrung von Nutzern auf langsameren Geräten und Verbindungen widerspiegelt, nicht nur die von Nutzern mit High-End-Hardware.

Wie misst man Interaction to Next Paint (INP)?

Interaction to Next Paint kann nur mit Feldtools gemessen werden, die echte Benutzerinteraktionen erfassen. Im Gegensatz zu Labormetriken, die einen einzelnen Seitenaufruf simulieren, erfordert INP tatsächliche Besucher, die auf Ihren Seiten klicken, tippen und tippen. Es gibt keine Möglichkeit, einen aussagekräftigen INP-Wert aus einem synthetischen Test zu erhalten, da INP von echtem menschlichem Verhalten abhängt.

Die offiziellen INP-Metriken abrufen

Sie können die offiziellen INP-Metriken von PageSpeed Insights oder dem CrUX-Dashboard und Google BigQuery abrufen. PageSpeed Insights gibt den 75.-Perzentil-Wert basierend auf den letzten 28 Tagen Chrome-Nutzerdaten aus. Google BigQuery bietet mehr historischen Kontext und ermöglicht benutzerdefinierte Abfragen über den gesamten CrUX-Datensatz.

Google Search Console meldet INP-Probleme ebenfalls unter dem Abschnitt Core Web Vitals, gruppiert betroffene URLs und markiert Seiten, die verbessert werden müssen oder eine schlechte Reaktionsfähigkeit aufweisen.

INP mit Real User Monitoring verfolgen

Während der offizielle CrUX-Datensatz die definitive Quelle für Core Web Vitals-Werte ist, ist er stark anonymisiert und unterstützt kein Echtzeit-Monitoring oder detailliertes Filtern. Deshalb verlassen sich Web-Performance-Experten auf Real User Monitoring (RUM)-Tools wie CoreDash, um praktische INP-Daten in Echtzeit zu erhalten. RUM-Tools sammeln INP-Messungen von jedem Seitenaufruf, ordnen sie bestimmten Elementen, Ladezuständen und Gerätetypen zu und ermöglichen es Ihnen, genau zu diagnostizieren, welche Interaktionen Probleme verursachen.

INP für die aktuelle Sitzung messen

Der einfachste Weg, INP während der Entwicklung zu debuggen, ist über Chrome DevTools. Öffnen Sie das Performance-Panel und verwenden Sie den "Zeitspanne"-Modus in Lighthouse, um Interaktionen aufzuzeichnen und deren Latenz zu sehen. Sie können auch die Core Web Vitals Visualizer-Erweiterung verwenden, die INP-Werte auf der Seite einblendet, während Sie mit ihr interagieren.

Für praktisches Debugging verwenden Sie die Google Web Vitals JavaScript Library, um einzelne Interaktionen in der Konsole zu protokollieren:

INP mit der Web Vitals JavaScript Library in der Konsole protokollieren

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Wie verbessert man Interaction to Next Paint?

Die Verbesserung von Interaction to Next Paint erfordert die Optimierung aller drei Phasen: Input Delay, Verarbeitungszeit und Darstellungsverzögerung. Ihre Seite reagiert möglicherweise sofort auf die meisten Interaktionen, aber wenn auch nur eine Interaktion langsam ist, kann sie den gesamten INP-Wert bestimmen. Deshalb ist ein systematischer Ansatz notwendig.

PageSpeed TIPP: In den meisten Fällen ist der INP deutlich schlechter, wenn ein Nutzer während der Startphase des Seitenladens mit der Seite interagiert. Deshalb ist es beim Debuggen von INP sinnvoll, alle Interaktionen sowie den Seitenladezustand zu protokollieren!

1. Input Delay minimieren: Lange Tasks auf dem Hauptthread vermeiden

Normalerweise ist jede Seite während der Startphase weniger reaktionsfähig, wenn die meiste Hauptthread-Arbeit stattfindet (Parsen, Decodieren, Rendern und Skripting). Um den Hauptthread so frei wie möglich zu halten:

• Ungenutzten Code entfernen. Verwenden Sie Tree Shaking, um toten Code zu entfernen, und Code Splitting, um Ihr Bundle in kleinere Teile aufzuteilen, die bei Bedarf geladen werden. Überprüfen Sie Ihre Code-Abdeckung mit Chrome DevTools, um Skripte zu identifizieren, die geladen, aber nie ausgeführt werden.
• Nicht wesentlichen Code während der Browser-Leerlaufzeit laden. Brauchen Sie wirklich ein Chat-Widget während der ersten 500ms des Seitenladens? Planen Sie nicht-kritische Skripte mit requestIdleCallback(), damit sie nur ausgeführt werden, wenn der Browser im Leerlauf ist.
• Langsame Skripte identifizieren und umschreiben, die übermäßige CPU-Ressourcen verbrauchen. Verwenden Sie das Chrome Performance-Panel, um Skripte mit langen Ausführungszeiten zu finden und für die Optimierung zu markieren.
• Die Seite einfach zu rendern halten. Große DOM-Größen vermeiden, übermäßig viele Bilder, zu viele Videos und CPU-intensive CSS-Animationen.
• Async und Defer verwenden bei Script-Tags, um zu verhindern, dass JavaScript den HTML-Parser blockiert. Erwägen Sie, nicht-kritisches JavaScript zu verzögern, bis die Seite interaktiv geworden ist.

Lange Tasks mit scheduler.yield() aufteilen

JavaScript läuft auf dem Hauptthread des Browsers nach dem "Run-to-Completion"-Modell: Sobald ein Task startet, blockiert er den Hauptthread, bis er fertig ist. Lange Tasks (über 50ms) hindern den Browser daran, auf Benutzereingaben zu reagieren. Die scheduler.yield()-API ermöglicht es Ihnen, explizit yield-Punkte innerhalb lang laufendem Code zu erstellen, die dem Browser die Möglichkeit geben, ausstehende Benutzerinteraktionen zu verarbeiten, bevor er fortfährt.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Nicht-kritische Arbeit mit requestIdleCallback aufschieben

Verwenden Sie requestIdleCallback(), um nicht wesentliche Aufgaben (Analytics, Telemetrie, Prefetching) für Zeiten zu planen, in denen der Browser im Leerlauf ist. Dies hält den Hauptthread frei für Benutzerinteraktionen und reduziert den Input Delay direkt.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Passive Event Listener verwenden

Für Events, die preventDefault() nicht aufrufen müssen, markieren Sie Ihre Event Listener als passiv. Dies teilt dem Browser mit, dass er nicht auf Ihren Handler warten muss, um zu entscheiden, ob das Standardverhalten abgebrochen werden soll, was flüssigeres Scrollen und schnellere Touch-Reaktionen ermöglicht.

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Verarbeitungszeit minimieren: Sofortiges Feedback geben

Wenn ein Besucher eine Aktion wie das Absenden eines Formulars oder das Hinzufügen eines Artikels zum Warenkorb durchführt, warten Sie nicht auf die serverseitige Bestätigung, bevor Sie die Benutzeroberfläche aktualisieren. Geben Sie sofortiges visuelles Feedback ("Formular wird gesendet...", "Artikel wird zum Warenkorb hinzugefügt...") und schließen Sie den Vorgang dann im Hintergrund ab.

Geben Sie außerdem den Hauptthread so schnell wie möglich nach dem kritischen visuellen Update frei. Da JavaScript dem "Run-to-Completion"-Modell folgt, blockiert es den Hauptthread, bis der gesamte Code im Callback ausgeführt wurde. Sie können manuell einen yield-Punkt erstellen, an dem der Browser das Layout aktualisieren kann, und dann den verbleibenden nicht-kritischen Code weiter ausführen.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Darstellungsverzögerung minimieren: Dinge einfach halten

Wenn die Seite nach einer Interaktion aktualisiert werden muss, muss der Browser Styles neu berechnen, das Layout durchführen, die geänderten Pixel zeichnen und das Ergebnis zusammensetzen. Die Komplexität und Größe Ihres DOMs bestimmt direkt, wie lange diese Rendering-Arbeit dauert.

Einige schlecht optimierte SPA-Umgebungen rendern nach jeder Interaktion viel zu viel Inhalt neu. Wenn Sie beispielsweise einen Zähler aktualisieren, stellen Sie sicher, dass Sie nur das Zählerelement aktualisieren, nicht den gesamten Komponentenbaum.

Befolgen Sie diese zwei goldenen Regeln für schnelleres Rendering:

1. Halten Sie das DOM klein und einfach. Es ist viel einfacher für einen Browser, eine Seite mit weniger DOM-Elementen (HTML-Knoten) zu rendern als eine Seite mit tief verschachtelten, komplizierten DOM-Strukturen. Streben Sie weniger als 1.400 DOM-Elemente insgesamt an und vermeiden Sie Verschachtelungen tiefer als 32 Ebenen.
2. Verwenden Sie content-visibility für Lazy-Rendering von Off-Screen-Inhalten. Die CSS-Eigenschaft content-visibility: auto beschleunigt das initiale Rendering, indem das Rendering von Off-Screen-Inhalten aufgeschoben wird, bis der Nutzer in deren Nähe scrollt.

/* Apply content-visibility to off-screen sections */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

INP debuggen mit der Long Animation Frames (LoAF) API

Die Long Animation Frames (LoAF) API ist ein leistungsstarkes Tool zur Diagnose von INP-Problemen. Sie liefert detaillierte Informationen über Frames, die länger als 50ms zum Rendern benötigen, einschließlich Script-Attribution-Daten, die Ihnen genau sagen, welche Skripte zu langsamen Interaktionen beitragen.

Im Gegensatz zur älteren Long Tasks API erfasst LoAF die Rendering-Zeit sowie die Script-Ausführungszeit, was sie besonders nützlich für die Diagnose von Darstellungsverzögerungsproblemen macht. LoAF-Einträge umfassen die Frame-Dauer, die Blockierungsdauer und ein Array von Script-Einträgen, die die Quell-URL, den Funktionsnamen und die Ausführungszeit jedes Skripts zeigen, das während des Frames ausgeführt wurde.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

RUM-Tools wie CoreDash integrieren LoAF-Daten automatisch und korrelieren lange Animationsframes mit bestimmten Benutzerinteraktionen, sodass Sie genau identifizieren können, welches Skript, auf welcher Seite, für welche Art von Interaktion Ihre schlechtesten INP-Werte verursacht.

INP und LCP: Die Long-Task-Verbindung

Lange Tasks auf dem Hauptthread beeinflussen sowohl INP als auch Largest Contentful Paint (LCP). Ein JavaScript-Task, der den Hauptthread für 200ms blockiert, verzögert die Event-Verarbeitung (verschlechtert INP) und hindert den Browser auch daran, das LCP-Element zu rendern (verschlechtert LCP). Wenn Sie Ihren Hauptthread optimieren, indem Sie lange Tasks aufteilen, nicht-kritisches JavaScript aufschieben und die Script-Ausführungszeit reduzieren, verbessern Sie beide Metriken gleichzeitig.

Fallstudien: INP-Verbesserungen in der Produktion

redBus: 80 bis 100% Verbesserung der mobilen Konversion

redBus, eine der weltweit größten Online-Busticket-Plattformen, investierte in die Core Web Vitals-Optimierung in ihren globalen Märkten. Ihr Fokus auf die Reduzierung der JavaScript-Ausführungszeit und die Optimierung von Event-Handlern trug zu einer 80 bis 100%igen Verbesserung der mobilen Konversionsraten in ihren globalen Märkten bei. Die Verbesserungen wurden durch eine Kombination aus der Reduzierung der Hauptthread-Blockierungszeit, der Optimierung des Ladens von Drittanbieter-Skripten und der Implementierung von Code Splitting erzielt, um die Menge an JavaScript zu reduzieren, die beim Seitenstart geparst wird.

Preply: INP von 250ms auf 185ms, geschätzte SEO-Einsparungen von 200.000 $ pro Jahr

Preply, eine Online-Sprachlernplattform, verbesserte ihr Homepage-INP von etwa 250ms auf 185ms und ihr Suchseiten-INP von etwa 250ms auf 175ms. Das Team erzielte diese Gewinne durch Profiling ihrer React-Anwendung, Identifizierung und Eliminierung unnötiger Re-Renders und Aufschieben nicht-kritischer Event-Callbacks. Die verbesserten Core Web Vitals-Werte korrelierten mit höheren Suchplatzierungen, was einem geschätzten Wert von 200.000 $ pro Jahr an organischem Suchwert entspricht.

Was reale Daten über INP zeigen

Der INP-Unterschied zwischen Mobil und Desktop

CoreDash-Daten zeigen, dass der mobile INP (131ms bei p75) 2,8-mal schlechter ist als der Desktop-INP (48ms bei p75). Dies ist der größte Geräteunterschied aller Core Web Vital-Metriken. Mobilgeräte haben langsamere Prozessoren, weniger Arbeitsspeicher und höhere Netzwerklatenz, was alles zu längeren Hauptthread-Blockierungszeiten und langsamerer Event-Verarbeitung beiträgt. Auf dem Desktop erreichen 95,6% der Interaktionen einen "guten" INP-Wert, während auf Mobilgeräten diese Zahl auf 88,0% sinkt. Mobile Nutzer erleben auch 5-mal mehr "schlechte" INP-Events (9,6% vs. 1,9%).

Tastatur- vs. Zeiger-Interaktionen

CoreDash-Daten zeigen, dass Tastaturinteraktionen (75ms p75) 56% langsamer sind als Zeiger-Interaktionen (49ms p75). Tastatur-Events haben auch deutlich mehr schlechte Erfahrungen: 7,4% der Tastaturinteraktionen führen zu einem schlechten INP, verglichen mit nur 1,4% bei Zeiger-Interaktionen. Dieser Unterschied liegt wahrscheinlich daran, dass Tastatur-Events, insbesondere in Formularfeldern, eine komplexere Verarbeitung auslösen, wie Eingabevalidierung, Autocomplete-Vorschläge und Statusaktualisierungen.

Interaktionen während des Ladens vs. nach dem Laden

Interaktionen, die während des Seitenladens stattfinden, haben einen dramatisch höheren INP als solche nach dem vollständigen Laden der Seite. CoreDash-Daten zeigen, dass Interaktionen während der "Ladephase" ein p75 INP von 132ms haben, verglichen mit nur 50ms für Interaktionen nach dem Laden. Das ist ein 2,6-facher Unterschied. Selbst Interaktionen während der "dom-content-loaded"-Phase (75ms) zeigen erhöhte INP-Werte, da asynchrone Skripte und Unterressourcen noch verarbeitet werden. Diese Daten unterstützen nachdrücklich die Empfehlung, nicht-kritisches JavaScript zu verzögern, um die Hauptthread-Konkurrenz beim Seitenstart zu reduzieren.

Globale INP-Bestehensquoten

Laut dem HTTP Archive Web Almanac 2025 erreichen 77% aller mobilen Seiten einen "guten" INP-Wert (gegenüber 55% im Jahr 2022). Allerdings bestehen nur 53% der 1.000 meistbesuchten Websites den INP-Test. Hochfrequentierte Websites haben tendenziell komplexeres JavaScript, mehr Drittanbieter-Skripte und kompliziertere DOM-Strukturen, was alles zu einer schlechteren Reaktionsfähigkeit beiträgt. Auf dem Desktop erreichen 97% der Seiten gute INP-Werte, was den enormen Leistungsunterschied zwischen Mobil und Desktop verdeutlicht. Die mittlere Total Blocking Time in Labortests beträgt 67ms auf dem Desktop, aber 1.209ms auf Mobilgeräten.

Häufig gestellte Fragen

Verwandte Leitfäden

Diese Übersichtsseite behandelt die Grundlagen von Interaction to Next Paint. Für vertiefte Anleitungen zu spezifischen Aspekten der INP-Optimierung erkunden Sie diese speziellen Artikel:

• <strong>INP-Probleme finden und beheben</strong>: Eine schrittweise Diagnosemethodik mit Search Console, RUM-Daten und Chrome DevTools, um genau zu identifizieren, welche Interaktionen Ihre schlechtesten INP-Werte verursachen.
• <strong>INP Input Delay</strong>: Behandelt die erste Phase von INP. Erfahren Sie, wie lange Tasks auf dem Hauptthread die Event-Verarbeitung blockieren und wie Sie den Input Delay mit Task-Scheduling, Code Splitting und Web Workers minimieren.
• <strong>INP Verarbeitungszeit</strong>: Behandelt die zweite Phase von INP. Erfahren Sie, wie Sie Event-Handler-Callbacks optimieren, kritischen Code priorisieren, nicht wesentliche Arbeit aufschieben und React-Concurrency-Features nutzen, um die Verarbeitungszeit zu reduzieren.
• <strong>INP Darstellungsverzögerung</strong>: Behandelt die dritte Phase von INP. Erfahren Sie, wie DOM-Größe, Layout Thrashing und clientseitiges Rendering zu langsamen visuellen Updates beitragen und wie Sie die Darstellungsverzögerung reduzieren.

Diese PageSpeed-Optimierungsleitfäden können ebenfalls bei der Verbesserung von INP hilfreich sein:

• INP verbessern: JavaScript-Scrollen abschaffen
• Async vs. Defer: JavaScript-Ladestrategien
• 14 Methoden zum Verzögern von JavaScript
• Chat-Widget mit perfekten Core Web Vitals
• Fix: Übermäßige DOM-Größe vermeiden