Eksperymentowanie z pomiarami poręcznej nawigacji

Barry Pollard

Michal Mocny

Data publikacji: 1 lutego 2023 r., ostatnia aktualizacja: 15 września 2025 r.

Od początku inicjatywa Podstawowe wskaźniki internetowe ma na celu pomiar rzeczywistych wrażeń użytkowników witryny, a nie szczegółów technicznych związanych z jej tworzeniem lub wczytywaniem. 3 podstawowe wskaźniki internetowe zostały opracowane jako dane zorientowane na użytkownika. Stanowią one ewolucję dotychczasowych danych technicznych, takich jak DOMContentLoaded czy load, które mierzyły czasy często niezwiązane z tym, jak użytkownicy postrzegali wydajność strony. Dlatego technologia użyta do utworzenia witryny nie powinna wpływać na ocenę, o ile witryna działa prawidłowo.

Rzeczywistość jest jednak nieco bardziej skomplikowana niż ideał, a popularna architektura aplikacji jednostronicowych nigdy nie była w pełni obsługiwana przez wskaźniki Core Web Vitals. Zamiast wczytywać różne, pojedyncze strony internetowe, gdy użytkownik porusza się po witrynie, te aplikacje internetowe używają tzw. „miękkiej nawigacji”, w której zawartość strony jest zmieniana przez JavaScript. W tych aplikacjach iluzja tradycyjnej architektury strony internetowej jest utrzymywana przez zmianę adresu URL i przesyłanie poprzednich adresów URL do historii przeglądarki, aby przyciski Wstecz i Dalej działały zgodnie z oczekiwaniami użytkownika.

Wiele platform JavaScriptu korzysta z tego modelu, ale każda na inny sposób. Ponieważ wykracza to poza to, co przeglądarka tradycyjnie rozumie jako „stronę”, pomiar tego zjawiska zawsze był trudny: gdzie należy wyznaczyć granicę między interakcją na bieżącej stronie a uznaniem jej za nową stronę?

Zespół Chrome od jakiegoś czasu zastanawia się nad tym problemem i chce ustandaryzować definicję „miękkiej nawigacji” oraz sposób pomiaru podstawowych wskaźników internetowych w jej przypadku – podobnie jak w przypadku witryn z tradycyjną architekturą wielostronicową (MPA).

Od czasu ostatniego testu pochodzenia intensywnie pracowaliśmy nad ulepszeniem interfejsu API. Teraz prosimy deweloperów o wypróbowanie najnowszej wersji i przesłanie opinii na temat tego podejścia przed jego wdrożeniem.

Co to jest miękka nawigacja?

Oto definicja miękkiej nawigacji:

• Nawigacja jest inicjowana przez działanie użytkownika.
• W wyniku nawigacji adres URL widoczny dla użytkownika ulega zmianie, a historia zostaje zaktualizowana.
• Nawigacja powoduje zmianę DOM.

W przypadku niektórych witryn te heurystyki mogą prowadzić do wyników fałszywie pozytywnych (użytkownicy nie uznaliby, że nastąpiła „nawigacja”) lub fałszywie negatywnych (użytkownicy uznaliby, że nastąpiła „nawigacja”, mimo że nie spełnia ona tych kryteriów). Chętnie poznamy Twoją opinię na temat heurystyki w repozytorium specyfikacji miękkiej nawigacji.

Jak Chrome implementuje miękkie nawigacje?

Po włączeniu heurystyki miękkiej nawigacji (więcej informacji w następnej sekcji) Chrome zmieni sposób raportowania niektórych danych o wydajności:

• Po wykryciu każdego miękkiego przejścia zostanie wyemitowane zdarzenie soft-navigation PerformanceTiming.
• Po interakcjach, które powodują znaczące renderowanie, zostanie wyemitowany nowy interaction-contentful-paint. Można go używać do pomiaru największego wyrenderowania treści (LCP) w przypadku miękkiej nawigacji, gdy takie wyrenderowanie obejmuje miękką nawigację. W pierwotnej implementacji resetowanie powodowało zresetowanie wartości largest-contentful-paint, co umożliwiało ponowne wysłanie tego parametru. Jednak ze względu na prostotę i większe możliwości w przyszłości zdecydowaliśmy się na to alternatywne podejście.
• Do każdego z czasów działania (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event i layout-shift) odpowiadających wpisowi nawigacji, z którym było powiązane zdarzenie, zostanie dodany atrybut navigationId, co umożliwi obliczanie i przypisywanie do prawidłowego adresu URL wskaźników Największe wyrenderowanie treści (LCP), Skumulowane przesunięcie układu (CLS) i Interakcja do następnego wyrenderowania (INP).

Te zmiany umożliwią pomiar podstawowych wskaźników internetowych i niektórych powiązanych z nimi danych diagnostycznych w przypadku każdej nawigacji po stronie, chociaż należy wziąć pod uwagę pewne niuanse.

Jakie są konsekwencje włączenia w Chrome miękkiej nawigacji?

Oto niektóre zmiany, które właściciele witryn muszą wziąć pod uwagę po włączeniu tej funkcji:

• Wartości CLS i INP mogą być dzielone według adresu URL miękkiej nawigacji, a nie mierzone w całym okresie działania strony.
• Wpis largest-contentul-paint jest już sfinalizowany w interakcji, więc służy tylko do pomiaru początkowego „twardego” nawigacyjnego LCP, dlatego nie jest potrzebna żadna dodatkowa logika, aby zmienić sposób jego pomiaru.
• Nowe dane interaction-contentful-paint będą generowane na podstawie interakcji, których można używać do pomiaru LCP w przypadku miękkich nawigacji.
• Aby przypisać miękkie nawigacje do prawidłowego adresu URL, w kodzie aplikacji może być konieczne uwzględnienie nowego atrybutu navigationID w pozycjach dotyczących wydajności.
• Nie wszyscy użytkownicy będą obsługiwać ten interfejs API nawigacji programowej, zwłaszcza w przypadku starszych wersji Chrome i osób korzystających z innych przeglądarek. Pamiętaj, że niektórzy użytkownicy mogą nie raportować wskaźników miękkiej nawigacji, nawet jeśli raportują podstawowe wskaźniki internetowe.
• Jest to nowa funkcja eksperymentalna, która nie jest domyślnie włączona, dlatego witryny powinny ją przetestować pod kątem niepożądanych efektów ubocznych.

Skontaktuj się z dostawcą narzędzia RUM, aby sprawdzić, czy obsługuje ono pomiar podstawowych wskaźników internetowych za pomocą miękkiej nawigacji. Wiele firm planuje przetestować ten nowy standard i weźmie pod uwagę wcześniejsze uwagi. W międzyczasie niektórzy dostawcy umożliwiają też ograniczone pomiary danych o skuteczności na podstawie własnych heurystyk.

Więcej informacji o tym, jak mierzyć wskaźniki w przypadku miękkich nawigacji, znajdziesz w sekcji dotyczącej pomiaru podstawowych wskaźników internetowych w przypadku miękkich nawigacji.

Jak włączyć w Chrome płynne przechodzenie między stronami?

Miękkie nawigacje nie są domyślnie włączone w Chrome, ale można je wypróbować, włączając tę funkcję.

Deweloperzy mogą włączyć tę opcję, ustawiając flagę chrome://flags/#soft-navigation-heuristics. Opcja „Włączono zaawansowaną atrybucję renderowania (wstępne renderowanie z użyciem pamięci podręcznej)” jest zalecana i wkrótce stanie się domyślna. Można ją też włączyć, używając argumentów wiersza poleceń --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution podczas uruchamiania Chrome.

W przypadku witryny, która chce włączyć tę funkcję dla wszystkich odwiedzających, aby sprawdzić jej wpływ, od Chrome 139 będzie dostępny test źródła. Aby go włączyć, należy zarejestrować się w teście i uwzględnić element meta z tokenem testu źródła w nagłówku HTML lub HTTP. Więcej informacji znajdziesz w artykule Pierwsze kroki z testami pochodzenia.

Właściciele witryn mogą włączyć testowanie w ramach programu Origin Trial na swoich stronach dla wszystkich lub tylko dla części użytkowników. Zapoznaj się z sekcją dotyczącą konsekwencji, aby dowiedzieć się, jak ta zmiana może wpłynąć na raportowanie danych, zwłaszcza jeśli włączysz ten okres próbny dla dużej części użytkowników. Pamiętaj, że CrUX będzie nadal raportować dane w dotychczasowy sposób niezależnie od tego ustawienia miękkiej nawigacji, więc nie ma to na niego wpływu. Warto też pamiętać, że testy origin są ograniczone do włączania funkcji eksperymentalnych na maksymalnie 0,5% wszystkich wczytań stron w Chrome jako mediany w ciągu 14 dni, ale powinno to stanowić problem tylko w przypadku bardzo dużych witryn.

Wykrywanie funkcji obsługi interfejsu Soft Navigations API

Aby sprawdzić, czy interfejs API jest obsługiwany, możesz użyć tego kodu:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Pamiętaj, że wartość supportedEntryTypes jest zamrażana przy pierwszym użyciu, więc jeśli obsługa miękkiej nawigacji zostanie dodana dynamicznie przez token testu pochodzenia wstrzyknięty na stronę, może to zwrócić pierwotną wartość sprzed aktywacji tej funkcji.

W takim przypadku możesz użyć poniższej alternatywy, dopóki miękka nawigacja nie będzie domyślnie obsługiwana i będzie w stanie przejściowym:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Jak mogę mierzyć miękkie nawigacje?

Po włączeniu eksperymentu dotyczącego miękkiej nawigacji dane będą raportowane za pomocą interfejsu PerformanceObserver, podobnie jak inne dane. W przypadku tych danych należy jednak wziąć pod uwagę kilka dodatkowych kwestii.

Raportowanie miękkich nawigacji

Aby obserwować miękkie nawigacje, możesz użyć PerformanceObserver. Poniżej znajdziesz przykładowy fragment kodu, który rejestruje w konsoli wpisy dotyczące miękkiej nawigacji, w tym poprzednie miękkie nawigacje na tej stronie, za pomocą opcji buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Możesz użyć tej funkcji, aby sfinalizować dane dotyczące całej strony z poprzedniej nawigacji.

Raportowanie danych w odniesieniu do odpowiedniego adresu URL

Miękkie nawigacje można zobaczyć dopiero po ich wystąpieniu, więc niektóre dane będą musiały zostać sfinalizowane po tym zdarzeniu, a następnie zgłoszone dla poprzedniego adresu URL, ponieważ bieżący adres URL będzie teraz odzwierciedlać zaktualizowany adres URL nowej strony.

Atrybut navigationId odpowiedniego atrybutu PerformanceEntry może służyć do powiązania zdarzenia z prawidłowym adresem URL. Możesz to sprawdzić za pomocą interfejsu API PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Ten pageUrl powinien być używany do raportowania danych dotyczących prawidłowego adresu URL, a nie bieżącego adresu URL, którego reklamodawcy mogli używać w przeszłości.

Uzyskiwanie startTime miękkich przycisków nawigacyjnych

Czas rozpoczęcia nawigacji można uzyskać w podobny sposób:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime to czas pierwszej interakcji (np. kliknięcia przycisku), która zainicjowała miękką nawigację.

Wszystkie czasy wydajności, w tym czasy dotyczące miękkiej nawigacji, są podawane jako czas od początkowej „twardej” nawigacji po stronie. Dlatego czas rozpoczęcia miękkiej nawigacji jest potrzebny do określenia wartości bazowych czasów wczytywania w przypadku miękkiej nawigacji (np. LCP) w odniesieniu do tego czasu.

Pomiar podstawowych wskaźników internetowych w przypadku nawigacji tymczasowej

Aby uwzględnić wpisy danych o miękkiej nawigacji, musisz dodać includeSoftNavigationObservations: true do wywołania observe obserwatora wydajności.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

W związku z najnowszymi zmianami w interfejsie API flaga includeSoftNavigationObservations nie jest już potrzebna i prawdopodobnie zostanie usunięta w przyszłości. Obecnie jednak oprócz włączenia funkcji płynnego przechodzenia w Chrome wymagana jest wyraźna zgoda na poziomie obserwatora wydajności.

Czasy będą nadal zwracane względem pierwotnego czasu rozpoczęcia „twardej” nawigacji. Aby na przykład obliczyć LCP w przypadku miękkiej nawigacji, musisz wziąć czas interaction-contentful-paint i odjąć odpowiedni czas rozpoczęcia miękkiej nawigacji, jak opisano wcześniej, aby uzyskać czas względny w stosunku do miękkiej nawigacji. Na przykład w przypadku LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Niektóre dane były tradycyjnie mierzone przez cały okres istnienia strony. Na przykład LCP może się zmieniać, dopóki nie nastąpi interakcja. Wartości CLS i INP można aktualizować, dopóki użytkownik nie opuści strony. Dlatego każda „nawigacja” (w tym pierwotna) może wymagać sfinalizowania danych poprzedniej strony, gdy następuje nowa nawigacja programowa. Oznacza to, że początkowe „twarde” wskaźniki nawigacji mogą zostać sfinalizowane wcześniej niż zwykle.

Podobnie w przypadku rozpoczęcia pomiaru danych dotyczących nowej nawigacji w ramach tych długotrwałych danych trzeba będzie „zresetować” lub „zainicjować ponownie” dane i traktować je jako nowe dane bez pamięci wartości ustawionych dla poprzednich „stron”.

Jak traktować treści, które pozostają takie same między nawigacjami?

LCP w przypadku miękkich nawigacji (obliczana na podstawie interaction-contentful-paint) będzie mierzyć tylko nowe wyrenderowania. Może to spowodować inną wartość LCP, np. w przypadku przejścia z zimnego ładowania nawigacji programowej na ładowanie programowe.

Weźmy na przykład stronę, która zawiera duży obraz banera będący elementem LCP, ale tekst pod nim zmienia się przy każdej miękkiej nawigacji. Początkowe wczytanie strony oznaczy obraz banera jako element LCP i na tej podstawie określi czas LCP. W przypadku kolejnych miękkich nawigacji największym elementem wyrenderowanym po miękkiej nawigacji będzie tekst poniżej, który stanie się nowym elementem LCP. Jeśli jednak nowa strona zostanie wczytana za pomocą linku bezpośredniego do adresu URL nawigacji programowej, obraz w banerze zostanie narysowany od nowa i dlatego będzie mógł być uznany za element LCP.

Jak widać na tym przykładzie, element LCP w przypadku miękkiej nawigacji może być raportowany inaczej w zależności od sposobu wczytania strony. Podobnie wczytanie strony z linkiem do kotwicy znajdującej się dalej na stronie może spowodować, że element LCP będzie inny.

Jak mierzyć TTFB?

Czas do pierwszego bajta (TTFB) w przypadku zwykłego wczytywania strony to czas, w którym zwracane są pierwsze bajty pierwotnego żądania.

W przypadku nawigacji programowej jest to trudniejsze pytanie. Czy powinniśmy mierzyć pierwsze żądanie wysłane na nową stronę? Co zrobić, jeśli wszystkie treści są już w aplikacji i nie ma dodatkowych próśb? Co się stanie, jeśli żądanie zostanie wysłane z wyprzedzeniem w ramach wstępnego pobierania? Co się stanie, jeśli żądanie nie jest związane z płynną nawigacją z perspektywy użytkownika (np. jest to żądanie analityczne)?

Prostszym sposobem jest zgłaszanie wartości TTFB równej 0 w przypadku miękkiej nawigacji – podobnie jak zalecamy w przypadku przywracania z pamięci podręcznej stanu strony internetowej. Jest to metoda, której web-vitalsbiblioteka używa w przypadku łagodnej nawigacji.

W przyszłości możemy wprowadzić bardziej precyzyjne sposoby określania, które żądanie jest „żądaniem nawigacji” w przypadku miękkiej nawigacji, co pozwoli nam uzyskiwać dokładniejsze pomiary TTFB. Nie jest to jednak częścią obecnego wdrożenia.

Jak mierzyć wyniki w przypadku starych i nowych działań powodujących konwersję?

Podczas tego eksperymentu zalecamy dalsze pomiary podstawowych wskaźników internetowych w dotychczasowy sposób, na podstawie „twardych” nawigacji po stronie, aby dopasować je do pomiarów i raportów CrUX, które będą oficjalnym zbiorem danych w ramach inicjatywy dotyczącej podstawowych wskaźników internetowych.

Miękkie nawigacje powinny być mierzone dodatkowo, aby umożliwić Ci sprawdzenie, jak mogą być mierzone w przyszłości, i dać Ci możliwość przekazania zespołowi Chrome opinii o tym, jak ta implementacja działa w praktyce. Pomoże to Tobie i zespołowi Chrome w dalszym kształtowaniu interfejsu API.

W przypadku LCP oznacza to uwzględnianie tylko wpisów largest-contentful-paint w przypadku starego sposobu oraz wpisów largest-contentful-paint i interaction-contentful-paint w przypadku nowego sposobu.

W przypadku CLS i INP oznacza to pomiar tych wskaźników w całym cyklu życia strony (tak jak w przypadku starego sposobu) oraz oddzielne dzielenie osi czasu według miękkich nawigacji, aby mierzyć osobne wartości CLS i INP dla nowego sposobu.

Używaj biblioteki web-vitals do pomiaru podstawowych wskaźników internetowych w przypadku łagodnych nawigacji

Najłatwiej uwzględnić wszystkie niuanse, korzystając z biblioteki JavaScript web-vitals, która ma eksperymentalną obsługę miękkiej nawigacji w osobnym pakiecie soft-navs branch (dostępnym też w npm i unpkg). Można to zmierzyć w ten sposób (zastępując doTraditionalProcessing i doSoftNavProcessing odpowiednimi wartościami):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Upewnij się, że dane są raportowane w odniesieniu do prawidłowego adresu URL zgodnie z wcześniejszymi informacjami.

Biblioteka web-vitals raportuje te dane dotyczące miękkich nawigacji:

Czy te zmiany staną się częścią pomiarów podstawowych wskaźników internetowych?

Ten eksperyment z miękką nawigacją jest właśnie tym – eksperymentem. Chcemy ocenić te heurystyki i sprawdzić, czy dokładniej odzwierciedlają wrażenia użytkowników, zanim podejmiemy decyzję o ich włączeniu do inicjatywy dotyczącej podstawowych wskaźników internetowych. Bardzo nas cieszy możliwość przeprowadzenia tego eksperymentu, ale nie możemy zagwarantować, czy i kiedy zastąpi on obecne pomiary.

Cenimy opinie deweloperów stron internetowych na temat eksperymentu, użytych w nim heurystyk i tego, czy ich zdaniem lepiej odzwierciedla on wrażenia użytkowników. Najlepszym miejscem na przekazanie opinii jest repozytorium GitHub dotyczące miękkiej nawigacji. Poszczególne błędy w implementacji tej funkcji w Chrome należy zgłaszać w narzędziu do śledzenia problemów w Chrome.

Jak w raporcie CrUX będą zgłaszane miękkie nawigacje?

Jeśli ten eksperyment się powiedzie, sposób raportowania miękkich nawigacji w CrUX nadal będzie wymagać ustalenia. Nie jest pewne, czy będą one traktowane tak samo jak obecne „twarde” nawigacje.

Na niektórych stronach internetowych miękkie nawigacje są niemal identyczne z pełnymi wczytaniami strony z punktu widzenia użytkownika, a korzystanie z technologii aplikacji jednostronicowej jest tylko szczegółem implementacji. W innych przypadkach mogą być bardziej podobne do częściowego wczytywania dodatkowych treści.

Dlatego możemy zdecydować się na oddzielne raportowanie tych miękkich nawigacji w CrUX lub na przypisywanie im wagi podczas obliczania podstawowych wskaźników internetowych dla danej strony lub grupy stron. W miarę rozwoju heurystyki możemy też całkowicie wykluczyć częściowe wczytywanie stron w przypadku miękkiej nawigacji.

Zespół koncentruje się na implementacji heurystycznej i technicznej, która pozwoli nam ocenić powodzenie tego eksperymentu, więc nie podjęto jeszcze żadnej decyzji w tych kwestiach.

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ę. Wolimy otrzymać opinię w jednym z tych miejsc. Z przyjemnością zajmiemy się problemami w obu miejscach i przekierujemy je do odpowiedniej lokalizacji.

Historia zmian

Ten interfejs API jest w fazie eksperymentalnej, więc wprowadzamy w nim wiele zmian, więcej niż w przypadku stabilnych interfejsów API. Więcej informacji znajdziesz w dzienniku zmian dotyczących heurystyki miękkiej nawigacji.

Podsumowanie

Eksperyment dotyczący miękkich nawigacji to interesujące podejście do tego, jak inicjatywa dotycząca podstawowych wskaźników internetowych może ewoluować, aby mierzyć powszechny wzorzec w nowoczesnej sieci, którego brakuje w naszych danych. Ten eksperyment jest jeszcze na wczesnym etapie i wiele jest jeszcze do zrobienia, ale udostępnienie dotychczasowych postępów szerszej społeczności internetowej do eksperymentowania jest ważnym krokiem. Zbieranie opinii w ramach tego eksperymentu jest jego kolejną kluczową częścią, dlatego zachęcamy osoby zainteresowane tym rozwiązaniem do skorzystania z tej możliwości, aby pomóc w kształtowaniu interfejsu API i zapewnić, że będzie on odzwierciedlał to, co chcemy dzięki niemu mierzyć.

Podziękowania

Miniatura: Jordan Madrid, Unsplash

Te prace są kontynuacją działań rozpoczętych przez Yoava Weissa, gdy pracował w Google. Dziękujemy Yoavowi za pracę nad tym interfejsem API.