Dobry wynik INP to 200 milisekund lub mniej, mierzone dla 75. percentyla prawdziwych wizyt. Między 200 a 500 ms strona “wymaga poprawy”, a powyżej 500 ms jest oceniana jako słaba. Google stosuje te progi osobno dla urządzeń mobilnych i komputerów, więc strona może przejść test na jednych i nie przejść na drugich.
Interaction to Next Paint (INP) mierzy, jak szybko strona reaguje wizualnie po kliknięciu, dotknięciu lub naciśnięciu klawisza. 12 marca 2024 roku stał się wskaźnikiem Core Web Vitals, zastępując First Input Delay (FID), który mierzył tylko opóźnienie przed obsłużeniem pierwszej interakcji. INP analizuje interakcje w całej wizycie i raportuje jedną z najwolniejszych.
W praktyce “dobry” oznacza trzy rzeczy: co najmniej 75% prawdziwych wizyt dostaje odpowiedź w ciągu 200 ms, mierzysz danymi z terenu, a nie jednym testem laboratoryjnym, i masz zapas poniżej progu, aby nowy skrypt lub intensywny tydzień wyprzedaży nie zepchnął Cię powyżej.
Ten poradnik wyjaśnia, jak obliczany jest wynik, gdzie go znaleźć, dlaczego niektóre narzędzia nic nie pokazują i jak zdiagnozować oraz poprawić wolny INP bez zgadywania.
Jakie są progi INP?
Google stosuje trzy przedziały, a wartości graniczne mają znaczenie. Poniższa tabela odzwierciedla dokumentację INP na web.dev i raport Podstawowe wskaźniki internetowe w Search Console.
| Ocena | Wartość INP | Co to oznacza dla użytkowników |
|---|---|---|
| Dobry | 200 ms lub mniej | Kliknięcia i dotknięcia działają natychmiast w większości wizyt |
| Wymaga poprawy | Powyżej 200 ms, do 500 ms | Zauważalne opóźnienie w menu, filtrach, formularzach lub przy dodawaniu do koszyka |
| Słaby | Powyżej 500 ms | Użytkownicy klikają ponownie, myślą, że strona nie działa, albo wychodzą |
Czy dokładnie 200 ms to dobry wynik? Tak. web.dev definiuje dobry wynik jako “poniżej lub równo” 200 ms, więc 200 przechodzi, a 201 już nie. Ta sama logika dotyczy 500 ms: dokładnie 500 to wciąż “wymaga poprawy”, a wszystko powyżej to wynik słaby.
Dla porównania, pozostałe dwa wskaźniki Core Web Vitals w Search Console mają progi LCP 2,5 s i 4 s oraz progi CLS 0,1 i 0,25. INP jako jedyny jest mierzony w milisekundach responsywności, a nie wczytywania czy stabilności wizualnej.
Jak właściwie obliczany jest wynik INP?
INP jest najpierw obliczany dla każdej wizyty, a potem podsumowywany dla wszystkich wizyt na poziomie 75. percentyla. Zrozumienie obu kroków wyjaśnia większość nieporozumień wokół tej liczby.
Podczas jednej wizyty przeglądarka mierzy czas każdego kliknięcia, dotknięcia i naciśnięcia klawisza. Każda interakcja ma trzy części:
- Opóźnienie wejścia (input delay): czas oczekiwania, zanim uruchomią się Twoje funkcje obsługi zdarzeń, zwykle dlatego, że wątek główny jest zajęty inną pracą.
- Czas przetwarzania (processing duration): czas wykonywania funkcji obsługi zdarzeń.
- Opóźnienie prezentacji (presentation delay): czas od zakończenia obsługi zdarzeń do narysowania przez przeglądarkę kolejnej klatki.
INP wizyty to najdłuższa z tych interakcji, z jednym wyjątkiem dla bardzo aktywnych stron: web.dev podaje, że na każde 50 interakcji pomijana jest jedna najwyższa, więc pojedynczy przypadkowy skok w długiej sesji nie przesądza o wyniku. Najechanie kursorem, przewijanie i powiększanie nie są liczone jako interakcje.
Następnie wartości ze wszystkich wizyt są łączone i raportowany jest 75. percentyl. To “zasada 75%”: strona ma dobry wynik, jeśli co najmniej trzy na cztery wizyty miały INP na poziomie 200 ms lub mniej. Pozostała ćwiartka może być wolniejsza bez oblania testu, dlatego poprawa typowej najwolniejszej interakcji jest ważniejsza niż gonienie za rzadkim przypadkiem brzegowym.
Wizyta, w której użytkownik niczego nie klika, nie dotyka ani nie wpisuje, w ogóle nie daje wartości INP. Strony, które ludzie głównie czytają, np. długie artykuły, często mają mniej danych INP niż strony, z których aktywnie korzystają, np. filtry kategorii lub checkout.
Czy dobry wynik INP różni się na urządzeniach mobilnych i komputerach?
Próg jest ten sam, 200 ms, ale wyniki są bardzo różne. Telefony mają wolniejsze procesory, więc ten sam kod wykonuje się dłużej, a Google raportuje urządzenia mobilne i komputery osobno zarówno w PageSpeed Insights, jak i w Search Console.
Rozdział o wydajności w Web Almanac 2024 od HTTP Archive wykazał, że dobry INP miało 74% stron mobilnych i 97% stron na komputerach. Innymi słowy, INP to głównie problem mobilny. Jeśli raport dla komputerów jest zielony, a dla urządzeń mobilnych żółty, to normalny wzorzec, a nie błąd pomiaru.
Priorytetem powinno być urządzenie, które przynosi ruch i przychody. Na większości stron konsumenckich są to urządzenia mobilne, co oznacza też testowanie na średniej klasy telefonie z Androidem lub z ograniczeniem CPU w Chrome DevTools, a nie na szybkim laptopie. Nasz poradnik mobile SEO omawia szerszy obraz.
Gdzie sprawdzić swój wynik INP?
Korzystaj z danych z terenu, aby wiedzieć, czy przechodzisz test, i z narzędzi laboratoryjnych, aby ustalić, dlaczego nie. Każde narzędzie odpowiada na inne pytanie.
| Narzędzie | Typ danych | Najlepsze do |
|---|---|---|
| Search Console, raport Podstawowe wskaźniki internetowe | Dane z terenu (CrUX), pogrupowane adresy URL | Sprawdzania, które grupy stron nie przechodzą testu na urządzeniach mobilnych lub komputerach, i weryfikacji poprawek |
| PageSpeed Insights | Dane z terenu (CrUX, ostatnie 28 dni) plus test laboratoryjny Lighthouse | Szybkiego sprawdzenia jednego adresu URL lub całej domeny |
| CrUX API, BigQuery lub CrUX Vis | Dane z terenu (CrUX) | Trendów w czasie i porównań z konkurencją |
| Monitorowanie prawdziwych użytkowników (RUM), np. biblioteka web-vitals | Dane z terenu, Twoi własni użytkownicy | Ustalenia, który element i która interakcja spowodowały wolny INP |
| Panel Performance w Chrome DevTools | Laboratoryjne | Nagrania interakcji i sprawdzenia, które zadanie ją zablokowało |
| Lighthouse (tryb nawigacji) | Laboratoryjne | Total Blocking Time jako przybliżenie; nie mierzy INP w teście wczytywania strony |
Dokumentacja Google jasno określa hierarchię: dane z terenu od prawdziwych użytkowników to najlepszy sposób pomiaru INP. Total Blocking Time może sugerować problemy, ale web.dev opisuje go jako rozsądne przybliżenie, “a nie zamiennik INP”. Idealny wynik w Lighthouse nie oznacza, że przechodzisz test INP.
Dlaczego PageSpeed Insights nie pokazuje wyniku INP dla niektórych stron?
Zwykle dlatego, że dla danego adresu URL brakuje wystarczającej ilości danych od prawdziwych użytkowników. PageSpeed Insights pobiera dane z terenu z Chrome UX Report (CrUX), który obejmuje tylko strony publicznie dostępne i mające wystarczająco wielu odwiedzających. Google nie publikuje dokładnego progu ruchu.
Gdy pojedynczy adres URL nie ma danych, PageSpeed Insights próbuje użyć danych dla całej domeny (origin). Jeśli domena również nie ma danych, sekcja danych z terenu pokazuje “Brak danych” i zostają tylko wyniki laboratoryjne Lighthouse. Inne częste przyczyny:
- Strona jest nowa, więc nie zebrała jeszcze 28 dni wizyt
- Strona jest za logowaniem lub zablokowana przed indeksowaniem, więc CrUX jej nie obejmuje
- Odwiedzający rzadko wchodzą w interakcję ze stroną, więc próbek INP jest mało nawet przy dobrym ruchu
Praktycznym rozwiązaniem jest własny RUM. Funkcja onINP z biblioteki web-vitals raportuje INP z każdej wizyty, a jej wersja z atrybucją pokazuje, jakiego elementu dotyczyła interakcja i ile trwała każda z trzech faz. Daje to dane dla stron o małym ruchu i, co ważniejsze, kontekst do debugowania.
Jak ustalić, co spowalnia INP?
Najpierw zdiagnozuj fazę, potem przyczynę. Każda faza wskazuje inny rodzaj poprawki.
| Wolna faza | Typowa przyczyna | Gdzie szukać |
|---|---|---|
| Opóźnienie wejścia | Wątek główny zajęty innymi skryptami: menedżery tagów, widgety czatu, testy A/B, ciężka hydratacja podczas wczytywania | Długie zadania w DevTools w okolicach momentu kliknięcia |
| Czas przetwarzania | Funkcja obsługi zdarzenia robi za dużo: filtruje dużą listę produktów, wywołuje analitykę, synchronicznie zapisuje dane, ponownie renderuje całe komponenty | Obsługa zdarzenia click lub keydown w panelu Performance |
| Opóźnienie prezentacji | Duży DOM, kosztowne przeliczanie stylów i układu, renderowanie dużych fragmentów HTML skryptami | Wpisy “Recalculate Style” i “Layout” po obsłudze zdarzenia |
Prosty proces:
- W Search Console znajdź grupy adresów URL z “problemem INP” na urządzeniach mobilnych.
- Otwórz jeden przykładowy adres i ustal interakcje, które ludzie faktycznie wykonują: menu, filtr, wybór rozmiaru, dodanie do koszyka, pole formularza.
- W Chrome DevTools ustaw ograniczenie CPU, rozpocznij nagrywanie w panelu Performance, wykonaj interakcję i zatrzymaj nagrywanie.
- Szukaj długich zadań, które web.dev definiuje jako zadania trwające ponad 50 ms, i zanotuj, z którego skryptu pochodzą.
- Powtórz interakcję, gdy strona wciąż się wczytuje. Wątek główny jest wtedy często najbardziej obciążony, a właśnie wtedy klikają prawdziwi użytkownicy.
Jak poprawić słaby wynik INP?
Wykonuj mniej pracy w wątku głównym w momencie interakcji i daj przeglądarce szansę na wcześniejsze narysowanie klatki. Poniższe poprawki są ułożone mniej więcej od najprostszych do najbardziej technicznych.
Najpierw zrób audyt skryptów zewnętrznych
Na wielu stronach marketingowych największym obciążeniem dla INP nie jest Twój kod. Widgety czatu, mapy cieplne, narzędzia do zgód, widgety opinii i kilka tagów analitycznych konkurują o wątek główny. Spisz każdy skrypt w menedżerze tagów, usuń to, czego nikt nie używa, a mniej istotne tagi opóźnij do momentu wczytania strony lub pierwszej interakcji.
Najpierw pokaż reakcję, potem zrób resztę
Natychmiast zaktualizuj interfejs (otwórz menu, pokaż spinner, oznacz przycisk jako naciśnięty), a wolniejszą pracę wykonaj w osobnym zadaniu. Nazywa się to oddawaniem kontroli wątkowi głównemu (yielding). Mała funkcja pomocnicza, jak ta poniżej, używa scheduler.yield() tam, gdzie przeglądarka to obsługuje, a w pozostałych przypadkach wraca do setTimeout:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Według web.dev scheduler.yield() jest obsługiwane w Chrome i Edge od wersji 129 oraz w Firefoksie od wersji 142, ale nie w Safari, dlatego rozwiązanie zapasowe ma znaczenie.
Dziel długie zadania
Każde zadanie dłuższe niż 50 ms blokuje reakcję na działania użytkownika. Dziel długie pętle, np. przetwarzanie setek produktów, na fragmenty z oddaniem kontroli pomiędzy nimi. Poproś programistę o przegląd hydratacji we frameworkach frontendowych, która często działa jako jedno duże zadanie podczas wczytywania.
Utrzymuj odchudzony DOM
Każdy dodatkowy element spowalnia przeliczanie stylów i układu. Dziel długie listy na strony lub je wirtualizuj, usuń ukryte, zduplikowane menu dla urządzeń mobilnych i komputerów oraz użyj właściwości CSS content-visibility, aby pominąć renderowanie sekcji poza ekranem.
Unikaj wymuszonych przeliczeń układu (layout thrashing)
Odczyt wartości układu, np. wysokości elementu, zaraz po zmianie stylów zmusza przeglądarkę do natychmiastowego przeliczenia układu. W funkcjach obsługi zdarzeń grupuj odczyty przed zapisami.
Sprawdzaj ponownie po każdej zmianie
Dane z terenu zmieniają się powoli. CrUX w PageSpeed Insights obejmuje ostatnie 28 dni, a weryfikacja w Search Console trwa 28 dni. Użyj własnego RUM, aby potwierdzić poprawkę w ciągu kilku dni, a potem poczekaj, aż raporty Google nadrobią zaległości.
Czy INP wpływa na pozycje w Google?
INP jest częścią Core Web Vitals, które według Google są zgodne z tym, co nagradzają jego główne systemy rankingowe, ale nie jest skrótem na szczyt wyników. Google “zdecydowanie zaleca” dobre Core Web Vitals dla sukcesu w wyszukiwarce, ale decydujące pozostają trafność i jakość treści.
Mocniejszy argument za poprawianiem INP jest biznesowy. Wolne filtry, opóźnione przyciski dodawania do koszyka i niereagujące formularze bezpośrednio kosztują konwersje, zwłaszcza na urządzeniach mobilnych. Traktuj dobry wynik INP jako punkt wyjścia dla użytecznej strony, a większość wysiłku SEO przeznacz na treści i strukturę. Nasz poradnik SEO dla e-commerce pokazuje, gdzie wydajność mieści się wśród priorytetów sklepu.
Do czego dążyć?
Dąż do INP na poziomie 75. percentyla wyraźnie poniżej 200 ms na urządzeniach mobilnych, a nie tylko tuż pod progiem. Strona z wynikiem 190 ms przechodzi dziś, ale może nie przejść po dodaniu jednego nowego tagu marketingowego lub skoku ruchu z wolniejszych urządzeń. Zapas kilkudziesięciu milisekund daje zespołowi miejsce na nowe funkcje.
Ustalaj cele dla szablonów, a nie pojedynczych adresów URL: strony kategorii, produktów, artykuły, formularze i checkout. Najpierw popraw szablon z największym ruchem i najgorszym INP, a INP włącz do listy kontrolnej wdrożeń, aby nowe skrypty były sprawdzane przed publikacją.
Gdzie w tym wszystkim jest Marketer Coffee?
Marketer Coffee to agencja AI SEO i GEO; wydajność traktujemy jako część technicznego SEO, obok architektury, danych strukturalnych i treści. Wyniki z innych branż:
- Aldi.pl (handel detaliczny). Kliknięcia organiczne wzrosły z 367 127 do 852 724 miesięcznie w 12 miesięcy (+132%) dzięki treściom produktowym, schema Product, uproszczonej architekturze i ujednoliconym danym sklepów. Przeczytaj case study Aldi.
- IDG-Online (usługi CCTV i afiliacja). Z 500 do ponad 30 000 kliknięć miesięcznie w 16 miesięcy w konkurencji z Ceneo, MediaExpert i MediaMarkt, dzięki stronom rankingowym, treściom Q&A i schema. Przeczytaj case study IDG-Online.
Do kogo pasujemy: do witryn, w których szybkość, struktura i treści wymagają jednego planu, często sklepów lub stron międzynarodowych. Do kogo nie pasujemy: do zespołów, które potrzebują wyłącznie specjalisty od wydajności frontendu do jednorazowej przebudowy frameworka; do tego zatrudnij wyspecjalizowanego programistę. Aby zobaczyć, jak Twoja witryna radzi sobie w wyszukiwaniu AI i w Google, zacznij od naszego bezpłatnego audytu widoczności w AI.
Najczęściej zadawane pytania o wynik INP
Jaki wynik INP jest dobry?
200 milisekund lub mniej dla 75. percentyla prawdziwych wizyt, mierzone osobno dla urządzeń mobilnych i komputerów. Powyżej 200 ms i do 500 ms wynik wymaga poprawy; powyżej 500 ms jest słaby.
Kiedy INP zastąpił FID?
INP stał się wskaźnikiem Core Web Vitals 12 marca 2024 roku, zastępując First Input Delay. Tego samego dnia Search Console usunął FID.
Dlaczego mój INP jest dobry na komputerach, a słaby na urządzeniach mobilnych?
Telefony mają wolniejsze procesory, więc te same skrypty wykonują się dłużej. Web Almanac 2024 wykazał dobry INP na 97% stron na komputerach, ale tylko na 74% stron mobilnych.
Czy Lighthouse może mierzyć INP?
Standardowy test wczytywania strony w Lighthouse nie obejmuje interakcji użytkownika, więc nie może raportować INP. Pokazuje Total Blocking Time, który jest jedynie przybliżeniem. Do oceny INP używaj danych z terenu z CrUX lub własnego RUM.
Ile trwa, zanim poprawka INP będzie widoczna w Search Console?
Dane z terenu obejmują kroczące okno 28 dni, a weryfikacja w Search Console monitoruje stronę przez 28 dni, więc licz się z około czterema tygodniami, zanim raporty w pełni odzwierciedlą poprawkę. Własny RUM może ją potwierdzić wcześniej.
Wersja skrócona
Dobry INP to 200 ms lub mniej dla co najmniej 75% prawdziwych wizyt, na każdym typie urządzenia. Znajdź w Search Console szablony, które nie przechodzą testu, nagraj wolne interakcje w DevTools, ustal, która faza jest wolna, i usuń przyczynę: mniej skryptów zewnętrznych, szybsza reakcja, krótsze zadania i mniejszy DOM. Potem zostaw sobie zapas.
Jeśli chcesz drugiej opinii o tym, jakie miejsce wśród Twoich priorytetów SEO zajmuje wydajność, umów bezpłatną konsultację.
Źródła: web.dev, “Interaction to Next Paint (INP)” (progi, 75. percentyl, fazy interakcji, zasada pomijania wartości odstających, TBT jako przybliżenie); wpis na blogu web.dev autorstwa Jeremy’ego Wagnera i Ricka Viscomiego ogłaszający INP jako wskaźnik Core Web Vitals od 12 marca 2024; web.dev, “Optimize Interaction to Next Paint” i “Optimize long tasks” (długie zadania 50 ms, obsługa scheduler.yield); Pomoc Google Search Console, raport Podstawowe wskaźniki internetowe (progi, 28-dniowa weryfikacja); Google Search Central, “Understanding Core Web Vitals and Google search results”; Chrome for Developers, metodologia CrUX i CrUX w PageSpeed Insights (kwalifikowalność, okno 28 dni, dane dla domeny); HTTP Archive, Web Almanac 2024, rozdział Performance; Marketer Coffee, case studies Aldi i IDG-Online (inne branże).
