Dążenie do lepszych danych dotyczących reagowania

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

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

Ważne: ten artykuł został napisany w okresie, w którym opracowano nowe dane dotyczące reagowania na potrzeby pomiaru pełnego opóźnienia na stronach internetowych. Te nowe dane zostały opublikowane i noszą nazwę Interakcje z kolejnym wyrenderowaniem (INP). Poza tym INP oficjalnie zastąpiło opóźnienie przy pierwszej próbie (FID) i jest teraz podstawowym wskaźnikiem dotyczącym wskaźników internetowych.

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.

Uwaga: jeśli chcesz bardziej szczegółowo przeanalizować niektóre dane, zapoznaj się z tymi badaniami i na temat technologii TTI.

Uwaga na temat pomiaru TTI w terenie

Pomiar TTI rzeczywistych użytkowników w tym polu jest problematyczny, ponieważ ma miejsce bardzo późno w trakcie wczytywania strony. Przed obliczeniem funkcji TTI wymagane jest 5-sekundowe okno cichej sieci. W module możesz wyładowywać stronę, gdy masz już wszystkie potrzebne dane, ale jest to niemożliwe w przypadku monitorowania rzeczywistych użytkowników w polu. Użytkownik może w każdej chwili opuścić stronę lub skorzystać z niej. W szczególności użytkownicy mogą opuścić strony, które długo się ładują, a dokładny tekst TTI nie zostanie wtedy zarejestrowany. Podczas pomiaru TTI rzeczywistych użytkowników w Chrome odkryliśmy, że tylko około połowa wczytywanych stron osiągnęła tryb TTI.

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.

Uwaga na temat zadań asynchronicznych

Najlepiej byłoby zarejestrować też asynchroniczną pracę wywoływaną przez to zdarzenie. Problem polega jednak na tym, że definicja pracy asynchronicznej aktywowanej przez to zdarzenie jest wyjątkowo trudna do przeanalizowania. Deweloper może na przykład rozpocząć animację w modułach obsługi zdarzeń, a do jej uruchomienia użyć setTimeout. Gdyby przechwycono wszystkie zadania opublikowane w modułach obsługi, animacja byłaby opóźniona o czas zakończenia. Uważamy, że warto zapoznać się z możliwościami użycia heurystyki do rejestrowania asynchronicznej pracy, którą należy wykonać jak najszybciej. Musimy jednak bardzo ostrożnie to robić, ponieważ nie chcemy nakładać kary na pracę, której wykonanie znacznie trwa długo. Dlatego na początku jako punkt końcowy przyjrzymy się krok 5: będzie brać pod uwagę tylko pracę synchroniczną oraz czas potrzebny na malowanie po ich zakończeniu. Oznacza to, że nie stosujemy heurystyki do odgadnięcia, jakie czynności na początku zostałyby rozpoczęte asynchronicznie w kroku 4.

Warto zauważyć, że w wielu przypadkach zadania powinny być wykonywane synchronicznie. W rzeczywistości może to być nie do uniknięcia, ponieważ zdarzenia są czasami wysyłane jeden po drugim, a moduły obsługi zdarzeń muszą być wykonywane w określonej kolejności. Nadal nie będziemy jednak pomijać ważnych zadań, na przykład zdarzeń, które uruchamiają pobieranie lub wymagają ważnej pracy do wykonania podczas następnego wywołania zwrotnego funkcji requestAnimationFrame.

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

Ważne: te treści w tej sekcji zostały napisane w czasie, gdy projekt „Interaction to Next Paint (INP) był jeszcze w fazie rozwoju. Aktualne dane tylko uwzględniają zdarzenia z klawiatury, myszy i dotyku, ale nie uwzględniają najechania ani przewijania przy obliczaniu INP.

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.

Zdarzenia DOM dla każdego typu interakcji.

Interakcja	Początek / koniec	Zdarzenia na komputerach	Zdarzenia na urządzeniach mobilnych
Klawiatura	Naciśnięto klawisz	keydown	keydown
		keypress	keypress
	Klucz został zwolniony	keyup	keyup
Kliknij lub przeciągnij	Kliknij „Rozpocznij” lub rozpocznij przeciąganie	pointerdown	pointerdown
		mousedown	touchstart
	Kliknij w górę lub przeciągnij koniec	pointerup	pointerup
		mouseup	touchend
		click	mousedown
			mouseup
			click
Przewiń	Nie dotyczy

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.

Notatka na początku i na końcu

Zwróć uwagę, że każda z tych interakcji składa się z 2 części: gdy użytkownik naciśnie mysz, palec lub przycisk w dół, oraz gdy podniesie urządzenie. Chcemy mieć pewność, że nasze dane nie zliczają czasu, który użytkownik spędził na przytrzymaniu palca w dół między tymi 2 działaniami w ramach opóźnienia strony.

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.

Uwaga: zdarzenie keypress zostało wycofane. Należy je uruchamiać w tym samym zadaniu co zdarzenie keydown, więc jego czas trwania będzie zawsze pokrywał się z czasem trwania zdarzenia keydown.

Uwaga na temat powtarzających się naciśnięć klawiszy

Warto tu wspomnieć o skrajnym przypadku: może się zdarzyć, że użytkownik naciśnie klawisz i jego zwolnienie trwa trochę czasu. W takiej sytuacji sekwencja wysyłanych zdarzeń może się zmieniać. W takich przypadkach bierzemy pod uwagę 1 interakcję na keydown, która może, ale nie musi, mieć odpowiadającego jej 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ę.

Czy możemy zawęzić wyniki tylko do pointerdown i pointerup?

Na początku warto użyć zdarzeń pointerdown i pointerup oraz założyć, że obejmują one wszystkie przedziały czasu, które nas interesują. Niestety tak nie jest, co pokazuje przypadek skrajny. Spróbuj otworzyć tę stronę na urządzeniu mobilnym lub za pomocą emulacji urządzenia mobilnego i kliknąć „Kliknij mnie”. Ta witryna uruchamia opóźnienie kliknięcia w przeglądarce. Jak widać, pointerdown, pointerup i touchend są wysyłane szybko, natomiast mousedown, mouseup i click czekają na opóźnienie przed wysłaniem. Oznacza to, że jeśli przyjrzymy się tylko pointerdown i pointerup, przegapimy czas trwania zdarzeń syntetycznych, który jest duży ze względu na opóźnienie kliknięcia w przeglądarce i należy go uwzględnić. Powinniśmy więc mierzyć wskaźniki 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 [e-mail].