Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Leistung vor Ort beheben

Hier erfahren Sie, wie Sie Ihren Leistungsdaten Debugging-Informationen hinzufügen, um Probleme mit echten Nutzern mithilfe von Analysen zu identifizieren und zu beheben.

Philip Walton

Google bietet zwei Kategorien von Tools zum Messen und Beheben von Leistungsproblemen:

Labortools:Tools wie Lighthouse, bei denen Ihre Seite in einer simulierten Umgebung geladen wird, die verschiedene Bedingungen nachahmen kann, z. B. ein langsames Netzwerk und ein Low-End-Mobilgerät.
Feldtools:Tools wie der Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX), der auf aggregierten Daten von echten Nutzern in Chrome basiert. Die von Tools wie PageSpeed Insights und der Search Console gemeldeten Felddaten stammen aus CrUX-Daten.

Feldtools liefern zwar genauere Daten, die tatsächlich das Nutzererlebnis widerspiegeln, aber mit Labortools lassen sich Probleme oft besser erkennen und beheben.

CrUX-Daten sind repräsentativer für die tatsächliche Leistung Ihrer Seite. Wenn Sie Ihre CrUX-Werte kennen, wissen Sie aber wahrscheinlich nicht, wie Sie die Leistung verbessern können.

Lighthouse hingegen identifiziert Probleme und macht konkrete Vorschläge zur Verbesserung. Lighthouse macht jedoch nur Vorschläge für Leistungsprobleme, die bei der Seitenladezeit erkannt werden. Es werden keine Probleme erkannt, die nur durch Nutzerinteraktionen wie Scrollen oder Klicken auf Schaltflächen auf der Seite auftreten.

Das wirft eine wichtige Frage auf: Wie können Sie Debugging-Informationen für Core Web Vitals oder andere Leistungsmesswerte von echten Nutzern erfassen?

In diesem Beitrag wird im Detail erläutert, welche APIs Sie verwenden können, um zusätzliche Debugging-Informationen für die einzelnen aktuellen Core Web Vitals-Messwerte zu erfassen. Außerdem erhalten Sie Ideen, wie Sie diese Daten in Ihrem vorhandenen Analysetool erfassen können.

APIs für Attribution und Debugging

Cumulative Layout Shift (CLS)

Von allen Core Web Vitals-Messwerten ist CLS vielleicht derjenige, für den das Erfassen von Debugging-Informationen im Feld am wichtigsten ist. CLS wird während der gesamten Lebensdauer der Seite gemessen. Die Art und Weise, wie ein Nutzer mit der Seite interagiert – wie weit er scrollt, worauf er klickt usw. – kann sich also erheblich darauf auswirken, ob es Layout Shifts gibt und welche Elemente verschoben werden.

Sehen Sie sich den folgenden Bericht aus PageSpeed Insights an:

Ein PageSpeed Insights-Bericht mit unterschiedlichen CLS-Werten — PageSpeed Insights zeigt sowohl Feld- als auch Labdaten an, sofern verfügbar. Diese können sich unterscheiden.

Der für CLS im Lab (Lighthouse) gemeldete Wert unterscheidet sich erheblich vom CLS im Feld (CrUX-Daten). Das ist nachvollziehbar, wenn man bedenkt, dass die Seite möglicherweise viele interaktive Inhalte enthält, die beim Testen in Lighthouse nicht verwendet werden.

Auch wenn Sie wissen, dass Nutzerinteraktionen sich auf die Felddaten auswirken, müssen Sie trotzdem wissen, welche Elemente auf der Seite sich verschieben, um einen Wert von 0,28 im 75.Perzentil zu erzielen. Die LayoutShiftAttribution-Schnittstelle macht das möglich.

Attribution von Layoutverschiebungen abrufen

Die Schnittstelle LayoutShiftAttribution wird für jeden layout-shift-Eintrag verfügbar gemacht, der von der Layout Instability API ausgegeben wird.

Eine detaillierte Beschreibung der beiden Oberflächen finden Sie unter Layoutverschiebungen debuggen. Für diesen Beitrag ist es vor allem wichtig zu wissen, dass Sie als Entwickler jeden Layoutwechsel auf der Seite sowie die Elemente, die sich verschieben, beobachten können.

Hier ist ein Beispielcode, mit dem jede Layoutverschiebung sowie die verschobenen Elemente protokolliert werden:

new PerformanceObserver((list) => {
  for (const {value, startTime, sources} of list.getEntries()) {
    // Log the shift amount and other entry info.
    console.log('Layout shift:', {value, startTime});
    if (sources) {
      for (const {node, curRect, prevRect} of sources) {
        // Log the elements that shifted.
        console.log('  Shift source:', node, {curRect, prevRect});
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

Es ist wahrscheinlich nicht praktikabel, Daten für jede einzelne Layoutverschiebung zu erfassen und an Ihr Analysetool zu senden. Wenn Sie jedoch alle Verschiebungen im Blick behalten, können Sie die schlimmsten Verschiebungen im Auge behalten und nur Informationen zu diesen melden.

Es geht nicht darum, jeden einzelnen Layoutwechsel zu identifizieren und zu beheben, der für jeden Nutzer auftritt. Ziel ist es, die Verschiebungen zu identifizieren, die die meisten Nutzer betreffen und somit am meisten zum CLS Ihrer Seite im 75. Perzentil beitragen.

Außerdem müssen Sie das größte Quellelement nicht jedes Mal berechnen, wenn es eine Verschiebung gibt. Das ist nur erforderlich, wenn Sie den CLS-Wert an Ihr Analysetool senden.

Der folgende Code nimmt eine Liste von layout-shift-Einträgen entgegen, die zu CLS beigetragen haben, und gibt das größte Quellelement aus der größten Verschiebung zurück:

function getCLSDebugTarget(entries) {
  const largestEntry = entries.reduce((a, b) => {
    return a && a.value > b.value ? a : b;
  });
  if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
    const largestSource = largestEntry.sources.reduce((a, b) => {
      return a.node && a.previousRect.width * a.previousRect.height >
          b.previousRect.width * b.previousRect.height ? a : b;
    });
    if (largestSource) {
      return largestSource.node;
    }
  }
}

Sobald Sie das größte Element ermittelt haben, das zum größten Shift beigetragen hat, können Sie es in Ihrem Analysetool melden.

Das Element, das am meisten zum CLS einer bestimmten Seite beiträgt, variiert wahrscheinlich von Nutzer zu Nutzer. Wenn Sie diese Elemente jedoch für alle Nutzer zusammenfassen, können Sie eine Liste der sich verschiebenden Elemente erstellen, die die meisten Nutzer betreffen.

Nachdem Sie die Ursache der Verschiebungen für diese Elemente ermittelt und behoben haben, werden in Ihrem Analysecode kleinere Verschiebungen als die „schlimmsten“ Verschiebungen für Ihre Seiten gemeldet. Schließlich sind alle gemeldeten Änderungen so gering, dass Ihre Seiten weit innerhalb des Grenzwerts von 0,1 für „Gut“ liegen.

Einige andere Metadaten, die zusammen mit dem Quellelement der größten Änderung erfasst werden können, sind:

Zeitpunkt der größten Änderung
Der URL-Pfad zum Zeitpunkt der größten Änderung (für Websites, die die URL dynamisch aktualisieren, z. B. Single-Page-Anwendungen).

Largest Contentful Paint (LCP)

Um den LCP in der Praxis zu debuggen, benötigen Sie in erster Linie Informationen dazu, welches Element bei diesem bestimmten Seitenaufruf das größte Element (das LCP-Kandidatelement) war.

Es ist durchaus möglich und sogar üblich, dass das LCP-Kandidatelement für verschiedene Nutzer unterschiedlich ist, selbst bei derselben Seite.

Dafür kann es verschiedene Gründe geben:

Die Geräte der Nutzer haben unterschiedliche Bildschirmauflösungen, was zu unterschiedlichen Seitenlayouts führt. Daher sind im Darstellungsbereich unterschiedliche Elemente sichtbar.
Nutzer laden Seiten nicht immer ganz oben. Häufig enthalten Links Fragment-IDs oder sogar Textfragmente. Das bedeutet, dass Ihre Seiten an jeder beliebigen Scrollposition geladen und angezeigt werden können.
Inhalte können für den aktuellen Nutzer personalisiert werden. Das LCP-Kandidatelement kann also von Nutzer zu Nutzer stark variieren.

Sie können also nicht davon ausgehen, welches Element oder welche Gruppe von Elementen das häufigste LCP-Kandidatelement für eine bestimmte Seite sein wird. Sie müssen sie anhand des Verhaltens echter Nutzer messen.

LCP-Kandidatelement identifizieren

Um das LCP-Kandidatelement in JavaScript zu ermitteln, können Sie die Largest Contentful Paint API verwenden, dieselbe API, die Sie zum Ermitteln des LCP-Zeitwerts verwenden.

Wenn Sie largest-contentful-paint-Einträge beobachten, können Sie das aktuelle LCP-Kandidatelement anhand des Attributs element des letzten Eintrags ermitteln:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});

Sobald Sie das LCP-Kandidatelement kennen, können Sie es zusammen mit dem Messwert an Ihr Analysetool senden. Wie beim CLS können Sie so herausfinden, welche Elemente Sie zuerst optimieren sollten.

Zusätzlich zum LCP-Kandidatelement kann es auch hilfreich sein, die LCP-Unterteilzeiten zu messen, um zu ermitteln, welche spezifischen Optimierungsschritte für Ihre Website relevant sind.

Interaction to Next Paint (INP)

Die wichtigsten Informationen, die im Feld für INP erfasst werden müssen, sind:

Mit welchem Element wurde interagiert?
Um welche Art von Interaktion es sich handelte
Wann diese Interaktion stattgefunden hat

Eine Hauptursache für langsame Interaktionen ist ein blockierter Hauptthread, was häufig beim Laden von JavaScript vorkommen kann. Wenn Sie wissen, ob die meisten langsamen Interaktionen während des Seitenaufbaus auftreten, können Sie besser entscheiden, was zur Behebung des Problems getan werden muss.

Beim INP-Messwert wird die gesamte Latenz einer Interaktion berücksichtigt, einschließlich der Zeit, die zum Ausführen aller registrierten Event-Listener benötigt wird, sowie der Zeit, die zum Rendern des nächsten Frames nach dem Ausführen aller Event-Listener erforderlich ist. Für INP ist es daher sehr nützlich zu wissen, welche Zielelemente tendenziell zu langsamen Interaktionen führen und um welche Arten von Interaktionen es sich dabei handelt.

Mit dem folgenden Code werden das Zielelement und die Zeit des INP-Eintrags protokolliert.

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);
  console.log('INP time:', inpEntry.startTime);
}

In diesem Code wird nicht gezeigt, wie der event-Eintrag für INP ermittelt wird, da diese Logik komplexer ist. Im folgenden Abschnitt wird jedoch beschrieben, wie Sie diese Informationen mit der JavaScript-Bibliothek web-vitals abrufen können.

Verwendung mit der JavaScript-Bibliothek „web-vitals“

In den vorherigen Abschnitten finden Sie einige allgemeine Vorschläge und Codebeispiele zum Erfassen von Debugging-Informationen, die in die Daten aufgenommen werden sollen, die Sie an Ihr Analysetool senden.

Seit Version 3 enthält die JavaScript-Bibliothek web-vitals einen Attributions-Build, der alle diese Informationen und einige zusätzliche Signale enthält.

Im folgenden Codebeispiel sehen Sie, wie Sie einen zusätzlichen Ereignisparameter (oder eine benutzerdefinierte Dimension) festlegen, der einen Debugging-String enthält, mit dem sich die Ursache von Leistungsproblemen leichter ermitteln lässt.

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'CLS':
      eventParams.debug_target = attribution.largestShiftTarget;
      break;
    case 'LCP':
      eventParams.debug_target = attribution.element;
      break;
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      break;
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Dieser Code ist spezifisch für Google Analytics, aber das allgemeine Konzept sollte sich auch auf andere Analysetools übertragen lassen.

Dieser Code zeigt auch nur, wie ein einzelnes Debug-Signal gemeldet wird. Es ist jedoch nützlich, mehrere verschiedene Signale pro Messwert zu erfassen und zu melden.

Wenn Sie beispielsweise INP debuggen möchten, sollten Sie das Element, mit dem interagiert wird, den Interaktionstyp, die Zeit, den Ladezustand, die Interaktionsphasen und weitere Daten (z. B. Daten zu Frames mit langen Animationen) erfassen.

Der web-vitals-Attributions-Build enthält zusätzliche Attributionsinformationen, wie im folgenden Beispiel für INP zu sehen ist:

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      eventParams.debug_type = attribution.interactionType;
      eventParams.debug_time = attribution.interactionTime;
      eventParams.debug_load_state = attribution.loadState;
      eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
      eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
      eventParams.debug_presentation_delay =  Math.round(attribution.presentationDelay);
      break;

    // Additional metric logic...
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Eine vollständige Liste der bereitgestellten Debug-Signale finden Sie in der Dokumentation zur Zuordnung von Web-Vitals.

Daten in Berichten darstellen und visualisieren

Nachdem Sie mit der Erfassung von Debugging-Informationen zusammen mit den Messwerten begonnen haben, müssen Sie die Daten für alle Nutzer aggregieren, um Muster und Trends zu erkennen.

Wie bereits erwähnt, müssen Sie nicht unbedingt jedes einzelne Problem beheben, das Ihre Nutzer haben. Konzentrieren Sie sich vor allem am Anfang auf die Probleme, die die meisten Nutzer betreffen und sich am stärksten negativ auf Ihre Core Web Vitals-Werte auswirken.

Für GA4 finden Sie einen speziellen Artikel dazu, wie Sie die Daten mit BigQuery abfragen und visualisieren.

Zusammenfassung

Wir hoffen, dass dieser Beitrag Ihnen geholfen hat, die spezifischen Möglichkeiten zu verstehen, wie Sie die vorhandenen Leistungs-APIs und die web-vitals-Bibliothek verwenden können, um Debugging-Informationen zu erhalten, mit denen Sie die Leistung basierend auf den Besuchen echter Nutzer im Feld diagnostizieren können. In diesem Leitfaden geht es zwar hauptsächlich um die Core Web Vitals, die Konzepte lassen sich aber auch auf das Debugging anderer Leistungsmesswerte anwenden, die in JavaScript gemessen werden können.

Wenn Sie ein Analytics-Anbieter sind und Ihre Produkte verbessern und Ihren Nutzern mehr Debugging-Informationen zur Verfügung stellen möchten, sollten Sie einige der hier beschriebenen Techniken in Betracht ziehen. Beschränken Sie sich jedoch nicht nur auf die hier vorgestellten Ideen. Dieser Beitrag soll allgemein für alle Analysetools gelten. Einzelne Analysetools können (und sollten) jedoch wahrscheinlich noch mehr Debugging-Informationen erfassen und melden.

Wenn Sie der Meinung sind, dass Sie diese Messwerte aufgrund fehlender Funktionen oder Informationen in den APIs selbst nicht richtig debuggen können, senden Sie Ihr Feedback an web-vitals-feedback@googlegroups.com.