Czym jest First Input Delay (FID)?

First Input Delay to pozycja o szczególnym znaczeniu w słowniku twórców stron, ponieważ pokazuje, jak szybko witryna odpowiada na pierwszą próbę interakcji użytkownika. Mierzy realne odczucie responsywności: czy kliknięcie w przycisk, naciśnięcie klawisza lub tapnięcie na ekranie uruchamia reakcję w ułamku sekundy, czy przeciwnie – zostaje wstrzymane, aż przeglądarka skończy wykonywać inne zadania. Prawidłowe zrozumienie tej metryki ułatwia podejmowanie trafnych decyzji projektowych i technicznych, a w efekcie obniża ryzyko porzucenia strony w pierwszych sekundach kontaktu.

Definicja i sens metryki

First Input Delay (w skrócie FID) to czas opóźnienia mierzony od momentu pierwszej interakcji użytkownika ze stroną do chwili, w której przeglądarka może zacząć obsługiwać to zdarzenie. Nie chodzi więc o ogólną szybkość ładowania, ale o pierwszą odpowiedź na konkretne działanie: kliknięcie, tapnięcie, naciśnięcie klawisza. FID rejestruje wyłącznie opóźnienie, zanim wątek przeglądarki rozpocznie wykonywanie kodu obsługującego dane zdarzenie. Nie obejmuje czasu samego wykonywania funkcji event handlera ani czasu renderowania kolejnej klatki obrazu. Dlatego precyzyjniej należy traktować go jako miarę gotowości interfejsu do reakcji, a nie pełny obraz kosztu interakcji.

Metryka jest częścią zestawu Core Web Vitals, które mają opisywać doświadczenie użytkownika w kategoriach wydajności i stabilności. Historycznie FID koncentrował się na wrażeniu pierwszego kontaktu z interfejsem – chwili, w której użytkownik po raz pierwszy sprawdza, czy strona jest “żywa”. Odpowiedź w ciągu ułamków sekundy buduje zaufanie, natomiast opóźnienie rzędu setek milisekund lub sekund daje odczucie zawieszania się aplikacji, nawet jeśli reszta witryny działa szybko.

Istotą FID jest zderzenie intencji człowieka z ograniczeniami technicznymi przeglądarki i kodu strony. Gdy w czasie pierwszej interakcji interaktywność jest blokowana przez wykonywanie ciężkich zadań, przeglądarka nie może natychmiast podjąć obsługi zdarzenia. Źródłem problemu bywa przeciążony kod, zbyt wiele skryptów ładowanych naraz, długa kompilacja i wykonywanie bundla, intensywne style i layouty, dekompresja obrazów, inicjalizacja bibliotek czy aktywność w tle, które kumulują się w krytycznym momencie. FID wyłapuje właśnie tę pierwszą szczelinę między oczekiwaniem a reakcją.

Klasyczne progi interpretacji FID były następujące: dobry wynik do 100 ms, wymagający poprawy między 100 a 300 ms, słaby powyżej 300 ms. Te wartości wiązały się z percepcją użytkownika: opóźnienia do około jednej dziesiątej sekundy często postrzegane są jako natychmiastowe, powyżej trzech dziesiątych sekundy użytkownik zaczyna zauważać zwłokę i może odczuwać irytację. Warto pamiętać, że mówimy o pomiarze w realnych warunkach korzystania – na różnych urządzeniach, w różnych sieciach i z różną liczbą uruchomionych rozszerzeń.

Najważniejsza konsekwencja definicji: FID nie jest mierzalny w laboratorium bez udziału człowieka. W praktyce narzędzia typu Lighthouse posługują się metryką zastępczą, aby uchwycić podobny wymiar wydajności. FID jest metryką “field-only”, co oznacza, że reprezentuje to, czego naprawdę doświadczają ludzie, a nie hipotetyczną sytuację w środowisku testowym.

Jak FID jest mierzony w praktyce

FID powstaje w momencie pierwszej realnej interakcji użytkownika po rozpoczęciu ładowania dokumentu. Zgodnie ze specyfikacją OAuth Web Vitals i implementacjami biblioteki web-vitals, uwzględniane są tzw. zdarzenia dyskretne: kliknięcia, naciśnięcia klawiszy i tapnięcia. Nie wlicza się gestów ciągłych, takich jak przewijanie czy pinch-zoom, gdyż mają osobne ścieżki przetwarzania i inny wpływ na odczuwaną responsywność.

Mechanizm wygląda następująco: użytkownik generuje zdarzenie (np. “click”), które trafia do kolejki zdarzeń w przeglądarce. Jeśli w momencie nadejścia zdarzenia wątek odpowiedzialny za jego obsługę jest zajęty, zdarzenie czeka. Po zwolnieniu zasobów przeglądarka przekazuje sterowanie do kodu obsługującego event, rejestrując długość czekania – to właśnie opóźnienie mierzone przez FID. Gdy wątek jest wolny, FID dla tej interakcji wynosi powiedzmy 10–20 ms, czyli mieści się w granicy nieodczuwalnej dla człowieka.

Ważne niuanse praktyczne:

• FID dotyczy pierwszego kwalifikującego się zdarzenia po nawigacji na stronę. Późniejsze interakcje nie wpływają na wynik tej metryki.
• Mierzona jest wyłącznie zwłoka “przed wejściem” do handlera; czas działania handlera i re-renderu nie jest doliczany. To rozróżnienie bywa źródłem nieporozumień.
• Jeśli użytkownik nie wykona żadnej interakcji, FID pozostaje nieokreślony dla danej sesji. To normalne i nie oznacza problemu.
• Wynik jest skorelowany z obciążeniem procesora i zasobów urządzenia. Na starszych telefonach opóźnienia rosną gwałtowniej niż na wydajnych laptopach.
• FID jest wartościowy jedynie w ujęciu populacyjnym. Pojedyncza sesja mówi niewiele; warto patrzeć na percentyle (np. 75. percentyl) w większej próbce użytkowników.

Gdzie zbierać dane? Dwa główne źródła to dane terenowe Google (Chrome UX Report) oraz własne RUM (Real User Monitoring). W RUM do rejestrowania użycia stosuje się bibliotekę web-vitals, która automatycznie obsługuje szczegóły pomiaru, agreguje wyniki i pozwala przesyłać je do narzędzia analitycznego. Daje to realny obraz działania witryny w zróżnicowanych warunkach i ułatwia wskazanie miejsc, które powodują największe opóźnienia.

W kontekście debugowania przydatna jest obserwacja “długich zadań” w przeglądarce: jeśli strona w momencie pierwszej interakcji wykonuje długi skrypt, opóźnienie przyjmie wartość zbliżoną do końcówki tego skryptu. Diagnostyka “long tasks” wraz z flame chartami w DevTools pokazuje, gdzie przepalane są milisekundy i co realnie trzyma wtyczkę akceleratora w pozycji “zajęty”.

FID a inne wskaźniki: TBT, TTI, INP

Aby poprawnie zinterpretować FID, warto zestawić go z innymi, pokrewnymi metrykami. Dają one szerszy obraz i wskazują kierunki optymalizacji.

Total Blocking Time (TBT) to metryka laboratoryjna, która sumuje czas, w którym wątek był zablokowany przez dłuższe zadania, licząc od momentu FCP do TTI. W praktyce TBT silnie koreluje z FID i stanowi jego proxy podczas analizy w narzędziach automatycznych. Gdy TBT jest wysoki, istnieje duże prawdopodobieństwo, że FID również będzie wysoki w terenie. TBT wskazuje na ogólne obciążenie, ale nie odzwierciedla konkretnego odczucia pierwszego kliknięcia.

Time to Interactive (TTI) to miara czasu potrzebnego, aby strona stała się w pełni interaktywna – by mogła niezawodnie reagować na wejścia użytkownika szybko i bez długich przerw. Jest przydatna, gdy chcemy wiedzieć, kiedy aplikacja przechodzi z fazy “ładowania” do fazy “działania”. Jednak TTI jest wrażliwa na szczegóły implementacji i bywa trudna w stabilnym wyznaczaniu. Podobnie jak TBT, TTI jest metryką laboratoryjną.

Najważniejsza zmiana ostatnich lat dotyczy wskaźnika INP (Interaction to Next Paint). Zastąpił on FID jako metrykę Core Web Vitals oceniającą responsywność w 2024 roku. INP mierzy nie tylko pierwszą interakcję, ale ogólną responsywność wielu interakcji w trakcie trwania sesji, a do tego uwzględnia nie tylko opóźnienie wejścia, ale także czas przetwarzania i renderowania do następnego odmalowania interfejsu. Dzięki temu lepiej reprezentuje wrażenia użytkownika, który korzysta z aplikacji dłużej niż kilka sekund i wykonuje więcej niż jedno kliknięcie.

W praktyce oznacza to, że FID pozostaje istotny historycznie i porównawczo (np. w analizie trendów), ale w nowych projektach nacisk należy kłaść na INP. Co jednak ważne, strategie obniżania FID – redukcja blokad w wątku, skracanie zadań, optymalizacja kodu – są w dużej mierze tożsame z tymi, które poprawiają wynik INP.

Narzędzia i źródła danych

Jest kilka dróg, by odczytywać i diagnozować FID oraz metryki korelate. W ekosystemie Google centralną rolę odgrywa PageSpeed Insights. To narzędzie zestawia dane laboratoryjne (Lighthouse) z danymi polowymi (Chrome UX Report). W przypadku FID odczyt pochodzi z CrUX, czyli zagregowanych danych z prawdziwych sesji użytkowników Chrome, jeśli tylko witryna ma wystarczający ruch, by raport mógł zostać zanonimizowany. PSI pokaże percentyle i klasyfikację jakościową, a także wskaże, czy problemy dotyczą głównie urządzeń mobilnych czy desktopów.

Lighthouse, uruchamiany lokalnie lub w CI, nie mierzy FID, ponieważ nie generuje realnych interakcji użytkownika. Posługuje się zamiast tego TBT, które pełni rolę wskaźnika zastępczego. W raportach znajdziesz konkretne zalecenia: zmniejsz rozmiar bundla, zastosuj code splitting, usuń nieużywany kod, wynieś ciężkie obliczenia do web workera. W wielu przypadkach zastosowanie tych rekomendacji obniża zarówno TBT, jak i FID.

Chrome UX Report (CrUX) udostępnia dane o doświadczeniu użytkowników na poziomie domeny i adresów URL. Wersje raportów dostępne są przez BigQuery, API i różne narzędzia społeczności. Warto łączyć te dane z własnym RUM, szczególnie gdy chcesz mierzyć specyficzne ścieżki użytkownika, różne warianty A/B lub gdy aplikacja ma złożone mechanizmy stanu i nawigacji klientowej.

Własny RUM to najpewniejszy sposób zrozumienia, skąd biorą się problemy. Biblioteka web-vitals umożliwia łatwe rejestrowanie FID i innych wskaźników wraz z kontekstem: rodzajem urządzenia, typem połączenia, wariantem renderowania. Możesz próbkując wysyłać dane do swojej analityki, a następnie budować dashboardy z percentylami i segmentacją. Jeżeli potrzebny jest głębszy wgląd, PerformanceObserver i Long Tasks API pomogą namierzyć dokładnie, które funkcje blokują wątek i jak długie są poszczególne odcinki wykonania.

Warto również korzystać z raportu Core Web Vitals w Search Console, który grupuje adresy na klastry podobnych problemów. Choć raport opiera się na danych polowych i bywa opóźniony względem aktualnego stanu wdrożenia, dobrze pokazuje trend: czy w populacji użytkowników rośnie udział doświadczeń dobrych, czy słabych.

Przyczyny słabego FID

Na wynik FID wpływają przede wszystkim blokady w wątku odpowiedzialnym za reakcję na zdarzenie. Najczęściej są to:

• Ciężkie operacje w JavaScript: parsing, kompilacja i wykonywanie dużych bundli na starcie, inicjalizacja frameworków, kosztowne obliczenia w kodzie użytkownika lub w bibliotekach.
• Wielkie, render-blokujące zasoby: duże pliki CSS dołączone w sekcji krytycznej, brak dzielenia stylów, niewydajne selektory i kaskady powodujące złożone przebudowy layoutu już podczas pierwszego wejścia.
• Trzecie strony: skrypty reklamowe, tagi analityczne, integracje social, chaty, menedżery tagów, które ładowane są wcześnie i uruchamiają dużo synchronicznego kodu.
• Niewydajna hydratacja SPA/SSR: duże drzewo komponentów, które musi zostać zhydratowane przed odpowiedzią na interakcje, a proces ten blokuje wątek i opóźnia obsługę pierwszego kliknięcia.
• Kaskadowe importy i brak code splittingu: wszystko ładuje się i uruchamia “na raz”, choć użytkownik potrzebuje w danej chwili tylko niewielkiego podzbioru funkcji.
• Przeciążenie pracy układu i stylów: wielokrotne wymuszanie synchronizacji layoutu, nieprzemyślane odczyty i zapisy do DOM w tej samej klatce, brak separacji kosztownych sekcji przez containment.
• Synchronizacja z siecią w krytycznym momencie: oczekiwanie na odpowiedzi API lub zasoby w sposób blokujący, zamiast odroczenia inicjalizacji do momentu bezczynności.
• Obciążenie urządzenia: wolne CPU, tryb oszczędzania energii, nagrzanie telefonu, współdzielenie zasobów z innymi aplikacjami – wszystko potęguje skutki nieoptymalnego kodu.

Warto rozumieć, że nawet drobne opóźnienia “sklejają się” w kumulatywne długie zadania. Gdy inicjalizacja wielu bibliotek następuje sekwencyjnie, a każda z nich wykonuje krótkie, ale synchroniczne kroki, w efekcie wątek pozostaje zajęty przez setki milisekund. Pierwszy klik – jeśli trafi w ten okres – dostanie wysoki FID. To dlatego optymalizacja musi celować zarówno w “grube” problemy (ogromne bundla), jak i w “drobniejsze” punkty tarcia (sekwencje małych zadań bez zwalniania sterowania).

Techniki optymalizacji FID

Strategia poprawy FID koncentruje się na uwolnieniu wątku w okolicy pierwszej interakcji i skróceniu zadań, które mogłyby ją zablokować. Poniżej zestaw praktycznych metod, które zwykle mają największy wpływ.

• Minimalizacja i dzielenie kodu: wprowadź code splitting oparty o routy i interakcje. Ładuj moduły “on demand”, zamiast dostarczać całą aplikację na starcie. Upewnij się, że narzędzie budujące stosuje tree-shaking i usuwa nieużywany kod.
• Odkładanie kosztów w czasie: oznacz skrypty jako defer/async, inicjalizuj ciężkie funkcje po pierwszym malowaniu i poza krytyczną ścieżką, korzystaj z requestIdleCallback i schedulerów, by porcjować pracę i oddawać sterowanie między zadaniami.
• Web Workery: przenieś CPU‑intensywne obliczenia poza główny wątek. Parsowanie, transformacje danych, serializacje – wszystko, co nie wymaga bezpośredniego dostępu do DOM, może trafić do workerów.
• Redukcja długich zadań: identyfikuj i rozbijaj Long Tasks (powyżej 50 ms) na mniejsze kawałki, dostosowując ich długość do budżetu jednej klatki (~16 ms dla 60 FPS).
• Optymalizacja hydratacji: rozważ częściową hydratację, architekturę wysp, SSR ze strumieniowaniem i priorytetyzacją istotnych interakcji. Niech elementy klikalne stają się operacyjne jak najwcześniej, nawet jeśli reszta UI “dogania” później.
• Krytyczne CSS: wydziel minimalny zestaw stylów konieczny do pierwszego renderu, resztę ładuj asynchronicznie. Zadbaj o containment i unikaj kaskad powodujących rozległe przebudowy.
• Weryfikacja zewnętrznych skryptów: oceń, które integracje są niezbędne. Wczytuj je później, używaj atrybutów async/defer, ogranicz liczebność tagów, konfiguruj tryb consent, by nie inicjalizować skryptów przed czasem.
• Priorytety i wskazówki ładowania: stosuj preload dla zasobów krytycznych, preconnect do domen trzecich, a tam gdzie to ma sens – wskazówki priorytetów. Zadbaj o serwerowe cachowanie, kompresję i HTTP/2/3.
• Eventy i słuchacze: używaj passive event listeners dla scroll/touch, deleguj eventy tam, gdzie to możliwe, i pilnuj, by w pierwszych handlerach nie było kosztownych operacji I/O lub złożonych re-renderów.
• Strona serwera: popraw TTFB i ogólne czasy odpowiedzi. Choć FID mierzy opóźnienie wejścia, wolny serwer często popycha programistów do kompensowania logiką po stronie klienta, powiększając bundla i obciążenie startowe.
• Obrazy i fonty: opóźniaj ładowanie obrazów poniżej “zgięcia”, stosuj formaty nowej generacji i odpowiednie wymiary. Dla fontów używaj display: swap lub fallbacków, by uniknąć blokady renderu.

Wdrożenia optymalizacyjne powinny być poparte pomiarem. Wyznacz bazowe percentyle FID oraz TBT, zaplanuj działania w małych krokach, po każdym wdrożeniu odczekaj na zapełnienie próbek polowych i porównaj wyniki. Tylko tak unikniesz regresji i upewnisz się, że realni użytkownicy odczuwają poprawę.

Najczęstsze pytania (FAQ)

• Co dokładnie mierzy FID?
  FID mierzy czas od pierwszej interakcji użytkownika (klik, tap, keydown) do momentu, gdy przeglądarka rozpoczyna wykonywanie handlera tego zdarzenia. Nie obejmuje czasu działania handlera ani renderowania po obsłudze.

• Czy FID jest nadal ważny, skoro pojawił się INP?
  Jest ważny historycznie i porównawczo, ale jako główny wskaźnik responsywności w Core Web Vitals został zastąpiony przez INP. W praktyce optymalizacje obniżające FID zwykle poprawiają także INP.

• Dlaczego Lighthouse nie pokazuje FID?
  Lighthouse to test laboratoryjny bez realnych interakcji użytkownika. Zamiast FID raportuje TBT, które koreluje z responsywnością i bywa używane jako proxy.

• Jakie wartości FID uznaje się za dobre?
  Klasyczne progi to: dobry wynik do 100 ms, wymagający poprawy 100–300 ms, słaby powyżej 300 ms. Należy interpretować je w kontekście 75. percentyla w populacji.

• Czy przewijanie wpływa na FID?
  Nie. FID dotyczy tylko dyskretnych interakcji (kliknięcia, naciśnięcia klawisza, tapnięcia). Gesty ciągłe mają inną charakterystykę i metryki.

• Czy FID mierzy się dla każdej interakcji?
  Nie. Rejestrowana jest tylko pierwsza kwalifikująca się interakcja po nawigacji na stronę.

• Jak mogę zmierzyć FID w mojej aplikacji?
  Skorzystaj z biblioteki web-vitals i własnej analityki RUM. Dodatkowo monitoruj dane z PageSpeed Insights / CrUX, jeśli twoja strona ma wystarczający ruch.

• Co najczęściej psuje FID?
  Długie, synchroniczne zadania w JS, ciężka hydratacja SPA, liczne skrypty zewnętrzne, rozbudowane CSS w krytycznej ścieżce renderowania i brak dzielenia kodu.

• Jakie szybkie działania mogą od razu pomóc?
  Dodaj defer/async do niekrytycznych skryptów, zastosuj code splitting, usuń nieużywany kod, przełóż ciężkie inicjalizacje na później, zweryfikuj i ogranicz skrypty trzecie.

• Czy SSR gwarantuje niski FID?
  Nie zawsze. SSR poprawia percepcję treści i może przyspieszyć pierwsze malowanie, ale jeśli hydratacja po stronie klienta jest kosztowna, FID wciąż może być wysoki.

• Czy FID zależy od szybkości serwera?
  Pośrednio. Choć FID mierzy opóźnienie reakcji po stronie klienta, wolne odpowiedzi i architektura wymuszająca ciężki JS na starcie mogą zwiększać blokady i opóźniać obsługę interakcji.

• Jak długo czekać na efekty po wdrożeniu optymalizacji?
  Zależnie od ruchu strony – zwykle kilka dni do kilku tygodni, aby zapełnić próbkę polową i zobaczyć stabilny wpływ zmian w raportach.