Nowy test origin Soft Navigations

Barry Pollard
Michal Mocny

Data publikacji: 31 lipca 2025 r.

W Chrome 139 rozpoczynamy nowe testowanie origin interfejsu Soft Navigations API, który testowaliśmy już wcześniej. Ten okres próbny origin umożliwia witrynom wypróbowanie interfejsu API w witrynie z udziałem prawdziwych użytkowników, aby przetestować go w praktyce i przekazać zespołowi Chrome opinię.

Czym są miękkie nawigacje?

Miękka nawigacja to sytuacja, w której kod JavaScript przechwytuje nawigację (np. kliknięcie linku) i aktualizuje treść na istniejącej stronie, zamiast wczytywać nową stronę. Następnie adres URL jest aktualizowany na pasku adresu (ze stanem historii, który umożliwia miękką nawigację do przodu i do tyłu). Dla użytkownika wyglądają one tak samo jak zwykłe nawigacje, ale z punktu widzenia przeglądarki strona jest nadal stroną oryginalną.

Dlaczego potrzebny jest interfejs Soft Navigation API

Soft Navigations API to proponowany interfejs API, który umożliwia heurystyczne wykrywanie tzw. „miękkich nawigacji” używanych przez witryny typu Single Page Application (SPA). W przypadku miękkiej nawigacji nie dochodzi do rzeczywistej nawigacji na stronie, co oznacza, że niektóre działania, które zwykle mają miejsce podczas nawigacji, muszą być zarządzane ręcznie przez JavaScript. Niektóre działania, takie jak zarządzanie historią nawigacji, są możliwe w przypadku obecnych interfejsów API. Jednak inne działania, takie jak pomiar Core Web Vitals, nie są możliwe w przypadku tych nawigacji.

Interfejs Soft Navigation API umożliwia obserwowanie miękkich nawigacji. Kod JavaScript inicjujący miękką nawigację (zwykle platforma JavaScript) wie, kiedy następuje nawigacja, ale inne skrypty JavaScript i sama przeglądarka nie będą o tym wiedzieć.

Core Web Vitals i aplikacje SPA

Jednym z głównych powodów wprowadzenia interfejsu Soft Navigation API jest umożliwienie pomiaru Core Web Vitals w przypadku aplikacji SPA. Core Web Vitals są mierzone zarówno przez przeglądarkę (aby wyświetlać je w narzędziach, takich jak Raport na temat użytkowania Chrome), jak i przez biblioteki JavaScript do monitorowania rzeczywistych użytkowników (RUM).

Frameworki JavaScript mogą mierzyć niektóre aspekty Core Web Vitals. W szczególności interakcja do kolejnego wyrenderowania (INP) i skumulowane przesunięcie układu (CLS) są oparte na elementach podstawowych (odpowiednio interfejsie Event Timing API i interfejsie Layout Instability API), które można mierzyć w dowolnym przedziale czasu, aby obliczyć wartości INP i CLS. Jednak przeglądarka raportuje i finalizuje największe wyrenderowanie treści (LCP) na podstawie nawigacji i interakcji na stronie, więc platformy JavaScript nie mają wglądu w nic poza początkową wydajnością wczytywania w przypadku aplikacji SPA.

Jak interfejs Soft Navigation API umożliwia pomiar Core Web Vitals w przypadku aplikacji SPA

Pierwsza wersja interfejsu Soft Navigation API łączyła heurystykę miękkiej nawigacji z resetowaniem LCP. Po zresetowaniu LCP można ponownie emitować w przypadku miękkich nawigacji dla nowego malowania z treścią, co umożliwia pomiar tego wskaźnika w przypadku miękkich nawigacji.

W najnowszej wersji zastosowano inne podejście i rozdzielono te pojęcia na interfejs Soft Navigation API i nowy wpis dotyczący wydajności Interakcja do wyrenderowania treści. Wpis interaction-contentful-paint mierzy „wyrenderowanie treści” po interakcjach. Obecnie jest on emitowany tylko w przypadku łagodnych nawigacji, ale jeśli zostanie włączony w przypadku wszystkich interakcji, otworzy to inne potencjalne zastosowania poza LCP.

API rozszerzył też każdy z wpisów dotyczących wydajności largest-contentful-paint, interaction-contentful-paint, event-timing i layout-shift, aby uwzględnić identyfikator nawigacji, której dotyczy wpis. Wpisy dotyczące wydajności są wysyłane po zdarzeniu, które mierzą – zwykle w czasie bezczynności. Oznacza to, że w momencie wygenerowania wpisu o wydajności adres URL często będzie już zmieniony. Uwzględnienie nawigacji w pozycji wejścia znacznie ułatwia pomiar Core Web Vitals dla danego adresu URL bez konieczności dopasowywania czasów pozycji wejścia dotyczących wydajności do czasów pozycji wejścia dotyczących miękkiej nawigacji.

Dlaczego heurystyka?

Interfejs Soft Navigation API uznaje miękką nawigację, gdy:

  • wystąpi interakcja użytkownika (aktualizacje adresu URL bez interakcji użytkownika nie są uwzględniane);
  • … co powoduje modyfikację DOM i renderowanie.
  • … i nastąpi aktualizacja adresu URL.
  • Aktualizacja adresu URL, w tym zmiana historii.

Interfejs API korzysta z tego podejścia opartego na heurystyce, zamiast zezwalać na „emitowanie” przez platformę JavaScript nawigacji tymczasowej lub na tworzenie jej na podstawie interfejsu Navigation API. Dzięki temu można spójnie określać, co stanowi nawigację tymczasową, niezależnie od platformy lub sposobu jej używania przez dewelopera.

Platformy lub deweloperzy mogą aktualizować adres URL w przypadku miękkiej nawigacji nawet bez interakcji użytkownika lub aktualizacji DOM, które uznalibyśmy za nawigację. Mogą też aktualizować adres URL w różnych momentach – na początku interakcji, dopiero na końcu, gdy jest ona zakończona, lub w dowolnym momencie pomiędzy tymi stanami.

Zamiast polegać na wyborach platformy, wbudowanie wykrywania miękkiej nawigacji w przeglądarce tworzy kanoniczne „heurystyki” (z Twoimi opiniami z tego testu origin), które pozwolą nam mierzyć Core Web Vitals w przypadku miękkiej nawigacji na dużą skalę i sprawiać, że takie pomiary będą porównywalne na dużą skalę.

Platformy i programiści mogą też ignorować heurystyki interfejsu Soft Navigations API i używać interfejsów Event Timing, Layout Instability i Interaction to Contentful Paint do pomiaru dodatkowych wskaźników wydajności, ale zalecamy korzystanie z Core Web Vitals za pomocą heurystyki, aby umożliwić pomiary w różnych witrynach.

Pomoc dotycząca testowania interfejsu Soft Navigation API

Potrzebujemy pomocy w testowaniu interfejsu Soft Navigations API, aby sprawdzić, czy heurystyka prawidłowo spełnia Twoje oczekiwania co do tego, kiedy następuje miękka nawigacja. Czy zdarzają się sytuacje, w których interfejs API nie zgłasza miękkich nawigacji, mimo że Twoim zdaniem wystąpiły? Czy API zgłasza powtarzające się nawigacje, które nie są przez Ciebie uznawane za nawigacje miękkie?

Przykłady, które powodują problemy, to aktualizacja adresu URL za pomocą replaceState zamiast dodania historii lub nawigacja, która nie jest inicjowana przez użytkownika (np. wylogowanie po upływie limitu czasu). W obu przypadkach nie pasują one do heurystyki, a zespół Chrome nie widzi potrzeby ich uwzględniania. Chcemy jednak poznać opinię deweloperów stron internetowych. Szczególnie zależy nam na przypadkach, w których heurystyka wydaje się spełniona, ale interfejs API nadal nie rozpoznaje miękkiej nawigacji.

Chcemy też sprawdzić, czy ten interfejs API i nowy element pierwotny interakcji do wyrenderowania treści rozwiązują główny przypadek użycia, czyli umożliwiają pomiar Core Web Vitals w przypadku aplikacji jednostronicowych.

Chcemy, aby interfejs API był jak najbardziej przydatny, a łatwiej to osiągnąć przed jego wprowadzeniem i zanim witryny zaczną polegać na jego implementacji. Dlatego prosimy deweloperów aplikacji SPA i osoby zainteresowane pomiarami wydajności tych witryn o wypróbowanie tego interfejsu API i przesłanie nam opinii na jego temat.

Jak przeprowadzić test

Interfejs API można testować lokalnie za pomocą flag Chrome lub opcji wiersza poleceń. Można ją też przetestować w terenie w ramach testowania origin.

Więcej szczegółów technicznych dotyczących interfejsu API, a w szczególności sposób pomiaru Core Web Vitals, znajdziesz w naszej dokumentacji lub w repozytorium GitHub. Dostępna jest też eksperymentalna wersja biblioteki web-vitals z miękką nawigacją.

Prześlij opinię

Aktywnie zbieramy opinie na temat tego eksperymentu w tych miejscach:

Jeśli masz wątpliwości, nie martw się zbytnio. Wolimy otrzymać opinię w jednym z tych miejsc. Z przyjemnością przeanalizujemy problemy w obu miejscach i przekierujemy je do właściwej lokalizacji.