Messwerte

Veröffentlicht: 23. Juni 2022, zuletzt aktualisiert: 13. Oktober 2026

Die Messwerte in CrUX basieren auf Standard-Webplattform-APIs, die von Browsern bereitgestellt werden. Im BigQuery-Dataset werden diese Daten insbesondere auf Ursprungsebene aggregiert. Websiteinhaber, die eine detailliertere Analyse (z.B. auf URL-Ebene) und Einblicke in die Leistung ihrer Website benötigen, können dieselben APIs verwenden, um detaillierte RUM-Daten (Real User Measurement) für ihre eigenen Ursprünge zu erheben. Alle APIs sind in Chrome verfügbar. Andere Browser unterstützen 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 zur Messung der visuellen Stabilität. Er gibt an, wie oft Nutzer unerwartete Layoutverschiebungen erleben. Ein niedriger CLS-Wert trägt dazu bei, dass die Seite ansprechend ist.“

web.dev/articles/cls

DOM Content Loaded

„Der Messwert DOMContentLoaded gibt an, wann das ursprüngliche HTML-Dokument vollständig geladen und geparst wurde, ohne dass auf das vollständige Laden von Stylesheets, Bildern und Subframes gewartet wird.“

MDN

First Paint

„First Paint gibt an, wann der Browser nach der Navigation zum ersten Mal gerendert hat. Der Standardhintergrund wird dabei nicht berücksichtigt, aber nicht standardmäßige Hintergründe werden einbezogen. Dies ist der erste wichtige Moment beim Seitenaufbau, auf den Entwickler achten, nämlich wenn der Browser mit dem Rendern der Seite begonnen hat.“

Paint Timing API

First Contentful Paint

„First Contentful Paint (FCP) gibt an, wann der Browser zum ersten Mal Text, ein Bild (einschließlich Hintergrundbilder), eine nicht weiße Canvas oder SVG gerendert hat. Dazu gehört auch Text mit ausstehenden Webfonts. Ab diesem Zeitpunkt können Nutzer mit den Inhalten der Seite interagieren.“

Paint Timing API

Interaction to Next Paint

„Interaction to Next Paint (INP) ist ein Messwert, mit dem die Reaktionsschnelligkeit bewertet wird. INP protokolliert die Latenz aller Interaktionen während des gesamten Lebenszyklus der Seite. 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

Interaction to Next Paint (INP) wurde im Februar 2022 dem CrUX-Dataset hinzugefügt. Dieser neue Messwert erfasst die End-to-End-Latenz einzelner Ereignisse und bietet ein umfassenderes Bild der allgemeinen Reaktionsschnelligkeit einer Seite während ihres gesamten Lebenszyklus.

Largest Contentful Paint

„Largest Contentful Paint (LCP) ist ein wichtiger, nutzerorientierter Messwert zur Messung der wahrgenommenen Ladegeschwindigkeit. Er gibt den Punkt auf der Seitenaufbau-Zeitachse an, an dem der Hauptinhalt der Seite wahrscheinlich geladen wurde. Ein schneller LCP-Wert gibt dem Nutzer die Gewissheit, dass die Seite nützlich ist.“

web.dev/articles/lcp

Ressourcentyp für „Largest Contentful Paint“

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

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

Text und Bild (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 Optimierungsmöglichkeiten besser verstehen.

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

Unterteile für „Largest Contentful Paint“-Bilder

„Die Optimierung für LCP kann komplexer sein, wenn PageSpeed Insights keine Informationen dazu liefert, wie dieser Messwert verbessert werden kann. Bei komplexen Aufgaben ist es in der Regel besser, sie in kleinere, übersichtlichere Aufgaben zu unterteilen und jede einzeln zu bearbeiten.“

web.dev/articles/optimize-lcp – LCP in Unterteile aufschlüsseln

Wenn Sie die LCPs von Bildern in die wichtigsten Unterteile aufschlüsseln, können Sie spezifische Empfehlungen und Best Practices zur Optimierung der einzelnen Teile nutzen.

Die Unterteile für LCP-Bilder 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

Unterteile sind nur für Bilder enthalten. Bilder des ersten Videoframes werden nicht berücksichtigt, da sie etwas komplizierter sind und wir die vollständige Downloadzeit nicht messen können. Bilder des ersten Videoframes sind jedoch im Messwert für den LCP-Ressourcentyp enthalten, bei dem diese Komplikation nicht relevant ist.

Textunterteile sind ebenfalls nicht enthalten, da sie weniger nützlich sind und die LCP-Zahlen für Bilder verfälschen würden. Bei Websites, die hauptsächlich aus Text-LCPs bestehen, sind die Messwerte für die Gesamt-TTFB und den Gesamt-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 weiteren Kategorien zugeordnet werden kann.
navigate_cache Ein Seitenaufruf, bei dem die Hauptressource (das Haupt-HTML-Dokument) aus dem HTTP-Cache bereitgestellt wurde. Websites nutzen häufig Caching für Unterressourcen. Das Haupt-HTML-Dokument wird jedoch oft deutlich seltener im Cache gespeichert. Wenn dies möglich ist, kann es 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, entweder durch Klicken auf die Schaltfläche „Neu laden“, durch Drücken der Eingabetaste in der Adressleiste oder durch Rückgängigmachen des Schließens eines Tabs. Beim Neuladen von Seiten wird häufig eine erneute Validierung auf dem 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 hinweisen.
restore Die Seite wurde nach einem Browserneustart oder dem Entfernen eines Tabs aus Speichergründen neu geladen. In Chrome unter Android werden diese stattdessen als „reload“ gemeldet.
back_forward Eine Navigation im Verlauf, d. h. die Seite wurde vor Kurzem aufgerufen und wieder aufgerufen. Bei korrekter Cache-Nutzung sollten diese Navigationen relativ schnell sein, aber die Seite muss trotzdem verarbeitet und JavaScript ausgeführt werden. Beides wird durch den Vor- und Zurück-Cache vermieden.
back_forward_cache Eine Navigation im Verlauf, die aus dem Vor- und Zurück-Cache bereitgestellt wurde. Wenn Sie Ihre Seiten optimieren, um den Vor- und Zurück-Cache zu nutzen, indem Sie Blocker entfernen, sollten die Navigationen schneller sein. Websites sollten also
prerender Die Seite wurde vorgerendert. Ähnlich wie beim Vor- und Zurück-Cache kann dies zu nahezu sofortigen Seitenaufrufen führen.

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

Weitere Informationen finden Sie im Blogpost zur Einführung von Navigationstypen.

Onload

„Das Ereignis „load“ wird ausgelöst, wenn die Seite und ihre abhängigen Ressourcen vollständig geladen wurden.“

MDN

Round Trip Time

Bietet eine Schätzung der HTTP-Umlaufzeit (Anwendungsebene) zu Beginn der Navigation, basierend auf den letzten Netzwerkverbindungen. Dieser Messwert basiert auf der rtt Eigenschaft der Network Information API, derselben API, die für die Dimension „ Effektiver Verbindungstyp (Effective Connection Type, ECT)“ verwendet wurde.

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

Testmesswerte

Testmesswerte 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 bleiben Sie auf dem neuesten Stand der neuesten Änderungen.

Testmesswerte für Core Web Vitals bei Soft-Navigationen

Mit dem Release vom Oktober 2026 wurden experimentelle Versionen der Core Web Vitals-Messwerte eingeführt, die Soft-Navigationen berücksichtigen:

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

Diese Messwerte umfassen sowohl vollständige Seitenaufrufe als auch Soft-Navigationen.

Weitere Informationen finden Sie im Blogpost Introducing experimental Core Web Vitals metrics to the Chrome UX Report.

Time to First Byte

TTFB in CrUX wird nur bei vollständigen Seitenaufrufen erfasst. Im Gegensatz dazu werden andere Zeitgeber (z. B. LCP) auch bei Vor- und Zurück-Cache-Navigationen (bfcache) und vorgerenderten Seiten erfasst. Daher kann die Stichprobengröße von TTFB kleiner sein als bei anderen Messwerten und ist möglicherweise nicht direkt mit diesen vergleichbar. TTFB in CrUX umfasst Seitenaufrufe ohne Cache, Seitenaufrufe mit Cache und Seitenaufrufe über eine bestehende Verbindung (z. B. Seitenaufrufe innerhalb einer Website).

TTFB ist kein direktes Maß für die Serverantwortzeit, da es auch Messungen vor diesem Zeitpunkt umfasst, einschließlich der Umleitungszeit. Außerdem wird es davon beeinflusst, ob eine Antwort aus dem Cache, von einem CDN oder vom Server bereitgestellt wird. Dies ist besonders bei Daten aus der Praxis wie CrUX der Fall, während Labortests in der Regel weniger von diesen Faktoren beeinflusst werden, da die endgültige URL getestet wird und Caching-Änderungen oft wiederholt aufgehoben werden.

Beliebtheit

Der Messwert „Beliebtheitsrang“ ist ein relatives Maß für die Beliebtheit einer Website im CrUX-Dataset, gemessen anhand der Gesamtzahl der Navigationen zum 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 Mio. usw.). Jeder Rang schließt den vorherigen aus (z. B. Top 5.000 sind tatsächlich 4.000 URLs, ohne die Top 1.000). Die Obergrenze ist dynamisch und wächst mit dem Dataset.

Die Beliebtheit wird als Leitfaden für umfassende Analysen bereitgestellt, z. B. um die Leistung nach Land für die 1.000 wichtigsten Ursprünge 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 Antworten der Nutzer auf die Aufforderungen an: „Akzeptieren“, „Ablehnen“, „Ignorieren“ oder „Schließen“.

Anzeigenmesswerte

Chrome bietet öffentliche Messwerte und Tools für Websites und andere Nutzer wie Werbetreibende, um die Anzeigenerfahrung echter Nutzer und ihre Auswirkungen besser zu verstehen.

  • 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 Anzeigen, die ein typischer Nutzer sieht.
  • Anzeigengewicht: CPU: Dieser Messwert gibt die CPU-Auslastung durch Anzeigen an, die sich auf die Leistung auswirken kann.
  • Anzeigengewicht: Netzwerk: Dieser Messwert gibt die Nutzung von Netzwerkressourcen durch Anzeigen an.

Wir gehen davon aus, dass diese Messwerte besonders für Webwerbetreibende und die Dienste nützlich sind, die sie zum Schalten von Anzeigen verwenden. Wir haben von vielen Stakeholdern im Anzeigenökosystem gehört, dass diese Messwerte ihnen helfen könnten, den Wert von Anzeigenmöglichkeiten besser einzuschätzen und Entscheidungen zu Anzeigenprodukten zu treffen.

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