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 wiedzy o języku SQL.

Z tego przewodnika dowiesz się, jak używać BigQuery do zapisywania zapytań na zbiorze danych CrUX w celu wyodrębniania wnikliwych wyników dotyczących wrażeń użytkowników w internecie:

  • Zrozumienie sposobu porządkowania danych
  • Napisz podstawowe zapytanie, aby ocenić wydajność punktu początkowego
  • Napisz zaawansowane zapytanie, aby śledzić wydajność na przestrzeni czasu

Organizacja danych

Zacznij od przeanalizowania podstawowego zapytania:

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

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

Wpisz proste zapytanie w edytorze i naciśnij Uruchom.

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

  • SELECT COUNT(DISTINCT origin) oznacza wysłanie zapytania o liczbę źródeł w tabeli. Ogólnie rzecz biorąc, 2 adresy URL są częścią tego samego źródła, jeśli mają ten sam schemat, hosta i port.

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

    • Nazwa projektu Cloud chrome-ux-report, w którym znajdują się wszystkie dane raportu CrUX
    • Zbiór danych all obejmujący dane ze wszystkich krajów
    • Tabela 202206, rok i miesiąc danych w formacie RRRRMM.

Dla każdego kraju istnieją też zbiory danych. Na przykład chrome-ux-report.country_ca.202206 reprezentuje tylko dane dotyczące wrażeń użytkowników pochodzące z Kanady.

W zbiorze danych są tabele odpowiadające poszczególnym miesiącom od 201710 r. Nowe tabele z poprzedniego miesiąca kalendarzowego są publikowane regularnie.

Struktura tabel danych (nazywany też schematem) zawiera:

  • punkt początkowy, np. origin = 'https://www.example.com', który reprezentuje zbiorczy rozkład wrażeń użytkowników na wszystkich stronach tej witryny;
  • szybkość połączenia w momencie wczytywania strony, np. effective_connection_type.name = '4G';
  • Typ urządzenia, na przykład form_factor.name = 'desktop'.
  • same dane dotyczące UX.
    • first_paint (FP)
    • first_contentful_paint (FCP)
    • dom_content_loaded (DCL)
    • przy obciążeniu (OL)
    • eksperymentalne.first_input_delay (FID)

Informacje o poszczególnych wskaźnikach są uporządkowane w formie tablicy obiektów. W notacji JSON pole 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ść obrazu, która odzwierciedla odsetek wrażeń użytkowników w danym przedziale czasu. Oznacza to, że 12, 34% wyników FCP w przypadku tego hipotetycznego źródła, szybkości połączenia i typu urządzenia trwa mniej niż 100 ms. Suma wszystkich gęstości pojemników to 100%.

Przeglądaj strukturę tabel w BigQuery.

Ocena skuteczności

Dzięki swojej wiedzy o schemacie tabel możemy napisać zapytanie wyodrębniające te dane o wydajności.

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

Wysyłanie zapytań dotyczących FCP CrUX w BigQuery

Wynik to 0.01115, co oznacza, że 1,115% wrażeń użytkownika w tym źródle trwa od 0 do 100 ms w sieci 4G i na telefonie. Jeśli chcesz uogólnić nasze zapytanie do dowolnego połączenia i dowolnego typu urządzenia, możesz pominąć je w klauzuli WHERE i użyć funkcji agregatora 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

Sumowanie FCP CrUX w BigQuery

Wynik to 0.05355, czyli 5,355% w przypadku wszystkich urządzeń i typów połączeń. Możemy nieznacznie zmodyfikować zapytanie i zsumować gęstości dla wszystkich kontenerów, które są „szybkie” Zakres FCP: 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

Wysyłanie zapytań o szybkie FCP w BigQuery

Daje nam to 0.6977. Oznacza to, że 69,77% wyświetleń stron FCP na stronie web.dev jest uznawanych za „szybkie”. zgodnie z definicją zakresu FCP.

Śledzenie skuteczności

Po wyodrębnieniu danych o wydajnoś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 z symbolem wieloznacznym, 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

Wysyłanie zapytań do ciągów czasowych FCP CrUX w BigQuery

Widzimy, że odsetek szybkich wyrenderowanych treści zmienia się w miesiącu o kilka punktów procentowych.

rrrrmm fast_fcp
202206 69,77%
202205 70,71%
202204 69,04%
202203 69,82%
202202 67,75%
202201 58,96%
202112 41,69%
… …

Dzięki tym technikom możesz sprawdzać wydajność źródła, obliczać odsetek szybkich rozwiązań i śledzić je w czasie. W kolejnym kroku spróbuj wysłać zapytanie o co najmniej 2 źródła i porównać ich wydajność.

Najczęstsze pytania

Oto niektóre z najczęstszych pytań o zbiór danych BigQuery w CrUX:

Kiedy należy korzystać z BigQuery, a nie innych narzędzi?

Usługa BigQuery jest potrzebna tylko wtedy, gdy nie możesz uzyskać tych samych informacji z innych narzędzi, takich jak panel CrUX czy PageSpeed Insights. BigQuery umożliwia na przykład sensowne wycinanie danych, a nawet łączenie ich z innymi publicznymi zbiorami danych, takimi jak archiwum HTTP, na potrzeby zaawansowanego wydobywania danych.

Czy są jakieś ograniczenia dotyczące korzystania z BigQuery?

Tak. Najważniejszym ograniczeniem jest to, że domyślnie użytkownicy mogą wysyłać zapytania dotyczące danych o wielkości maksymalnie 1 TB na miesiąc. Poza tym obowiązuje standardowa stawka 5 USD za TB.

Gdzie znajdę więcej informacji o BigQuery?

Więcej informacji znajdziesz w dokumentacji BigQuery.