Pomiar miękkiej nawigacji

Barry Pollard

Michal Mocny

Data publikacji: 1 lutego 2023 r., ostatnia aktualizacja: 24 czerwca 2026 r.

Od momentu uruchomienia inicjatywy Core Web Vitals jej celem jest 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 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 treść strony jest zmieniana przez JavaScript. W tych aplikacjach iluzja konwencjonalnej 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 tradycyjne rozumienie „strony” przez przeglądarkę, 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).

Wprowadziliśmy kilka ulepszeń w propozycji na podstawie opinii deweloperów. W Chrome 151 planujemy udostępnić 2 nowe interfejsy API dotyczące wydajności, które pomogą rozwiązać ten problem.

Co to jest miękka nawigacja?

Oto definicja miękkiej nawigacji:

• Nawigacja jest inicjowana przez działanie użytkownika.
• Nawigacja powoduje widoczną dla użytkownika zmianę adresu URL.
• Interakcja powoduje widoczne wyrenderowanie.

W przypadku niektórych witryn ta definicja może prowadzić do wyników fałszywie pozytywnych (gdy użytkownicy nie uznają danego działania za „nawigację”) lub fałszywie negatywnych (gdy użytkownik uzna dane działanie za „nawigację”, mimo że nie spełnia ono tych kryteriów). Zapraszamy do przekazywania opinii w repozytorium specyfikacji miękkiej nawigacji.

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

Na panelu Wydajność w Narzędziach deweloperskich w widoku śladu dodaliśmy obsługę miękkich nawigacji:

Możesz zobaczyć 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 wykrywanie miękkich nawigacji 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?

Gdy funkcja miękkiej nawigacji zostanie włączona (więcej informacji znajdziesz 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 wyemitowany co najmniej 1 wpis interaction-contentful-paint. Będzie on zawierać wpis largestContentfulPaint, który można wykorzystać do pomiaru największego wyrenderowania treści (LCP) w przypadku miękkich nawigacji.
• 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ć funkcję getLargestInteractionContentfulPaint(), która pobiera największy wpis interaction-contentful-paint dla danej 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. Zastępuje to atrybut largestInteractionContentfulPaint dostępny w poprzednich testach origin.
• Niektóre wpisy interaction-contentful-paint mogły nastąpić przed miękką nawigacją (jeśli aktualizacja adresu URL nastąpi dopiero po tych renderowaniach). W takich przypadkach funkcja getLargestInteractionContentfulPaint() zapobiega konieczności buforowania i przeglądania starych wpisów po zakończeniu miękkiej nawigacji. Pamiętaj, że wpis zwrócony przez getLargestInteractionContentfulPaint() jest dokładną kopią największego wpisu interaction-contentful-paint w momencie jego wygenerowania. Wpis ten mógł więc używać poprzedniego navigationId, ponieważ wtedy nastąpiło renderowanie, ale te renderowania 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ć, a także tylko do właściwości largestContentfulPaint w ramach tego.

Te zmiany umożliwią pomiar Core Web Vitals i niektórych powiązanych z nimi danych diagnostycznych w przypadku każdej nawigacji na stronie, choć należy wziąć pod uwagę pewne niuanse.

Jakie są konsekwencje włączenia w Chrome miękkich 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”.
• Dane CLS i INP można już dzielić według własnego uznania, zamiast mierzyć je w całym cyklu życia strony. Funkcja miękkiej nawigacji zapewnia jednak standardowy pomiar tego, kiedy to następuje, niezależnie od użytej technologii.
• 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 LCP nawigacji „twardej”. Oznacza to, że nie zmieni się on podczas pomiaru miękkich nawigacji, dzięki czemu LCP w przypadku początkowego, twardego wczytania strony można mierzyć tak jak dotychczas.
• Nowy wpis interaction-contentful-paint, który będzie generowany w wyniku interakcji, może służyć do pomiaru LCP w przypadku miękkich nawigacji. Wystarczy sprawdzić właściwość largestContentfulPaint w tym wpisie. Istnieją jednak 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ć tę funkcję płynnego przechodzenia, 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 zgłaszać danych opartych na miękkiej nawigacji, nawet jeśli zgłaszają dane dotyczące Core Web Vitals.

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 dotyczące miękkich nawigacji, znajdziesz w sekcji poświęconej pomiarowi Core Web Vitals w przypadku miękkich nawigacji.

Jak włączyć w Chrome miękkie nawigacje?

Funkcja miękkiej nawigacji ma być domyślnie włączona w Chrome 151, ale można ją przetestować wcześniej, włączając ją ręcznie.

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.

Niektórzy właściciele witryn włączyli tę funkcję w swoich witrynach przed ich uruchomieniem w ramach procesu testowania origin. Pamiętaj, że kształt interfejsu API zmieniał się w trakcie opracowywania tej funkcji, a ostateczna wersja różni się od poprzednich testów origin, co zostało opisane w dzienniku zmian dotyczących płynnego przechodzenia.

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 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 nie wyjdzie ze stanu przejściowego:

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

Jak mogę mierzyć miękkie nawigacje?

Po włączeniu wykrywania miękkich nawigacji dane będą raportowane przy użyciu interfejsu PerformanceObserver API, tak jak w przypadku innych danych. 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żna go użyć do sfinalizowania danych dotyczących całej strony w przypadku poprzedniej nawigacji.

Raportowanie danych w odniesieniu do odpowiedniego adresu URL

Gdy wystąpi miękka nawigacja, należy sfinalizować podstawowe wskaźniki internetowe poprzedniej strony, a następnie zgłosić je dla poprzedniego adresu URL i 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 jednej aplikacji jednostronicowej).

Należy ustawić wartość każdego wpisu soft-navigation i używać jej do raportowania danych do momentu otrzymania kolejnego wpisu soft-navigation.

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

Aby obliczyć LCP na podstawie wpisów interaction-contentful-paint, należy 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 wpisów może zostać wyemitowanych 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ę po 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, wpisy 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 płynnej 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, a nie 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.

Dodatkowo warto rozważyć przetwarzanie funkcji getLargestInteractionContentfulPaint() wpisów soft-navigation, aby łatwiej obsługiwać wpisy interaction-contentful-paint, które występują przed wyemitowaniem soft-navigation entries.

Uzyskiwanie startTime miękkich nawigacji

Wszystkie czasy działania, w tym czasy dotyczące 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 wskaźnikó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. FCP może być emitowany na podstawie wpisu presentationTime, a LCP może być inicjowany na podstawie wpisu getLargestInteractionContentfulPaint(). Wartości INP i CLS powinny być zainicjowane jako 0, tak jak w przypadku wczytania strony.

Wskaźniki LCP, INP i CLS można wtedy mierzyć i monitorować w zwykły sposób (z wyjątkiem używania interaction-contentful-paint w przypadku LCP, które zapewnia dopasowanie interactionId). interactionId może służyć do nazywania wpisów w adresie URL, jak wspomnieliś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: np. 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 „twarde” wskaźniki 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 miękkiej nawigacji w tych długotrwałych danych trzeba będzie „zresetować” lub „zainicjować ponownie” dane i traktować je jako nowe, 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 (obliczone na podstawie interaction-contentful-paint) będzie mierzyć tylko nowe wyrenderowania i tylko te, które są powiązane z interakcją powodującą nawigację. Może to spowodować inną wartość LCP, np. w przypadku przejścia od wczytywania „na zimno” do miękkiego ładowania.

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 strona zostanie wczytana za pomocą precyzyjnego linku do adresu URL nawigacji programowej, obraz banera 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 miękkiego przejścia do LCP nie będą brane pod uwagę żadne nowe wyrenderowania wynikające z animacji tła. 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ę niżej na stronie może skutkować innym elementem LCP w przypadku twardej nawigacji.

Jak mierzyć TTFB?

Czas do pierwszego bajta (TTFB) w przypadku tradycyjnego 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ż dostępne 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?

Te nowe interfejsy API są ograniczone tylko do przeglądarek opartych na Chromium, ale witryny mogą chcieć mierzyć oba rodzaje nawigacji, dzieląc je na nawigacje miękkie i twarde. Umożliwi to porównywanie danych z różnych przeglądarek i trendów historycznych.

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 wartości 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 nowej.

Dane te musiałyby być wysyłane i przechowywane 2 razy na potrzeby analizy.

Używanie 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ż na 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});

web-vitals Biblioteka zapewnia też raportowanie danych w odniesieniu do prawidłowego adresu URL (jak wspomnieliśmy wcześniej), ponieważ w danych przekazywanych do wywołania zwrotnego znajdują się zarówno navigationId, jak i navigationURL.

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

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

Głównym celem jest zapewnienie możliwości lepszego pomiaru wydajności w odniesieniu do wrażeń użytkowników. Tak, po uruchomieniu interfejsu API chcemy uwzględniać te wskaźniki w pomiarach podstawowych wskaźników internetowych, które są udostępniane przez wszystkie narzędzia.

Cenimy opinie programistów stron internetowych na temat interfejsu API i tego, czy ich zdaniem lepiej odzwierciedla on wrażenia użytkowników. Najlepszym miejscem na przekazanie opinii jest repozytorium GitHub dotyczące płynnej 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?

Sposób raportowania miękkich nawigacji w CrUX po wprowadzeniu tej funkcji nie został jeszcze określony. Gdy będziemy mieć więcej informacji, ogłosimy, jak zmieni się CrUX.

Prześlij opinię

Opinie na temat tego interfejsu API możesz przesyłać w tych miejscach:

• Opinie o interfejsie 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ą przeanalizujemy problemy w obu miejscach i przekierujemy je do właściwej lokalizacji.

Historia zmian

W trakcie opracowywania tego interfejsu API wprowadzono w nim wiele zmian, więcej niż w przypadku stabilnych interfejsów API. Więcej informacji znajdziesz w historii zmian dotyczących miękkiej nawigacji.

Podsumowanie

Funkcja miękkiej nawigacji to ciekawe podejście do tego, jak inicjatywa Core Web Vitals może ewoluować, aby mierzyć powszechny wzorzec w nowoczesnej sieci, którego brakuje w naszych danych. Zebraliśmy wiele opinii od społeczności internetowej. Zachęcamy osoby zainteresowane tym rozwiązaniem do skorzystania z tej możliwości, aby pomóc w kształtowaniu interfejsów API i dopilnować, aby odzwierciedlały one to, co chcemy za ich pomocą 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.