Jak korzystać ze zbioru danych BigQuery w zakresie CrUX

Rick Viscomi

Nieprzetworzone dane z Raportu na temat użytkowania Chrome (CrUX) są dostępne w BigQuery, bazie danych w Google Cloud. Korzystanie z BigQuery wymaga projektu GCP i podstawowej znajomości SQL.

Z tego przewodnika dowiesz się, jak używać BigQuery do pisania zapytań dotyczących zbioru danych CrUX, aby wyodrębniać przydatne informacje o stanie wrażeń użytkowników w internecie:

• Jak są zorganizowane dane
• Jak napisać podstawowe zapytanie, aby ocenić skuteczność źródła
• Jak napisać zaawansowane zapytanie, aby śledzić skuteczność w czasie

Organizacja danych

Zacznij od zapoznania się z podstawowym zapytaniem:

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

Aby uruchomić zapytanie, wpisz je w edytorze zapytań i naciśnij przycisk „Uruchom zapytanie”:

To zapytanie składa się z 2 części:

• SELECT COUNT(DISTINCT origin) oznacza zapytanie o liczbę źródeł w tabeli. Mówiąc w uproszczeniu, 2 adresy URL należą do tego samego źródła, jeśli mają ten sam schemat, host i port.

• FROM chrome-ux-report.all.202206 określa adres tabeli źródłowej, który składa się z 3 części:

  • Nazwa projektu w chmurze chrome-ux-report, w którym są zorganizowane wszystkie dane CrUX.
  • Zbiór danych all reprezentujący dane ze wszystkich krajów.
  • Tabela 202206, czyli rok i miesiąc danych w formacie RRRRMM.

Dostępne są też zbiory danych dla każdego kraju. Na przykład chrome-ux-report.country_ca.202206 reprezentuje tylko dane o wrażeniach użytkowników pochodzące z Kanady.

W każdym zbiorze danych znajdują się tabele za każdy miesiąc od 201710. Regularnie publikowane są nowe tabele za poprzedni miesiąc kalendarzowy.

Struktura tabel danych (znana też jako schemat) zawiera:

• Źródło, np. origin = 'https://www.example.com', które reprezentuje zbiorcze rozłożenie wrażeń użytkowników na wszystkich stronach tej witryny.
• Szybkość połączenia w momencie wczytywania strony, np. effective_connection_type.name = '4G' (usunięte w lutym 2025 r.)
• Typ urządzenia, np. form_factor.name = 'desktop'.
• Same dane o wrażeniach użytkowników:
  • 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)

Dane każdego wskaźnika są zorganizowane jako tablica obiektów. W notacji JSON first_contentful_paint.histogram.bin wyglądałoby podobnie do tego:

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

Każdy przedział zawiera czas rozpoczęcia i zakończenia w milisekundach oraz gęstość reprezentującą odsetek wrażeń użytkowników w tym przedziale czasu. Innymi słowy, 12, 34% wrażeń FCP w przypadku tego hipotetycznego źródła, szybkości połączenia i typu urządzenia trwało krócej niż 100 ms. Suma gęstości wszystkich przedziałów wynosi 100%.

Przeglądaj strukturę tabel w BigQuery.

Ocena skuteczności

Dzięki znajomości schematu tabeli możemy napisać zapytanie, które wyodrębni te dane o skuteczności.

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

Wynik to 0.01115, co oznacza, że 1,115% wrażeń użytkowników w tym źródle trwało od 0 do 100 ms w sieci 4G i na telefonie. Jeśli chcemy uogólnić zapytanie na dowolne połączenie i dowolny typ urządzenia, możemy pominąć je w klauzuli WHERE i użyć funkcji agregującej SUM, aby zsumować wszystkie odpowiednie gęstości przedziałów:

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

Wynik to 0.05355, czyli 5,355% na wszystkich urządzeniach i typach połączeń. Możemy nieznacznie zmodyfikować zapytanie i zsumować gęstości wszystkich przedziałów, które mieszczą się w „szybkim” zakresie FCP wynoszącym 0–1000 ms:

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

Daje to nam 0.6977. Innymi słowy, 69,77% wrażeń użytkowników FCP w witrynie web.dev jest uważanych za „szybkie” zgodnie z definicją zakresu FCP.

Śledzenie skuteczności

Teraz, gdy mamy już dane o skuteczności źródła, możemy porównać je z danymi historycznymi dostępnymi w starszych tabelach. Aby to zrobić, możemy zmienić adres tabeli na wcześniejszy miesiąc lub użyć składni symboli wieloznacznych, aby wysłać zapytanie dotyczące wszystkich miesięcy:

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

Widzimy, że odsetek szybkich wrażeń FCP różni się o kilka punktów procentowych w każdym miesiącu.

Dzięki tym technikom możesz sprawdzić skuteczność źródła, obliczyć odsetek szybkich wrażeń i śledzić go w czasie. Następnym krokiem jest wysłanie zapytania dotyczącego co najmniej 2 źródeł i porównanie ich skuteczności.

Najczęstsze pytania

Oto niektóre z najczęstszych pytań dotyczących zbioru danych CrUX BigQuery:

Kiedy warto używać BigQuery zamiast innych narzędzi?

BigQuery jest potrzebne tylko wtedy, gdy nie możesz uzyskać tych samych informacji z innych narzędzi, takich jak CrUX Vis i PageSpeed Insights. BigQuery umożliwia na przykład dzielenie danych w znaczący sposób, a nawet łączenie ich z innymi publicznymi zbiorami danych, takimi jak HTTP Archive, w celu przeprowadzenia zaawansowanej analizy danych.

Czy korzystanie z BigQuery wiąże się z jakimiś ograniczeniami?

Tak. Najważniejsze ograniczenie polega na tym, że domyślnie użytkownicy mogą wysyłać zapytania dotyczące tylko 1 TB danych miesięcznie. Poza tym obowiązuje standardowa stawka 5 USD za TB.

Gdzie mogę dowiedzieć się więcej o BigQuery?

Więcej informacji znajdziesz w dokumentacji BigQuery.