INP Core Web Vitals — metryka responsywności, która zastąpiła FID

Definicja: INP (Interaction to Next Paint) to metryka Core Web Vitals mierząca ogólną responsywność strony przez obserwację czasu odpowiedzi na wszystkie interakcje użytkownika — kliknięcia, tapnięcia i naciśnięcia klawiszy — od momentu interakcji do chwili, gdy przeglądarka prezentuje następną klatkę wizualną. Składa się z trzech faz: (1) input delay — czas między zdarzeniem użytkownika a możliwością jego obsługi przez przeglądarkę; (2) processing duration — czas wykonywania event handlerów przypisanych do interakcji; (3) presentation delay — czas między zakończeniem handlerów a wyrenderowaniem nowej klatki wizualnej.

Ostatnia aktualizacja: 2026-02-24

Szybkie fakty

• INP zastąpiło FID jako oficjalną metrykę Core Web Vitals 12 marca 2024 roku.
• Dobry wynik INP według Google wynosi poniżej 200 ms mierzony na 75. percentylu sesji użytkowników.
• INP mierzy najdłuższą interakcję ze wszystkich zarejestrowanych w trakcie sesji, a nie tylko pierwszą jak FID.

INP (Interaction to Next Paint) to metryka Core Web Vitals aktywna od marca 2024 roku, mierząca czas od interakcji użytkownika do następnej klatki wizualnej przeglądarki. Zastąpiła FID, obejmując całą sesję — nie tylko pierwsze kliknięcie.

• Próg dobrego INP: poniżej 200 ms — strona reaguje niezwłocznie na wszystkie interakcje
• Trzy składowe: input delay + processing duration + presentation delay
• Główne przyczyny wysokiego INP: długie zadania JavaScript blokujące main thread, ciężkie event handlery, złożone przeliczenia layoutu po interakcji

Metryka INP (Interaction to Next Paint) stała się oficjalnym wskaźnikiem Core Web Vitals 12 marca 2024 roku, zastępując FID (First Input Delay). Zmiana ta objęła wszystkich właścicieli stron, których wyniki są monitorowane przez Google Search Console i raport Page Experience.

INP różni się od poprzedniczki zakresem pomiaru — zamiast rejestrować wyłącznie pierwsze kliknięcie, obserwuje wszystkie interakcje użytkownika w trakcie sesji. Dobry wynik wynosi poniżej 200 ms na 75. percentylu, co oznacza, że trzy czwarte użytkowników strony doświadcza odpowiedzi szybszej niż jedna piąta sekundy. Strony z wynikiem powyżej 500 ms są klasyfikowane jako słabe, co może mieć przełożenie na sygnał Page Experience w rankingu Google Search.

Czym jest INP i co mierzy ta metryka

INP mierzy czas, który upływa od momentu interakcji użytkownika z elementem strony do chwili, gdy przeglądarka wyświetla kolejną klatkę wizualną. Wynik INP to najdłuższa zarejestrowana interakcja z sesji — z pominięciem outlierów przy ponad 50 zdarzeniach — wyrażona w milisekundach na 75. percentylu sesji rzeczywistych użytkowników.

„Interaction to Next Paint (INP) will officially become a Core Web Vital and replace FID on March 12 of this year, and that FID will be deprecated in this transition.”¹

Ogłoszenie to potwierdziło pełną zmianę zestawu metryk Core Web Vitals i wycofanie FID z programu oceny jakości stron przez Google.

Metryka rejestruje trzy typy interakcji: kliknięcia myszą, tapnięcia na urządzeniach dotykowych oraz naciśnięcia klawiszy na klawiaturze fizycznej lub wirtualnej. Przewijanie strony i hover nie są uwzględniane — decyzja ta wynika z tego, że obie czynności mają odrębne metryki płynności i nie wiążą się bezpośrednio z responsywnością na działanie użytkownika.

Metodologia percentyla 75. oznacza, że Google ocenia doświadczenie większości użytkowników, a nie wartości skrajne — ani najlepszych, ani najgorszych sesji. Przy ponad 50 interakcjach w jednej sesji outlier (najdłuższa wartość) jest pomijany, co chroni wynik przed jednorazowymi anomaliami spowodowanymi np. tymczasowym przeciążeniem urządzenia. Podstawą techniczną pomiaru jest Event Timing API dostępne w nowoczesnych przeglądarkach, które rejestruje znaczniki czasu dla każdego zdarzenia wejściowego.

Jeśli strona rejestruje mniej interakcji niż wymagany próg CrUX, wartość INP może być niedostępna w raportach — brak danych nie oznacza dobrego wyniku, lecz niewystarczający ruch do wyliczenia statystycznie wiarygodnej wartości.

Trzy składowe INP — input delay, processing duration, presentation delay

Czas INP składa się z trzech następujących po sobie faz, których suma determinuje końcowy wynik metryki. Zrozumienie każdej z nich jest warunkiem skutecznej diagnostyki — różne przyczyny wysokiego INP wymagają odmiennych metod naprawy.

Pierwsza faza — input delay — to czas między zdarzeniem użytkownika a momentem, gdy przeglądarka może zacząć je obsługiwać. Najczęściej wynika z długich zadań JavaScript wykonywanych w tle na main thread, które blokują obsługę nowych zdarzeń. Im więcej skryptów działa równolegle w chwili kliknięcia, tym dłuższy input delay.

Druga faza — processing duration — obejmuje czas wykonywania event handlerów przypisanych do konkretnej interakcji. Długi czas w tej fazie wskazuje na zbyt ciężki kod JavaScript w obsłudze zdarzeń: synchroniczne operacje na DOM, kosztowne obliczenia lub nadmiarowe wywołania funkcji wewnątrz handlerów. Optymalizacja tej fazy polega na usunięciu zbędnych operacji z bezpośredniej ścieżki obsługi zdarzenia.

Trzecia faza — presentation delay — to czas między zakończeniem event handlerów a wyrenderowaniem nowej klatki przez przeglądarkę. Wynika najczęściej z rozbudowanych przeliczeniach layoutu (reflow) lub operacji paint po zmianie drzewa DOM. Zastosowanie właściwości CSS contain lub ograniczenie liczby elementów podlegających przeliczeniu skraca tę fazę.

Jak Chrome DevTools pokazuje składowe INP

Chrome DevTools w zakładce Performance → Insights prezentuje szczegółowy podział INP na trzy fazy dla każdej zarejestrowanej interakcji. Kliknięcie wybranej interakcji na osi czasu ujawnia długość input delay, processing duration i presentation delay osobno, co pozwala precyzyjnie zidentyfikować, która faza dominuje w danym przypadku. Biblioteka web-vitals JS udostępnia analogiczne dane programistycznie — wynik INP wraz z jego składowymi można przesyłać bezpośrednio do Google Analytics lub innego systemu monitorowania.

Identyfikację stron z podwyższonym INP umożliwia raport Core Web Vitals w GSC, który grupuje adresy URL według statusu responsywności i wskazuje, które podstrony wymagają działań.

Przy wysokim processing duration przy jednoczesnym niskim input delay najbardziej prawdopodobne jest, że problem tkwi w logice event handlerów — a nie w obciążeniu main thread przez procesy tła.

Progi INP — jak Google klasyfikuje responsywność strony

Google definiuje trzy zakresy wyników INP, które bezpośrednio przekładają się na klasyfikację strony w raporcie Core Web Vitals w Search Console. Progi te dotyczą wartości z 75. percentylu sesji rzeczywistych użytkowników, nie danych laboratoryjnych.

²„An INP below or at 200 milliseconds means a page has good responsiveness. An INP above 200 milliseconds and below or at 500 milliseconds means a page’s responsiveness needs improvement. An INP above 500 milliseconds means a page has poor responsiveness.”

Progi te stanowią oficjalne kryterium klasyfikacji responsywności stosowane przez Google w raporcie Core Web Vitals i narzędziu PageSpeed Insights.

Wartość INP może być niedostępna w Search Console przy niewystarczającym ruchu — Google wymaga minimalnego progu sesji w Chrome User Experience Report, by wyliczyć statystycznie reprezentatywny percentyl 75. Dla nowych domen lub stron o niskim ruchu brak wartości INP jest stanem normalnym, nie błędem konfiguracji.

Progi INP obowiązują globalnie dla wszystkich domen indeksowanych przez Google, niezależnie od platformy technicznej strony — zarówno dla WordPressa, jak i aplikacji opartych na frameworkach JavaScript czy statycznych generatorach stron.

Jak mierzyć INP — dane rzeczywiste i laboratoryjne

INP mierzy się wyłącznie z danych rzeczywistych użytkowników — nie można go obliczyć w warunkach laboratoryjnych, ponieważ wymaga realnych interakcji. Google Search Console i PageSpeed Insights prezentują dane field z Chrome User Experience Report (CrUX) aktualizowane co 28 dni.

Google Search Console to podstawowe narzędzie do monitorowania INP na poziomie poszczególnych URL. Raport Core Web Vitals w zakładce Doświadczenie pokazuje, które podstrony uzyskały status dobry, wymaga poprawy lub słaby, z podziałem na ruch mobilny i desktopowy. PageSpeed Insights wyświetla wartość INP z CrUX bezpośrednio dla analizowanego adresu — wystarczy wkleić URL i odczytać sekcję Field Data.

Do diagnostyki laboratoryjnej służy Chrome DevTools — zakładka Performance z panelem Insights rejestruje czas interakcji przy ręcznym klikaniu strony podczas sesji nagrywania. Wyniki lab nie trafiają do CrUX i nie wpływają na status strony w Search Console, ale pozwalają zidentyfikować konkretny fragment kodu odpowiedzialny za opóźnienie. Biblioteka JavaScript web-vitals umożliwia pomiar INP w czasie rzeczywistym bezpośrednio w kodzie strony z wysyłką wyników do Google Analytics lub dowolnego systemu zbierania danych.

Dane field czy dane lab — które wyniki INP są wiarygodne?

Dane field pochodzące z CrUX odzwierciedlają rzeczywiste doświadczenia użytkowników strony na przestrzeni ostatnich 28 dni i są źródłem, na którym Google opiera ocenę Core Web Vitals w Search Console. Dane lab z PageSpeed Insights lub Chrome DevTools rejestrują zachowanie strony w kontrolowanym środowisku bez realnych interakcji, dlatego wynik INP w trybie lab może być niedostępny lub znacznie niższy niż w field. Kryterium wyboru źródła zależy od celu: dane field służą do oceny statusu i monitorowania trendów, a dane lab — do debugowania i identyfikacji konkretnego fragmentu kodu odpowiedzialnego za opóźnienie. Rozbieżność między tymi źródłami wynika z natury metryki — INP mierzy interakcje, których nie sposób odtworzyć w pełni w środowisku bez prawdziwego użytkownika.

Poprawa INP jest jednym z elementów szeroko rozumianej optymalizacji technicznej strony, obejmującej również szybkość ładowania zasobów, strukturę kodu JS i konfigurację serwera.

Dane field z CrUX pozwalają odróżnić problem systemowy (wysoki INP na większości podstron) od problemu lokalnego (wysoki INP na konkretnym szablonie lub typie strony) bez ryzyka błędnej diagnozy opartej wyłącznie na danych lab.

Główne przyczyny wysokiego INP i metody naprawy

Wysoki INP najczęściej wynika z zadań JavaScript blokujących main thread podczas obsługi interakcji użytkownika. Diagnostyka powinna zaczynać się od identyfikacji fazy — input delay, processing duration lub presentation delay — bo każda wymaga innego podejścia technicznego.

Długie zadania JavaScript (long tasks) to najczęstszy powód wysokiego input delay. Gdy main thread jest zajęty wykonywaniem skryptu trwającego ponad 50 ms, nowe zdarzenia czekają w kolejce — użytkownik klika, ale strona nie reaguje. Rozwiązaniem jest rozbicie long tasks na mniejsze jednostki z zastosowaniem strategii yielding: scheduler.yield() lub setTimeout z wartością 0 ms pozwalają oddać kontrolę przeglądarce między fragmentami kodu.

Ciężkie event handlery generują wysoki processing duration. Synchroniczne operacje na DOM, złożone przeliczenia danych lub nadmiarowe wywołania funkcji wewnątrz handlera bezpośrednio wydłużają tę fazę. Przeniesienie logiki niezwiązanej z bezpośrednią odpowiedzią wizualną poza synchroniczny przepływ zdarzenia — np. do Web Worker lub asynchronicznego callbacku — skraca processing duration bez zmiany funkcjonalności.

Kosztowne operacje reflow i repaint powodują wysoki presentation delay. Każda zmiana właściwości CSS lub struktury DOM, która wymusza przeliczenie layoutu przez przeglądarkę, wydłuża czas do wyrenderowania następnej klatki. Zastosowanie właściwości contain: layout lub content-visibility ogranicza zakres elementów podlegających przeliczeniu. Skrypty stron trzecich — czaty, reklamy, widgety analityczne — mogą blokować main thread niezależnie od własnego kodu strony; lazy loading i wzorzec facade odkładają ich inicjalizację do momentu, gdy nie koliduje z interakcjami użytkownika.

Optymalizacja INP wpisuje się w szerszy system Core Web Vitals wskaźniki witryny, obejmujący równolegle LCP i CLS jako mierniki ładowania i stabilności wizualnej.

Optymalizacja INP jest procesem iteracyjnym — po każdej zmianie technicznej wyniki field w CrUX aktualizują się z opóźnieniem około 28 dni, dlatego dane lab z Chrome DevTools służą jako bieżący wskaźnik postępu między kolejnymi odczytami z Search Console.

Pytania i odpowiedzi

Czym jest INP i co mierzy ta metryka?

INP (Interaction to Next Paint) mierzy ogólną responsywność strony przez obserwację czasu odpowiedzi na wszystkie kliknięcia, tapnięcia i naciśnięcia klawiszy w trakcie sesji. Wartość INP to najdłuższa zarejestrowana interakcja wyrażona w milisekundach na 75. percentylu sesji rzeczywistych użytkowników — z pominięciem outlierów przy ponad 50 zdarzeniach.

Jaki jest dobry wynik INP według Google?

INP poniżej 200 ms oznacza dobrą responsywność strony. Wartość między 200 ms a 500 ms sygnalizuje potrzebę poprawy. INP powyżej 500 ms oznacza słabą responsywność, która wpływa negatywnie na odbiór strony przez użytkowników i obniża sygnał Page Experience w rankingu Google.

Dlaczego Google zastąpiło FID metryką INP?

FID mierzył wyłącznie opóźnienie pierwszej interakcji na stronie, co dawało niepełny obraz rzeczywistego doświadczenia użytkownika. INP obserwuje wszystkie interakcje w trakcie całej sesji, uwzględniając zarówno kliknięcia nawigacyjne, jak i interakcje z formularzami czy elementami interaktywnymi. Zmiana weszła w życie 12 marca 2024 roku, a FID zostało oficjalnie wycofane z programu Core Web Vitals.

Jakie typy interakcji są mierzone przez INP?

INP uwzględnia trzy typy interakcji: kliknięcia myszą, tapnięcia na urządzeniach dotykowych oraz naciśnięcia klawiszy na klawiaturze fizycznej lub wirtualnej. Przewijanie strony i hover nie są uwzględniane w obliczaniu INP — te czynności mają odrębne wskaźniki płynności i nie należą do kategorii responsywności na działanie użytkownika.

Jak INP wpływa na pozycje w Google Search?

INP jest jedną z trzech metryk Core Web Vitals, które Google uwzględnia jako sygnał Page Experience w rankingu organicznym. Strony z dobrym INP (poniżej 200 ms) spełniają próg jakości doświadczenia użytkownika, co wspiera ich widoczność w wynikach wyszukiwania. Słaby INP (powyżej 500 ms) oznacza niespełnienie kryterium Page Experience, jednak wpływ na ranking jest jednym z wielu sygnałów i nie determinuje pozycji samodzielnie.

Jak zmierzyć INP strony?

INP mierzy się z danych rzeczywistych użytkowników (field data) poprzez raport Core Web Vitals w Google Search Console lub PageSpeed Insights oparty na danych CrUX. Do pomiarów laboratoryjnych służy Chrome DevTools (zakładka Performance → Insights) oraz biblioteka JavaScript web-vitals, która pozwala rejestrować INP bezpośrednio w kodzie strony i przesyłać wyniki do systemu analitycznego.

Podsumowanie

• INP zastąpiło FID 12 marca 2024 roku i mierzy responsywność strony przez całą sesję użytkownika — nie tylko przy pierwszym kliknięciu.
• Próg dobrego INP wynosi poniżej 200 ms na 75. percentylu — powyżej 500 ms wynik jest uznawany za słaby i negatywnie wpływa na sygnał Page Experience.
• Trzy składowe INP (input delay, processing duration, presentation delay) wymagają osobnej diagnostyki — każda ma inne przyczyny i inne metody naprawy.
• Głównym narzędziem do monitorowania INP są dane field z Google Search Console i CrUX — wyniki lab z PageSpeed Insights mogą odbiegać od rzeczywistości ze względu na brak realnych interakcji.

Źródła

• Google Search Central — Core Web Vitals and Google Search Results
• Chrome for Developers — INP Breakdown: Diagnosing Responsiveness Issues
• Google Search Central Blog — Introducing INP to Core Web Vitals

1. web.dev Blog — INP becomes a Core Web Vital on March 12 (2024) ↩︎
2. web.dev — Interaction to Next Paint (INP) ↩︎