Interaction to Next Paint - Verarbeitungszeit (Processing Time)

Interaction to Next Paint (INP) Probleme verursacht durch Verarbeitungszeit

In unserem vorherigen Artikel haben wir über den Interaction to Next Paint gesprochen und wie man Interaction to Next Paint Probleme identifiziert. Wenn Sie die Grundlagen nachlesen möchten, ist dies ein großartiger Ort, um zu beginnen!

In diesem Artikel werde ich mich auf 'Verarbeitungszeit' konzentrieren. Wie dies die Interaction To Next Paint Probleme beeinflusst und dann erklären, wie man die Verarbeitungszeit minimieren kann, um den Interaction to Next Paint zu verbessern!

Kurz gesagt: Der Interaction to Next Paint (INP) misst, wie lange es dauert, bis eine visuelle Änderung auf einer Seite zu sehen ist, nachdem ein Benutzer mit der Seite interagiert hat. Dieser INP kann in 3 Komponenten unterteilt werden: 'Input Delay', 'Processing Time' (Verarbeitungszeit) und 'Presentation Delay'. Verarbeitungszeit trägt erheblich zum gesamten INP bei und macht im Durchschnitt etwa 40% der Verzögerung aus.  Das bedeutet, dass die Optimierung Ihres JavaScript-Codes, insbesondere von Event-Handlern, einen signifikanten Einfluss auf den INP-Score Ihrer Website haben kann.

INP TIPP: Verarbeitungszeit kann optimiert werden, indem wichtiger Code, der dem Layout-Update vorausgeht, sofort ausgeführt wird und aller andere Code so geplant wird, dass er danach läuft.

Was ist Verarbeitungszeit?

Der Interaction to Newt Paint (INP) kann in 3 Unterteile zerlegt werden: 'Input Delay', 'Processing Time' und 'Presentation Delay'

Verarbeitungszeit bezieht sich auf die Zeit, die der Browser benötigt, um den zugehörigen Event-Callback zu verarbeiten, nachdem ein Benutzer mit einer Webseite interagiert hat (z. B. Klicken auf eine Schaltfläche oder Drücken einer Taste). Während es immer etwas Verarbeitungszeit gibt, treten INP-Probleme auf, wenn die Event-Callbacks zu viel Verarbeitungszeit beanspruchen.

Verarbeitungszeit und der INP

Verarbeitungszeit könnte 'das Ding' sein, wenn Sie an die Optimierung des Interaction To Next Paint denken. Es ist der 'Job, der erledigt werden muss', bevor das Layout vom Browser aktualisiert werden kann.

Viele Entwickler denken beim Verbessern des INP an die Optimierung der Callback-Funktion (Optimierung der Verarbeitungszeit) und sie haben Recht. Aber in Bezug auf die Wichtigkeit ist Verarbeitungszeit nicht einmal der wichtigste Teil, den es zu verbessern gilt, aber sie macht im Durchschnitt immer noch 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 Verarbeitungszeit 40% des Interaction to Next Paint aus. Und obwohl das viel ist, wird die Optimierung der Verarbeitungszeit allein höchstwahrscheinlich nicht ausreichen, um INP-Probleme zu beheben

Beispiel für Verarbeitungszeit: Wenn ein Benutzer mit einer Webseite interagiert, z. B. auf eine Schaltfläche klickt, wird die Zeit, die der mit diesem Klick verbundene Event-Handler benötigt, um seine Ausführung abzuschließen, als Verarbeitungszeit bezeichnet. Wenn ein Benutzer beispielsweise auf eine Schaltfläche klickt, um ein Formular abzusenden, würde der Code, der die Formulardaten validiert, sie an den Server sendet und die Antwort verarbeitet, zur Verarbeitungszeit beitragen. Je länger diese Operationen dauern, desto länger ist die Verarbeitungszeit und desto schlechter ist möglicherweise der INP-Score.

Was verursacht hohe Verarbeitungszeit?

Um INP-Probleme zu beheben, die durch hohe Verarbeitungszeit verursacht werden, müssen wir verstehen, was die mögliche Ursache für hohe Verarbeitungszeit sein kann.  Hohe Verarbeitungszeit, die Zeit, die Event-Callbacks benötigen, um vollständig ausgeführt zu werden, kann durch unnötigen Code, nicht optimierten Code, geclusterte Callbacks und Layout Thrashing verursacht werden. Lassen Sie uns diese 4 Bereiche genauer betrachten.

1. Unnötiger Code. Alter, ungenutzter Code oder Code ohne unmittelbare Relevanz für die Benutzerinteraktion kann die Ausführungszeit von Callbacks verlängern.
   
2. Nicht optimierter Code. Ineffizienter Code (meistens Schleifen oder ineffiziente DOM-Lookups) kann dazu führen, dass die Event-Callbacks langsamer laufen als nötig.
   
3. Geclusterte Callbacks: Mehrere Event-Callbacks, die kurz hintereinander geplant sind, erstellen eine Warteschlange. Wenn ein Callback, der durch die Benutzerinteraktion ausgelöst wird, in dieser Warteschlange stecken bleibt, erscheint die Antwort verzögert.
   
4. Layout Thrashing: Häufige DOM-Manipulationen, die Layout-Neuberechnungen auslösen, können den Browser belasten und zu Leistungsrückgängen führen.

Minimieren Sie die Verarbeitungszeit

Um die Verarbeitungszeit zu minimieren, müssen wir sicherstellen, dass der Code, der für das nachfolgende Layout-Update verantwortlich ist, so schnell wie möglich läuft. Wir können dies tun, indem wir vorhandenen Code optimieren (unnötigen Code entfernen und den aktuellen Code optimieren) und indem wir zwischen Code unterscheiden, der vor und nach dem Layout-Update laufen muss. Im Grunde muss Code, der für das Layout-Update kritisch ist, davor laufen und aller andere Code kann nach dem Layout-Update laufen.

1. Entfernen Sie ungenutzten Code.  Während das Entfernen von ungenutztem Code wie ein Kinderspiel erscheinen mag, gibt es auf den meisten Websites zumindest etwas alten ungenutzten Code, der einfach ausgeführt wird, ohne der Seite oder der UX wirklich etwas hinzuzufügen.  Das bedeutet, dass das erste, was zu tun ist, sicherzustellen, dass kein Code läuft, der nicht benötigt wird. Dies kann auf viele Arten geschehen. Zum Beispiel durch  einen Prozess namens Tree Shaking oder Code Splitting. Oder manuell, indem Sie Ihre Code Coverage in Chrome überprüfen und auch eine gute IDE verwenden, die auf ungenutzten Code hinweist. (Profi-Tipp: Werfen Sie auch einen kritischen Blick auf Ressourcen, die von Ihrem Tag Manager geladen werden)
2. Minimieren Sie die Callback-Ausführungszeit: Verwenden Sie einen JavaScript-Profiler, um Engpässe in Ihrem Code zu identifizieren und diese Bereiche für die Optimierung ins Visier zu nehmen. Ziehen Sie Techniken wie Memoization, Vorberechnung und Caching in Betracht, um redundante Berechnungen zu vermeiden. (Tipp: Sie können das Chrome Performance Panel verwenden, um Skripte mit langer Ausführungszeit zu finden!)
   
3. Priorisieren Sie kritischen Code und planen Sie anderen Code: Wenn der Callback-Code optimiert wurde, teilen Sie den Code in Code auf, der sofort laufen muss, und Code, der verzögert werden kann. Schauen Sie sich dieses Beispiel aus der Praxis an:
   
   In diesem Beispiel werden Google Tag Manager und Facebook Events Callback ausgeführt, bevor der (REACT) Code, der dem Layout-Update vorausging. Die Lösung wäre gewesen, die GTM-Callbacks zu planen, wenn der Browser inaktiv ist
4. Vermeiden Sie Layout Thrashing oder Reflow. Layout Thrashing geschieht, 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, was zu einer schnelleren Webseite führt.
   Zum Beispiel, in einer Schleife, die die Breite jedes Absatzes so einstellt, dass sie der Breite eines Elements entspricht, 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.

Priorisieren von kritischem Code

Das letzte Element 'Priorisieren Sie kritischen Code und planen Sie anderen Code' könnte für viele von Ihnen etwas abstrakt sein. Wir können kritischen Code priorisieren, indem wir requestIdleCallback() und nutzen und dem Hauptthread Vorrang geben.

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-Ereignisses.

/* 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 möchten. In diesem Fall können wir 'dem Hauptthread Vorrang geben', nachdem der wichtigste Code ausgeführt wurde, und dem Browser so einen Moment Zeit geben, um die Layout-Updates auszuführen. Hier ist ein Beispiel, wie man Aufgaben aufteilen kann, indem man dem Hauptthread Vorrang gibt

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 asap after the layout update
}

In Zukunft könnten wir viel mehr mit der window.scheduler machen, als nur dem Hauptthread Vorrang zu geben. . Wir könnten auch Aufgaben mit der Scheduler API priorisieren (siehe [url=https://caniuse.com/mdn-api_scheduler_posttask]Support Table[/url]).

Die Scheduler API bietet die postTask() Funktion für eine feinkörnigere Planung von Aufgaben durch das Setzen von Prioritäten, was dem Browser hilft, Arbeit zu priorisieren, so dass Aufgaben mit niedriger Priorität dem Hauptthread Vorrang geben. 

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

Durch die Priorisierung kritischer Aufgaben mit 'user-blocking' können Entwickler sicherstellen, dass sie mit höherer Priorität ausgeführt werden, was es dem Browser ermöglicht, Benutzerinteraktionen reaktionsschneller zu behandeln. Die Scheduler API bietet die postTask() Funktion für eine feinkörnigere Planung von Aufgaben durch das Setzen von Prioritäten, was dem Browser hilft, Arbeit zu priorisieren, so dass Aufgaben mit niedriger Priorität dem Hauptthread Vorrang geben. 

Praktische Auswirkungen

Lassen Sie uns zur wichtigsten Frage kommen: 'Was bedeutet das alles für meine Seite?'. Lassen Sie uns es aufschlüsseln für WordPress & REACT und sehen, wie Sie den Interaction to Next Paint verbessern können, wenn es um Verarbeitungszeit geht.

WordPress

WordPress bietet sehr wenig Kontrolle, wenn es um Skripte geht. 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-Seite Probleme mit dem Interaction to Next Paint hat, die durch lange Verarbeitungszeit verursacht werden, unternehmen Sie die folgenden Schritte:

• Überprüfen Sie die Theme-Einstellungen. Deaktivieren Sie alle unnötigen Optionen wie 'Smooth Scroll' oder 'animiertes Menü'. Einstellungen wie diese neigen dazu, INP-Probleme zu verursachen.
• Überprüfen Sie, welche Skripte für die lange Verarbeitungszeit 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 das Gleiche tut
• Oft laufen benutzerdefinierte Skripte auf der Seite. Überprüfen Sie diese Skripte und stellen Sie sicher, dass sie dem Hauptthread oft Vorrang geben und weniger wichtige Callbacks in eine requestIdleCallback-Funktion verpacken
• Entladen Sie ungenutzte Skripte auf Seitenbasis (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. Oft haben Mehrzweck-Themes, die 'alles tun', tendenziell mehr Skripte
• Vermeiden Sie Page Builder, da sie oft stark auf JavaScript angewiesen sind, um Seiten dem Endbenutzer zu präsentieren

REACT / NextJS

React Hooks und Funktionen machen es möglich, die INP-Verarbeitungszeit zu reduzieren:

Priorisieren Sie Benutzerinteraktion mit React Concurrency Features:

Reacts Concurrency Features, die in den Versionen 16 und 18 eingeführt wurden, bieten Hooks und Mechanismen zur Optimierung des Renderings für eine reibungslosere Benutzererfahrung, insbesondere während der Eingabe.

• useTransition & startTransition: Markieren Sie nicht-kritische Updates für späteres Rendering. Dies verhindert, dass große Updates die Benutzerinteraktion blockieren.
• useDeferredValue: Teilen Sie Ihre UI in wesentliche und weniger kritische Abschnitte auf. React kann das Rendern der weniger kritischen Teile unterbrechen, um eine reaktionsschnellere Erfahrung zu bieten.
• useOptimistic: Zeigen Sie einen temporären, optimistischen Zustand an, während asynchrone Operationen (wie Netzwerkanfragen) laufen. Dies hält die UI reaktionsfähig, auch während des Datenabrufs.

Suspense für Data Fetching (React 18+):

Suspense in React 18 kann verwendet werden, um INP (Interaction to Next Paint) zu verbessern, indem dem Browser ermöglicht wird, Benutzerinteraktionen zu priorisieren und das Rendering zu optimieren. Während React 16 Suspense für Code Splitting eingeführt hat, erweitert React 18 diese Funktionalität, um auch Data Fetching einzubeziehen.

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

Insgesamt arbeiten diese Funktionen zusammen, um sicherzustellen, dass React Benutzerinteraktionen priorisiert und das Blockieren der UI während Updates oder Datenabruf vermeidet.