Pomiar miękkiej nawigacji

Barry Pollard

Michal Mocny

Data publikacji: 1 lutego 2023 r., ostatnia aktualizacja: 20 września 2026 r.

Od momentu uruchomienia inicjatywa Core Web Vitals ma na celu mierzenie rzeczywistych wrażeń użytkowników witryny, a nie szczegółów technicznych związanych z jej tworzeniem lub wczytywaniem. Trzy podstawowe wskaźniki internetowe Core Web Vitals zostały utworzone jako dane zorientowane na użytkownika – to rozwinięcie 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. Z tego powodu technologia użyta do utworzenia witryny nie powinna mieć wpływu na ocenę, pod warunkiem że witryna działa prawidłowo.

Rzeczywistość jest zawsze 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 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 używa tego modelu, ale każda na inny sposób. Ponieważ wykracza to poza to, co przeglądarka tradycyjnie rozumie jako „stronę”, pomiar zawsze był trudny: gdzie jest granica między interakcją na bieżącej stronie a uznaniem jej za nową stronę?

Zespół Chrome od pewnego czasu analizuje to wyzwanie i stara się ujednolicić definicję „nawigacji miękkiej” oraz sposób pomiaru Core Web Vitals w tym przypadku – podobnie jak w przypadku witryn wdrożonych w konwencjonalnej architekturze wielostronicowej (MPA).

Na podstawie opinii deweloperów wprowadziliśmy kilka ulepszeń w propozycji i uruchomiliśmy 2 nowe interfejsy API wydajności, które pomogą rozwiązać ten problem w Chrome 151. Dodatkowo udostępniliśmy dane dotyczące łagodnej nawigacji w Raporcie na temat użytkowania Chrome (CrUX) jako dane eksperymentalne.

Czym jest miękka nawigacja?

Oto nasza definicja nawigacji miękkiej:

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

W przypadku niektórych witryn ta definicja może prowadzić do fałszywie pozytywnych wyników (użytkownicy nie uznają, że nastąpiła „nawigacja”) lub fałszywie negatywnych wyników (użytkownik uważa, że nastąpiła „nawigacja”, mimo że nie spełnia tych kryteriów). Chętnie poznamy Twoją opinię w repozytorium specyfikacji łagodnej nawigacji.

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

Dodaliśmy obsługę miękkich nawigacji w panelu Wydajność Narzędzi deweloperskich w widoku Wskaźniki na żywo oraz w widoku śladu z obsługą Statystyk i znaczników:

Jak Chrome implementuje łagodne nawigacje dla programistów stron internetowych?

Po włączeniu funkcji łagodnej nawigacji (więcej informacji znajdziesz w następnej sekcji) Chrome zmieni sposób raportowania niektórych wskaźników skuteczności:

• Po wykryciu każdej nawigacji programowej zostanie wygenerowane zdarzenie soft-navigation PerformanceTiming.
• Ten wpis soft-navigation będzie zawierać navigationId, nowy adres URL w atrybucie name, a także interactionId interakcji inicjującej.
• Po interakcjach, które powodują wyrenderowanie treści, zostanie wygenerowany co najmniej 1 wpis interaction-contentful-paint. Będzie on zawierać wpis largestContentfulPaint, który może służyć do pomiaru największego wyrenderowania treści (LCP) w przypadku miękkich nawigacji.
• Atrybut navigationId jest dodawany do każdego ze zdarzeń związanych z czasem działania (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event i layout-shift). Odpowiada on wpisowi nawigacyjnemu, w ramach którego zdarzenie zostało wygenerowane. Pamiętaj, że gdy te wpisy obejmują nawigacje miękkie, mogą zawierać poprzedni lub następny element navigationId w zależności od tego, kiedy wpis został wygenerowany. Więcej informacji na ten temat znajdziesz w sekcji Raportowanie danych dotyczących odpowiedniego adresu URL.
• soft-navigation będzie zawierać funkcję getLargestInteractionContentfulPaint(), która będzie pobierać największy wpis interaction-contentful-paint dla tej nawigacji. Można go następnie użyć jako początkowego LCP dla tej nawigacji, a potem aktualizować go w miarę obserwowania kolejnych wpisów interaction-contentful-paint dla tej interakcji. Uwaga: zastępuje on atrybut largestInteractionContentfulPaint dostępny we wcześniejszych wersjach próbnych origin.
• Niektóre wpisy interaction-contentful-paint mogą pojawić się przed łagodną nawigacją (jeśli aktualizacja adresu URL nastąpi dopiero po tych renderowaniach). W takich przypadkach funkcja getLargestInteractionContentfulPaint() pozwala uniknąć buforowania i sprawdzania starych wpisów po zakończeniu nawigacji miękkiej. Pamiętaj, że wpis zwracany przez getLargestInteractionContentfulPaint() jest dokładną kopią największego wpisu interaction-contentful-paint w momencie jego wygenerowania, więc wpis ten mógł 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 wpisy interaction-contentful-paint będą też generowane po kolejnych interakcjach, ale LCP dla adresu URL powinien być ograniczony do wpisów interaction-contentful-paint, które pasują do łagodnych nawigacji interactionId, aby je wykluczyć, a także tylko do właściwości largestContentfulPaint w ich obrębie.

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

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

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

• Monitorowanie wpisów soft-navigation umożliwia „podział” wpisów dotyczących wydajności na poszczególne „nawigacje”.
• Wskaźniki CLS i INP można już dzielić według własnego uznania, zamiast mierzyć je przez cały cykl życia strony, ale funkcja łagodnej nawigacji zapewnia ustandaryzowany pomiar tego, kiedy to następuje, niezależnie od używanej 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 LCP początkowej „twardej” nawigacji. Oznacza to, że nie zmieni się sposób pomiaru łagodnych nawigacji, więc LCP dla początkowego, twardego wczytania strony będzie można mierzyć tak jak zawsze.
• Nowy wpis interaction-contentful-paint, który będzie generowany przez interakcje, może służyć do pomiaru LCP w przypadku nawigacji miękkiej przez sprawdzenie właściwości largestContentfulPaint. W tym artykule omówimy jednak pewne kwestie związane z używaniem tego wpisu.
• Pamiętaj, że nie wszyscy użytkownicy będą obsługiwać tę funkcję łagodnej nawigacji, zwłaszcza ci, którzy korzystają z innych przeglądarek lub wersji Chrome starszych niż 151. Pamiętaj, że niektórzy użytkownicy mogą nie zgłaszać danych opartych na miękkiej nawigacji, nawet jeśli zgłaszają Core Web Vitals.

Sprawdź u swojego dostawcy RUM, czy obsługuje on pomiary Core Web Vitals za pomocą nawigacji programowej. Wielu z nich planuje przetestować ten nowy standard i uwzględni przy tym powyższe kwestie. Tymczasem niektórzy dostawcy umożliwiają też ograniczone pomiary wskaźników skuteczności na podstawie własnych metod heurystycznych.

Więcej informacji o tym, jak mierzyć dane dotyczące miękkich nawigacji, znajdziesz w sekcji poświęconej pomiarom Core Web Vitals w przypadku miękkich nawigacji.

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

Funkcja łagodnej nawigacji jest domyślnie włączona od wersji 151 Chrome.

Wykrywanie 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
}

Możesz też:

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

Jak mierzyć miękkie nawigacje?

Jeśli jest to obsługiwane, dane można raportować za pomocą interfejsu API PerformanceObserver, tak jak inne dane. W przypadku tych danych należy jednak wziąć pod uwagę kilka dodatkowych kwestii.

Zgłaszanie miękkich nawigacji

Do obserwowania łagodnych nawigacji możesz użyć interfejsu PerformanceObserver. Poniżej znajdziesz przykładowy fragment kodu, który rejestruje wpisy dotyczące nawigacji miękkiej w konsoli, w tym poprzednie nawigacje miękkie 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.

raportować dane dotyczące odpowiedniego adresu URL.

Gdy wykryta zostanie łagodna nawigacja, należy sfinalizować Core Web Vitals 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 ciągu cyklu życia aplikacji jednostronicowej).

Należy ustawić tę wartość dla każdego wpisu soft-navigation i używać jej do raportowania danych do momentu otrzymania następnego wpisu soft-navigation.

Zgłaszanie prawidłowego adresu URL w przypadku: interaction-contentful-paint

Obliczanie LCP na podstawie wpisów interaction-contentful-paint wymaga dodatkowych działań, ponieważ nie wszystkie wpisy interaction-contentful-paint powinny być mapowane za pomocą navigationId i raportowane jako LCP dla danego adresu URL:

• Pierwszy problem polega na tym, że wpisy interaction-contentful-paint mogą być wysyłane przed wystąpieniem łagodnej nawigacji, 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 miękką nawigację. W takim przypadku najpierw zostanie wygenerowany wpis soft-navigation, a wpis interaction-contentful-paint będzie zawierać nowy adres URL.
• Drugi problem polega na tym, że w przypadku nowszych interakcji wpisy interaction-contentful-paint będą nadal generowane, ponieważ zakres tego wskaźnika skuteczności wykracza poza LCP w przypadku nawigacji miękkich. W przypadku LCP chcemy brać pod uwagę tylko renderowanie podczas ładowania miękkiej nawigacji, a nie podczas kolejnych interakcji.

Dlatego do mapowania wpisów interaction-contentful-paint na soft-navigation-entries należy używać interactionId, a nie navigationId, aby uzyskać prawidłowy adres URL. Spowoduje to obsługę wszystkich wpisów ze starymi elementami navigationId oraz odfiltrowanie wszystkich wpisów interaction-contentful-paint, które nie powinny być brane pod uwagę w przypadku LCP.

Dodatkowo należy najpierw przetworzyć funkcję getLargestInteractionContentfulPaint() wpisów soft-navigation, aby obsłużyć wpisy interaction-contentful-paint, które wystąpiły przed wyemitowaniem soft-navigation entries.

Pobieranie startTime miękkich nawigacji

Wszystkie czasy wydajności, w tym czasy nawigacji miękkiej, oraz wpisy używane do obliczania Core Web Vitals są raportowane jako czas od początkowego czasu nawigacji na stronie. Dlatego czas rozpoczęcia nawigacji miękkiej należy odjąć od czasu wczytywania danych nawigacji miękkiej (np. LCP), aby raportować je w odniesieniu do tego czasu nawigacji miękkiej.

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

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

Pomiar Core Web Vitals w przypadku nawigacji miękkiej

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 LCP może być inicjowany do wpisu getLargestInteractionContentfulPaint(). Wskaźniki INP i CLS powinny być inicjowane na wartość 0, tak jak w przypadku wczytywania strony.

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, jeśli interactionId pasuje). interactionId może służyć do nazywania wpisów adresu URL, jak omówiono wcześniej.

Czasy będą nadal zwracane względem pierwotnego „twardego” czasu rozpoczęcia nawigacji. Aby obliczyć LCP dla nawigacji miękkiej, musisz od czasu interaction-contentful-paint odjąć odpowiedni czas rozpoczęcia nawigacji miękkiej, jak opisano wcześniej, aby uzyskać czas względny dla nawigacji miękkiej.

Niektóre dane są tradycyjnie mierzone przez cały okres istnienia strony: na przykład LCP może się zmieniać, dopóki nie nastąpi interakcja. Wskaźniki CLS i INP mogą być aktualizowane do momentu opuszczenia strony, niezależnie od interakcji. Dlatego dane poprzedniej nawigacji powinny być finalizowane po każdym wystąpieniu nowej miękkiej nawigacji. Oznacza to, że początkowe „twarde” dane nawigacyjne mogą zostać sfinalizowane wcześniej niż zwykle, gdy Core Web Vitals są mierzone za pomocą nawigacji miękkiej.

Podobnie, gdy zaczynasz mierzyć dane dotyczące nowej miękkiej nawigacji, te długotrwałe dane trzeba „zresetować” lub „ponownie zainicjować” i traktować jako nowe dane, bez pamięci o wartościach ustawionych dla poprzednich „stron”. Oznacza to, że informacje o tym, czym jest „największe” wyrenderowanie, interakcja do kolejnego wyrenderowania lub przesunięcie układu, są resetowane, aby umożliwić ponowny pomiar od zera.

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

LCP w przypadku nawigacji miękkich (obliczany od interaction-contentful-paint) będzie mierzyć tylko nowe renderowania i tylko renderowania powiązane z interakcją, która spowodowała nawigację. Może to spowodować, że LCP będzie się różnić w przypadku wczytywania „na zimno” i wczytywania „na miękko”.

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 nawigacji programowej. Początkowe wczytanie strony oznaczy obraz banera jako element LCP i na tej podstawie określi czas LCP. W przypadku kolejnych miękkich nawigacji tekst pod spodem będzie największym elementem wyrenderowanym po miękkiej nawigacji i będzie nowym elementem LCP. Jeśli jednak strona zostanie wczytana za pomocą precyzyjnego linku do adresu URL nawigacji miękkiej, obraz banera będzie nowym renderowaniem i dlatego będzie mógł zostać uznany za element LCP.

Podobnie animacja może stale aktualizować część strony, niezależnie od tego, czy następuje miękka nawigacja. Żadne nowe renderowania spowodowane animacją tła nie będą uwzględniane w LCP w przypadku nowej miękkiej nawigacji. Mogą być jednak 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 nawigacji miękkiej może być raportowany inaczej w zależności od sposobu wczytywania strony – tak samo jak wczytywanie strony z linkiem do kotwicy w dalszej części strony może skutkować innym elementem LCP w przypadku nawigacji twardej.

Jak mierzyć TTFB?

Czas do pierwszego bajtu (TTFB) w przypadku konwencjonalnego wczytywania strony to czas, po którym zwracane są pierwsze bajty pierwotnego żądania.

W przypadku nawigacji miękkiej jest to trudniejsze pytanie. Czy powinniśmy mierzyć pierwsze żądanie wysłane w przypadku nowej strony? Co zrobić, jeśli wszystkie treści są już w aplikacji i nie ma żadnych dodatkowych żądań? Co się stanie, jeśli żądanie zostanie wysłane z wyprzedzeniem za pomocą 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)?

Prostszą metodą jest raportowanie TTFB o wartości 0 w przypadku nawigacji miękkich – podobnie jak zalecamy w przypadku przywracania pamięci podręcznej stanu strony internetowej. Jest to metoda, której biblioteka web-vitals używa do łagodnych nawigacji i którą obecnie zalecamy w przypadku tych danych.

Czy należy mierzyć Core Web Vitals za pomocą obu metodologii?

Te nowe interfejsy API są ograniczone tylko do przeglądarek opartych na Chromium, ale witryny mogą chcieć mierzyć oba te parametry, dzieląc je na nawigacje miękkie i twarde. Umożliwiłoby to porównywanie danych między przeglądarkami i trendami historycznymi.

W przypadku LCP oznacza to, że w obecnej metodzie uwzględniane są tylko wpisy largest-contentful-paint, a w nowej – zarówno wpisy largest-contentful-paint, jak i interaction-contentful-paint.

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

Dane musiałyby być wtedy przesyłane i przechowywane dwukrotnie na potrzeby analizy.

Używanie biblioteki web-vitals do pomiaru Core Web Vitals w przypadku nawigacji miękkiej

Najprostszym sposobem na uwzględnienie wszystkich niuansów jest użycie biblioteki JavaScript web-vitals, która od wersji 6.0.0 obsługuje nawigację miękką. Można to zmierzyć w ten sposób (odpowiednio zastępując doTraditionalProcessing i doSoftNavProcessing):

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ż, że dane są raportowane w odniesieniu do prawidłowego adresu URL, jak wspomniano wcześniej, ponieważ zawierają zarówno navigationId, jak i navigationURL we wpisach przekazywanych do wywołania zwrotnego.

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

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

Głównym celem jest zapewnienie możliwości lepszego pomiaru wydajności na podstawie wrażeń prawdziwych użytkowników. Tak, celem jest uwzględnienie tych danych w pomiarach Core Web Vitals, które będą widoczne we wszystkich narzędziach po uruchomieniu interfejsu API.

Jak miękkie nawigacje będą raportowane w CrUX?

W CrUX udostępniliśmy eksperymentalne wersje danych Core Web Vitals. Kończą one CLS i INP „twardej nawigacji” po pierwszej nawigacji miękkiej, a także obejmują dodatkowe pomiary LCP, CLS i INP dla każdej nawigacji miękkiej. W maju 2027 r. planujemy przekształcić te dane eksperymentalne w dane stabilne. Więcej informacji znajdziesz w poście na blogu Eksperymentalne dane dotyczące miękkiej nawigacji są już dostępne w CrUX.

Jak obsługiwać łagodne nawigacje w innych przeglądarkach?

Płynne nawigacje są trudne do wykrycia programowo w przeglądarkach, które nie obsługują interfejsu API. To właśnie dlatego pracowaliśmy nad tym interfejsem API.

Możesz użyć interfejsu Navigation API do monitorowania zmian adresów URL, co może umożliwić podział INP według adresu URL (i podobnie CLS, chociaż obecnie jest to możliwe tylko w Chromium, więc i tak nie byłoby mierzone). Nie dotyczy to jednak danych związanych z renderowaniem (FCP i LCP), które można tylko oszacować.

Jednocześnie uważamy, że statystyki oferowane przez ten interfejs API są zbyt cenne, aby je ignorować, zarówno w przypadku pomiaru czasu łagodnych nawigacji, jak i przypisywania danych do właściwej nawigacji. Zalecamy korzystanie z tego nowego interfejsu API, mimo że obecnie nie jest on obsługiwany przez wszystkie przeglądarki. Podobnie jak w przypadku wprowadzenia Core Web Vitals, wykryte problemy i rozwiązania dotyczące wydajności będą prawdopodobnie miały wpływ na wszystkie przeglądarki, nawet jeśli na razie widoczność jest ograniczona tylko do przeglądarek opartych na Chromium.

Będziemy kontynuować proces standaryzacji i współpracować z innymi dostawcami przeglądarek, aby pokazać znaczenie tego interfejsu API.

Prześlij opinię

Aktywnie zbieramy opinie na temat tego interfejsu API w tych miejscach:

• Opinie o interfejsie API należy zgłaszać jako problemy na GitHubie.
• Błędy w implementacji Chromium należy zgłaszać w narzędziu do śledzenia błędów w Chrome, jeśli nie są jeszcze wymienione wśród znanych problemów.
• Ogólne opinie na temat podstawowych wskaźników internetowych można przesyłać na adres web-vitals-feedback@googlegroups.com.

Jeśli masz wątpliwości, nie martw się – chętnie przyjmiemy opinię w dowolnym miejscu, a następnie przeanalizujemy problemy i przekierujemy je do odpowiedniej lokalizacji.

Historia zmian

W trakcie rozwoju tego interfejsu API wprowadzono w nim wiele zmian, więcej niż w przypadku stabilnych interfejsów API. Więcej informacji znajdziesz w liście zmian dotyczących płynnych nawigacji.

Podsumowanie

Funkcja Soft Navigations to ciekawe podejście do tego, jak inicjatywa Core Web Vitals może ewoluować, aby mierzyć typowy wzorzec we współczesnym internecie, którego brakuje w naszych danych. Zebraliśmy wiele opinii od szerszej społeczności internetowej i jesteśmy zachęceni potencjałem tego interfejsu API.

Podziękowania

Miniatura: Jordan Madrid, Unsplash

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