Wymiar Core/Dash: Navigation Origin

Zobacz, czy użytkownicy trafiają do Ciebie z tej samej domeny, czy ze źródeł zewnętrznych, i jak ten podział wpływa na Twoje Core Web Vitals.

Bezpłatny okres próbny

Trusted by market leaders · Client results

marktplaatsadevintavpnsnverasmusmcmy work featured on web.devcompareloopearplugsebayperionwhowhatwearnina caresaturndpg mediahappyhorizonharvardworkivafotocasakpnmonarchaleteianestle

Co mierzy Navigation Origin

Wymiar Navigation Origin dzieli Twoje field data na dwie grupy:

  • Same Origin (1) — poprzednia strona znajdowała się w tej samej domenie.
  • Cross Origin (2) — użytkownik przeszedł 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, pobrać zasoby podrzędne z pamięci podręcznej HTTP i skorzystać z prefetchingu skonfigurowanego na Twojej stronie. Nawigacja cross-origin zaczyna od zera.

Dlaczego nawigacje cross-origin są wolniejsze

Gdy użytkownik klika link z zewnętrznej witryny, przeglądarka musi wykonać dodatkową pracę, zanim w ogóle wyśle zapytanie o Twój HTML:

  1. DNS lookup — rozwiązać Twoją domenę na adres IP.
  2. TCP handshake — otworzyć połączenie z Twoim serwerem.
  3. TLS negotiation — ukończyć handshake HTTPS.

Razem te kroki zazwyczaj dodają od 200 do 500 ms na połączeniu mobilnym, zanim zostanie zażądany pierwszy bajt Twojej strony. Ten koszt przekłada się bezpośrednio na Time to First Byte (TTFB), a jeśli Twój element LCP zależy od zasobu ładowanego po odebraniu HTML, kaskadowo pogarsza to również Largest Contentful Paint (LCP).

Zasoby podrzędne w pamięci podręcznej również są niedostępne. Użytkownik, który przeszedł z Google, nie ma w pamięci podręcznej Twoich fontów, obrazu hero ani krytycznego CSS. Użytkownik, który właśnie przeszedł z Twojej strony głównej, prawdopodobnie ma je wszystkie.

Nawigacje same-origin a back-forward cache

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

Po pierwsze, Speculation Rules API umożliwia prefetchowanie lub prerenderowanie stron wewnętrznych, zanim użytkownik je kliknie. Przeglądarka może w pełni wyrenderować kolejną stronę w tle, dzięki czemu przejście jest natychmiastowe. Działa to tylko w przypadku stron docelowych same-origin.

Po drugie, back-forward cache (bfcache) przywraca stronę z pamięci, gdy użytkownik naciśnie przycisk Wstecz. Trafienia w bfcache są niezwykle szybkie i uzyskują świetne wyniki we wszystkich Core Web Vitals. W Twoich danych pojawiają się jako nawigacje same-origin. Jeśli Twój LCP dla same-origin jest znacznie lepszy niż LCP dla cross-origin, ta różnica wynika prawdopodobnie z działania bfcache i prefetch.

Jak odczytywać ten wymiar w CoreDash

W CoreDash możesz użyć Navigation Origin jako filtra lub wymiaru podziału obok dowolnej metryki. Najbardziej przydatnym porównaniem jest LCP według Navigation Origin. Duża różnica między LCP dla same-origin i cross-origin oznacza jedną z trzech rzeczy:

  • Twoje strony wejściowe cross-origin mają powolny TTFB, co zawyża LCP.
  • Nawigacje same-origin korzystają z prefetchu lub bfcache, a Twoje strony cross-origin nie.
  • Twoje zasoby podrzędne w pamięci podręcznej pomagają powracającym użytkownikom, ale nie tym, którzy trafiają do Ciebie po raz pierwszy ze źródeł zewnętrznych.

Dane cross-origin są zazwyczaj ważniejsze dla SEO. Chrome UX Report (CrUX) od Google uwzględnia wszystkie typy nawigacji, ale ruch z wyszukiwarek to niemal wyłącznie cross-origin. Jeśli Twój LCP dla cross-origin zalicza test, a LCP dla same-origin go oblewa, jest to nietypowe i warto to zbadać. Odwrotna sytuacja zdarza się znacznie częściej.

Zmniejszanie kary za cross-origin

Nie wyeliminujesz całkowicie opóźnienia związanego z zimnym startem, ale możesz je zmniejszyć:

  • Używaj CDN z szybkim TTFB. Narzut połączenia maleje, gdy Twój serwer znajduje się blisko geograficznie użytkownika i szybko odpowiada. Celuj w TTFB poniżej 200 ms dla dokumentu HTML.
  • Używaj preload dla obrazu LCP. Znacznik <link rel="preload"> w sekcji <head> uruchamia pobieranie obrazu tak wcześnie, jak to możliwe, skracając czas między dostarczeniem HTML a wyrenderowaniem elementu LCP.
  • Osadzaj krytyczny CSS w kodzie HTML (inline). Brak blokującego renderowanie żądania o arkusz stylów oznacza, że przeglądarka może szybciej wyrenderować stronę, nawet przy zimnym połączeniu.
  • Dodawaj wskazówki preconnect dla domen zewnętrznych (third-party). Jeśli Twój obraz LCP lub zasób blokujący renderowanie znajduje się w innej domenie, wskazówka rel="preconnect" wcześnie rozpoczyna nawiązywanie połączenia TCP i TLS.

Dla nawigacji same-origin interfejs Speculation Rules API to dziś najbardziej wpływowe ulepszenie. Prerenderowanie najbardziej prawdopodobnej kolejnej strony skraca LCP dla tych przejść niemal do zera.

Navigation Origin w szerszym kontekście

Navigation Origin świetnie współpracuje z wymiarem Navigation Type (który rozróżnia navigate, reload, back-forward i prerender) oraz wymiarem Effective Connection Type. Nawigacja cross-origin na wolnym połączeniu to najtrudniejszy scenariusz, z jakim mierzy się Twoja strona. Filtrowanie według obu tych warunków jednocześnie pokaże Ci rzeczywistą, najgorszą wydajność oraz miejsca, w których leżą największe rezerwy do optymalizacji.