Verbessere Interaction to Next Paint (INP)
Erfahren Sie mehr über Interaction to Next Paint (INP) und wie Sie ihn verbessern können

Was ist Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) ist eine relativ neue und spannende Metrik, die die Reaktionsfähigkeit einer Webseite während aller Interaktionen auf einer Seite misst. Ein niedriger Interaction to Next Paint stellt sicher, dass die Seite jederzeit zuverlässig reaktionsschnell ist. Der INP wird im März 2024 zu einem Core Web Vital, wenn Google die FID-Metrik durch die INP-Metrik ersetzt.
Table of Contents!
- Was ist Interaction to Next Paint (INP)?
- 98. Perzentil oder der schlechteste INP?
- Wie funktioniert Interaction to Next Paint (INP) genau?
- Was sind gute und schlechte Werte des Interaction to Next Paint (INP)?
- Wie misst man den Interaction to Next Paint (INP)?
- Wie verbessert man den Interaction to Next Paint?
- 1. Minimieren Sie die Input Delay - vermeiden Sie lange Aufgaben auf dem Main Thread
- 2. Minimieren Sie die Processing Time - geben Sie sofortiges Feedback, um sicherzustellen, dass die Seite direkt auf Benutzereingaben reagiert
- 3. Minimieren Sie die Presentation Delay - halten Sie die Dinge einfach!
Um die Interaction to Next Paint-Metrik zu berechnen, werden alle Differenzen zwischen jeder Benutzerinteraktion und der endgültigen Präsentationsänderung auf der Seite gespeichert. Die höchste Zahl aller Interaktionen (oder das 98. Perzentil) wird die endgültige Interaction to Next Paint (INP)-Metrik sein.
98. Perzentil oder der schlechteste INP?
INP ist eine Metrik, die darauf abzielt, die gesamte Interaktionslatenz einer Seite darzustellen, indem eine der längsten Interaktionen ausgewählt wird, die auftreten, wenn ein Benutzer eine Seite besucht. Bei Seiten mit weniger als 50 Interaktionen insgesamt ist INP die Interaktion mit der schlechtesten Latenz. Bei Seiten mit vielen Interaktionen ist INP meist das 98. Perzentil der Interaktionslatenz.
Wie funktioniert Interaction to Next Paint (INP) genau?
Eine Interaktion findet statt, wenn ein Besucher auf eine Seite klickt oder tippt. Diese Interaktion kann zu einer Änderung der Darstellung auf dem Bildschirm führen. Der Interaction to Next Paint (INP) misst die Zeit zwischen dem Klick und der Präsentation.
Die Latenz einer einzelnen Interaktion besteht aus der einzelnen längsten Dauer eines Ereignisses, das Teil der Interaktion ist, wobei die Dauer von dem Zeitpunkt gemessen wird, an dem der Benutzer mit der Seite interagiert hat, bis das nächste Frame präsentiert wird, nachdem alle zugehörigen Event-Handler ausgeführt wurden. Die Dauer ist die Summe der folgenden Zeitspannen:

Was sind gute und schlechte Werte des Interaction to Next Paint (INP)?
Um die Core Web Vitals für die Interaction to Next Paint-Metrik zu bestehen, sollte das 75. Perzentil der im Feld aufgezeichneten Seitenladevorgänge unter 200ms 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.

Wie misst man den Interaction to Next Paint (INP)?
Der Interaction to Next Paint kann nur mit Feld-Tools gemessen werden. Um den Interaction to Next Paint zu messen, benötigen wir echte Benutzerinteraktion. Google misst alle Interaktionen, die echte Chrome-Benutzer mit einer Seite haben, und speichert sie im CrUX-Datensatz. Der CrUX-Datensatz ist der offizielle Datensatz für die Core Web Vitals.
Erhalten Sie die offiziellen INP-Metriken
Sie können die offiziellen INP-Metriken in PageSpeed Insights oder im CrUX Dashboard und Google BigQuery erhalten. PageSpeed Insights gibt Ihnen den 75. Perzentil-Score für die letzten 28 Tage. Google BigQuery (über Data Studio) gibt Ihnen mehr historischen Kontext.
Verfolgen des Interaction to Next Paint mit Real User Monitoring
Während der offizielle CrUX-Datensatz die endgültige Quelle für Interaction to Next Paint-Metriken ist, ist der CrUX-Datensatz nicht wirklich nützlich, da er stark anonymisiert ist. Der CrUX-Datensatz bietet weder Echtzeitüberwachung noch erlaubt er viel Filterung. Deshalb verlassen sich Web Performance Consultants typischerweise auf Real User Monitoring.
Messen Sie den Interaction to Next Paint der aktuellen Sitzung.
Der einfachste Weg, den Interaction to Next Paint zu debuggen, ist durch Lighthouse im 'Timespan'-Modus. Sie könnten auch den Core Web Vitals Visualizer verwenden oder wenn Sie sich praktisch fühlen, mit der Google Web Vitals JavaScript Library
Protokollieren Sie den INP in der Konsole mit der Web Vitals JavaScript-Bibliothek
<script type="module">
import {onINP}
from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';
onINP(console.log);
</script>
Wie verbessert man den Interaction to Next Paint?
Der Interaction to Next Paint ist eine komplizierte Metrik. Ihre Seite kann größtenteils wirklich schnell sein und sofort reagieren. Leider, wenn nur eine Interaktion langsam ist, wirkt sich dies auf den gesamten Interaction to Next Paint aus.
Erinnern Sie sich nun daran, dass der INP in die Input Delay, Processing Time und die Presentation Delay unterteilt werden kann.
PageSpeed TIPP: Meistens wird der INP viel schlechter sein, wenn ein Benutzer während der Startphase des Seitenladens mit der Seite interagiert. Deshalb ist es beim Debuggen des INP sinnvoll, sowohl alle Interaktionen als auch den Ladezustand der Seite zu protokollieren!
1. Minimieren Sie die Input Delay - vermeiden Sie lange Aufgaben auf dem Main Thread
Normalerweise ist jede Seite während der Startphase der Seite weniger reaktionsschnell. Das ist der Zeitpunkt, an dem die meiste Arbeit auf dem Main Thread erledigt wird (Parsing, Dekodierung, Rendering und Scripting). Um den Main Thread so frei wie möglich zu halten, erwägen Sie:
- Entfernen Sie ungenutzten Code. Dies kann durch einen Prozess namens Tree Shaking (Entfernen von ungenutztem Code) und Code Splitting (Bündeln Ihres Codes so, dass er in viele kleine Bündel gruppiert ist, die bei Bedarf geladen werden können) erfolgen.
- Laden Sie nicht wesentlichen Code während der Browser-Leerlaufzeit. Benötigen Sie zum Beispiel wirklich ein Chat-Widget während der ersten 500ms des Seitenladens? Nein, wahrscheinlich nicht!
- Identifizieren Sie langsame Skripte, die viele Ressourcen benötigen, und schreiben Sie den Code neu, um ihn effizienter zu machen.
- Stellen Sie sicher, dass Ihre Seite 'leicht zu rendern' ist. Vermeiden Sie große DOM-Größen, zu viele oder riesige Bilder, zu viele Videos, CSS-Animationen usw.
2. Minimieren Sie die Processing Time - geben Sie sofortiges Feedback, um sicherzustellen, dass die Seite direkt auf Benutzereingaben reagiert
Wenn ein Besucher eine Aktion ausführt, wie das Senden eines Formulars oder das Hinzufügen eines Artikels zu einem Warenkorb, warten Sie nicht auf die serverseitige Bestätigung (Ihr Formular wurde gesendet, Ihre Artikel wurden zum Warenkorb hinzugefügt), sondern geben Sie sofortiges Feedback (wir senden Ihr Formular, fügen ArtikelX zum Warenkorb hinzu).
Geben Sie den Main Thread auch so schnell wie möglich frei (Yield). Da JavaScript dieses 'Run to Completion'-Ding macht, blockiert es den Main Thread, bis der gesamte Code ausgeführt wurde. Sie können manuell einen Haltepunkt erstellen, an dem der Browser das Layout aktualisieren kann (und dann den Rest des Codes fortsetzen kann), indem Sie 'an den Main Thread yielden'. Der einfachste Weg, dies zu tun, besteht darin, Teile des Codes in ein setTimeout() zu verpacken
const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");
formEl.addEventListener("submit", (evt) => {
evt.preventDefault();
formfeedbackEl.innerText = "Formular wird gesendet ... bitte warten";
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. Minimieren Sie die Presentation Delay - halten Sie die Dinge einfach!
1. Halten Sie das DOM klein und einfach. Im Grunde wird es für einen Browser viel einfacher sein, eine Seite mit weniger DOM-Elementen (HTML-Knoten) zu rendern, als für einen Browser, eine Seite mit vielen verschachtelten und komplizierten DOM-Knoten zu rendern.
2. Verwenden Sie Content-Visibility, um Off-Screen-Inhalte lazy zu rendern. Content-Visibility beschleunigt das Rendern von sichtbaren Teilen der Seite, indem das Rendern von Off-Screen-Inhalten verzögert wird, indem dieser Off-Screen-Inhalt Just-in-Time gerendert wird.
Your dev team is busy.
Delegate the performance architecture to a specialist. I handle the optimization track while your team ships the product.
- Parallel Workflows
- Specialized Expertise
- Faster Delivery

