Hoe u de Crux BigQuery-dataset gebruikt

De onbewerkte gegevens van het Chrome UX Report ( CrUX ) zijn beschikbaar op BigQuery , een database op Google Cloud. Voor het gebruik van BigQuery is een GCP-project en basiskennis van SQL vereist.

In deze handleiding leert u hoe u BigQuery kunt gebruiken om query's te schrijven op de CrUX-dataset om inzichtelijke resultaten te verkrijgen over de status van gebruikerservaringen op internet:

  • Begrijp hoe de gegevens zijn georganiseerd
  • Schrijf een basisquery om de prestaties van een oorsprong te evalueren
  • Schrijf een geavanceerde query om de prestaties in de loop van de tijd bij te houden

Gegevensorganisatie

Begin met het bekijken van een basisquery:

SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`

Om de query uit te voeren, voert u deze in de query-editor in en drukt u op de knop "Query uitvoeren":

Voer een eenvoudige vraag in de editor in en druk op Uitvoeren.

Deze vraag bestaat uit twee delen:

  • SELECT COUNT(DISTINCT origin) betekent het opvragen van het aantal origines in de tabel. Grof gezegd maken twee URL's deel uit van dezelfde oorsprong als ze hetzelfde schema, dezelfde host en poort hebben.

  • FROM chrome-ux-report.all.202206 specificeert het adres van de brontabel, die uit drie delen bestaat:

    • De Cloud-projectnaam chrome-ux-report waarbinnen alle CrUX-gegevens zijn georganiseerd
    • De dataset all , die gegevens uit alle landen vertegenwoordigt
    • De tabel 202206 , het jaar en de maand van de gegevens in JJJJMM-formaat

Er zijn ook datasets voor elk land. chrome-ux-report.country_ca.202206 vertegenwoordigt bijvoorbeeld alleen de gegevens over de gebruikerservaring afkomstig uit Canada.

Binnen elke dataset zijn er sinds 2017 voor elke maand tabellen beschikbaar10. Er worden regelmatig nieuwe tabellen voor de voorgaande kalendermaand gepubliceerd.

De structuur van de gegevenstabellen (ook wel het schema genoemd) bevat:

  • De oorsprong, bijvoorbeeld origin = 'https://www.example.com' , die de totale distributie van de gebruikerservaring vertegenwoordigt voor alle pagina's op die website
  • De verbindingssnelheid op het moment dat de pagina wordt geladen, bijvoorbeeld effective_connection_type.name = '4G'
  • Het apparaattype, bijvoorbeeld form_factor.name = 'desktop'
  • De UX-statistieken zelf
    • first_paint (FP)
    • first_contentful_paint ( FCP )
    • largest_contentful_paint ( LCP )
    • dom_content_loaded (DCL)
    • onload (OL)
    • layout_instability.cumulative_layout_shift ( CLS )
    • interaction_to_next_paint ( INP )

De gegevens voor elke metriek zijn georganiseerd als een array van objecten. In JSON-notatie zou first_contentful_paint.histogram.bin er ongeveer zo uitzien:

[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]

Elke bak bevat een begin- en eindtijd in milliseconden en een dichtheid die het percentage gebruikerservaringen binnen dat tijdsbereik vertegenwoordigt. Met andere woorden: 12,34% van de FCP-ervaringen voor deze hypothetische oorsprong, verbindingssnelheid en apparaattype zijn minder dan 100 ms. De som van alle bindichtheden is 100%.

Blader door de structuur van de tabellen in BigQuery.

Evalueer de prestaties

We kunnen onze kennis van het tabelschema gebruiken om een ​​query te schrijven die deze prestatiegegevens extraheert.

SELECT
  fcp
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  effective_connection_type.name = '4G' AND
  form_factor.name = 'phone' AND
  fcp.start = 0

Query's uitvoeren op Crux FCP op BigQuery

Het resultaat is 0.01115 , wat betekent dat 1,115% van de gebruikerservaringen op deze oorsprong tussen 0 en 100 ms liggen op 4G en op een telefoon. Als we onze zoekopdracht willen generaliseren naar elke verbinding en elk apparaattype, kunnen we ze weglaten uit de WHERE clausule en de SUM -aggregatorfunctie gebruiken om al hun respectieve bin-dichtheden bij elkaar op te tellen:

SELECT
  SUM(fcp.density)
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start = 0

Samenvatting van Crux FCP op BigQuery

Het resultaat is 0.05355 , oftewel 5,355% voor alle apparaten en verbindingstypen. We kunnen de query enigszins aanpassen en de dichtheden optellen voor alle bins die zich in het "snelle" FCP-bereik van 0-1000 ms bevinden:

SELECT
  SUM(fcp.density) AS fast_fcp
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start < 1000

Snelle FCP-query's uitvoeren op BigQuery

Dit geeft ons 0.6977 . Met andere woorden: 69,77% van de FCP-gebruikerservaringen op web.dev worden als "snel" beschouwd volgens de FCP-bereikdefinitie.

Houd de prestaties bij

Nu we prestatiegegevens over een oorsprong hebben opgehaald, kunnen we deze vergelijken met de historische gegevens die beschikbaar zijn in oudere tabellen. Om dat te doen, kunnen we het tabeladres herschrijven naar een eerdere maand, of we kunnen de syntaxis met jokertekens gebruiken om alle maanden op te vragen:

SELECT
  _TABLE_SUFFIX AS yyyymm,
  SUM(fcp.density) AS fast_fcp
FROM
  `chrome-ux-report.all.*`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start < 1000
GROUP BY
  yyyymm
ORDER BY
  yyyymm DESC

Een tijdreeks van Crux FCP op BigQuery opvragen

Hier zien we dat het percentage snelle FCP-ervaringen elke maand met een paar procentpunten varieert.

jjjjmm snelle_fcp
202206 69,77%
202205 70,71%
202204 69,04%
202203 69,82%
202202 67,75%
202201 58,96%
202112 41,69%
... ...

Met deze technieken kun je de prestaties van een oorsprong opzoeken, het percentage snelle ervaringen berekenen en deze in de loop van de tijd volgen. Probeer als volgende stap twee of meer herkomsten op te vragen en hun prestaties te vergelijken.

Veelgestelde vragen

Dit zijn enkele veelgestelde vragen over de CrUX BigQuery-dataset:

Wanneer zou ik BigQuery gebruiken in plaats van andere tools?

BigQuery is alleen nodig als u niet dezelfde informatie uit andere tools zoals het Crux Dashboard en PageSpeed ​​Insights kunt halen. Met BigQuery kunt u de gegevens bijvoorbeeld op zinvolle manieren opsplitsen en deze zelfs samenvoegen met andere openbare datasets zoals het HTTP-archief om geavanceerde datamining uit te voeren.

Zijn er beperkingen aan het gebruik van BigQuery?

Ja, de belangrijkste beperking is dat gebruikers standaard slechts 1 TB aan gegevens per maand kunnen opvragen. Daarbuiten is het standaardtarief van $ 5/TB van toepassing.

Waar kan ik meer te weten komen over BigQuery?

Bekijk de BigQuery-documentatie voor meer informatie.