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ś zostanie lojalnym użytkownikiem, czy przestanie. Powstaje pytanie, co robi dobre wrażenie i jak zmierzyć, jakie wrażenie robi na użytkownikach.
Pierwsze wrażenia w internecie mogą przybierać różne formy – mamy np. pierwsze wrażenia dotyczące wyglądu i wizualnej strony witryny, jak również pierwsze wrażenie jej szybkości i responsywności.
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). Jednak szybkość, z jaką witryna potrafi malować piksele do ekranu, to 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 zapewnić wygodę użytkowników, opóźnienie przy pierwszym działaniu powinno wynosić 100 milisekund lub mniej. 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 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 zdarzają się sytuacje odwrotne od sytuacji – wczytywaliśmy stronę internetową na telefonie i próbowaliśmy z niej korzystać, a gdy nic się nie stało, okazało się, że wszystko się denerwowało.
Ogólnie opóźnienie danych wejściowych (inaczej 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. Częstą przyczyną takiej sytuacji może być to, że przeglądarka jest zajęta analizowaniem i wykonywaniem dużego pliku JavaScript wczytanego przez aplikację. Podczas tego działania nie może uruchomić żadnych detektorów zdarzeń, ponieważ załadowany przez nią JavaScript może kazać mu wykonać coś 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.
Między pierwszym wyrenderowaniem treści (FCP) a czasem do pełnej interakcji (TTI) występują zazwyczaj duże opóźnienia przy pierwszym działaniu, ponieważ strona wyrenderowała część treści, ale nie jest ona jeszcze bardziej interaktywna. Aby to pokazać, dodaliśmy do osi czasu FCP i TTI:
Być może zauważyłeś, że między FCP i TTI jest sporo czasu (w tym 3 długie zadania) – jeśli użytkownik próbuje w tym czasie wejść w interakcję ze stroną (np. klikając link), występuje opóźnienie między otrzymaniem kliknięcia a możliwością udzielenia odpowiedzi w wątku głównym.
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 pojawiają się, gdy przeglądarka jest w trakcie uruchamiania zadania, więc musi poczekać na zakończenie zadania, zanim będzie mogła na nie odpowiedzieć. Czas oczekiwania to wartość FID dla 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 następnym bezczynnością wątku głównego. Oznacza to, że FID jest mierzony nawet wtedy, gdy nie został zarejestrowany detektor zdarzeń. Dzieje się tak, ponieważ wiele interakcji użytkowników nie wymaga detektora zdarzeń, ale wymaga, aby wątek główny był nieaktywny, aby mógł działać.
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 (
<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 wrażenie reagowania Twojej witryny przez użytkownika. Pierwsze wyświetlenia mają kluczowe znaczenie dla kształtowania ogólnego poziomu jakości i niezawodności witryny.
- Największe problemy z interaktywnością występują obecnie w internecie podczas wczytywania stron. Dlatego uważamy, że początkowo skupienie się na ulepszeniu pierwszej interakcji użytkownika w witrynie będzie miało największy wpływ na poprawę ogólnej interakcji z internetem.
- Zalecane rozwiązania problemów z dużymi opóźnieniami przy pierwszym wczytaniu strony (podział kodu, krótszy czas wczytywania JavaScriptu od razu itp.) mogą nie być tymi samymi rozwiązaniami, które pozwalają wyeliminować opóźnienia danych wejściowych po wczytaniu strony. Rozdzielając te dane, możemy dostarczać deweloperom stron internetowych bardziej szczegółowe wskazówki 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 koncentruje się tylko na zdarzeniach wejściowych pochodzących z dyskretnych działań, takich jak kliknięcia, dotknięcia czy 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ą korzystać z Twojej witryny za każdym razem, gdy ją odwiedzą. I nie wszystkie interakcje mają znaczenie w przypadku FID (jak wspomniano w poprzedniej sekcji). Oprócz tego niektóre pierwsze interakcje użytkowników występują w nieodpowiednich momentach (gdy wątek główny jest zajęty przez dłuższy czas), a u niektórych użytkowników pierwsze interakcje występują w dobrych momentach (gdy główny wątek jest całkowicie nieaktywny).
Oznacza to, że niektórzy użytkownicy nie będą mieli wartości FID, niektórzy z nich będą mieli niskie wartości FID, a inni prawdopodobnie będą mieli wysokie wartości.
Sposób śledzenia, raportowania i analizowania FID będzie pewnie nieco inny niż w przypadku innych rodzajów danych, do których być może przyzwyczaiłeś(-aś) się. Jak to zrobić, dowiesz się w następnej sekcji.
Dlaczego należy brać pod uwagę tylko opóźnienie danych wejściowych?
Jak wspomnieliśmy powyżej, FID mierzy tylko „opóźnienie” w przetwarzaniu zdarzeń. Nie mierzy całkowitego czasu przetwarzania zdarzeń ani czasu potrzebnego przeglądarce na aktualizację interfejsu po uruchomieniu modułów obsługi zdarzeń.
Choć ten czas jest ważny dla użytkownika i ma wpływ na wygodę użytkownika, nie jest uwzględniony w tych danych, ponieważ mogłoby to zachęcić deweloperów do dodania rozwiązań, które rzeczywiście pogorszą wrażenia użytkownika, np. mogą dodać logikę obsługi zdarzeń w asynchroniczne wywołanie zwrotne (za pomocą setTimeout()
lub requestAnimationFrame()
), aby oddzielić ją od zadania powiązanego ze zdarzeniem. W rezultacie nastąpi poprawa wyniku wskaźnika, ale wolniejsza odpowiedź z perspektywy użytkownika.
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 po danych niestandardowych.
Jak mierzyć wskaźnik FID
FID to dane, które można mierzyć tylko w terenie, ponieważ aby wejść w interakcję ze stroną przez faktycznego użytkownika, musi on wejść w interakcję ze stroną. Wartość FID możesz mierzyć za pomocą tych narzędzi.
Narzędzia terenowe
- Raport na temat użytkowania Chrome
- PageSpeed Insights
- Search Console (raport dotyczący podstawowych wskaźników internetowych)
web-vitals
Biblioteka JavaScript
Pomiar FID w JavaScript
Aby mierzyć FID w JavaScript, możesz użyć interfejsu API określania czasu trwania zdarzeń. Poniższy przykład pokazuje, jak utworzyć obiekt 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 określenie różnicy między znacznikami czasowymi startTime
i processingStart
. W większości przypadków będzie to wartość FID, jednak nie wszystkie wpisy first-input
nadają się 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 wpisy
first-input
w przypadku stron wczytywanych na karcie w tle, ale należy je zignorować przy obliczaniu FID. - API wysyła też wpisy
first-input
, jeśli strona była w tle przed wystąpieniem pierwszego wejścia, ale te strony powinny też zostać pominięte przy obliczaniu FID (wejścia są brane pod uwagę tylko wtedy, gdy strona była przez cały czas na pierwszym planie). - 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 raportuje danych wejściowych, które występują w elementach iframe, ale te dane widzą, ponieważ stanowią część interfejsu użytkownika strony. Może to wyróżniać się jako różnica między CrUX a RUM.
Aby prawidłowo mierzyć FID, należy je wziąć pod uwagę. Ramki podrzędne mogą używać interfejsu API do zgłaszania wpisów
first-input
do ramki nadrzędnej w celu agregacji.
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 zwrócić uwagę na rozkład wartości i skupić się na wyższych percentylu.
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.
Dzieje się tak nawet wtedy, gdy posegmentujesz raporty według kategorii lub typu urządzenia. Jeśli np. generujesz osobne raporty dla użytkowników komputerów i urządzeń mobilnych, wartość FID, na której najbardziej Ci zależy w przypadku komputerów, powinna mieścić się w przedziale 95–99 centyla użytkowników komputerów, a wartości FID, na których najbardziej zależy Ci na urządzeniach mobilnych, powinna mieścić się w przedziale 95–99 centyl użytkowników urządzeń mobilnych.
Jak poprawić 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. danych web-vitals.