Pomiar miękkiej nawigacji

Barry Pollard

Michal Mocny

Data publikacji: 1 lutego 2023 r., ostatnia aktualizacja: 2 września 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 to, co przeglądarka tradycyjnie rozumie jako „stronę”, pomiar tego zjawiska zawsze był trudny: gdzie należy wyznaczyć granicę między interakcją na bieżącej stronie a uznaniem jej za nową stronę?

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

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

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

Dodaliśmy obsługę miękkich nawigacji w panelu Wydajność w Narzędziach deweloperskich w widoku Dane na żywo oraz w widoku śledzenia z statystykami i obsługą znaczników:

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

Gdy funkcja miękkiej nawigacji zostanie włączona (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. 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ą wystą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 wydajnoś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. 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łynnej 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ą 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 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?

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

Wykrywanie funkcji obsługi interfejsu Soft Navigations API

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

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

Możesz też:

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

Jak mogę mierzyć miękkie nawigacje?

W przypadku obsługiwanych platform dane te 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.

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 navigationId będzie unikalnym odniesieniem do tej nawigacji (ponieważ ten sam adres URL może być odwiedzany wielokrotnie w okresie istnienia pojedynczej 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

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 jeśli renderowanie nastąpi przed aktualizacją adresu URL, przed miękką nawigacją może zostać wyemitowanych interaction-contentful-paint wpisów. 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 skuteczności wykracza poza LCP w przypadku miękkich nawigacji. W przypadku LCP chcemy brać pod uwagę tylko wyrenderowania związane z wczytaniem nawigacji programowej, a nie te, które są związane z kolejnymi interakcjami.

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 najpierw przetwórz 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 łagodnych 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 łagodnej nawigacji należy odjąć od czasów wczytywania danych w ramach ł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 Core Web Vitals w przypadku każdego miękkiego przejścia

Aby zmierzyć wskaźniki Core Web Vitals, nasłuchuj wpisów soft-navigation i resetuj metryki po ich otrzymaniu. Protokół FCP można wyemitować na podstawie wpisu presentationTime, a protokół LCP można zainicjować wpisem getLargestInteractionContentfulPaint(). INP i CLS powinny zostać zainicjowane wartością 0, tak jak miałoby to miejsce 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 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 ł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 wskaźniki tradycyjnie mierzono przez cały cykl życia strony: na przykład LCP może się zmieniać aż do momentu wystąpienia interakcji. Wartości CLS i INP można aktualizować do momentu opuszczenia strony, niezależnie od interakcji. Dlatego też metryki poprzedniej nawigacji powinny być finalizowane przy każdej nowej miękkiej nawigacji. 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, rozpoczynając pomiar metryk dla nowej miękkiej nawigacji tych długotrwałych metryk, metryki będą musiały zostać „zresetowane” lub „ponownie zainicjowane” i traktowane jako nowe metryki, bez pamięci o wartościach ustawionych dla poprzednich „stron”. Oznacza to, że interpretacja „największego” wyrenderowania, interakcji do kolejnego wyrenderowania lub przesunięcia 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ć, że LCP będzie się różnić od LCP w przypadku wczytywania „na zimno” tej miękkiej nawigacji 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 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 załadowana za pomocą głębokiego łącza do adresu URL nawigacji miękkiej, obraz banera będzie nowym obrazem i w związku z tym będzie mógł zostać uznany za element LCP.

Podobnie animacja może stale aktualizować część strony, niezależnie od miękkiej nawigacji. 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 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 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ż 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żywaj biblioteki web-vitals do pomiaru Core Web Vitals w przypadku łagodnych nawigacji

Najprostszym sposobem uwzględnienia wszystkich niuansów jest użycie biblioteki JavaScript web-vitals, która od wersji 6.0.0 obsługuje miękkie nawigacje. 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 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.

Jak w raporcie na temat użytkowania Chrome będą raportowane 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.

Jak obsługiwać miękkie nawigacje w innych przeglądarkach?

W przeglądarkach, które nie obsługują interfejsu API, trudno jest wykrywać programowo miękkie nawigacje. To właśnie dlatego pracowaliśmy nad tym interfejsem API.

Możesz użyć interfejsu Navigation API, aby monitorować zmiany adresu URL, co może umożliwić dzielenie INP według adresu URL (podobnie jak CLS, chociaż obecnie jest on dostępny tylko w Chromium, więc nie będzie mierzony). Nie rozwiązuje to jednak problemu z danymi dotyczącymi renderowania (FCP i LCP), które można tylko oszacować.

Jednocześnie uważamy, że informacje oferowane przez ten interfejs API są zbyt cenne, aby je ignorować – zarówno w zakresie pomiaru czasu trwania miękkich nawigacji, jak i przypisywania danych do prawidłowej nawigacji. Zalecamy korzystanie z tego nowego interfejsu API pomimo braku obsługi w różnych przeglądarkach. Podobnie jak w przypadku wprowadzenia Core Web Vitals, zidentyfikowane problemy i rozwiązania dotyczące wydajności prawdopodobnie będą 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ć, jak ważny jest ten interfejs API.

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 i jesteśmy zachęceni potencjałem tego interfejsu API.

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.