Eksperymentowanie z pomiarami poręcznej nawigacji

Barry Pollard

Yoav Weiss

Od czasu uruchomienia inicjatywa dotycząca podstawowych wskaźników internetowych ma na celu zmierzenie faktycznego doświadczenia użytkownika strony internetowej, a nie zmierzenia szczegółów technicznych związanych z tworzeniem lub wczytywaniem strony. Trzy Podstawowe wskaźniki internetowe zostały utworzone jako dane dotyczące użytkowników i stanowią ewolucję w porównaniu z dotychczasowymi danymi technicznymi, takimi jak DOMContentLoaded czy load, które mierzyły czasy, które nie były związane z sposobem postrzegania wydajności strony przez użytkowników. Dlatego technologia użyta do utworzenia witryny nie powinna wpływać na jej ocenę, ponieważ witryna będzie działać dobrze.

Rzeczywistość zawsze jest nieco trudniejsza niż idealna, a popularna architektura aplikacji jednostronicowych nigdy nie była w pełni poparta danymi dotyczącymi Podstawowych wskaźników internetowych. Zamiast wczytywać odrębne, pojedyncze strony w czasie, gdy użytkownik porusza się po witrynie, aplikacje te korzystają z tak zwanych „miękkich elementów nawigacyjnych”, w których treść strony jest zmieniana przez JavaScript. W tych aplikacjach można utrzymać iluzję konwencjonalnej architektury stron internetowych przez zmianę adresu URL i przeniesienie wcześniejszych adresów URL z 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 w inny sposób. Jest to coś poza tym, co przeglądarka tradycyjnie uznaje za „stronę”, dlatego pomiar tego zawsze był trudny: gdzie jest granica między interakcją na bieżącej stronie a czy traktować ją jako nową?

Zespół Chrome już od jakiegoś czasu zastanawia się nad tym wyzwaniem i zastanawia się nad ujednoliceniem definicji „łagodnej nawigacji” oraz sposobów pomiaru podstawowych wskaźników internetowych w sposób analogiczny do pomiaru skuteczności witryn w tradycyjnej architekturze wielostronicowej (MPA). Choć wciąż są na wczesnym etapie, zespół jest już gotowy do szerzej zakrojonego udostępniania witrynom implementacji rozwiązań już wdrożonych w ramach eksperymentów. Dzięki temu właściciele witryn będą mogli przekazywać opinie na temat dotychczasowego podejścia.

Czym jest łagodna nawigacja?

Oto definicja miękkiej nawigacji:

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

W przypadku niektórych witryn taka heurystyka może prowadzić do fałszywych trafień (które użytkownicy nie uznaliby za „nawigację”), lub wyników fałszywie negatywnych (gdy użytkownik uzna, że doszło do „nawigacji”, mimo że nie spełnia tych kryteriów). Chętnie poznamy opinie na temat heurystyki w repozytorium specyfikacji miękkiej nawigacji.

Jak Chrome implementuje łagodną nawigację?

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

• Po wykryciu każdej nawigacji dodatkowej będzie emitowane zdarzenie soft-navigation PerformanceTiming.
• Interfejs Performance API zapewni dostęp do wpisu czasu soft-navigation wygenerowanego przez zdarzenie soft-navigation PerformanceTiming.
• Wskaźniki Pierwsze wyrenderowanie (FP), Pierwsze wyrenderowanie treści (FCP) i Największe wyrenderowanie treści (LCP) zostaną zresetowane i ponownie wyemitowane przy kolejnych odpowiednich wystąpieniach tych zdarzeń. (Uwaga: FP i FCP nie są zaimplementowane).
• Do każdego z czasów skuteczności (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event i layout-shift) powiązanych z wpisem nawigacji, z którym było powiązane zdarzenie, zostanie dodany atrybut navigationId, co umożliwi obliczenie skumulowanego przesunięcia układu (CLS) i interakcji z następnym wyrenderowaniem (INP).

Dzięki tym zmianom podstawowe wskaźniki internetowe – i niektóre powiązane z nimi dane diagnostyczne – będą mierzone w przypadku każdej nawigacji na stronie. Trzeba jednak wziąć pod uwagę pewne niuanse.

Jakie jest skutki włączenia łagodnej nawigacji w Chrome?

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

• Dodatkowe zdarzenia FP, FCP i LCP mogą być ponownie wysyłane w przypadku łagodnej nawigacji. Te dodatkowe wartości zostaną zignorowane w Raporcie na temat użytkowania Chrome, ale może to mieć wpływ na monitorowanie pomiaru rzeczywistych użytkowników w Twojej witrynie. Jeśli masz wątpliwości, czy będzie to miało wpływ na te pomiary, skontaktuj się z dostawcą RUM. Zapoznaj się z sekcją dotyczącą pomiaru podstawowych wskaźników internetowych w przypadku łagodnej nawigacji.
• Może być konieczne uwzględnienie nowego (i opcjonalnego) atrybutu navigationID we wpisach dotyczących wydajności w kodzie aplikacji.
• Tylko przeglądarki oparte na Chromium będą obsługiwać ten nowy tryb. Choć wiele z nowszych danych jest dostępnych tylko w przeglądarkach opartych na Chromium, niektóre (FCP, LCP) są dostępne w innych przeglądarkach, a nie każdy użytkownik mógł zaktualizować przeglądarkę do najnowszej wersji. Pamiętaj więc, że niektórzy użytkownicy mogą nie zgłaszać danych dotyczących łagodnej nawigacji.
• Jest to nowa, eksperymentalna funkcja, która nie jest domyślnie włączona, dlatego witryny powinny ją przetestować, aby mieć pewność, że nie wystąpią inne niezamierzone efekty uboczne.

Więcej informacji o mierzeniu danych dotyczących łagodnej nawigacji znajdziesz w sekcji na temat pomiaru podstawowych wskaźników internetowych na potrzeby nawigacji.

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

Łatwa nawigacja nie jest domyślnie włączona w Chrome, ale możesz ją przetestować, gdy włączysz tę funkcję.

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

Jak mogę mierzyć łagodną nawigację?

Po włączeniu eksperymentu z bezproblemową nawigacją dane będą raportowane za pomocą interfejsu API PerformanceObserver w zwykły sposób. W kontekście tych danych należy jednak wziąć pod uwagę kilka dodatkowych kwestii.

Zgłoś łagodną nawigację

Aby obserwować łagodną nawigację, możesz użyć: PerformanceObserver. Poniżej znajduje się przykładowy fragment kodu, który rejestruje w konsoli wpisy opcjonalnej nawigacji, w tym poprzednie nawigacje na tej stronie przy użyciu opcji buffered:

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

Może ona służyć do finalizacji danych dotyczących całego cyklu życia strony w poprzedniej nawigacji.

Raportowanie danych z użyciem odpowiedniego adresu URL

Ponieważ łagodna nawigacja jest widoczna dopiero po wystąpieniu tego zdarzenia, niektóre dane muszą zostać sfinalizowane w momencie wystąpienia zdarzenia, a następnie raportowane dla poprzedniego adresu URL, ponieważ bieżący URL będzie teraz odzwierciedlać zaktualizowany adres URL nowej strony.

Za pomocą atrybutu navigationId odpowiedniej PerformanceEntry można powiązać zdarzenie z prawidłowym adresem URL. Możesz sprawdzić te problemy 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;

Interfejs pageUrl służy do raportowania danych w odniesieniu do prawidłowego adresu URL, a nie aktualnego adresu URL, który mógł być używany w przeszłości.

Korzystanie z startTime łagodnej nawigacji

Godzina 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 nawigację do ekranu.

Wszystkie okresy działania, w tym te związane z łagodną nawigacją, są raportowane jako czas od początkowego „pełnego” czas nawigacji na stronie. W związku z tym czas rozpoczęcia łagodnej nawigacji jest potrzebny do uzyskania wartości odniesienia przy pomiarze czasu wczytywania łagodnej nawigacji (np. LCP) w odniesieniu do tego czasu łagodnego nawigacji.

Pomiar podstawowych wskaźników internetowych w przypadku miękkiej nawigacji

Aby uwzględnić wpisy danych dotyczących łagodnej nawigacji, musisz uwzględnić parametr 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 łagodnej nawigacji w Chrome potrzebna jest dodatkowa flaga includeSoftNavigationObservations w metodzie observe. Ta wyraźna zgoda na poziomie obserwatora wydajności ma na celu zapewnienie, że obecni obserwatorzy wydajności nie są zaskoczeni tymi dodatkowymi wpisami. Przy próbie pomiaru podstawowych wskaźników internetowych w przypadku łagodnej nawigacji należy wziąć pod uwagę kilka dodatkowych kwestii.

Czasy są nadal zwracane w odniesieniu do oryginalnego „twardego” elementu czasu rozpoczęcia nawigacji. Aby więc obliczyć na przykład LCP dla łagodnej nawigacji, musisz zmierzyć czas LCP i odejmij odpowiedni czas rozpoczęcia łagodnej nawigacji zgodnie omówionych wcześniej. W ten sposób uzyskasz czas względem łagodnej nawigacji. Na przykład dla 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ą zwykle mierzone przez cały okres istnienia strony. Przykład: LCP może się zmieniać, dopóki nie nastąpi interakcja. CLS i INP można aktualizować, dopóki nie przejdziesz na inną stronę. Dlatego każda „nawigacja” (w tym oryginalnej nawigacji) może wymagać finalizacji danych o poprzedniej stronie w miarę następowania każdej nowej nawigacji dodatkowej. Oznacza to, że początkowy „twardy” mogą być finalizowane wcześniej niż zwykle.

I podobnie, gdy zaczniesz mierzyć dane na potrzeby nowej, łagodnej nawigacji po tych długoterminowych danych, trzeba będzie je zresetować. lub „ponownie zainicjowano” i traktowane jako nowe dane bez pamięci wartości ustawionych dla poprzednich „stron”.

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

FP, FCP i LCP w przypadku łagodnej nawigacji będą mierzyć tylko nowe wyrenderowania. Może to prowadzić do różnych LCP, np. od wczytywania „na zimno” podczas nawigacji po łagodnym ekranie.

Weźmy na przykład stronę, na której znajduje się duży obraz banera będący elementem LCP, ale tekst pod nią zmienia się z każdą łagodną nawigacją. Początkowe wczytanie strony oznaczy obraz banera jako element LCP i będzie bazować na czasie LCP. Podczas następnej nawigacji podrzędnej tekst pod spodem będzie największym elementem wyrenderowanym po przejściu do nawigacji za pomocą pilota i będzie nowym elementem LCP. Jeśli jednak nowa strona zostanie wczytana za pomocą precyzyjnego linku do adresu URL nawigacji, obraz banera zostanie pomalowany od nowa i będzie kwalifikować się do użycia jako element LCP.

Jak widać w tym przykładzie, element LCP dla miękkiej nawigacji może być raportowany na różne sposoby w zależności od sposobu wczytywania strony – tak jak w przypadku wczytywania strony z linkiem do kotwicy w dalszej części strony, co może spowodować wystąpienie innego elementu LCP.

Jak mierzyć dane TTFB?

Czas do pierwszego bajtu (TTFB) w przypadku konwencjonalnego wczytywania strony oznacza czas zwrócenia pierwszych bajtów pierwotnego żądania.

To pytanie jest bardziej skomplikowane niż w przypadku miękkiej nawigacji. Czy powinniśmy mierzyć pierwsze żądanie wysłane dla nowej strony? Co zrobić, jeśli wszystkie treści są już w aplikacji i nie ma dodatkowych żądań? Co się stanie, jeśli żądanie zostanie przesłane z wyprzedzeniem za pomocą pobierania z wyprzedzeniem? Co się stanie, jeśli żądanie niezwiązane z łatwością nawigacji z perspektywy użytkownika (np. dotyczące statystyk)?

Prostszą metodą jest zgłoszenie wartości 0 TTFB w przypadku łagodnej nawigacji – w sposób podobny do zalecanego w przypadku przywracania pamięci podręcznej stanu strony internetowej. Jest to metoda, której biblioteka web-vitals używa do łagodnej nawigacji.

W przyszłości możemy obsługiwać dokładniejsze sposoby sprawdzania, które żądanie jest „żądaniem nawigacji” funkcji nawigacji programowej. i będzie mieć możliwość dokładniejszego pomiaru TTFB. Nie jest to jednak część obecnego eksperymentu.

Jak mierzyć skuteczność starych i nowych?

W trakcie tego eksperymentu zalecamy dalsze pomiary podstawowych wskaźników internetowych w obecny sposób, w oparciu o „twarde” jak korzystać z nawigacji na stronie, tak aby były zgodne z danymi zmierzonymi przez CrUX i raportowanymi w ramach inicjatywy Podstawowe wskaźniki internetowe.

Oprócz nich należy też mierzyć przebieg nawigacji płynnej, aby przekonać się, jak można je mierzyć w przyszłości, oraz przekazać zespołowi Chrome opinię o tym, jak ta implementacja działa w praktyce. Pomoże to Tobie i zespołowi Chrome rozwijać ten interfejs API.

Aby mierzyć oba te zdarzenia, musisz wziąć pod uwagę nowe zdarzenia, które mogą być wywoływane w trybie miękkiej nawigacji (np. wiele zdarzeń FCP i dodatkowych LCP), i odpowiednio zareagować, finalizując te dane w odpowiednim momencie, oraz ignorując przyszłe zdarzenia, które będą stosowane tylko do łagodnej nawigacji.

Za pomocą biblioteki web-vitals możesz mierzyć podstawowe wskaźniki internetowe umożliwiające płynną nawigację

Najłatwiejszym sposobem uwzględnienia wszystkich niuansów jest użycie biblioteki JavaScript web-vitals, która ma eksperymentalną obsługę łagodnej nawigacji w osobnej sekcji soft-navs branch (dostępnej też w wersjach npm i unpkg). Można to mierzyć w następujący sposób (zastępując stosownie do sytuacji 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 na podstawie prawidłowego adresu URL jak już wspomnieliśmy.

Biblioteka web-vitals raportuje te dane na potrzeby łagodnej nawigacji:

Czy te zmiany zostaną uwzględnione w podstawowych wskaźnikach internetowych?

Ten eksperyment z miękką nawigacją jest właśnie eksperymentem. Zanim podejmiemy decyzję, czy uwzględnić te dane w programie dotyczącym podstawowych wskaźników internetowych, chcemy przeprowadzić ocenę heurystyki i zobaczyć, czy będą one dokładniej odzwierciedlać wrażenia użytkownika. Cieszymy się z możliwości tego eksperymentu, ale nie możemy zagwarantować, czy i kiedy zastąpi on obecne pomiary.

Cenimy współpracę z twórcami stron internetowych opinii na temat eksperymentu, zastosowanych metod heurystycznych oraz tego, czy Twoim zdaniem dane rozwiązanie lepiej odzwierciedla jego sytuację. Najlepsze miejsce na taką informację znajdziesz w repozytorium GitHub nawigacji, choć poszczególne błędy implementacji w Chrome należy zgłaszać w narzędziu do śledzenia problemów w Chrome.

W jaki sposób łagodna nawigacja będzie raportowana w CrUX?

Nadal nie wiemy, w jaki sposób będą one dokładnie raportowane w raporcie CrUX (jeśli ten eksperyment zakończy się powodzeniem). Nie musi to oznaczać, że będą traktowane tak samo jak obecne „twarde” lub funkcji nawigacji.

Na niektórych stronach internetowych łagodna nawigacja jest niemal identyczna z wczytywaniem całej strony z punktu widzenia użytkownika, a wykorzystanie technologii aplikacji jednostronicowej jest tylko kwestią implementacji. W innych można je porównać do częściowego wczytania dodatkowych treści.

Dlatego możemy je osobno raportować w raporcie CrUX lub przypisać im wagę przy obliczaniu podstawowych wskaźników internetowych w przypadku danej strony lub grupy stron. Możemy też być w stanie całkowicie wykluczyć częściową nawigację powolną, w miarę rozwoju heurystyki.

Zespół koncentruje się na implementacji heurystycznej i technicznej, co pozwoli nam ocenić sukces tego eksperymentu, dlatego nie podjęto jeszcze w tej kwestii decyzji.

Prześlij opinię

Opinie na temat tego eksperymentu przyjmujemy w następujących miejscach:

• Hurystyka i standaryzacja miękkiej nawigacji.
• Problemy z implementacją w Chrome wynikające z heurystyki.
• Ogólne opinie o Web Vitals wyślij e-maila na adres web-vitals-feedback@googlegrouops.com.

Historia zmian

Ponieważ ten interfejs API jest w fazie eksperymentów, zachodzi w nim wiele zmian, bardziej niż w przypadku stabilnych interfejsów API. Więcej informacji znajdziesz w dzienniku zmian heurystyki miękkiej nawigacji.

Podsumowanie

Eksperyment dotyczący łagodnej nawigacji to ekscytujące podejście do dalszego rozwoju inicjatywy dotyczące podstawowych wskaźników internetowych w celu zmierzenia wspólnego wzorca we współczesnym internecie, którego brakuje w naszych danych. Chociaż eksperyment dopiero się rozpoczął i jest jeszcze wiele do zrobienia, udostępnianie dotychczasowych postępów szerszej społeczności internetowej w celu eksperymentowania jest ważnym krokiem. Gromadzenie opinii z tego eksperymentu jest kolejnym ważnym elementem eksperymentu, dlatego gorąco zachęcamy osoby zainteresowane tym rozwojem do skorzystania z tej możliwości do opracowania interfejsu API w taki sposób, aby był on reprezentatywny dla tego, co chcemy dzięki temu zmierzyć.

Podziękowania

Miniatura: Jordan Madrid na kanale Unsplash