Eksperymentowanie z pomiarami poręcznej nawigacji

Barry Pollard

Michal Mocny

Data publikacji: 1 lutego 2023 r., ostatnia aktualizacja: 30 marca 2026 r.

Od początku inicjatywa Core Web Vitals ma na celu pomiar rzeczywistych wrażeń użytkowników witryny, a nie szczegółów technicznych związanych z jej tworzeniem lub wczytywaniem. Trzy wskaźniki Core Web Vitals zostały opracowane jako wskaźniki zorientowane na użytkownika, które są rozwinięciem dotychczasowych wskaźników technicznych, takich jak DOMContentLoaded czy load. Te ostatnie mierzyły czasy, które często nie miały związku 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 JavaScript 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 wyzwaniem i chce ustandaryzować definicję „miękkiej nawigacji” oraz sposób pomiaru Core Web Vitals w jej przypadku – podobnie jak w przypadku witryn zaimplementowanych w konwencjonalnej architekturze wielostronicowej (MPA).

Na podstawie opinii deweloperów z ostatniego testowania origin wprowadziliśmy kilka ulepszeń interfejsu API. Teraz prosimy deweloperów o wypróbowanie najnowszej iteracji i przekazanie opinii na temat tego podejścia przed jego wprowadzeniem. Jesteśmy przekonani, że po tych iteracjach interfejs API jest już w odpowiednim miejscu, i planujemy go udostępnić jeszcze w tym roku. Zależy to jednak od opinii na temat najnowszego testowania origin.

Co to jest miękka nawigacja?

Oto definicja miękkiej nawigacji:

• Nawigacja jest inicjowana przez działanie użytkownika.
• W wyniku nawigacji użytkownik widzi zmianę adresu URL.
• Interakcja powoduje widoczne wyrenderowanie.

W przypadku niektórych witryn te heurystyki mogą prowadzić do wyników fałszywie pozytywnych (gdy użytkownicy nie uznają danego działania za „nawigację”) lub fałszywie negatywnych (gdy użytkownicy uznają dane działanie za „nawigację”, mimo że nie spełnia ono tych kryteriów). Zachęcamy do przesyłania opinii na temat heurystyki w repozytorium specyfikacji miękkiej nawigacji.

Obsługa miękkiej nawigacji w Narzędziach deweloperskich

Dodaliśmy obsługę miękkiej nawigacji na panelu Wydajność w Narzędziach deweloperskich w widoku śladu:

Zobaczysz znaczniki miękkich nawigacji i LCP, które są oznaczone symbolem *, aby odróżnić je od zwykłych wpisów dotyczących twardej nawigacji. Ta funkcja jest domyślnie włączona i nie jest powiązana ze zmianami w interfejsie Performance API, o których będziemy mówić w dalszej części. To szybki sposób na sprawdzenie, czy eksperyment z miękką nawigacją działa prawidłowo w Twojej witrynie.

Obecnie w widoku śledzenia wyświetlane są tylko sygnatury czasowe miękkiej nawigacji i LCP. Inne dane (np. LCP) i obsługa w widoku Dane na żywo zostaną dodane później.

Jak Chrome wdraża miękkie nawigacje dla deweloperów stron internetowych?

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

• Po wykryciu każdego miękkiego przejścia zostanie wyemitowane zdarzenie soft-navigation PerformanceTiming.
• Ten wpis soft-navigation będzie zawierać navigationId, nowy adres URL w atrybucie name oraz interactionId interakcji inicjującej.
• Po interakcjach, które powodują wyrenderowanie treści, zostanie wyemitowanych co najmniej 1 wpis interaction-contentful-paint. Można go używać do pomiaru największego wyrenderowania treści (LCP) w przypadku miękkiej nawigacji, gdy interakcja powoduje jej wyemitowanie.
• Atrybut navigationId jest dodawany 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). Odpowiada on wpisowi nawigacji, w którym zostało wyemitowane zdarzenie. Pamiętaj, że jeśli te wpisy obejmują miękkie nawigacje, mogą zawierać poprzedni lub następny element navigationId w zależności od tego, kiedy wpis został wyemitowany. Więcej informacji znajdziesz w sekcji Raportowanie danych w odniesieniu do odpowiedniego adresu URL.
• soft-navigation będzie zawierać wpis largestInteractionContentfulPaint, w którym znajdzie się największy wpis interaction-contentful-paint wyemitowany w ramach nawigacji. Może to być początkowa wartość LCP dla tej nawigacji, która może być aktualizowana w miarę obserwowania kolejnych wpisów interaction-contentful-paint dotyczących tej interakcji.
• Niektóre wpisy interaction-contentful-paint mogą wystąpić przed nawigacją programową (jeśli aktualizacja adresu URL nastąpi dopiero po tych renderowaniach). W takich przypadkach największy wpis largestInteractionContentfulPaint pozwala uniknąć buforowania i przeglądania starych wpisów. Pamiętaj, że largestInteractionContentfulPaint to dokładna kopia największego wpisu interaction-contentful-paint, więc ten wpis będzie używać poprzedniego navigationId, ponieważ wtedy nastąpiło malowanie, ale te malowania powinny być mierzone względem nowego navigationId.
• Wpis soft-navigation będzie też zawierać wartości paintTime i presentationTime jako FCP dla tej nawigacji.
• Pamiętaj, że po dalszych interakcjach będą też emitowane wpisy interaction-contentful-paint, ale LCP dla adresu URL powinien być ograniczony do wpisów interaction-contentful-paint, które pasują do miękkich nawigacji interactionId, aby je wykluczyć.

Te zmiany umożliwią pomiar Core Web Vitals—i niektórych powiązanych z nimi danych diagnostycznych—w przypadku każdej nawigacji na 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:

• Monitorowanie wpisów soft-navigation umożliwia „dzielenie” wpisów dotyczących skuteczności na poszczególne „nawigacje”.
• Wskaźniki CLS i INP można już dzielić według własnego uznania, zamiast mierzyć je w całym cyklu życia strony. Interfejs Soft Navigation API zapewnia jednak standardowy pomiar tego, kiedy to następuje, niezależnie od użytej technologii bazowej.
• Wpis largest-contentful-paint jest finalizowany podczas interakcji (która jest niezbędna do rozpoczęcia nawigacji miękkiej), więc można go używać tylko do pomiaru początkowego „twardego” LCP nawigacji. Oznacza to, że nie zmieni się on podczas pomiaru miękkich nawigacji, dzięki czemu LCP w przypadku początkowego, twardego wczytania strony będzie można mierzyć tak jak dotychczas.
• Nowy wpis interaction-contentful-paint, który będzie generowany na podstawie interakcji, może służyć do pomiaru LCP w przypadku miękkich nawigacji, ale istnieją pewne kwestie dotyczące sposobu korzystania z tego wpisu, które omówimy w tym artykule.
• Pamiętaj, że nie wszyscy użytkownicy będą obsługiwać ten interfejs API miękkiej nawigacji, 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 opartych na miękkiej nawigacji, nawet jeśli raportują Core Web Vitals.
• Jest to nowa funkcja eksperymentalna, która nie jest domyślnie włączona, dlatego witryny powinny ją przetestować pod kątem niepożądanych skutków ubocznych.

Skontaktuj się z dostawcą narzędzia RUM, aby sprawdzić, czy obsługuje ono pomiar Core Web Vitals 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 Core Web Vitals 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. Można ją też włączyć, używając argumentów wiersza poleceń --enable-features=SoftNavigationHeuristics podczas uruchamiania Chrome. Włączenie flagi chrome://flags/#enable-experimental-web-platform-features powoduje też włączenie miękkiej nawigacji.

W przypadku witryny, która chce włączyć tę funkcję, aby wszyscy odwiedzający mogli zobaczyć jej wpływ, od Chrome 147 będzie prowadzona wersja próbna origin. Można ją włączyć, rejestrując się w niej i dodając element meta z tokenem wersji próbnej origin w kodzie HTML lub nagłówku HTTP. Więcej informacji znajdziesz w artykule Pierwsze kroki z testami pochodzenia.

Właściciele witryn mogą włączyć testowanie origin na swoich stronach dla wszystkich lub tylko dla niektórych użytkowników. Zapoznaj się z sekcją dotyczącą konsekwencji, aby dowiedzieć się, jak ta zmiana może wpłynąć na raportowanie wskaźników, zwłaszcza jeśli włączysz ten okres próbny origin 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 z 14 dni, ale powinno to stanowić problem tylko w przypadku bardzo dużych witryn.

Obsługa interfejsu API wykrywania funkcji Soft Navigations

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 origin 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ę dodatkowe kwestie.

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

Gdy wystąpi miękka nawigacja, należy sfinalizować Core Web Vitals poprzedniej strony i zgłosić je dla poprzedniego adresu URL, a następnie rozpocząć nowe monitorowanie dla nowego adresu URL.

Atrybut name odpowiedniego wpisu soft-navigation będzie zawierać nowy adres URL, dla którego mają być raportowane dane, a atrybut navigationId będzie unikalnym odniesieniem do tej nawigacji (ponieważ ten sam adres URL może być odwiedzany wielokrotnie w trakcie działania aplikacji jednostronicowej). 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;

Zgłoś prawidłowy adres URL dla interaction-contentful-paint

Aby obliczyć LCP na podstawie wpisów interaction-contentful-paint, musisz wziąć pod uwagę dodatkowe kwestie, ponieważ nie wszystkie wpisy interaction-contentful-paint powinny być mapowane za pomocą navigationId i zgłaszane jako LCP dla danego adresu URL:

• Pierwszy problem polega na tym, że interaction-contentful-paint wpisy mogą być emitowane przed miękką nawigacją, jeśli renderowanie nastąpi przed aktualizacją adresu URL. W takich przypadkach navigationId będzie dotyczyć starego adresu URL. Jeśli najpierw zostanie zaktualizowany adres URL, renderowanie zakończy się w ramach miękkiej nawigacji. W takim przypadku najpierw zostanie wyemitowany wpis soft-navigation, a wpis interaction-contentful-paint będzie zawierać nowy adres URL.
• Drugi problem polega na tym, że interaction-contentful-paint będą nadal emitowane w przypadku nowszych interakcji, ponieważ zakres tego wskaźnika skuteczności wykracza poza LCP w przypadku miękkich nawigacji. W przypadku LCP chcemy brać pod uwagę tylko renderowania podczas ładowania w ramach miękkiej nawigacji, a nie te, które występują w przypadku kolejnych interakcji.

Dlatego do mapowania wpisów interaction-contentful-paint na soft-navigation-entries należy używać znaku interactionId zamiast navigationId, aby uzyskać prawidłowy adres URL. Obejmie to wszystkie wpisy ze starymi navigationId, a także odfiltruje wszystkie wpisy interaction-contentful-paint, które nie powinny być brane pod uwagę w przypadku LCP.

Warto też rozważyć przetwarzanie wpisu largestInteractionContentfulPaint z wpisów soft-navigation, aby łatwiej obsługiwać wpisy interaction-contentful-paint, które występują przed wyemitowaniem wpisu soft-navigation entries.

Uzyskiwanie startTime miękkich przycisków nawigacyjnych

Wszystkie czasy działania, w tym czasy miękkich nawigacji, oraz wpisy używane do obliczania wskaźników Core Web Vitals są raportowane jako czas od początkowej „twardej” nawigacji na stronie. Dlatego czas rozpoczęcia miękkiej nawigacji należy odjąć od czasów pomiarów wczytywania miękkiej nawigacji (np. LCP), aby raportować je w odniesieniu do tego czasu.

Czas rozpoczęcia nawigacji można uzyskać w podobny sposób, mapując go na odpowiedni wpis soft-navigation i używając jego startTime.

startTime to czas pierwszej interakcji (np. kliknięcia przycisku), która zainicjowała miękką nawigację. Różni się to nieco od „twardej nawigacji”, w przypadku której „czas rozpoczęcia” to moment, w którym nowa strona jest „zatwierdzana” w przeglądarce i po uruchomieniu części kodu obsługi zdarzeń. Czasy rozpoczęcia miękkiej nawigacji obejmują też kod obsługi zdarzeń, ponieważ pomiar rozpoczynamy od czasu rozpoczęcia interakcji.

Pomiar Core Web Vitals w przypadku każdego miękkiego przejścia

Aby mierzyć Core Web Vitals, nasłuchuj wpisów soft-navigation i resetuj wskaźniki po ich otrzymaniu. Wartość FCP może być emitowana na podstawie presentationTime, a wartość LCP może być inicjowana na podstawie largestInteractionContentfulPaint. Wartości INP i CLS powinny być zainicjowane jako 0, tak jak w przypadku wczytania strony.

Wskaźniki LCP, INP i CLS można następnie mierzyć i monitorować w zwykły sposób (z wyjątkiem używania interaction-contentful-paint w przypadku LCP, które zapewnia dopasowania interactionId). Symbole interactionId i navigationId mogą służyć do nazywania wpisów do adresu URL, jak omówiliśmy wcześniej.

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ąć pod uwagę 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.

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ć do momentu opuszczenia strony, niezależnie od interakcji. Dlatego dane poprzedniej nawigacji powinny być finalizowane po każdej nowej nawigacji programowej. Oznacza to, że początkowe wskaźniki „twardej” nawigacji mogą zostać sfinalizowane wcześniej niż zwykle podczas pomiaru Core Web Vitals za pomocą miękkiej nawigacji.

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”. Oznacza to, że wiedza o tym, co jest „największym” wyrenderowaniem, interakcją do kolejnego wyrenderowania lub przesunięciem układu, jest resetowana, aby umożliwić ponowny pomiar od zera.

Jak traktować treści, które pozostają takie same podczas nawigacji?

LCP w przypadku miękkich nawigacji (obliczana na podstawie interaction-contentful-paint) będzie mierzyć tylko nowe wyrenderowania i tylko te, które są powiązane z interakcją, która spowodowała nawigację. Może to spowodować inną wartość LCP, np. w przypadku wczytywania „na zimno” miękkiej nawigacji i miękkiego wczytania.

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 w banerze jako element LCP i na tej podstawie określi czas LCP. W przypadku kolejnych miękkich nawigacji największym elementem renderowanym po miękkiej nawigacji będzie tekst poniżej, który stanie się nowym elementem LCP. Jeśli jednak strona zostanie wczytana za pomocą linku bezpośredniego do adresu URL nawigacji programowej, obraz w banerze zostanie wyrenderowany na nowo i dlatego będzie mógł być uznany za element LCP.

Podobnie animacja może stale aktualizować część strony, niezależnie od nawigacji tymczasowej. W przypadku nowego, płynnego przejścia do następnej strony nie będą one brane pod uwagę przy obliczaniu LCP. Mogą jednak być brane pod uwagę w przypadku LCP, jeśli strona została ponownie załadowana z tego adresu URL.

Jak pokazują te przykłady, 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 skutkować innym elementem LCP w przypadku twardej nawigacji.

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 pobierania wstępnego? 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 używa web-vitalsbiblioteka w przypadku miękkich nawigacji. Obecnie zalecamy ją w przypadku tego rodzaju pomiarów.

Czy warto mierzyć Core Web Vitals za pomocą obu metod?

Podczas tego eksperymentu zalecamy kontynuowanie pomiaru Core Web Vitals w dotychczasowy sposób, na podstawie „twardych” nawigacji po stronie, ponieważ nowa implementacja może mieć problemy lub ulec zmianie przed ostatecznym wdrożeniem. Będzie to też zgodne z tym, co obecnie mierzy CrUX (więcej informacji znajdziesz w dalszej części artykułu).

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 obecnego 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 obecnie) oraz oddzielne dzielenie osi czasu według miękkich nawigacji, aby mierzyć oddzielne wartości CLS i INP dla nowych.

Używaj biblioteki web-vitals do pomiaru Core Web Vitals 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';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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});

Biblioteka web-vitals zapewnia też raportowanie danych w odniesieniu do prawidłowego adresu URL zgodnie z tym, co zostało wcześniej wspomniane, ponieważ w danych przekazywanych do wywołania zwrotnego znajdują się zarówno navigationId, jak i navigationURL.

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

Czy te zmiany staną się częścią pomiarów Core Web Vitals?

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 Core Web Vitals. Głównym celem jest zapewnienie możliwości lepszego pomiaru skuteczności na podstawie wrażeń prawdziwych użytkowników. Jeśli ten eksperyment się powiedzie, zamierzamy uwzględnić te dane w pomiarach Core Web Vitals, które są dostępne we wszystkich narzędziach.

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ą z punktu widzenia użytkownika niemal identyczne z pełnymi wczytaniami strony, 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 Core Web Vitals dla danej strony lub grupy stron. W miarę rozwoju heurystyki możemy też całkowicie wykluczyć częściowe wczytywanie 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 o interfejsie API należy zgłaszać jako problemy w GitHubie.
• 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ą przeanalizujemy problemy w obu miejscach i przekierujemy je do odpowiedniej lokalizacji.

Historia zmian

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

Podsumowanie

Eksperyment z miękkimi nawigacjami to ciekawe podejście do tego, jak inicjatywa dotycząca Core Web Vitals 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.