Messwerte

Veröffentlicht: 23. Juni 2022, Letzte Aktualisierung: 15. September 2026

Die Messwerte in CrUX basieren auf Standard-Webplattform-APIs, die von Browsern bereitgestellt werden. Im BigQuery-Dataset werden diese Daten insbesondere auf Ursprungsauflösungsebene aggregiert. Websiteinhaber, die eine detailliertere Analyse (z.B. auf URL-Ebene) und Einblicke in die Websiteleistung benötigen, können dieselben APIs verwenden, um detaillierte RUM-Daten (Real User Measurement) für ihre eigenen Ursprünge zu erfassen. Alle APIs sind in Chrome verfügbar, andere Browser unterstützen jedoch möglicherweise nicht alle Messwerte.

Die meisten Messwerte werden als Histogrammaggregation dargestellt, sodass die Verteilung visualisiert und Perzentilwerte geschätzt werden können.

Cumulative Layout Shift

„Cumulative Layout Shift (CLS) ist ein wichtiger, nutzerorientierter Messwert für die visuelle Stabilität. Er hilft zu erfassen, wie oft ein Nutzer unerwartete Veränderungen am Layout erfährt. Ein niedriger CLS-Wert trägt dazu bei, dass die Seite ansprechend ist.“

web.dev/articles/cls

DOM Content Loaded

„DOMContentLoaded meldet die verstrichene Zeit, wenn das ursprüngliche HTML-Dokument komplett geladen und geparst wurde, ohne darauf zu warten, dass Stylesheets, Bilder und Subframes vollständig geladen sind.“

MDN

First Paint

„First Paint“ gibt die Zeit an, nach der der Browser nach der Navigation erstmals gerendert wurde. Standard-Hintergrundfarben sind dabei ausgeschlossen, benutzerdefinierte Farbe hingegen eingeschlossen. Das ist der erste wichtige Moment beim Seitenaufbau, auf den Entwickler achten – wenn der Browser mit dem Rendern der Seite begonnen hat.“

Paint Timing API

First Contentful Paint

„First Contentful Paint (FCP) gibt die Zeit an, nach der der Browser erstmals einen Text, ein Bild (einschließlich Hintergrundbilder), Canvas, der nicht weiß ist, oder SVG gerendert hat. Das gilt auch für Text mit ausstehenden Webfonts. Das ist das erste Mal, dass Nutzer mit dem Konsum von Seiteninhalten beginnen konnten.“

Paint Timing API

Interaction to Next Paint

„Interaction to Next Paint (INP) ist ein Feldmesswert, mit dem die Reaktionsschnelligkeit bewertet wird. INP erfasst die Latenz aller Interaktionen während des gesamten Seitenlebenszyklus. Der höchste Wert dieser Interaktionen oder ein Wert, der bei Seiten mit vielen Interaktionen nahe am höchsten liegt, wird als INP der Seite erfasst. Ein niedriger INP-Wert sorgt dafür, dass die Seite jederzeit zuverlässig reagiert.“

web.dev/articles/inp

INP wurde dem CrUX-Dataset im Februar 2022 hinzugefügt. Mit diesem neuen Messwert wird die End-to-End-Latenz einzelner Ereignisse erfasst. So erhalten Sie ein umfassenderes Bild der allgemeinen Reaktionsfähigkeit einer Seite während ihres gesamten Lebenszyklus.

Largest Contentful Paint

„Largest Contentful Paint (LCP) ist ein wichtiger, nutzerorientierter Messwert, mit dem die wahrgenommene Ladegeschwindigkeit ermittelt wird. Er gibt den Punkt auf der Seitenaufbau-Zeitachse an, an dem der Hauptinhalt der Seite wahrscheinlich geladen wurde. Ein schneller LCP hilft dem Nutzer, sich davon zu überzeugen, dass die Seite nützlich ist.“

web.dev/articles/lcp

Ressourcentyp für „Largest Contentful Paint“

„LCP gibt die Renderingzeit des größten im Darstellungsbereich sichtbaren Bildes, Textblocks oder Videos an, bezogen auf den Zeitpunkt, zu dem der Nutzer die Seite zum ersten Mal aufgerufen hat.“

web.dev/articles/lcp – Welche Elemente werden für LCP berücksichtigt?

Text und Bilder (einschließlich des ersten Videoframes) haben oft sehr unterschiedliche Ladeeigenschaften und Optimierungstechniken. Wenn Sie das Verhältnis der LCP-Ressourcentypen kennen, können Sie Ihre LCP-Messwerte und Optimierungspfade besser nachvollziehen.

Weitere Informationen finden Sie im Blogpost zur Einführung von LCP-Ressourcentypen.

Untergeordnete Elemente des Largest Contentful Paint-Bilds

„Die LCP-Optimierung kann komplexer sein, wenn PageSpeed Insights keine Antwort darauf gibt, wie sich dieser Messwert verbessern lässt. Bei komplexen Aufgaben ist es im Allgemeinen besser, sie in kleinere, übersichtlichere Aufgaben aufzuteilen und jede davon getrennt anzugehen.“

web.dev/articles/optimize-lcp – Aufschlüsselung des LCP in Unterabschnitte

Wenn Sie die LCP von Bildern in die wichtigsten Unterbereiche aufteilen, können Sie für jeden Teil spezifische Empfehlungen und Best Practices zur Optimierung nutzen.

Die LCP-Bildunterteile werden in vier separaten Messwerten angegeben:

  • 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

Untergeordnete Elemente sind nur für Bilder enthalten. Das gilt nicht für Bilder des ersten Videoframes, da diese etwas komplizierter sind. Wir können die vollständige Downloadzeit nicht messen. Hinweis: Bilder des ersten Videoframes sind im Messwert für den Ressourcentyp „LCP“ enthalten, wo diese Komplikation nicht relevant ist.

Auch Textunterteile sind nicht enthalten, da sie weniger nützlich sind und die LCP-Zahlen für Bilder verzerren würden. Bei Websites, die hauptsächlich aus Text bestehen, sind die Messwerte für den TTFB und den FCP nützliche Aufschlüsselungen. Sie beziehen sich jedoch auf alle LCPs und nicht speziell auf Text-LCPs.

Weitere Informationen finden Sie im Blogpost zur Einführung von LCP-Bildunterteilen.

Der Messwert Navigationstypen enthält eine Aufschlüsselung des Prozentsatzes der Seitenaufrufe der folgenden Navigationen:

Typ Beschreibung
navigate Ein Seitenaufruf, der keiner der anderen Kategorien zugeordnet werden kann.
navigate_cache Ein Seitenaufruf, bei dem die Hauptressource (das primäre HTML-Dokument) aus dem HTTP-Cache bereitgestellt wurde. Websites verwenden häufig Caching für untergeordnete Ressourcen, das primäre HTML-Dokument wird jedoch oft deutlich seltener im Cache gespeichert. Wenn es im Cache gespeichert werden kann, kann dies zu spürbaren Leistungsverbesserungen führen, da es lokal und in einem CDN im Cache gespeichert werden kann.
reload Der Nutzer hat die Seite neu geladen, indem er entweder auf den Button „Neu laden“ geklickt, in der Adressleiste die Eingabetaste gedrückt oder das Schließen eines Tabs rückgängig gemacht hat. Bei Seitenneuladungen wird häufig eine erneute Validierung zum Server durchgeführt, um zu prüfen, ob sich die Hauptseite geändert hat. Ein hoher Prozentsatz an Seitenneuladungen kann auf Probleme mit der Nutzerfreundlichkeit hindeuten.
restore Die Seite wurde nach einem Browserneustart oder nach dem Entfernen eines Tabs aus Speichermangel neu geladen. In Chrome für Android werden diese Ereignisse stattdessen als „reload“ gemeldet.
back_forward Eine Verlaufsnavigation, d. h., die Seite wurde vor Kurzem aufgerufen und wieder aufgerufen. Bei korrekter Zwischenspeicherung sollten diese Vorgänge relativ schnell ablaufen. Die Seite muss jedoch verarbeitet und JavaScript ausgeführt werden. Das wird durch den BF-Cache vermieden.
back_forward_cache Eine Verlaufsnavigation, die aus dem Bfcache bereitgestellt wurde. Wenn Sie Ihre Seiten optimieren, um den bfcache zu nutzen, indem Sie Blocker entfernen, sollte dies zu einer schnelleren Nutzererfahrung führen. Websites sollten also
prerender Die Seite wurde vorab gerendert, was ähnlich wie beim Back-Forward-Cache (bfcache) zu nahezu sofortigen Seitenaufrufen führen kann.

In einigen Fällen kann ein Seitenaufbau eine Kombination aus mehreren Navigationstypen sein. In diesem Fall wird im CrUX-Bericht die erste Übereinstimmung in umgekehrter Reihenfolge der Tabelle (von unten nach oben) angegeben.

Weitere Informationen finden Sie im Blogpost zu Navigationstypen.

Onload

„Das Ereignis ‚Laden‘ wird ausgelöst, wenn die Seite und die zugehörigen Ressourcen vollständig geladen wurden.“

MDN

Umlaufzeit

Schätzt die Umlaufzeit der HTTP-Anwendungsschicht (Application Layer) zu Beginn der Navigation auf Grundlage der letzten Netzwerkverbindungen. Diese Messung basiert auf der rtt-Eigenschaft der Network Information API, die auch für die ehemalige Dimension Effective Connection Type (ECT) verantwortlich ist.

Weitere Informationen finden Sie im Blogpost zur Einführung von LCP-Ressourcentypen.

Testmesswerte

Die experimentellen Messwerte sind sowohl im CrUX-Dataset mit BigQuery als auch in der CrUX API verfügbar. Allerdings sind nicht alle Messwerte in beiden verfügbar. Diese Messwerte können sich ändern, da sie auf Nutzerfeedback basieren. In den Versionshinweisen finden Sie Informationen zu den neuesten Änderungen.

Time to First Byte

Der TTFB-Wert in CrUX wird nur bei vollständigen Seitenaufrufen erfasst, im Gegensatz zu anderen Zeitmessungen wie LCP, die auch bei Back-Forward-Cache-Navigationen (bfcache) und vorgenderte Seiten erfasst werden. Daher kann die Stichprobengröße von TTFB kleiner sein als bei anderen Messwerten und sollte nicht unbedingt direkt mit ihnen verglichen werden. Der TTFB in CrUX umfasst Kaltstarts, Seitenaufrufe aus dem Cache und Seitenaufrufe über eine bestehende Verbindung (z. B. Seitenaufrufe innerhalb einer Website).

TTFB ist kein direktes Maß für die Serverantwortzeit, da sie auch Messungen davor umfasst, einschließlich der Weiterleitungszeit. Außerdem wird sie davon beeinflusst, ob eine Antwort vom Cache, vom CDN oder vom Server bereitgestellt wird. Das ist besonders bei Felddaten wie CrUX der Fall. Labortests sind in der Regel weniger von diesen Faktoren betroffen, da die End-URL getestet und das Caching oft wiederholt negiert wird.

Beliebtheit

Der Messwert Beliebtheitsrang ist ein relativer Messwert für die Beliebtheit einer Website im CrUX-Dataset, gemessen an der Gesamtzahl der Navigationsvorgänge am Ursprung. Der Rang wird auf einer Log10-Skala mit halben Schritten angegeben (z. B. Top 1.000, Top 5.000, Top 10.000, Top 50.000, Top 100.000, Top 500.000, Top 1 Million usw.). Jeder Rang schließt den vorherigen aus (z. B. „Top 5.000“ umfasst tatsächlich 4.000 URLs, ohne die Top 1.000). Die Obergrenze ist dynamisch und wächst mit dem Dataset.

Die Popularität dient als Richtlinie für allgemeine Analysen, z. B. um die Leistung nach Land für die 1.000 wichtigsten Quellen zu ermitteln.

Berechtigung zum Senden von Benachrichtigungen

Bei Websites, die die Berechtigung zum Anzeigen von Benachrichtigungen für Nutzer anfordern, gibt dieser Messwert die relative Häufigkeit der Nutzerreaktionen auf die Aufforderungen an: „Akzeptieren“, „Ablehnen“, „Ignorieren“ oder „Schließen“.

Anzeigenmesswerte

Chrome bietet öffentliche Messwerte und Tools für Websites und andere, z. B. Werbetreibende, damit sie die Anzeigennutzung durch echte Nutzer und ihre Auswirkungen besser nachvollziehen können.

  • Anzahl der Anzeigen: Dieser Messwert gibt an, wie viele Anzeigen ein typischer Nutzer gleichzeitig auf der Website sieht.
  • Anzeigendichte: Dieser Messwert beschreibt das Gleichgewicht zwischen Inhalten und Anzeigensichtbarkeit für einen typischen Nutzer.
  • Ad Weight: CPU: Dieser Messwert beschreibt die CPU-Auslastung durch Anzeigen, die sich auf die Leistung auswirken kann.
  • Anzeigengewicht: Netzwerk: Dieser Messwert beschreibt den Verbrauch von Netzwerkressourcen durch Anzeigen.

Wir gehen davon aus, dass diese Messwerte besonders für Web-Werbetreibende und die Dienste, die sie zum Schalten von Anzeigen verwenden, nützlich sind. Wir haben von vielen Stakeholdern im Werbe-Ökosystem gehört, dass diese Messwerte ihnen helfen könnten, Werbemöglichkeiten besser zu bewerten und Entscheidungen zu Werbeprodukten zu treffen.

Weitere Informationen finden Sie im Blogpost zur Einführung von Anzeigenmesswerten und in der Dokumentation zu Anzeigenmessungen.