Interaction to Next Paint (INP) dla SEO

TL;DR — INP mierzy, jak szybko Twoja strona reaguje, gdy ktoś kliknie, dotknie lub wpisze tekst. Przeglądarka mierzy czas między interakcją a następną aktualizacją wizualną, w trakcie całej wizyty, i raportuje w przybliżeniu najgorszy wynik. Poniżej 200 ms jest dobrze; powyżej 500 ms jest źle. To jedna z trzech podstawowych wskaźników internetowych (Core Web Vitals) i w 2024 roku zastąpiła starszy wskaźnik o nazwie First Input Delay.

Co dokładnie mierzy INP

Kiedy klikniesz przycisk, dotkniesz menu lub wpiszesz tekst w polu, oczekujesz, że strona zareaguje — menu się otworzy, pole wyboru zostanie zaznaczone, tekst się pojawi. Interaction to Next Paint (INP) mierzy, ile to trwa: czas od interakcji do momentu, gdy przeglądarka namaluje następną klatkę pokazującą zmianę.

Oto najważniejsza część. INP nie patrzy tylko na jedną interakcję. Obserwuje każde kliknięcie, dotknięcie i naciśnięcie klawisza podczas całej wizyty, a następnie raportuje (w przybliżeniu) najwolniejszą z nich. Więc pojedyncza zacinająca się interakcja — pole wyszukiwania, które zamraża na pół sekundy przy każdym wpisaniu znaku — może zepsuć cały wynik.

Przewijanie, najeżdżanie kursorem i powiększanie nie są liczone. Mierzone są tylko kliknięcia, dotknięcia i interakcje klawiaturowe.

Progi

INP jest raportowany w milisekundach, a Google dzieli go na trzy kategorie:

• Dobry — 200 ms lub mniej
• Wymaga poprawy — więcej niż 200 ms, do 500 ms
• Słaby — więcej niż 500 ms

Dla kontekstu: 200 ms to szybko, ale to niewiele zapasu. Wszystko, co Twój kod robi w odpowiedzi na kliknięcie — plus rysowanie wyniku przez przeglądarkę — musi się w tym zmieścić.

Dlaczego zastąpił FID

Stary wskaźnik responsywności to First Input Delay (FID). FID mierzył tylko opóźnienie przed rozpoczęciem obsługi pierwszej interakcji na stronie — i kończył pomiar w momencie rozpoczęcia pracy. Nie liczył, ile czasu faktycznie zajęła ta praca ani ile czasu zajęło zaktualizowanie ekranu.

INP naprawił to wszystko. Mierzy pełny czas (od początku do aktualizacji wizualnej) dla wszystkich interakcji, nie tylko pierwszej. Google oficjalnie dokonał zmiany 12 marca 2024 roku, a FID całkowicie zniknął z narzędzi do września 2024.

Co powoduje zły INP — w prostych słowach

Prawie zawsze to JavaScript blokujący główny wątek. Przeglądarka może robić tylko jedną rzecz naraz na tym wątku, więc jeśli fragment skryptu jest zajęty wykonywaniem, Twoje kliknięcie musi czekać w kolejce. Typowi winowajcy:

• Ciężka praca wykonywana bezpośrednio w handlerze kliknięcia/dotknięcia.
• Duże „długie zadania” JavaScriptu blokujące wszystko.
• Skrypty stron trzecich — analityka, banery zgody na pliki cookie, widgety czatu, menedżery tagów. To jedni z najgorszych winowajców, nawet na prostych stronach z treścią.

Naprawa, ogólnie rzecz biorąc, polega na robieniu mniej pracy podczas interakcji i dzieleniu dużych zadań na małe części, aby przeglądarka mogła wcisnąć Twoją interakcję między nimi.

Chcesz poznać prawdziwe mechanizmy — trójczęściowy podział opóźnienia, matematykę 75. percentyla, dokładnie jak naprawić każdą przyczynę i aspekt SEO? Przełącz się na zakładkę Zaawansowane.

TL;DR — INP to podstawowy wskaźnik internetowy (Core Web Vital) dla responsywności. Obserwuje opóźnienie wszystkich interakcji kliknięcia, dotknięcia i klawiatury podczas wizyty i raportuje wartość na 75. percentylu (jeden odstający wynik pomijany na 50 interakcji) — nie tylko pierwsze wejście, jak robił to FID. Opóźnienie interakcji = opóźnienie wejścia + czas przetwarzania + opóźnienie prezentacji. Dobry ≤ 200 ms, słaby > 500 ms, oceniane na podstawie danych terenowych na p75. Zastąpił FID 12 marca 2024 roku (FID całkowicie usunięty z narzędzi we wrześniu 2024). Napraw to, dzieląc długie zadania, ustępując głównemu wątkowi za pomocą scheduler.yield(), robiąc mniej w handlerach zdarzeń, zmniejszając DOM i odraczając skrypty stron trzecich. To metryka terenowa — Total Blocking Time to laboratoryjny odpowiednik, a te dwie wartości nie zawsze się zgadzają.

Co mierzy INP — i czym różni się od FID

Definicja Google jest precyzyjna: INP „ocenia ogólną responsywność strony na interakcje użytkownika, obserwując opóźnienia wszystkich kliknięć, dotknięć i interakcji klawiaturowych, które występują przez cały czas trwania wizyty użytkownika na stronie.”

To sformułowanie „wszystkie interakcje… przez cały czas trwania wizyty” mówi wszystko. INP jest metryką na poziomie wizyty, a nie czasu ładowania — a rozumowanie Google jest takie, że zdecydowana większość czasu spędzonego przez użytkownika na stronie ma miejsce po jej załadowaniu, więc responsywność podczas użytkowania ma większe znaczenie niż samo pierwsze wrażenie.

Kontrast z First Input Delay to najczystszy sposób na zrozumienie tego: „FID mierzył tylko opóźnienie wejścia pierwszej interakcji na stronie. INP ulepsza FID, obserwując wszystkie interakcje na stronie, od opóźnienia wejścia, do czasu wykonania procedur obsługi zdarzeń.” FID mierzył jedną rzecz dotyczącą jednej interakcji — czas oczekiwania przed uruchomieniem jej procedury obsługi — i ignorował zarówno czas działania procedury, jak i czas potrzebny na zaktualizowanie ekranu. INP mierzy pełne opóźnienie każdej interakcji.

Jeden niuans, który warto dobrze zrozumieć, bo to powszechny mit: INP nie jest dosłownie najgorszą interakcją. Aby nie karać strony za pojedynczy losowy skok, przeglądarka odrzuca jedną wartość odstającą na każde 50 interakcji, a następnie raportuje wartość na 75. percentylu wyświetleń strony. Przy wizycie z małą liczbą interakcji trafia to na najwolniejszą interakcję; przy intensywnej wizycie kilka wartości odstających jest najpierw wykluczanych.

To, co liczy się jako interakcja, jest również węższe, niż ludzie zakładają. Mierzone są tylko kliknięcia, dotknięcia i naciśnięcia klawiszy. Przewijanie, najeżdżanie kursorem i powiększanie są wyraźnie wykluczone. A pojedynczy gest może wywołać kilka zdarzeń — dotknięcie generuje pointerdown, pointerup i click — które INP grupuje jako jedną interakcję, a nie trzy. W ramach tej grupy INP bierze najdłuższy czas trwania pojedynczego zdarzenia, a nie sumę wszystkich — więc szybki pointerdown obok wolnego click nadal raportuje się jako jedna interakcja o rozmiarze określonym przez wolne zdarzenie. Jeśli strona nie ma kwalifikujących się interakcji podczas wizyty, INP po prostu nie jest dla niej raportowany.

Trzy części opóźnienia interakcji

Opóźnienie każdej interakcji dzieli się na trzy sekwencyjne części. To model, który warto mieć w głowie, ponieważ każda część wskazuje na inną poprawkę:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Opóźnienie wejścia — czas przed rozpoczęciem działania procedur obsługi zdarzeń, zwykle dlatego, że główny wątek jest zajęty kończeniem długiego zadania.
2. Czas przetwarzania — czas potrzebny na wykonanie wszystkich wywołań zwrotnych procedur obsługi zdarzeń.
3. Opóźnienie prezentacji — czas od zakończenia procedur obsługi do namalowania przez przeglądarkę następnej klatki na ekranie.

Wersja z atrybucją web-vitals udostępnia wszystkie trzy wartości (inputDelay, processingDuration, presentationDelay), dzięki czemu możesz zobaczyć, która część dominuje w rzeczywistej interakcji. Według danych Web Almanac z 2024 r., opóźnienie prezentacji jest często największą pojedynczą częścią przy medianie — ale to czas przetwarzania zwykle daje największe możliwości optymalizacji, ponieważ to ta część rośnie na źle zbudowanych stronach.

Progi — i uwaga dotycząca pola p75

Google Search Central jasno określa cel — “an INP of less than 200 milliseconds” (tłumaczenie) „INP mniejsze niż 200 milisekund” — i przedstawia cały program jako: “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (tłumaczenie) „Zdecydowanie zalecamy właścicielom witryn osiągnięcie dobrych wyników Core Web Vitals dla sukcesu w wyszukiwarce”. Budżet 200 ms jest naprawdę napięty, gdy pamiętasz, że przeglądarka chce klatki co ~16,7 ms przy 60 fps; cała praca procedur obsługi plus renderowanie musi się w tym zmieścić.

Dlaczego INP jest metryką polową (a dane laboratoryjne nie wystarczą)

To jest pułapka, w którą wpada wielu SEO: zielony wynik Lighthouse nie oznacza dobrego INP. Ale stwierdzenie „Lighthouse nie może zmierzyć INP” wymaga trzech osobnych przypadków, a nie jednego, inaczej źle odczytasz własne narzędzia:

1. Standardowe, nieinteraktywne uruchomienie Lighthouse w ogóle nie raportuje INP. Obserwuje tylko ładowanie strony — nigdy nie klika, nie dotyka ani nie wpisuje niczego — więc nie ma interakcji do zmierzenia. Lighthouse używa w zamian Total Blocking Time (TBT) jako proxy czasu ładowania. Ujęcie Google: “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (tłumaczenie) „Ponieważ TBT dobrze koreluje z INP, strona z wysokim TBT jest rozsądnym wskaźnikiem, że mogą występować wysokie wartości INP podczas ładowania.” Kluczowe słowa to “during load.” (tłumaczenie) „podczas ładowania.” TBT nie mówi nic o interakcji, która psuje się dziesięć sekund później, gdy uruchomi się leniwie ładowany widget — to proxy, nigdy substytut ani wzór do przeliczania.
2. Ręcznie lub syntetycznie wykonana interakcja — kliknięcie prawdziwego przycisku w DevTools lub skryptowanie kliknięcia w narzędziu laboratoryjnym — faktycznie daje rzeczywistą wartość opóźnienia w stylu INP dla tej jednej interakcji. To przydatne do odtworzenia konkretnego błędu. Ale to wciąż jedna ścieżka skryptowa na jednym urządzeniu: nie może zastąpić mieszanki prawdziwych urządzeń, prawdziwych użytkowników, prawdziwych celów interakcji i pełnego czasu życia strony z danych terenowych. Jak ujmuje to Google, wynikowa wartość “will be dependent on what interactions are performed during the measurement period,” (tłumaczenie) „będzie zależeć od tego, jakie interakcje są wykonywane w okresie pomiaru,” a prawdziwe zachowanie użytkowników jest zbyt zmienne, aby pojedyncze uruchomienie laboratoryjne mogło je reprezentować.
3. Rozkład danych terenowych to jedyna rzecz, którą INP faktycznie jest. Dlatego autorytatywnym źródłem są dane terenowe: raport Chrome User Experience Report (CrUX), prezentowany przez PageSpeed Insights i raport Core Web Vitals w Search Console. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (tłumaczenie) „Dane terenowe to najlepsze źródło informacji, na którym możesz polegać, jeśli chodzi o zrozumienie, które interakcje są problematyczne dla prawdziwych użytkowników.”

Użyj laboratorium (przypadki 1 i 2), aby znaleźć i odtworzyć wolną interakcję; użyj danych terenowych (przypadek 3), aby potwierdzić, czy faktycznie obniża wyniki prawdziwych odwiedzających.

Dlaczego Twój wynik INP jest słaby

Prawie każdy problem z INP sprowadza się do zablokowania głównego wątku, gdy użytkownik interaguje. Typowi podejrzani:

• Długie zadania. Każde zadanie na głównym wątku trwające ponad 50 ms jest długim zadaniem; ilość ponad 50 ms to jego „okres blokowania”. Gdy jedno działa, Twoja interakcja nie może być obsłużona. To najczęstsza przyczyna.
• Ciężkie procedury obsługi zdarzeń. Robienie zbyt wiele synchronicznie w procedurze obsługi kliknięcia/wejścia bezpośrednio zwiększa czas przetwarzania.
• Duży rozmiar DOM. Większe DOM-y kosztują więcej przy renderowaniu, co zwiększa zarówno opóźnienie wejścia, jak i prezentacji.
• Skrypty stron trzecich. Według Web Almanac, dostawcy zgód, menedżery tagów, analityka i widgety czatu to główni winowajcy — i dotykają nawet prostych stron z treścią. To pierwsze miejsce, na które patrzę na stronie, której nie zbudowałem.
• JavaScript po załadowaniu. To, że strona się wyrenderowała, nie oznacza, że skończyła się ładować — skrypty uruchamiane po pierwszym malowaniu mogą blokować wczesne interakcje.

Jak to naprawić

Strategie, mniej więcej w kolejności wpływu:

1. Dziel długie zadania. Główna rada Google dotycząca procedur obsługi to “do as little work as possible in them.” (tłumaczenie) „rób w nich jak najmniej pracy.” Podziel duże zadanie na mniejsze, aby przeglądarka mogła wpleść interakcję użytkownika. Gdy zadania są podzielone, “the browser can respond to higher-priority work much sooner — including user interactions.” (tłumaczenie) „przeglądarka może reagować na pracę o wyższym priorytecie znacznie szybciej — w tym na interakcje użytkownika.”

2. Ustąp głównemu wątkowi. Nowoczesny, zalecany sposób to scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() wstrzymuje Twój kod, pozwala przeglądarce obsłużyć oczekujące zadania i wznawia z priorytetem — więc inne zadania nie przeskoczą Twojej kontynuacji. Klasycznym rozwiązaniem awaryjnym jest setTimeout(..., 0), które nadal działa, ale wysyła Twój kod na koniec kolejki zadań (a przeglądarki wymuszają minimalny czas 5 ms po kilku zagnieżdżonych wywołaniach). Jedna rzecz, którą należy przestać robić: isInputPending() — Google mówi teraz “we no longer recommend using this API.” (tłumaczenie) „nie zalecamy już korzystania z tego interfejsu API”. Zobacz kartę Scripts, aby poznać wzorzec.

3. Rób mniej w procedurach obsługi zdarzeń — odraczaj mniej krytyczną pracę. Wykonuj tylko aktualizację wizualną, którą następna klatka potrzebuje synchronicznie; wszystko inne (zapisywanie, sprawdzanie pisowni, analityka, liczenie słów) przesuń za requestAnimationFrame + setTimeout lub yield. Użytkownik widzi odpowiedź natychmiast; księgowość dzieje się później.

4. Unikaj thrashowania układu. Czytanie właściwości układu zaraz po zapisaniu stylów w tym samym zadaniu zmusza przeglądarkę do synchronicznego układu, który mogła pogrupować. Najpierw czytaj, potem zapisuj.

5. Zmniejsz rozmiar DOM. Mniejsze drzewa renderują się szybciej. content-visibility może leniwie renderować elementy poza ekranem, aby nie kosztowały Cię podczas ładowania lub interakcji.

6. Audytuj i odraczaj skrypty stron trzecich. To najskuteczniejsza poprawka SEO na prawdziwych stronach. Ładuj skrypty zgody/tagów/analityki leniwie, ograniczaj je do interakcji lub przenieś poza ścieżkę krytyczną. “Lekka” strona z treścią może nie zdać INP wyłącznie z powodu ciężkiego osadzonego widgetu.

Czy INP wpływa na rankingi?

Tak — INP jest jednym z trzech podstawowych wskaźników internetowych (Core Web Vitals), a Core Web Vitals są częścią sygnałów doświadczenia strony Google. Ale to lekki sygnał: rozstrzygający między porównywalnie istotnymi wynikami, a nie główny czynnik rankingowy. Nie goń za idealnym wynikiem INP kosztem treści i trafności.

Dwie praktyczne uwagi SEO. Po pierwsze, mobile to twarda liczba. W Web Almanac 2024, ~74% witryn mobilnych zdało INP w porównaniu z ~97% na desktopie — a ponieważ Google indeksuje mobile-first, liczba mobilna jest tą, która się liczy. Po drugie, złożone witryny radzą sobie gorzej: tylko ~53% z 1000 najlepszych witryn zdało, ponieważ strony bogate w funkcje dostarczają więcej JavaScriptu, który blokuje główny wątek. Ciężki rozwój funkcji to ryzyko INP, a strony o wysokiej interakcji — strony produktów, kasy, wyniki wyszukiwania, formularze — są znacznie bardziej narażone niż statyczne treści.

INP vs FID — pełny obraz

FID zniknął — usunięty z Search Console w dniu premiery INP i z CrUX BigQuery/API do września 2024. Jeśli narzędzie lub audyt nadal odwołuje się do FID, jest nieaktualne.

Przypadki brzegowe, które powodują rozbieżności w danych INP

Kilka osobliwości cyklu życia wyjaśnia większość pytań “dlaczego mój RUM nie zgadza się z CrUX”:

• Brak interakcji, brak INP. Jeśli wizyta nie obejmuje kliknięcia, dotknięcia ani naciśnięcia klawisza — lub obejmuje tylko wykluczone gesty, takie jak przewijanie i najeżdżanie — nie ma wartości INP dla tego wyświetlenia strony. To normalne na stronach tylko do odczytu i nie jest błędem w Twoim monitorowaniu.
• Iframe’y wliczają się do metryki, ale Twój własny JavaScript nie widzi ich wnętrza. Interakcja w osadzonym iframe (reklama, widget, osadzony formularz) przyczynia się do INP strony. Ale skrypt RUM pierwszej strony nie może czytać zdarzeń z iframe’a innego pochodzenia tak, jak robi to natywna metryka przeglądarki — więc CrUX i konfiguracja RUM tego samego pochodzenia mogą zasadnie się różnić na stronach z osadzeniami innych firm. Udokumentuj tę lukę, zamiast traktować niezgodność RUM/pole jako błąd.
• Przywrócenie z pamięci podręcznej wstecz/wprzód resetuje INP do zera. Strona pobrana z bfcache (na przykład przycisk wstecz) rozpoczyna nowe zliczanie INP — interakcje sprzed nawigacji nie są przenoszone.
• Długo żyjące i działające w tle karty nadal muszą raportować. Ponieważ karta może pozostać otwarta przez godziny bez formalnego zwolnienia — zwłaszcza na urządzeniach mobilnych, gdzie system operacyjny może ją po prostu zabić — INP powinno być przechwytywane, gdy strona staje się ukryta, a nie tylko przy zwolnieniu. Konfiguracje RUM, które wysyłają dane tylko przy unload, po cichu stracą dane z tych wizyt.

Gdzie to się znajduje

INP to jeden z elementów obrazu Core Web Vitals, obok Largest Contentful Paint (ładowanie) i Cumulative Layout Shift (stabilność wizualna). Sprawdź go w PageSpeed Insights i raporcie Search Console (pole), a debuguj w Lighthouse / Chrome DevTools (laboratorium, przez proxy TBT). Dane za tym wszystkim pochodzą z CrUX.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• INP = Core Web Vital dla responsywności. Obserwuje opóźnienie wszystkich kliknięć, dotknięć i interakcji klawiaturowych podczas całej wizyty i raportuje wartość na 75. percentylu (jeden odstający pomiar odrzucany na 50 interakcji) — nie tylko pierwsze wejście, jak robiło to FID.
• Opóźnienie = opóźnienie wejścia + czas przetwarzania + opóźnienie prezentacji. Każda część wskazuje na inną poprawkę; czas przetwarzania zwykle daje największe możliwości.
• Progi (pole, p75): dobry ≤ 200 ms, wymaga poprawy ≤ 500 ms, słaby

  500 ms.

• Liczą się tylko kliknięcia, dotknięcia i klawiatura — przewijanie, najeżdżanie i powiększanie są wykluczone; wiele zdarzeń jednego gestu jest grupowanych jako jedna interakcja.
• Zastąpiło FID 12 marca 2024 r. (FID całkowicie usunięte z narzędzi we wrześniu 2024 r.). FID mierzyło tylko opóźnienie wejścia pierwszej interakcji.
• To metryka polowa, a „Lighthouse nie może jej zmierzyć” ma trzy przypadki: standardowe nieinteraktywne uruchomienie Lighthouse nie raportuje INP i używa Total Blocking Time jako proxy czasu ładowania; ręcznie wykonana interakcja laboratoryjna daje rzeczywiste opóźnienie pojedynczej interakcji, ale nie zastępuje populacji polowej; tylko dane polowe CrUX / PageSpeed Insights / Search Console są autorytatywne.
• Przyczyny: długie zadania (>50 ms), ciężkie procedury obsługi zdarzeń, duży DOM, a zwłaszcza skrypty innych firm (zgody, menedżery tagów, analityka, czat).
• Poprawki: rozbijaj długie zadania, ustępuj za pomocą scheduler.yield() (fallback setTimeout; isInputPending() nie jest już zalecane), rób mniej w procedurach obsługi, unikaj thrashingu układu, zmniejsz DOM, odraczaj skrypty innych firm.
• Przypadki brzegowe: brak kwalifikującej interakcji oznacza brak wartości INP; interakcje w iframe wliczają się do metryki, ale skrypt RUM tego samego pochodzenia nie widzi ich wnętrza; przywrócenia bfcache resetują INP; długo żyjące/karty w tle powinny raportować przy ukryciu, nie tylko przy zwolnieniu.
• SEO: lekki sygnał rankingowy. Mobile (~74% przechodzi vs ~97% desktop) to liczba, która ma znaczenie w indeksowaniu mobile-first; strony z dużą liczbą interakcji są najbardziej narażone.

Oficjalna dokumentacja

Dokumentacja źródłowa od Google / zespołu Chrome.

web.dev — referencje INP

• Interakcja do następnego renderowania (INP) — definitywna definicja: co mierzy, trójczęściowy podział opóźnienia, typy interakcji i progi.
• Optymalizacja Interaction to Next Paint — podręcznik optymalizacji: robienie mniej w handlerach, odkładanie niekrytycznej pracy, thrashing layoutu, rozmiar DOM, content-visibility.
• Interaction to Next Paint oficjalnie staje się Core Web Vital — post z 12 marca 2024 (Jeremy Wagner i Rick Viscomi); harmonogram wycofania FID.
• First Input Delay (FID) — wycofana metryka; co mierzyła i dlaczego została zastąpiona.
• Nowa metryka responsywności: podziel się opinią — ograniczenia projektowe FID i ulepszenia INP.
• Optymalizacja długich zadań — definicja długiego zadania 50 ms, scheduler.yield(), fallback setTimeout i dlaczego isInputPending() nie jest już zalecane.
• Ocena skryptów i długie zadania — TBT jako proxy INP i wskazówki dotyczące rozmiaru skryptów.
• Znajdowanie wolnych interakcji w danych terenowych — build atrybucji web-vitals i API Long Animation Frames (LoAF).

Chrome / Google Search

• Performance features reference (Chrome DevTools) — ścieżka Interactions, Live Metrics i ostrzeżenie 200 ms.
• CrUX release notes — potwierdza usunięcie FID z BigQuery/API we wrześniu 2024.
• Core Web Vitals & Google Search results — INP jako część sygnału page-experience; cel ≤ 200 ms.

Cytaty ze źródła

Oświadczenia na piśmie od Google / zespołu Chrome. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Co mierzy INP i czym różni się od FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (tłumaczenie) „INP to metryka Core Web Vitals, która ocenia ogólną responsywność strony na interakcje użytkownika, obserwując opóźnienie wszystkich kliknięć, dotknięć i interakcji klawiatury, które występują w trakcie wizyty użytkownika na stronie.” — web.dev, Interaction to Next Paint (INP). Przejdź do cytatu
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (tłumaczenie) „FID mierzyło tylko opóźnienie wejścia pierwszej interakcji na stronie. INP ulepsza FID, obserwując wszystkie interakcje na stronie, od opóźnienia wejścia do czasu wykonania handlerów zdarzeń.” Przejdź do cytatu
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (tłumaczenie) „First Input Delay (FID) nie jest już Core Web Vital i zostało zastąpione metryką Interaction to Next Paint (INP).” — web.dev, First Input Delay (FID). Przejdź do cytatu

Przejście z FID na INP

• “FID will be deprecated.” (tłumaczenie) „FID zostanie wycofane.” — Jeremy Wagner i Rick Viscomi, blog web.dev, Interaction to Next Paint officially becomes a Core Web Vital. Przejdź do cytatu
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (tłumaczenie) „FID zostanie usunięte z Google Search Console, gdy tylko INP stanie się Core Web Vital 12 marca.” Przejdź do cytatu

Długie zadania — główna przyczyna

• “Any task that takes longer than 50 milliseconds is a long task.” (tłumaczenie) „Każde zadanie, które trwa dłużej niż 50 milisekund, jest długim zadaniem.” — web.dev, Optimize long tasks. Przejdź do cytatu

Dane terenowe są podstawą

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (tłumaczenie) „Dane terenowe są najlepszym źródłem informacji, na którym można się oprzeć, jeśli chodzi o zrozumienie, które interakcje są problematyczne dla rzeczywistych użytkowników.” — web.dev, Znajdowanie wolnych interakcji w danych terenowych. Przejdź do cytatu

Google Search

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (tłumaczenie) „Zdecydowanie zalecamy właścicielom witryn osiągnięcie dobrych wyników Core Web Vitals, aby odnieść sukces w wyszukiwarce.” — Google Search Central, Core Web Vitals i wyniki wyszukiwania. Źródło

Lista kontrolna naprawy INP

Pracuj od góry do dołu — pozycje znajdujące się na górze zwykle najbardziej zmieniają liczbę:

• Pobierz polowy INP (PageSpeed Insights / raport CWV w Search Console), a nie tylko wynik laboratoryjny — i sprawdź osobno wersję mobilną.
• Zidentyfikuj wolne interakcje za pomocą wersji z atrybucją web-vitals lub ścieżki Interactions w Chrome DevTools (oznacza wszystko powyżej 200 ms).
• Znajdź i rozbij długie zadania (wszystko powyżej 50 ms w wątku głównym).
• Oddawaj sterowanie do wątku głównego wewnątrz długo działających pętli — scheduler.yield(), z fallbackiem setTimeout(..., 0). (Przestań używać isInputPending().)
• Wewnątrz każdego handlera wykonuj tylko krytyczną dla renderowania aktualizację synchronicznie; odraczaj zapisywanie, walidację, sprawdzanie pisowni, analitykę za rAF + setTimeout.
• Sprawdź thrashing układu — czytanie układu zaraz po zapisaniu stylów w tym samym zadaniu. Grupuj odczyty, potem zapisy.
• Przeprowadź audyt skryptów stron trzecich (zgody, menedżer tagów, analityka, czat). Odraczaj, ładuj leniwie lub uzależniaj je od interakcji — zwykle to największa pojedyncza wygrana.
• Zmniejsz rozmiar DOM; zastosuj content-visibility do sekcji poza ekranem.
• Odraczaj / dziel na części niekrytyczny JS, aby skrypty po załadowaniu nie blokowały wczesnych interakcji.
• Zmierz ponownie w terenie po wdrożeniu — CrUX to ruchome okno 28-dniowe, więc wynik zmienia się powoli.

INP vs FID — ściąga

Szybkie fakty

• Progi (pole, p75): Dobry ≤ 200 ms · Wymaga poprawy ≤ 500 ms · Słaby > 500 ms.
• Liczone: kliknięcia, dotknięcia, klawiatura. Wykluczone: przewijanie, najechanie, powiększanie.
• Opóźnienie = opóźnienie wejścia + czas przetwarzania + opóźnienie prezentacji.
• Długie zadanie = każde zadanie w wątku głównym > 50 ms.
• Zastępstwo laboratoryjne: Total Blocking Time — koreluje, ale odzwierciedla tylko blokowanie w czasie ładowania. Autorytatywnym źródłem są dane terenowe (CrUX).
• Wskaźnik zdawalności na mobile (~74 %) jest znacznie niższy niż na desktopie (~97 %) — a mobile się liczy.

Oddawaj sterowanie do wątku głównego

Gdy masz długo działającą pętlę (renderowanie dużej listy, przetwarzanie danych po kliknięciu), okresowo oddawaj kontrolę przeglądarce, aby mogła obsłużyć oczekującą interakcję użytkownika. Nowoczesne API to scheduler.yield(); w miejscach, gdzie nie jest obsługiwane, użyj fallbacku setTimeout.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Kilka uwag:

• scheduler.yield() zwraca obietnicę, która rozwiązuje się w przyszłym zadaniu, a jej kontynuacja jest priorytetyzowana — inne zakolejkowane zadania nie wyprzedzą Twojego wznowionego kodu.
• setTimeout(..., 0) działa wszędzie, ale przesuwa Twoją kontynuację na koniec kolejki (a przeglądarki egzekwują ~5 ms minimum po kilku zagnieżdżonych wywołaniach).
• Nie sięgaj po isInputPending() — Google “no longer recommend[s] using this API.”

Odraczaj niekrytyczną pracę w handlerze

Uruchamiaj tylko to, czego potrzebuje następna klatka; resztę odsuń za paint.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Narzędzia do pomiaru i naprawy INP

Pole (autorytatywne — to jest to, co Google ocenia)

• PageSpeed Insights — CrUX field INP dla URL/originy, podzielone na mobile i desktop, plus labowy przebieg diagnostyczny.
• Search Console — raport Core Web Vitals — status INP dla Twoich URL-i, pogrupowany według problemu, na danych polowych.
• CrUX — bazowy zbiór danych Chrome User Experience Report (dostępny również przez CrUX API / BigQuery).

Lab / debugowanie

• Chrome DevTools — panel Performance — ścieżka Interactions mierzy czas opóźnienia wejścia, przetwarzania i prezentacji dla każdej interakcji oraz flaguje wszystko powyżej 200 ms; Live Metrics aktualizuje się podczas klikania.
• Lighthouse — nie może zmierzyć INP bezpośrednio; raportuje Total Blocking Time jako labowy proxy.

Monitorowanie rzeczywistych użytkowników (RUM)

• Biblioteka JS web-vitals — onINP() dla wartości; wersja z atrybucją (web-vitals/attribution) udostępnia inputDelay / processingDuration / presentationDelay, selektor interactionTarget oraz wpisy LoAF, dzięki czemu możesz dokładnie zobaczyć, który skrypt i element spowodował wolną interakcję. Niezależnie od konfiguracji RUM, udokumentuj jego współczynnik próbkowania i pokrycie atrybucji — wartość RUM cytowana bez tego kontekstu nie jest porównywalna z polowym p75 CrUX i nie widzi wewnątrz iframe z innych originów tak, jak zagregowany wskaźnik (patrz Edge cases, w zakładce Advanced).

Jak same narzędzia są oceniane

Żywy przykład metryki opisanej na tej stronie — znane usługi pomiaru szybkości stron i monitorowania uszeregowane według ich własnego rzeczywistego INP na urządzeniach mobilnych (dane polowe Chrome UX Report):

Poprawki INP, które zwykle nie trafiają w sedno

Optymalizowanie tylko pierwszej interakcji

INP ocenia interakcje w trakcie całej wizyty, nie tylko pierwsze wejście. Ćwicz menu, wyszukiwanie, filtry, formularze i inne powtarzalne elementy sterujące, zanim uznasz stronę za responsywną.

Traktowanie Total Blocking Time jako wyniku

TBT jest użytecznym labowym proxy, ponieważ ujawnia długie zadania na głównym wątku, ale nie jest polowym INP. Użyj go do znalezienia kandydatów, a następnie zweryfikuj rzeczywiste interakcje danymi polowymi lub śladem interakcji.

Przenoszenie całej pracy do jednego opóźnionego wywołania zwrotnego

Odroczenie dużego bloku może po prostu przesunąć zamrożenie. Podziel pracę na mniejsze zadania i ustępuj, aby przeglądarka mogła malować między nimi.

Usuwanie wizualnego sprzężenia zwrotnego w celu skrócenia handlera

Element sterujący, który wykonuje pracę bez pokazywania odpowiedzi, nadal wydaje się zepsuty. Najpierw wyrenderuj natychmiastową zmianę stanu, a następnie odrocz niekrytyczną pracę uzupełniającą.

Diagnozuj INP za pomocą trójczęściowego modelu opóźnień

Każda wolna interakcja ma trzy miejsca do sprawdzenia:

1. Opóźnienie wejścia: zdarzenie czekało, ponieważ wcześniejsza praca na głównym wątku wciąż trwała. Audytuj długie zadania i JavaScript stron trzecich przed rozpoczęciem handlera.
2. Czas przetwarzania: sam handler zdarzenia robił zbyt wiele. Zmniejsz pracę synchroniczną, podziel pętle i odrocz wszystko, czego następna klatka nie potrzebuje.
3. Opóźnienie prezentacji: styl, układ lub malowanie trwały zbyt długo po handlerze. Zmniejsz złożoność DOM i unikaj wymuszania wielokrotnych obliczeń układu.

Zacznij od największej fazy w śladzie. Nagraj ponownie tę samą interakcję po każdej zmianie, aby szybszy handler nie ukrył nowego wąskiego gardła prezentacji.

Udowodnij, że zmiana INP poprawiła interakcję

Test ustępowania handlera

Test do wykonania: zarejestruj docelową interakcję w panelu Performance przed i po podziale lub odroczeniu długiego zadania. Oczekiwany wynik: czas przetwarzania interakcji skraca się lub jest dzielony przez malowanie. Interpretacja błędu: kosztowna praca znajduje się gdzie indziej lub nadal jest wykonywana synchronicznie. Okno monitorowania: natychmiastowe w powtarzanych śladach. Wyzwalacz wycofania: kontrolka aktualizuje się w złej kolejności, traci stan lub generuje nowe błędy wejściowe.

Test prezentacji

Test do wykonania: sprawdź w tym samym śladzie pracę stylów, układu i malowania po obsłudze zdarzenia. Oczekiwany wynik: następne malowanie pojawia się szybciej bez większego zadania układu. Interpretacja błędu: rozmiar DOM lub wymuszony układ pozostaje wąskim gardłem. Okno monitorowania: natychmiastowe w śladach laboratoryjnych. Wyzwalacz wycofania: odpowiedź wizualna staje się niekompletna lub niestabilna.

Potwierdzenie w terenie

Test do wykonania: porównaj atrybucję onINP() po wydaniu dla zmienionej interakcji i szablonu z jej wartością bazową. Oczekiwany wynik: p75 INP poprawia się, a docelowy element przestaje dominować w wolnych zdarzeniach. Interpretacja błędu: przypadek laboratoryjny nie odzwierciedlał rzeczywistych urządzeń lub ścieżek użytkownika. Okno monitorowania: RUM w miarę pojawiania się wizyt; CrUX w swoim ruchomym oknie 28-dniowym. Wyzwalacz wycofania: responsywność lub ukończenie interakcji pogarsza się konsekwentnie po wdrożeniu.

Metryki INP, które warto śledzić

Rzeczywisty INP użytkowników na poziomie p75

Metryka: 75. percentyl INP według szablonu i klasy urządzenia. Co ci mówi: czy typowe rzeczywiste wizyty są responsywne na całej swojej ścieżce. Jak ją pobrać: CrUX, PageSpeed Insights lub RUM web-vitals. Punkt odniesienia / realistyczny zakres: 200 ms lub mniej jest dobre; powyżej 500 ms jest słabe. Częstotliwość: monitoruj po wydaniach JavaScript i przeglądaj miesięcznie trend pola ruchomego.

Wskaźnik wolnych interakcji

Metryka: udział zmierzonych interakcji powyżej 200 ms, pogrupowanych według celu. Co ci mówi: które kontrolki powodują największe widoczne opóźnienie, nawet gdy p75 na poziomie strony przechodzi. Jak ją pobrać: wersja atrybucyjna web-vitals lub dane Event Timing w RUM. Punkt odniesienia / realistyczny zakres: ustal bazę dla każdej ścieżki i zmniejsz najczęstsze problemy. Częstotliwość: co tydzień dla szablonów przypominających aplikacje.

Udział faz opóźnienia

Metryka: opóźnienie wejścia, czas przetwarzania i opóźnienie prezentacji dla wolnych interakcji. Co ci mówi: czy planowanie, kod obsługi czy renderowanie jest głównym ograniczeniem. Jak ją pobrać: ślady DevTools i atrybucja INP. Punkt odniesienia / realistyczny zakres: nie ma uniwersalnego podziału, który byłby zdrowy; porównaj każdą fazę z jej własną bazą i całkowitym progiem 200 ms jako dobrym. Częstotliwość: podczas każdego ukierunkowanego badania wydajności.

Zasoby warte Twojego czasu

Google / Chrome (kanon)

• Interaction to Next Paint (INP) — zacznij tutaj.
• Optimize Interaction to Next Paint — poprawki.
• Optimize long tasks — odraczanie, scheduler.yield().
• Find slow interactions in the field — debugowanie LoAF + atrybucja.
• INP becomes a Core Web Vital — premiera 12 marca 2024 r.

Dane

• Web Almanac 2024 — Performance — rzeczywiste liczby wskaźnika zdawalności INP i mediany podczęści.

Z branży

• INP — MDN Web Docs — wpis referencyjny MDN; dobry do weryfikacji wsparcia przeglądarek i definicji metryki poza dokumentacją Google.
• Scheduler API: scheduler.yield() — MDN — tabela wsparcia przeglądarek i szczegóły specyfikacji dla głównego prymitywu yield.
• PerformanceEventTiming — MDN — bazowe API przeglądarki, z którego korzysta INP; przydatne przy analizie surowych danych o czasie zdarzeń.
• Long Animation Frames API — Chrome Platform Status — śledzenie wsparcia LoAF w przeglądarkach, API zasilające atrybucję INP w bibliotece web-vitals.
• Temat INP — Search Engine Land — branżowe relacje o aktualizacjach INP, wynikach testów i przejściu z FID na INP od praktyków.

Statystyki, które warto cytować

• ~74 % mobile vs ~97 % desktop spełnia INP (2024). Mobile jest znacznie trudniejsze — a ponieważ Google indeksuje w trybie mobile-first, to ta liczba ma znaczenie dla SEO. Web Almanac 2024
• Tylko ~53 % z 1 000 największych witryn spełnia INP — witryny bogate w funkcje dostarczają więcej JavaScriptu, który blokuje główny wątek, więc największe witryny często radzą sobie gorzej. Web Almanac 2024
• Długie zadanie = > 50 ms. Wszystko powyżej 50 ms w głównym wątku blokuje przeglądarce reagowanie na interakcje — to bezpośredni mechanizm stojący za słabym INP. web.dev — Optymalizacja długich zadań
• Mediany podskładników (2024): opóźnienie prezentacji ~36 ms jest często największym pojedynczym składnikiem w medianie, a opóźnienie wejścia i czas przetwarzania są tuż za nim na p75 — przydatne do określenia, którą trzecią część atakować. Web Almanac 2024

Filmy

• Google Chrome Developers (YouTube) — wyjaśnienia Core Web Vitals i INP od zespołu Chrome, w tym przewodniki po diagnozowaniu wolnych interakcji w DevTools. Kanał

Sprawdź się: Interaction to Next Paint

Pięć szybkich pytań o responsywność i diagnozowanie INP. Wybierz odpowiedź na każde, a potem sprawdź.

Dziennik zmian