Eksperymentowanie z pomiarami poręcznej nawigacji

Barry Pollard

Yoav Weiss

Od momentu wprowadzenia inicjatywy dotyczącej podstawowych wskaźników internetowych celem było pomiar rzeczywistych wrażeń użytkowników witryny, a nie technicznych szczegółów jej tworzenia lub wczytywania. 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 tworzenia witryny nie powinna wpływać na jej ocenę, o ile tylko witryna działa prawidłowo.

Rzeczywistość jest zawsze nieco bardziej skomplikowana niż ideał, a popularna architektura aplikacji jednostronicowej nigdy nie była w pełni obsługiwana przez wskaźniki podstawowe wskaźniki internetowe. Zamiast wczytywania osobnych stron internetowych podczas nawigacji po witrynie te aplikacje internetowe korzystają z tzw. „miękkiej nawigacji”, w której treści strony są zmieniane 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 umożliwić działanie przycisków Wstecz i Dalej zgodnie z oczekiwaniami użytkownika.

Wiele platform JavaScript korzysta z tego modelu, ale każda w inny sposób. Ponieważ nie jest to coś, co przeglądarka tradycyjnie rozumie jako „stronę”, pomiar był zawsze trudny: gdzie przebiega granica między interakcją na bieżącej stronie a uwzględnieniem jej jako nowej strony?

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). Chociaż wciąż jesteśmy na wczesnym etapie, nasz zespół jest gotowy udostępnić już wdrożone rozwiązania większej liczbie witryn, aby mogły one z nich korzystać. Dzięki temu właściciele witryn będą mogli przekazywać opinie na temat dotychczasowego podejścia.

Co to jest miękka nawigacja?

Oto nasza definicja miękkiej nawigacji:

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

W przypadku niektórych witryn te heurystyki mogą prowadzić do fałszywie pozytywnych wyników (gdy użytkownicy nie uznają, że nastąpiła „nawigacja”) lub fałszywie negatywnych wyników (gdy użytkownicy uznają, że nastąpiła „nawigacja”, mimo że nie spełniają tych kryteriów). Zachęcamy do dzielenia się opiniami na temat heurystyk w repozytorium specyfikacji nawigacji miękkiej.

Jak Chrome implementuje łagodną nawigację?

Po włączeniu heurystyki łagodnej nawigacji (więcej informacji znajdziesz w następnej sekcji) Chrome zmieni sposób raportowania niektórych danych dotyczących skuteczności:

• Po wykryciu każdej nawigacji dodatkowej będzie emitowane zdarzenie soft-navigation PerformanceTiming.
• Interfejs Performance API udostępnia dostęp do pozycji soft-navigation w ramach okna czasowego, które jest emitowane przez zdarzenie soft-navigation PerformanceTiming.
• Dane pierwszego wyrenderowania (FP), pierwszego wyrenderowania treści (FCP) i największego wyrenderowania treści (LCP) zostaną zresetowane i wyemitowane ponownie przy następnym wystąpieniu. (Uwaga: nie są wdrażane formaty FP i FCP).
• Do każdego z czasów wykonania (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event i layout-shift) odpowiadającego wpisowi nawigacyjnemu, z którym jest powiązane zdarzenie, zostanie dodany atrybut navigationId, który umożliwi obliczenie skumulowanego przesunięcia układu (CLS) i czasu od interakcji do następnego wyrenderowania (INP).

Te zmiany umożliwią pomiar podstawowych wskaźników internetowych (oraz niektórych powiązanych danych diagnostycznych) na podstawie liczby stron, które użytkownik otworzył, ale należy wziąć pod uwagę pewne niuanse.

Jakie są konsekwencje włączenia miękkiej 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. Raport na temat użytkowania Chrome (CrUX) zignoruje te dodatkowe wartości, ale może to wpłynąć na monitorowanie w Twojej witrynie za pomocą usługi Real User Measurement (RUM). Jeśli masz wątpliwości, czy to wpłynie na te pomiary, skontaktuj się z dostawcą usługi RUM. Zapoznaj się z sekcją dotyczącą pomiaru podstawowych wskaźników internetowych w przypadku łagodnej nawigacji.
• Nowy (opcjonalny) atrybut navigationID w rekordach wydajności może wymagać uwzględnienia w kodzie aplikacji, która korzysta z tych rekordów.
• Ten nowy tryb będą obsługiwać tylko przeglądarki oparte na Chromium. 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, że niektórzy użytkownicy mogą nie generować danych o łatwej nawigacji.
• Ponieważ jest to nowa funkcja eksperymentalna, która nie jest domyślnie włączona, witryny powinny przetestować tę funkcję, aby mieć pewność, że nie ma żadnych innych niezamierzonych skutków ubocznych.

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ć płynne przewijanie w Chrome?

Domyślnie w Chrome nie są one włączone, ale można je wypróbować, jeśli się je włączy.

Deweloperzy mogą włączyć tę funkcję, włączając flagę Eksperymentalne funkcje 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.

Jak mogę mierzyć łagodną nawigację?

Gdy eksperyment z miękką nawigacją zostanie włączony, dane będą jak zwykle raportowane za pomocą interfejsu API PerformanceObserver. W przypadku tych danych należy jednak wziąć pod uwagę kilka dodatkowych kwestii.

Zgłaszanie nawigacji łagodnych

Aby obserwować nawigację miękką, możesz użyć PerformanceObserver. Oto przykładowy fragment kodu, który rejestruje w konsoli wpisy dotyczące nawigacji łagodnej, w tym poprzednie nawigacje łagodne na tej stronie za pomocą opcji buffered:

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

Możesz go użyć do ukończenia pomiarów strony w całym okresie jej wyświetlania w przypadku poprzedniej ścieżki nawigacyjnej.

Raportowanie danych na podstawie 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 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;

Wartości pageUrl należy używać do raportowania danych pod adresem URL, który jest właściwy w danym momencie, a nie pod adresem URL, który był używany w przeszłości.

Korzystanie z startTime łagodnej 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;

Wartość startTime to czas początkowej interakcji (np. kliknięcia przycisku), która zainicjowała nawigację miękką.

Wszystkie czasy działania, w tym czasy działania związane z miękką nawigacją, są podawane jako czas od momentu początkowej „twardej” nawigacji po stronie. Dlatego czas rozpoczęcia nawigacji miękkiej jest potrzebny do ustalenia wartości referencyjnych czasów wczytywania nawigacji miękkiej (np. LCP) w porównaniu z czasem nawigacji miękkiej.

Pomiar podstawowych wskaźników internetowych na podstawie łagodnej 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 nadal będą zwracane zgodnie z pierwotnym „dokładnym” czasem rozpoczęcia nawigacji. Aby obliczyć LCP dla nawigacji łagodnej, musisz wziąć czas LCP i odjąć od niego odpowiedni czas rozpoczęcia nawigacji łagodnej, który omówiliśmy wcześniej. 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ą zwykle mierzone przez cały okres istnienia strony. Są to na przykład LCP, które mogą zmieniać się do momentu interakcji z reklamą. Wartości CLS i INP można aktualizować, dopóki nie przejdziesz na inną stronę. Dlatego każda „nawigacja” (w tym pierwotna nawigacja) może wymagać finalizacji danych o poprzedniej stronie w miarę występowania nowej nawigacji dodatkowej. Oznacza to, że początkowe „twarde” dane dotyczące nawigacji mogą zostać sfinalizowane wcześniej niż zwykle.

Podobnie, gdy zaczniesz mierzyć dane w ramach nowej elastycznej nawigacji tych długotrwałych danych, trzeba je „zresetować” lub „ponownie zainicjować” i traktować jako nowe dane, bez pamięci o wartościach ustawionych w przypadku poprzednich „stron”.

Jak należy traktować treści, które pozostają takie same w różnych miejscach nawigacji?

W przypadku łagodnej nawigacji wskaźniki FP, FCP i LCP będą uwzględniać tylko nowe animacje. Może to prowadzić do różnych LCP, np. od wczytywania „na zimno” podczas nawigacji po łagodnym ekranie.

Weźmy na przykład stronę, która zawiera duży obraz banera będący elementem LCP, ale tekst pod nią zmienia się z każdym nowym elementem nawigacji. Podczas początkowego wczytywania strony obraz banera zostanie oznaczony jako element LCP, a czas LCP zostanie określony na jego podstawie. 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 wczytuje się nowa strona z linkiem do strony docelowej w ramach miękkiej nawigacji, obraz banera będzie nowym elementem, który może zostać uznany za element LCP.

Jak widać w tym przykładzie, element LCP w przypadku łagodnej nawigacji może być raportowany inaczej w zależności od sposobu wczytywania strony. Podobnie wczytanie strony z linkiem kotwicy niżej na stronie może spowodować, że element LCP będzie inny.

Jak mierzyć TTFB?

Czas do pierwszego bajta (TTFB) w przypadku zwykłego wczytania strony to czas, jaki upływa od momentu wysłania pierwotnego żądania do momentu zwrócenia pierwszych bajtów.

To pytanie jest bardziej skomplikowane niż w przypadku miękkiej nawigacji. Czy powinniśmy mierzyć pierwsze żądanie wysłane do 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 wysłane z wyprzedzeniem za pomocą funkcji pobierania w tle? Co się stanie, jeśli żądanie niezwiązane z łatwością nawigacji z perspektywy użytkownika (np. dotyczące statystyk)?

Prostszą metodą jest raportowanie wartości TTFB 0 w przypadku łagodnej nawigacji – podobnie jak 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 udostępnić bardziej precyzyjne sposoby określania, które żądanie jest „żądaniem nawigacyjnym” w ramach miękkiej nawigacji, i uzyskać dokładniejsze pomiary TTFB. Nie jest to jednak część obecnego eksperymentu.

Jak mierzyć zarówno starą, jak i nową wersję?

W trakcie tego eksperymentu zalecamy dalsze pomiary podstawowych wskaźników internetowych w dotychczasowy sposób, opierając się na „twardej” nawigacji na stronach, tak aby były zgodne z danymi, które CrUX będzie mierzyć i uwzględniać w raportach jako oficjalny zbiór danych w ramach inicjatywy Core Web Vitals.

Oprócz tego należy mierzyć płynne przejścia, aby można było zobaczyć, jak można je mierzyć w przyszłości, oraz dać możliwość przekazania zespołowi Chrome opinii na temat tego, jak ta implementacja działa w praktyce. Pomoże to Tobie i zespołowi Chrome rozwijać ten interfejs API.

Aby mierzyć oba te wskaźniki, musisz wiedzieć, jakie nowe zdarzenia mogą być generowane w trybie miękkiej nawigacji (np. liczne zdarzenia FCP i dodatkowe zdarzenia LCP) i odpowiednio je obsługiwać, finalizując te dane w odpowiednim momencie, a także ignorując przyszłe zdarzenia, które dotyczą tylko miękkiej 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 ten sposób (z odpowiednią wymianą wartości 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 wspomniano wcześniej).

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

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

Ten eksperyment dotyczący nawigacji jest dokładnie tym, czym się wydaje – eksperymentem. Zanim podejmiemy decyzję o włączeniu tej funkcji do inicjatywy dotyczącej podstawowych wskaźników internetowych, chcemy sprawdzić, czy heurystyka dokładniej odzwierciedla wrażenia użytkowników. Cieszymy się z możliwości tego eksperymentu, ale nie możemy zagwarantować, czy i kiedy zastąpi on obecne pomiary.

Cenimy opinie web developerów na temat eksperymentu, użytej heurystyki i tego, czy ich zdaniem lepiej odzwierciedla ona działanie. Opinie na temat łagodnej nawigacji najlepiej przesyłać do repozytorium GitHub. Poszczególne błędy w implementacji w Chrome należy zgłaszać w śledzeniu 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 jest powiedziane, że będą one traktowane tak samo jak obecne „twarde” elementy nawigacyjne.

Na niektórych stronach internetowych łagodna nawigacja jest niemal identyczna z wczytywaniem całych stron, a wykorzystanie technologii aplikacji na jednej stronie to tylko jeden z elementów implementacji. W innych przypadkach mogą one przypominać częściowe wczytywanie dodatkowych treści.

Dlatego możemy zdecydować się na raportowanie tych miękkich przejść osobno w raporcie CrUX lub nadać im większą wagę podczas obliczania podstawowych wskaźników internetowych dla danej strony lub grupy stron. W miarę ulepszania heurystyki możemy też całkowicie wykluczyć częściowe wczytywanie nawigacji.

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ę

Aktywnie zbieramy opinie na temat tego eksperymentu w tych miejscach:

• Heurystyka i standardyzacja nawigacji miękkiej.
• Problemy z implementacją tych heurystyk w Chrome
• ogólne opinie na temat Core Web Vitals 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. Ten eksperyment jest jeszcze na wczesnym etapie i przed nami jeszcze wiele pracy, ale udostępnienie dotychczasowych wyników szerszej społeczności internetowej jest ważnym krokiem. Zbieranie 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ł reprezentatywny dla tego, co chcemy dzięki temu zmierzyć.

Podziękowania

Obraz miniatury autorstwa Jordan Madrid na Unsplash