Wszyscy wiemy, jak ważne jest zrobienie dobrego pierwszego wrażenia. Poznawanie nowych ludzi jest ważne, a także pozwala tworzyć wrażenia użytkowników w internecie.
W internecie dobre pierwsze wrażenie może zadecydować o tym, czy użytkownik zostanie lojalnym użytkownikiem, czy opuści witrynę na jakiś czas później. Pytanie brzmi: co sprawia, że dobre wrażenie wywiera dobre wrażenie i jak można zmierzyć, jakiego rodzaju wyświetlenia wykonują użytkownicy.
W internecie pierwsze wrażenie może przyjmować bardzo różne formy: pierwsze wrażenie architektonicznej i wizualnej witryny, a także jej szybkość i responsywność.
Chociaż trudno jest ocenić, jak bardzo użytkownikom podoba się projekt witryny za pomocą internetowych interfejsów API, nie trzeba mierzyć szybkości i responsywności.
Szybkość ładowania witryny można zmierzyć za pomocą narzędzia Pierwsze wyrenderowanie treści (FCP). Jednak to, jak szybko witryna wyświetla piksele na ekranie, to tylko część historii. Równie ważne jest to, jak responsywność jest responsywna w przypadku interakcji użytkowników z pikselami.
Opóźnienie przy pierwszym działaniu (FID) pomaga mierzyć pierwsze wrażenia użytkownika związane z interaktywnością i responsywnością witryny.
Co to jest FID?
FID to czas od pierwszej interakcji użytkownika ze stroną (czyli od kliknięcia linku, kliknięcia przycisku lub użycia niestandardowego elementu sterującego JavaScript) do momentu, w którym przeglądarka jest w stanie rozpocząć przetwarzanie modułów 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 na maksymalnie 100 milisekund. Aby mieć pewność, że w przypadku większości użytkowników osiągasz ten cel, dobrym progiem jest 75 centyl wczytania stron w podziale na urządzenia mobilne i komputery.
Szczegółowy opis FID
Jako programiści, którzy piszą kod, który odpowiada na zdarzenia, często zakładamy, że zostanie on uruchomiony natychmiast, zaraz po wystąpieniu zdarzenia. Jednak jako użytkownicy często miewaliśmy do czynienia wręcz przeciwnie – załadowaliśmy stronę internetową na naszym telefonie, próbowaliśmy z niej skorzystać, a potem denerwowaliśmy się, gdy nic się nie wydarzyło.
Ogólnie opóźnienie wejściowe (opóźnienie wejścia) występuje, gdy główny wątek przeglądarki jest zajęty czymś innym, więc 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ę. Przy okazji nie może uruchamiać żadnych detektorów zdarzeń, ponieważ wczytywany JavaScript może nakazać mu wykonanie czegoś innego.
Oto przebieg standardowego wczytywania strony internetowej:
Powyższa wizualizacja pokazuje stronę, która wysyła kilka żądań sieciowych dotyczących zasobów (najprawdopodobniej do plików CSS i JS), a potem po ich pobraniu są one przetwarzane w wątku głównym.
Powoduje to okres, w którym wątek główny jest chwilowo zajęty, na co wskazują beżowe bloki zadania.
Długie opóźnienia przy pierwszym działaniu zwykle występują między First Contentful Paint (FCP) a czasem do pełnej interaktywności (TTI), ponieważ strona renderowała część treści, ale nie jest jeszcze bardziej interaktywna. Aby pokazać, jak to się dzieje, do osi czasu dodaliśmy FCP i TI:
Jak można zauważyć, między FCP i technologią TTI upływa 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ą blisko początku najdłuższego zadania:
Dane wejściowe mają miejsce, gdy przeglądarka jest w trakcie uruchamiania zadania, więc musi czekać na jego zakończenie, zanim będzie mogła odpowiedzieć 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 następnym bezczynnością wątku głównego. Oznacza to, że FID jest mierzone nawet w przypadku, gdy detektor zdarzeń nie został zarejestrowany. Dzieje się tak, ponieważ wiele interakcji użytkowników nie wymaga detektora zdarzeń, ale wymaga bezczynności wątku głównego.
Na przykład wszystkie te elementy HTML muszą czekać na zakończenie zadań w toku w wątku głównym, zanim będą odpowiadać na interakcje użytkownika:
- Pola tekstowe, pola wyboru i przyciski opcji (
<input>,<textarea>) - Wybierz menu (
<select>) - linki (
<a>)
Dlaczego warto brać pod uwagę tylko pierwsze dane wejściowe?
Chociaż opóźnienie danych wejściowych może źle wpływać na wrażenia użytkownika, zalecamy przede wszystkim pomiar opóźnienia przy pierwszym działaniu z kilku powodów:
- Pierwsze opóźnienie to pierwsze wrażenie użytkownika na temat responsywności witryny, a pierwsze wrażenia mają kluczowe znaczenie dla ogólnego wpływu na jakość i niezawodność witryny.
- Największe problemy z interakcją, które widzimy obecnie w sieci, występują podczas wczytywania stron. Dlatego sądzimy, że początkowo skupienie się na poprawie 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 wprowadzania danych przez witryny (podział kodu, mniej wczytywania JavaScriptu itp.) niekoniecznie są tymi samymi w przypadku rozwiązywania problemów z powolnymi opóźnieniami danych wejściowych po wczytaniu strony. Dzięki rozdzieleniu tych danych będziemy mogli udostępnić programistom stron internetowych bardziej szczegółowe wskazówki dotyczące wydajności.
Co zalicza się do pierwszych danych wejściowych?
FID to wartość, która mierzy responsywność strony podczas wczytywania. Skupia się więc tylko na zdarzeniach wejściowych pochodzących z określonych 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 i mają zupełnie inne ograniczenia wydajności (przeglądarki często potrafią ukryć czas oczekiwania, uruchamiając je w osobnym wątku).
Inaczej mówiąc, FID skupia się na R (reaktywacji) w modelu wydajności RAIL, podczas gdy przewijanie i powiększanie jest bardziej związane z animacją A, a ich skuteczność należy oceniać oddzielnie.
Co zrobić, jeśli użytkownik nigdy nie wchodzi w interakcję z witryną?
Nie wszyscy użytkownicy wchodzą w interakcję z Twoją witryną przy każdej wizycie. Nie wszystkie interakcje mają zastosowanie do FID (jak wspomniano w poprzedniej sekcji). Poza tym pierwsze interakcje niektórych użytkowników będą przeprowadzane 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ą się odbywać w dobrych momentach (gdy wątek główny jest całkowicie nieaktywny).
Oznacza to, że niektórzy użytkownicy nie będą mieć wartości FID, niektórzy z nich mają niskie wartości FID, a inni – wysokie.
Sposób, w jaki śledzisz, raportujesz i analizujesz FID, będzie się nieco różnić od innych danych, do których należysz. W następnej sekcji wyjaśniamy, jak to zrobić.
Dlaczego należy brać pod uwagę tylko opóźnienie danych wejściowych?
Jak już wspomnieliśmy, FID mierzy tylko „opóźnienie” w trakcie przetwarzania zdarzeń. Nie mierzy on czasu przetwarzania zdarzenia ani czasu potrzebnego na aktualizację interfejsu użytkownika po uruchomieniu modułów obsługi zdarzeń.
Ten czas jest ważny dla użytkownika i ma wpływ na wygodę użytkowników, ale nie jest on uwzględniany w tych danych, ponieważ może to zachęcić deweloperów do dodania rozwiązań, które rzeczywiście pogorszą wrażenia użytkownika. Oznacza to, że mogliby ująć logikę obsługi zdarzeń asynchronicznie (za pomocą setTimeout() lub requestAnimationFrame()), aby oddzielić ją od zadania powiązanego ze zdarzeniem. Efektem jest poprawa wyniku wskaźnika, ale wolniejsza odpowiedź postrzegana przez użytkownika.
Mimo że FID mierzy tylko „opóźnienie” czasu oczekiwania na zdarzenie, deweloperzy, którzy chcą śledzić dłuższy okres cyklu życia zdarzenia, mogą to zrobić za pomocą interfejsu Event Timing API. Więcej informacji znajdziesz w przewodniku po danych niestandardowych.
Jak mierzyć FID
FID to wartość, którą można zmierzyć tylko w tym polu, ponieważ do interakcji ze stroną niezbędny jest rzeczywisty użytkownik. Wskaźnik 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)
- Biblioteka JavaScript
web-vitals
Mierz FID w JavaScript
Do pomiaru FID w kodzie JavaScript możesz używać 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 tym przykładzie wartość opóźnienia wpisu first-input jest mierzona przez wybranie różnicy między sygnaturami czasowymi wpisu 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 tej sekcji opisujemy różnice między danymi w raportach interfejsu API a sposobem obliczania tych danych.
Różnice między danymi a interfejsem API
- W przypadku stron wczytywanych w tle interfejs API wysyła wpisy
first-input, ale należy je zignorować podczas obliczania FID. - Interfejs API wysyła też wpisy
first-input, jeśli przed wprowadzeniem pierwszych danych wejściowych strona działała w tle, ale te strony powinny być też ignorowane przy obliczaniu FID (dane wejściowe są uwzględniane tylko wtedy, gdy strona przez cały czas znajdowała się na pierwszym planie). - Interfejs API nie zgłasza 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ą je jako osobne wizyty na stronie. - Interfejs API nie raportuje danych wejściowych, które występują w elementach iframe, ale są one uwzględniane, ponieważ są częścią wrażeń użytkownika na stronie. Może to różnić się między wartościami CrUX i RUM.
Aby prawidłowo mierzyć FID, warto je wziąć pod uwagę. Ramki podrzędne mogą używać interfejsu API do raportowania swoich wpisów
first-inputw ramce nadrzędnej na potrzeby agregacji.
Zamiast zapamiętywać wszystkie te subtelne różnice, deweloperzy mogą użyć biblioteki JavaScript web-vitals do pomiaru FID, która obsługuje te różnice (tam, gdzie to możliwe, problem z elementami iframe nie jest omówiony):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
Pełny przykład pomiaru FID w JavaScript znajdziesz w kodzie źródłowym onFID().
Analizowanie danych FID i tworzenie raportów na ich temat
Ze względu na spodziewaną wariancję wartości FID ważne jest, aby przy raportowaniu danych dotyczących FID zwracać uwagę na rozkład wartości i koncentrować się na wyższych centylach.
Chociaż wybór percentyla dla wszystkich progów podstawowych wskaźników internetowych to 75., w przypadku FID nadal zdecydowanie zalecamy sprawdzanie 95–99 centyla, ponieważ będzie to odpowiadać wyjątkowo złym ustawieniom witryny. Dzięki temu dowiesz się, które obszary musisz poprawić.
Dzieje się tak nawet wtedy, gdy posegmentujesz raporty według kategorii lub typu urządzenia. Jeśli np. generujesz osobne raporty dla komputerów i urządzeń mobilnych, wartością FID, na której najbardziej Ci zależy, w przypadku komputerów powinna być wartość z przedziału 95–99 centyla użytkowników komputerów, a wartości FID, na których najbardziej Ci zależy w przypadku użytkowników urządzeń mobilnych – dla 95–99 percentyla użytkowników urządzeń mobilnych.
Jak poprawić FID
Dostępny jest pełny przewodnik po optymalizacji FID, z którego dowiesz się, jak poprawić ten wskaźnik.
Historia zmian
Czasami błędy wykrywane są w interfejsach API używanych do pomiaru danych, a czasem w definicjach samych danych. Dlatego czasem trzeba wprowadzać określone zmiany, które mogą być widoczne w wewnętrznych raportach i panelach jako ulepszenia lub regresje.
Aby Ci w tym pomóc, wszystkie zmiany w implementacji lub definicji tych danych będą pojawiać się w tej historii zmian.
Jeśli chcesz podzielić się swoją opinią na temat tych danych, możesz ją przekazać w grupie dyskusyjnej Google web-vitals-feedback.