Informationen zum Zuordnen von Leistungsdaten zu Debug-Informationen, um Probleme mit echten Nutzern mithilfe von Analysen zu erkennen und zu beheben
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. Hinweis: Die Felddaten, die von Tools wie PageSpeed Insights und der Search Console erfasst werden, stammen aus CrUX-Daten.
Während Tools für die Feldarbeit genauere Daten liefern, die tatsächlich die Erfahrung echter Nutzer widerspiegeln, können Sie mit Lab-Tools Probleme 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 Vorschläge zur Verbesserung. Lighthouse macht jedoch 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 derjenige, für den das Erfassen von Fehlerbehebungsinformationen vor Ort am wichtigsten ist. Die 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 einen erheblichen Einfluss darauf haben, ob es Layoutverschiebungen gibt und welche Elemente sich verschieben.
Sehen Sie sich den folgenden Bericht aus PageSpeed Insights an:
Der Wert für den CLS aus dem Labor (Lighthouse) unterscheidet sich stark vom Wert aus dem Feld (CrUX-Daten). Dies 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.
Auch wenn Sie wissen, dass sich Nutzerinteraktionen auf Felddaten auswirken, müssen Sie trotzdem wissen, welche Elemente auf der Seite sich verschieben, um eine Punktzahl von 0,28 im 75. Perzentil zu erhalten. Die LayoutShiftAttribution-Schnittstelle macht das möglich.
Zuordnung von Layoutverschiebungen abrufen
Die Schnittstelle LayoutShiftAttribution ist für jeden layout-shift
-Eintrag verfügbar, der von der Layout Instability API gesendet wird.
Eine ausführliche Erklärung dieser beiden Oberflächen finden Sie unter Layoutänderungen im Debug-Modus. 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.
Hier ist ein Beispielcode, der jede Layoutänderung sowie die entsprechenden 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 Layoutwechsel 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 zu diesen Änderungen 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 das größte Quellelement nicht jedes Mal berechnen, wenn sich etwas ändert. Sie müssen dies nur tun, wenn Sie den CLS-Wert an Ihr Analysetool senden möchten.
Der folgende Code nimmt eine Liste von layout-shift
-Einträgen an, die zur CLS beigetragen haben, und gibt das größte Quellelement mit der größten Änderung 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 Ursache für die Abweichungen dieser Elemente ermittelt und behoben haben, werden in Ihrem Analytics-Code kleinere Abweichungen als die „schlimmsten“ Abweichungen für Ihre Seiten erfasst. Am Ende werden die gemeldeten Veränderungen so gering sein, dass Ihre Seiten deutlich innerhalb des Schwellenwerts für „Gut“ von 0,1 liegen.
Weitere Metadaten, die Sie zusammen mit dem Element für die größte Veränderung erfassen können:
- Die Zeit der größten Abweichung
- Der URL-Pfad zum Zeitpunkt der größten Änderung (für Websites, auf denen die URL dynamisch aktualisiert wird, z. B. Single-Page-Anwendungen).
Largest Contentful Paint (LCP)
Um den LCP vor Ort zu debuggen, benötigen Sie in erster Linie Informationen dazu, welches Element bei diesem Seitenladevorgang das größte Element (das LCP-Kandidatenelement) war.
Es ist durchaus möglich, dass sich das LCP-Kandidatenelement von Nutzer zu Nutzer unterscheidet, auch bei genau derselben Seite.
Dafür kann es verschiedene Gründe geben:
- Die Geräte der Nutzer haben unterschiedliche Bildschirmauflösungen, was zu unterschiedlichen Seitenlayouts und damit zu unterschiedlichen Elementen im Darstellungsbereich führt.
- 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 werden. Daher kann das LCP-Kandidatenelement von Nutzer zu Nutzer stark variieren.
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.
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.
Wenn Sie largest-contentful-paint
-Einträge beobachten, können Sie das aktuelle LCP-Kandidatenelement anhand der element
-Eigenschaft 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 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.
Zusätzlich zum LCP-Kandidatenelement kann es auch hilfreich sein, die LCP-Teilzeiträume zu messen. So können Sie besser nachvollziehen, welche 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 interagiert wurde
- Gründe für die Art der Interaktion
- Wann diese Interaktion stattgefunden hat
Eine Hauptursache für langsame Interaktionen ist ein blockierter Hauptthread, was beim Laden von JavaScript häufig vorkommt. Wenn Sie wissen, ob die meisten langsamen Interaktionen beim Seitenaufbau auftreten, lässt sich das Problem leichter beheben.
Der INP-Messwert berücksichtigt die gesamte Latenz einer Interaktion, einschließlich der Zeit, die für die Ausführung aller registrierten Ereignis-Listener und für das Zeichnen des nächsten Frames nach Ausführung aller Ereignis-Listener erforderlich ist. 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.
Der folgende Code protokolliert Zielelement und Zeit des INP-Eintrags.
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 ermittelt wird, welcher event
-Eintrag der INP-Eintrag ist, da diese Logik etwas komplizierter ist. Im folgenden Abschnitt wird jedoch erläutert, wie Sie diese Informationen mit der JavaScript-Bibliothek web-vitals abrufen.
Verwendung mit der JavaScript-Bibliothek für 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, 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);
onINP(sendToGoogleAnalytics);
Dieser Code ist spezifisch für Google Analytics, aber die allgemeine Idee sollte auch auf andere Analysetools übertragen werden können.
In diesem Code wird auch nur gezeigt, wie Berichte zu einem einzelnen Debug-Signal erstellt werden. Es ist jedoch nützlich, mehrere verschiedene Signale pro Messwert erfassen und in Berichte aufnehmen zu 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);
onINP(sendToGoogleAnalytics);
Eine vollständige Liste der bereitgestellten Fehlerbehebungssignale finden Sie in der Dokumentation zu Web Vitals-Attribution.
Daten in Berichten zusammenfassen und 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. Sie sollten vor allem zuerst die Probleme angehen, 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 im Hilfeartikel Daten mit BigQuery abfragen und visualisieren weitere Informationen.
Zusammenfassung
Wir hoffen, dass dieser Beitrag Ihnen verdeutlicht hat, wie Sie die vorhandenen Leistungs-APIs und die web-vitals
-Bibliothek verwenden können, um Informationen zur Fehlerbehebung zu erhalten und die Leistung anhand von Besuchen echter Nutzer zu analysieren. In diesem Leitfaden liegt der Schwerpunkt auf den Core Web Vitals. Die Konzepte gelten jedoch auch für das Beheben von Fehlern bei allen Leistungsmesswerten, die in JavaScript gemessen werden können.
Wenn Sie gerade erst mit der Leistungsmessung beginnen und bereits Google Analytics verwenden, ist das Web Vitals-Berichtstool ein guter Ausgangspunkt. Es unterstützt bereits die Berichterstellung von Debug-Informationen für die Core Web Vitals-Messwerte.
Wenn Sie Anbieter von Analysediensten 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 für alle Analysetools gelten. Einzelne Analysetools können und sollten jedoch wahrscheinlich noch mehr Informationen zur Fehlerbehebung erfassen und melden.
Wenn Sie der Meinung sind, dass Sie diese Messwerte aufgrund fehlender Funktionen oder Informationen in den APIs nicht richtig debuggen können, senden Sie Ihr Feedback an web-vitals-feedback@googlegroups.com.