Langsame Interaktionen im Außendienst erkennen

Hier erfahren Sie, wie Sie langsame Interaktionen in den Felddaten Ihrer Website finden, um den Messwert „Interaction to Next Paint“ zu verbessern.

Jeremy Wagner

Felddaten sind Daten, die Aufschluss darüber geben, wie tatsächliche Nutzer Ihre Website erleben. So lassen sich Probleme erkennen, die in Labdaten allein nicht zu finden sind. In Bezug auf Interaction to Next Paint (INP) sind Felddaten unerlässlich, um langsame Interaktionen zu identifizieren, und liefern wichtige Hinweise, die Ihnen bei der Behebung helfen.

In diesem Leitfaden erfahren Sie, wie Sie den INP Ihrer Website mithilfe von Felddaten aus dem Chrome User Experience Report (CrUX) schnell bewerten können, um festzustellen, ob es Probleme mit dem INP gibt. Anschließend erfahren Sie, wie Sie den Attributions-Build der JavaScript-Bibliothek „web-vitals“ und die neuen Informationen aus der Long Animation Frames API (LoAF) verwenden, um Felddaten für langsame Interaktionen auf Ihrer Website zu erfassen und zu interpretieren.

Beginnen Sie mit CrUX, um den INP Ihrer Website zu bewerten

Wenn Sie keine Felddaten von den Nutzern Ihrer Website erheben, ist CrUX möglicherweise ein guter Ausgangspunkt. Im CrUX werden Felddaten von echten Chrome-Nutzern erfasst, die dem Senden von Telemetriedaten zugestimmt haben.

CrUX-Daten werden in verschiedenen Bereichen angezeigt. Es hängt davon ab, nach welchen Informationen Sie suchen. CrUX kann Daten zu INP und anderen Core Web Vitals für Folgendes bereitstellen:

• Einzelne Seiten und ganze Ursprünge mit PageSpeed Insights
• Seitentypen. Viele E-Commerce-Websites haben beispielsweise Produktdetailseiten und Produktlistenseiten. In der Search Console finden Sie CrUX-Daten für einzelne Seitentypen.

Als Ausgangspunkt können Sie die URL Ihrer Website in PageSpeed Insights eingeben. Nachdem Sie die URL eingegeben haben, werden Felddaten für mehrere Messwerte angezeigt, sofern verfügbar, einschließlich INP. Sie können auch die Schalter verwenden, um Ihre INP-Werte für Mobilgeräte und Computer zu prüfen.

Diese Daten sind nützlich, weil sie Ihnen zeigen, ob ein Problem vorliegt. CrUX kann Ihnen jedoch nicht sagen, was die Probleme verursacht. Es gibt viele RUM-Lösungen (Real User Monitoring), mit denen Sie eigene Felddaten von den Nutzern Ihrer Website erheben können, um diese Frage zu beantworten. Eine Möglichkeit besteht darin, diese Felddaten selbst mit der JavaScript-Bibliothek „web-vitals“ zu erheben.

Felddaten mit der JavaScript-Bibliothek web-vitals erfassen

Die web-vitals-JavaScript-Bibliothek ist ein Script, das Sie auf Ihrer Website laden können, um Felddaten von den Nutzern Ihrer Website zu erfassen. Damit können Sie eine Reihe von Messwerten erfassen, einschließlich INP in Browsern, die dies unterstützen.

Mit dem Standard-Build der web-vitals-Bibliothek können Sie grundlegende INP-Daten von Nutzern im Feld abrufen:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  console.log(name);    // 'INP'
  console.log(value);   // 512
  console.log(rating);  // 'poor'
});

Wenn Sie die Felddaten Ihrer Nutzer analysieren möchten, müssen Sie diese Daten an einen bestimmten Ort senden:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  // Prepare JSON to be sent for collection. Note that
  // you can add anything else you'd want to collect here:
  const body = JSON.stringify({name, value, rating});

  // Use `sendBeacon` to send data to an analytics endpoint.
  // For Google Analytics, see https://github.com/GoogleChrome/web-vitals#send-the-results-to-google-analytics.
  navigator.sendBeacon('/analytics', body);
});

Diese Daten allein sagen jedoch nicht viel mehr aus als CrUX. Hier kommt der Attributions-Build der web-vitals-Bibliothek ins Spiel.

Mehr Möglichkeiten mit dem Attributions-Build der web-vitals-Bibliothek

Der Attributions-Build der web-vitals-Bibliothek liefert zusätzliche Daten, die Sie von Nutzern im Feld erhalten können, um problematische Interaktionen, die sich auf den INP Ihrer Website auswirken, besser zu beheben. Auf diese Daten kann über das attribution-Objekt zugegriffen werden, das in der onINP()-Methode der Bibliothek angezeigt wird:

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

onINP(({name, value, rating, attribution}) => {
  console.log(name);         // 'INP'
  console.log(value);        // 56
  console.log(rating);       // 'good'
  console.log(attribution);  // Attribution data object
});

Zusätzlich zum INP der Seite selbst liefert der Attributions-Build viele Daten, mit denen Sie die Gründe für langsame Interaktionen besser nachvollziehen können. Dazu gehört auch, auf welchen Teil der Interaktion Sie sich konzentrieren sollten. So lassen sich wichtige Fragen beantworten, darunter:

• „Hat der Nutzer mit der Seite interagiert, während sie geladen wurde?“
• „Haben die Event-Handler der Interaktion lange ausgeführt?“
• „Wurde der Start des Ereignis-Handlers für die Interaktion verzögert? Wenn ja, was ist zu diesem Zeitpunkt sonst noch im Hauptthread passiert?“
• „Hat die Interaktion zu viel Rendering-Arbeit geführt, die das Rendern des nächsten Frames verzögert hat?“

In der folgenden Tabelle sind einige der grundlegenden Attributionsdaten aufgeführt, die Sie aus der Bibliothek abrufen können. Sie können Ihnen helfen, einige der Hauptursachen für langsame Interaktionen auf Ihrer Website zu ermitteln:

Ab Version 4 der web-vitals-Bibliothek können Sie noch tiefere Einblicke in problematische Interaktionen erhalten. Dazu stehen Ihnen die Daten aus den INP-Phasenaufschlüsselungen (Eingabeverzögerung, Verarbeitungsdauer und Präsentationsverzögerung) und die Long Animation Frames API (LoAF) zur Verfügung.

Die Long Animation Frames API (LoAF)

Das Debuggen von Interaktionen mithilfe von Felddaten ist eine anspruchsvolle Aufgabe. Mit Daten aus LoAF ist es jetzt jedoch möglich, bessere Einblicke in die Ursachen langsamer Interaktionen zu erhalten, da LoAF eine Reihe detaillierter Zeitangaben und anderer Daten bereitstellt, mit denen Sie die genauen Ursachen ermitteln können – und vor allem, wo sich die Ursache des Problems im Code Ihrer Website befindet.

Der Attributions-Build der web-vitals-Bibliothek stellt ein Array von LoAF-Einträgen unter dem Schlüssel longAnimationFrameEntries des attribution-Objekts bereit. In der folgenden Tabelle sind einige wichtige Daten aufgeführt, die Sie in jedem LoAF-Eintrag finden:

All diese Informationen können Ihnen viel darüber verraten, was eine Interaktion langsam macht. Das scripts-Array, das LoAF-Einträge anzeigen, sollte jedoch von besonderem Interesse sein:

Jeder Eintrag in diesem Array enthält die in dieser Tabelle gezeigten Daten, die Informationen über das Skript enthalten, das für die langsame Interaktion verantwortlich war, und wie es dafür verantwortlich war.

Häufige Ursachen für langsame Interaktionen messen und identifizieren

In diesem Leitfaden wird beschrieben, wie Sie mit LoAF-Daten aus der web-vitals-Bibliothek einige Ursachen für langsame Interaktionen ermitteln können.

Lange Verarbeitungsdauer

Die Verarbeitungsdauer einer Interaktion ist die Zeit, die die registrierten Event-Handler-Callbacks der Interaktion benötigen, um vollständig ausgeführt zu werden, sowie alles andere, was dazwischen passieren kann. Lange Verarbeitungsdauern werden von der web-vitals-Bibliothek angezeigt:

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

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5
});

Es ist naheliegend, zu denken, dass die Hauptursache für eine langsame Interaktion darin besteht, dass die Ausführung des Codes des Event-Handlers zu lange gedauert hat. Das ist aber nicht immer der Fall. Wenn Sie sich sicher sind, dass dies das Problem ist, können Sie sich die LoAF-Daten genauer ansehen:

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

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5

  // Get the longest script from LoAF covering `processingDuration`:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Get attribution for the long-running event handler:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

Wie Sie im vorherigen Code-Snippet sehen können, können Sie mit LoAF-Daten die genaue Ursache für eine Interaktion mit hohen Verarbeitungsdauerwerten ermitteln, darunter:

• Das Element und der registrierte Event-Listener.
• Die Skriptdatei und die Zeichenposition darin, die den Code des Ereignis-Handlers mit langer Ausführungszeit enthält.
• Der Name der Funktion.

Diese Art von Daten ist von unschätzbarem Wert. Sie müssen nicht mehr mühsam herausfinden, welche Interaktion oder welcher ihrer Event-Handler für die hohen Werte der Verarbeitungsdauer verantwortlich war. Da Drittanbieterskripts oft ihre eigenen Event-Handler registrieren können, können Sie außerdem feststellen, ob Ihr Code verantwortlich war oder nicht. Für den Code, den Sie selbst kontrollieren, sollten Sie sich mit der Optimierung von Long Tasks befassen.

Lange Eingabeverzögerungen

Lang laufende Event-Handler sind zwar häufig, es gibt aber auch andere Teile der Interaktion, die berücksichtigt werden müssen. Ein Teil tritt vor der Verarbeitungsdauer auf und wird als Eingabeverzögerung bezeichnet. Das ist die Zeitspanne zwischen dem Initiieren der Interaktion durch den Nutzer und dem Beginn der Ausführung der Event-Handler-Callbacks. Sie tritt auf, wenn der Hauptthread bereits eine andere Aufgabe verarbeitet. Der Attributions-Build der web-vitals-Bibliothek kann Ihnen die Länge der Eingabeverzögerung für eine Interaktion mitteilen:

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

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536
});

Wenn Sie feststellen, dass einige Interaktionen hohe Eingabeverzögerungen aufweisen, müssen Sie herausfinden, was zum Zeitpunkt der Interaktion auf der Seite passiert ist, was die lange Eingabeverzögerung verursacht hat. Das hängt oft davon ab, ob die Interaktion während des Ladens der Seite oder danach stattgefunden hat.

War es während des Seitenaufbaus?

Der Hauptthread ist oft am stärksten ausgelastet, wenn eine Seite geladen wird. In dieser Zeit werden alle möglichen Aufgaben in die Warteschlange gestellt und verarbeitet. Wenn der Nutzer versucht, mit der Seite zu interagieren, während all diese Aufgaben ausgeführt werden, kann sich die Interaktion verzögern. Auf Seiten, die viel JavaScript laden, können Skripts kompiliert und ausgewertet sowie Funktionen ausgeführt werden, die eine Seite für Nutzerinteraktionen vorbereiten. Diese Arbeit kann im Weg stehen, wenn der Nutzer während dieser Aktivität interagiert. Sie können herausfinden, ob das bei den Nutzern Ihrer Website der Fall ist:

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

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Invoker types can describe if script eval blocked the main thread:
    const {invokerType} = script;    // 'classic-script' | 'module-script'
    const {sourceLocation} = script; // 'https://example.com/app.js'
  }
});

Wenn Sie diese Daten im Feld aufzeichnen und hohe Eingabeverzögerungen und Aufrufertypen von 'classic-script' oder 'module-script' feststellen, kann man davon ausgehen, dass die Auswertung der Skripts auf Ihrer Website lange dauert und den Hauptthread so lange blockiert, dass Interaktionen verzögert werden. Sie können diese Blockierzeit reduzieren, indem Sie Ihre Skripts in kleinere Bundles aufteilen, die Ausführung von anfänglich nicht verwendetem Code auf einen späteren Zeitpunkt verschieben und Ihre Website auf nicht verwendeten Code prüfen, den Sie vollständig entfernen können.

War es nach dem Seitenaufbau?

Eingabeverzögerungen treten zwar häufig während des Ladens einer Seite auf, können aber auch nach dem Laden einer Seite auftreten, und zwar aus einem ganz anderen Grund. Häufige Ursachen für Eingabeverzögerungen nach dem Seitenaufbau sind Code, der aufgrund eines früheren setInterval-Aufrufs regelmäßig ausgeführt wird, oder Ereignis-Callbacks, die für eine frühere Ausführung in die Warteschlange gestellt wurden und noch verarbeitet werden.

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

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  if (script) {
    const {invokerType} = script;        // 'user-callback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

Wie bei der Fehlerbehebung bei hohen Verarbeitungsdauerwerten erhalten Sie auch bei hohen Eingabeverzögerungen aufgrund der oben genannten Ursachen detaillierte Daten zur Skriptzuordnung. Der Unterschied besteht jedoch darin, dass sich der Aufrufertyp je nach Art der Arbeit ändert, die die Interaktion verzögert hat:

• 'user-callback' gibt an, dass die blockierende Aufgabe von setInterval, setTimeout oder sogar requestAnimationFrame stammt.
• 'event-listener' gibt an, dass die blockierende Aufgabe aus einer früheren Eingabe stammt, die in die Warteschlange gestellt wurde und noch verarbeitet wird.
• 'resolve-promise' und 'reject-promise' bedeuten, dass die blockierende Aufgabe von einer asynchronen Arbeit stammt, die zuvor gestartet und zu einem Zeitpunkt aufgelöst oder abgelehnt wurde, als der Nutzer versucht hat, mit der Seite zu interagieren, wodurch die Interaktion verzögert wurde.

In jedem Fall geben Ihnen die Script-Attributionsdaten einen Anhaltspunkt dafür, wo Sie mit der Suche beginnen sollten und ob die Eingabeverzögerung auf Ihren eigenen Code oder auf den eines Drittanbieter-Scripts zurückzuführen ist.

Lange Verzögerungen bei der Präsentation

Die Darstellungsverzögerung ist der letzte Teil einer Interaktion. Sie beginnt, wenn die Event-Handler der Interaktion abgeschlossen sind, und endet, wenn der nächste Frame dargestellt wird. Sie treten auf, wenn die Arbeit in einem Event-Handler aufgrund einer Interaktion den visuellen Zustand der Benutzeroberfläche ändert. Wie bei Verarbeitungsdauern und Eingabeverzögerungen kann die web-vitals-Bibliothek Ihnen mitteilen, wie lang die Präsentationsverzögerung für eine Interaktion war:

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

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691
});

Wenn Sie diese Daten aufzeichnen und hohe Präsentationsverzögerungen für Interaktionen feststellen, die zum INP Ihrer Website beitragen, kann das verschiedene Ursachen haben. Hier sind einige mögliche Gründe:

Teure Stil- und Layoutarbeiten

Lange Verzögerungen bei der Darstellung können auf eine teure Stilneuberechnung und Layoutarbeit zurückzuführen sein, die aus verschiedenen Gründen erforderlich ist, z. B. aufgrund komplexer CSS-Selektoren und großer DOM-Größen. Sie können die Dauer dieser Arbeit mit den LoAF-Timings messen, die in der web-vitals-Bibliothek angezeigt werden:

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

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  // Get necessary timings:
  const {startTime} = loaf; // 2120.5
  const {duration} = loaf;  // 1002

  // Figure out the ending timestamp of the frame (approximate):
  const endTime = startTime + duration; // 3122.5

  // Get the start timestamp of the frame's style/layout work:
  const {styleAndLayoutStart} = loaf; // 3011.17692309

  // Calculate the total style/layout duration:
  const styleLayoutDuration = endTime - styleAndLayoutStart; // 111.32307691

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running style and layout operation:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

LoAF gibt nicht die Dauer der Stil- und Layoutarbeiten für einen Frame an, sondern den Zeitpunkt, an dem sie begonnen haben. Mit diesem Startzeitstempel können Sie andere Daten aus LoAF verwenden, um die genaue Dauer dieser Arbeit zu berechnen. Dazu bestimmen Sie die Endzeit des Frames und subtrahieren davon den Startzeitstempel der Stil- und Layoutarbeit.

requestAnimationFrame-Callbacks mit langer Ausführungszeit

Eine mögliche Ursache für lange Präsentationsverzögerungen ist, dass in einem requestAnimationFrame-Callback zu viel Arbeit erledigt wird. Der Inhalt dieses Callbacks wird ausgeführt, nachdem die Event-Handler ausgeführt wurden, aber unmittelbar vor der Neuberechnung des Stils und der Layoutarbeit.

Die Ausführung dieser Callbacks kann sehr lange dauern, wenn die darin ausgeführten Aufgaben komplex sind. Wenn Sie vermuten, dass hohe Werte für die Präsentationsverzögerung auf die Arbeit mit requestAnimationFrame zurückzuführen sind, können Sie diese Szenarien mithilfe von LoAF-Daten identifizieren, die von der web-vitals-Bibliothek bereitgestellt werden:

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 543.1999999880791

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  // Get the render start time and when style and layout began:
  const {renderStart} = loaf;         // 2489
  const {styleAndLayoutStart} = loaf; // 2989.5999999940395

  // Calculate the `requestAnimationFrame` callback's duration:
  const rafDuration = styleAndLayoutStart - renderStart; // 500.59999999403954

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running requestAnimationFrame callback:
    const {invokerType} = script;        // 'user-callback'
    const {invoker} = script;            // 'FrameRequestCallback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

Wenn Sie feststellen, dass ein erheblicher Teil der Präsentationsverzögerung auf einen requestAnimationFrame-Callback zurückzuführen ist, sollten Sie darauf achten, dass die in diesen Callbacks ausgeführten Aufgaben auf die Aktualisierung der Benutzeroberfläche beschränkt sind. Alle anderen Arbeiten, die nicht das DOM betreffen oder Stile aktualisieren, verzögern das Rendern des nächsten Frames unnötig. Seien Sie also vorsichtig.

Fazit

Felddaten sind die beste Informationsquelle, um zu verstehen, welche Interaktionen für tatsächliche Nutzer problematisch sind. Wenn Sie Tools zur Felddatenerhebung wie die JavaScript-Bibliothek „web-vitals“ (oder einen RUM-Anbieter) verwenden, können Sie sicherer sein, welche Interaktionen am problematischsten sind. Anschließend können Sie problematische Interaktionen im Labor reproduzieren und dann beheben.