Pomiar miękkiej nawigacji

Barry Pollard

Michal Mocny

Data publikacji: 1 lutego 2023 r., ostatnia aktualizacja: 8 lipca 2026 r.

Od momentu uruchomienia inicjatywy Podstawowe wskaźniki internetowe jej celem jest 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, które są rozwinięciem dotychczasowych danych 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 podstawowe wskaźniki internetowe. 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 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 zamierzamy 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 łagodnej 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 (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). 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:

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 API wydajności, 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ł wygenerowany. 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. Uwaga: zastępuje to atrybut largestInteractionContentfulPaint dostępny w poprzednich testach origin trial.
• 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 podstawowych wskaźników internetowych i niektórych powiązanych z nimi danych diagnostycznych w przypadku każdej nawigacji po 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 łagodnej nawigacji), więc można go używać tylko do pomiaru początkowego LCP „twardej” nawigacji. Oznacza to, że nie zmieni się ona 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 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 podstawowych wskaźników internetowych.

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 podstawowych wskaźników internetowych 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 jest dostępna do testowania wcześniej po jej wyraźnym włączeniu.

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 źródła. 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 miękkich nawigacji.

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żna 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 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ę kilka dodatkowych kwestii.

Raportowanie łagodnej 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 navigationId będzie unikalnym odniesieniem do tej nawigacji (ponieważ ten sam adres URL może być odwiedzany wielokrotnie w trakcie działania aplikacji jednostronicowej).

Należy ustawić go jako każdy wpis soft-navigation i używać do raportowania danych do momentu otrzymania następnego wpisu soft-navigation.

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

Do obliczania LCP na podstawie wpisów interaction-contentful-paint potrzebne są dodatkowe uwagi, 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 zaktualizujesz 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, wpisy będą nadal emitowane w przypadku nowszych interakcji, ponieważ zakres tego wskaźnika wydajności wykracza poza LCP w przypadku miękkich nawigacji. W przypadku LCP chcemy brać pod uwagę tylko renderowania podczas ładowania nawigacji programowej, a nie podczas 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 łagodnych nawigacji

Wszystkie czasy działania, w tym czasy dotyczące miękkich nawigacji, oraz wpisy używane do obliczania podstawowych wskaźników internetowych są raportowane jako czas od początkowej „twardej” nawigacji na stronie. Dlatego czas rozpoczęcia łagodnej nawigacji należy odjąć od czasów wczytywania w przypadku łagodnej nawigacji (np. LCP), aby podawać 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 łagodnej nawigacji obejmują też kod obsługi zdarzeń, ponieważ pomiar rozpoczynamy od czasu rozpoczęcia interakcji.

Pomiar podstawowych wskaźników internetowych w przypadku każdego miękkiego przejścia

Aby mierzyć podstawowe wskaźniki internetowe, 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 ładowania 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 nawigacji „na sztywno”. Aby na przykład obliczyć LCP w przypadku łagodnej nawigacji, musisz wziąć pod uwagę czas interaction-contentful-paint i odjąć odpowiedni czas rozpoczęcia łagodnej nawigacji, jak opisano wcześniej, aby uzyskać czas względny w stosunku do łagodnej 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 podstawowych wskaźników internetowych 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, czasem od interakcji 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ą powodującą nawigację. Może to spowodować inną wartość LCP, np. w przypadku przejścia od zimnego ładowania do miękkiego ładowania.

Załóżmy na przykład, że strona zawiera duży obraz banera, który jest 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 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 jak 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ć podstawowe wskaźniki internetowe 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ż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';

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 (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 podstawowych wskaźników internetowych?

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 odpowiedniej 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ękkich 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.