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 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 pozostaje stroną oryginalną.
Dlaczego potrzebny jest interfejs Soft Navigation API
Soft Navigations API to proponowany interfejs API, który umożliwia wykrywanie na podstawie heurystyki tzw. „miękkich nawigacji” używanych przez witryny SPA (Single Page Application). W przypadku miękkiej nawigacji nie dochodzi do rzeczywistego przejścia na inną stronę, 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 podstawowych wskaźników internetowych, 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 framework JavaScript) wie, kiedy następuje nawigacja, ale inne skrypty JavaScript i sama przeglądarka nie mają tej świadomości.
Podstawowe wskaźniki internetowe i aplikacje SPA
Jednym z głównych powodów wprowadzenia interfejsu Soft Navigation API jest umożliwienie pomiaru podstawowych wskaźników internetowych w przypadku aplikacji SPA. Podstawowe wskaźniki internetowe 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 podstawowych wskaźników internetowych. 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ć wskaźniki INP i CLS. 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 Soft Navigation API umożliwia pomiar podstawowych wskaźników internetowych w przypadku aplikacji SPA
Pierwsza iteracja interfejsu Soft Navigation API łączyła heurystykę miękkiej nawigacji z resetowaniem LCP. Po zresetowaniu wartość LCP może zostać ponownie wyemitowana w przypadku miękkich nawigacji dla nowego malowania z treścią, co umożliwia pomiar tego wskaźnika w przypadku miękkich nawigacji.
Ta najnowsza wersja wykorzystuje inne podejście i rozdziela te koncepcje na interfejs Soft Navigation API i nowy wpis dotyczący skutecznoś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 dotyczącego wydajności adres URL często będzie już zmieniony. Uwzględnienie nawigacji w pozycji ułatwia pomiar podstawowych wskaźników internetowych dla danego adresu URL bez konieczności dopasowywania czasów pozycji dotyczących wydajności do czasów pozycji dotyczących miękkiej nawigacji.
Dlaczego heurystyka?
Interfejs Soft Navigation API uznaje miękką nawigację, gdy:
- nastą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 framework 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 frameworka lub sposobu, w jaki deweloper go używa.
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 frameworka, wbudowanie wykrywania miękkiej nawigacji w przeglądarce tworzy kanoniczne „heurystyki” (z Twoimi opiniami z tego testu pochodzenia), które pozwolą nam mierzyć podstawowe wskaźniki internetowe 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ć heurystykę interfejsu Soft Navigations API i używać interfejsów Event Timing, Layout Instability i Interaction to Contentful Paint API do pomiaru dodatkowych wskaźników wydajności w dowolny sposób, ale zalecamy korzystanie z Core Web Vitals za pomocą heurystyki, aby umożliwić pomiary na różnych stronach.
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 problem, czyli umożliwiają pomiar podstawowych wskaźników internetowych w przypadku aplikacji jednostronicowych.
Chcemy, aby interfejs API był jak najbardziej przydatny, a to jest znacznie łatwiejsze do osiągnięcia przed jego wprowadzeniem 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 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 sposobu pomiaru podstawowych wskaźników internetowych, 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:
- Opinie na temat interfejsu API należy zgłaszać jako problemy w GitHub.
- Błędy w implementacji Chromium należy zgłaszać w narzędziu do śledzenia problemów w Chrome, jeśli nie należą jeszcze do znanych problemów.
- Ogólne opinie na temat Core Web Vitals można przesyłać na adres web-vitals-feedback@googlegroups.com.
Jeśli masz wątpliwości, nie martw się zbytnio. Wolimy otrzymać opinię w jednym z tych miejsc. Z przyjemnością zajmiemy się problemami w obu miejscach i przekierujemy je do właściwej lokalizacji.