Interaction to Next Paint (INP): jak mierzyć i poprawić interaktywność

Dlaczego INP ma znaczenie dla technicznego SEO w Austrii

Interaction to Next Paint (INP) mierzy, jak szybko strona reaguje na interakcje użytkownika. Kliknięcia, dotknięcia i naciśnięcia klawiszy uruchamiają proces przetwarzania, którego efektem jest kolejna widoczna klatka (paint). INP rejestruje opóźnienie przez całą wizytę na stronie, a nie tylko przy pierwszym działaniu. Od 12 marca 2024 roku INP jest stabilnym wskaźnikiem Core Web Vitals i zastępuje First Input Delay. Tym samym metryka należy do sygnałów Page Experience, które według dokumentacji Google są dopasowane do głównych systemów rankingowych.

Dla dostawców B2B w Austrii ma to podwójne znaczenie. Po pierwsze, responsywność jest czynnikiem biznesowym: analiza czterech sklepów e-commerce wykazała konsekwentnie ujemną korelację między INP a współczynnikiem konwersji, przy czym konwersje częściowo spadały już przy 100 ms, czyli w zakresie „dobrym”. Po drugie, w Austrii nieco ponad dwie na pięć wizyt pochodzą z urządzeń mobilnych: według StatCounter ruch dzieli się na 57,6% desktop i 42,4% urządzenia mobilne (maj 2026). Przy 8,69 mln użytkowników internetu i penetracji na poziomie 95,3% (październik 2025) to wydajność mobilna decyduje o znacznej części widoczności.

Ta przeszkoda jest realna. Według DebugBear w skali międzynarodowej na urządzeniach mobilnych tylko 64,9% stron przechodziło test INP, a w przypadku CLS było to 76,9%. Jedynie LCP, z wynikiem 54,9%, był jeszcze trudniejszy do zaliczenia. Wartości te opierają się na danych CrUX z listopada 2023 roku. Za 2024 rok Web Almanac podaje 74% stron mobilnych z dobrym INP, ale 97% na desktopie. Różnica między urządzeniami pozostaje duża.

Jak działa INP: trzy fazy i kluczowa różnica w porównaniu z FID

INP dzieli każdą interakcję na trzy fazy. Input Delay: czas, zanim główny wątek się zwolni i będzie mógł wykonać funkcję obsługi zdarzenia. Wątek zablokowany przez JavaScript wydłuża tę fazę. Processing Time: wykonanie samych funkcji obsługi zdarzeń, czyli Twojej logiki biznesowej, aktualizacji frameworka i obliczeń. Presentation Delay: czas, zanim przeglądarka wyrenderuje wynik i narysuje kolejną klatkę.

Kluczowa różnica w porównaniu z First Input Delay tkwi w zakresie pomiaru. FID rejestrował tylko opóźnienie przy pierwszym działaniu użytkownika i pomijał czas przetwarzania oraz prezentacji. INP uwzględnia wszystkie interakcje w ramach wyświetlenia strony i raportuje (w uproszczeniu) najwyższą istotną wartość. Strona mogła więc mieć idealny FID, a mimo to wykazywać słaby INP, bo późniejsze interakcje, takie jak otwarcie menu, filtrowanie listy czy wysłanie formularza, są wolne. Próg: co najmniej 75% wyświetleń strony powinno osiągać INP nieprzekraczający 200 milisekund.

Główną przyczyną słabych wyników jest przeciążony główny wątek. Długie zadania go blokują i opóźniają każdą nową interakcję. Za długie zadania uznaje się zadania trwające ponad 50 ms. Dane są jednoznaczne: według mediany strona mobilna spędza 2366 ms w długich zadaniach, wobec zaledwie 329 ms na desktopie, a liczba długich zadań wynosi 14 zamiast 3. Total Blocking Time, popularny laboratoryjny wskaźnik zastępczy dla INP, ma na urządzeniach mobilnych medianę 1208 ms wobec 67 ms na desktopie, czyli około 18 razy wyższą.

Pomiar INP: dane terenowe wygrywają z danymi laboratoryjnymi

Aby postawić wiarygodną diagnozę, musisz oddzielić dane terenowe od laboratoryjnych.

Dane terenowe (rozstrzygające): pochodzą od prawdziwych użytkowników. Chrome User Experience Report (CrUX) zasila PageSpeed Insights i Search Console. Do ciągłego monitorowania integrujesz bibliotekę JavaScript web-vitals lub rozwiązanie Real User Monitoring (RUM). Tylko dane terenowe odzwierciedlają rzeczywiste urządzenia, jakość sieci i wzorce interakcji. Właśnie tutaj widać słabość urządzeń mobilnych wynikającą z ich realnej mocy obliczeniowej i jakości sieci.

Dane laboratoryjne (diagnostyczne): Lighthouse i Chrome DevTools dostarczają powtarzalnych wyników w kontrolowanym środowisku. Samego INP nie da się zmierzyć bezpośrednio w laboratorium, bo wymaga on interakcji rozłożonych w czasie. Zamiast tego jako wskaźnik zastępczy służy Total Blocking Time: pokazuje, jak mocno główny wątek jest blokowany podczas ładowania. Dane laboratoryjne nadają się do debugowania i testów regresji w pipelinie CI, ale nigdy nie zastąpią oceny w warunkach rzeczywistych.

Wniosek: nie optymalizuj na ślepo pod wynik Lighthouse. Ustalaj priorytety według percentyli. O wartości INP decyduje wolny koniec rozkładu, czyli wszystko od 75. percentyla w górę. Interakcja, która przy większości wyświetleń jest szybka, ale w jednej trzeciej przypadków trwa 600 ms, to Twój właściwy problem.

Dobre praktyki: odciążenie głównego wątku i przyspieszenie interakcji

Najskuteczniejsze dźwignie zmniejszają ilość pracy JavaScriptu albo rozkładają ją w czasie.

Dzielenie długich zadań: rozbijaj pracę na mniejsze części i oddawaj kontrolę głównemu wątkowi, zanim przekroczysz 50 ms. scheduler.yield() oddaje kontrolę po bieżącej pracy i wznawia ją z priorytetem. scheduler.postTask() pozwala ustawiać jawne priorytety. setTimeout służy jako szerzej obsługiwane rozwiązanie awaryjne. Google odradza już korzystanie z isInputPending(), bo to API może przeoczyć interakcje. Lepiej regularnie oddawać kontrolę, niezależnie od tego, czy jakaś interakcja czeka.

Zmniejszenie obciążenia JavaScriptem: według mediany na urządzenia mobilne trafia 558 KB JavaScriptu, z czego około 206 KB pozostaje nieużywane, czyli 44%. Code splitting, tree shaking i usuwanie martwego kodu działają bezpośrednio na Input Delay i Processing Time. Ładuj tylko to, czego potrzebuje dana strona, i odkładaj logikę niekrytyczną na później.

Optymalizacja funkcji obsługi zdarzeń: ograniczaj częstotliwość obsługi częstych zdarzeń. Debouncing dla danych wejściowych i throttling dla funkcji obsługi przewijania (scroll) lub zmiany rozmiaru (resize) zapobiegają niepotrzebnej pracy. Studium przypadku redBus dokładnie to potwierdza: dzięki debouncingowi funkcji obsługi przewijania i lokalnemu zarządzaniu stanem z opóźnioną synchronizacją Redux INP strony wyszukiwania spadł o 72%, a przychód wzrósł o 7%. Unikaj kosztownych ponownych renderów, używaj requestAnimationFrame do aktualizacji wizualnych, stosuj CSS zamiast JavaScriptu do animacji i odciążaj renderowanie za pomocą content-visibility.

Okiełznanie skryptów zewnętrznych i skryptów zgód: skrypty śledzące, menedżery tagów i skrypty zgód często działają w głównym wątku i blokują go dokładnie wtedy, gdy użytkownik chce wejść w interakcję. Ładuj je z opóźnieniem, po pierwszej interakcji lub w Web Workerze. Sprawdź, które skrypty są naprawdę krytyczne.

Architektura Next.js zapewniająca niskie wartości INP

W Next.js duża część obciążenia wpływającego na INP pochodzi z hydracji: przeglądarka musi „ożywić” wyrenderowany po stronie serwera HTML za pomocą JavaScriptu klienta, co obciąża główny wątek.

React Server Components: komponenty bez interaktywności renderują się po stronie serwera i nie wysyłają JavaScriptu do klienta. To zmniejsza bundle, a tym samym koszty hydracji u źródła. Efekt jest udokumentowany w praktyce: serwis Economic Times obniżył Total Blocking Time z 3260 ms do 120 ms, a INP z około 1000 ms do 257 ms, m.in. dzięki migracji do Next.js. Rezultat: o 50% mniej odrzuceń i o 43% więcej odsłon.

Streaming i Suspense: dzięki <Suspense> streamujesz fragmenty strony, gdy tylko są gotowe, zamiast czekać na całość. Skraca to czas, po którym widoczne obszary stają się interaktywne.

Selektywna hydracja i dynamiczne importy: oznaczaj jako komponenty klienckie ("use client") tylko interaktywne wyspy. Ciężkie komponenty klienckie ładuj przez next/dynamic, najlepiej dopiero wtedy, gdy są potrzebne. W ten sposób unikasz dużych bundli klienckich, które wcześnie blokują główny wątek.

Najczęstsze błędy przy optymalizacji INP

Patrzenie wyłącznie na wynik Lighthouse: zielony wynik laboratoryjny nie gwarantuje dobrego INP w danych terenowych. Dane laboratoryjne nie znają prawdziwych interakcji rozłożonych w czasie. Bez danych terenowych i analizy percentyli optymalizujesz obok problemu.

Ignorowanie najwolniejszego przypadku: kto patrzy na średnie, przeoczy 75. percentyl. A właśnie tam mierzy się INP. Celowo identyfikuj najwolniejszą interakcję.

Pozostawienie skryptów zgód i skryptów śledzących bez zmian: skrypty banerów pojawiają się wcześnie i często blokują właśnie pierwszą interakcję. Bez opóźnionego ładowania lub przeniesienia ich poza główny wątek efekt pozostaje widoczny, zwłaszcza w realnych warunkach urządzeń mobilnych.

Ten sam budżet dla urządzeń mobilnych i desktopu: urządzenia mobilne mają mniejszą moc obliczeniową. Przy medianie TBT 1208 ms na urządzeniach mobilnych wobec 67 ms na desktopie wersja mobilna potrzebuje bardziej rygorystycznego budżetu JavaScriptu. Bundle akceptowalny na desktopie może na urządzeniach mobilnych mocno przekroczyć próg.

Niekontrolowane gromadzenie JavaScriptu: jeśli 44% przesyłanego JavaScriptu pozostaje nieużywane, to martwy balast. Regularnie sprawdzaj pokrycie kodu i usuwaj nieużywany kod.

Metryki, debugowanie i priorytetyzacja w praktyce

Do precyzyjnego debugowania są dziś dostępne dokładne narzędzia.

API Long Animation Frames (LoAF): dostarcza szczegółowych danych o długich klatkach, łącznie ze skryptami, które je spowodowały, i źródłem blokady. Dzięki temu ustalasz nie tylko, że klatka była długa, ale też, który kod ją wywołał.

Panel Performance w Chrome DevTools: pokazuje ścieżkę interakcji z Input Delay, Processing Time i Presentation Delay. Widzisz w ten sposób, która z trzech faz dominuje, i odpowiednio dobierasz działanie: Input Delay wskazuje na blokady głównego wątku, długi Processing Time na kosztowne funkcje obsługi zdarzeń, a wysoki Presentation Delay na koszty renderowania lub layoutu.

Atrybucja najwolniejszej interakcji: za pomocą biblioteki web-vitals w trybie atrybucji lub rozwiązania RUM rejestrujesz dla każdego wyświetlenia strony najgorszą interakcję wraz z kontekstem. Ustalaj priorytety według częstotliwości i wagi przy 75. percentylu.

Wyznaczanie wartości docelowych dla Austrii: przyjmij 200 ms jako twardą górną granicę, ale zaplanuj zapas, ponieważ według SpeedCurve konwersje czasem cierpią już przy 100 ms. Zdefiniuj osobne budżety dla urządzeń mobilnych i desktopu. Ponieważ według StatCounter w maju 2026 roku w Austrii 42,4% ruchu pochodziło z urządzeń mobilnych, a urządzenia mobilne znacznie częściej przekraczają próg mimo 99,5% szerokopasmowych połączeń komórkowych (3G/4G/5G), budżet mobilny powinien być Twoim głównym wskaźnikiem sterującym.

Dalsze informacje: INP, crawlery AI i zgody RODO

INP nie działa w izolacji. W Generative Engine Optimization (GEO) liczy się przede wszystkim dostarczana treść, którą pobierają crawlery AI. Lekka architektura renderowana po stronie serwera pomaga w równym stopniu crawlerom i użytkownikom: Server Components ograniczają JavaScript po stronie klienta i dostarczają treść bezpośrednio w początkowym HTML. Crawlery pobierają ją wtedy bardziej niezawodnie, a użytkownicy są szybciej obsługiwani.

Zgoda RODO to najczęściej przeoczany obszar. Platformy do zarządzania zgodami ładują się wcześnie, renderują nakładki, a po wyrażeniu zgody uruchamiają kaskadę skryptów zewnętrznych, które wszystkie obciążają główny wątek. Trzy działania pomagają, nie narażając zgodności z prawem: ładuj skrypty śledzące dopiero po udzieleniu zgody i z opóźnieniem. Przenoś nieistotne skrypty na serwer lub do Web Workera. Dbaj też o to, by sam skrypt zgód był jak najlżejszy, bo z definicji pojawia się przed pierwszą interakcją. Dzięki temu główny wątek pozostaje wolny, gdy użytkownik zamyka baner, a to właśnie ta pierwsza interakcja trafia do INP.