Interaction to Next Paint verbessern: Eingabe, Verarbeitung und Darstellung untersuchen

Verbessern Sie Interaction to Next Paint, indem Sie eine langsame Interaktion reproduzieren und prüfen, ob die Verzögerung vor ihren Handlern, in ihnen oder vor dem nächsten Bild entsteht. Entfernen Sie unnötige Arbeit, teilen Sie verbleibende Arbeit soweit fachlich möglich auf und reduzieren Sie aufwendiges Rendering. Bestätigen Sie das Ergebnis mit interaktiven Aufzeichnungen und Nutzermessungen, nicht allein mit einem besseren Ladewert.

INP gilt bei höchstens 200 Millisekunden am 75. Perzentil als gut. Der Wert beschreibt die Reaktionsfähigkeit während eines Besuchs. Die bestimmende Handlung kann lange nach dem scheinbaren Ladeende stattfinden. Ein Produktfilter oder Navigationsknopf kann trotz schnellen Ladens das Problem sein.

Verstehen Sie den Umfang der INP-Messung

INP bewertet relevante Klicks, Berührungen und Tastaturinteraktionen. Gemessen wird die Verzögerung bis zur nächsten Darstellung nach der zugehörigen Interaktionsarbeit. Das ist weder bloß die Handlerlaufzeit noch eine Stoppuhr für den gesamten Geschäftsprozess nach einem Klick.

Eine Suche kann beispielsweise sofort einen Ladezustand zeigen, während eine asynchrone Anfrage Ergebnisse abruft. Die schnelle Rückmeldung verbessert die Reaktionsfähigkeit, beschleunigt aber nicht das Netzwerk. Messen Sie auch den Aufgabenabschluss, wenn das Besucherziel von diesem späteren Ergebnis abhängt.

Die Kennzahl spiegelt im Allgemeinen die langsamste beobachtete Interaktion des Besuchs wider, mit Ausreißerbehandlung bei vielen Interaktionen. Besuche ohne relevante Interaktion erzeugen keinen INP-Wert. Ersetzen Sie fehlende Werte nicht durch null und werten Sie sie nicht als sofortige Reaktion.

INP ersetzte First Input Delay im März 2024 als Core Web Vital. FID erfasste nur die anfängliche Wartezeit der ersten relevanten Eingabe, nicht die vollständige Reaktion während des Besuchs. Ältere FID-Empfehlungen können deshalb spätere langsame Interaktionen oder teure Darstellung übersehen.

Der Core-Web-Vitals-Leitfaden für Einsteiger erklärt Grenzen und Perzentile im Zusammenhang. Trennen Sie diese Bevölkerungsergebnisse von einer einzelnen gezielt reproduzierten Interaktion in der Entwicklung.

Zerlegen Sie die Latenz in drei Phasen

Die Phasen führen zu unterschiedlichen Untersuchungen. Googles INP-Optimierungsleitfaden verbindet darüber die Kennzahl mit Hauptthreadarbeit.

Ein kurzer Handler kann langsam wirken, weil ein anderes Skript den Start blockiert. Er kann auch schnell enden und danach aufwendiges Layout auslösen. Wer nur eine Funktionslaufzeit liest, übersieht beide Fälle.

Beginnen Sie mit der längsten Phase im problematischen Trace. Prüfen Sie nach der Verbesserung erneut die gesamte Interaktion. Arbeit zwischen Phasen zu verschieben senkt nicht zwingend die Gesamtlatenz. Eine kleinere Aktualisierung kann dagegen mehrere Phasen gleichzeitig entlasten.

Zeichnen Sie einen repräsentativen Zustand auf

Verwenden Sie den Performance-Bereich von Chrome DevTools für die Handlung selbst. Starten Sie die Aufnahme, führen Sie die Interaktion aus und untersuchen Sie nach dem Stoppen die Zeitleiste. Berücksichtigen Sie den relevanten Zustand: offenes Menü, gefüllter Warenkorb, aufgeklappte Liste oder nach Scrollen hinzugekommener Inhalt.

Eine frisch geöffnete leere Seite reproduziert möglicherweise kein Problem, das erst nach mehreren Änderungen entsteht. Umgekehrt können fremde Browsererweiterungen Arbeit hinzufügen, die Ihre Besucher nicht erhalten. Kontrollieren Sie die Umgebung, ohne relevante Bestandteile des echten Ablaufs zu entfernen.

Testen Sie nach Möglichkeit auf repräsentativer Hardware. CPU-Drosselung kann Empfindlichkeit zeigen, bleibt aber eine Simulation und muss so dokumentiert werden. Beschreiben Sie eine lokale gedrosselte Aufzeichnung nicht als Messung eines bestimmten Smartphones, wenn Sie es nicht tatsächlich getestet haben.

Speichern Sie Interaktionsziel, Bedingungen und relevanten Aufrufstapel. Ein hilfreicher Fehlerbericht nennt das langsame Bedienelement und die Arbeit im betreffenden Intervall. Ein Bild eines roten Gesamtwerts zwingt andere zur Wiederholung der Untersuchung.

Ergänzen Sie Attribution hinter aggregierten Berichten

CrUX und Search Console erkennen Probleme auf Bevölkerungsebene, ohne den verursachenden Bestandteil oder Release zu benennen. Eigene Instrumentierung kann langsame Interaktionen mit Anwendungskontext verbinden, abhängig von Datenschutz und Browserunterstützung.

Dieses Diagnosemodul verwendet den Attribution-Build von web-vitals mit kompatiblem installiertem Paket. Es protokolliert Phasenzeiten, statt Interaktionsdetails an einen Server zu senden.

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.table({
    inp: value,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay
  });
});

Prüfen Sie die Attribution-API gegen Ihre installierte Version. Produktive Erfassung benötigt Aggregation, Dublettenbehandlung und Regeln für gespeicherten Kontext. Erfassen Sie keine eingegebenen Texte, Kontokennungen oder vollständigen URLs mit privaten Parametern, nur weil sie sich bequem anhängen lassen.

Behandeln Sie Attribution als Spur zur Reproduktion. Ihre Abdeckung kann von CrUX abweichen, und ein aggregierter Wert kann mehrere langsame Interaktionsarten verbergen. Gruppieren Sie sinnvoll nach Vorlage oder Komponente, statt für jede langsame Stichprobe dieselbe Ursache anzunehmen.

Entfernen Sie Arbeit vor dem Eingabestart

Der Hauptthread kann keinen Eingabehandler ausführen, während eine andere Aufgabe ihn belegt. Aufgaben über 50 Millisekunden gelten als lange Aufgaben. Auch kürzere können jedoch bei angesammelter Planung und Renderingarbeit Verzögerungen verursachen.

Prüfen Sie unmittelbar vor den Handlern liegende Arbeit. Typische Kandidaten sind Startcode, wiederholte Timer, Analysefunktionen, Hydration und externe Widgets. Das angeklickte Element kann unschuldig sein: Ein leichtes Menü reagiert langsam, wenn fremde Arbeit den Thread bereits monopolisiert.

Entfernen Sie ungenutzte Funktionen und doppelte Initialisierung vor aufwendiger Ablaufplanung. Codeaufteilung kann Laden und Auswerten unnötiger Routenfunktionen vermeiden. Ein verzögertes Skript läuft später, verliert aber seine Ausführungskosten nicht.

Prüfen Sie bei weiterhin notwendigem teurem Code kleinere Aufgaben oder Ausführung außerhalb des Hauptthreads. Der Leitfaden zur JavaScript-Ausführung behandelt diese Möglichkeiten. Entscheidend ist weniger Konkurrenz um echte Interaktionen, nicht nur rund um das Ladeereignis.

Geben Sie zwischen unabhängigen Arbeitsstücken die Kontrolle ab

Eine Funktion in kleinere Funktionen aufzuteilen erzeugt nicht automatisch kleinere Browseraufgaben. Direkte aufeinanderfolgende Aufrufe im selben Handler halten den Thread weiterhin bis zum Aufgabenende belegt.

scheduler.yield() setzt Arbeit in einer späteren Aufgabe fort. Wegen unterschiedlicher Browserunterstützung sind Funktionserkennung und Rückfalllösung sinnvoll. Ein Timer erzeugt ebenfalls eine neue Aufgabe, bietet aber nicht dieselbe Fortsetzungspriorität.

Dieses vollständige Browserbeispiel verarbeitet eine lokale Sammlung in beispielhaften Abschnitten. Die Abschnittsgröße demonstriert das Prinzip und ist kein universelles Leistungsbudget.

<button id="process" type="button">Process example data</button>
<p id="progress" role="status">Ready</p>
<script type="module">
  const button = document.querySelector('#process');
  const progress = document.querySelector('#progress');
  const values = Array.from({ length: 10000 }, (_, index) => index);

  async function yieldToBrowser() {
    if (globalThis.scheduler?.yield) {
      await globalThis.scheduler.yield();
    } else {
      await new Promise(resolve => setTimeout(resolve, 0));
    }
  }

  button.addEventListener('click', async () => {
    button.disabled = true;
    progress.textContent = 'Processing';
    try {
      let total = 0;
      for (let start = 0; start < values.length; start += 250) {
        await yieldToBrowser();
        const end = Math.min(start + 250, values.length);
        for (let index = start; index < end; index++) {
          total += values[index];
        }
      }
      progress.textContent = `Total: ${total}`;
    } finally {
      button.disabled = false;
    }
  });
</script>

Die Kontrollabgabe ermöglicht andere Browserarbeit. Sie verspricht nicht, dass ein bestimmtes Bild zu einem festgelegten Zeitpunkt erscheint. Messen Sie die tatsächliche Operation auf geeigneten Geräten und passen Sie den Arbeitsumfang je Abschnitt an.

Unterbrechen Sie keine Zustandsänderung, die atomar sein muss. Vor der Fortsetzung kann anderer Code laufen und gemeinsamen Zustand verändern. Bewahren Sie Korrektheit, unterstützen Sie nötigenfalls Abbruch und sichern Sie wiederholte Aktivierung ab. Eine schnellere Oberfläche, die eine Aktion doppelt ausführt, ist keine Verbesserung.

Verwenden Sie requestIdleCallback nur für wirklich optionale Hintergrundarbeit, mit Funktionserkennung und geeigneter Alternative. Der Callback kann bei ausgelastetem Browser warten. Er ersetzt deshalb weder sofortige Rückmeldung noch notwendige Abschlussarbeit. Ein Timeout begrenzt die Wartezeit, beschränkt die Ausführung dann aber nicht mehr auf Leerlauf.

Halten Sie die unmittelbare Reaktion klein und hilfreich

Prüfen Sie den Handler auf Arbeit, die vor sichtbarer Rückmeldung nicht notwendig ist. Einen Auswahlzustand zu ändern kann wesentlich sein. Einen fremden Bericht neu zu berechnen, ein verborgenes Widget zu laden oder nebensächliche Analysewerte zu senden möglicherweise nicht.

Ersetzen Sie echte Rückmeldung nicht durch einen irreführenden Erfolgszustand. Kann eine Operation scheitern, zeigen Sie laufende Verarbeitung statt behauptetem Abschluss. Erhalten Sie Fehlerbehandlung und zugängliche Ankündigungen für Tastatur- und Hilfstechnologienutzer.

Worker helfen bei geeigneten Berechnungen, etwa beim Einlesen oder Umformen großer Datensammlungen. Sie können das Seiten-DOM nicht direkt bearbeiten, und Kommunikation kostet Zeit. Kleine Operationen auszulagern kann nur Komplexität hinzufügen. Die richtige große Operation auszulagern kann den Thread für Eingabe und Rendering freihalten.

Prüfen Sie außerdem die Ausführungshäufigkeit. Doppelte Listener, wiederholte Frameworkeffekte und unnötige Zustandsweitergabe vervielfachen auch kleine Arbeit. Entfernen Sie Duplikate, statt sie hinter einer Verzögerung zu verstecken.

Bei wiederholten Eingaben wie Suchvorschlägen kann Debouncing Zwischenwerte einsparen. Halten Sie die Eingabe selbst reaktionsfähig, wählen Sie die Verzögerung passend zur Aufgabe und verwerfen oder stoppen Sie veraltete asynchrone Ergebnisse. Wenden Sie Debouncing nicht wahllos an und verzögern Sie sichtbare Bestätigung nicht mit beliebigen Timern.

Reduzieren Sie das Rendering nach dem Handler

Ändert eine Interaktion große Seitenteile, kann die Darstellung dominieren. Prüfen Sie Stilneuberechnung, Layout und Paint nach dem Handler. Eine kurze Funktion, die Tausende Knoten einfügt, kann umfangreiche Browserarbeit auslösen.

Aktualisieren Sie den kleinsten relevanten Bereich. Erwägen Sie Seitennavigation oder sorgfältig implementierte Virtualisierung für große Sammlungen, unter Erhalt von Navigation, Fokus und zugänglichen Inhalten. Ein kleineres Anfangs-DOM hilft nur, wenn die spätere Interaktion nicht denselben Engpass auf einmal wiederherstellt.

Vermeiden Sie ständiges Wechseln zwischen Layoutlesen und Schreiben in Schleifen. Ein Geometrielesen nach Stiländerungen kann synchrones Layout erzwingen. Bündeln Sie Messungen, wenden Sie danach Änderungen an und prüfen Sie den Rückgang erzwungener Layoutarbeit im Trace.

Verwenden Sie keine bestimmte DOM-Knotenzahl als universelle Bestehensgrenze. Komplexität, Stilabhängigkeiten und Aktualisierungsfläche beeinflussen die Kosten. Belegen Sie die durch die Interaktion verursachte Renderingarbeit, statt nur einen Zähler mit einer auswendig gelernten Zahl zu vergleichen.

Prüfen Sie Drittanbieter während derselben Handlung

Tagmanager, Chat, Experimente und Werbeskripte können rund um Interaktionen laufen, obwohl ihre Netzwerkanfragen längst abgeschlossen sind. Eine reine Netzwerkprüfung übersieht diese Ausführungskosten.

Blockieren Sie im kontrollierten Test vorübergehend eine verdächtige Ressource oder deaktivieren Sie eine konkrete Integration. Wiederholen Sie die Handlung. Prüfen Sie, ob die Seite noch funktioniert und die Änderung die Ursache isoliert. Eine fehlende Abhängigkeit, die die Funktion zerstört, kann einen irreführend schnellen Trace erzeugen.

Geben Sie jeder Integration einen Verantwortlichen und einen Grund, an dieser Stelle des Ablaufs zu laufen. Laden Sie optionale Einbettungen bei Bedarf, wenn das Nutzern hilft. Bedenken Sie, dass die erste Interaktion dann Initialisierung enthalten kann. Eine Fassade sollte nicht lediglich sämtliche Kosten auf den aktivierenden Klick verschieben.

Prüfen Sie mehr als eine günstige Aufzeichnung

Ein gewöhnlicher Lighthouse-Navigationslauf misst Laden und meldet TBT als Blockierungsindikator. Er erzeugt nicht die Besucherinteraktionen für Feld-INP. Rechnen Sie TBT nicht in INP um und betrachten Sie einen besseren Lighthouse-Wert nicht als Beweis für einen reparierten Filter.

Wiederholen Sie die wirkliche Interaktion unter vergleichbaren Bedingungen. Prüfen Sie Phasen, sichtbare Reaktion, Endergebnis und Fehlerzustände. Beobachten Sie nach Veröffentlichung Feldergebnisse nach relevanter Gerätekategorie und Vorlage.

Dokumentieren Sie Änderung und Prüfbedingungen mit der Performance-Checkliste. Die Core-Web-Vitals-Leitfäden helfen bei verbleibenden Lade- oder Stabilitätsproblemen. Bewahren Sie das Szenario als Regressionstest auf, damit spätere Skript- oder Layoutänderungen die Verzögerung nicht unbemerkt zurückbringen.