Ostatnia wersja próbna origin miękkich nawigacji rozpocznie się w Chrome 147

Barry Pollard
Michal Mocny

Data publikacji: 20 kwietnia 2026 r.

Chrome planuje wprowadzić jeszcze w tym roku interfejs Soft Navigations API, który wcześniej testowaliśmy. W ramach przygotowań do tego wydarzenia oferujemy jeszcze jedną wersję próbną origin, która będzie dostępna od Chrome 147 do Chrome 149. Ten okres próbny uwzględnia opinie z poprzednich okresów próbnych, aby interfejs API miał oczekiwany kształt końcowy. Zachęcamy właścicieli witryn zainteresowanych tą funkcją do przeprowadzenia ostatecznego testu oczekiwanego kształtu interfejsu API przed jego udostępnieniem.

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ę, a adres URL jest nadal aktualizowany na pasku adresu. Dla użytkowników wyglądają one tak samo jak tradycyjne nawigacje, ale z perspektywy przeglądarki strona pozostaje stroną oryginalną.

Potrzeba interfejsu Soft Navigation API

Soft Navigations API to proponowany interfejs API do wykrywania miękkich nawigacji, z których korzystają witryny typu Single Page Application (SPA). W przypadku miękkiej nawigacji nie następuje rzeczywista nawigacja na stronie, więc JavaScript musi ręcznie zarządzać niektórymi działaniami, które zwykle są wykonywane podczas nawigacji. 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. Chociaż kod JavaScript, który inicjuje miękką nawigację (zwykle jest to platforma JavaScript), wie, kiedy następuje nawigacja, inne skrypty JavaScript używane przez witrynę (np. skrypty analityczne) 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 pojawiały się w narzędziach takich jak Raport na temat użytkowania Chrome), jak i przez właścicieli witryn za pomocą rozwiązań do monitorowania rzeczywistych użytkowników (RUM).

Frameworki JavaScript mogą mierzyć niektóre aspekty Core Web Vitals w przypadku aplikacji SPA. 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ć te dane. Jednak inne dane, takie jak największe wyrenderowanie treści (LCP), są wysyłane tylko przez przeglądarkę na podstawie nawigacji po stronie i są finalizowane po interakcji.

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

Interfejs Soft Navigation API wprowadza 2 nowe wpisy dotyczące wydajności:

  • SoftNavigationEntryWpis, który jest emitowany, gdy spełnione są wszystkie wymagania dotyczące miękkiej nawigacji. Obejmuje to interactionId interakcji, która spowodowała miękką nawigację, unikalny navigationId i name ustawiony na nowy adres URL oraz różne czasy renderowania, które można wykorzystać do pomiaru pierwszego wyrenderowania treści w przypadku miękkiej nawigacji.
  • InteractionContentfulPaintWpis, który umożliwia pomiar wielu wyrenderowań treści o coraz większym rozmiarze po interakcjach, aby mierzyć LCP w przypadku miękkich nawigacji.

Nowe wpisy można obserwować za pomocą interfejsu PerformanceObserver, używając odpowiednio typów soft-navigation i interaction-contentful-paint.

Interfejs API rozwija też każdy z wpisów dotyczących wydajności largest-contentful-paint, interaction-contentful-paint, event-timing i layout-shift (oraz innych), aby uwzględnić identyfikator navigationId, który reprezentuje nawigację, której dotyczy wpis. Ponieważ PerformanceObserver nie obserwują wpisów dotyczących wydajności, dopóki strona nie jest bezczynna, może upłynąć trochę czasu między zdarzeniem, które utworzyło wpis dotyczący wydajności, a jego obserwacją. Jest to szczególnie ważne, gdy strona jest bardzo obciążona, np. podczas miękkiej nawigacji. Ta wartość navigationId pomaga przypisywać wpisy do odpowiedniej nawigacji.

Niektóre wpisy interaction-contentful-paint mogą pojawić się przed nawigacją, a niektóre po niej. Zamiast śledzić wszystkie wyrenderowania, które mogą spowodować miękką nawigację, wpis soft-navigation zawiera wpis largestInteractionContentfulPaint, który jest największym wyrenderowaniem widocznym do tego momentu.

Umożliwiają one pomiar Core Web Vitals w przypadku:

  • LCP używa largest-contentful-paint do początkowego wczytywania strony oraz nowych wpisów interaction-contentful-paint i soft-navigation do miękkiej nawigacji.
  • CLS za pomocą wpisów layout-shift i dzielenia ich na podstawie wpisów soft-navigation w przypadku miękkich nawigacji.
  • INP: korzystanie z wpisów event i dzielenie ich na podstawie wpisów soft-navigation w przypadku miękkich nawigacji.
  • FCP używa first-contentful-paint do początkowego wczytywania strony i szczegółów czasu renderowania w nowych wpisach soft-navigation w przypadku miękkiej nawigacji.

Więcej informacji znajdziesz w dokumentacji dotyczącej miękkich nawigacji.

Jak są wywoływane miękkie nawigacje?

Interfejs Soft Navigation API wywołuje miękką nawigację, gdy:

  • nastąpi interakcja użytkownika,
  • … co powoduje widoczne wyrenderowanie treści dla użytkownika.
  • … i następuje aktualizacja adresu URL.

Interfejs API stosuje to podejście zamiast zezwalać na „emitowanie” przez platformę JavaScript miękkiej nawigacji lub korzystać z interfejsu Navigation API z 2 powodów:

  1. Po pierwsze, obejmuje to wszystkie dotychczasowe witryny SPA bez konieczności wprowadzania w nich zmian.
  2. Po drugie, umożliwia spójne rozumienie, co stanowi miękką nawigację, niezależnie od tego, jak framework lub deweloper obsługuje nawigację.

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

Zamiast polegać na wyborach platformy i dewelopera, wbudowanie wykrywania miękkiej nawigacji w przeglądarce tworzy kanoniczną definicję, która umożliwia pomiar Core Web Vitals w przypadku miękkiej nawigacji na dużą skalę i sprawia, że te pomiary są porównywalne na dużą skalę.

Platformy i programiści mogą też zignorować interfejs Soft Navigations API i używać interfejsów Event Timing API, Layout Instability API oraz nowego wpisu InteractionContentfulPaint performance do pomiaru dodatkowych danych o skuteczności w dowolny sposób. Zalecamy jednak używanie interfejsu API do pomiaru Core Web Vitals, aby umożliwić spójne pomiary w różnych witrynach i narzędziach.

Pomoc dotycząca testowania interfejsu Soft Navigation API

Potrzebujemy Twojej pomocy w testowaniu interfejsu Soft Navigations API i określeniu, czy prawidłowo spełnia Twoje oczekiwania dotyczące tego, kiedy występuje miękka nawigacja. Czy interfejs API nie zgłasza miękkich nawigacji, gdy Twoim zdaniem wystąpiły? Czy interfejs API zgłasza zbyt wiele nawigacji, które nie są przez Ciebie uznawane za nawigacje?

Co się zmieniło od ostatniego testu origin

Główną zmianą w tej najnowszej wersji jest oddzielenie InteractionContentfulPaint od miękkich nawigacji, aby umożliwić inne zastosowania tego wpisu dotyczącego wydajności, oraz dodanie atrybutu largestInteractionContentfulPaint do SoftNavigationEntry.

Z perspektywy witryny interfejs API uwzględnia teraz też replaceState jako miękkie nawigacje, ponieważ zgodnie z Waszymi opiniami w wielu przypadkach warto traktować je jako nawigację. Chętnie poznamy inne przypadki, w których interfejs API nie rozpoznaje miękkiej nawigacji.

Wprowadziliśmy też niezliczone inne ulepszenia w implementacji. Jeśli chcesz dowiedzieć się, co dokładnie zmieniło się w najnowszej wersji, szczegółową historię wszystkich zmian znajdziesz w dzienniku zmian dotyczących miękkiej nawigacji.

Chcemy, aby interfejs API był jak najbardziej przydatny, i jesteśmy otwarci na dalsze zmiany, które to umożliwią. Zmiany w interfejsie API łatwiej jest wprowadzać przed jego uruchomieniem i zanim witryny zaczną zależeć od jego wdrożenia. Dlatego prosimy deweloperów aplikacji SPA i osoby zainteresowane pomiarami wydajności tych witryn o przetestowanie tego interfejsu API i przesłanie opinii na jego temat.

Jak przeprowadzić test

Interfejs API można testować lokalnie za pomocą flag Chrome lub opcji wiersza poleceń. Możesz też przetestować ją w terenie w ramach testowania origin (więcej informacji o testowaniu origin).

Więcej szczegółów technicznych dotyczących interfejsu API, a zwłaszcza sposobu pomiaru Core Web Vitals, znajdziesz w naszej dokumentacji lub w repozytorium GitHub.

Dodatkowo na GitHubie i w npm dostępna jest eksperymentalna wersja biblioteki web-vitals z miękką nawigacją.

Aby przeprowadzić prostszy test, w panelu Wydajność w Narzędziach deweloperskich w Chrome od wersji 145 wyświetlane są ślady wydajności dotyczące miękkiej nawigacji, nawet jeśli ta funkcja nie jest włączona:

W panelu Wydajność znajduje się znacznik nawigacji programowej ze śladem z youtube.com.

Prześlij opinię

Opinie o interfejsie API należy zgłaszać jako problemy w GitHubie, a błędy w implementacji Chromium – w narzędziu do śledzenia problemów w Chrome. Jeśli nie masz pewności, do której kategorii należy opinia, nie przejmuj się tym. Wolimy otrzymywać opinie w obu tych miejscach. Będziemy je tam analizować i przekierowywać do odpowiednich zespołów.