CrUX History API

Veröffentlicht: 7. Februar 2023, zuletzt aktualisiert: 11. April 2025

Die CrUX History API bietet Zugriff auf Verlaufsdaten zur Nutzererfahrung von echten Nutzern der letzten sechs Monate mit geringer Latenz und auf Seiten- und Herkunftsebene.

Testen!

Gängiger Anwendungsfall

Mit der CrUX History API können Verlaufsmesswerte zur Nutzererfahrung für einen bestimmten URI abgefragt werden, z. B. „Verlaufs-UX-Trends für den Ursprung https://example.com abrufen“.

Die History API hat dieselbe Struktur wie die tägliche CrUX API, mit der Ausnahme, dass die Werte in einem Array angegeben und die Schlüssel mit Pluralformen gekennzeichnet sind (z. B. histogramTimeseries statt histogram oder p75s statt p75).

CrUX API-Schlüssel

Wie bei der täglichen API ist für die Verwendung der CrUX History API ein Google Cloud API-Schlüssel erforderlich, der für die Nutzung von Chrome UX Report API bereitgestellt wurde. Derselbe Schlüssel kann für die tägliche und die Verlaufs-API verwendet werden.

API-Schlüssel erhalten und nutzen

Schlüssel anfordern

Alternativ können Sie auf der Seite "Anmeldedaten" einen Schlüssel erstellen.

Nachdem Sie einen API-Schlüssel haben, kann Ihre Anwendung den Abfrageparameter key=yourAPIKey an alle Anfrage-URLs anhängen.

Der API-Schlüssel lässt sich sicher in URLs einbetten. Eine Codierung ist nicht notwendig.

Weitere Informationen finden Sie unter Beispielabfragen.

Datenmodell

In diesem Abschnitt wird die Struktur der Daten in Anfragen und Antworten beschrieben.

Aufnehmen

Eine einzelne Information zu einer Seite oder Website. Ein Eintrag kann Daten enthalten, die für eine Kennung und eine bestimmte Kombination von Dimensionen spezifisch sind. Ein Eintrag kann Daten für einen oder mehrere Messwerte enthalten.

IDs

Mithilfe von IDs wird festgelegt, welche Datensätze gesucht werden sollen. In CrUX sind dies Webseiten und Websites.

Ursprung

Wenn die Kennung eine Quelle ist, werden alle Daten für alle Seiten in dieser Quelle zusammengefasst. Angenommen, die Quelle http://www.example.com hatte Seiten wie in dieser Sitemap dargestellt:

http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html

Wenn Sie den Chrome UX-Bericht mit dem Ursprung http://www.example.com abfragen, werden also Daten für http://www.example.com/, http://www.example.com/foo.html und http://www.example.com/bar.html zurückgegeben, die zusammengefasst werden, da es sich bei diesen Seiten alle um Seiten mit diesem Ursprung handelt.

URLs

Wenn die Kennung eine URL ist, werden nur Daten für diese URL zurückgegeben. Sehen wir uns noch einmal die Sitemap von http://www.example.com an:

http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html

Wenn die Kennung auf „URL“ mit dem Wert „http://www.example.com/foo.html“ festgelegt ist, werden nur Daten für diese Seite zurückgegeben.

Dimensionen

Mithilfe von Dimensionen wird eine bestimmte Datengruppe angegeben, anhand derer ein Datensatz zusammengefasst wird. Ein Formfaktor von PHONE gibt beispielsweise an, dass der Datensatz Informationen zu Ladevorgängen auf einem Mobilgerät enthält.

Formfaktor

Die CrUX History API ist nur aggregiert nach der Dimension „Formfaktor“ verfügbar. Dies ist eine allgemeine Geräteklasse, die in PHONE, TABLET und DESKTOP unterteilt ist.

Messwert

Messwerte werden in Zeitreihen statistischer Aggregationen dargestellt, also in Histogrammen, Perzentilen und Brüchen.

Histogramme

Wenn Messwerte in einem Histogramm-Array ausgedrückt werden, entspricht jeder Zeitreiheneintrag dem prozentualen Anteil der Seitenladevorgänge, bei denen der Messwert in ein Intervall fiel. Die Datenpunkte werden in der Reihenfolge der Datenerfassungszeiträume dargestellt, die ebenfalls von der API zurückgegeben werden. Der erste Punkt entspricht dem frühesten Zeitraum und der letzte Punkt dem aktuellsten Zeitraum.

Ein Histogramm mit drei Bins für einen Beispielmesswert sieht so aus:

{
  "histogramTimeseries": [
    {
      "start": 0,
      "end": 2500,
      "densities": [0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187]
    },
    {
      "start": 2500,
      "end": 4000,
      "densities": [0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527]
    },
    {
      "start": 4000,
      "densities": [0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285]
    }
  ],
}

Diese Daten zeigen, dass für 91,90% der Seitenladevorgänge im ersten Erfassungszeitraum der Messwert zwischen 0 ms und 2.500 ms lag, gefolgt von 92,03%, 91,94 % usw. Die Einheiten des Messwerts sind in diesem Histogramm nicht enthalten. In diesem Fall gehen wir von Millisekunden aus.

Außerdem lag der Messwert für 5,21% der Seitenladevorgänge im ersten Erfassungszeitraum der Verlaufsdaten zwischen 2.500 ms und 4.000 ms und für 2,88% der Seitenladevorgänge im ersten Erfassungszeitraum der Verlaufsdaten über 4.000 ms.

Perzentile

Messwerte können auch Zeitreihen von Perzentilen enthalten, die für zusätzliche Analysen nützlich sein können.

Die Datenpunkte werden in der Reihenfolge der Datenerfassungszeiträume dargestellt, die ebenfalls von der API zurückgegeben werden. Der erste Punkt entspricht dem frühesten Zeitraum und der letzte Punkt dem aktuellsten Zeitraum.

{
  "percentilesTimeseries": {
    "p75s": [1362, 1352, 1344, 1356, 1366, 1377]
  },
}

Diese Perzentile können bestimmte Messwertwerte für den jeweiligen Messwert anzeigen. Sie basieren auf dem gesamten Datenpool und nicht auf den endgültigen geclusterten Daten. Daher stimmen sie nicht unbedingt mit einem interpolierten Prozentrang überein, der auf dem endgültigen geclusterten Histogramm basiert.

Brüche

Messwerte können als Zeitreihen mit beschrifteten Bruchteilen ausgedrückt werden. Jedes Label beschreibt eine Seitenladezeit auf eine bestimmte Weise. Die Datenpunkte werden in der Reihenfolge der Datenerfassungszeiträume dargestellt, die ebenfalls von der API zurückgegeben werden. Der erste Punkt entspricht dem frühesten Zeitraum und der letzte Punkt dem aktuellsten Zeitraum.

Beispiel:

{    
  "fractionTimeseries": {
    "desktop": {"fractions": [0.3195, 0.2115, 0.1421]},
    "phone": {"fractions": [0.6295, 0.7544, 0.8288]},
    "tablet": {"fractions": [0.051, 0.0341, 0.029]}
  }
}

In diesem Beispiel geht aus dem letzten Datenpunkt hervor, dass 14,21% der Seitenaufrufe von Computern und 82,88% von Smartphones ausgingen.

Messwerttypen

Da die CrUX History API dieselben Messwerttypen verwendet, finden Sie weitere Informationen in der Dokumentation zu den täglichen Messwerttypen der CrUX API.

Verfügbarkeit von Messwerten

Je nach Teilnahmevoraussetzungen ist ein Ursprung oder eine URL möglicherweise nur für einige der Erhebungszeiträume verfügbar, die von der CrUX History API abgedeckt sind. In diesen Fällen gibt die CrUX History API für die Erfassungszeiträume, für die keine geeigneten Daten vorhanden sind, "NaN" für die histogramTimeseries-Dichten und null für die percentilesTimeseries zurück. Der Grund für den Unterschied ist, dass die Histogrammdichten immer Zahlen sind, während die Perzentile Zahlen oder Strings sein können. In CLS werden Strings verwendet, auch wenn sie wie Zahlen aussehen.

Wenn für den zweiten Zeitraum beispielsweise keine geeigneten Daten vorhanden sind, wird Folgendes angezeigt:

{
  "histogramTimeseries": [
    {
      "start": 0,
      "end": 2500,
      "densities": [0.9190, "NaN", 0.9194, 0.9195, 0.9183, 0.9187]
    },
    {
      "start": 2500,
      "end": 4000,
      "densities": [0.0521, "NaN", 0.0518, 0.0518, 0.0526, 0.0527]
    },
    {
      "start": 4000,
      "densities": [0.0288, "NaN", 0.0286, 0.0285, 0.0290, 0.0285]
    }
  ],
  "percentilesTimeseries": {
    "p75s": [1362, null, 1344, 1356, 1366, 1377]
  },
}

Bei URLs oder Ursprüngen, die im Laufe der Zeit infrage kommen und dann wieder nicht, sehen Sie möglicherweise viele fehlende Einträge.

Erhebungszeiträume

Die CrUX History API enthält ein collectionPeriods-Objekt mit einem Array von firstDate- und endDate-Feldern, die die Start- und Enddaten der einzelnen Aggregationszeiträume darstellen. Beispiel:

    "collectionPeriods": [{
        "firstDate": { "year": 2022, "month": 7, "day": 10 },
        "lastDate": { "year": 2022, "month": 8, "day": 6 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 17 },
        "lastDate": { "year": 2022, "month": 8, "day": 13 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 24 },
        "lastDate": { "year": 2022, "month": 8, "day": 20 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 31 },
        "lastDate": { "year": 2022, "month": 8, "day": 27 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 7 },
        "lastDate": { "year": 2022, "month": 9, "day": 3 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 14 },
        "lastDate": { "year": 2022, "month": 9, "day": 10 }
      }
    ]

Diese Erfassungszeiträume sind in aufsteigender Reihenfolge und geben den Zeitraum an, in dem die Datenpunkte in den anderen Abschnitten der Antwort erfasst wurden.

Die History API wird jeden Montag aktualisiert und enthält Daten bis zum Vortag (Samstag). Die Daten sind also mit einer Verzögerung von zwei Tagen verfügbar. Sie enthält Daten aus den letzten 40 Wochen – ein Erhebungszeitraum pro Woche. Standardmäßig werden 25 Erfassungszeiträume zurückgegeben. Sie können dies ändern, indem Sie "collectionPeriodCount" in der Anfrage auf eine Zahl zwischen 1 und 40 setzen.

Da jeder Erhebungszeitraum die aggregierten Daten der letzten 28 Tage enthält und die Erhebungszeiträume wöchentlich sind, überschneiden sie sich. Sie ähneln einem gleitenden Mittelwert, wobei in jedem nachfolgenden Zeitraum Daten aus drei Wochen enthalten sind und eine Woche variiert.

Beispielabfragen

Abfragen werden als JSON-Objekte mit einer POST-Anfrage an https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=[YOUR_API_KEY]" gesendet. Die Abfragedaten sind dabei im POST-Body als JSON-Objekt enthalten.

Beachten Sie, dass queryHistoryRecord die queryRecord der täglichen CrUX API ersetzt.

Ein Beispiel für den Textkörper:

{
  "origin": "https://example.com",
  "formFactor": "PHONE",
  "metrics": [
    "largest_contentful_paint",
    "experimental_time_to_first_byte"
  ]
}

Sie können ihn beispielsweise über curl mit der folgenden Befehlszeile aufrufen (ersetzen Sie API_KEY durch Ihren Schlüssel):

curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=API_KEY' \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --data '{"formFactor":"PHONE","origin":"https://www.example.com","metrics":["largest_contentful_paint", "experimental_time_to_first_byte"]}'

Daten auf Seitenebene sind über die API verfügbar, wenn Sie in der Abfrage eine url-Property anstelle von origin übergeben:

{
  "url": "https://example.com/page",
  "formFactor": "PHONE",
  "metrics": [
    "largest_contentful_paint",
    "experimental_time_to_first_byte"
  ]
}

Wenn die Property metrics nicht festgelegt ist, werden alle verfügbaren Messwerte zurückgegeben:

  • cumulative_layout_shift
  • first_contentful_paint
  • interaction_to_next_paint
  • largest_contentful_paint
  • experimental_time_to_first_byte
  • largest_contentful_paint_resource_type
  • 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
  • navigation_types
  • round_trip_time
  • form_factors (wird nur gemeldet, wenn in der Anfrage kein formFactor angegeben ist)

Wenn kein formFactor-Wert angegeben ist, werden die Werte für alle Formfaktoren zusammengefasst.

Weitere Beispielabfragen finden Sie im Leitfaden CrUX History API verwenden.

Datenpipeline

Der CrUX-Datensatz wird über eine Pipeline verarbeitet, um die Daten zu konsolidieren, zu aggregieren und zu filtern, bevor sie über die API verfügbar sind.

Der gleitende Durchschnitt

Die Daten im UX-Bericht für Chrome sind ein gleitender 28-Tage-Durchschnitt der zusammengefassten Messwerte. Das bedeutet, dass die Daten, die im Chrome UX Report zu einem bestimmten Zeitpunkt angezeigt werden, in Wirklichkeit Daten der letzten 28 Tage sind, die zusammengefasst wurden.

Die History API enthält eine Reihe von Erhebungszeiträumen, die jeweils 28 Tage umfassen. Da jeder Erhebungszeitraum die aggregierten Daten der letzten 28 Tage enthält und die Erhebungszeiträume wöchentlich sind, überschneiden sie sich. Sie ähneln einem gleitenden Mittelwert, wobei in jedem nachfolgenden Zeitraum Daten aus drei Wochen enthalten sind und eine Woche variiert.

Wöchentliche Updates

Die History API wird jeden Montag gegen 04:00 Uhr (UTC) aktualisiert und enthält Daten bis zum Vorsabbat (gemäß der standardmäßigen Verzögerung von zwei Tagen). Sie enthält Daten aus den letzten 40 Wochen (ungefähr 10 Monate), jeweils einen Erhebungszeitraum pro Woche. Standardmäßig werden 25 Einträge pro Zeitreihe zurückgegeben. Diese Anzahl kann jedoch überschrieben werden, indem Sie den Abfrageparameter collectionPeriodCount angeben.

Es gibt kein Service Level Agreement für die Aktualisierungszeit. Die Aktualisierung erfolgt täglich auf Best-Effort-Basis.

Schema

Es gibt einen einzigen Endpunkt für die CrUX History API, der POST HTTP-Anfragen akzeptiert. Die API gibt eine record zurück, die eine oder mehrere metrics enthält, die den Leistungsdaten für den angeforderten Ursprung oder die angeforderte Seite entsprechen.

HTTP-Anfrage

POST https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord

Die URL verwendet die Syntax der gRPC-Transcodierung.

Anfragetext

Die CrUX History API verwendet ähnliche Anfragetexte wie die tägliche CrUX API, mit einem zusätzlichen optionalen "collectionPeriodCount"-Feld:

{
  "formFactor": enum (FormFactor),
  "metrics": [
    string
  ],

  // Union field url_pattern can be only one of the following:
  "origin": string,
  "url": string,
  // End of list of possible types for union field url_pattern.

  "collectionPeriodCount": int32 // Optional: Number of periods to collect
}
Felder
formFactor

enum (FormFactor)

Der Formfaktor ist eine Abfragedimension, die die Geräteklasse angibt, zu der die Daten des Datensatzes gehören sollten.

In diesem Feld werden die Werte DESKTOP, PHONE oder TABLET verwendet.

Hinweis: Wenn kein Formfaktor angegeben ist, wird ein spezieller Datensatz mit aggregierten Daten für alle Formfaktoren zurückgegeben.
metrics[]

string

Die Messwerte, die in der Antwort enthalten sein sollen. Wenn keine angegeben sind, werden alle gefundenen Messwerte zurückgegeben.

Zulässige Werte: ["cumulative_layout_shift", "first_contentful_paint", "interaction_to_next_paint", "largest_contentful_paint", "experimental_time_to_first_byte", "largest_contentful_paint_resource_type", "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", "navigation_types", "round_trip_time"]
Union-Feld url_pattern. Die url_pattern ist die Hauptkennzeichnung für die Datensatzsuche. Mögliche Werte:
origin

string

„url_pattern origin“ bezieht sich auf ein URL-Muster, das der Ursprung einer Website ist.

Beispiele: "https://example.com", "https://cloud.google.com"
url

string

url_pattern url bezieht sich auf ein URL-Muster, das eine beliebige URL ist.

Beispiele: "https://example.com/, https://cloud.google.com/why-google-cloud/"
Ende des Union-Felds url_pattern.
collectionPeriodCount

int32 (optional)

Die Anzahl der zurückzugebenden Erhebungszeiträume muss zwischen 1 und 40 liegen. Der Standardwert ist 25.

Hinweis: Wenn kein collectionPeriodCount angegeben ist, wird der Standardwert 25 zurückgegeben.

So rufen Sie beispielsweise die LCP-Werte für den Desktop für die Startseite von web.dev ab:

{
  "url": "https://web.dev/",
  "formFactor": "DESKTOP",
  "metrics": [
    "largest_contentful_paint"
  ]
}

Diese ähnliche Abfrage enthält das optionale Feld collectionPeriodCount und würde 40 Zeitreiheneinträge mit einem Web-Leistungsverlauf von etwa 10 Monaten für den Ursprung https://web.dev liefern:

{
  "url": "https://web.dev/",
  "formFactor": "DESKTOP",
  "metrics": [
    "largest_contentful_paint"
  ],
  "collectionPeriodCount": 40
}

Antworttext

Bei erfolgreichen Anfragen werden Antworten mit einem record-Objekt und urlNormalizationDetails in der folgenden Struktur zurückgegeben:

{
  "record": {
    "key": {
      object (Key)
    },
    "metrics": [
      string: {
        object (Metric)
      }
    ]
  },
  "urlNormalizationDetails": {
    object (UrlNormalization)
  }
}

Die Antwort auf den Anfragetext in der vorherigen Anfrage könnte beispielsweise so aussehen:

{
  "record": {
    "key": {
      "origin": "https://web.dev"
    },
    "metrics": {
      "largest_contentful_paint": {
        "histogramTimeseries": [{
            "start": 0, "end": 2500, "densities": [
              0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187, ...
            ]
          }, {
            "start": 2500, "end": 4000, "densities": [
              0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527, ...
            ]
          },  {
            "start": 4000, "densities": [
              0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285, ...
            ]
          }
        ],
        "percentilesTimeseries": {
          "p75s": [
            1362, 1352, 1344, 1356, 1366, 1377, ...
          ]
        }
      }
    },
    "collectionPeriods": [{
        "firstDate": { "year": 2022, "month": 7, "day": 10 },
        "lastDate": { "year": 2022, "month": 8, "day": 6 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 17 },
        "lastDate": { "year": 2022, "month": 8, "day": 13 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 24 },
        "lastDate": { "year": 2022, "month": 8, "day": 20 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 31 },
        "lastDate": { "year": 2022, "month": 8, "day": 27 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 7 },
        "lastDate": { "year": 2022, "month": 9, "day": 3 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 14 },
        "lastDate": { "year": 2022, "month": 9, "day": 10 }
      }, {
        ...
      }
    ]
  }
}

Schlüssel

Key definiert alle Dimensionen, die diesen Datensatz als eindeutig identifizieren.

{
  "formFactor": enum (FormFactor),

  // Union field url_pattern can be only one of the following:
  "origin": string,
  "url": string
  // End of list of possible types for union field url_pattern.
}
Felder
formFactor

enum (FormFactor)

Der Formfaktor ist die Geräteklasse, die alle Nutzer für den Zugriff auf die Website für diesen Datensatz verwendet haben.

Wenn der Formfaktor nicht angegeben ist, werden aggregierte Daten für alle Formfaktoren zurückgegeben.
Union-Feld url_pattern. Das URL-Muster ist die URL, auf die sich der Eintrag bezieht. Für url_pattern ist nur einer der folgenden Werte zulässig:
origin

string

„Origin“ gibt den Ursprung an, für den dieser Eintrag gilt.

Hinweis: Wenn Sie einen Ursprung angeben, werden Daten für Ladevorgänge unter diesem Ursprung auf allen Seiten zu Nutzerfreundlichkeitsdaten auf Ursprungsebene zusammengefasst.
url

string

Mit url wird eine bestimmte URL angegeben, für die dieser Eintrag gilt.

Hinweis: Wenn Sie eine url angeben, werden nur Daten für diese bestimmte URL zusammengefasst.

Messwerte

Ein metric ist eine Reihe von Daten zur Nutzerfreundlichkeit für einen einzelnen Web-Leistungsmesswert, z. B. „First Contentful Paint“. Es enthält ein zusammenfassendes Histogramm der tatsächlichen Chrome-Nutzung in Form einer Reihe von bins.

{
  "histogramTimeseries": [
    {
      object (Bin)
    }
  ],
  "percentilesTimeseries": {
    object (Percentiles)
  }
}

oder

"fractionTimeseries": {
  object (Fractions)
}
Felder
histogramTimeseries[]

object (Bin)

Das Zeitreihenhistogramm der Nutzererfahrungen für einen Messwert. Das Zeitreihenhistogramm hat mindestens einen Bin und die Dichten aller Bins summieren sich auf etwa 1.

Fehlende Werte für diesen Erfassungszeitraum werden als "NaN" gekennzeichnet.
percentilesTimeseries

object (Percentiles)

Gängige nützliche Perzentile des Messwerts. Der Werttyp für die Perzentile ist derselbe wie der Werttyp für die Histogrammbalken.

Fehlende Werte für diesen Erfassungszeitraum werden als null gekennzeichnet.
fractionTimeseries

object (Fractions)

Dieses Objekt enthält Zeitreihen mit beschrifteten Brüchen, die pro Eintrag ungefähr 1 ergeben.

Brüche werden auf vier Dezimalstellen gerundet.

Fehlende Einträge werden in allen Brüchen als „NaN“ ausgedrückt.

Klasse

Ein bin ist ein diskreter Datenbereich, der vom Anfang bis zum Ende reicht oder, wenn kein Ende angegeben ist, vom Anfang bis unendlich.

Die Start- und Endwerte eines Buckets sind im Werttyp des Messwerts angegeben, den er darstellt. „First Contentful Paint“ wird beispielsweise in Millisekunden gemessen und als Ganzzahl dargestellt. Daher werden für die Messwert-Bins int32-Werte für die Start- und Endtypen verwendet. Die kumulative Layoutverschiebung wird jedoch in dezimalen Werten ohne Einheiten gemessen und als Dezimalzahl als String dargestellt. Daher werden für die Messwertgruppen Strings als Werttyp verwendet.

{
  "start": value,
  "end": value,
  "densities": [number, number, number...etc.]
}
Felder
start

(integer | string)

„Start“ ist der Beginn des Datenbins.
end

(integer | string)

„End“ ist das Ende des Datenbins. Wenn „end“ nicht angegeben ist, hat der Bin kein Ende und ist von „start“ bis +inf gültig.
densities

array[number]

Eine Zeitreihe mit dem Anteil der Nutzer, für die der Wert dieses Buckets für den jeweiligen Messwert aufgetreten ist.

Dichten werden auf 4 Dezimalstellen gerundet.

Perzentile

Percentiles enthält synthetische Werte eines Messwerts bei einem bestimmten statistischen Perzentil. Mithilfe dieser Messwerte lässt sich der Wert eines Messwerts für einen Prozentsatz der Nutzer im Vergleich zur Gesamtzahl der Nutzer schätzen.

{
  "P75": value
}
Felder
p75s

array[(integer | string)]

Zeitreihe der Werte, bei denen der Messwert bei 75% der Seitenladevorgänge den angegebenen Wert erreicht oder unterschreitet hat.

Brüche

Fractions enthält Zeitreihen mit beschrifteten Anteilen, die pro Eintrag auf etwa 1 addieren. Jedes Label beschreibt eine Seitenlade in irgendeiner Weise. Daher können Messwerte, die auf diese Weise dargestellt werden, als eindeutige Werte anstelle von numerischen Werten betrachtet werden. Die Brüche geben an, wie oft ein bestimmter eindeutiger Wert gemessen wurde.

{
  "label_1": { "fractions": array[fraction]},
  "label_1": { "fractions": array[fraction]},
  ...
  "label_n": { "fractions": array[fraction]}
}

Ähnlich wie die Dichtewerte in Histogrammbalken ist jeder fraction eine Zahl 0.0 <= value <= 1.0 und ihre Summe beträgt etwa 1,0. Wenn der Messwert für einen bestimmten Erfassungszeitraum nicht verfügbar ist, wird in allen Arrays mit Brüchen „NaN“ als entsprechender Eintrag angezeigt.

Felder
p75s

array[(integer | string)]

Zeitreihe der Werte, bei denen der Messwert bei 75% der Seitenladevorgänge diesem Wert entspricht oder darunter liegt.

UrlNormalization

Objekt, das die Normalisierungsaktionen darstellt, die durchgeführt wurden, um eine URL zu normalisieren und so die Wahrscheinlichkeit einer erfolgreichen Suche zu erhöhen. Das sind grundlegende, automatisierte Änderungen, die vorgenommen werden, wenn beim Abrufen der angegebenen url_pattern ein Fehler auftritt. Komplexe Aktionen wie das Folgen von Weiterleitungen werden nicht verarbeitet.

{
  "originalUrl": string,
  "normalizedUrl": string
}
Felder
originalUrl

string

Die ursprünglich angeforderte URL vor jeglichen Normalisierungsaktionen.
normalizedUrl

string

Die URL nach allen Normalisierungsaktionen. Dies ist eine gültige URL für die Nutzerfreundlichkeit, die in angemessener Weise aufgerufen werden kann.

Ratenlimits

Die CrUX History API hat das gleiche Limit wie die CrUX API: 150 Anfragen pro Minute und Google Cloud-Projekt. Beide APIs sind kostenlos. Dieses Limit und Ihre aktuelle Nutzung finden Sie in der Google Cloud Console. Dieses großzügige Kontingent sollte für die meisten Anwendungsfälle ausreichen. Es ist nicht möglich, ein höheres Kontingent zu erwerben.