Leistung vor Ort beheben

Hier erfahren Sie, wie Sie Ihre Leistungsdaten mit Informationen zur Fehlerbehebung verknüpfen, um Probleme mit echten Nutzern zu identifizieren und zu beheben.

Philip Walton

Google bietet zwei Kategorien von Tools zum Messen und Debuggen der Leistung:

• Lab-Tools: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 Chrome User Experience Report (CrUX), der auf aggregierten, echten Nutzerdaten aus Chrome basiert. Die von Tools wie PageSpeed Insights und der Search Console gemeldeten Felddaten stammen aus CrUX-Daten.

Feldtools bieten zwar genauere Daten – also Daten, die die tatsächliche Erfahrung der Nutzer wiedergeben – mit Lab-Tools lassen sich Probleme jedoch oft besser erkennen und beheben.

CrUX-Daten sind repräsentativer für die tatsächliche Leistung Ihrer Seite. Es ist jedoch unwahrscheinlich, dass Sie Ihre CrUX-Werte kennen, um herauszufinden, wie Sie die Leistung verbessern können.

Lighthouse hingegen identifiziert Probleme und macht konkrete Verbesserungsvorschläge. Lighthouse macht aber nur Vorschläge zu Leistungsproblemen, die beim Seitenaufbau gefunden werden. Probleme, die nur durch eine Nutzerinteraktion wie Scrollen oder Klicken auf Schaltflächen auf der Seite auftreten, werden nicht erkannt.

Das wirft eine wichtige Frage auf: Wie lassen sich Informationen zur Fehlerbehebung für Core Web Vitals oder andere Leistungsmesswerte von echten Nutzern vor Ort erfassen?

In diesem Beitrag wird ausführlich erläutert, mit welchen APIs Sie zusätzliche Debugging-Informationen für jeden der aktuellen Core Web Vitals-Messwerte erfassen können. Außerdem erhalten Sie Vorschläge, wie Sie diese Daten in Ihrem vorhandenen Analysetool erfassen können.

APIs für Attribution und Fehlerbehebung

Cumulative Layout Shift (CLS)

Von allen Core Web Vitals-Messwerten ist der CLS wahrscheinlich derjenige, bei dem die Erfassung von Informationen zur Fehlerbehebung am wichtigsten ist. Der CLS wird über die gesamte Lebensdauer der Seite gemessen. Die Art und Weise, wie ein Nutzer mit der Seite interagiert – wie weit er scrollt, was er klickt usw. – kann also einen erheblichen Einfluss darauf haben, ob es Layoutverschiebungen gibt und welche Elemente sich verschieben.

Betrachten Sie den folgenden Bericht von PageSpeed Insights:

PageSpeed Insights zeigt sowohl Feld- als auch Lab-Daten an, sofern verfügbar. Diese können voneinander abweichen.

Der Wert für den CLS aus dem Labor (Lighthouse) unterscheidet sich stark vom Wert aus dem Feld (CrUX-Daten). Das ist sinnvoll, wenn Sie in Betracht ziehen, dass die Seite möglicherweise viele interaktive Inhalte enthält, die beim Testen in Lighthouse nicht verwendet werden.

Aber auch wenn Sie wissen, dass sich die Nutzerinteraktion auf Felddaten auswirkt, müssen Sie wissen, welche Elemente auf der Seite sich verschieben, damit Sie beim 75.Perzentil einen Wert von 0,28 erhalten. Die Schnittstelle LayoutShiftAttribution macht das möglich.

Zuordnung von Layoutverschiebungen abrufen

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

Eine ausführliche Erläuterung dieser beiden Oberflächen finden Sie unter Layoutverschiebungen debuggen. Für die Zwecke dieses Beitrags ist es wichtig zu wissen, dass Sie als Entwickler alle Layoutverschiebungen auf der Seite sowie die Elemente beobachten können, die sich verschieben.

Im Folgenden finden Sie Beispielcode, der jeden Layout Shift sowie die verschobenen Elemente protokolliert:

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, für jeden einzelnen Layout Shift die Daten zu messen und an Ihr Analysetool zu senden. Wenn Sie jedoch alle Schichten überwachen, können Sie die schlimmsten Schichten im Blick behalten und einfach Informationen dazu melden.

Das Ziel besteht nicht darin, jeden einzelnen Layoutwechsel für jeden Nutzer zu identifizieren und zu beheben. Ziel ist es, die Verschiebungen zu ermitteln, die sich auf die größte Anzahl von Nutzern auswirken und so im 75. Perzentil am meisten zum CLS Ihrer Seite beitragen.

Außerdem müssen Sie nicht bei jeder Verschiebung das größte Quellelement berechnen, sondern nur dann, wenn Sie bereit sind, den CLS-Wert an Ihr Analysetool zu senden.

Der folgende Code verwendet eine Liste von layout-shift-Einträgen, die zum CLS beigetragen haben, und gibt das größte Quellelement 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 identifiziert haben, das zur größten Verschiebung beigetragen hat, können Sie es an Ihr Analysetool melden.

Das Element, das den größten Einfluss auf den CLS-Wert für eine bestimmte Seite hat, variiert wahrscheinlich von Nutzer zu Nutzer. Wenn Sie diese Elemente jedoch für alle Nutzer aggregieren, können Sie eine Liste mit sich bewegenden Elementen erstellen, die die meisten Nutzer betreffen.

Nachdem Sie die Grundursache der Verschiebungen für diese Elemente identifiziert und behoben haben, meldet Ihr Analytics-Code kleinere Verschiebungen als die „schlechtesten“ Verschiebungen für Ihre Seiten. Schließlich werden die gemeldeten Veränderungen so gering sein, dass Ihre Seiten deutlich innerhalb des Schwellenwerts für „gute“ Änderungen von 0,1 liegen.

Hier einige weitere Metadaten, die zusammen mit dem größten Verschiebungsquellelement nützlich sein können:

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

Largest Contentful Paint (LCP)

Für die Fehlerbehebung in diesem Feld benötigen Sie hauptsächlich Informationen dazu, welches Element das größte Element (das LCP-Kandidatenelement) für den jeweiligen Seitenaufbau war.

Es ist durchaus möglich, dass sich das LCP-Kandidatenelement von Nutzer zu Nutzer unterscheidet, sogar bei genau derselben Seite.

Dafür kann es verschiedene Gründe geben:

• Nutzergeräte haben unterschiedliche Bildschirmauflösungen, was zu unterschiedlichen Seitenlayouts und somit unterschiedlichen Elementen führt, die im Darstellungsbereich sichtbar sind.
• Nutzer laden nicht immer Seiten, die ganz nach oben gescrollt werden. Häufig enthalten Links Fragmentbezeichner oder sogar Textfragmente. Dadurch können deine Seiten an jeder Scrollposition auf der Seite geladen und angezeigt werden.
• Inhalte können für den aktuellen Nutzer personalisiert sein, sodass das LCP-Kandidatenelement von Nutzer zu Nutzer stark variieren kann.

Das bedeutet, dass Sie keine Annahmen darüber treffen können, welches Element oder welche Gruppe von Elementen das am häufigsten verwendete LCP-Kandidatenelement für eine bestimmte Seite ist. Sie müssen sie anhand des tatsächlichen Nutzerverhaltens messen.

Hinweis : Weitere Informationen zu diesen Unterschieden finden Sie unter Warum sich Lab- und Felddaten unterscheiden können (und was Sie dagegen tun können).

Element des LCP-Kandidaten identifizieren

Um das LCP-Kandidatenelement in JavaScript zu ermitteln, können Sie die Largest Contentful Paint API verwenden. Dies ist dieselbe API, mit der Sie den LCP-Zeitwert ermitteln.

Bei der Beobachtung von largest-contentful-paint-Einträgen können Sie das aktuelle LCP-Kandidatenelement ermitteln, indem Sie sich die Eigenschaft element des letzten Eintrags ansehen:

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});

Achtung : Wie in der Dokumentation zum LCP-Messwert erläutert, kann sich das LCP-Kandidatenelement während des Seitenaufbaus ändern. Daher ist mehr Arbeit erforderlich, um das „endgültige“ LCP-Kandidatenelement zu identifizieren. Die einfachste Möglichkeit, das „finale“ LCP-Kandidatenelement zu identifizieren und zu messen, ist die Verwendung der JavaScript-Bibliothek web-vitals, wie im Beispiel gezeigt.

Sobald Sie das Element des LCP-Kandidaten kennen, können Sie es zusammen mit dem Messwert an Ihr Analysetool senden. Wie bei CLS können Sie so herausfinden, welche Elemente am wichtigsten sind.

Neben dem LCP-Kandidatenelement kann es auch nützlich sein, die LCP-Teilzeiten zu messen. So lässt sich ermitteln, welche spezifischen Optimierungsschritte für Ihre Website relevant sind.

Interaktion mit nächstem Paint (INP)

Tipp : Weitere Informationen zum Debuggen von INP mit Felddaten finden Sie im Artikel Langsame Interaktionen finden.

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

1. Mit welchem Element interagiert wurde
2. Gründe für die Art der Interaktion
3. Wann diese Interaktion stattfand

Eine Hauptursache für langsame Interaktionen ist ein blockierter Hauptthread, der häufig auftreten kann, während JavaScript geladen wird. Wenn Sie wissen, ob die meisten langsamen Interaktionen beim Seitenaufbau auftreten, lässt sich das Problem leichter beheben.

Der INP-Messwert berücksichtigt die vollständige Latenz einer Interaktion, einschließlich der Zeit, die für die Ausführung registrierter Ereignis-Listener sowie die Zeit benötigt wird, um den nächsten Frame zu erfassen, nachdem alle Ereignis-Listener ausgeführt wurden. Für INP ist es also sehr nützlich zu wissen, welche Zielelemente 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);
}

Dieser Code zeigt nicht, wie ermittelt werden kann, welcher event-Eintrag der INP-Eintrag ist, da diese Logik komplexer ist. Im folgenden Abschnitt wird jedoch erläutert, wie Sie diese Informationen über die JavaScript-Bibliothek web-vitals abrufen.

Verwendung mit der JavaScript-Bibliothek von „Web Vitals“

In den vorherigen Abschnitten finden Sie einige allgemeine Vorschläge und Codebeispiele zum Erfassen von Informationen zur Fehlerbehebung, die in die Daten aufgenommen werden können, die Sie an Ihr Analysetool senden.

Seit Version 3 enthält die JavaScript-Bibliothek von web-vitals einen Attributions-Build, der all diese Informationen sowie einige zusätzliche Signale berücksichtigt.

Im folgenden Codebeispiel wird gezeigt, wie Sie einen zusätzlichen Ereignisparameter (oder eine benutzerdefinierte Dimension) mit einem Debug-String festlegen, mit dem sich die Ursache von Leistungsproblemen 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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Dieser Code gilt speziell für Google Analytics, aber die Grundidee sollte auch für andere Analysetools genutzt werden können.

Dieser Code zeigt auch nur, wie Berichte zu einem einzelnen Debug-Signal erstellt werden. Es ist aber hilfreich, wenn Sie mehrere verschiedene Signale pro Messwert erfassen und in Berichte aufnehmen können.

Zur Fehlerbehebung von INP können Sie beispielsweise das Element, mit dem interagiert wird, den Interaktionstyp, die Zeit, den Ladezustand (loadState), die Interaktionsphase (z. B. Long Animation Frame data) erfassen.

Mit dem Attributions-Build web-vitals werden zusätzliche Attributionsinformationen bereitgestellt, wie im folgenden Beispiel für INP gezeigt:

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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Eine vollständige Liste der bereitgestellten Fehlerbehebungssignale finden Sie in der Dokumentation zu Web Vitals-Attribution.

Berichte erstellen und Daten visualisieren

Nachdem Sie mit dem Erfassen von Debug-Informationen und Messwerten begonnen haben, besteht der nächste Schritt darin, die Daten für alle Nutzer zu aggregieren, um nach Mustern und Trends zu suchen.

Wie bereits erwähnt, müssen Sie nicht unbedingt jedes einzelne Problem beheben, auf das Ihre Nutzer stoßen. Besonders zuerst sollten Sie die Probleme beheben, die die größte Anzahl von Nutzern betreffen. Das sollten auch die Probleme sein, die sich am stärksten negativ auf Ihre Core Web Vitals-Werte auswirken.

Für GA4 finden Sie weitere Informationen im Artikel Daten mit BigQuery abfragen und visualisieren.

Zusammenfassung

Hoffentlich haben wir in diesem Beitrag die konkreten Möglichkeiten erläutert, wie Sie die vorhandenen Performance APIs und die web-vitals-Bibliothek verwenden können, um Informationen zur Fehlerbehebung zu erhalten und die Leistung anhand von tatsächlichen Nutzerbesuchen vor Ort zu analysieren. Der Schwerpunkt dieses Leitfadens liegt auf den Core Web Vitals. Die Konzepte gelten aber auch für die Fehlerbehebung bei Leistungsmesswerten, die in JavaScript gemessen werden können.

Wenn Sie gerade erst mit der Leistungsmessung beginnen und Google Analytics nutzen, ist das Tool „Web Vitals-Bericht“ möglicherweise ein guter Ausgangspunkt. Es unterstützt bereits die Berichterstellung für Informationen zur Fehlerbehebung für die Core Web Vitals-Messwerte.

Wenn Sie Anbieter von Analyselösungen sind und Ihre Produkte verbessern und Ihren Nutzern weitere Informationen zur Fehlerbehebung zur Verfügung stellen möchten, sollten Sie einige der hier beschriebenen Techniken in Betracht ziehen. Sie sollten sich jedoch nicht auf nur die hier vorgestellten Ideen beschränken. Dieser Beitrag soll allgemein auf alle Analysetools anwendbar sein. Mit einzelnen Analysetools können und sollten jedoch wahrscheinlich noch mehr Informationen zur Fehlerbehebung erfasst und gemeldet werden.

Wenn Sie der Meinung sind, dass Funktionen oder Informationen in den APIs fehlen, weil Funktionen oder Informationen fehlen, senden Sie Ihr Feedback an [e-mail].