Veröffentlicht: 11. Februar 2025
Die Februar 2025-Version des Chrome User Experience Report (CrUX) enthält eine Reihe neuer (und geänderter) Messwerte:
- Largest Contentful Paint (LCP)-Bildunterteile und Ressourcentypen
- Details zur Umlaufzeit (Round Trip Time, RTT)
- Entfernung der Dimension „Effektiver Verbindungstyp“
Mit diesen neuen Funktionen erhalten Sie einen besseren Einblick in die Leistungsmesswerte von Ursprüngen und URLs, die in CrUX verfügbar sind. In diesem Beitrag erfahren Sie, warum das so ist.
LCP-Diagnoseinformationen
Wir haben das Konzept der LCP-Unterelemente auf der Google I/O 2022 als effektive Methode eingeführt, um die LCP-Zeit für Seiten mit LCPs für Bilder in kleinere Komponenten aufzuteilen. So können Sie Ihre Bemühungen darauf konzentrieren, die richtigen Ursachen für eine hohe LCP zu optimieren.
Die Analyse der HTTP Archive-Lab-Daten in diesem Vortrag hat gezeigt, dass die Bilddownloadzeit oft der kleinste Teil der LCP-Zeit ist. Viele Lab-Tools (einschließlich Lighthouse von Google) konzentrierten sich häufig auf Ratschläge zur Optimierung von Bildformaten und -größen, um die Downloadzeiten zu verkürzen und die Leistung zu verbessern. Die Analyse hat zwar gezeigt, dass der Ratschlag korrekt ist, aber möglicherweise zu sehr betont wurde. Ein größeres Problem waren die Verzögerungen, bevor das Bild vom Browser gefunden und heruntergeladen wurde.
Die Analyse von Labordaten kann zwar nützlich sein, die Nutzung des Webs in der Praxis kann sich jedoch oft unterscheiden. Daher ist es wichtig, diese Unterabschnitte für Felddaten sehen zu können. In einem Beitrag, der letztes Jahr veröffentlicht wurde, wurde bestätigt, dass ein häufiges Missverständnis zur Optimierung des LCP mit Felddaten besteht.
LCP-Bild-Unterteile
Mit dieser Version können Websiteinhaber ihre eigenen Websites auf die Unterelemente für die LCP von Bildern auf Ursprungs- oder URL-Ebene prüfen.
Untergeordnete Teile sind nur für Bilder verfügbar. Das gilt nicht für Bilder des ersten Videoframes, da wir die vollständige Downloadzeit nicht messen können. Textunterteile werden ebenfalls nicht berücksichtigt, da sie weniger nützlich sind und die LCP-Werte von Bildern verfälschen würden. Bei Websites, die hauptsächlich aus LCPs mit Text bestehen, sind die Messwerte „TTFB insgesamt“ und „FCP insgesamt“ nützliche Aufschlüsselungen. Beachten Sie jedoch, dass sie sich auf alle LCPs beziehen und nicht speziell auf LCPs mit Text. Bildunterteile werden nur beim vollständigen Laden der Seite erfasst, im Gegensatz zum LCP-Messwert selbst, der auch bei Vor- und Zurück-Navigationen und vorab gerenderten Seiten erfasst wird.
Diese Daten wurden der CrUX API und der CrUX History API ab Februar 2025 hinzugefügt (nicht BigQuery). Die CrUX History API enthält bei der Einführung Daten für zwei Wochen. Im Laufe der Zeit wird der Verlauf auf 25 Wochen erweitert. Die APIs stellen die Daten als 75. Perzentil jedes Teils in Millisekunden bereit.
Wenn Sie beispielsweise die LCP-Bild-Unterteile für https://web.dev/ für PHONE Seitenaufrufe abrufen möchten, können Sie den folgenden Curl-Befehl verwenden (ersetzen Sie API_KEY durch Ihren eigenen Schlüssel):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Sie erhalten dann eine Antwort, die in etwa so aussieht:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Wir haben das CrUX-Vis-Tool um diese Daten erweitert. Wir gehen davon aus, dass auch andere Drittanbietertools, die die CrUX APIs verwenden, diese wertvollen Daten bereitstellen:
In diesem Beispiel sehen wir, dass bei einer beliebten Medienwebsite die Dauer des Ressourcenladevorgangs die kleinste Komponente ist. Die größten Verbesserungsmöglichkeiten für diese Website liegen bei der TTFB und der Verzögerung beim Laden der Ressourcen. Die Verzögerung beim Rendering des Elements bietet weniger Optimierungspotenzial.
Hohe Werte in den einzelnen Unterabschnitten deuten auf verschiedene Probleme hin:
- Ein hoher TTFB (Time To First Byte) weist in der Regel auf Server-, Netzwerk- oder Weiterleitungsprobleme hin, wie unter TTFB optimieren erläutert.
- Eine hohe Verzögerung beim Laden von Ressourcen weist darauf hin, dass das LCP-Bild vom Browser erst spät erkannt wird. Das kann beispielsweise bei einem LCP-Bild der Fall sein, das durch clientseitiges JavaScript eingefügt wird und dessen Ausführung einige Zeit in Anspruch nimmt.
- Bei einer hohen Dauer der Ressourcenauslastung sollten Sie die Größe des Bilddownloads reduzieren.
- Eine hohe Element-Rendering-Verzögerung liegt vor, wenn das Bild verfügbar ist (z. B. über ein
<link rel=preload>), aber lange nicht verwendet wird. Dies ist oft darauf zurückzuführen, dass für die Darstellung des Bilds clientseitiges JavaScript erforderlich ist.
Wir hoffen, dass es für Websites einfacher wird, den LCP-Messwert zu optimieren, da diese Daten jetzt sowohl auf Quell- als auch auf URL-Ebene in CrUX verfügbar sind (vorbehaltlich der üblichen Teilnahmevoraussetzungen).
LCP-Ressourcentypen
Da sich die Unterelemente am besten für LCPs von Bildern ansehen lassen, werden diese Daten in CrUX nur auf Seiten mit Bildern beschränkt. Daher ist es wichtig zu wissen, wie viele Ihrer LCPs LCPs für Bilder und wie viele LCPs für Text sind (z. B. <h1>-Überschriften und lange Absätze).
Neben den LCP-Bildunterteilen enthalten die CrUX APIs jetzt auch eine Ressourcenaufschlüsselung, die die Aufteilung der LCP-Seitenaufrufe in Text und Bilder zeigt.
Wenn Sie beispielsweise die LCP-Ressourcentypen für https://web.dev/ für PHONE Seitenaufrufe abrufen möchten, können Sie den folgenden Curl-Befehl verwenden. Ersetzen Sie dabei API_KEY durch Ihren eigenen Schlüssel:
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Sie erhalten dann eine Antwort, die in etwa so aussieht:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
CrUX Vis wurde ebenfalls aktualisiert, um diese Daten anzuzeigen:
Bei der Startseite von web.dev sehen wir beispielsweise, dass 98,5% der LCPs tatsächlich LCPs für Text waren.Die LCP-Unterabschnitte für Bilder sind für diese Seite also weniger nützlich. In diesem Fall können wir die ursprünglichen TTFB- und FCP-Messwerte als potenziell bessere Diagnoseaufschlüsselung verwenden.
LCP-Ressourcentypen sind ein weiteres nützliches Diagnosetool, um LCP zu verstehen und zu verbessern, insbesondere um zu erfahren, wie nützlich die LCP-Bildunterteile sind.
RTT-Diagnoseinformationen
Außerdem haben wir den RTT-Messwert, der im August 2024 eingeführt wurde, erweitert.
RTT-Dreiecksgruppen
Wir haben den CrUX APIs Dreifach-Bins hinzugefügt, die drei Gruppierungen von RTT-Dichten enthalten:
| Netzwerklatenz | Start | Ende |
|---|---|---|
| Niedrig | 0 Millisekunden | < 75 Millisekunden |
| Mittel | 75 Millisekunden | < 275 Millisekunden |
| Hoch | 275 Millisekunden | ∞ |
Diese Bins sind aussagekräftiger als die bisherigen ECT-Kategorien, in denen alle Werte unter 270 Millisekunden in der Kategorie 4g zusammengefasst wurden. Aufgrund der Fortschritte bei der Netzwerktechnologie seit der Einführung dieser Kategorien entfielen auf die meisten Websites die meisten Zugriffe auf diese Kategorie, was diese Kategorisierung weniger nützlich machte.
Daher empfehlen wir die Verwendung der Labels niedrig, mittel und hoch anstelle der üblichen Labels gut, verbesserungswürdig und schlecht. Diese Messwerte können nicht direkt vom Websiteinhaber verbessert werden. Sie dienen daher als Diagnosemesswerte, um die anderen Messwerte zu verstehen und zu ermitteln, warum sie möglicherweise von den Erwartungen abweichen. Sie können auch erklären, warum sich andere Messwerte im Laufe der Zeit ändern, obwohl sich die Website nicht ändert, wenn sie eine Änderung der Nutzerbasis zeigen.
Diese Bins sind in den CrUX APIs verfügbar, z. B. für web.dev für PHONE Seitenaufrufe (ersetzen Sie API_KEY wieder durch Ihren eigenen Schlüssel):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Dies gibt in etwa Folgendes zurück:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Die Bins werden in CrUX-Visualisierungen angezeigt, wenn Verteilungen ausgewählt sind:
RTT in BigQuery
Wir haben den RTT-Messwert in den CrUX APIs um die Tri-Bins erweitert und die Daten auch im monatlichen BigQuery-Dataset verfügbar gemacht. Dazu gehören ein vollständiges Histogramm in 25-Millisekunden-Buckets in den Raw-Tabellen sowie Tri-Bins und p75-Werte in den materialisierten Tabellen.
So erhalten Sie ein besseres Verständnis der Datenverteilung über die in den CrUX APIs verfügbaren Dreifach-Bins hinaus. Außerdem können wir die Aufschlüsselung der durchschnittlichen Ladezeit neu erstellen, die seit diesem Monat aus CrUX entfernt wurde (mehr dazu später). Dabei wird der Grenzwert von 275 Millisekunden für 4g statt des bisherigen Grenzwerts von 270 Millisekunden verwendet. Die Aufschlüsselungen nach ECT (jetzt aus RTT-Daten) sind weiterhin in den materialisierten BigQuery-Tabellen von CrUX verfügbar, sodass diese Aufschlüsselung in Tools wie dem CrUX-Dashboard weiterhin angezeigt werden kann.
Das BigQuery-Dataset enthält auch Daten nach Land (gemäß ISO 3166-1). So können Sie die Leistung genauer analysieren und herausfinden, warum die Leistungsmesswerte für einige Nutzer schlechter sind. So können wir uns beispielsweise die Daten für Google Pixel-Nutzer ansehen, indem wir uns die Daten für https://www.google.com ansehen:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Anschließend visualisieren wir die Daten auf einer Geo-Karte:
https://www.google.com(Quelldaten mit interaktivem Diagramm).
Wir sehen, dass die meisten Länder der Welt (insbesondere die „westliche Welt“) sehr gute RTTs haben, während in Afrika südlich der Sahara, in Teilen des Nahen Ostens und in Teilen Asiens die Werte schlechter sind. Tatsächlich ist die Grafik auf 500 Millisekunden RTT begrenzt,da die Farben bei Verwendung der vollständigen Daten verzerrt wurden – insbesondere bei Eritrea mit einem 75. Perzentil von 3.850 Millisekunden.
Das kann auch nützlich sein, wenn sich die Zugriffsmuster ändern. So kann beispielsweise ein höherer Anteil an Nutzern aus Ländern mit höheren RTTs zu schlechteren Core Web Vitals-Statistiken führen, obwohl sich an der Website nichts geändert hat.
Websites können die RTT zwar nicht direkt verbessern, aber wenn diese Daten von den Besuchern einer Website zur Verfügung gestellt werden, können Sie die Nutzer Ihrer Website weltweit besser verstehen. Außerdem bietet es viele Möglichkeiten für Analysen in der Zukunft und wir hoffen, dass Forscher interessante Erkenntnisse aus diesem Datensatz gewinnen.
Entfernung der Dimension „ECT“
Die letzte Änderung in der Februar-2025-Version ist die Einstellung der Dimension „Effektiver Verbindungstyp“ (Effective Connection Type, ECT) in BigQuery. Wir hatten RTT bereits im September 2024 aus den APIs entfernt, als wir den Messwert RTT als Ersatz einführten.
Wie bereits in diesem Beitrag erwähnt, bietet der RTT-Messwert eine detailliertere Ansicht der Verbindungsdetails der Besucher einer Website. Sie können die ECT-Buckets sogar anhand dieser Histogramme neu erstellen. Technisch gesehen sollte die erwartete Verbindungsdauer eine Kombination aus RTT und Downlinkgeschwindigkeit sein, aber in Chrome wurde immer nur RTT verwendet.
Ein wichtiger Unterschied besteht darin, dass „ECT“ eine CrUX-Dimension war. Das bedeutet, dass die anderen Messwerte nach „ECT“ segmentiert werden konnten. RTT ist ein CrUX-Messwert und keine Dimension. Daher ist es nicht möglich, beispielsweise LCP nach RTT aufzurufen. Sie können die RTTs jedoch nach den anderen Dimensionen (Gerätetyp und Land) aufrufen.
Das mag zwar etwas einschränkend klingen, aber durch die Umstellung von Dimensionen auf Messwerte stehen in CrUX tatsächlich mehr Daten zur Verfügung. Das liegt daran, dass für CrUX bestimmte Mindestgrenzwerte gelten, bevor Daten angezeigt werden können. Wir haben Dimensionen bereits 2022 optional gemacht, d. h. wir haben ECT oder das Gerät entfernt, wenn Berichte auf einer höheren Ebene erforderlich waren. Messwerte, die bei den meisten Seitenladevorgängen nicht vorhanden waren (Interaktion bis zur nächsten Darstellung (INP), verschiedene Navigationstypen und jetzt LCP-Bildunterteile), waren in BigQuery häufig nicht für Ursprünge verfügbar.
Durch die Verringerung der Anzahl der Dimensionen werden die Daten weniger segmentiert, sodass die Anzahl der Ursprünge, die diese Mindestanforderungen erfüllen, erhöht wird. Im Januar geben wir für 68, 1% der Ursprünge INP an, während im Datensatz für Dezember nur für 64, 5% der Ursprünge INP angegeben wurden. Der Mechanismus gilt auch für Navigationstypen, LCP-Unterelemente und Ressourcentypen in dieser Version. Sie alle profitieren vom Entfernen der ECT-Dimension. In den CrUX APIs ist die erweiterte Abdeckung seit Anfang Februar verfügbar.
Die ECT-Spalten bleiben aus Gründen der Konsistenz mit früheren Datensätzen in BigQuery erhalten. Die ECT-Daten in den materialisierten Ansichten sind weiterhin verfügbar, basieren aber zusätzlich zu den neuen RTT-p75- und Tri-Bins auf den RTT-Informationen (mit einem Unterschied von 5 Millisekunden für 3g und 4g wie bereits erwähnt).
Fazit
Durch die Erweiterung des öffentlichen CrUX-Datensatzes um weitere Messwerte erhalten Websiteinhaber und Rechercheure viel mehr Informationen, um Leistungsprobleme zu diagnostizieren und letztendlich zu beheben.
Da CrUX ein öffentlicher Datensatz ist, sind die Details, die wir anzeigen können, begrenzt. So können beispielsweise einzelne Elementauswahlen in CrUX nie angezeigt werden. Websiteinhabern, die diese Detailebene benötigen, wird dringend empfohlen, eine RUM-Lösung zu implementieren, die nicht so eingeschränkt ist.
Aggregierte Daten auf höherer Ebene, wie die in diesem Beitrag beschriebenen, können jedoch helfen, die Lücke zwischen dem Wissen, dass ein Problem vorliegt, und dem Wissen, warum das Problem vorliegt, zu schließen. Wir hoffen, dass diese zusätzlichen Daten hilfreich sind. Wenn du Feedback oder Fragen hast, kannst du dich in der Diskussionsgruppe an uns wenden.