First Input Delay (FID)

Obsługa przeglądarek

  • 76
  • 79
  • 89
  • x

Źródło

Wszyscy wiemy, jak ważne jest zrobienie dobrego pierwszego wrażenia. To ważne poznawanie nowych osób. Ważne jest też, by dzielić się doświadczeniami w sieci.

W internecie dobre pierwsze wrażenie może zadecydować o tym, czy ktoś inny w stają się lojalnymi użytkownikami lub gdy opuszczają witrynę i nigdy nie wracają. Pytanie brzmi: co sprawia, że wyświetlenie jest dobre, i jak można je zmierzyć, które prawdopodobnie zarabiasz na użytkownikach?

Pierwsze wyświetlenia mogą przybierać różne formy. pierwsze wrażenia związane z projektem i atrakcją wizualną witryny, ale nie spowalniają jej działania.

Chociaż trudno jest zmierzyć, jak bardzo użytkownikom podoba się projekt witryny za pomocą interfejsów API, mierzenie jego szybkości i reagowania nie jest.

Jak szybko można zmierzyć szybkość wczytywania strony, gdy użytkownik zobaczy pierwsze wrażenie Pierwsze wyrenderowanie treści (FCP). Ale jak szybko Twoja witryna może malować piksele To tylko część historii. Równie ważna jest responsywność, w Twojej witrynie, gdy użytkownicy próbują wchodzić w interakcje z tymi pikselami.

Dane Opóźnienie przy pierwszym działaniu (FID) pomagają zmierzyć pierwsze wyświetlenie reklamy interaktywność i responsywność Twojej witryny.

Co to jest FID?

FID to czas od pierwszej interakcji użytkownika ze stroną (tzn. klikają link, dotykają przycisku lub korzystają z niestandardowych elementów sterujących opartych na języku JavaScript). do momentu, gdy przeglądarka jest w stanie rozpocząć przetwarzanie modułów obsługi zdarzeń w odpowiedzi na tę interakcję.

Jaki jest dobry wynik FID?

Aby zapewnić wygodę użytkownikom, witryny powinny mieć w pierwszej kolejności Opóźnienie maksymalnie 100 milisekund. Aby mieć pewność, że osiągniesz ten cel: większości użytkowników, dobrym prógem do pomiaru jest 75. percentyl wczytywania stron z podziałem na urządzenia mobilne i komputery.

Dobre wartości FID to maksymalnie 2,5 sekundy, niskie wartości powyżej 4,0 sekund, a wszystkie inne elementy wymagają poprawy

Szczegóły FID

Programiści, którzy piszą kod odpowiadający na zdarzenia, często zakładamy, zostanie uruchomiony natychmiast – gdy tylko wystąpi zdarzenie. Jednak jako użytkownicy Często zdarza się, że wczytaliśmy stronę internetową nasz telefon, próbował korzystać z niego, ale byłem sfrustrowany, gdy nic miało miejsce.

Ogólnie opóźnienie danych wejściowych (inaczej opóźnienie sygnału wejściowego) zachodzi dlatego, że wątek główny jest zajęty czymś innym, więc nie może (jeszcze) odpowiedzieć użytkownikowi. Jedną z częstych przyczyn takiej sytuacji jest to, że przeglądarka jest zajęta analizowaniem i wykonywaniem działań duży plik JavaScript wczytany przez aplikację. Podczas tego działania nie może działać wszystkich detektorów zdarzeń, ponieważ wczytywany przez niego JavaScript może kazać mu to coś innego.

Przyjrzyjmy się takiemu osią czasu typowego wczytywania strony internetowej:

Przykładowy log czasu wczytywania strony

Na powyższej wizualizacji widać stronę, która wysyła kilka żądań sieciowych zasobów (prawdopodobnie plików CSS i JS), a po tych zasobach po zakończeniu pobierania – zostaną przetworzone w wątku głównym.

Powoduje to momenty, w których wątek główny jest chwilowo zajęty, czyli oznaczone kolorem beżowym, zadanie bloki.

Między pierwszym wyrenderowaniem treści występują zazwyczaj długie opóźnienia przy pierwszym działaniu (FCP) i Time to Interactive (TTI), ponieważ na stronie wyrenderowała część jego treści, ale nie jest jeszcze wystarczająco interaktywna. Do zilustrowania Do osi czasu dodaliśmy opcje FCP i TTI.

Przykładowy log czasu wczytywania strony z FCP i TTI

Jak już pewnie zauważyliście, zajmuje dużo czasu (w tym trzy długie ) między FCP a TTI, jeśli użytkownik użytkownicy będą mogli wejść w interakcję z Twoją stroną (np. klikając link), między otrzymaniem kliknięcia a momentem, w którym wątek główny odpowiedzieć.

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

Przykładowy zrzut wczytywania strony z FCP, TTI i FID

Dane wejściowe mają miejsce, gdy przeglądarka jest w trakcie uruchamiania zadania, musi zaczekać na zakończenie zadania, zanim będzie mógł zareagować na dane wejściowe. czas oczekiwania, to wartość FID tego użytkownika na tej stronie.

Co zrobić, jeśli interakcja nie ma detektora zdarzeń?

FID mierzy różnicę między otrzymaniem zdarzenia wejściowego a odebraniem zdarzenia głównego wątek jest następny bezczynny. Oznacza to, że FID jest mierzone nawet w przypadkach, gdy zdarzenie nie zarejestrowano detektora. Dzieje się tak, ponieważ wiele interakcji użytkowników nie wymagają detektora zdarzeń, ale wymagają, aby wątek główny był bezczynny przed uruchomieniem.

Na przykład wszystkie poniższe elementy HTML muszą czekać na trwające zadania w wątku głównym do wykonania, zanim odpowiesz użytkownikowi; interakcje:

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

Dlaczego należy brać pod uwagę tylko pierwszą odpowiedź?

Chociaż opóźnienia w dostarczaniu jakichkolwiek danych mogą negatywnie wpływać na wygodę użytkowników, zalecamy pomiar opóźnienia przy pierwszym działaniu z kilku powodów:

  • Opóźnienie przy pierwszym działaniu oznacza pierwsze wyświetlenie reklamy czas reakcji, pierwsze wrażenie ma kluczowe znaczenie dla jakość i wiarygodność witryny.
  • Największe problemy z interaktywnością, jakie obecnie obserwujemy w internecie, występują podczas strony. Dlatego uważamy, że początkowo skoncentrujemy się na poprawie pierwszego użytkownika witryny, mają największy wpływ na poprawę i interaktywność w internecie.
  • Zalecane rozwiązania problemów z dużymi opóźnieniami przy pierwszym działaniu w witrynach (podział kodu, ładowanie mniej JavaScriptu od razu itp.) nie muszą być te same rozwiązania w przypadku korygowania opóźnień w danych wejściowych po wczytaniu strony. Rozdzielając Dzięki tym danym będziemy mogli wytycznymi dla programistów stron internetowych.

Co zalicza się do pierwszych danych wejściowych?

FID to wskaźnik mierzący responsywność strony podczas jej wczytywania. W związku z tym skupia się tylko na zdarzeniach związanych z wejściem od dyskretnych działań, takich jak kliknięcia, dotknięcia czy naciśnięcie klawisza naciśnięć.

Inne interakcje, takie jak przewijanie i powiększanie, mają charakter ciągły i mają zupełnie inne ograniczenia wydajności (przeglądarki często mają możliwość ukrywają opóźnienia, uruchamiając je w osobnym wątku).

Inaczej mówiąc, FID skupia się na R (responsywności) w RAIL występ , a w przypadku przewijanie i powiększanie jest bardziej powiązane z A (animacją). jakości trzeba ocenić oddzielnie.

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

Nie wszyscy użytkownicy będą korzystać z Twojej witryny za każdym razem, gdy ją odwiedzą. Nie wszystkie interakcje mają znaczenie w przypadku FID (jak wspomniano w poprzedniej sekcji). W niektóre pierwsze interakcje mogą też wystąpić w złych momentach (gdy główny jest zajęty przez dłuższy czas), a niektórzy użytkownicy interakcje będą odbywały się w odpowiednich momentach (gdy wątek główny jest całkowicie nieaktywny).

Oznacza to, że niektórzy użytkownicy nie mają wartości FID, a inni – niskie FID i niektórzy użytkownicy będą prawdopodobnie mieć wysokie wartości FID.

Sposób śledzenia, raportowania i analizowania FID będzie pewnie nieco inny. od innych wskaźników, do których możesz się przyzwyczaić. W następnej sekcji dowiesz się, co zrobić, to osiągnąć.

Dlaczego należy uwzględniać tylko opóźnienie sygnału wejściowego?

Jak wspomnieliśmy powyżej, FID mierzy tylko „opóźnienie”. do przetwarzania zdarzeń. Tak nie mierzyć całkowitego czasu przetwarzania zdarzeń ani czasu potrzebnego przeglądarka zaktualizuje interfejs po uruchomieniu modułów obsługi zdarzeń.

Choć ten czas jest ważny dla użytkownika i ma wpływ na wrażenia użytkownika, nie jest ujęte w tym wskaźniku, ponieważ mogłoby to zachęcić deweloperów do zaangażowania się. dodawania rozwiązań, które rzeczywiście pogarszają działanie aplikacji, może dodać logikę obsługi zdarzeń w asynchroniczne wywołanie zwrotne (za pomocą setTimeout() lub requestAnimationFrame()), aby oddzielić go od parametru powiązane ze zdarzeniem. Pozwoli to poprawić wskaźnik wynik, ale wolniejsza odpowiedź z perspektywy użytkownika.

FID mierzy tylko „opóźnienie” dla części czasu oczekiwania na zdarzenia, którzy chcą śledzić większą część cyklu życia zdarzeń, mogą to zrobić za pomocą kolumny Czas zdarzenia API. Zapoznaj się z przewodnikiem po standardzie niestandardowym , aby dowiedzieć się więcej.

Jak mierzyć FID

FID to dane, które można mierzyć tylko , ponieważ wymaga ono prawdziwego interakcji ze stroną. FID możesz mierzyć za pomocą poniższych narzędzi.

Narzędzia terenowe

Pomiar FID w JavaScript

Do pomiaru FID w JavaScripcie możesz użyć parametru Czas zdarzenia API. Ten przykład pokazuje, jak Utwórz PerformanceObserver który słucha 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 obliczając różnicę między wartościami startTime i processingStart wpisu sygnatury czasowe. W większości przypadków będzie to wartość FID, jednak nie wszystkie Pozycje first-input są prawidłowe do pomiaru FID.

W poniższej sekcji wymieniono różnice między danymi w raportach interfejsu API i sposobem ich przesyłania dane są obliczane.

Różnice między danymi a interfejsem API

  • Interfejs API będzie wysyłać wpisy first-input w przypadku załadowanych stron na karcie w tle, ale należy je zignorować przy obliczaniu FID.
  • Interfejs API wyśle też wpisy first-input, jeśli strona działała w tle. przed pierwszym działaniem wejściowym, ale należy je również zignorować. przy obliczaniu FID (dane wejściowe są brane pod uwagę tylko wtedy, gdy strona była cały czas na pierwszym planie).
  • Interfejs API nie zgłasza wpisów first-input po przywróceniu strony z z pamięci podręcznej stanu strony internetowej, ale FID powinna być mierzone w takich przypadkach, ponieważ użytkownicy postrzegają je jako odrębną stronę. wizyty.
  • Interfejs API nie raportuje danych wejściowych występujących w elementach iframe, ale dane już ponieważ wchodzą w skład strony. Może to spowodować wskazywać różnicę między CrUX a RUM. Aby prawidłowo mierzyć FID, należy je wziąć pod uwagę. Ramki podrzędne mogą używać interfejsu API raportują wpisy first-input w ramce nadrzędnej w celu agregacji.

Zamiast zapamiętywać wszystkie te subtelne różnice, programiści mogą korzystać z web-vitals biblioteki JavaScript do Pomiar FID, który uwzględnia te różnice (tam, gdzie to możliwe – problem z elementem iframe nie został omówiony):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Możesz skorzystać z kodu źródłowego witryny, onFID() , aby zobaczyć pełny przykład pomiaru FID w języku JavaScript.

Analizowanie danych FID i generowanie raportów na ich temat

Ze względu na spodziewaną wariancję wartości FID ważne jest, aby przy raportowaniu FID przyjrzysz się rozkładowi wartości i skoncentrujesz się na wyższych percentylu.

Mimo że wybór percentylu dla wszystkich Progi Podstawowych wskaźników internetowych to 75. W przypadku FID nadal duże znaczenie zalecamy brać pod uwagę przedział 95-99 centyli, ponieważ będą one odpowiadać szczególnie złe doświadczenia użytkowników witryny. Będzie te obszary, które wymagają poprawy.

Dzieje się tak nawet wtedy, gdy posegmentujesz raporty według kategorii lub typu urządzenia. Dla: Jeśli np. generujesz osobne raporty dla komputerów i urządzeń mobilnych, wartość FID użytkowników komputerów powinno stanowić 95–99 centyl użytkowników komputerów, a wartość FID, na której najbardziej Ci zależy na urządzeniach mobilnych, powinna wynosić od 95 do 99 percentyl użytkowników mobilnych.

Jak poprawić FID

Dostępny jest pełny przewodnik na temat optymalizacji FID, w którym znajdziesz techniki pozwalające poprawić te dane.

Historia zmian

Czasami błędy wykrywane są w interfejsach API używanych do pomiaru danych, a czasem w definicjach samych wskaźników. Dlatego czasami konieczne jest wprowadzenie zmian, które mogą być widoczne jako ulepszenia lub regresje w wewnętrznych raportach i panelach.

Aby ułatwić Ci to zadanie, wszystkie zmiany w implementacji lub definicji tych danych będą widoczne w tym dzienniku zmian.

Jeśli chcesz podzielić się opinią na temat tych danych, możesz przesłać ją w grupie dyskusyjnej Google z informacjami o web-vitals-feedback.