Wymiar Core/Dash: Navigation Origin

Sprawdź, czy Twoi odwiedzający przybywają z tej samej domeny, czy z zewnętrznych źródeł, i jak ten podział kształtuje Twoje Core Web Vitals.

Darmowy okres próbny

Trusted by market leaders · Client results

ebaysnvkpnperionaleteiasaturnmarktplaatsvpnmonarchharvardnina careerasmusmcworkivaloopearplugswhowhatwearmy work featured on web.devhappyhorizoncomparenestleadevintafotocasadpg media

Co mierzy Navigation Origin

Wymiar Navigation Origin dzieli dane z pomiarów u użytkowników (field data) na dwie grupy:

  • Same Origin (1) — poprzednia strona znajdowała się w tej samej domenie.
  • Cross Origin (2) — użytkownik przybył z innej domeny, wyszukiwarki, platformy społecznościowej lub wpisał adres URL bezpośrednio.

To rozróżnienie ma znaczenie, ponieważ warunki początkowe przeglądarki są w każdym przypadku zupełnie inne. Nawigacja same-origin może ponownie wykorzystać istniejące połączenie, czerpać z pamięci podręcznej HTTP dla zasobów podrzędnych i korzystać z wszelkich mechanizmów prefetching'u skonfigurowanych w Twojej witrynie. Nawigacja cross-origin zaczyna się od zera.

Dlaczego nawigacje cross-origin są wolniejsze

Kiedy użytkownik klika link z zewnętrznej witryny, przeglądarka ma sporo pracy do wykonania, zanim w ogóle będzie mogła zażądać Twojego kodu HTML:

  1. Wyszukiwanie DNS (DNS lookup) — przetłumaczenie Twojej domeny na adres IP.
  2. Nawiązanie połączenia TCP (TCP handshake) — otwarcie połączenia z Twoim serwerem.
  3. Negocjacja TLS (TLS negotiation) — zakończenie procesu nawiązywania połączenia HTTPS.

Te kroki łącznie dodają zazwyczaj od 200 do 500 ms na połączeniu mobilnym, zanim zostanie zażądany pierwszy bajt Twojej strony. Ten koszt uwidacznia się bezpośrednio w Time to First Byte (TTFB), a jeśli Twój element LCP zależy od zasobu ładowanego po dotarciu kodu HTML, przekłada się to na gorszy wynik Largest Contentful Paint (LCP).

Zasoby podrzędne w pamięci podręcznej są również niedostępne. Odwiedzający, który kliknął link w Google, nie ma zapisanej w pamięci podręcznej kopii Twoich czcionek, obrazu hero ani krytycznego CSS. Odwiedzający, który właśnie przeszedł ze strony głównej, najprawdopodobniej to wszystko posiada.

Nawigacje same-origin i back-forward cache

Nawigacje same-origin otwierają drzwi do dwóch korzyści wydajnościowych, z których nawigacje cross-origin nie mogą korzystać tak niezawodnie.

Po pierwsze, Speculation Rules API pozwala na pobieranie z wyprzedzeniem (prefetch) lub wstępne renderowanie (prerender) wewnętrznych stron, zanim użytkownik w nie kliknie. Przeglądarka może mieć w pełni wyrenderowaną kolejną stronę w karcie w tle, sprawiając, że nawigacja jest natychmiastowa. Dotyczy to wyłącznie celów w ramach same-origin.

Po drugie, back-forward cache (bfcache) przywraca stronę z pamięci, gdy użytkownik naciśnie przycisk wstecz. Trafienia bfcache są niezwykle szybkie i osiągają świetne wyniki we wszystkich metrykach Core Web Vitals. Pojawiają się w Twoich danych jako nawigacje same-origin. Jeśli Twój LCP dla same-origin jest znacznie lepszy niż LCP dla cross-origin, bfcache i prefetch prawdopodobnie przyczyniają się do tej różnicy.

Jak czytać ten wymiar w CoreDash

coredash metric table urls

W CoreDash używaj Navigation Origin jako filtra lub jako wymiaru podziału obok dowolnej metryki. Najbardziej użytecznym porównaniem jest LCP według pochodzenia nawigacji. Duża różnica między LCP dla same-origin a cross-origin mówi Ci jedną z trzech rzeczy:

  • Twoje strony wejściowe cross-origin mają wolny TTFB, który zawyża LCP.
  • Nawigacje same-origin korzystają z prefetch lub bfcache, a Twoje strony cross-origin nie.
  • Zasoby podrzędne zapisane w pamięci podręcznej pomagają powracającym odwiedzającym, ale nie osobom przybywającym po raz pierwszy ze źródeł zewnętrznych.

Dane cross-origin są zazwyczaj ważniejszą liczbą dla SEO. Chrome UX Report (CrUX) od Google obejmuje wszystkie typy nawigacji, ale ruch z organicznych wyników wyszukiwania to prawie w całości cross-origin. Jeśli Twój LCP dla cross-origin osiąga dobry wynik, podczas gdy LCP dla same-origin nie, jest to niezwykłe zjawisko warte zbadania. Odwrotna sytuacja jest znacznie częstsza.

Zmniejszanie narzutu dla cross-origin

Nie możesz całkowicie wyeliminować opóźnień zimnego startu (cold-start penalty), ale możesz je zmniejszyć:

  • Używaj CDN z szybkim TTFB. Narzut związany z połączeniem maleje, gdy Twój serwer znajduje się blisko użytkownika pod względem geograficznym i szybko odpowiada. Celuj w TTFB poniżej 200 ms dla dokumentu HTML.
  • Wstępnie ładuj obraz LCP (preload). Tag <link rel="preload"> w sekcji <head> rozpoczyna pobieranie obrazu najwcześniej jak to możliwe, skracając czas między dostarczeniem kodu HTML a wyrenderowaniem elementu LCP.
  • Umieszczaj krytyczny CSS w linii (inline). Brak blokującego renderowanie żądania arkusza stylów oznacza, że przeglądarka może szybciej wyrenderować widok, nawet przy zimnym połączeniu.
  • Dodaj wskazówki preconnect dla zasobów z innych domen. Jeśli Twój obraz LCP lub zasób blokujący renderowanie jest hostowany na innej domenie, wskazówka rel="preconnect" wcześniej rozpoczyna pracę z TCP i TLS.

W przypadku nawigacji same-origin, Speculation Rules API jest obecnie najbardziej wpływowym usprawnieniem. Prerendering najbardziej prawdopodobnej kolejnej strony obniża LCP niemal do zera dla takich przejść.

Navigation Origin w szerszym kontekście

Navigation Origin działa świetnie w połączeniu z wymiarem Navigation Type (który oddziela nawigację, przeładowanie, wstecz-dalej i prerender) oraz wymiarem Effective Connection Type. Nawigacja cross-origin na wolnym połączeniu to najtrudniejszy scenariusz, z jakim mierzy się Twoja witryna. Filtrowanie według obu tych warunków naraz pokaże Ci prawdziwą wydajność w najgorszym przypadku i miejsca, w których możliwe są największe usprawnienia.