Typy nawigacji są teraz dostępne w raporcie na temat użytkowania Chrome

Barry Pollard

Johannes Henkel

Od zbioru danych z marca 2024 roku raport na temat użytkowania Chrome (CrUX) zawiera dane navigation_types. Znajdziesz w nim zbiorcze statystyki dotyczące typów nawigacji wczytań stron w przypadku wymiaru, którego dotyczy zapytanie.

Różne typy nawigacji powodują różnice w danych dotyczących skuteczności, więc przy analizowaniu skuteczności witryny warto poznać względną częstotliwość wyświetlania tych różnych typów. Na przykład: gdy nawigacja korzysta z pamięci podręcznej stanu strony internetowej (bfcache), zwykle zapewnia to niemal natychmiastową nawigację, co znajduje odzwierciedlenie w bardzo niewielkich wskaźnikach LCP i FCP oraz wartości CLS i INP.

Mamy nadzieję, że udostępnienie podziału według typów nawigacji zachęci właścicieli witryn do poznania typów nawigacji używanych w ich witrynach i zachęci ich do szybszego działania dzięki konfigurowaniu pamięci podręcznej, blokadom pamięci podręcznej (bfcache) i wstępnym renderowaniu.

Dane navigation_types są dostępne w codziennym interfejsie CrUX API, interfejsie CrUX History API (z 3-tygodniową historią dostępną początkowo z 3-tygodniową historią, która w ciągu najbliższych 6 miesięcy rośnie co tydzień do pełnego pokrycia), w najnowszym zbiorze danych CrUX BigQuery i panelu CrUX. Historia pozwala też właścicielom witryn przeglądać zmiany w wykorzystaniu typu nawigacji na przestrzeni czasu. Może to umożliwić śledzenie ulepszeń (np. usunięcie blokady pamięci podręcznej stanu strony internetowej). Może też pomóc w objaśnieniu zmian w danych, nawet jeśli w witrynach nie zostały wprowadzone żadne zmiany.

Jakie typy nawigacji są dostępne w CrUX?

Raport CrUX rozróżnia te typy nawigacji w poniższej tabeli:

Typ	Opis
navigate	Wczytanie strony, które nie pasuje do żadnej z pozostałych kategorii.
navigate_cache	Wczytanie strony, dla którego zasób główny (główny dokument HTML) został wyświetlony z pamięci podręcznej HTTP. Witryny często korzystają z pamięci podręcznej w przypadku zasobów podrzędnych, ale główny dokument HTML jest często znacznie mniej w pamięci podręcznej. W razie potrzeby ich zapisywanie w pamięci podręcznej lokalnie i w sieci CDN może znacznie poprawić wydajność.
reload	Użytkownik ponownie załaduje stronę, klikając przycisk ponownego załadowania, naciskając Enter na pasku adresu lub cofając zamknięcie karty. Ponowne załadowanie strony często powoduje ponowną weryfikację na serwerze w celu sprawdzenia, czy strona główna się zmieniła. Wysoki odsetek ponownych przeładowań stron może oznaczać zdenerwowanie użytkowników.
restore	Strona została ponownie załadowana po ponownym uruchomieniu przeglądarki lub karta, która została usunięta z powodu użycia pamięci. W przypadku Chrome na Androida są one raportowane jako reload.
back_forward	nawigację w historii, która oznacza, że strona została ostatnio wyświetlona i do niej wróciła; Przy prawidłowym buforowaniu powinny one być dość szybkie, ale jednocześnie wymagają przetworzenia strony i wykonania JavaScriptu – oba te przypadki omijają pamięć podręczna bfcache.
back_forward_cache	Nawigacja w historii wyświetlana z pamięci podręcznej stanu strony internetowej. Optymalizacja stron pod kątem korzystania z pamięci podręcznej stanu strony internetowej powinna przyspieszyć działanie. Witryny powinny usunąć blokady pamięci podręcznej (bfcache), aby zwiększyć odsetek nawigacji w tej kategorii.
prerender	Strona została wstępnie wyrenderowana, co – podobnie jak w przypadku pamięci podręcznej – może powodować niemal natychmiastowe wczytywanie strony.

W niektórych przypadkach wczytanie strony może się składać z różnych typów nawigacji. W takim przypadku raport na temat użytkowania Chrome zgłasza pierwsze dopasowanie w odwrotnej kolejności z poprzedniej tabeli (od dołu do góry).

Ograniczenia typów nawigacji w raporcie na temat użytkowania Chrome

Raport CrUX jest publicznym zbiorem danych, więc jego szczegółowość raportowania jest ograniczona. W przypadku wielu źródeł i adresów URL dane navigation_types nie są dostępne z powodu niewystarczającego ilości odpowiedniego ruchu. Więcej informacji znajdziesz w artykule Metodologia CrUX.

Ponadto raport ten nie przedstawia zestawienia innych danych według typu nawigacji, ponieważ spowodowałoby to dalsze zmniejszenie liczby źródeł i adresów URL dostępnych w tym systemie.

Ważne: typy nawigacji nie są wymiarami w raportach na temat użytkowania Chrome i nie można wysyłać zapytań dotyczących danych o wydajności, takich jak LCP, według typu nawigacji. Jest to jedynie podział ułamkowy oparty na istniejących wymiarach.

Zalecamy wdrożenie w witrynach własnego narzędzia Real User Monitoring (RUM), aby móc dzielić ruch według takich kryteriów jak typy nawigacji. Możesz zauważyć różnice w typach nawigacji w tych rozwiązaniach w zależności od zgłaszanych typów i wyświetleń stron. Przeczytaj artykuł Dlaczego dane raportu na temat użytkowania Chrome różnią się od danych RUM?.

RUM może też dostarczać bardziej szczegółowe informacje o konkretnych problemach z wydajnością. Na przykład, chociaż CrUX może sugerować, że warto poprawić wymagania dotyczące pamięci podręcznej, bfcache notRestoredReasons API może dokładnie poinformować, dlaczego nie można wyświetlić danego wczytania strony z pamięci podręcznej stanu strony internetowej.

Typy nawigacji w interfejsie CrUX API

Aby wyświetlić typy nawigacji w interfejsie API, uwzględnij w żądaniu dane navigation_types lub nie ustawiaj danych, aby uwzględniać wszystkie dane:

export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.com", metrics: ["navigation_types"]}'

Format żądania został szczegółowo opisany w dokumentacji interfejsu API, w tym wyjaśnieniu, jak uzyskać klucz interfejsu API, oraz w przewodniku po interfejsie API. Spowoduje to zwrócenie obiektu podobnego do tego:

{
  "record": {
    "key": {  "origin": "https://example.com" },
    "metrics": {
      "navigation_types": {
        "fractions": {
          "navigate": 0.5335,
          "navigate_cache": 0.2646,
          "reload": 0.0885,
          "restore": 0.0023,
          "back_forward": 0.0403,
          "back_forward_cache": 0.0677,
          "prerender": 0.0031
        }
      }
    },
    "collectionPeriod": {
      "firstDate": { "year": 2024, "month": 3, "day": 6 },
      "lastDate": { "year": 2024, "month": 4, "day": 2 }
    }
  }
}

W odpowiedzi CrUX raportuje dane navigation_types jako obiekt z ułamkami wczytań strony dla każdego typu nawigacji. Każdy ułamek jest wartością z zakresu od 0.0 (co wskazuje 0% wczytań strony) do 1.0 (co oznacza 100% wczytań strony) dla danego klucza.

Z tej odpowiedzi wynika, że w okresie gromadzenia danych od 6 marca 2024 r. – do 2 kwietnia 2024 r. włącznie – 6, 77% nawigacji (wczytań stron) pochodziło z pamięci podręcznej przeglądarki. Podobnie niektóre z pozostałych części mogą pomóc w określeniu możliwości optymalizacji wczytywania strony. Pamiętaj, że w przypadku każdego klucza (w tym kombinacji adresu URL lub źródła i formatu) ułamki navigation_types sumują się do około 1,0.

Typy nawigacji w interfejsie CrUX History API

Interfejs CrUX History API może tworzyć ciągi czasowe dla typów nawigacji z maksymalnie 25 punktami danych na ułamek, co umożliwia wizualizację tych ułamków w czasie. Aby zmienić żądanie z interfejsu CrUX API na interfejs CrUX History API, uruchom je w punkcie końcowym queryHistoryRecord, a nie queryRecord. Na przykład w Historii użytkowania Chrome w Colab dane navigation_types są przedstawiane jako słupki skumulowane:

Typy nawigacji na przestrzeni czasu

Na poprzednim zrzucie ekranu historia jest dostępna tylko dla 3 okresów zbierania danych (28 dni z odstępem 7 dni). Gdy to zrobisz, obejmie to wszystkie 25 okresów zbierania danych. Wizualizowanie tej historii pozwala potwierdzić, czy optymalizacje zaczęły działać lub przestały działać. Dotyczy to zwłaszcza konfiguracji pamięci podręcznej HTTP, która jest optymalizowana pod kątem buforowania i wstępnego renderowania strony.

Typy nawigacji w BigQuery na potrzeby użytkowania Chrome

Tabele BigQuery w BigQuery obejmują teraz rekord navigation_type utworzony dla każdego typu, a widoki zmaterializowane w podsumowaniu obejmują wiele kolumn navigation_types_* – po jednej dla każdego typu.

Szczegółowe tabele

Szczegółowy schemat tabeli w BigQuery zawiera szczegółowe histogramy danych dotyczących wydajności sieci, co pozwala nam pokazać w tej przykładowej analizie, jak poszczególne typy nawigacji mogą być powiązane z szybkim lub dobrym wczytywaniem.

Na przykład przyglądaliśmy się ułamkowi back_forward_cache i jego korelacji z częstotliwością błyskawicznego wczytywania stron (instant_lcp_density zdefiniowaną jako LCP <= 200 ms) i częstotliwością wyświetlania dobrego LCP (good_lcp_density zdefiniowanego jako LCP <= 2500 ms). Zaobserwowaliśmy silną korelację statystyczną między back_forward_cache a instant_lcp_density (operator=0,87) – widoczną na następującym wykresie – oraz umiarkowaną korelację między back_forward_cache a good_lcp_density (operator=0,29).

Korelacja szybkiego wczytywania strony z wykorzystaniem pamięci podręcznej bfcache

Artykuł Colab na potrzeby tej analizy jest dobrze skomentowany. Tutaj omawiamy tylko zapytanie, które wyodrębnia ułamki Navigation_types 10 tys. najpopularniejszych źródeł ze szczegółowych tabel w BigQuery na temat użytkowania Chrome:

• Otwieramy tu tabelę all.202403 (patrz klauzula FROM) i filtrujemy form_factor pod kątem wartości phone i wybieramy źródła o rankingu popularności <= 10 000 dla 10 tys. pierwszych najpopularniejszych źródeł (patrz klauzula WHERE).
• Podczas wysyłania w BigQuery zapytań dotyczących danych navigation_types musisz podzielić dane na segmenty przez łączną liczbę ułamków (navigation_types), ponieważ sumują się one tylko według źródła, a nie według kombinacji (źródło, format).
• Nie wszystkie źródła mają atrybut navigation_types, więc warto używać elementu SAVE_DIVIDE.

WITH tmp AS (
  SELECT
    origin,
    SUM(navigation_types.navigate.fraction) AS navigate,
    SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
    SUM(navigation_types.reload.fraction) AS reload,
    SUM(navigation_types.restore AS restore,
    SUM(navigation_types.back_forward.fraction) AS back_forward,
    SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
    SUM(navigation_types.prerender.fraction) AS prerender,
    SUM(navigation_types.navigate.fraction
      + navigation_types.navigate_cache.fraction
      + navigation_types.reload.fraction
      + navigation_types.restore.fraction
      + navigation_types.back_forward.fraction
      + navigation_types.back_forward_cache.fraction
      + navigation_types.prerender.fraction) AS total
  FROM
    `chrome-ux-report.all.202403`
  WHERE
    experimental.popularity.rank <= 10000 AND
    form_factor.name = 'phone'
  GROUP BY
    origin
)

SELECT
  origin,
  ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
  ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
  ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
  ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
  ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
  ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
  ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
  tmp

Tabele zmaterializowane

Jeśli podsumowanie jest wystarczające, wygodniejsze (i tańsze) jest wysłanie zapytania do tabel zmaterializowanych. To zapytanie wyodrębnia na przykład dostępne dane navigation_types z tabeli chrome-ux-report.materialized.device_summary. Ta tabela zawiera dane według miesiąca, źródła i typu urządzenia.

SELECT
  yyyymm,
  device,
  navigation_types_navigate,
  navigation_types_navigate_cache,
  navigation_types_reload,
  navigation_types_restore,
  navigation_types_back_forward,
  navigation_types_back_forward_cache,
  navigation_types_prerender
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://example.com' AND
  navigation_types_navigate IS NOT NULL
ORDER BY
  yyyymm DESC,
  device DESC

Pamiętaj, że te ułamki nie sumują się do 1,0 na wiersz, więc konieczne jest podzielenie każdego ułamka przez sumę wyników, dla których zapytanie ma zostać zinterpretowane.

Powodem jest to, że ułamki typu navigation_type w chrome-ux-report.materialized.device_summary, np.gęstości histogramu, sumują się do 1,0 dla źródła, a nie według źródła i urządzenia dla daty. Pozwoli Ci to wyświetlić rozkład typów nawigacji na urządzeniach:

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

device	navigation_types_back_forward
phone	0.0663
desktop	0.0179
tablet	0.0009

W tym wyniku zapytania ułamki odzwierciedlają odsetek wczytań strony w przypadku źródła https://www.google.com: 6,63% tych stron miało typ nawigacji back_forward na telefonie, 1,79% na komputerach i 0,09% na tabletach.

Znacznie wyższy odsetek wartości back_forward w witrynie phone sugeruje, że warto spróbować zoptymalizować wczytywanie stron, aby można było wyświetlać je z pamięci podręcznej stanu strony internetowej.

Trzeba też jednak wziąć pod uwagę, jaka część wczytań strony jest już obsługiwana przez pamięć podręczną (bfcache), czyli częstotliwość trafień pamięci podręcznej (bfcache). Zapytanie podane poniżej sugeruje, że to konkretne źródło może już być dobrze zoptymalizowane, biorąc pod uwagę współczynnik trafień na telefonie i komputerach przekraczającym 60%.

SELECT
  device,
  navigation_types_back_forward_cache /
    (navigation_types_back_forward + navigation_types_back_forward_cache)
    AS back_forward_cache_hit_rate
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

device	back_forward_cache_hit_rate
phone	0.6239
desktop	0.6805
tablet	0.7353

Wydaje się więc, że wysoki współczynnik back_forward na telefonach nie jest spowodowany mniejszym wykorzystaniem pamięci podręcznej, ale raczej odzwierciedleniem tego, jak użytkownicy częściej poruszają się wstecz i przekierowują użytkowników na telefonach.

Typy nawigacji w panelu raportu na temat użytkowania Chrome

Najłatwiejszym sposobem sprawdzenia typów nawigacji jest panel raportu CrUX. Można go otworzyć w przypadku źródła za pomocą tego linku. Jak widać na poniższym zrzucie ekranu, początkowo dostępne są dane tylko z jednego miesiąca, ale z czasem historia będzie się zapełniać i będziesz widzieć zmiany w typach danych z miesiąca na miesiąc.

Typy nawigacji w panelu CrUX

Jak widać, na górze tej strony panelu wyróżniamy szybsze typy nawigacji, które powinny być zoptymalizowane pod kątem optymalizacji.

Podsumowanie

Mamy nadzieję, że podział typów nawigacji w raporcie na temat użytkowania Chrome będzie dla Ciebie przydatny i pomoże Ci lepiej zrozumieć i zoptymalizować wydajność witryny. Zapewniając efektywne wykorzystanie buforowania HTTP, pamięci podręcznej stanu strony internetowej i renderowania wstępnego, witryny mogą wczytywać się znacznie szybciej niż strony wymagające ponownego ruchu na serwer.

Cieszymy się też, że dane są dostępne we wszystkich różnych punktach dostępu raportu CrUX, aby użytkownicy mogli z nich korzystać według własnego uznania i wyświetlać podział typów danych według adresów URL w interfejsach API CrUX.

Chętnie poznamy Twoją opinię o tym wprowadzeniu CrUX w mediach społecznościowych lub na grupie dyskusyjnej dotyczącej tego raportu.