Opóźnienie pierwszego wejścia (FID)

TL;DR — First Input Delay (FID) to stara metryka. Mierzyła, jak długo strona kazała użytkownikowi czekać, zanim mogła w ogóle zacząć reagować na jego pierwsze kliknięcie lub stuknięcie. Google wycofało ją w marcu 2024 r. i zastąpiło INP, a następnie całkowicie usunęło ją ze swoich narzędzi we wrześniu 2024 r. Nie ma więc już czego tu naprawiać — warto jednak wiedzieć, czym była, gdy trafisz na „FID” w starych raportach.

Czym było First Input Delay

Gdy stukasz przycisk i przez chwilę nic się nie dzieje, strona sprawia wrażenie zepsutej — nawet jeśli wygląda na załadowaną. First Input Delay (FID) było sposobem Google na przypisanie liczby do tego konkretnego problemu.

FID mierzyło jedną wąską rzecz: odstęp między pierwszą interakcją ze stroną (kliknięciem, stuknięciem albo naciśnięciem klawisza) a momentem, w którym przeglądarka była faktycznie wolna, aby zacząć na nią reagować. Jeśli podczas stuknięcia przeglądarka zajmowała się JavaScriptem, stuknięcie musiało poczekać w kolejce. To oczekiwanie było „opóźnieniem”.

Dwie rzeczy, których nie mierzyło:

• Jak długo działał kod przycisku po jego uruchomieniu.
• Jak długo strona potrzebowała potem na wizualną aktualizację.

Tylko oczekiwanie, zanim cokolwiek mogło się rozpocząć. Ta wąska definicja jest ważnym powodem, dla którego FID ostatecznie zastąpiono.

Co oznaczał dobry wynik

FID wyrażano w milisekundach:

• Dobry: 100 ms lub mniej
• Wymaga poprawy: 100–300 ms
• Słaby: powyżej 300 ms

Dlaczego nie musisz się już tym przejmować

Oto najważniejsza informacja dla każdego, kto czyta to w 2026 r.: FID zostało wycofane. Google zastąpiło je jako Core Web Vital metryką INP (Interaction to Next Paint) 12 marca 2024 r. — tego samego dnia Search Console przestało wyświetlać FID. PageSpeed Insights i API CrUX raportowały je jeszcze przez krótki czas, po czym usunęły je 9 września 2024 r. Jeśli poradnik lub stary pulpit nadal wymienia FID jako aktualny Core Web Vital, jego treść jest nieaktualna.

INP wykonuje to samo zadanie lepiej: zamiast mierzyć wyłącznie oczekiwanie na pierwszą interakcję, mierzy pełną responsywność każdej interakcji podczas wizyty. Jeśli chcesz, aby witryna działała dziś żwawo, obserwuj INP, a nie FID.

Chcesz poznać pełną historię — dokładne progi, powód tak wąskiej konstrukcji FID, miejsce przechowywania starych danych FID i sposób ich odniesienia do INP? Przejdź do karty Advanced.

TL;DR — FID było Core Web Vital odpowiedzialnym za responsywność do czasu zastąpienia go przez INP 12 marca 2024 r. — tego samego dnia Search Console usunęło je ze swojego raportu. Narzędzia Chrome, PageSpeed Insights i działające API CrUX obsługiwały je jeszcze przez pewien czas i zakończyły to 9 września 2024 r., każde według własnego harmonogramu. FID mierzyło wyłącznie opóźnienie wejścia pierwszej interakcji — nie czas działania handlera ani ponownego rysowania — celowo, aby uniknąć wypaczonych zachęt. Progi: dobry ≤100 ms, słaby >300 ms przy p75, wyłącznie w polu (Total Blocking Time był przybliżeniem laboratoryjnym — skorelowaną diagnostyką, a nie wzorem konwersji). Nie myl tych progów z 200/500 ms dla INP i nie próbuj przeliczać liczby jednej metryki na drugą. Słabe FID wynikało z rywalizacji o główny wątek — długich zadań JavaScript — czyli dokładnie z tego, co powoduje słabe INP i TBT, dlatego poprawki dla starej metryki nadal pomagają. Historyczne dane FID przetrwały w zbiorze CrUX BigQuery (do wydania 202409); wszędzie indziej na żywo już ich nie ma.

Co naprawdę mierzyło FID

Google’s definition was precise. Per web.dev: “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” (Polski gloss: „FID mierzy czas od pierwszej interakcji użytkownika ze stroną do chwili, gdy przeglądarka może zacząć przetwarzać handlery zdarzeń w odpowiedzi na tę interakcję”).

Przeczytaj to uważnie, bo zakres jest tu najważniejszy. FID obejmowało opóźnienie przed rozpoczęciem przetwarzania — i nic ponadto. Nie czas działania handlera zdarzenia. Nie czas potrzebny stronie na narysowanie wyniku. Tylko oczekiwanie.

Why was the browser ever “not able to begin”? web.dev is blunt about the cause: “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” There is one main thread, and if it’s mid-task parsing or executing JavaScript when the user acts, the interaction sits in the queue until that task finishes. I make the same point in my Ahrefs FID guide: there’s just one main thread, JavaScript competes to run tasks on it, and while a task is running the page can’t respond to input — that stall is the delay a user actually feels. (Polski gloss: „Opóźnienie wejścia, nazywane też opóźnieniem interakcji, zwykle wynika z zajętości głównego wątku przeglądarki innym zadaniem, przez co nie może on jeszcze odpowiedzieć użytkownikowi”).

Dlaczego FID mierzyło tylko opóźnienie, a nie całą interakcję

To wygląda jak wada konstrukcyjna, dopóki nie zrozumiesz uzasadnienia. Google celowo mierzyło tylko opóźnienie wejścia. Włączenie czasu wykonania handlera i ponownego rysowania do metryki mogłoby — jak wyjaśnia web.dev — zachęcać developerów do jej obchodzenia: mogliby opakować logikę handlera zdarzenia w asynchroniczne wywołanie zwrotne, oddzielić ją od zadania interakcji i sprawić, że liczba wyglądałaby lepiej, podczas gdy rzeczywiste doświadczenie byłoby gorsze. Dlatego FID pozostało wąskie.

Ta wąskość jest też śmiertelnym ograniczeniem FID. Strona mogła uzyskać świetne FID i nadal sprawiać wrażenie powolnej, ponieważ każda interakcja po pierwszej pozostawała niezmierzona, a wolna część interakcji często przypada na przetwarzanie i ponowne rysowanie, które FID pomijało. Tę lukę miało wypełnić INP.

Progi — i ten błąd, który często popełniasz

Mierzono je na 75. percentylu załadowań stron, osobno dla urządzeń mobilnych i komputerów. Zalecenie web.dev było proste: witryny powinny dążyć do First Input Delay wynoszącego 100 milisekund lub mniej. Mój własny artykuł o FID używa tych samych wartości — dobry wynik ≤100 ms, wymagający poprawy >100 ms i ≤300 ms, słaby >300 ms.

Częsty błąd: mylenie progów FID z progami INP. To różne liczby dla różnych metryk. FID = 100 ms dla wyniku dobrego / 300 ms dla słabego. INP = 200 ms dla dobrego / 500 ms dla słabego. Kilka podsumowań stron trzecich — a nawet automatyczne procesy tworzenia treści — miesza te wartości, więc jeśli widzisz „200 ms” jako dobry próg FID, jest to błąd.

FID było metryką wyłącznie polową

Nigdy nie można było uzyskać FID z Lighthouse ani żadnego narzędzia laboratoryjnego, ponieważ wymagało ono rzeczywistej pierwszej interakcji rzeczywistego użytkownika — web.dev wyraźnie stwierdza, że FID można mierzyć tylko w polu, bo użytkownik musi wejść w interakcję ze stroną. Narzędzia laboratoryjne nie klikają, więc nie miały czego mierzyć.

Laboratoryjnym odpowiednikiem zawsze było Total Blocking Time (TBT). Jak pisałem w moim przewodniku po PageSpeed Insights, w danych laboratoryjnych nie znajdziesz FID ani INP — wymagają kliknięć na stronie, których testy laboratoryjne nie odtwarzają — dlatego jako metryki zastępczej używa się Total Blocking Time, aby wiedzieć, nad czym pracować. Ta zależność przetrwała FID: TBT jest obecnie laboratoryjnym przybliżeniem INP.

Warto jasno zaznaczyć jedną rzecz: TBT to skorelowana diagnostyka, a nie wzór konwersji. Nigdy nie istniało równanie zamieniające liczbę TBT na dokładną wartość FID i nie ma go również dla INP — słaby wynik TBT mówi, że prawdopodobną przyczyną jest praca głównego wątku, a nie jaka byłaby wartość FID lub INP w polu.

Dlaczego wycofano FID: przejście na INP

Następcę FID zapowiedziano z dużym wyprzedzeniem. Według web.dev INP oficjalnie stało się Core Web Vital i zastąpiło FID 12 marca 2024 r.; wtedy FID wycofano i usunięto z programu. Uzasadnienie Google było następujące: z czasem stało się jasne, że potrzebna jest nowa metryka obejmująca aspekty interaktywności, których FID nie uwzględniało.

Oś czasu miała dwa odrębne kamienie milowe — warto je rozróżniać, bo łatwo i często sprowadza się je do jednej daty:

1. 12 marca 2024 r. — wycofanie jako Core Web Vital. INP przejęło tę rolę; FID przestało należeć do podstawowego zbioru istotnego dla rankingu. Tego samego dnia Search Console usunęło FID ze swojego raportu Core Web Vitals.
2. 9 września 2024 r. — usunięcie z narzędzi według harmonogramów zależnych od produktu. Według web.dev od tej daty FID nie było już obsługiwane w narzędziach Chrome. PageSpeed Insights przestało wyświetlać dane FID od prawdziwych użytkowników, a API CrUX przestało udostępniać tę metrykę; zbiór CrUX BigQuery przestał dodawać nowe pola FID od wydania 202409, choć wcześniejsze miesiące pozostały dostępne do odpytywania.

Nie jest prawdą, że każda usługa Google usunęła FID 9 września — granica dla Search Console nastąpiła sześć miesięcy wcześniej i była związana z zastąpieniem FID przez INP, a nie z późniejszym sprzątaniem narzędzi.

Własny artykuł web.dev o FID zaczyna się dziś od komunikatu o wycofaniu: First Input Delay nie jest już Core Web Vital i zostało zastąpione przez metrykę Interaction to Next Paint (INP). Aktualna dokumentacja Google Search Central dotycząca Core Web Vitals w ogóle nie wspomina o FID — obejmuje tylko LCP, INP i CLS. Gdy dokument o oficjalnym rankingu przestaje wymieniać metrykę, trudno o wyraźniejszy sygnał jej wycofania.

FID a INP: co się zmieniło

Obie metryki mierzą rzeczywiście różne rzeczy, dlatego nie można po prostu przełożyć jednej na drugą:

Sedno sprawy: FID mierzyło próg wejścia jednej interakcji; INP mierzy całą podróż każdej interakcji. Nie ma wzoru przeliczającego starą liczbę FID na równoważną liczbę INP, a FID jednej strony w porównaniu z innymi stronami nie przewiduje jej pozycji w rankingu INP względem tych samych stron — mierzą różne zbiory interakcji wobec różnych punktów końcowych, więc podobieństwo obu liczb na konkretnej stronie jest przypadkowe, a nie regułą. Pełny opis metryki, która ją zastąpiła, znajdziesz w Interaction to Next Paint.

Gdzie nadal znajdują się stare dane FID

Wycofanie metryki nie wymazało historycznego zapisu. Oto, co zniknęło, a co pozostało:

• Zniknęły (na żywo / w bieżących interfejsach): raport Core Web Vitals w Search Console usunął FID 12 marca 2024 r., w dniu przejęcia tej roli przez INP. Interfejs PageSpeed Insights i działające API CrUX raportowały je jeszcze przez krótki czas i zakończyły to 9 września 2024 r.
• Nadal dostępne (historyczne): dane FID sprzed odcięcia można odpytywać w publicznym zbiorze CrUX BigQuery — ale tylko do zbioru danych 202409; BigQuery przestało dodawać nowe pola FID od tego wydania, choć wcześniejsze miesiące pozostały na miejscu. Jeśli musisz odtworzyć dawną historię responsywności witryny, właśnie tam jej szukaj — nie w narzędziach działających na żywo. Przypinaj miesiąc zbioru danych, gdy cytujesz liczbę, oznaczaj ją jako historyczną i nie traktuj starej wartości FID jako porównywalnej liczbowo z aktualną wartością INP — nie ma między nimi przelicznika.

Czy FID nadal ma dziś znaczenie?

Bezpośrednio — nie; nie ma już czego mierzyć ani raportować, więc nie ma czego „naprawiać”. Jednak przyczyny słabego FID i przyczyny słabego INP są niemal identyczne: długie zadania JavaScript zajmujące główny wątek. Dlatego praca wykonana wcześniej nad poprawą FID nie poszła na marne. Jak zauważam w moim przewodniku po FID, mimo że FID zastąpiono przez INP w marcu 2024 r., nadal warto pracować nad tymi samymi przyczynami — wiele działań poprawiających TBT i FID poprawia także INP.

Poprawki, które zmniejszały FID, są tymi samymi, które pomagają teraz INP i TBT:

• Ogranicz ilość JavaScriptu, który wysyłasz.
• Ładuj JavaScript później, gdy to możliwe (async/defer).
• Dziel długie zadania za pomocą code splittingu, aby żadne pojedyncze zadanie nie monopolizowało głównego wątku.
• Przenieś pracę poza główny wątek za pomocą web workerów.
• Używaj renderowania po stronie serwera albo prerenderingu, aby ograniczyć pracę po stronie klienta.

Czy FID było kiedyś ważnym czynnikiem rankingowym?

Nawet gdy było aktywne, FID — jako część Core Web Vitals — nigdy nie było silnym sygnałem rankingowym. Przedstawiciele Google wielokrotnie opisywali Core Web Vitals jako coś bliższego kryterium rozstrzygającemu remis niż głównemu sygnałowi, stosowanemu tylko wtedy, gdy inne elementy są mniej więcej równe. Mój własny wniosek z mojego przewodnika po Core Web Vitals jest taki: “I don’t think Core Web Vitals have much impact on SEO and, unless you are extremely slow, I generally won’t prioritize fixing them.” (Polski gloss: „Nie sądzę, aby Core Web Vitals miały duży wpływ na SEO i, jeśli strona nie jest wyjątkowo wolna, na ogół nie traktuję ich naprawy priorytetowo”). FID rzadko było wyróżniane samo w komentarzach przedstawicieli — niemal zawsze omawiano je jako część pakietu Core Web Vitals, a nie samodzielną dźwignię rankingową.

Bing i FID

Nie ma tu praktycznie osobnego wątku dotyczącego Binga. Bing nigdy nie przyjął Core Web Vitals jako nazwanego sygnału rankingowego w sposób, w jaki zrobiło to Google, i nigdy nie opublikował własnych progów FID (ani INP). Bing ogólnie zwraca uwagę na szybkie, responsywne strony, ale FID od początku do końca było metryką ekosystemu Google.

Co dalej

FID należy do inicjatywy Web Vitals, w klastrze Web Performance. Metryki najbardziej związane z FID:

• Interaction to Next Paint — Core Web Vital, który zastąpił FID i pod który należy dziś faktycznie optymalizować.
• Total Blocking Time — laboratoryjne przybliżenie, które zastępowało FID (a teraz zastępuje INP), gdy nie można było mierzyć rzeczywistych interakcji.
• Core Web Vitals — istotna dla rankingu trójka (LCP, INP, CLS), do której FID kiedyś należało.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• FID = wycofane Core Web Vital dotyczące responsywności. Mierzyło tylko opóźnienie wejścia pierwszej interakcji — oczekiwanie, zanim przeglądarka mogła zacząć przetwarzać handler zdarzenia — a nie czas działania handlera ani ponowne rysowanie.
• Progi: dobry ≤ 100 ms, wymaga poprawy 100–300 ms, słaby > 300 ms, przy 75. percentylu, osobno dla urządzeń mobilnych i komputerów. Tylko pole — nigdy nie dało się go zmierzyć w Lighthouse; Total Blocking Time było przybliżeniem laboratoryjnym.
• Nie myl progów: FID = 100/300 ms; INP = 200/500 ms. Różne metryki, różne liczby.
• Przyczyna słabego FID: rywalizacja o główny wątek — długie zadania JavaScript. Ta sama przyczyna źródłowa co w przypadku słabego INP i TBT.
• Oś czasu wycofania: zastąpione przez INP 12 marca 2024 r. — tego samego dnia Search Console usunęło FID ze swojego raportu. Narzędzia Chrome, PageSpeed Insights i działające API CrUX przestały je obsługiwać 9 września 2024 r., każde według własnego harmonogramu — nie była to jedna uniwersalna data. Aktualny dokument Google Search Central o CWV już o nim nie wspomina.
• FID a INP: FID mierzyło opóźnienie pierwszej interakcji; INP mierzy pełne opóźnienie wszystkich interakcji (opóźnienie + przetwarzanie + prezentacja). Nie ma wzoru, który przeliczałby liczbę jednej metryki na drugą.
• Stare dane: zniknęły z narzędzi działających na żywo; dane FID sprzed odcięcia nadal znajdują się w zbiorze CrUX BigQuery do wydania 202409 — przypnij miesiąc zbioru danych i nie porównuj ich liczbowo z aktualnym INP.
• Nigdy nie przeliczaj: TBT jest skorelowanym laboratoryjnym przybliżeniem FID i INP, a nie wzorem tłumaczącym jedną metrykę na drugą.
• Czy nadal ma znaczenie? Nie ma czego bezpośrednio naprawiać, ale poprawki JavaScriptu (ograniczenie/opóźnienie ładowania, dzielenie długich zadań, web workery, SSR) przenoszą się bezpośrednio na INP i TBT.
• Waga rankingowa: nawet gdy było aktywne — niewielka; CWV przedstawiano jako kryterium rozstrzygające remis. Patrick: nie traktuj go priorytetowo, chyba że strona jest wyjątkowo wolna. Bing nie ma odpowiednika FID.

Dokumentacja oficjalna

Dokumentacja z podstawowych źródeł dotycząca FID i jego wycofania.

Google / web.dev

• First Input Delay (FID) — definicja metryki, progi, powód mierzenia wyłącznie opóźnienia wejścia i komunikat o wycofaniu (Philip Walton; aktualizacja 2024-10-06).
• Chrome kończy obsługę First Input Delay — usunięcie z narzędzi Chrome, PSI i API CrUX we wrześniu 2024 r. (Rick Viscomi).
• Interaction to Next Paint staje się Core Web Vital 12 marca — zapowiedź zastąpienia FID przez INP (Jeremy Wagner, Rick Viscomi).
• Zrozumienie Core Web Vitals i wyników wyszukiwania Google — aktualny dokument rankingowy, który wymienia tylko LCP, INP i CLS (bez FID).
• Interaction to Next Paint (INP) — metryka, która zastąpiła FID.

MDN

• First Input Delay (FID) — glosariusz — krótka definicja referencyjna.

Bing / Microsoft

• Brak materiału dotyczącego wyłącznie FID. Bing nigdy nie opublikował progów FID ani nie nazwał Core Web Vitals własnym sygnałem rankingowym.

Cytaty ze źródła

Wypowiedzi dostępne w oficjalnej dokumentacji web.dev Google. Każdy odnośnik prowadzi bezpośrednio do cytowanego fragmentu na stronie źródłowej.

Google / web.dev — co mierzyło FID

• “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” Przejdź do cytatu
• “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” Przejdź do cytatu (Polski gloss: „FID mierzy czas od pierwszej interakcji użytkownika ze stroną — kliknięcia odnośnika, stuknięcia przycisku lub użycia własnego sterowania JavaScript — do chwili, gdy przeglądarka może zacząć przetwarzać handlery zdarzeń w odpowiedzi na tę interakcję”. Drugi cytat: „Opóźnienie wejścia, nazywane też opóźnieniem interakcji, zwykle wynika z zajętości głównego wątku przeglądarki innym zadaniem, przez co nie może on jeszcze odpowiedzieć użytkownikowi”).

Google / web.dev — „dobry” próg

• “To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.” Przejdź do cytatu (Polski gloss: „Aby zapewnić dobre doświadczenie użytkownika, witryny powinny dążyć do First Input Delay wynoszącego 100 milisekund lub mniej”).

Ściąga First Input Delay

Status: wycofane. Zachowaj tę informację do odczytywania starszych danych i raportów — nie jako cel optymalizacji.

FID w skrócie

FID a INP — nie mieszaj ich

Najważniejsze daty

• 12 marca 2024 r. — INP zastępuje FID jako Core Web Vital; Search Console tego samego dnia usuwa FID ze swojego raportu.
• 9 września 2024 r. — narzędzia Chrome, PageSpeed Insights i działające API CrUX przestają obsługiwać FID, każde według własnego harmonogramu (nie jest to ta sama data co w GSC).

Gdzie są dziś dane FID

• Narzędzia działające na żywo (interfejs PSI, GSC, API CrUX): brak (GSC od 12 marca 2024 r.; PSI/CrUX od 9 września 2024 r.).
• Historia sprzed odcięcia: zbiór danych CrUX BigQuery, do wydania 202409. Nie porównuj jego liczb bezpośrednio z aktualnym INP — nie ma między nimi przelicznika.

Naprawa przyczyny źródłowej (pomaga teraz INP/TBT)

• Ogranicz JavaScript · odrocz ładowanie przez defer/async · dziel długie zadania (code splitting) · używaj web workerów · SSR/prerendering.

Błędy, których należy unikać przy pracy ze starymi danymi FID

Traktowanie FID jako aktualnego Core Web Vital

FID zastąpiono przez INP w marcu 2024 r., a później w tym samym roku usunięto z aktualnych interfejsów raportowania Chrome. Do bieżących prac nad responsywnością używaj INP; FID zachowaj wyłącznie do interpretacji historycznych zbiorów danych.

Porównywanie FID i INP przy użyciu tych samych progów

Historyczne progi Dobry/Słaby dla FID wynosiły 100/300 ms, a dla INP wynoszą 200/500 ms. Liczby nie są wymienne, ponieważ FID mierzyło tylko opóźnienie przed handlerem, podczas gdy INP obejmuje całą interakcję aż do kolejnego rysowania.

Szukanie FID w teście laboratoryjnym

FID wymagało rzeczywistego pierwszego wejścia użytkownika i było metryką wyłącznie polową. Total Blocking Time było przybliżeniem laboratoryjnym; wynik Lighthouse nigdy nie był bezpośrednią obserwacją FID.

Optymalizowanie wycofanego wyniku zamiast problemu użytkownika

Nie utrzymuj pulpitu FID jako celu. Dziel długie zadania głównego wątku i ogranicz blokujący JavaScript, a następnie mierz bieżącą responsywność za pomocą INP w polu.

Sprawdź się: First Input Delay (FID)

Pięć krótkich pytań o tym, co mierzyło FID i dlaczego je wycofano. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Dziennik zmian