First Input Delay (FID)

Philip Walton

Wszyscy wiemy, jak ważne jest zrobienie dobrego pierwszego wrażenia. Jest to ważne podczas poznawania nowych osób, ale też podczas tworzenia stron internetowych.

W internecie dobre pierwsze wrażenie może zadecydować o tym, czy ktoś zostanie lojalnym użytkownikiem, czy opuści witrynę i nigdy do niej nie wróci. Pytanie brzmi: co sprawia, że pierwsze wrażenie jest dobre, i jak zmierzyć, jakie wrażenie wywierasz na użytkownikach?

W internecie pierwsze wrażenie może przybierać różne formy – może dotyczyć wyglądu i atrakcyjności wizualnej witryny, a także jej szybkości i czasu reakcji.

Za pomocą interfejsów API nie można zmierzyć, jak bardzo użytkownikom podoba się wygląd witryny, ale można zmierzyć jej szybkość i czas reakcji.

Pierwsze wrażenie użytkowników na temat szybkości wczytywania się witryny można zmierzyć za pomocą wskaźnika pierwsze wyrenderowanie treści (FCP). Szybkość, z jaką witryna może wyświetlać piksele na ekranie, to tylko część historii. Równie ważne jest to, jak elastyczna jest Twoja witryna, gdy użytkownicy próbują wchodzić w interakcje z tymi pikselami.

Wskaźnik opóźnienie przy pierwszym działaniu (FID) pomaga mierzyć pierwsze wrażenie użytkownika na temat interaktywności i czasu reakcji witryny.

Co to jest FID?

FID mierzy czas, jaki upływa od pierwszej interakcji użytkownika ze stroną (czyli od kliknięcia linku, dotknięcia przycisku lub użycia niestandardowego elementu sterującego JavaScript) do momentu, w którym przeglądarka może rozpocząć przetwarzanie procedur obsługi zdarzeń w odpowiedzi na tę interakcję.

Jaki jest dobry wynik FID?

Aby zadbać o wygodę użytkowników, witryny powinny mieć opóźnienie przy pierwszym działaniu wynoszące 100 milisekund lub mniej. Aby mieć pewność, że osiągasz ten cel w przypadku większości użytkowników, dobrym progiem do zmierzenia jest 75 percentyl wczytywania stron, podzielony na urządzenia mobilne i komputery.

Szczegółowe informacje o FID

Jako deweloperzy piszący kod, który reaguje na zdarzenia, często zakładamy, że nasz kod zostanie uruchomiony natychmiast – zaraz po wystąpieniu zdarzenia. Jako użytkownicy często doświadczamy jednak czegoś przeciwnego – wczytujemy stronę internetową na telefonie, próbujemy z nią wejść w interakcję, a potem frustrujemy się, gdy nic się nie dzieje.

Opóźnienie przy działaniu (inaczej opóźnienie wejścia) występuje zwykle dlatego, że główny wątek przeglądarki jest zajęty czymś innym i nie może (jeszcze) odpowiedzieć użytkownikowi. Jednym z częstych powodów może być to, że przeglądarka jest zajęta analizowaniem i wykonywaniem dużego pliku JavaScript wczytanego przez Twoją aplikację. W tym czasie nie może uruchamiać żadnych detektorów zdarzeń, ponieważ wczytywany kod JavaScript może nakazać jej wykonanie czegoś innego.

Oto oś czasu typowego wczytywania strony internetowej:

Powyższa wizualizacja przedstawia stronę, która wysyła kilka żądań sieciowych dotyczących zasobów (najprawdopodobniej plików CSS i JS), a po zakończeniu pobierania te zasoby są przetwarzane w wątku głównym.

Powoduje to okresy, w których wątek główny jest chwilowo zajęty, co jest oznaczone blokami zadań w kolorze beżowym zadań.

Długie opóźnienia przy pierwszym działaniu występują zwykle między pierwszym wyrenderowaniem treści (FCP) a czasem do pełnej interaktywności (TTI), ponieważ strona wyrenderowała część treści, ale nie jest jeszcze w pełni interaktywna. Aby zilustrować, jak to może się zdarzyć, do osi czasu dodano FCP i TTI:

Możesz zauważyć, że między FCP a TTI upływa sporo czasu (w tym trzy długie zadania). Jeśli w tym czasie użytkownik spróbuje wejść w interakcję ze stroną (np. klikając link), wystąpi opóźnienie między momentem otrzymania kliknięcia a momentem, w którym wątek główny będzie mógł zareagować.

Zastanów się, co by się stało, gdyby użytkownik spróbował wejść w interakcję ze stroną na początku najdłuższego zadania:

Ponieważ działanie występuje, gdy przeglądarka jest w trakcie wykonywania zadania, musi ona poczekać na jego zakończenie, zanim będzie mogła zareagować na działanie. Czas, jaki musi odczekać, to wartość FID dla tego użytkownika na tej stronie.

Co się stanie, jeśli interakcja nie ma detektora zdarzeń?

FID mierzy różnicę między momentem otrzymania zdarzenia wejścia a momentem, w którym wątek główny jest bezczynny. Oznacza to, że FID jest mierzony nawet w przypadkach, gdy nie zarejestrowano detektora zdarzeń. Dzieje się tak, ponieważ wiele interakcji użytkownika nie wymaga detektora zdarzeń, ale wymaga bezczynności wątku głównego, aby można było je uruchomić.

Na przykład wszystkie te elementy HTML muszą poczekać na zakończenie zadań w toku w wątku głównym, zanim będą mogły zareagować na interakcje użytkownika:

• Pola tekstowe, pola wyboru i przyciski opcji (<input>, <textarea>)
• Listy rozwijane (<select>)
• Linki (<a>)

Dlaczego należy brać pod uwagę tylko pierwsze działanie?

Opóźnienie przy każdym działaniu może pogorszyć wygodę użytkowników, ale z kilku powodów zalecamy mierzenie przede wszystkim opóźnienia przy pierwszym działaniu:

• Opóźnienie przy pierwszym działaniu będzie pierwszym wrażeniem użytkownika na temat czasu reakcji witryny, a pierwsze wrażenia mają kluczowe znaczenie dla kształtowania ogólnego wrażenia na temat jakości i niezawodności witryny.
• Największe problemy z interaktywnością, które obserwujemy obecnie w internecie, występują podczas wczytywania strony. Dlatego uważamy, że początkowe skupienie się na poprawie pierwszej interakcji nowego użytkownika z witryną będzie miało największy wpływ na poprawę ogólnej interaktywności internetu.
• Zalecane rozwiązania dotyczące tego, jak witryny powinny radzić sobie z dużymi opóźnieniami przy pierwszym działaniu (dzielenie kodu, wczytywanie mniejszej ilości kodu JavaScript z góry itp.), niekoniecznie są tymi samymi rozwiązaniami, które pozwalają naprawić powolne opóźnienia przy działaniu po wczytaniu strony. Dzięki rozdzieleniu tych danych będziemy mogli przekazywać deweloperom bardziej szczegółowe wskazówki dotyczące wydajności.

Co zalicza się do pierwszego działania?

FID to wskaźnik, który mierzy czas reakcji strony podczas wczytywania. W związku z tym koncentruje się tylko na zdarzeniach wejścia pochodzących z dyskretnych działań, takich jak kliknięcia, dotknięcia i naciśnięcia klawiszy.

Inne interakcje, takie jak przewijanie i powiększanie, to działania ciągłe, które mają zupełnie inne ograniczenia wydajności (ponadto przeglądarki często mogą ukrywać opóźnienie, uruchamiając je w osobnym wątku).

Innymi słowy, FID koncentruje się na R (czasie reakcji) w modelu wydajności RAIL, natomiast przewijanie i powiększanie są bardziej związane z A (animacją), a ich jakość wydajności należy oceniać osobno.

Co się stanie, jeśli użytkownik nigdy nie wejdzie w interakcję z Twoją witryną?

Nie wszyscy użytkownicy będą wchodzić w interakcję z Twoją witryną za każdym razem, gdy ją odwiedzą. Ponadto nie wszystkie interakcje są istotne dla FID (jak wspomnieliśmy w poprzedniej sekcji). Dodatkowo pierwsze interakcje niektórych użytkowników będą miały miejsce w nieodpowiednich momentach (gdy wątek główny jest zajęty przez dłuższy czas), a pierwsze interakcje niektórych użytkowników będą miały miejsce w odpowiednich momentach (gdy wątek główny jest całkowicie bezczynny).

Oznacza to, że niektórzy użytkownicy nie będą mieli wartości FID, niektórzy będą mieli niskie wartości FID, a niektórzy prawdopodobnie będą mieli wysokie wartości FID.

Sposób śledzenia, raportowania i analizowania FID będzie prawdopodobnie znacznie różnił się od innych danych, do których możesz być przyzwyczajony. W następnej sekcji wyjaśniamy, jak to zrobić.

Dlaczego należy brać pod uwagę tylko opóźnienie przy działaniu?

Jak wspomnieliśmy powyżej, FID mierzy tylko „opóźnienie” w przetwarzaniu zdarzeń. Nie mierzy ani całkowitego czasu przetwarzania zdarzenia, ani czasu potrzebnego przeglądarce na zaktualizowanie interfejsu po uruchomieniu procedur obsługi zdarzeń.

Chociaż ten czas jest ważny dla użytkownika i wpływa na jego wrażenia, nie jest on uwzględniany w tym wskaźniku, ponieważ mogłoby to zachęcać deweloperów do dodawania obejść, które w rzeczywistości pogarszają wrażenia użytkowników. Mogliby oni np. opakować logikę procedury obsługi zdarzeń w asynchroniczne wywołanie zwrotne (za pomocą setTimeout() lub requestAnimationFrame()), aby oddzielić ją od zadania powiązanego ze zdarzeniem. W rezultacie wskaźnik uległby poprawie, ale reakcja byłaby wolniejsza z punktu widzenia użytkownika.

Chociaż FID mierzy tylko „opóźnienie” w opóźnieniu zdarzenia, deweloperzy którzy chcą śledzić więcej informacji o cyklu życia zdarzenia, mogą to zrobić za pomocą interfejsu Event Timing API. Więcej informacji znajdziesz w przewodniku po danych niestandardowych metrics.

Jak mierzyć FID

FID to wskaźnik, który można mierzyć tylko w warunkach rzeczywistych, ponieważ wymaga interakcji prawdziwego użytkownika ze stroną. FID możesz mierzyć za pomocą tych narzędzi:

Narzędzia do pomiarów w warunkach rzeczywistych

• Raport na temat użytkowania Chrome
• PageSpeed Insights
• Search Console (raport Core Web Vitals)
• web-vitals Biblioteka JavaScript

Pomiar FID w JavaScript

Aby mierzyć FID w JavaScript, możesz użyć interfejsu Event Timing API. Poniższy przykład pokazuje, jak utworzyć PerformanceObserver który nasłuchuje wpisów first-input i rejestruje je w konsoli:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

W powyższym przykładzie wartość opóźnienia wpisu first-input jest mierzona przez obliczenie różnicy między sygnaturami czasowymi startTime i processingStart wpisu. W większości przypadków będzie to wartość FID, ale nie wszystkie wpisy first-input są prawidłowe do pomiaru FID.

W sekcji poniżej znajdziesz listę różnic między tym, co raportuje interfejs API, a sposobem obliczania wskaźnika.

Różnice między wskaźnikiem a interfejsem API

• Interfejs API będzie wysyłać wpisy first-input w przypadku stron wczytanych na karcie w tle, ale te strony należy ignorować podczas obliczania FID.
• Interfejs API będzie też wysyłać wpisy first-input, jeśli strona została przeniesiona w tło przed pierwszym działaniem, ale te strony też należy ignorować podczas obliczania FID (działania są uwzględniane tylko wtedy, gdy strona była przez cały czas na pierwszym planie).
• Interfejs API nie raportuje first-input wpisów, gdy strona jest przywracana z pamięci podręcznej wstecz/dalej, ale FID należy mierzyć w tych przypadkach, ponieważ użytkownicy traktują je jako osobne wizyty na stronie.
• Interfejs API nie raportuje działań, które występują w elementach iframe, ale wskaźnik je uwzględnia, ponieważ są one częścią wrażeń użytkowników na stronie. Może to powodować różnice między CrUX a RUM. Aby prawidłowo mierzyć FID, należy je uwzględnić. Podramki mogą używać interfejsu API do raportowania swoich wpisów first-input do ramki nadrzędnej w celu agregacji.

Analizowanie i raportowanie danych FID

Ze względu na oczekiwaną różnicę w wartościach FID podczas raportowania danych FID należy uwzględniać rozkład wartości i skupiać się na wyższych percentylach.

Chociaż w przypadku wszystkich progów podstawowych wskaźników internetowych wybieramy 75 percentyl, w przypadku FID nadal zdecydowanie zalecamy uwzględnianie 95–99 percentyla, ponieważ odpowiadają one szczególnie złym pierwszym wrażeniom użytkowników na temat Twojej witryny. Pokaże Ci to obszary, które wymagają największych ulepszeń.

Dotyczy to również sytuacji, gdy dzielisz raporty na segmenty według kategorii lub typu urządzenia. Jeśli np. tworzysz osobne raporty na komputery i urządzenia mobilne, wartość FID, która najbardziej Cię interesuje na komputerach, powinna być 95–99 percentylem użytkowników komputerów, a wartość FID, która najbardziej Cię interesuje na urządzeniach mobilnych, powinna być 95–99 percentylem użytkowników urządzeń mobilnych.

Jak poprawić FID

Pełny przewodnik po optymalizacji FID zawiera informacje o technikach, które pozwolą Ci poprawić ten wskaźnik.

Historia zmian

Czasami w interfejsach API używanych do pomiaru danych lub w definicjach samych danych wykrywane są błędy. W rezultacie czasami trzeba wprowadzać zmiany, które mogą powodować poprawę lub pogorszenie wyników w raportach wewnętrznych i panelach.

Aby ułatwić Ci zarządzanie tymi zmianami, wszystkie zmiany w implementacji lub definicji tych danych będą widoczne w tej historii zmian.

Jeśli masz jakieś uwagi na temat tych danych, możesz je przesłać w grupie dyskusyjnej web-vitals-feedback.