Wymiar CoreDash: Navigation Type

Wymiar: Navigation Type (nt)

Każde wyświetlenie strony w danych CrUX niesie ze sobą typ nawigacji. Mówi on o tym, jak przeglądarka załadowała stronę, co określa, które systemy przeglądarki były zaangażowane: stos sieciowy, back/forward cache, pipeline prerender lub przywracanie sesji. CoreDash udostępnia to jako wymiar nt, dzięki czemu można filtrować i porównywać Core Web Vitals oddzielnie dla każdego kontekstu nawigacji.

Dane pochodzą z PerformanceNavigationTiming API, a konkretnie z właściwości type. Odczytuje się ją za pomocą performance.getEntriesByType("navigation")[0].type. Chrome raportuje tę wartość wraz z każdym pomiarem web vitals wysyłanym do CrUX, a CoreDash przechowuje ją i indeksuje, umożliwiając segmentację bez konieczności pisania własnej instrumentacji.

Dlaczego Navigation Type ma znaczenie

Agregowanie LCP lub INP dla wszystkich typów nawigacji daje wynik, który jest technicznie poprawny, ale w praktyce mylący. Trafienie w back/forward cache kończy się w milisekundach. Nawigacja „na zimno” czeka na DNS, TCP, TLS i TTFB. Jeśli 20% sesji to trafienia w bfcache, obniżają one p75 LCP i utrudniają dostrzeżenie realnego problemu przy świeżych nawigacjach.

Odwrotna sytuacja również jest prawdziwa. Jeśli bfcache na Twojej stronie nie działa, sesje back/forward będą miały tak samo słabe wyniki jak świeże nawigacje. Bez segmentacji według typu nawigacji nigdy tego nie zauważysz, ponieważ agregat pozostanie stabilny.

Prerender to najbardziej spektakularny przypadek. Poprawnie wyrenderowana wstępnie strona (prerendered) powinna wykazywać LCP bliskie zeru, ponieważ renderowanie zakończyło się, zanim użytkownik w ogóle kliknął link. Jeśli strony z prerender wykazują normalne liczby LCP, konfiguracja Speculation Rules jest błędna, a prerender albo nie jest wyzwalany, albo zostaje odrzucony przed użyciem.

Typy nawigacji

navigate

Standardowa nawigacja: użytkownik wpisał URL, kliknął link z innej strony lub przeszedł przez przekierowanie. Jest to pełne ładowanie strony bez skrótów związanych z buforowaniem. Przeglądarka przechodzi przez pełny pipeline żądań, w tym wyszukiwanie DNS, nawiązywanie połączenia i pełne ładowanie zasobów. W danych CoreDash navigate odpowiada za około 65% sesji. To Twój punkt odniesienia (baseline). Każdy inny typ nawigacji powinien być oceniany w porównaniu do 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 zbuforowanych zasobów, co oznacza, że TTFB często wygląda gorzej niż przy zwykłej nawigacji, mimo że użytkownik jest na tej samej stronie. Jeśli TTFB dla reload jest drastycznie wyższe niż dla navigate, Twoje nagłówki cache wymuszają rewalidację przy każdym odświeżeniu zamiast serwować nieaktualną treść. W typowym ruchu CoreDash około 10% sesji to odświeżenia.

back_forward

Użytkownik nacisnął przycisk wstecz lub dalej w przeglądarce. Jeśli back/forward cache (bfcache) działa, jest to najszybszy możliwy typ nawigacji. Przeglądarka przywraca stronę z pamięci bez żadnych żądań sieciowych. LCP dla trafienia w bfcache to w rzeczywistości czas malowania (paint) z pamięci, który jest prawie natychmiastowy.

Jeśli Twoje metryki back_forward wyglądają podobnie do navigate, bfcache nie działa. Najczęstsze przyczyny to handlery zdarzeń unload, nagłówki odpowiedzi Cache-Control: no-store oraz otwarte połączenia IndexedDB, które nie zostały zamknięte przed nawigacją. Dane CoreDash wskazują, że back/forward to około 20% sesji, co czyni to poprawką o dużym znaczeniu.

prerender

Strona została załadowana w tle przy użyciu Speculation Rules API zanim użytkownik kliknął link. Gdy użytkownik kliknie, wstępnie wyrenderowany dokument jest aktywowany natychmiast. LCP for poprawnie aktywowanego prerender jest bliskie zeru, ponieważ wszystkie prace związane z renderowaniem zakończyły się przed zdarzeniem nawigacji.

Jeśli LCP dla prerender wygląda normalnie, wydarzyła się jedna z trzech rzeczy: prerender został odrzucony przed aktywacją, reguła spekulacji celowała w złe adresy URL lub strona używa nagłówków lub JavaScript, które uniemożliwiają prerendering. Około 3% sesji CoreDash to aktywacje prerender, ale ten udział szybko rośnie po wdrożeniu Speculation Rules.

restore

Karta została przywrócona po zamknięciu przeglądarki lub awarii karty. Przeglądarka ładuje stronę od zera, ale sesja jest uważana za przywrócenie (restore), a nie za nową nawigację. Wydajność jest podobna do nawigacji „na zimno”. Stanowi to około 2% sesji i rzadko jest głównym celem optymalizacji, ale warto to monitorować, jeśli masz użytkowników z niestabilnymi sesjami przeglądarki.

Workflow debugowania

1. Porównaj LCP dla navigate z ogólnym celem LCP. To Twoja prawda o wydajności świeżego ładowania. Jeśli navigate mieści się w normie, problem leży gdzie indziej.
2. Sprawdź back_forward względem navigate. Jeśli są zbliżone, bfcache nie działa. Otwórz Chrome DevTools, przejdź do panelu Application i uruchom test bfcache. DevTools wskaże dokładnie, które funkcje lub nagłówki blokują możliwość korzystania z bfcache.
3. Sprawdź LCP dla prerender. Jeśli przekracza 200ms, pipeline prerender nie dowozi wyników. Sprawdź, czy JSON Speculation Rules jest poprawny, czy docelowe strony nie zwracają żadnej logiki blokującej i potwierdź aktywacje w Chrome DevTools w sekcji Speculation Rules.

Inżynierska zasada kciuka

• navigate: Powinien spełniać próg LCP dzięki normalnej optymalizacji: szybki TTFB, fetchpriority="high" dla obrazu LCP, brak zasobów blokujących renderowanie.
• back_forward: Powinien być 10 do 20 razy szybszy niż navigate. Jeśli nie jest, bfcache jest uszkodzony.
• prerender: Powinien wykazywać LCP poniżej 200ms. Jeśli nie, Twoje Speculation Rules są błędnie skonfigurowane.
• reload: TTFB nie powinien być drastycznie gorszy niż przy navigate. Jeśli jest, popraw nagłówki rewalidacji cache.

Navigation Type to wymiar, który oddziela pytanie „jak działa moja strona?” od „jak działa moja strona w ramach każdej strategii ładowania przeglądarki?”. To rozróżnienie stanowi różnicę między zgadywaniem a debugowaniem.