INP w praktyce: jak zdiagnozować i naprawić opóźnioną reakcję strony bez przepisywania jej od zera

Czym jest INP i co dokładnie mierzy

INP mierzy, jak długo strona blokuje narysowanie kolejnej klatki po działaniu użytkownika. Dokumentacja web.dev wymienia trzy rodzaje działań liczonych jako interakcja: kliknięcie myszą, kliknięcie na ekranie dotykowym i naciśnięcie klawisza na klawiaturze. Przewijanie i najeżdżanie kursorem się nie liczą.

Warto od razu wyprostować najczęstsze nieporozumienie, bo od niego zależy, czy diagnoza w ogóle ruszy w dobrą stronę. INP nie mierzy, jak długo trwa cała operacja uruchomiona kliknięciem. Mierzy tylko odcinek do najbliższej klatki, w której użytkownik zobaczy jakąkolwiek reakcję. Dokumentacja stawia to wprost: celem nie jest pomiar wszystkich ostatecznych efektów interakcji, tylko czasu, przez który blokowane jest kolejne wyrenderowanie.

Praktyczna konsekwencja jest taka, że formularz, który po kliknięciu natychmiast pokazuje wskaźnik ładowania, a odpowiedź z serwera dostaje po dwóch sekundach, może mieć znakomity INP. I odwrotnie: przycisk, który przez pół sekundy nie robi nic widocznego, a potem pokazuje wynik od razu, będzie miał INP fatalny. To jest dźwignia, o której zapomina się najczęściej — czasem wystarczy pokazać reakcję wcześniej, zamiast przyspieszać całą operację.

Historia wskaźnika też ma znaczenie, bo w sieci wciąż krążą poradniki opisujące poprzednika. INP stał się Core Web Vitalem 12 marca 2024 roku i zastąpił wtedy FID; ogłaszający to wpis na blogu web.dev ukazał się 31 stycznia 2024 roku. Wsparcie dla FID w narzędziach Chrome skończyło się 10 września 2024 roku — od tego dnia PageSpeed Insights przestał raportować FID w sekcji danych rzeczywistych użytkowników, a interfejsy CrUX przestały go udostępniać. Jeśli więc trafisz na materiał mówiący o „pierwszym opóźnieniu wejścia”, sprawdź jego datę, zanim cokolwiek z niego wdrożysz.

Jaka wartość INP jest dobra, a jaka zła

Dobra wartość INP to 200 milisekund lub mniej, przedział od 200 do 500 milisekund oznacza wynik wymagający poprawy, a powyżej 500 milisekund — wynik słaby. Sama liczba jest jednak mniej istotna od sposobu jej liczenia: dokumentacja zaleca mierzenie 75. percentyla wczytań strony zarejestrowanych w terenie, osobno dla urządzeń mobilnych i komputerów.

To rozróżnienie decyduje o tym, czy praca ma sens. Nie chodzi o to, żeby strona działała szybko na Twoim laptopie, tylko żeby działała szybko u trzech czwartych realnych użytkowników — razem z ich telefonami sprzed czterech lat i słabym zasięgiem. Wynik na jednym urządzeniu nie jest pomiarem, tylko anegdotą.

Obok trzech wskaźników podstawowych dokumentacja wymienia wskaźniki uzupełniające, które służą do diagnozy, a nie do oceny: czas do pierwszego bajta i pierwsze wyrenderowanie treści pomagają zrozumieć problemy z LCP. Dla INP odpowiednikiem diagnostycznym jest całkowity czas blokowania, o którym za chwilę.

Dlaczego wysoki wynik w PageSpeed nie mówi nic o INP

INP nie wchodzi do wyniku wydajności Lighthouse i nie ma go w danych laboratoryjnych PageSpeed Insights — a to znaczy, że wynik z testu nie jest dowodem na nic w sprawie responsywności. Powód jest prozaiczny: INP wymaga prawdziwych interakcji, a test laboratoryjny wczytuje stronę i w nią nie klika.

Na wynik wydajności Lighthouse składa się pięć wskaźników z konkretnymi wagami: pierwsze wyrenderowanie treści 10%, Speed Index 10%, największe wyrenderowanie treści 25%, całkowity czas blokowania 30% i skumulowane przesunięcie układu 25%. INP nie występuje w tej tabeli w ogóle. Dokumentacja PageSpeed Insights wymienia go natomiast wśród danych terenowych, pochodzących z raportu Chrome User Experience i obejmujących poprzednie 28 dni.

Najbliższym laboratoryjnym przybliżeniem jest całkowity czas blokowania i dokumentacja mówi o tym wprost.

TBT jest wskaźnikiem zastępczym dla INP w warunkach laboratoryjnych.

web.dev, artykuł „Całkowity czas blokowania (TBT)”, wersja polska, odczyt 18.08.2026

Całkowity czas blokowania liczy się jako suma nadwyżek ponad 50 milisekund we wszystkich długich zadaniach po pierwszym wyrenderowaniu treści — zadanie trwające 150 milisekund wnosi do niego 100 milisekund. Dokumentacja zaleca utrzymanie tej wartości poniżej 200 milisekund przy testowaniu na przeciętnym sprzęcie mobilnym. To dobry wskaźnik pomocniczy, bo można go zmierzyć od razu po wdrożeniu zmiany, nie czekając miesiąca na dane terenowe. Ale zastępnik to nie to samo co pomiar: sama dokumentacja zaleca, żeby w realnych warunkach optymalizować pod INP, bo w laboratorium nikt w stronę nie klika.

Gdzie sprawdzić INP swojej strony

Punktem wyjścia są dane terenowe, a dla większości firm najwygodniejszym wejściem jest raport Core Web Vitals w Search Console. Działa on na danych z raportu Chrome User Experience obejmujących 28 dni wstecz i — co ważne przy diagnozie — przypisuje je do rzeczywistego adresu URL, a nie do kanonicznego, jak większość pozostałych raportów.

Warto znać jeszcze dwa ograniczenia samego zbioru CrUX, bo tłumaczą sytuację, w której raport po prostu milczy. Po pierwsze, strona musi być publicznie wykrywalna: adresy zwracające kod inny niż 200 albo oznaczone jako niepodlegające indeksowaniu do zbioru nie wchodzą. Po drugie, źródła i strony, w przypadku których ponad 20% ruchu jest wykluczane z powodu niekwalifikujących się kombinacji wymiarów, są ze zbioru usuwane w całości. Brak danych nie oznacza więc dobrego wyniku — oznacza brak danych.

Trzy części interakcji: gdzie ucieka czas

Każda interakcja składa się z trzech odcinków i naprawa zaczyna się od ustalenia, który z nich jest najdłuższy. Pierwszy to opóźnienie wejścia — czas od działania użytkownika do uruchomienia procedur obsługi zdarzeń. Drugi to czas przetwarzania, czyli wykonanie wszystkich wywołań zwrotnych. Trzeci to opóźnienie wyświetlenia — czas do wyrenderowania następnej klatki.

Rozróżnienie ma znaczenie praktyczne, bo każdy odcinek naprawia się czym innym, a wybranie złego narzędzia to stracony sprint. Skracanie kodu w procedurze obsługi zdarzeń nie pomoże, jeśli problemem jest opóźnienie wejścia spowodowane skryptem ocenianym w tle.

Jak namierzyć konkretną wolną interakcję

Najskuteczniejszym narzędziem jest biblioteka web-vitals w wersji z atrybucją, wpięta na produkcji — bo tylko produkcja ma prawdziwych użytkowników. Sama biblioteka waży około 2 kilobajtów po kompresji, a wersja z atrybucją mniej więcej półtora kilobajta więcej, więc koszt wdrożenia jest znikomy w porównaniu z tym, co daje.

Dla INP atrybucja zwraca selektor elementu, w który kliknięto, typ interakcji, rozbicie czasu na opóźnienie wejścia, czas przetwarzania i opóźnienie wyświetlenia, stan wczytywania dokumentu oraz powiązane wpisy Long Animation Frames. To jest różnica między „mamy słaby INP na stronie produktu” a „przycisk dodania do koszyka blokuje klatkę na 480 milisekund, z czego 390 to czas przetwarzania”.

Drugą warstwą jest interfejs Long Animation Frames, dostępny w Chrome i Edge od wersji 123. Za długą klatkę uznaje on taką, której aktualizacja renderowania opóźniła się o więcej niż 50 milisekund, a udostępnia między innymi czas blokowania, moment rozpoczęcia renderowania i obliczeń układu oraz tablicę skryptów z adresem źródła i nazwą funkcji. Dokumentacja zauważa, że większość problematycznych przypadków INP powinna mieć powiązane dane z tego interfejsu — czyli w praktyce wskazuje on konkretny plik, a nie tylko objaw.

Lokalnie pomaga panel Performance w Chrome DevTools, w którym można nagrać sesję i ograniczyć wydajność procesora, na przykład czterokrotnie, żeby zobaczyć zachowanie strony na słabszym urządzeniu. To dobre miejsce do sprawdzenia hipotezy przed wdrożeniem, ale nie do jej postawienia — hipoteza powinna wyjść z danych terenowych.

Co najczęściej psuje INP

W zdecydowanej większości przypadków winne są długie zadania w wątku głównym, czyli takie, które trwają dłużej niż 50 milisekund. Dopóki takie zadanie się wykonuje, przeglądarka nie może zareagować na kliknięcie — i to jest cała mechanika problemu.

Pierwsze źródło długich zadań to ocena skryptów przy wczytywaniu strony. Przeglądarka musi każdy skrypt przetworzyć i skompilować, zanim go uruchomi, a ta praca blokuje wątek główny. Dokumentacja podaje tu konkretną wskazówkę wielkościową: około 100 kilobajtów na pojedynczy skrypt to rozsądny kompromis między skutecznością kompresji, czasem pobierania i czasem oceny. Zwraca też uwagę na pułapkę, o której mało kto wie: w przeglądarkach opartych na Chromium wszystkie skrypty z atrybutem defer wykonują się w jednym zadaniu razem ze zdarzeniem DOMContentLoaded, co potrafi to zadanie wydłużyć.

Drugie źródło to skrypty zewnętrzne. Dokumentacja web.dev opisuje ich wpływ dwutorowo: obciążają sieć i opóźniają renderowanie, a przy wykonaniu synchronicznym na ścieżce krytycznej wstrzymują przetwarzanie reszty dokumentu. Podaje przy tym scenariusz, który warto znać przed dołożeniem kolejnego narzędzia analitycznego: jeśli dostawca ma problem po swojej stronie, renderowanie może być zablokowane na czas od 10 do 80 sekund, aż żądania wygasną. W praktyce menedżer tagów bywa na typowej stronie firmowej największym pojedynczym źródłem obcego kodu.

Trzecie źródło to rozmiar DOM. Lighthouse zaczyna ostrzegać po przekroczeniu 800 węzłów, a przy 1400 traktuje to jako błąd. Duży DOM szkodzi na trzy sposoby naraz: wydłuża pierwsze renderowanie, podnosi koszt każdej aktualizacji wywołanej interakcją i zwiększa zużycie pamięci przez zapytania JavaScriptu przechowujące referencje do elementów.

Czwarte, najczęściej pomijane, to szarpanie układu — sytuacja, w której kod odczytuje wartość stylu, natychmiast ją zmienia i robi to w pętli, zmuszając przeglądarkę do przeliczenia układu przy każdym obrocie. Wymuszają je zmiany właściwości geometrycznych, takich jak szerokość, wysokość czy pozycja. Osobno warto sprawdzić timery: dokumentacja wskazuje setInterval jako szczególnie kłopotliwy, bo uruchamia wywołanie zwrotne w nieskończoność i prędzej czy później wejdzie w drogę interakcji.

Naprawy, które nie wymagają przepisywania strony

Najważniejsza technika to dzielenie pracy i oddawanie sterowania wątkowi głównemu — i nie wymaga ona przebudowy niczego poza pojedynczą funkcją. Zasada jest prosta: gdy zadania są podzielone, przeglądarka może znacznie wcześniej zająć się pracą o wyższym priorytecie, w tym interakcjami użytkownika.

Do oddawania sterowania służy nowoczesne API scheduler.yield, które zwraca obietnicę spełnianą w przyszłym zadaniu, a jego przewagą nad starszymi metodami jest to, że kontynuacja wykonuje się przed innymi oczekującymi zadaniami. Wsparcie jest jednak ograniczone: Chrome i Edge od wersji 129, Firefox od 142, Safari nie obsługuje. MDN określa je wprost jako funkcję o ograniczonej dostępności, która nie działa w części najpopularniejszych przeglądarek. Dlatego dokumentacja podaje wzorzec awaryjny: sprawdzić dostępność API i w razie jego braku oddać sterowanie przez setTimeout opakowany w obietnicę. Przy samym setTimeout trzeba pamiętać o jednym ograniczeniu przeglądarki: po pięciu zagnieżdżonych wywołaniach narzuca ona minimalne opóźnienie 5 milisekund.

Druga technika to odkładanie niekrytycznych aktualizacji. Przed najbliższą klatką wykonuj wyłącznie to, co użytkownik ma zobaczyć, a całą resztę logiki przenieś za nią. To jest dokładnie ta dźwignia, o której była mowa na początku: pokazujesz reakcję wcześniej, zamiast przyspieszać całą operację.

Osobnej uwagi wymaga content-visibility, bo daje dużo przy małym nakładzie. Wartość auto pozwala przeglądarce pominąć renderowanie elementów poza ekranem i wznowić je, gdy treść zbliża się do widocznego obszaru; rozmiar zastępczy podaje się właściwością contain-intrinsic-size, żeby pasek przewijania nie skakał. Dokumentacja pokazuje demonstracyjny przykład bloga podróżniczego, w którym czas renderowania spadł z 232 do 30 milisekund — to jest jednak wynik z przykładu w dokumentacji, a nie obietnica dla Twojej strony. Ważne zastrzeżenie: treść pominięta w renderowaniu pozostaje w modelu dokumentu i w drzewie dostępności, więc wyszukiwanie w stronie działa normalnie.

Jeśli szukasz szerszego kontekstu technicznego wokół tych zmian — od dostępności dla robota po renderowanie i migracje — zebraliśmy go w poradniku o SEO technicznym krok po kroku, a wariant sklepowy tych samych problemów opisaliśmy przy Core Web Vitals w Shopify.

W jakiej kolejności to robić

Kolejność jest ważniejsza od techniki, bo większość zmarnowanej pracy przy INP bierze się z naprawiania niewłaściwego odcinka. Zacznij od danych terenowych: sprawdź w raporcie Core Web Vitals, które grupy adresów mają wynik słaby, i dopiero na tej podstawie wybierz szablon strony do analizy.

Drugi krok to atrybucja. Wepnij bibliotekę web-vitals w wersji z atrybucją i zbierz dane przez kilka dni, aż będziesz mieć konkretny element, konkretny typ interakcji i konkretny odcinek czasu. Bez tego kroku każda dalsza decyzja jest zgadywaniem.

Trzeci krok to najtańsza możliwa naprawa z tabeli powyżej, wdrożona pojedynczo. Czwarty to weryfikacja w dwóch warstwach: całkowity czas blokowania od razu po wdrożeniu, jako szybki sygnał kierunku, i dane terenowe po miesiącu, jako rozstrzygnięcie. Wdrażanie kilku zmian naraz jest kuszące, ale odbiera możliwość ustalenia, która zadziałała.

Ile trwa, zanim poprawka będzie widoczna

Pierwszego wiarygodnego sygnału nie zobaczysz wcześniej niż po około miesiącu od wdrożenia. Raport Core Web Vitals w Search Console pracuje na oknie 28 dni wstecz, a procedura walidacji poprawki trwa kolejne 28 dni, w czasie których Search Console obserwuje, czy problem nie wraca na żadnym z adresów.

Dane zbiorcze mają jeszcze wolniejszy rytm: zbiory CrUX w BigQuery publikowane są raz w miesiącu, w drugi wtorek. Warto też wiedzieć, że dotychczasowy CrUX Dashboard jest oznaczony jako przestarzały, a dokumentacja kieruje do nowszego narzędzia CrUX Vis — jeśli więc pracujesz na starym pulpicie, przy najbliższej okazji sprawdź, czy nie warto się przenieść.

Ten rytm ma bezpośrednie przełożenie na sposób prowadzenia projektu. Zmiany pod INP planuje się w cyklach miesięcznych, a nie ocenia następnego dnia, i mówi się o tym klientowi przed startem prac, a nie wtedy, gdy po tygodniu pyta o efekt.

Czego poprawa INP nie załatwi

Poprawa INP nie jest dźwignią pozycji i nie należy jej tak sprzedawać. Strona Google poświęcona Core Web Vitals w wyszukiwarce formułuje to ostrożnie: zaleca właścicielom witryn dążenie do dobrych wyników i mówi, że to właśnie jakość strony systemy rankingowe „starają się nagradzać”. To zdanie o kierunku, nie o gwarancji, i tak trzeba je czytać.

Uczciwe uzasadnienie prac nad INP jest inne i wcale nie słabsze. Wolno reagująca strona kosztuje realne konwersje, niezależnie od tego, co robi z nią wyszukiwarka: użytkownik, który klika przycisk i nie widzi reakcji, klika drugi raz albo wychodzi. Ten argument da się obronić bez powoływania się na ranking.

Warto też zachować proporcje. INP jest zwykle tańszy w naprawie niż LCP, bo w wielu przypadkach nie wymaga zmian w infrastrukturze ani w sposobie budowania serwisu — wystarczy uporządkowanie skryptów i podzielenie kilku funkcji. Ale bywa i tak, że słaby wynik wynika z architektury aplikacji i wtedy rzetelną odpowiedzią jest wskazanie kosztu przebudowy, a nie obiecywanie poprawy kosmetykami. Częstą okolicznością, w której INP nagle się psuje, jest przebudowa serwisu lub zmiana motywu — dlatego warto go zmierzyć przed i po, tak samo jak przy migracji strony.

Checklista diagnostyczna

Poniższa lista prowadzi od danych do decyzji i jest ułożona w kolejności, w której warto ją wykonywać.

• Sprawdź raport Core Web Vitals w Search Console i wypisz grupy adresów z wynikiem słabym oraz wymagającym poprawy, osobno dla urządzeń mobilnych i komputerów.
• Sprawdź w PageSpeed Insights, czy dla wybranego adresu w ogóle są dane terenowe — ich brak nie znaczy, że jest dobrze.
• Nie wyciągaj wniosków o INP z wyniku wydajności w teście laboratoryjnym: tego wskaźnika w nim nie ma.
• Wepnij bibliotekę web-vitals w wersji z atrybucją i zbieraj dane co najmniej kilka dni.
• Ustal dla najgorszej interakcji, który z trzech odcinków czasu jest najdłuższy — od tego zależy wybór naprawy.
• Przejrzyj listę skryptów zewnętrznych i menedżera tagów; usuń to, czego nikt nie używa.
• Policz węzły DOM na najgorszym szablonie i porównaj z progami ostrzeżenia i błędu w Lighthouse.
• Poszukaj w kodzie miejsc, w których odczyt stylu sąsiaduje z jego zmianą w pętli, oraz wywołań setInterval.
• Wdrażaj pojedynczo, od najtańszej naprawy, i mierz całkowity czas blokowania po każdej zmianie.
• Odczekaj pełne okno danych terenowych, zanim uznasz zmianę za skuteczną, i zapowiedz ten termin przed rozpoczęciem prac.

Podsumowanie

INP wyłamuje się z rutyny, do której przyzwyczaiły nas pozostałe Core Web Vitals: nie da się go sprawdzić jednym testem i odhaczyć. Nie ma go w wyniku wydajności Lighthouse ani w danych laboratoryjnych PageSpeed Insights, bo wymaga prawdziwych kliknięć prawdziwych ludzi. Zielona tarcza w teście nie jest więc dowodem, a jej brak nie jest wyrokiem.

Diagnoza ma stałą kolejność: dane terenowe wskazują szablony, atrybucja wskazuje interakcję i odcinek czasu, dopiero potem wybiera się technikę. Naprawy z górnej części tabeli — usunięcie martwych skryptów zewnętrznych, wyeliminowanie timerów wchodzących w drogę interakcjom, odłożenie niekrytycznej logiki za pierwszą klatkę, kilka reguł content-visibility — nie wymagają przepisywania serwisu i w wielu przypadkach wystarczają.

Na koniec dwie rzeczy, o których warto pamiętać przy rozmowie z klientem. Pierwsza: efekt zobaczycie po miesiącu, nie po tygodniu, bo tak działa okno danych terenowych i walidacja poprawki. Druga: poprawa INP jest argumentem konwersyjnym, nie pozycyjnym — sam Google mówi o nagradzaniu jakości strony ostrożnie i my też powinniśmy.