Finden und Beheben von Interaction to Next Paint (INP) Problemen: Eine Schritt-für-Schritt-Anleitung
Lernen Sie, wie Sie Interaction to Next Paint Probleme mithilfe von RUM-Daten, Chrome DevTools und der LoAF API identifizieren und beheben
Finden und Beheben von Interaction to Next Paint (INP) Problemen
Diese Seite ist Teil unserer Interaction to Next Paint (INP) Serie. INP misst die Reaktionsfähigkeit Ihrer Website, indem die Verzögerung zwischen einer Benutzerinteraktion und der nächsten visuellen Aktualisierung verfolgt wird. Ein guter INP-Wert liegt unter 200 Millisekunden, während Werte über 500 Millisekunden als schlecht bewertet werden. Wenn INP neu für Sie ist, beginnen Sie mit der INP-Hub-Seite für einen vollständigen Überblick.
In diesem Artikel gehen wir eine vollständige Methodik zur Identifizierung von Interaction to Next Paint Problemen durch und erklären dann, wie man sie behebt. Der Prozess umfasst die Bestätigung des Problems in der Google Search Console, die Diagnose der Ursachen mit Real User Monitoring (RUM) Daten, die lokale Reproduktion der Bedingungen und die Anwendung gezielter Korrekturen für jede INP-Phase.
INP TIPP: Meistens ist der INP viel schlechter
wenn ein Benutzer während der Startphase des Seitenladens mit der Seite interagiert. Deshalb ist es beim Debuggen des INP sinnvoll, alle Interaktionen sowie den Ladestatus der Seite zu protokollieren!
Table of Contents!
Step 1: Überprüfen Sie den INP in der Search Console
Der erste Schritt besteht darin zu bestätigen, dass Sie tatsächlich ein INP-Problem haben. Bevor Sie Codeänderungen vornehmen, überprüfen Sie das Problem in der Google Search Console, damit Sie auf der Grundlage echter Felddaten und nicht auf Annahmen arbeiten.
Melden Sie sich in Ihrer Google Search Console an. Klicken Sie im linken Menü auf Core Web Vitals und wählen Sie entweder Mobil oder Computer (Tipp: Meistens treten INP-Probleme zuerst auf Mobilgeräten auf, beginnen Sie also mit Mobil).
Hier sehen Sie einen Überblick über alle Probleme im Zusammenhang mit Core Web Vitals, die derzeit auf Ihrer Website bestehen. Wenn eines dieser Probleme INP-bezogen ist, haben Sie bestätigt, dass ein Problem vorliegt.
Step 2: Identifizieren Sie Interaction to Next Paint Probleme
Die Google Search Console gibt Ihnen außer URL-Gruppen keine Informationen, um herauszufinden, was die Probleme mit dem Interaction to Next Paint verursacht. Meistens gehen Entwickler also blind vor. Sie beginnen damit, ungenutztes JavaScript zu entfernen (immer eine gute Idee) und den Main Thread aufzubrechen (auch eine gute Idee), aber das behebt den INP fast nie vollständig.
Deshalb müssen wir bei der Verbesserung des INP genau wissen, was vor sich geht. Wir brauchen Antworten auf vier kritische Fragen:
Welche Elemente verursachen bei Interaktion einen schlechten INP-Wert?
Normalerweise wird ein schlechter INP-Wert nicht durch ein einzelnes Element verursacht, sondern durch eine Kombination von Problemen. Wir müssen
sie nacheinander angehen, beginnend mit den schlimmsten, und uns nach oben arbeiten.
Wann treten diese Interaktionen auf? Treten sie
während der Startphase des Seitenladens auf oder passieren sie auch, wenn die Hauptseite vollständig geladen ist?
Wo treten diese
Interaktionen auf? Passieren sie auf jeder Seite oder nur auf wenigen ausgewählten Seiten?
Wie können wir diese Interaktionen replizieren? Sie haben vielleicht schon bemerkt, dass es schwer ist, INP-Probleme zu replizieren. Deshalb müssen wir uns auf den Erfolg vorbereiten, indem wir die Geräteeigenschaften mit einem schlechten INP-Wert nachahmen.
RUM-Tracking einrichten
Um alle diese Fragen zu beantworten, müssen wir anfangen, echte Benutzer zu tracken und alle Probleme zu protokollieren, die mit dem Interaction to Next Paint auftreten könnten. Es gibt mehrere Möglichkeiten, RUM-Tracking zu aktivieren. Die erste besteht darin, die Web Vitals-Bibliothek zu nutzen und die Ergebnisse an Ihr eigenes Analytics-Backend zu senden. Der Vorteil dieser Methode ist, dass sie günstig und flexibel ist. Der Nachteil ist, dass es viel zusätzliche Arbeit bedeuten kann.
Eine gute Alternative zum Senden Ihrer Core Web Vitals-Daten an Ihr eigenes Backend ist die Verwendung eines der vielen verfügbaren RUM-Tools. Wir haben CoreDash genau für diese Anwendungsfälle entwickelt. CoreDash ist ein kostengünstiges, schnelles und effektives RUM-Tool, das die Arbeit erledigt. Natürlich gibt es viele RUM-Lösungen da draußen, die die Arbeit ebenfalls erledigen (allerdings zu einem höheren Preis).
Langsame Interaktionen pro Element finden, die einen hohen INP verursachen
Als Erstes müssen die langsamsten Interaktionen gefunden werden, die die schlechtesten INP-Werte verursachen. Listen Sie Ihre Seiten in CoreDash nach "INP metric by Elements" auf und Sie erhalten Ihre langsamsten Interaktionen. Klicken Sie auf die erste Zeile, um Ihre Metriken nach diesen Interaktionen zu filtern.
Herausfinden, wann schlechte INP-Interaktionen auftreten
Sortieren Sie als Nächstes die gefilterten URLs nach Ladestatus (Load State). Dies gibt Ihnen mehr Einblick in die Ursache des INP. In diesem Fall tritt der hohe INP auf, wenn der DOM-Inhalt geladen wurde. Das bedeutet, dass Skripte geparst wurden, aber asynchrone Skripte und die Unterressourcen der Seite noch nicht geladen wurden. In diesem Fall wird der INP durch frühe Klicks verursacht, wenn das Laden der Seite noch nicht vollständig abgeschlossen ist.
Fahren Sie fort, indem Sie auf den Ladestatus mit der höchsten Auswirkung klicken, um einen weiteren Filter zu erstellen.
URLs finden, die für hohe INP-Werte verantwortlich sind
Wenn wir schließlich nach den Elementen mit der langsamsten Interaktion und dem korrekten Ladestatus gefiltert haben, werfen wir einen Blick auf die URLs, bei denen der INP am schlechtesten ist. In diesem Fall passiert dies eindeutig auf einer bestimmten Gruppe von Seiten.
Geräteeigenschaften finden
Wenn wir langsame Interaktionen, Ladestatus und URLs identifiziert haben, die einen hohen Interaction to Next Paint verursachen, sehen wir uns an, welche Arten von Besuchern die schlechtesten INP-Werte verursachen. Wir würden uns Gerätespeicher, Bandbreite, Bildschirmgröße und andere Hardwareeigenschaften ansehen. Sobald wir diese Eigenschaften identifiziert haben, können wir dazu übergehen, das Problem zu replizieren und zu protokollieren.
Verwendung der Long Animation Frames (LoAF) API zur INP-Diagnose
Die Long Animation Frames API (LoAF) bietet granulare Attributionsdaten, mit denen Sie genau bestimmen können, welche Skripte und Funktionen für langsame Interaktionen verantwortlich sind. Im Gegensatz zur älteren Long Tasks API liefert LoAF Skript-URLs, Funktionsnamen und zeitliche Aufschlüsselungen pro Frame. Dies macht es zu einem unschätzbaren Werkzeug für das INP-Debugging, insbesondere in Kombination mit RUM-Daten von einem Tool wie CoreDash.
Verwenden Sie den folgenden Code, um LoAF-Einträge für Interaktionen zu sammeln, die einen Schwellenwert überschreiten. Dieser Observer erfasst die Skript-Attribution, Dauer und Blockierzeit für jeden Long Animation Frame:
// Beobachten von Long Animation Frames für die INP-Zuordnung
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Nur Frames protokollieren, die länger als 50ms sind
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Die LoAF API zeigt, welche Skripte zu jeder Phase des INP beitragen. Das scripts-Array nennt Ihnen die genaue Quelldatei und den Funktionsnamen, während renderStart und styleAndLayoutStart Ihnen helfen, Verarbeitungszeit von Präsentationsverzögerung zu trennen. Für eine tiefere Diskussion darüber, wie sich async vs defer JavaScript-Laden auf diese Zeiten auswirkt, lesen Sie unseren speziellen Leitfaden.
Step 3: Replizieren und Debuggen von Interaktionen, die einen hohen INP-Wert verursachen
Sobald wir alle benötigten Informationen haben, können wir beginnen, tief in die zugrunde liegenden Probleme des Interaction to Next Paint einzutauchen.
Bereiten Sie sich auf den Erfolg vor: Replizieren Sie die Umstände des INP-Fehlers
Als Nächstes sollten wir versuchen, den fehlerhaften INP nachzustellen. Wir tun dies, indem wir die Umstände nachahmen, unter denen der INP möglicherweise fehlschlägt.
Verwenden Sie das Chrome Performance Panel: Öffnen Sie die Chrome Developer Tools (Strg+Umschalt+I) und wählen Sie das Performance-Panel. In der oberen Leiste können Sie die CPU-Drosselung auswählen (drosseln Sie sie auf 4x Verlangsamung, um ein normales Mobilgerät zu emulieren), die Netzwerkdrosselung (wählen Sie die Voreinstellung "Fast 3G", um Ihr durchschnittliches Mobilgerät nachzuahmen) und setzen Sie die Hardware-Concurrency auf 4 oder 8, um Ihr durchschnittliches Mobilgerät nachzuahmen.
Um Chrome mit weniger verfügbarem Speicher zu laden (obwohl das Verringern der Netzwerk- und CPU-Einstellungen oft ausreicht), starten Sie Chrome in einem Docker-Container und weisen Sie weniger Speicher zu.
Laden Sie die Seite neu, interagieren Sie und überprüfen Sie den INP mit dem Core Web Vitals Visualizer
Der nächste Schritt, um die Ursache der schlechten INP-Werte zu finden, besteht darin, die Bedingungen zu simulieren und zu bestätigen, dass die INP-Werte tatsächlich so schlecht sind wie berichtet.
Laden Sie die Seite neu und klicken Sie auf das richtige Element zur richtigen Zeit
Debuggen Sie den INP mit einem Performance Trace
Dies ist der Moment, auf den Sie sich in den vorherigen Schritten vorbereitet haben. Es ist an der Zeit herauszufinden, warum eine bestimmte Interaktion den schlechten Interaction to Next Paint Wert verursacht.
Öffnen Sie die Chrome Developer Console (Strg+Umschalt+I), navigieren Sie zum Performance-Panel und klicken Sie diesmal auf das Symbol mit dem kreisförmigen Pfeil, um die Seite neu zu laden und die Aufzeichnung zu starten (oder verwenden Sie die Tastenkombination Strg+Umschalt+E). Während die Aufzeichnung läuft, interagieren Sie mit dem Element, das den schlechten INP verursacht. Stoppen Sie nach einigen Sekunden die Aufzeichnung und untersuchen Sie die Zeitleiste. Suchen Sie in der Spur "Interactions" nach dem Interaktionsereignis und untersuchen Sie dann die entsprechenden Aufgaben in der Spur "Main", um genau zu sehen, welcher Code während jeder Phase ausgeführt wird.
Lesen des Performance Traces
Im Chrome Performance-Panel erscheint die Interaktion als farbiger Balken in der Spur "Interactions". Klicken Sie darauf, um die gesamte INP-Dauer und ihre Aufschlüsselung zu sehen. Unten, in der Spur "Main", können Sie die einzelnen Aufgaben sehen, die während der Interaktion liefen. Achten Sie auf:
- Aufgaben vor dem Event-Handler: diese tragen zum Input Delay bei
- Der Event-Handler selbst: dies ist die Processing Time
- Rendering-Arbeit, nachdem der Handler fertig ist: dies ist der Presentation Delay
Vergleichen Sie diese Erkenntnisse mit Ihren LoAF-Daten, um zu bestätigen, dass die im Trace identifizierten Skripte mit den Attributionsdaten Ihres RUM-Tools übereinstimmen. Dies ist auch ein guter Moment, um zu prüfen, ob JavaScript-Scroll-Handler zu dem Problem beitragen.
Step 4: INP-Probleme beheben
Wir sind nun an einem Punkt, an dem wir wissen, welche Interaktion unseren schlechten INP verursacht, und wir haben genau analysiert, was während dieser langsamen Interaktion passiert. Das bedeutet, es ist an der Zeit, den Interaction to Next Paint zu reparieren. Der Interaction to Next Paint kann in 3 Phasen unterteilt werden: Input Delay, Processing Time und Presentation Delay.
Jede Phase des Interaction to Next Paint sollte unterschiedlich behandelt werden. Unten finden Sie eine Zusammenfassung der wirkungsvollsten Strategien für jede Phase. Für vollständige Optimierungsleitfäden folgen Sie den Links zu den entsprechenden Unterseiten.
Input Delay minimieren:
Input Delay ist die Zeit zwischen der Interaktion mit der Seite und dem Beginn der Ausführung des Event-Callbacks. Während es immer eine gewisse Eingabeverzögerung gibt (selbst Browser benötigen Zeit, um die Callbacks zu planen), gibt es einige Dinge zu beachten:
- Vermeiden Sie Long Tasks. Wann immer ein Task läuft, blockiert er den Main Thread und lässt die Event-Callbacks warten. Dies ist besonders wichtig bei der Optimierung früher Klicks (da die meisten Skripte zu diesem Zeitpunkt ausgeführt werden). Strategien zur Reduzierung von JavaScript-Blockaden finden Sie in unserem Leitfaden zu async vs defer JavaScript.
- Seien Sie vorsichtig beim Erstellen neuer Tasks. Zum Beispiel wiederkehrende Tasks via
setTimeout()oder Tasks, die wahrscheinlich vor dem INP-Ereignis auftreten, wie Callbacks beimmouseover-Event. - Messen und bewerten Sie frühe Interaktionen. Wenn ein interaktives Element früh angezeigt wird (zum Beispiel ein Website-Suche-Element) und von JavaScript gesteuert wird, das später geladen wird, löst keine Interaktion mit dem Element eine sofortige Layout-Aktualisierung aus. Priorisieren Sie entweder die Funktionalität oder blenden/deaktivieren Sie das Element, bevor es ordnungsgemäß funktioniert.
- Verwenden Sie Web Worker, um JavaScript abseits des Main Threads des Browsers auszuführen. Web Worker ermöglichen es Skripten, abseits des Main Threads zu laufen. Dies verhindert, dass der Main Thread blockiert und Probleme mit INP Input Delay verursacht.
- Laden Sie "Nice-to-have" Drittanbieter-Skripte während der Leerlaufzeit des Browsers. Einige Skripte sind kritischer als andere. Es ist sinnvoll, diese Skripte zu priorisieren und weniger wichtige Skripte während der Leerlaufzeit des Browsers zu laden. Zum Beispiel ein Chat-Skript. Siehe unseren Leitfaden zu 14 Methoden zum Deferring von JavaScript für praktische Techniken.
Processing Time minimieren
- Entfernen Sie unnötigen Code. Unnötiger Code ist entweder älterer Code, der noch läuft, oder neuer Code, der auf dieser spezifischen Seite nicht benötigt wird, aber dennoch CPU-Zeit beansprucht. Dies ist bei weitem der einfachste Weg, den INP sofort zu verbessern.
- Verschieben Sie Code, der nicht vor dem nächsten Paint ausgeführt werden muss. Teilen Sie Code in kritischen Code auf, der vor dem INP ausgeführt werden muss, und nicht-kritischen Code (zum Beispiel das Senden von Analytics), und planen Sie diesen nach dem Paint-Event mit der
requestIdleCallback()Methode. - Optimieren Sie Code, der vor dem Paint ausgeführt werden muss. Überprüfen Sie Ihren Code und schreiben Sie langsame oder ineffektive Teile neu.
- Geben Sie sofortiges Feedback. Bei komplizierten oder möglicherweise langsamen Tasks, geben Sie sofortiges Feedback, bevor der Hauptcode ausgeführt wird.
Presentation Delay minimieren
- Halten Sie das DOM klein und einfach. Es ist für einen Browser viel einfacher, eine Seite mit wenigen und einfachen, nicht verschachtelten DOM-Elementen (HTML-Nodes) zu rendern, als eine Seite mit vielen verschachtelten DOM-Nodes. Lesen Sie mehr über das Beheben übermäßiger DOM-Größe.
- Verwenden Sie content-visibility, um Off-Screen-Inhalte lazy zu rendern. Content-visibility beschleunigt das Rendern sichtbarer Teile der Seite, indem das Rendern von Off-Screen-Inhalten verzögert und diese Inhalte erst Just-in-Time gerendert werden.
Schnelle Lösung: Dem Main Thread Vorrang geben mit scheduler.yield()
Eine der effektivsten Techniken zur Verbesserung des INP über alle drei Phasen hinweg ist das Nachgeben (Yielding) an den Main Thread zwischen kritischer und nicht-kritischer Arbeit. Die scheduler.yield() API bietet hierfür einen sauberen Weg. Hier ist eine wiederverwendbare Hilfsfunktion mit einem Fallback für Browser, die die API noch nicht unterstützen:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Verwendung in einem Event-Handler
async function handleButtonClick() {
// Kritische Arbeit: UI aktualisieren
updateVisualFeedback();
// Nachgeben, um den Browser malen (paint) zu lassen
await yieldToMain();
// Nicht-kritische Arbeit: Analytics, Logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Tiefer Einblick in jede INP-Phase
Da Sie nun wissen, wie Sie INP-Probleme identifizieren und beheben, erkunden Sie jede Phase im Detail:
- <b>Input Delay</b>: Erfahren Sie, wie Sie die Zeit zwischen Benutzerinteraktion und Beginn der Ereignisverarbeitung minimieren. Input Delay macht etwa 18% der gesamten INP-Zeit aus.
- <b>Processing Time</b>: Optimieren Sie die Ausführung des Event-Handlers, die etwa 40% der gesamten INP-Zeit ausmacht.
- <b>Presentation Delay</b>: Reduzieren Sie die Rendering- und Painting-Arbeit, die etwa 42% der gesamten INP-Zeit ausmacht.
Für zusätzliche Strategien, die alle drei Phasen betreffen, lesen Sie unsere Leitfäden zur Verbesserung des INP durch Verzicht auf JavaScript-Scrolling und zur Wahl zwischen async vs defer für Ihr JavaScript.
I have done this before at your scale.
Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.
Discuss Your Situation
