INP Processing Time: Ursachen, Optimierung und Codebeispiele

Interaction to Next Paint (INP)-Probleme durch Processing Time

Diese Seite ist Teil unserer Interaction to Next Paint (INP)-Serie. INP misst die Gesamtzeit von einer Benutzerinteraktion bis zum nächsten visuellen Update. Processing Time ist die zweite von drei Phasen, die den INP ausmachen, nach der Input Delay und vor der Presentation Delay. Wenn Sie neu bei INP sind, lesen Sie zuerst unseren Leitfaden zum Identifizieren und Beheben von INP-Problemen.

Kurz gesagt: Der Interaction to Next Paint (INP) misst, wie lange es dauert, bis ein Benutzer nach einer Interaktion eine visuelle Änderung auf der Seite sieht. Dieser INP kann in 3 Komponenten unterteilt werden: "Input Delay", "Processing Time" und "Presentation Delay".

Processing Time ist ein wesentlicher Beitrag zum gesamten INP und macht durchschnittlich etwa 40 % der Verzögerung aus. Die Optimierung Ihrer Event Handler ist der direkteste Weg, die Processing Time zu reduzieren und Ihren INP-Wert zu verbessern.

INP-TIPP: Processing Time kann optimiert werden, indem wichtiger Code, der dem Layout-Update vorausgeht, sofort ausgeführt und aller andere Code für die Ausführung danach geplant wird.

Was ist Processing Time?

Der Interaction to Next Paint (INP) kann in 3 Teilbereiche unterteilt werden: "Input Delay", "Processing Time" und "Presentation Delay".

Processing Time bezeichnet die Zeit, die der Browser benötigt, um alle zugehörigen Event-Callbacks auszuführen, nachdem ein Benutzer mit einer Webseite interagiert hat (z. B. durch Klicken einer Schaltfläche oder Drücken einer Taste). Obwohl es immer eine gewisse Processing Time gibt, treten INP-Probleme auf, wenn die Event-Callbacks zu viel Processing Time beanspruchen.

Einfach ausgedrückt: Processing Time ist die Dauer der „Arbeit“, die als Reaktion auf Ihre Interaktion stattfindet. Wenn Sie auf eine Suchschaltfläche klicken, umfasst die Processing Time alles von der Validierung Ihrer Abfrage, der Vorbereitung des API-Requests, der Aktualisierung des lokalen Zustands, dem Auslösen von Analytics-Events und jedem anderen Code, der an dieses Click-Event angehängt ist. Jede Zeile JavaScript in diesen Event Handlern trägt zur Processing Time bei.

Processing Time und der INP

Processing Time ist möglicherweise das Erste, woran Sie denken, wenn es um die Optimierung des Interaction to Next Paint geht. Es ist die „Arbeit, die erledigt werden muss“, bevor das Layout vom Browser aktualisiert werden kann.

Viele Entwickler denken bei der Verbesserung des INP an die Optimierung von Callback-Funktionen (Optimierung der Processing Time), und sie haben recht. Aber in Bezug auf die Wichtigkeit ist Processing Time nicht einmal der wichtigste Teil zur Verbesserung. Sie macht im Durchschnitt dennoch etwa 40 % der gesamten INP-Zeit aus.

Bei CoreDash sammeln wir jede Stunde Millionen von Core Web Vitals-Datenpunkten. Basierend auf diesen Daten macht die Processing Time 40 % des Interaction to Next Paint aus. 40 % sind viel, aber die Optimierung der Processing Time allein wird INP-Probleme nicht beheben. Sie sollten auch Input Delay (18 %) und Presentation Delay (42 %) betrachten.

Processing Time-Beispiel: Wenn ein Benutzer auf eine Schaltfläche klickt, um ein Formular abzusenden, tragen der Code zur Validierung der Formulardaten, zum Senden an den Server und zur Verarbeitung der Antwort alle zur Processing Time bei. Je länger diese Operationen dauern, desto länger die Processing Time und potenziell desto schlechter der INP-Wert.

Was verursacht hohe Processing Time?

Hohe Processing Time hat vier häufige Ursachen: unnötiger Code, nicht optimierter Code, geclusterte Callbacks und Layout Thrashing.

1. Unnötiger Code. Alter, ungenutzter Code oder Code ohne unmittelbare Relevanz für die Benutzerinteraktion kann die Callback-Ausführungszeit verlängern. Dies umfasst Analytics-Aufrufe, Logging und Zustandssynchronisation, die nicht vor dem nächsten Paint abgeschlossen sein müssen.
   
2. Nicht optimierter Code. Ineffizienter Code (normalerweise Schleifen oder ineffiziente DOM-Abfragen) kann die Event-Callbacks langsamer als nötig ausführen. Ein häufiges Beispiel ist die DOM-Abfrage innerhalb einer Schleife mit document.querySelectorAll() anstatt das Ergebnis vor der Schleife zu cachen.
   
3. Geclusterte Callbacks. Mehrere Event-Callbacks, die zeitlich nah zusammen geplant sind, erzeugen eine Warteschlange. Wenn ein durch die Benutzerinteraktion ausgelöster Callback in dieser Warteschlange stecken bleibt, erscheint die Antwort verzögert. Zum Beispiel können ein pointerdown-Handler, ein mousedown-Handler und ein click-Handler alle sequenziell für einen einzelnen Klick ausgelöst werden.
   
4. Layout Thrashing. Häufige DOM-Manipulationen, die Layout-Neuberechnungen auslösen, können den Browser belasten und zu Performance-Regressionen führen. Dies passiert, wenn Ihr Code innerhalb einer Schleife zwischen dem Lesen und Schreiben von Layout-Eigenschaften wechselt, was den Browser zwingt, das Layout mehrfach neu zu berechnen.

Processing Time minimieren

Die Strategie ist zweifach: bestehenden Code optimieren (unnötigen Code entfernen und den aktuellen Code optimieren) und zwischen Code unterscheiden, der vor und nach dem Layout-Update ausgeführt werden muss. Code, der für das Layout-Update kritisch ist, muss zuerst ausgeführt werden, und aller andere Code kann nach dem Layout-Update ausgeführt werden.

1. Ungenutzten Code entfernen. Obwohl das Entfernen ungenutzten Codes selbstverständlich erscheinen mag, gibt es auf den meisten Websites zumindest etwas alten ungenutzten Code, der einfach ausgeführt wird, ohne wirklich etwas zur Seite oder zur UX beizutragen. Das Erste ist sicherzustellen, dass kein Code ausgeführt wird, der nicht benötigt wird. Dies kann durch Tree Shaking, Code Splitting, Überprüfung Ihrer Code Coverage in Chrome und durch die Verwendung einer guten IDE erreicht werden, die auf ungenutzten Code hinweist. (Profitipp: Werfen Sie auch einen kritischen Blick auf die von Ihrem Tag Manager geladenen Ressourcen.) Für weitere Strategien lesen Sie unseren Leitfaden zu 14 Methoden zum Verzögern von JavaScript.
2. Callback-Ausführungszeit minimieren. Verwenden Sie einen JavaScript-Profiler, um Engpässe in Ihrem Code zu identifizieren und diese Bereiche für die Optimierung ins Visier zu nehmen. Erwägen Sie Techniken wie Memoisierung, Vorberechnung und Caching, um redundante Berechnungen zu vermeiden. (Tipp: Sie können das Chrome Performance-Panel verwenden, um Skripte mit langer Ausführungszeit zu finden.)
   
3. Kritischen Code priorisieren und anderen Code planen. Wenn der Callback-Code optimiert wurde, teilen Sie den Code in Code auf, der sofort ausgeführt werden muss, und Code, der verzögert werden kann. Schauen Sie sich dieses Praxisbeispiel an:
   
   In diesem Beispiel werden Google Tag Manager- und Facebook-Event-Callbacks vor dem (React-)Code ausgeführt, der dem Layout-Update vorausgeht. Die Lösung ist, die GTM- und Facebook-Callbacks so zu planen, dass sie ausgeführt werden, wenn der Browser im Leerlauf ist.
4. Layout Thrashing oder Reflow vermeiden. Layout Thrashing tritt auf, wenn Stil-Updates und Stil-Lesevorgänge in einer Schleife gemischt werden, was den Browser veranlasst, das Layout zahlreiche Male neu zu berechnen. Um Layout Thrashing zu vermeiden, führen Sie alle Stiländerungen (die „Sets“) durch, bevor Sie Stilwerte anfordern (die „Gets“). Dieser Ansatz minimiert die Häufigkeit von Layout-Updates und führt zu einer schnelleren Seite. Zum Beispiel: In einer Schleife, die die Breite jedes Absatzes an die Breite eines Elements anpasst, lesen Sie die Breite des Elements einmal vor der Schleife und verwenden Sie diesen Wert, um die Breiten der Absätze innerhalb der Schleife zu aktualisieren.

Event Handler mit setTimeout(0) aufbrechen

Wenn Sie Code aus einem Event Handler nicht entfernen oder verzögern können, ist die nächstbeste Option, den Handler in kleinere Teile aufzubrechen. Das setTimeout(callback, 0)-Muster ermöglicht es Ihnen, Arbeit auf mehrere Tasks aufzuteilen, sodass der Browser die Möglichkeit hat, das Layout-Update dazwischen zu verarbeiten. Hier ist ein praktisches Beispiel:

// Before: one long event handler blocks the next paint
button.addEventListener('click', () => {
  updateUI();           // Critical: must run before paint
  validateForm();       // Important but can wait
  sendAnalytics();      // Non-critical
  syncLocalStorage();   // Non-critical
});

// After: break into critical and deferred work
button.addEventListener('click', () => {
  updateUI();  // Critical: runs immediately before paint

  setTimeout(() => {
    validateForm();
  }, 0);

  setTimeout(() => {
    sendAnalytics();
    syncLocalStorage();
  }, 0);
});

Der Nachteil von setTimeout(0) ist, dass es die Fortsetzung ans Ende der Task-Warteschlange stellt. Wenn bereits andere Tasks in der Warteschlange sind, wird der verzögerte Code möglicherweise nicht sofort ausgeführt. Für vorhersagbareres Verhalten verwenden Sie stattdessen scheduler.yield() (siehe den Abschnitt unten). Für Muster, die sich speziell auf JavaScript-Scroll-Handling beziehen, lesen Sie unseren speziellen Leitfaden.

requestAnimationFrame für visuelle Updates verwenden

Wenn Ihr Event Handler ein visuelles Update auslösen muss, stellt requestAnimationFrame() sicher, dass Ihr Code zum optimalen Zeitpunkt ausgeführt wird: direkt bevor der Browser seinen nächsten Repaint durchführt. Dies ist besonders nützlich, wenn Sie DOM-Lesevorgänge und -Schreibvorgänge bündeln müssen, um Layout Thrashing zu vermeiden.

// Use requestAnimationFrame to batch visual updates
button.addEventListener('click', () => {
  // Read layout properties first (outside rAF)
  const containerWidth = container.offsetWidth;

  requestAnimationFrame(() => {
    // Write layout properties inside rAF
    items.forEach(item => {
      item.style.width = containerWidth + 'px';
    });
  });

  // Schedule non-visual work for idle time
  requestIdleCallback(() => {
    trackButtonClick();
    updateSessionState();
  });
});

Dieses Muster trennt DOM-Lesevorgänge von DOM-Schreibvorgängen und verhindert erzwungenes synchrones Layout. Das visuelle Update wird zum idealen Zeitpunkt in der Rendering-Pipeline des Browsers ausgeführt, und nicht-visuelle Arbeit wird während der Leerlaufzeit ausgeführt.

Wie man kritischen Code priorisiert

„Kritischen Code priorisieren und anderen Code planen“ klingt abstrakt, daher hier wie es in der Praxis aussieht. Wir können kritischen Code priorisieren, indem wir requestIdleCallback() verwenden und dem Main Thread nachgeben.

Wir verwenden requestIdleCallback für weniger wichtige Aufgaben, die nicht sofort ausgeführt werden müssen. Hier ist ein Vorher-Nachher-Beispiel für die Planung eines GTM-Events:

/* before: immediately run code */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* after: run the same code during browser idle */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

Der Nachteil von requestIdleCallback ist, dass Code möglicherweise nicht so schnell ausgeführt wird, wie Sie es möchten. In diesem Fall können Sie nach dem wichtigsten Code „dem Main Thread nachgeben“, um dem Browser einen Moment für das Layout-Update zu geben. Hier ist ein Beispiel, wie man Tasks durch Nachgeben an den Main Thread aufbricht:

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

async function handleClick() {
  // Do the most important layout updates here
  await yieldToMain();
  // Do other tasks that need to run as soon as possible after the layout update
}

Feingranulare Planung mit scheduler.postTask()

Die scheduler.postTask()-Funktion bietet feingranulare Aufgabenplanung durch Setzen von Prioritäten, was dem Browser hilft, Arbeit zu priorisieren, sodass Aufgaben mit niedriger Priorität dem Main Thread nachgeben. Überprüfen Sie die Browser-Unterstützungstabelle, bevor Sie diese API in der Produktion verwenden.

Die postTask()-Funktion akzeptiert drei Prioritätseinstellungen: "background" für Aufgaben mit niedrigster Priorität, "user-visible" für Aufgaben mit mittlerer Priorität und "user-blocking" für kritische Aufgaben, die hohe Priorität erfordern.

Indem Sie jedem Arbeitsteil innerhalb Ihres Event Handlers die richtige Priorität zuweisen, können Sie sicherstellen, dass der Browser Benutzerinteraktionen reaktionsschnell verarbeitet und gleichzeitig alle notwendigen Aufgaben erledigt:

// Schedule critical UI work at high priority
scheduler.postTask(() => {
  updateCartBadge();
  showConfirmation();
}, { priority: 'user-blocking' });

// Schedule data sync at medium priority
scheduler.postTask(() => {
  syncCartWithServer();
}, { priority: 'user-visible' });

// Schedule analytics at low priority
scheduler.postTask(() => {
  gtag('event', 'add_to_cart', { item: productId });
  fbq('track', 'AddToCart');
}, { priority: 'background' });

Praktische Auswirkungen

So gehen Sie die Processing Time-Optimierung bei WordPress und React/Next.js an.

WordPress

WordPress bietet begrenzte Kontrolle über Third-Party-Skripte. Viele Skripte werden über Plugins hinzugefügt. Meistens fügen diese Skripte Event Listener zur Seite hinzu, die nichts anderes tun, als den Interaction to Next Paint (INP) zu verzögern. Wenn Ihre WordPress-Website INP-Probleme durch lange Processing Time hat, unternehmen Sie folgende Schritte:

• Überprüfen Sie die Theme-Einstellungen. Deaktivieren Sie unnötige Optionen wie „Smooth Scroll“ oder „Animiertes Menü“. Solche Einstellungen verursachen häufig INP-Probleme.
• Prüfen Sie, welche Skripte für die lange Processing Time verantwortlich sind (Tipp: Verwenden Sie das Chrome Performance-Panel). Wenn diese Skripte plugin-bezogen sind, erwägen Sie, ein anderes Plugin zu finden, das ungefähr dasselbe mit weniger JavaScript macht.
• Häufig laufen benutzerdefinierte Skripte auf der Seite. Überprüfen Sie diese Skripte und stellen Sie sicher, dass sie häufig dem Main Thread nachgeben und weniger wichtige Callbacks in eine requestIdleCallback-Funktion einwickeln.
• Entladen Sie ungenutzte Skripte seitenweise (Tipp: Verwenden Sie wp_deregister_script). Einige Plugins neigen dazu, Skripte auf jeder Seite einzufügen, auch wenn die Funktionalität nicht benötigt wird.
• Überprüfen Sie Ihren Tag Manager und entfernen Sie ungenutzte oder unnötige Tags.
• Verwenden Sie schlanke und saubere Themes. Mehrzweck-Themes, die „alles können“, haben tendenziell mehr Skripte und schwerere Event Handler.
• Vermeiden Sie Page Builder, da sie sich oft stark auf JavaScript verlassen, um Seiten dem Endbenutzer zu präsentieren.

React / Next.js

Reacts Hooks und Concurrency-Funktionen ermöglichen es, die INP Processing Time erheblich zu reduzieren. Hier sind die wichtigsten Techniken:

Benutzerinteraktion mit React Concurrency-Funktionen priorisieren:

React 18 führte Concurrency-Funktionen ein, die das Rendering für eine flüssigere Benutzererfahrung optimieren, insbesondere bei Eingaben.

• useTransition und startTransition: Markieren Sie nicht-kritische Updates für späteres Rendering. Dies verhindert, dass große Updates die Benutzerinteraktion blockieren. Wickeln Sie beispielsweise ein Update der Suchergebnisse in startTransition ein, damit das Tippen im Suchfeld reaktionsschnell bleibt.
• useDeferredValue: Teilen Sie Ihre UI in wesentliche und weniger kritische Bereiche auf. React kann das Rendering der weniger kritischen Teile unterbrechen, um eine reaktionsschnellere Erfahrung zu bieten. Dies ist ideal für das Rendering gefilterter Listen oder Suchergebnisse.
• useOptimistic (React 19+): Zeigen Sie einen temporären, optimistischen Zustand an, während asynchrone Operationen (wie Netzwerk-Requests) laufen. Dies hält die UI auch während des Datenladens reaktionsschnell.

Suspense für Datenabruf (React 18+)

Suspense in React 18 kann verwendet werden, um den INP zu verbessern, indem es dem Browser ermöglicht, Benutzerinteraktionen zu priorisieren und das Rendering zu optimieren. Während React 16 Suspense für Code Splitting einführte, erweitert React 18 diese Funktionalität um Datenabruf.

• Eine Fallback-Komponente, wie ein Ladeindikator, wird angezeigt, während Daten geladen werden.
• Sobald die Daten eintreffen, setzt React das Rendering der suspendierten Komponente fort.
• Suspense, kombiniert mit unterbrechbarem Rendering in Concurrent React, priorisiert Benutzerinteraktionen. Wenn ein Benutzer mit einer suspendierten Komponente interagiert, priorisiert React das Rendering dieser Komponente und erhält die Reaktionsfähigkeit.

Diese Funktionen helfen React, Benutzerinteraktionen gegenüber Hintergrund-Rendering-Arbeit zu priorisieren.

Die anderen INP-Phasen erkunden

Processing Time ist nur ein Teil des Interaction to Next Paint. Um Ihre INP-Werte vollständig zu optimieren, sollten Sie auch die anderen zwei Phasen behandeln:

• Input Delay: Minimieren Sie die Wartezeit, bevor Event Handler mit der Ausführung beginnen. Input Delay macht ungefähr 18 % der gesamten INP-Zeit aus.
• Presentation Delay: Reduzieren Sie die Rendering- und Painting-Arbeit, die ungefähr 42 % der gesamten INP-Zeit ausmacht.

Für einen vollständigen diagnostischen Workflow lesen Sie unseren Leitfaden zum Finden und Beheben von INP-Problemen und kehren Sie zur INP-Hub-Seite für den vollständigen Überblick zurück.