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. 3 dane Core Web Vitals zostały stworzone jako dane zorientowane na użytkownika. Stanowią one rozwinięcie dotychczasowych danych technicznych, takich jak DOMContentLoaded lub load, które mierzyły czasy wczytywania, często niezwiązane z tym, jak użytkownicy postrzegali wydajność strony. 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 to samo, co „strona” w tradycyjnym rozumieniu przez przeglądarkę, pomiar tego zjawiska zawsze był trudny: gdzie przebiega granica między interakcją na bieżącej stronie a uwzględnieniem jej jako nowej strony?

Zespół Chrome od jakiegoś czasu pracuje nad rozwiązaniem tego problemu i próbuje ustandaryzować definicję „łatwej nawigacji” oraz sposób pomiaru podstawowych wskaźników internetowych w tym kontekście – podobnie jak w przypadku witryn wdrożonych w ramach konwencjonalnej architektury 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 przekazać opinię na temat dotychczasowego podejścia.

Co to jest miękka nawigacja?

Oto nasza definicja łagodnej 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łnia ona tych kryteriów). Zachęcamy do dzielenia się opiniami na temat heurystyk w repozytorium specyfikacji nawigacji miękkiej.

Jak Chrome implementuje nawigację miękką?

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 miękkiej nawigacji zostanie wyemitowane zdarzenie soft-navigation PerformanceTiming.
• Interfejs Performance API udostępnia dostęp do pozycji soft-navigation w ramach 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: FP i FCP nie są implementowane).
• Do każdego z czasów wykonania (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event i layout-shift) odpowiadającego pozycji nawigacyjnej, do której jest powiązane zdarzenie, zostanie dodany atrybut navigationId, co 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 niektóre zmiany, które właściciele witryn muszą wziąć pod uwagę po włączeniu tej funkcji:

• W przypadku łagodnej nawigacji mogą być ponownie wysyłane dodatkowe zdarzenia FP, FCP i LCP. 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.
• Ten nowy tryb będą obsługiwać tylko przeglądarki oparte na Chromium. Chociaż wiele nowych danych jest dostępnych tylko w przeglądarkach opartych na Chromium, niektóre z nich (FCP, LCP) są dostępne w innych przeglądarkach, a nie wszyscy użytkownicy mogą mieć zainstalowaną najnowszą wersję przeglądarki opartej na Chromium. 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 pomiarach dotyczących łagodnej nawigacji znajdziesz w sekcji dotyczącej pomiaru podstawowych wskaźników internetowych na podstawie łagodnej 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 je wyraźnie włączysz.

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 mierzyć nawigację miękką?

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 nieprawidłowej nawigacji

Możesz użyć PerformanceObserver, aby obserwować nawigację niejawną. 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 nawigacji.

Raportowanie danych na podstawie odpowiedniego adresu URL

Ponieważ przejścia miękkie można zobaczyć dopiero po ich wystąpieniu, niektóre dane zostaną sfinalizowane po tym zdarzeniu, a następnie ujęte w raportach dotyczących poprzedniego adresu URL, ponieważ bieżący adres URL będzie odzwierciedlać zaktualizowany adres URL nowej strony.

Atrybutu navigationId odpowiedniego zdarzenia PerformanceEntry można użyć do powiązania zdarzenia z odpowiednim 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 z użyciem prawidłowego adresu URL, a nie bieżącego adresu URL, który mógł być używany w przeszłości.

Pobieranie startTime łagodnych 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 łagodnej nawigacji, 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 o łatwej nawigacji, musisz użyć funkcji includeSoftNavigationObservations: true w wywołaniu observe obserwatora skutecznoś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 przy metodzie observe. Ta wyraźna zgoda na poziomie obserwatora wydajności ma na celu zapewnienie, że obecni obserwatorzy wydajności nie będą zaskoczeni tymi dodatkowymi wpisami, ponieważ podczas 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ą tradycyjnie mierzone przez cały czas istnienia strony: na przykład LCP może się zmieniać do momentu wystąpienia interakcji. Wartości CLS i INP można aktualizować do momentu, gdy użytkownik opuści stronę. Dlatego każda „nawigacja” (w tym pierwotna nawigacja) może wymagać ukończenia pomiarów poprzedniej strony po wystąpieniu każdej nowej nawigacji miękkiej. 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 dla 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 skutkować różnym czasem LCP, np. od wczytania tej miękkiej nawigacji w stanie zimnym do wczytania w stanie miękkim.

Weźmy na przykład stronę, która zawiera duży obraz banera, który jest elementem LCP, ale tekst pod nim zmienia się przy każdej zmianie strony. Podczas początkowego wczytywania strony obraz banera zostanie oznaczony jako element LCP, a czas LCP zostanie określony na jego podstawie. W przypadku kolejnych przejść miękkich tekst pod spodem będzie największym elementem wyświetlanym po przejściu miękkim 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.

W przypadku miękkiej nawigacji to bardziej skomplikowane pytanie. Czy powinniśmy mierzyć pierwsze żądanie wysłane do nowej strony? Co zrobić, jeśli wszystkie treści znajdują się już w aplikacji i nie ma dodatkowych próśb? Co się stanie, jeśli żądanie zostanie wysłane z wyprzedzeniem za pomocą funkcji pobierania w tle? Co zrobić, jeśli żądanie nie jest związane z miękką nawigacją z perspektywy użytkownika (np. jest to żądanie dotyczące analityki)?

Prostszą metodą jest raportowanie wartości TTFB 0 w przypadku łagodnej nawigacji – podobnie jak w przypadku przywracania pamięci podręcznej stanu strony internetowej. Ta metoda jest używana przez bibliotekę web-vitals do nawigacji miękkiej.

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ę?

Podczas tego eksperymentu zalecamy dalsze pomiary podstawowych wskaźników internetowych w obecny sposób, czyli na podstawie „twardego” przechodzenia między stronami, aby uzyskać zgodność z danymi, które CrUX będzie mierzyć i przekazywać jako oficjalny zbiór danych w ramach inicjatywy dotyczącej podstawowych wskaźników internetowych.

Oprócz tych pomiarów należy mierzyć też pomiary łagodnego przewijania, aby można było zobaczyć, jak można je mierzyć w przyszłości, oraz dać Ci 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 w dalszym kształtowaniu interfejsu 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 mają zastosowanie tylko do miękkiej nawigacji.

Korzystanie z biblioteki web-vitals do pomiaru podstawowych wskaźników internetowych w przypadku łagodnej nawigacji

Najłatwiej uwzględnić wszystkie niuanse, używając biblioteki JavaScript web-vitals, która ma eksperymentalne wsparcie dla miękkiej nawigacji w osobnym pliku soft-navs branch (dostępnym też w npm i unpkg). Można to mierzyć w taki 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 dotyczące miękkiej 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 przeprowadzenia 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.

Jak będą raportowane przejścia pośrednie w raporcie na temat użytkowania Chrome?

W przypadku powodzenia tego eksperymentu nadal nie wiadomo, jak dokładnie będzie raportowana w CrUX nawigacja pośrednia. Nie jest powiedziane, że będą traktowane tak samo jak obecne „twarde” elementy nawigacyjne.

Na niektórych stronach internetowych nawigacja miękka jest dla użytkownika prawie identyczna z załadowaniem całej strony, a używanie technologii aplikacji jednostronicowej to tylko szczegół implementacji. W innych przypadkach mogą one przypominać częściowe wczytywanie dodatkowych treści.

Dlatego możemy zdecydować się na raportowanie tych łagodnych przejść osobno w 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ć miękką nawigację z częściowym wczytywaniem.

Zespół koncentruje się na implementacji heurystycznej i technicznej, która pozwoli nam ocenić powodzenie tego eksperymentu, więc nie podjęliśmy jeszcze żadnych decyzji w tych kwestiach.

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 dotyczące funkcji Core Web Vitals na adres web-vitals-feedback@googlegrouops.com;

Historia zmian

Ten interfejs API jest w fazie eksperymentalnej, dlatego wprowadzamy w nim więcej zmian niż w przypadku stabilnych interfejsów API. Więcej informacji znajdziesz w Changelogu dotyczącym heurystyk miękkiej nawigacji.

Podsumowanie

Eksperyment dotyczący łagodnej nawigacji to ekscytujące podejście do tego, jak inicjatywa dotycząca podstawowych wskaźników internetowych może się rozwijać, aby mierzyć typowy w dzisiejszym internecie wzorzec, 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 na temat tego eksperymentu to kolejna ważna część eksperymentu, dlatego zachęcamy osoby zainteresowane tą funkcją do skorzystania z tej okazji i poinformowania nas o tym, co chcieliby zmierzyć za pomocą interfejsu API.

Podziękowania

Obraz miniatury autorstwa Jordan Madrid na Unsplash