INP zastąpiło FID — co musisz wiedzieć

W marcu 2024 roku Google formalnie zastąpiło First Input Delay przez Interaction to Next Paint jako trzeci filar Core Web Vitals obok LCP i CLS. Dla wielu właścicieli stron ta zmiana przeszła niezauważenie, dopóki w Google Search Console nie pojawiły się nowe, gorsze oceny responsywności. INP Core Web Vitals mierzy responsywność strony w zupełnie inny sposób niż FID — bardziej rygorystyczny i bliższy temu, co użytkownik faktycznie odczuwa podczas korzystania ze strony.

W tym artykule wyjaśniamy, na czym polegała zmiana, dlaczego FID przestało wystarczać jako miara responsywności oraz jakie konkretne działania pozwalają utrzymać dobry wynik INP.

Czym było FID i dlaczego przestało wystarczać

First Input Delay mierzył wyłącznie czas od momentu, w którym użytkownik po raz pierwszy wchodził w interakcję ze stroną — na przykład klikał przycisk lub link — do chwili, gdy przeglądarka mogła zacząć przetwarzać tę interakcję. FID nie uwzględniał jednak dwóch istotnych elementów: czasu potrzebnego na faktyczne wykonanie kodu obsługującego zdarzenie oraz czasu do wyrenderowania kolejnej klatki, w której użytkownik widzi efekt swojego działania.

W praktyce oznaczało to, że strona mogła mieć doskonały wynik FID, a jednocześnie sprawiać wrażenie „zawieszonej" — na przykład gdy kliknięcie w menu mobilne rejestrowało się natychmiast, ale samo menu pojawiało się na ekranie z zauważalnym opóźnieniem. FID mierzył też tylko pierwszą interakcję w danej sesji, więc kolejne kliknięcia, przewijanie czy wypełnianie formularza pozostawały poza jego zasięgiem. To sprawiało, że metryka dawała niepełny obraz rzeczywistego doświadczenia użytkownika.

Jak działa INP Core Web Vitals

Interaction to Next Paint mierzy responsywność strony w całej sesji użytkownika, a nie tylko przy pierwszej interakcji. Dla każdego kliknięcia, dotknięcia ekranu czy naciśnięcia klawisza INP rejestruje czas od momentu interakcji do wyrenderowania kolejnej klatki, w której widoczna jest wizualna odpowiedź na to działanie. Jako wynik strony przyjmowana jest zazwyczaj najwyższa (najgorsza) wartość spośród wszystkich zarejestrowanych interakcji, z pominięciem nielicznych wartości odstających przy bardzo dużej liczbie interakcji.

Google przyjmuje następujące progi dla INP mierzonego na 75. percentylu wizyt:

• Dobry wynik — 200 milisekund lub mniej.
• Wymaga poprawy — od 200 do 500 milisekund.
• Słaby wynik — powyżej 500 milisekund.

Taka konstrukcja metryki oznacza, że strona z rozbudowaną interaktywnością — formularzami, filtrami, animowanymi komponentami — musi utrzymywać responsywność konsekwentnie, przez cały czas trwania sesji, a nie tylko przy pierwszym kliknięciu.

Najczęstsze przyczyny wysokiego INP

Wysoki wynik INP niemal zawsze wynika z tego, że główny wątek przeglądarki (main thread) jest zablokowany w momencie, gdy użytkownik wchodzi w interakcję. Do najczęstszych źródeł problemu należą:

• Duże, niepodzielone zadania JavaScript, które blokują main thread na setki milisekund.
• Nadmierna liczba lub zbyt duży rozmiar skryptów firm trzecich (analityka, czaty, piksele reklamowe, widżety).
• Kosztowne operacje na DOM wykonywane synchronicznie po kliknięciu, na przykład przeliczanie layoutu dla wielu elementów naraz.
• Nieoptymalne event listenery, które wykonują zbyt wiele pracy zanim przeglądarka zdąży wyrenderować odpowiedź wizualną.
• Hydratacja frameworków JavaScript, która na słabszych urządzeniach mobilnych potrafi zająć main thread na dłuższy czas po załadowaniu strony.

Warto zaznaczyć, że problem z INP częściej ujawnia się na urządzeniach mobilnych o ograniczonej mocy obliczeniowej niż na komputerach stacjonarnych — dlatego pomiary i testy zawsze powinny obejmować realistyczne warunki mobilne, a nie tylko szybki sprzęt deweloperski.

Jak poprawić wynik INP w praktyce

Dziel długie zadania JavaScript

Zamiast wykonywać jedną dużą operację blokującą, warto dzielić ją na mniejsze fragmenty, oddając kontrolę do main thread pomiędzy nimi. Dzięki temu przeglądarka zyskuje okna czasowe, w których może obsłużyć interakcję użytkownika, zamiast czekać na zakończenie długiego zadania.

Ogranicz i odraczaj skrypty firm trzecich

Każdy dodatkowy skrypt analityczny, marketingowy czy czatowy zajmuje main thread i zwiększa ryzyko opóźnień w reakcji na kliknięcia. Warto regularnie audytować, które integracje są faktycznie potrzebne, ładować je z opóźnieniem (po pierwszej interakcji użytkownika) i unikać duplikowania podobnych narzędzi.

Optymalizuj obsługę zdarzeń i renderowanie

Reakcja na kliknięcie powinna w pierwszej kolejności aktualizować to, co użytkownik widzi na ekranie — na przykład stan przycisku czy animację — a dopiero potem wykonywać cięższe operacje, takie jak zapytania sieciowe czy przeliczenia danych. Rozdzielenie tych dwóch etapów sprawia, że wizualna odpowiedź pojawia się szybko, nawet jeśli pełne przetworzenie akcji trwa dłużej w tle.

Zadbaj o architekturę renderowania strony

Sposób, w jaki strona jest budowana i renderowana, ma bezpośredni wpływ na to, ile pracy main thread wykonuje podczas interakcji. Więcej o tym, jak podejść do wskaźników kompleksowo, opisujemy w przewodniku po Core Web Vitals, gdzie INP omawiamy razem z LCP i CLS jako spójny zestaw wymagań technicznych.

INP a pozostałe wskaźniki Core Web Vitals

INP nie działa w oderwaniu od pozostałych metryk. Strona, która nadmiernie polega na dynamicznie wstrzykiwanych elementach czy animacjach uruchamianych po interakcji, często ma problemy nie tylko z responsywnością, ale też ze stabilnością layoutu — zjawisko to szerzej opisujemy w artykule o skakaniu layoutu i wskaźniku CLS. Podobnie duże, nieoptymalizowane obrazy potrafią obciążać main thread podczas dekodowania i przeliczania układu strony, co pośrednio wpływa również na responsywność — więcej na ten temat piszemy w tekście o optymalizacji obrazów na stronie.

Traktowanie Core Web Vitals jako zestawu trzech powiązanych ze sobą wskaźników, a nie osobnych, niezależnych zadań, pozwala uniknąć sytuacji, w której poprawa jednej metryki pogarsza inną.

Jak sprawdzić wynik INP na swojej stronie

Ponieważ INP opiera się na rzeczywistych interakcjach użytkowników, najbardziej wiarygodnym źródłem danych jest Google Search Console (raport Core Web Vitals) oraz Chrome User Experience Report, a nie testy laboratoryjne wykonywane jednorazowo w narzędziach deweloperskich. Testy laboratoryjne — na przykład symulacje interakcji w narzędziach do audytu wydajności — są przydatne do diagnozowania konkretnych problemów, ale nie zastępują danych z realnego ruchu, ponieważ nie odzwierciedlają pełnej różnorodności urządzeń i warunków sieciowych odwiedzających.

1. Sprawdź raport Core Web Vitals w Google Search Console dla adresów URL zgrupowanych mobilnie i desktopowo.
2. Zidentyfikuj strony i typy interakcji odpowiedzialne za najgorsze wyniki.
3. Wykonaj profilowanie main thread w narzędziach deweloperskich przeglądarki, symulując interakcję na wskazanych stronach.
4. Wdrażaj poprawki iteracyjnie i monitoruj zmianę wyniku w kolejnych tygodniach, ponieważ dane w Search Console są uśredniane z pewnym opóźnieniem.

Najczęstsze pytania

Czy FID nadal ma jakiekolwiek znaczenie po zastąpieniu przez INP?

FID nie jest już częścią Core Web Vitals i nie wpływa na oceny w Google Search Console. Warto jednak pamiętać, że dobra responsywność w rozumieniu FID nie gwarantuje dobrego wyniku INP, ponieważ ta druga metryka obejmuje znacznie szerszy zakres interakcji i etapów przetwarzania.

Czy INP dotyczy tylko stron z dużą liczbą interakcji, na przykład sklepów internetowych?

Nie. INP mierzone jest dla każdej strony, na której użytkownik wykonuje choćby jedną interakcję — kliknięcie linku, przycisku czy pola formularza. Strony z bogatą interaktywnością są bardziej narażone na problemy, ale dobry wynik INP jest istotny dla każdego typu witryny.

Jak szybko po wdrożeniu poprawek zobaczę zmianę wyniku INP w Search Console?

Google opiera raport Core Web Vitals na danych zbieranych z rzeczywistych wizyt w okresie kilkudziesięciu dni, dlatego zmiana wyniku po wdrożeniu poprawek widoczna jest z opóźnieniem, a nie natychmiast. Do bieżącej weryfikacji lepiej sprawdzają się testy laboratoryjne wykonywane bezpośrednio po zmianach.

Czy INP zależy wyłącznie od kodu frontendu, czy też od hostingu i backendu?

INP w największym stopniu zależy od tego, co dzieje się w przeglądarce użytkownika po stronie klienta — od ilości i sposobu wykonywania JavaScriptu. Backend i hosting mają większy wpływ na LCP, natomiast na INP oddziałują pośrednio, na przykład poprzez opóźnione odpowiedzi na żądania wywoływane w trakcie interakcji.

Jeśli Twoja strona notuje słabe wyniki INP w Google Search Console lub podejrzewasz, że interaktywne elementy działają wolniej, niż powinny, warto zlecić audyt techniczny. Sprawdź ofertę optymalizacji Core Web Vitals od 2BInteractive — przeanalizujemy main thread Twojej strony, wskażemy konkretne przyczyny opóźnień i wdrożymy poprawki, które realnie przełożą się na wynik INP.