Dążenie do lepszych danych dotyczących reagowania

Poznaj nasze przemyślenia na temat pomiaru responsywności i prześlij nam swoją opinię.

Zespół Chrome Speed Metrics pomaga lepiej zrozumieć, jak szybko strony internetowe reagują na działania użytkowników. Chcielibyśmy podzielić się kilkoma pomysłami na poprawę wskaźników czasu reakcji i poznać Twoją opinię.

Ten post obejmuje 2 główne tematy:

1. Zapoznaj się z naszym obecnym wskaźnikiem czasu reakcji – opóźnieniem przy pierwszym działaniu (FID) i wyjaśnij, dlaczego wybraliśmy FID zamiast niektórych innych opcji.
2. Przedstaw pewne ulepszenia, które według naszych ustaleń powinny lepiej wychwycić całkowite opóźnienia poszczególnych zdarzeń. Te ulepszenia pozwalają też uzyskać bardziej całościowy obraz ogólnej responsywności strony przez cały okres jej działania.

Co to jest opóźnienie przy pierwszym działaniu?

Opóźnienie przy pierwszym działaniu (FID) określa, ile czasu zajmuje przeglądarce rozpoczęcie przetwarzania pierwszej interakcji użytkownika na stronie. W szczególności mierzy różnicę między czasem interakcji użytkownika z urządzeniem a czasem, w którym przeglądarka może rozpocząć przetwarzanie modułów obsługi zdarzeń. FID jest mierzony tylko w przypadku naciśnięć i naciśnięć klawiszy, co oznacza, że uwzględnia tylko pierwsze wystąpienie tych zdarzeń:

• click
• keydown
• mousedown
• pointerdown (tylko jeśli występuje po nim pointerup)

Poniższy diagram przedstawia FID:

FID nie uwzględnia czasu potrzebnego na uruchomienie tych modułów obsługi zdarzeń ani żadnej czynności wykonywanej przez przeglądarkę w późniejszym czasie przy aktualizowaniu ekranu. Mierzy czas, przez jaki wątek główny był zajęty, zanim możliwe będzie przetworzenie danych wejściowych. Ten czas blokowania jest zwykle spowodowany długimi zadaniami JavaScript, ponieważ nie można ich w dowolnym momencie zatrzymać. Dlatego bieżące zadanie musi zostać ukończone, zanim przeglądarka zacznie przetwarzać dane wejściowe.

Dlaczego wybraliśmy FID?

Uważamy, że należy mierzyć rzeczywiste wrażenia użytkownika, aby mieć pewność, że poprawa wskaźnika przynosi rzeczywiste korzyści dla użytkownika. Zdecydowaliśmy się na pomiar FID, ponieważ stanowi on część wrażeń użytkownika, gdy postanawia wejść w interakcję z właśnie wczytaną stroną. FID rejestruje czas, przez jaki użytkownik musi czekać na odpowiedź z interakcji z witryną. Inaczej mówiąc, FID to dolna granica czasu oczekiwania użytkownika po interakcji.

Inne wskaźniki, takie jak Total Block Time (TBT) i Czas do interakcji (TTI), opierają się na długich zadaniach i np. FID mierzą też czas blokowania głównego wątku podczas wczytywania. Ponieważ te dane można mierzyć zarówno w terenie, jak i w laboratorium, wielu deweloperów pyta, dlaczego nie wolimy żadnego z nich niż FID.

Istnieje kilka przyczyn tej sytuacji. Być może najważniejszym powodem jest to, że dane te nie mierzą bezpośrednio wrażeń użytkownika. Wszystkie te wskaźniki mierzą, jak bardzo JavaScript jest uruchomiony na stronie. Długo działający kod JavaScript zwykle powoduje problemy w witrynach, ale te zadania nie wpływają negatywnie na wrażenia użytkownika, gdy użytkownik nie wchodzi w interakcję ze stroną. Strona może mieć bardzo dobry wynik w przypadku TBT i technologii TTI, ale jest powolna lub może mieć niski wynik, a użytkownicy szybko się wczytują. Jak wynika z naszego doświadczenia, te pośrednie pomiary dają wyniki, które sprawdzają się w przypadku niektórych witryn, ale nie w większości. Krótko mówiąc, długie zadania i algorytm TTI nie są skupione na użytkowniku, co sprawia, że ich słabości.

Pomiary laboratoryjne są z pewnością ważne i nieocenione w przypadku diagnostyki, jednak tak naprawdę chodzi o to, jak użytkownicy korzystają z witryn. Jeśli podasz dane na temat użytkowników, które odzwierciedlają rzeczywiste warunki, na pewno uda Ci się określić coś miłego. Zdecydowaliśmy się zacząć od ułamka, choć wiemy, że nie jest to reprezentatywna część. Dlatego staramy się rejestrować dłuższy czas oczekiwania użytkownika na przetworzenie danych wejściowych.

Jakie ulepszenia rozważamy?

Chcemy opracować nowy rodzaj danych, który rozszerza dotychczasowe pomiary FID, a jednocześnie zachowuje silny związek z wrażeniami użytkowników.

Chcemy, aby nowe dane:

1. Bierz pod uwagę responsywność wszystkich danych wejściowych użytkownika (nie tylko pierwszego).
2. Rejestruj cały czas trwania każdego zdarzenia (a nie tylko opóźnienie).
3. Możesz grupować zdarzenia, które są częścią tej samej logicznej interakcji użytkownika, i określać czas oczekiwania dla tej interakcji jako maksymalny czas trwania wszystkich jej zdarzeń.
4. Utwórz zbiorczy wynik dla wszystkich interakcji, które wystąpiły na stronie w całym jej cyklu życia.

Aby odnieść sukces, musimy z dużą pewnością stwierdzić, że witryna, która uzyskuje słabe wyniki w tych nowych danych, nie reaguje szybko na interakcje użytkowników.

Rejestruj cały czas trwania wydarzenia

Pierwszą oczywistą poprawą jest próba uchwycenia większego pełnego opóźnienia zdarzenia. Jak wspomnieliśmy powyżej, FID rejestruje tylko opóźnienie zdarzenia wejściowego. Nie uwzględnia czasu potrzebnego przeglądarce na rzeczywiste przetworzenie modułów obsługi zdarzeń.

W cyklu życia zdarzenia występują różne etapy, co pokazano na tym diagramie:

Oto kroki, które Chrome wykonuje w celu przetworzenia danych wejściowych:

1. Informacje podawane przez użytkownika Godzina, o której ma to miejsce, to timeStamp zdarzenia.
2. Przeglądarka przeprowadza testy, aby ustalić, do której ramki HTML (ramki głównej czy elementu iframe) należy zdarzenie. Następnie przeglądarka wysyła zdarzenie do odpowiedniego procesu renderowania, który zarządza daną ramką HTML.
3. Mechanizm renderowania odbiera zdarzenie i umieszcza je w kolejce, aby mógł zostać przetworzony, gdy stanie się dostępny.
4. Mechanizm renderowania przetwarza zdarzenie, uruchamiając odpowiednie moduły obsługi. Mogą one umieszczać w kolejce dodatkowe zadania asynchroniczne, np. setTimeout i pobrania, które są częścią obsługi danych wejściowych. Jednak w tym momencie praca synchroniczna jest już ukończona.
5. Na ekranie jest malowana ramka, która odzwierciedla efekt działania modułów obsługi zdarzeń. Pamiętaj, że wszystkie asynchroniczne zadania umieszczone w kolejce przez moduły obsługi zdarzeń mogą nadal być nieukończone.

Czas między krokami (1) a (3) powyżej jest opóźnieniem zdarzenia, które jest mierzone przez FID.

Czas między krokami (1) i (5) powyżej to czas trwania zdarzenia. To właśnie będzie mierzyć nasz nowy wskaźnik.

Czas trwania zdarzenia obejmuje opóźnienie, ale obejmuje też pracę wykonywane w modułach obsługi zdarzeń oraz zadania, które przeglądarka musi wykonać, aby wyrenderować następną ramkę po uruchomieniu tych modułów. Czas trwania zdarzenia jest obecnie dostępny w interfejsie Event Timing API w atrybucie duration wpisu.

Grupowanie zdarzeń w interakcje

Rozszerzenie pomiaru danych z opóźnienia na czas trwania to dobry pierwszy krok, ale i tak zostawia krytyczną lukę w danych: koncentruje się na indywidualnych zdarzeniach, a nie na wrażeniach użytkowników związanych ze stroną.

Pojedyncza interakcja użytkownika może wywołać wiele różnych zdarzeń, a każdy z nich osobno nie da nam wglądu w działania użytkownika. Chcemy mieć pewność, że nasz wskaźnik rejestruje cały czas, przez jaki użytkownik musi czekać na odpowiedź po dotknięciu, naciskaniu klawiszy, przewijaniu i przeciąganiu. Aby mierzyć czas oczekiwania każdej z nich, wprowadzamy interakcje.

Typ interakcji

W tabeli poniżej znajdziesz 4 interakcje, które chcesz zdefiniować, wraz ze zdarzeniami DOM, z którymi są powiązane. Zwróć uwagę, że nie jest to dokładnie tak samo jak zbiór wszystkich zdarzeń, które są wysyłane w momencie interakcji użytkownika. Na przykład gdy użytkownik przewija stronę, zdarzenie przewijania jest wysyłane, ale ma miejsce po zaktualizowaniu ekranu, aby odzwierciedlał przewijanie. Nie uznajemy go więc za część opóźnienia interakcji.

Pierwsze 3 interakcje wymienione powyżej (klawiatura, dotknięcie i przeciąganie) są obecnie objęte przez FID. W przypadku naszego nowego wskaźnika responsywności chcemy też uwzględnić przewijanie, ponieważ jest ono niezwykle powszechne w internecie i ma kluczowe znaczenie dla reagowania strony na potrzeby użytkowników.

Klawiatura

Interakcja z klawiaturą składa się z 2 części: momentu, gdy użytkownik naciśnie klawisz i go puści. Z tą interakcją użytkownika są powiązane 3 zdarzenia: keydown, keyup i keypress. Poniższy diagram przedstawia opóźnienia i czasy trwania keydown i keyup dla interakcji z klawiaturą:

Na powyższym schemacie czasy trwania są rozłączone, ponieważ ramka z aktualizacji keydown jest wyświetlana przed wystąpieniem keyup, ale nie musi tak być zawsze. Dodatkowo pamiętaj, że w mechanizmie renderowania klatka może wyświetlić się w trakcie zadania, ponieważ ostatnie kroki niezbędne do utworzenia ramki są wykonywane poza tym mechanizmem.

keydown i keypress występują, gdy użytkownik naciśnie klawisz, a keyup – gdy użytkownik zwolni klucz. Zasadniczo główna aktualizacja treści ma miejsce po naciśnięciu klawisza – na ekranie pojawia się tekst lub stosowany jest efekt modyfikatora. Chcemy jednak uwzględniać rzadkie przypadki, w których keyup również przedstawia interesujące aktualizacje interfejsu. Chcemy więc przyjrzeć się ogólnemu czasowi.

Aby określić ogólny czas potrzebny na działanie klawiatury, możemy obliczyć maksymalny czas trwania zdarzeń keydown i keyup.

Naciśnij

Kolejna ważna interakcja to kliknięcie przez niego strony internetowej. Podobnie jak w przypadku keypress, niektóre zdarzenia są wywoływane, gdy użytkownik naciska przycisk w dół, a inne w miarę ich zwalniania. Jak widać na przykładzie powyżej. Zdarzenia związane z dotknięciem na komputerze są nieco inne niż na urządzeniu mobilnym.

Kliknięcie wersji zwykle wywołuje większość reakcji, ale, podobnie jak w przypadku interakcji z klawiaturą, chcemy zarejestrować pełną interakcję. W tym przypadku jest to ważniejsze, ponieważ aktualizacje interfejsu pojawiają się po naciśnięciu.

Chcielibyśmy uwzględnić czasy trwania wszystkich tych zdarzeń, ale ponieważ wiele z nich w pełni się pokrywa, musimy uwzględnić tylko pointerdown, pointerup i click, aby uwzględnić pełną interakcję.

Opór

Zdecydowaliśmy się też uwzględnić przeciąganie, ponieważ wiąże się to z podobnymi zdarzeniami i zwykle powoduje ważne aktualizacje interfejsu użytkownika w witrynach. Jednak w przypadku naszych danych chcemy brać pod uwagę tylko początek i koniec przeciągania, czyli początkowe i końcowe fragmenty przeciągania. Ułatwia to radzenie sobie z wynikami analizy i ułatwia porównanie czasu oczekiwania z innymi uwzględnianymi interakcjami. Jest to zgodne z naszą decyzją o wykluczeniu zdarzeń ciągłych, takich jak mouseover.

Nie uwzględniamy też przeciągania implementowanych za pomocą interfejsu Drag and Drop API, ponieważ działają one tylko na komputerach.

Przewijanie

Jedną z najczęstszych form interakcji z witryną jest przewijanie. W przypadku naszych nowych danych chcemy mierzyć czas oczekiwania na pierwszą interakcję użytkownika, który polega na przewijaniu. Szczególnie zwracamy uwagę na początkową reakcję przeglądarki na fakt, że użytkownik poprosił o przewinięcie. Nie omówimy całego procesu przewijania. Oznacza to, że podczas przewijania strony powstaje wiele klatek. Skupiamy się na pierwszej klatce wygenerowanej w wyniku reakcji na przewijanie.

Dlaczego tylko pierwsza? W przypadku jednej z nich kolejne klatki mogą być przechwytywane w oddzielnej ofercie pakietowej dotyczącej płynności. Oznacza to, że gdy użytkownik zobaczy pierwszy wynik przewijania, reszta musi być mierzona pod kątem płynności przewijania. Dlatego uważamy, że płynność działania można by to uchwycić. Dlatego, podobnie jak w przypadku FID, zależy nam na wrażeniach użytkownika: z jasnymi punktami w czasie i dla których możemy łatwo obliczyć czas oczekiwania. Przewijanie w całości odbywa się bez przerwy, więc nie zamierzamy w tym celu uwzględniać wszystkich informacji.

Po co więc mierzyć przewijanie? Zebrane w Chrome dane o wydajności przewijania świadczą o tym, że przewijanie jest zwykle bardzo szybkie. Nadal jednak z różnych powodów chcemy uwzględniać w naszym nowym wskaźniku początkowe opóźnienia przewijania. Po pierwsze, przewijanie jest szybkie tylko dlatego, że zostało dostatecznie zoptymalizowane, ponieważ jest bardzo ważne. Istnieją jednak sposoby na ominięcie niektórych korzyści płynących z wydajności przeglądarki. Najczęstszym elementem w Chrome jest wymuszanie przewijania w wątku głównym. Nasze dane powinny więc określać, kiedy ma to miejsce, i sprawia, że przewijanie jest przez użytkowników niskiej wydajności. Po drugie przewijanie jest po prostu zbyt ważne, aby je ignorować. Obawiamy się, że jeśli wykluczymy przewijanie, mamy do czynienia z dużym słabym obszarem, który może z czasem się zmniejszyć, a programiści nie zauważą odpowiednio.

Istnieje kilka zdarzeń wysyłanych, gdy użytkownik przewija stronę, np. touchstart, touchmove i scroll. Z wyjątkiem zdarzenia przewijania zależy to w dużej mierze od urządzenia używanego do przewijania: zdarzenia dotyku są wysyłane podczas przewijania palcem na urządzeniach mobilnych, a pokrętła – przy używaniu kółka myszy. Zdarzenia przewijania są wywoływane po zakończeniu wstępnego przewijania. Ogólnie rzecz biorąc, zdarzenia DOM nie blokują przewijania, chyba że witryna używa niepasywnych detektorów zdarzeń. Uważamy więc, że przewijanie jest całkowicie oddzielone od zdarzeń DOM. Chcemy zmierzyć czas od momentu, w którym użytkownik rusza się wystarczająco dużo, aby wykonać gest przewijania, do momentu, gdy pojawi się pierwsza klatka pokazująca przewijanie.

Jak zdefiniować opóźnienie interakcji?

Jak już wspomnieliśmy, interakcje z komponentami „w dół” i „w górę” trzeba rozpatrywać osobno, aby uniknąć przypisania czasu, który użytkownik spędził na przytrzymaniu palca w dół.

W przypadku tego typu interakcji czas oczekiwania powinien uwzględniać czas trwania wszystkich powiązanych z nimi zdarzeń. Czasy trwania zdarzeń w poszczególnych częściach interakcji mogą się pokrywać, dlatego najprostszą definicją czasu oczekiwania na interakcję, która pozwala na osiągnięcie takiego progu, jest maksymalny czas trwania dowolnego powiązanego z nim zdarzenia. Jeśli wspomnimy o schemacie klawiatury z poprzedniego momentu, to będzie to długość keydown, ponieważ jest ona większa niż keyup:

Czasy trwania keydown i keyup również mogą się pokrywać. Może się tak zdarzyć, np. gdy klatka prezentowana w przypadku obu zdarzeń jest taka sama jak na tym diagramie:

Takie podejście ma swoje wady i zalety. Chętnie poznamy Twoją opinię:

• Za: jest to zgodne ze sposobem, w jaki zamierzamy mierzyć przewijanie, ponieważ mierzy tylko 1 wartość czasu trwania.
• Zaleta: ma na celu zmniejszenie szumu w przypadkach takich jak interakcje z klawiaturą, gdy keyup zwykle nie wykonuje żadnego działania i gdzie użytkownik może nacisnąć i wycisnąć klawisz szybko lub powoli.
• Wada: nie rejestruje pełnego czasu oczekiwania użytkownika. Na przykład zarejestruje ono początek i koniec przeciągania, ale nie oba te elementy jednocześnie.

W przypadku przewijania (które ma tylko jedno powiązane zdarzenie) czas oczekiwania to czas potrzebny przeglądarce na utworzenie pierwszej klatki w wyniku przewijania. Oznacza to, że czas oczekiwania to różnica między zdarzeniem timeStamp pierwszego zdarzenia DOM (np. touchmove, jeśli używasz palca), która jest wystarczająco duża, aby wywołać przewijanie, a pierwszym wyrenderowaniem, które odzwierciedla to przewijanie.

Agreguj wszystkie interakcje na stronie

Po określeniu czasu oczekiwania interakcji musimy obliczyć łączną wartość wczytania strony, która może obejmować wiele interakcji użytkownika. Dane zbiorcze pozwalają nam:

• Korelacje z danymi biznesowymi.
• Ocena korelacji z innymi danymi o skuteczności. W idealnej sytuacji nasz nowy wskaźnik będzie na tyle niezależny, aby wnosił wartość do dotychczasowych danych.
• Udostępniaj wartości w narzędziach w łatwy sposób.

Aby przeprowadzić taką agregację, musimy odpowiedzieć na 2 pytania:

1. Jakie liczby staramy się zebrać?
2. Jak zbieramy te dane?

Analizujemy i oceniamy kilka opcji. Chętnie poznamy Twoją opinię na temat tej agregacji.

Jedną z opcji jest określenie budżetu na czas oczekiwania na interakcję, który może zależeć od jej typu (przewinięcie, klawiatura, kliknięcie lub przeciągnięcie). Jeśli np. budżet kliknięć wynosi 100 ms, a czas oczekiwania na kliknięcie 150 ms, ponad budżet tej interakcji wynosi 50 ms. Następnie możemy obliczyć maksymalny czas oczekiwania, który przekracza budżet na dowolną interakcję użytkownika na stronie.

Inna opcja to obliczenie średniego lub mediany czasu oczekiwania interakcji w trakcie działania strony. Jeśli więc czas oczekiwania wynosi 80 ms, 90 ms i 100 ms, średni czas oczekiwania na stronę wynosi 90 ms. Możemy też wziąć pod uwagę średnią lub medianę wartości „powyżej budżetu”, by uwzględnić różne oczekiwania w zależności od typu interakcji.

Jak to wygląda w przypadku internetowych interfejsów API?

Czego brakuje w czasie zdarzeń?

Nie wszystkie pomysły przedstawione w tym poście można przedstawić za pomocą interfejsu Event Timing API. W szczególności nie ma prostego sposobu sprawdzania zdarzeń powiązanych z daną interakcją użytkownika za pomocą interfejsu API. W tym celu zaproponujemy dodanie do interfejsu API interactionID.

Innym wadą interfejsu Event Timing API jest to, że nie można mierzyć interakcji z przewijaniem, dlatego pracujemy nad włączeniem tych pomiarów (za pomocą Event Timing lub osobnego interfejsu API).

Co możesz teraz wypróbować?

W tej chwili nadal można obliczać maksymalny czas oczekiwania przy dotknięciu/przeciągnięciu i interakcjach z klawiaturą. Poniższy fragment kodu generuje te 2 rodzaje danych.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

Prześlij opinię

Powiedz nam, co myślisz o tych pomysłach, wysyłając e-maila na adres web-vitals-feedback@googlegroups.com.