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.
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:
![Skumulowany wykres słupkowy przedstawiający historię typów nawigacji na przestrzeni 3 tygodni, przy czym większość nawigacji jest typu „nawigacja”, bez większych zmian w ciągu 3 tygodni.](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/navigation-types-history-chart.png?authuser=6&hl=pl)
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).
![Wykres korelacji pokazujący silną zależność między ułamkiem liczby wczytań stron błyskawicznych a ułamkiem liczby wczytań strony z pamięci podręcznej stanu strony internetowej](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/instant-lcp-bfcache-correlation.png?authuser=6&hl=pl)
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 klauzulaFROM
) i filtrujemyform_factor
pod kątem wartościphone
i wybieramy źródła o rankingu popularności <= 10 000 dla 10 tys. pierwszych najpopularniejszych źródeł (patrz klauzulaWHERE
). - 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ć elementuSAVE_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.
![Zrzut ekranu przedstawiający sekcję Rozkład typów nawigacji w panelu CrUX z danymi z jednego miesiąca.](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/crux-dashboard-navigation-types.png?authuser=6&hl=pl)
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.