Leistung vor Ort beheben

Informationen zur Zuordnung von Leistungsdaten mithilfe von Informationen zur Fehlerbehebung zur Identifizierung und Behebung echter Nutzerprobleme mit Analysen

Philip Walton

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

  • Lab-Tools:Mit Tools wie Lighthouse wird Ihre Seite in einem simulierte Umgebung, die verschiedene Bedingungen nachahmen kann (z. B. eine langsame und ein Low-End-Mobilgerät.
  • Feld-Tools:Tools wie Chrome User Experience Melden (CrUX), die auf aggregierten, echten Nutzerdaten aus Chrome basiert. (Beachten Sie, dass die Felddaten, die von Tools wie PageSpeed Statistiken und Suche Console stammt aus CrUX-Daten).

Feldtools liefern zwar präzisere Daten – Daten, die genau darstellen, echte User Experience: Mit Lab-Tools lassen sich Probleme häufig besser identifizieren und beheben. Probleme.

Daten zur Nutzererfahrung in Chrome sind repräsentativer für die tatsächliche Leistung Ihrer Seite. Es ist unwahrscheinlich, dass Ihre CrUX-Werte Ihnen helfen, herauszufinden, wie Sie Ihre Leistung verbessern können. die Leistung.

Lighthouse hingegen erkennt Probleme und stellt spezifische Verbesserungsvorschläge. Lighthouse macht jedoch nur Vorschläge, bei Leistungsproblemen, die bei der Seitenladezeit festgestellt werden. Es werden keine Probleme erkannt die sich nur bei einer Nutzerinteraktion wie Scrollen oder Klicken bemerkbar machen. auf der Seite.

Das wirft eine wichtige Frage auf: Wie können Sie Informationen zur Fehlerbehebung Core Web Vitals oder andere Leistungsmesswerte von echten Nutzern aus der Praxis?

In diesem Beitrag wird ausführlich erläutert, mit welchen APIs Sie zusätzliche Informationen zur Fehlerbehebung für alle aktuellen Core Web Vitals-Messwerte Ideen, wie Sie diese Daten in Ihrem vorhandenen Analysetool erfassen können.

APIs für Attribution und Fehlerbehebung

Cumulative Layout Shift (CLS)

Unter allen Core Web Vitals-Messwerten ist wohl der CLS derjenige, der möglicherweise Informationen zur Fehlerbehebung vor Ort zu sammeln. Der CLS wird gemessen, über die gesamte Lebensdauer der Seite hinweg, sodass die Art und Weise, wie Nutzende mit der z. B. wie weit sie scrollen, worauf sie klicken usw., ob es Layoutverschiebungen gibt und welche Elemente sich verschieben.

Betrachten Sie den folgenden Bericht von PageSpeed Insights:

<ph type="x-smartling-placeholder">
</ph> PageSpeed Insights-Bericht mit unterschiedlichen CLS-Werten
PageSpeed Insights zeigt sowohl Feld- als auch Lab-Daten an, sofern verfügbar. Diese können abweichen.

Der im Labor (Lighthouse) angegebene Wert für CLS im Vergleich zu den CLS aus dem (CrUX-Daten) sehr unterschiedlich sind. Dies ist sinnvoll, wenn Sie dass die Seite möglicherweise viele interaktive Inhalte enthält, die wird beim Testen in Lighthouse nicht verwendet.

Aber selbst wenn Sie verstehen, dass sich die Nutzerinteraktion auf Felddaten auswirkt, müssen wissen, welche Elemente auf der Seite sich verschieben, um einen Wert von 0,28 zu erzielen. beim 75. Perzentil. LayoutShiftAttribution ist dies möglich.

Zuordnung von Layoutverschiebungen abrufen

LayoutShiftAttribution wird bei jedem layout-shift-Eintrag offengelegt, bei dem Layout-Instabilität die API ausgibt.

Eine ausführliche Erläuterung dieser beiden Oberflächen finden Sie unter Layoutfehler beheben Schichten. Zum Zweck der Wichtig ist vor allem, dass Sie als Entwickler um alle Layoutänderungen auf der Seite zu beobachten und welche Elemente die sich im Lauf der Zeit ändern.

Im Folgenden finden Sie Beispielcode, der jeden Layout Shift sowie die Elemente die sich verändert:

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 zu messen und an Ihr Analysetool zu senden, bei jedem einzelnen Layout Shift Wenn Sie jedoch alle Schichten beobachten, die schlimmsten Schichten im Blick behalten und einfach Informationen darüber melden.

Das Ziel besteht nicht darin, jeden einzelnen Layout Shift für jeden Nutzer, Ziel ist es, die Veränderungen zu identifizieren, die die größte Anzahl Nutzer und tragen im 75. Perzentil am meisten zum CLS Ihrer Seite bei.

Außerdem müssen Sie nicht jedes Mal das größte Quellelement berechnen, wenn ein müssen Sie dies nur tun, wenn Sie bereit sind, den CLS-Wert an Ihre analysieren.

Im folgenden Code wird eine Liste von layout-shift-Einträgen übernommen, die einen Beitrag zur in CLS und gibt das größte Quellelement ab 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 dies an Ihr Analysetool melden.

Das Element, das am stärksten zum CLS beiträgt, variiert wahrscheinlich aber wenn Sie diese Elemente für alle Nutzenden zusammenfassen, eine Liste mit sich bewegenden Elementen erstellen, die die meisten Nutzenden betreffen.

Nachdem Sie die Grundursache der Verschiebungen für diese werden kleinere Verschiebungen in Ihrem Analysecode für Ihre Seiten. Schließlich werden alle gemeldeten Schichten klein genug sein, Ihre Seiten sich innerhalb der „guten“ Grenzwert von 0,1!

Einige weitere Metadaten, die in Verbindung mit der größten Verschiebung sinnvoll sein könnten Quellelement ist:

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

Largest Contentful Paint (LCP)

Um LCP-Fehler in diesem Feld zu beheben, benötigen Sie das größte Element (das LCP-Kandidatenelement) für die jeweilige Seitenaufbau.

Der LCP-Wert kann recht üblich sein. Kandidatenelement unterscheidet sich von Nutzer zu Nutzer, selbst bei exakt gleichen Seite.

Dafür kann es verschiedene Gründe geben:

  • Die Geräte der Nutzer haben unterschiedliche Bildschirmauflösungen, was zu unterschiedlichen Seitenlayouts und damit verschiedene Elemente innerhalb des Darstellungsbereichs sichtbar sind.
  • Nutzer laden nicht immer Seiten, die ganz nach oben gescrollt werden. Oftmals werden Links Fragmentbezeichner oder sogar Textfragmente. Es ist also möglich, dass Ihre Seiten an jeder Scrollposition auf der Seite geladen und angezeigt werden können.
  • Inhalte können für den aktuellen Nutzer personalisiert sein. Das LCP-Kandidatenelement kann je nach Nutzer stark variieren.

Das bedeutet, dass Sie keine Annahmen darüber treffen können, welches Element oder welche Gruppe von Elementen es ist. ist das gängigste LCP-Kandidatenelement für eine bestimmte Seite. Sie müssen und anhand des tatsächlichen Nutzungsverhaltens gemessen werden.

Element des LCP-Kandidaten identifizieren

Zur Bestimmung des LCP-Kandidatenelements in JavaScript können Sie die Größte Contentful Paint API, die die Sie auch zum Ermitteln des LCP-Zeitwerts verwenden.

Bei der Beobachtung von largest-contentful-paint-Einträgen können Sie die des aktuellen LCP-Kandidatenelements anhand der element-Eigenschaft des letzten Eintrags:

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-Kandidatenelement kennen, können Sie es an Ihr Analysetool senden. zusammen mit dem Messwert. Wie bei CLS können Sie so ermitteln, zuerst zu optimieren.

Neben dem LCP-Kandidatenelement kann es auch nützlich sein, LCP-Unterabschnittszeiten, die nützlich sein können um die für Ihre Website relevanten Optimierungsschritte zu ermitteln.

Interaktion mit nächstem Paint (INP)

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 beim Laden von JavaScript häufig vorkommen. Wenn Sie wissen, ob die meisten langsamen Interaktionen Seitenaufbau auftreten, ist hilfreich, wenn Sie herausfinden möchten, welche Maßnahmen das Problem zu lösen.

Der INP-Messwert berücksichtigt die gesamte Latenz eines Interaktion, einschließlich der Zeit, die für die Ausführung registrierter Ereignis-Listener als sowie die Zeit, die benötigt wird, um den nächsten Frame nach allen Ereignis-Listenern zu übertragen. ausgeführt wurden. Für INP ist es also sehr nützlich zu wissen, zu langsamen Interaktionen führen. dies sind.

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 ist. da diese Logik komplexer ist. Im folgenden Abschnitt wird jedoch erklärt, wie Sie diese Informationen mit der web-vitals-JavaScript-Bibliothek.

Verwendung mit der JavaScript-Bibliothek von „Web Vitals“

In den vorherigen Abschnitten finden Sie einige allgemeine Vorschläge und Codebeispiele, Debug-Informationen, die in die Daten aufgenommen werden, die du an dein Analysetool sendest.

Seit Version 3 sind die Web-Vitals Die JavaScript-Bibliothek enthält eine Quellenangabe erstellen, die alle diese Informationen und einige zusätzliche Informationen Signale an.

Das folgende Codebeispiel zeigt, wie Sie ein zusätzliches Ereignis Parameter (oder benutzerdefinierter Parameter) Dimension) mit einem Debug-String, der bei der Ermittlung der Ursache der Leistung hilfreich ist Probleme.

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 sich Analysetools anwenden.

Dieser Code zeigt auch, wie Berichte für ein einzelnes Debug-Signal erstellt werden, ist es nützlich, mehrere verschiedene Signale pro Messwert.

Zum Debuggen von INP sollten Sie beispielsweise das Element erfassen, interagiert mit, der Interaktionstyp, die Zeit, der Ladezustand, die Interaktion Phasen und mehr (wie Long Animation Frame data).

Die Attributions-Build web-vitals liefert zusätzliche Attributionsinformationen, 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);

Weitere Informationen finden Sie im Hilfeartikel Zuordnung von Web Vitals Dokumentation für die vollständige Liste der exponierten Fehlerbehebungssignale.

Berichte erstellen und Daten visualisieren

Sobald Sie mit dem Erfassen von Debug-Informationen und Messwerten begonnen haben, Aggregieren Sie als Nächstes die Daten all Ihrer Nutzenden, Muster und Trends.

Wie bereits erwähnt, müssen Sie nicht unbedingt jedes einzelne Problem beheben, sollten Sie – insbesondere zu Anfang – auf die Probleme eingehen, die die meisten Nutzer betreffen. Das sollte auch die Probleme sein, die sich am stärksten negativ auf Ihre Core Web Vitals-Werte auswirken.

Weitere Informationen zu GA4 finden Sie in diesem Hilfeartikel zum Abfragen und Visualisieren BigQuery

Zusammenfassung

Hoffentlich konnte ich Ihnen in diesem Beitrag erklären, wie Sie das vorhandene Performance APIs und die web-vitals-Bibliothek, um Informationen zur Fehlerbehebung zu erhalten , mit dem Sie die Leistung basierend auf den tatsächlichen Besuchen der Nutzer vor Ort analysieren können. Während dies auf die Core Web Vitals konzentriert, gelten die Konzepte auch für die Fehlerbehebung. Leistungskennzahlen, die in JavaScript messbar sind.

Wenn Sie gerade erst mit der Leistungsmessung beginnen und bereits Google Analytics-Nutzer ist das Tool „Web Vitals-Bericht“ ein guter Ausgangspunkt, da bereits Informationen zur Fehlerbehebung für das Core Web Vitalparameter

Wenn Sie Analyseanbieter sind und Ihre Produkte und mehr Debugging-Informationen zur Verfügung stellen, sollten Sie einige der den hier beschriebenen Techniken, aber beschränken Sie sich nicht auf nur die vorgestellten Ideen. hier. Dieser Beitrag ist allgemein für alle Analysetools anwendbar. Einzelne Analysetools können (und sollten) jedoch wahrscheinlich noch mehr Informationen zur Fehlerbehebung.

Wenn Sie der Meinung sind, dass diese Messwerte aufgrund von fehlende Funktionen oder Informationen in den APIs selbst senden Sie Ihr Feedback an web-vitals-feedback@googlegroups.com