Eksperymentowanie z pomiarami poręcznej nawigacji

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

Od momentu wprowadzenia inicjatywy „Podstawowe wskaźniki internetowe” jej celem było umożliwienie pomiaru rzeczywistych wrażeń użytkowników strony, a nie kwestii technicznych związanych z tworzeniem lub ładowaniem strony internetowej. 3 podstawowe wskaźniki internetowe zostały utworzone jako dane dotyczące użytkowników. To ewolucja dotychczasowych danych technicznych, np. DOMContentLoaded i load, które mierzyły czasy, które często nie mają związku z tym, jak użytkownicy postrzegają wydajność strony. Z tego względu technologia użyta do stworzenia witryny nie powinna wpływać na ocenę, zapewniając jej dobrą skuteczność.

Rzeczywistość zawsze bywa nieco trudniejsza niż idealna, a popularna architektura aplikacji składających się z pojedynczych stron nigdy nie była w pełni obsługiwana przez podstawowe wskaźniki internetowe. Zamiast wczytywać osobne, poszczególne strony internetowe, gdy użytkownik porusza się po witrynie, te aplikacje korzystają z tzw. „pozornego nawigowania”, gdzie treść strony jest zmieniana przez kod JavaScript. W takich aplikacjach można uzyskać wrażenie tradycyjnej architektury stron internetowych, zmieniając URL i umieszczając poprzednie adresy w historii przeglądarki, dzięki czemu przyciski Wstecz i Dalej działają zgodnie z oczekiwaniami.

Z tego modelu korzysta wiele platform JavaScript, ale każda w inny sposób. Nie jest to coś, co przeglądarka zwykle rozumie jako „strona”, dlatego pomiar wyników zawsze był trudny. Gdzie należy narysować granicę między interakcją na bieżącej stronie, a czy uznanie jej za nową stronę?

Zespół Chrome już od jakiegoś czasu zastanawia się nad tym wyzwaniem i chce ujednolicić definicję tego, czym jest „miękka nawigacja” oraz sposób pomiaru podstawowych wskaźników internetowych. Chociaż zespół jest na wczesnym etapie rozwoju, zespół jest teraz gotowy do szerszego udostępnienia witrynom, które już zostały wdrożone, do eksperymentowania. Dzięki temu witryny będą mogły wyrazić opinię o podejściu do tej pory.

Czym jest łagodna nawigacja?

Opracowaliśmy następującą definicję pozornej nawigacji:

  • Nawigacja jest inicjowana przez działanie użytkownika.
  • Spowoduje to zmianę adresu URL widocznego dla użytkownika i zmianę historii.
  • Nawigacja powoduje zmianę DOM.

W przypadku niektórych witryn te statystyki heurystyczne mogą prowadzić do wyników fałszywie pozytywnych (które użytkownicy nie zdają sobie sprawy z nawigacji) lub wyników fałszywie negatywnych (gdy użytkownik uważa, że „nawigacja” miała miejsce pomimo niespełnienia tych kryteriów). Chętnie poznamy opinie na temat heurystyki w repozytorium miękkiej specyfikacji nawigacji.

W jaki sposób Chrome wdraża pozorną nawigację?

Po włączeniu heurystyki nawigacji pozornej (więcej na ten temat znajdziesz w następnej sekcji) Chrome zmieni sposób raportowania niektórych danych o wydajności:

Dzięki tym zmianom podstawowe wskaźniki internetowe – i niektóre powiązane z nimi dane diagnostyczne – będą mierzone w odniesieniu do każdego wyświetlenia strony. Trzeba jednak wziąć pod uwagę pewne niuanse.

Jakie są skutki włączenia pozornej nawigacji w Chrome?

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

  • Dodatkowe zdarzenia FP, FCP i LCP mogą być wysyłane ponownie w przypadku nawigacji pobocznej. Raport na temat użytkowania Chrome (CrUX) zignoruje te dodatkowe wartości, ale może to wpłynąć na monitorowanie pomiaru liczby użytkowników (RUM) w Twojej witrynie. Jeśli masz wątpliwości dotyczące tych pomiarów, skontaktuj się z dostawcą RUM. Zapoznaj się z sekcją poświęconą pomiarowi podstawowych wskaźników internetowych w przypadku uproszczonej nawigacji.
  • Może być konieczne uwzględnienie nowego (i opcjonalnego) atrybutu navigationID we wpisach dotyczących wydajności w kodzie aplikacji przy użyciu tych wpisów.
  • Ten nowy tryb będą obsługiwać tylko przeglądarki oparte na Chromium. Chociaż wiele z nowszych danych jest dostępnych tylko w przeglądarkach opartych na Chromium, niektóre z nich (FCP, LCP) są dostępne w innych przeglądarkach i nie wszyscy muszą zainstalować najnowszą wersję przeglądarek opartych na Chromium. Pamiętaj więc, że niektórzy użytkownicy mogą nie podawać danych pomocnych w nawigacji.
  • Jest to nowa, eksperymentalna funkcja, która nie jest domyślnie włączona. Witryny powinny ją testować, aby mieć pewność, że nie występują żadne inne niezamierzone efekty uboczne.

Więcej informacji o mierzeniu danych w przypadku uproszczonej nawigacji znajdziesz w sekcji na temat pomiaru podstawowych wskaźników internetowych w przypadku uproszczonej nawigacji.

Jak włączyć pozorną nawigację w Chrome?

Domyślnie układy nawigacyjne nie są włączone w Chrome, ale możesz je przetestować w Chrome 110 po jawnym włączeniu tej funkcji.

Deweloperzy mogą włączyć tę opcję, włączając flagę Eksperymentalnych funkcji platformy internetowej w chrome://flags/#enable-experimental-web-platform-features lub używając argumentu wiersza poleceń --enable-experimental-web-platform-features podczas uruchamiania Chrome.

W przypadku witryny, która chce włączyć tę funkcję u wszystkich użytkowników, można skorzystać z testowania origin w Chrome 117. Aby go włączyć, zarejestruj się w wersji próbnej i dodaj element meta z tokenem testowania origin w nagłówku HTML lub HTTP. Więcej informacji znajdziesz w poście Pierwsze kroki z testami origin.

Właściciele witryn mogą uwzględnić na swoich stronach wersję próbną origin u wszystkich lub tylko dla części użytkowników. Zapoznaj się z poprzednią sekcją na temat konsekwencji zmiany sposobu raportowania danych, zwłaszcza jeśli ten test dotyczący origin jest włączony w przypadku dużej części Twoich użytkowników. Pamiętaj, że raport na temat użytkowania Chrome będzie nadal raportować dane w dotychczasowy sposób niezależnie od tego ustawienia łatwej nawigacji, więc nie będzie to miało na nie wpływu. Pamiętaj też, że testy origin ograniczają się do włączenia funkcji eksperymentalnych w przypadku maksymalnie 0,5% wszystkich wczytań stron Chrome (wartość mediana w okresie 14 dni). Problem ten powinien jednak występować tylko w przypadku bardzo dużych witryn.

Jak mogę mierzyć uproszczoną nawigację?

Po włączeniu eksperymentu z nieskomplikowaną nawigację dane będą w zwykły sposób raportowane za pomocą interfejsu API PerformanceObserver. Istnieją jednak dodatkowe uwagi, które należy wziąć pod uwagę w odniesieniu do tych danych.

Raportuj uproszczoną nawigację

Możesz użyć aplikacji PerformanceObserver, aby obserwować łagodne nawigację. Poniżej znajduje się przykładowy fragment kodu, który rejestruje w konsoli wpisy nawigacyjne do łatwej nawigacji – łącznie z poprzednimi ekranami poręcznymi na tej stronie przy użyciu opcji buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Pozwoli to uzyskać ostateczne dane o całym okresie aktywności strony dla poprzedniego menu nawigacyjnego.

Raportuj dane dotyczące odpowiedniego adresu URL

Ponieważ uproszczona nawigacja jest widoczna dopiero po wystąpieniu zdarzenia, niektóre dane muszą zostać sfinalizowane po tym zdarzeniu, a potem raportowane w przypadku poprzedniego adresu URL, ponieważ bieżący URL będzie teraz odzwierciedlać zaktualizowany adres URL nowej strony.

Można użyć atrybutu navigationId odpowiedniego elementu PerformanceEntry, aby powiązać zdarzenie z prawidłowym adresem URL. 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;

Tej funkcji pageUrl należy używać do raportowania danych według prawidłowego adresu URL, a nie aktualnego adresu URL, którego mógł on używać w przeszłości.

Pobieram startTime pozornej nawigacji

Czas rozpoczęcia nawigacji można uzyskać w podobny sposób:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime to czas pierwszej interakcji (np. kliknięcia przycisku), która zainicjowała uproszczoną nawigację.

Wszystkie czasy wydajności, w tym te dotyczące uproszczonej nawigacji, są raportowane jako czas od początkowego „trudnego” czasu nawigacji na stronie. Dlatego czas rozpoczęcia łagodnej nawigacji jest potrzebny do wyznaczenia punktu odniesienia dla czasów wczytywania danych do łagodnej nawigacji (np. LCP) w odniesieniu do tego czasu.

Pomiar podstawowych wskaźników internetowych w przypadku ręcznej nawigacji

Aby uwzględnić wpisy danych pomocnych w nawigacji, musisz uwzględnić pole includeSoftNavigationObservations: true w wywołaniu observe obserwatora wydajności.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Oprócz włączenia funkcji pozornej nawigacji w Chrome wymagana jest dodatkowa flaga includeSoftNavigationObservations w metodzie observe. Taka wyraźna akceptacja na poziomie obserwatora wydajności ma na celu sprawdzenie, aby obecni obserwatorzy wydajności nie byli zaskoczeni dodatkowymi wpisami, ponieważ przy próbie pomiaru podstawowych wskaźników internetowych w przypadku uproszczonej nawigacji należy wziąć pod uwagę kilka dodatkowych kwestii.

Harmonogramy będą nadal podawane zgodnie z pierwotną „twardą” godziną rozpoczęcia nawigacji. Aby więc obliczyć LCP na przykład dla pozornej nawigacji, musisz uwzględnić czas LCP i odejmij odpowiedni czas rozpoczęcia płynnej nawigacji, jak opisano wcześniej. Pozwoli Ci to uzyskać czas w porównaniu do nawigacji pomocniczej. Na przykład w przypadku LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Niektóre dane są mierzone przez cały okres istnienia strony, np. LCP mogą się zmieniać, dopóki nie nastąpi interakcja z nią. CLS i INP można aktualizować, dopóki użytkownik nie opuści danej strony. Z tego względu każda nawigacja (w tym pierwotna nawigacja) może wymagać dopracowania danych poprzedniej strony, gdy zachodzi nowa uproszczona nawigacja. Oznacza to, że początkowe „trudne” dane dotyczące nawigacji mogą być finalizowane wcześniej niż zwykle.

Podobnie, gdy zaczniesz mierzyć dane związane z nową, uproszczoną nawigacji po tych długoterminowych danych, musisz je „zresetować” lub „ponownie zainicjować” i potraktować jako nowe dane, bez pamięci o wartościach ustawionych dla poprzednich „stron”.

Jak traktować treści, które pozostają takie same w elementach nawigacyjnych?

FP, FCP i LCP w przypadku łagodnej nawigacji mierzą tylko nowe operacje renderowania. Może to spowodować inny wskaźnik LCP, np. zimne wczytywanie podczas nawigowania w ramach niepowodzeń i przejście do kosza.

Weźmy na przykład stronę zawierającą duży baner będący elementem LCP, ale znajdujący się pod nim tekst zmienia się przy każdym poziomym nawigacji. Przy wstępnym wczytaniu strony obraz banera zostanie oznaczony jako element LCP i na tym będzie oparty czas LCP. W przypadku kolejnych uproszczonych nawigacji tekst poniżej będzie największym elementem wyrenderowanym po łagodnej nawigacji i będzie nowym elementem LCP. Jeśli jednak nowa strona zostanie wczytana za pomocą precyzyjnego linku prowadzącego do adresu URL do pozornego nawigacji, obraz banera zostanie wyrenderowany w nowy sposób i będzie kwalifikował się do uwzględnienia jako elementu LCP.

Jak pokazujemy w tym przykładzie, element LCP w uproszczonej nawigacji może być raportowany w różny sposób w zależności od sposobu wczytywania strony – tak samo jak w przypadku wczytywania strony z linkiem zakotwiczonym umieszczonym u dołu strony może spowodować utworzenie innego elementu LCP.

Jak mierzyć TTFB?

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

To pytanie jest nieco trudniejsze, jeśli chodzi o miękką nawigację. Czy mamy mierzyć pierwsze żądanie nowej strony? Co zrobić, jeśli cała treść jest już w aplikacji i nie ma żadnych dodatkowych próśb? Co zrobić, jeśli żądanie zostało przesłane z wyprzedzeniem za pomocą pobierania z wyprzedzeniem? Co się stanie, jeśli żądanie nie jest związane z funkcjonalną nawigacją z perspektywy użytkownika (na przykład jest to żądanie dotyczące statystyk)?

Prostszą metodą jest zgłoszenie wartości 0 TTFB w przypadku uproszczonej nawigacji w podobny sposób, jak w przypadku przywracania danych z pamięci podręcznej stanu strony internetowej. Jest to metoda używana obecnie przez bibliotekę web-vitals do uproszczenia nawigacji.

W przyszłości możemy wprowadzić dokładniejsze sposoby określania, które żądanie dotyczy „żądania nawigacji” w ramach funkcji nawigacji poręcznej, a tym samym uzyskać dokładniejsze pomiary dotyczące TTFB. Nie jest to jednak uwzględnione w obecnie przeprowadzanym eksperymencie.

Jak mierzyć zarówno stare, jak i nowe dane?

Zalecamy, aby w trakcie eksperymentu nadal mierzyć podstawowe wskaźniki internetowe w bieżący sposób na podstawie „trudnych” nawigacji na stronach. Pozwoli to dopasować dane, które CrUX będzie mierzyć i raportować jako oficjalny zbiór danych w ramach inicjatywy Podstawowe wskaźniki internetowe.

Warto też mierzyć stosowanie funkcji miękkich nawigacji, aby móc sprawdzać, jak w przyszłości będą one mierzone, a także przekazać zespołowi Chrome opinię na temat tego, jak ta implementacja działa w praktyce. Pomoże to Tobie i zespołowi Chrome kształtować interfejs API w przyszłości.

Aby mierzyć oba te rodzaje zdarzeń, musisz wiedzieć o nowych zdarzeniach, które mogą być wysyłane w trybie pozornej nawigacji (np. wielu zdarzeń FCP i dodatkowych zdarzeń LCP), i odpowiednio je obsługiwać, finalizując te dane w odpowiednim momencie, a jednocześnie ignorując przyszłe zdarzenia, które będą dotyczyć tylko nawigacji pomocniczej.

Używanie biblioteki web-vitals do pomiaru podstawowych wskaźników internetowych na potrzeby uproszczonej nawigacji

Najprostszym sposobem, aby uwzględnić wszystkie niuanse, jest użycie biblioteki JavaScript web-vitals, która ma eksperymentalną obsługę pogodnej nawigacji w oddzielnej sekcji soft-navs branch (która jest również dostępna w wersjach npm i unpkg). Można to zmierzyć w następujący sposób (zastępując odpowiednio doTraditionalProcessing i doSoftNavProcessing):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

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

Upewnij się, że dane są raportowane według prawidłowego adresu URL jak podano wcześniej.

Biblioteka web-vitals raportuje te dane dotyczące uproszczonej nawigacji:

Wskaźnik Szczegóły
TTFB Zgłoszona jako 0.
FCP Obecnie biblioteka web-vitals raportuje tylko pierwsze FCP strony.
LCP Czas następnego największego wyrenderowania treści w odniesieniu do czasu rozpoczęcia łagodnej nawigacji. Dotychczasowe wyrenderowania z poprzedniej nawigacji nie są brane pod uwagę. W związku z tym LCP będzie wynosić >= 0. Jak zwykle zostanie to odnotowane po interakcji lub gdy strona działa w tle, ponieważ tylko wtedy można sfinalizować LCP.
CLS Największe okno zmian między czasem nawigacji. Zwykle ma to miejsce, gdy strona działa w tle, ponieważ tylko wtedy można sfinalizować CLS. Jeśli nie ma zmian, raportowana jest wartość 0.
INP Wartość INP między czasami nawigowania. Jak zwykle jest to zgłaszane po interakcji lub gdy strona działa w tle, ponieważ tylko wtedy można sfinalizować INP. Jeśli nie ma interakcji, wartość 0 nie jest raportowana.

Czy te zmiany staną się częścią pomiarów podstawowych wskaźników internetowych?

To jest właśnie eksperyment z łagodną nawigacją. Przed podjęciem decyzji o uwzględnieniu tych danych w ramach inicjatywy „Podstawowe wskaźniki internetowe” chcemy ocenić wyniki heurystyki i sprawdzić, czy lepiej odzwierciedlają wrażenia użytkowników. Bardzo się cieszymy z możliwości tego eksperymentu, ale nie możemy zagwarantować, czy i kiedy zastąpi on dotychczasowe pomiary.

Cenimy opinie twórców stron internetowych na temat eksperymentu, użytej metody heurystyki i tego, czy Twoim zdaniem lepiej odzwierciedla to doświadczenie. Najlepiej przesłać opinię w repozytorium pozornej nawigacji na GitHubie. Wszelkie błędy w implementacji Chrome należy zgłaszać w narzędziu Chrome Issue Tracker.

W jaki sposób uproszczona nawigacja będzie raportowana w raporcie na temat użytkowania Chrome?

Sposób, w jaki dokładnie pojemne elementy nawigacyjne będą raportowane w CrUX, czy ten eksperyment zakończy się sukcesem, jeszcze nie został ustalony. Nie musi to oznaczać, że będą traktowane tak samo jak bieżące „twarde” nawigację.

Na niektórych stronach internetowych uproszczona nawigacja jest niemal taka sama jak w przypadku pełnego wczytania strony, a zastosowanie technologii aplikacji na jednej stronie to tylko szczegóły implementacji. W innych mogą być podobne do częściowego załadowania dodatkowych treści.

W związku z tym możemy uwzględnić te opcjonalne elementy nawigacyjne w raporcie CrUX oddzielnie lub nadać im wagi przy obliczaniu podstawowych wskaźników internetowych w przypadku danej strony lub grupy stron. W miarę rozwoju heurystyki możemy też całkowicie wykluczyć łatwą nawigację po częściowym załadowaniu.

Obecnie zespół koncentruje się na implementacji heurystycznej i technicznej, co pozwoli nam ocenić powodzenie tego eksperymentu, dlatego nie podjęliśmy żadnych decyzji w tych kwestiach.

Prześlij opinię

Czekamy na opinie na temat tego eksperymentu w tych miejscach:

Historia zmian

Ponieważ ten interfejs API jest w fazie eksperymentów, zachodzą w nim liczne zmiany, bardziej niż w przypadku stabilnych interfejsów API. Więcej informacji znajdziesz w Historii zmian heurystyki nawigacji pozornej.

Podsumowanie

Eksperyment z funkcjonalną nawigacją pokazuje, jak inicjatywa dotycząca podstawowych wskaźników internetowych może ewoluować, aby mierzyć wspólny wzorzec, którego obecnie nie ma w naszych danych. Chociaż eksperyment jeszcze się rozpoczął, a jeszcze wiele zostało do zrobienia, udostępnienie dotychczasowych postępów szerszej społeczności internetowej w celu przetestowania jest ważnym krokiem. Kolejną istotną częścią eksperymentu jest zbieranie opinii, dlatego gorąco zachęcamy wszystkich zainteresowanych tym rozwojem do skorzystania z możliwości, by pomóc nam ukształtować interfejs API i zapewnić jego reprezentatywność.

Podziękowania

Miniatura, której autorem jest Jordan Madrid w Unsplash