First Input Delay (FID)

Philip Walton

Wszyscy wiemy, jak ważne jest sprawienie dobrego pierwszego wrażenia. Jest to ważne podczas poznawania nowych osób, a także podczas tworzenia doświadczeń w internecie.

W internecie dobre pierwsze wrażenie może zdecydować o tym, czy ktoś stanie się lojalnym użytkownikiem, czy też odejdzie i nigdy nie wróci. Pytanie brzmi: co sprawia, że reklama robi dobre wrażenie? Jak możesz zmierzyć, jakie wrażenie wywierasz na użytkownikach?

W internecie pierwsze wrażenie może być bardzo różne. Może to być pierwsze wrażenie związane z projektem i atrakcyjnością wizualną witryny, a także pierwsze wrażenie związane z szybkością i odpowiadaniem na działania.

Chociaż trudno jest zmierzyć, na ile użytkownicy lubią wygląd witryny za pomocą interfejsów API, to szybkość i odporność na błędy można zmierzyć bez problemu.

Pierwsze wrażenie użytkowników dotyczące szybkości wczytywania witryny można zmierzyć za pomocą pierwszego wyrenderowania treści (FCP). Szybkość wyświetlania pikseli na ekranie to jednak tylko część historii. Równie ważne jest to, jak szybko Twoja witryna reaguje, gdy użytkownicy próbują wchodzić w interakcje z tymi pikselami.

Dane o opóźnieniu przy pierwszym działaniu (FID) pomagają mierzyć pierwsze wrażenia użytkownika dotyczące interakcji i responsywności witryny.

Co to jest FID?

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

Jaki jest dobry wynik FID?

Aby wygodnie korzystać z witryny, użytkownicy powinni mieć opóźnienie pierwszego wejścia poniżej 100 milisekund. Aby mieć pewność, że osiągasz ten cel w przypadku większości użytkowników, dobrym progiem do pomiaru jest 75. percentyl wczytywania stron podzielony na urządzenia mobilne i komputery.

Szczegóły dotyczące FID

Jako programiści, którzy piszą kod reagujący na zdarzenia, często zakładamy, że nasz kod będzie uruchamiany natychmiast, gdy tylko zdarzenie się pojawi. Jednak jako użytkownicy często doświadczamy sytuacji odwrotnej: wczytujemy stronę na telefonie, próbujemy z nią wejść w interakcję, a potem zniechęcamy się, gdy nic się nie dzieje.

Ogólnie opóźnienie danych wejściowych (czyli opóźnienie danych wejściowych) występuje, gdy główny wątek przeglądarki jest zajęty wykonywaniem innej czynności, przez co nie może (jeszcze) odpowiedzieć użytkownikowi. Jedną z częstych przyczyn może być to, że przeglądarka jest zajęta analizowaniem i wykonywaniem dużego pliku JavaScript wczytanego przez aplikację. Podczas tej czynności nie może ona wykonywać żadnych odbiorników zdarzeń, ponieważ wczytywany przez nią kod JavaScript może wymagać od niej wykonania czegoś innego.

Rozważ następujący harmonogram typowego wczytywania strony:

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

Powoduje to okresy, w których wątek główny jest chwilowo zajęty, co jest sygnalizowane beżowymi blokami zadania.

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:

Zauważysz pewnie, że między FCP a TTI występuje dość długi czas (w tym 3 długie zadania). Jeśli użytkownik spróbuje w tym czasie wchodzić w interakcję ze stroną (np. kliknąć link), nastąpi opóźnienie między momentem otrzymania kliknięcia a możliwością reakcji wątku głównego.

Zastanów się, co się stanie, jeśli użytkownik spróbuje wejść w interakcję ze stroną w pobliżu początku najdłuższego zadania:

Dane wejściowe są przekazywane, gdy przeglądarka wykonuje jakieś zadanie, dlatego musi poczekać na jego zakończenie, zanim będzie mogła na nie zareagować. Czas oczekiwania to wartość FID dla tego użytkownika na tej stronie.

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

FID mierzy różnicę między momentem otrzymania zdarzenia wejściowego a momentem, gdy główny wątek jest ponownie nieczynny. Oznacza to, że FID jest mierzony nawet wtedy, gdy nie został zarejestrowany detektor zdarzeń. Dzieje się tak, ponieważ wiele interakcji użytkownika nie wymaga interfejsu zdarzeń, ale wymaga, aby wątek główny był nieaktywny.

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 reagować na interakcje użytkownika:

• pola tekstowe, pola wyboru i przyciski opcji (<input>, <textarea>);
• Wybierz menu (<select>)
• linki (<a>),

Dlaczego bierzemy pod uwagę tylko pierwszy element wejściowy?

Opóźnienie w reakcji na dowolne dane wejściowe może pogorszyć wrażenia użytkownika, ale przede wszystkim zalecamy pomiar opóźnienia pierwszego wejścia z kilku powodów:

• Pierwsze opóźnienie wprowadzania danych to pierwsze wrażenie użytkownika dotyczące szybkości reakcji witryny, a pierwsze wrażenia mają kluczowe znaczenie dla ogólnego wrażenia dotyczącego jakości i rzetelności witryny.
• Największe problemy z interaktywnością występują obecnie w internecie podczas wczytywania stron. Dlatego uważamy, że początkowe skupienie się na ulepszeniu interakcji z użytkownikiem w witrynie będzie miało największy wpływ na ogólną interaktywność witryny.
• Zalecane rozwiązania dotyczące tego, jak witryny powinny eliminować długie opóźnienia w przypadku pierwszego wprowadzania danych (np. podział kodu, wczytywanie mniejszej ilości kodu JavaScript na początku itp.), nie muszą być tymi samymi rozwiązaniami, które eliminują opóźnienia w przypadku wprowadzania danych po załadowaniu strony. Dzięki temu będziemy mogli udostępniać deweloperom stron internetowych bardziej szczegółowe wytyczne dotyczące skuteczności.

Co zaliczamy do pierwszego wejścia?

FID to dane służące do pomiaru responsywności strony podczas wczytywania. W związku z tym skupia się tylko na zdarzeniach związanych z wprowadzaniem danych, które pochodzą z pojedynczych działań, takich jak kliknięcia, stuknięcia i naciśnięcia klawiszy.

Inne interakcje, takie jak przewijanie i powiększanie, to ciągłe działania, które mają zupełnie inne ograniczenia dotyczące wydajności (poza tym przeglądarki często mogą ukryć opóźnienia, wykonując je w ramach osobnego wątku).

Inaczej mówiąc, FID koncentruje się na R (odporności na zakłócenia) w modelu wydajności RAIL, podczas gdy przewijanie i powiększanie są bardziej związane z A (animacja), a ich wydajność powinna być oceniana 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ą przy każdej wizycie. Nie wszystkie interakcje są istotne dla FID (jak wspomniano w poprzedniej sekcji). Ponadto niektóre pierwsze interakcje użytkownika będą miały miejsce w nieodpowiednim momencie (gdy główny wątek jest zajęty przez dłuższy czas), a inne w odpowiednim momencie (gdy główny wątek jest całkowicie nieaktywny).

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

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

Dlaczego uwzględnić tylko opóźnienie danych wejściowych?

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

Mimo że ten czas jest ważny dla użytkownika i ma wpływ na wrażenia, nie jest uwzględniany w tych danych, ponieważ mogłoby to zachęcić deweloperów do dodania obejść, które w efekcie pogorszyłyby wrażenia. Mogliby oni otoczyć logikę obsługi zdarzeń w niesynchronizowanym wywoływaniu zwrotnym (za pomocą setTimeout() lub requestAnimationFrame()), aby oddzielić ją od zadania powiązanego ze zdarzeniem. W efekcie poprawi się wynik wskaźnika, ale użytkownik będzie odczuwał dłuższy czas oczekiwania na odpowiedź.

Jednak pomiar FID obejmuje tylko część opóźnienia, jaką jest czas oczekiwania na odpowiedź. 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 na temat danych niestandardowych.

Jak mierzyć wskaźnik FID

FID to dane, które można mierzyć tylko w polu, ponieważ wymagają interakcji z użytkownikiem. Wartość FID możesz mierzyć za pomocą tych narzędzi.

Narzędzia w polu

• 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 API określania czasu trwania zdarzeń. Ten przykład pokazuje, jak utworzyć skrypt PerformanceObserver, który nasłuchuje wpisów w first-inputi zapisuje 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 określenie różnicy między znacznikami czasowymi startTime i processingStart. W większości przypadków będzie to wartość FID, ale nie wszystkie wpisy first-input są odpowiednie do pomiaru FID.

W następującej sekcji znajdziesz różnice między tym, co raportuje interfejs API, a sposobem obliczania danych.

Różnice między danymi a interfejsem API

• Interfejs API wysyła rekordy first-input dotyczące stron wczytywanych w karcie w tle, ale te strony powinny być ignorowane podczas obliczania FID.
• Interfejs API wysyła też wpisy first-input, jeśli strona była w tle przed wystąpieniem pierwszego wejścia, ale te strony też powinny być ignorowane podczas obliczania FID (wejścia są brane pod uwagę tylko wtedy, gdy strona była na pierwszym planie przez cały czas).
• Interfejs API nie raportuje wpisów first-input, gdy strona jest przywracana z pamięci podręcznej stanu strony internetowej, ale w takich przypadkach należy mierzyć FID, ponieważ użytkownicy postrzegają te wizyty jako odrębne wizyty na stronie.
• Interfejs API nie rejestruje danych wejściowych w ramkach iframe, ale dane rejestrują te dane, ponieważ są one częścią wrażeń użytkownika związanych ze stroną. Może to wynikać z różnic między CrUX a RUM. Aby prawidłowo mierzyć FID, należy wziąć je pod uwagę. Ramki podrzędne mogą używać interfejsu API do przekazywania swoich wpisów first-input do ramki nadrzędnej w celu ich agregacji.

Analizowanie i raportowanie danych FID

Ze względu na oczekiwaną zmienność wartości FID bardzo ważne jest, aby w raportach dotyczących FID analizować rozkład wartości i skupić się na wyższych wartościach percentylowych.

Wybór percentyla dla wszystkich wartości progowych podstawowych wskaźników internetowych to 75, ale w przypadku FID zdecydowanie zalecamy sprawdzanie 95. i 99. percentyla, ponieważ odpowiadają one szczególnie złym pierwszym wrażeniom użytkowników z Twojej witryny. Pokaże Ci też obszary, które wymagają największej poprawy.

Dotyczy to nawet wtedy, gdy dzielisz raporty na segmenty według kategorii lub typu urządzenia. Jeśli na przykład uruchamiasz osobne raporty dotyczące komputerów i urządzeń mobilnych, wartość FID, która Cię najbardziej interesuje na komputerach, powinna odpowiadać 95.–99. percentylowi użytkowników komputerów, a wartość FID, która Cię najbardziej interesuje na urządzeniach mobilnych, powinna odpowiadać 95.–99. percentylowi użytkowników urządzeń mobilnych.

Jak poprawić wskaźnik FID

Pełny przewodnik dotyczący optymalizacji FID zawiera wskazówki dotyczące technik, które pomogą Ci poprawić ten wskaźnik.

Historia zmian

Czasami w interfejsach API służących do pomiaru danych i czasami w definicjach samych danych występują błędy. W związku z tym czasami trzeba wprowadzić zmiany, które mogą się pojawiać w raportach i panelach wewnętrznych jako ulepszenia lub regresje.

Aby ułatwić Ci zarządzanie tymi danymi, wszystkie zmiany w ich implementacji lub definicji będą widoczne w Historii zmian.

Jeśli masz opinię na temat tych danych, możesz ją przekazać w grupie Google nt. opinii na temat funkcji web-vitals.