Wymiar Core/Dash: Typ nawigacji

Segmentuj Core Web Vitals według sposobu, w jaki użytkownicy trafili na stronę, aby debugować wydajność bfcache, prerenderingu i przeładowań.

Bezpłatny okres próbny

Trusted by market leaders · Client results

marktplaatskpnsaturndpg mediaerasmusmcadevintavpnloopearplugsfotocasanestleperionwhowhatwearworkivacompareharvardhappyhorizonnina caremy work featured on web.devebayaleteiamonarchsnv

Wymiar: Typ nawigacji (nt)

Każda odsłona w twoich danych CrUX ma przypisany typ nawigacji. Mówi ci on, jak przeglądarka załadowała stronę. To z kolei decyduje, które mechanizmy przeglądarki zostały zaangażowane: stos sieciowy, back/forward cache, proces prerenderingu czy przywracanie sesji. CoreDash udostępnia te dane jako wymiar nt, co pozwala na osobne filtrowanie i porównywanie Core Web Vitals w każdym kontekście nawigacji.

Dane pochodzą z interfejsu PerformanceNavigationTiming API, a dokładnie z właściwości type. Odczytasz ją za pomocą performance.getEntriesByType("navigation")[0].type. Chrome przekazuje tę wartość przy każdym pomiarze web vitals wysyłanym do CrUX, a CoreDash zapisuje ją i indeksuje, co pozwala na segmentację bez pisania własnego kodu pomiarowego.

Dlaczego Typ nawigacji ma znaczenie

Agregowanie LCP lub INP dla wszystkich typów nawigacji daje wynik technicznie poprawny, ale w praktyce mylący. Trafienie w back/forward cache trwa milisekundy. Zimna nawigacja musi poczekać na DNS, TCP, TLS i TTFB. Jeśli 20% sesji to trafienia w bfcache, zaniżają one p75 LCP, przez co rzeczywisty problem przy świeżych otwarciach strony staje się trudniejszy do zauważenia.

W drugą stronę jest tak samo. Jeśli bfcache na twojej stronie nie działa, sesje typu back/forward będą ładować się tak samo wolno jak świeże otwarcia. Bez podziału na typy nawigacji nigdy tego nie zauważysz, bo ogólny wynik pozostanie stabilny.

Prerender to najbardziej jaskrawy przypadek. Prawidłowo prerenderowana strona powinna mieć LCP bliski zeru, ponieważ renderowanie zakończyło się, zanim użytkownik w ogóle kliknął link. Jeśli prerenderowane strony wykazują standardowe wartości LCP, konfiguracja Speculation Rules jest błędna – prerender albo się nie uruchamia, albo jest odrzucany przed użyciem.

Typy nawigacji

navigate

Standardowa nawigacja: użytkownik wpisał adres URL, kliknął link na innej stronie lub przeszedł przez przekierowanie. To pełne ładowanie strony bez korzystania z pamięci podręcznej. Przeglądarka przechodzi przez pełną ścieżkę żądania, w tym wyszukiwanie DNS, nawiązywanie połączenia i pobieranie wszystkich zasobów. W danych CoreDash navigate stanowi około 65% sesji. To twój punkt odniesienia. Każdy inny typ nawigacji należy oceniać przez porównanie z navigate.

reload

Użytkownik nacisnął F5, kliknął przycisk odświeżania w przeglądarce lub twój kod wywołał location.reload(). Przeglądarka wysyła żądania rewalidacji dla zasobów z pamięci podręcznej. Oznacza to, że TTFB często wygląda gorzej niż przy navigate, mimo że użytkownik jest na tej samej stronie. Jeśli TTFB dla reload jest drastycznie wyższy niż dla navigate, nagłówki pamięci podręcznej wymuszają rewalidację przy każdym odświeżeniu, zamiast serwować zapisaną zawartość. W typowym ruchu CoreDash przeładowania stanowią około 10% sesji.

back_forward

Użytkownik kliknął przycisk wstecz lub dalej w przeglądarce. Jeśli back/forward cache (bfcache) działa prawidłowo, jest to najszybszy możliwy typ nawigacji. Przeglądarka przywraca stronę z pamięci, całkowicie pomijając zapytania sieciowe. LCP w przypadku trafienia w bfcache to w zasadzie czas potrzebny na wyrysowanie z pamięci, co dzieje się niemal natychmiast.

Jeśli wskaźniki dla back_forward wyglądają podobnie do navigate, bfcache nie działa. Najczęstsze przyczyny to obsługa zdarzeń unload, nagłówki odpowiedzi Cache-Control: no-store oraz otwarte połączenia IndexedDB, które nie zostały zamknięte przed opuszczeniem strony. W danych CoreDash sesje typu back_forward to około 20% wszystkich sesji, więc rozwiązanie tego problemu to zmiana o dużym przełożeniu.

prerender

Strona została załadowana w tle za pomocą Speculation Rules API, zanim użytkownik kliknął link. W momencie kliknięcia prerenderowany dokument jest aktywowany natychmiast. LCP dla poprawnie aktywowanego prerendera jest bliskie zeru, ponieważ cały proces renderowania zakończył się przed samym zdarzeniem nawigacji.

Jeśli LCP dla prerender wygląda zwyczajnie, oznacza to jedną z trzech rzeczy: prerender został odrzucony przed aktywacją, reguła w Speculation Rules wskazała niewłaściwe adresy URL albo strona używa nagłówków bądź kodu JavaScript, które uniemożliwiają prerendering. W typowych danych CoreDash aktywacje prerendera to około 3% sesji, ale ten odsetek szybko rośnie po wdrożeniu Speculation Rules.

restore

Karta została przywrócona po zamknięciu przeglądarki lub po jej awarii (crashu). Przeglądarka ładuje stronę od zera, ale sesja jest traktowana jako przywrócenie (restore), a nie nowa nawigacja. Wydajność jest podobna do zimnej nawigacji. Odpowiada to za około 2% sesji i rzadko stanowi cel prac optymalizacyjnych, ale warto to monitorować, jeśli twoi użytkownicy korzystają z niestabilnych sesji przeglądarki.

Proces debugowania

  1. Porównaj LCP dla navigate z ogólnym celem LCP. To twój punkt odniesienia dla wydajności świeżych ładowań. Jeśli navigate mieści się w normie, problem leży gdzie indziej.
  2. Porównaj back_forward z navigate. Jeśli wyniki są zbliżone, bfcache nie działa. Otwórz Chrome DevTools, przejdź do panelu Application i uruchom test bfcache. DevTools wyświetli listę funkcji lub nagłówków, które uniemożliwiają skorzystanie z bfcache.
  3. Sprawdź LCP dla prerender. Jeśli przekracza 200 ms, proces prerenderingu nie działa prawidłowo. Upewnij się, że plik JSON ze Speculation Rules jest poprawny, sprawdź, czy docelowe strony nie zawierają blokującej logiki, i potwierdź w Chrome DevTools (w sekcji Speculation Rules), że aktywacje są zliczane.

Praktyczne reguły inżynierskie

  • navigate: Powinien spełniać próg LCP dzięki standardowej optymalizacji: szybki TTFB, fetchpriority="high" na obrazie LCP, brak zasobów render blocking.
  • back_forward: Powinien być od 10 do 20 razy szybszy niż navigate. Jeśli tak nie jest, bfcache nie działa.
  • prerender: Powinien wykazywać LCP poniżej 200 ms. Jeśli tak nie jest, konfiguracja Speculation Rules jest błędna.
  • reload: TTFB nie powinien być drastycznie gorszy niż dla navigate. Jeśli jest, popraw nagłówki rewalidacji pamięci podręcznej.

Typ nawigacji to wymiar, który oddziela pytanie „jak działa moja strona?” od „jak działa moja strona w zależności od strategii ładowania przeglądarki?”. Ta różnica to granica między zgadywaniem a właściwym debugowaniem.