Jeśli Twoja strona internetowa otwiera się szybko, a mimo to Google pokazuje, że wynik Core Web Vitals kuleje, to pewnie wina nowej metryki – Interaction to Next Paint (INP). To właśnie INP sprawia, że użytkownik klika, a interfejs „myśli” ułamek sekundy za długo. I choć gołym okiem różnica wydaje się mała, to z punktu widzenia Google Page Experience może zadecydować o Twojej widoczności.
W uproszczeniu – INP mierzy czas od interakcji użytkownika (kliknięcia, scrolla, wpisania tekstu) do momentu, aż przeglądarka wyrenderuje kolejną wizualną zmianę. Czyli chodzi o to, czy Twoja strona jest naprawdę responsywna, czy tylko udaje. A jak go poprawić?
Głównie przez redukcję opóźnienia interakcji, mądre zarządzanie JavaScriptem i trzymanie w ryzach wydajności interfejsu. O tym wszystkim poniżej, a jeśli chcesz od razu mieć sprawę załatwioną – zerknij na projektowanie stron internetowych w dobrej cenie, bo dobrze zrobiona strona potrafi wyeliminować 90% tego typu problemów już na starcie.
- Krok 1: Zrozum czym jest Interaction to Next Paint i jak Google mierzy ten wskaźnik
- Krok 2: Sprawdź swoje wyniki INP w praktyce i odczytaj dane z realnych użytkowników
- Krok 3: Ogranicz obciążenie głównego wątku i rozbij czasochłonne operacje JavaScript
- Krok 4: Stosuj techniki programowania asynchronicznego i zadbaj o responsywność interfejsu
- Krok 5: Minimalizuj opóźnienia w interakcji poprzez optymalizację zasobów i renderowania
A jeśli chcesz, żeby Twoja strona realnie odpowiadała na każde kliknięcie jak błyskawica… to czytaj dalej.
Krok 1: Zrozum czym jest Interaction to Next Paint i jak Google mierzy ten wskaźnik
Żeby w ogóle poprawiać INP, trzeba wiedzieć, co dokładnie oznacza. Google od 2024 roku postanowiło zastąpić dotychczasowy First Input Delay (FID) nową metryką – i to nie bez powodu. Problem z FID był taki, że mierzył tylko pierwszą interakcję użytkownika, a przecież strona żyje dłużej. Dlatego do gry weszło Interaction to Next Paint (INP), które ocenia KAŻDĄ interakcję użytkownika – a wynik końcowy bazuje na najgorszym zarejestrowanym przypadku lub wartości zbliżonej do niego.
W praktyce INP mierzy pełen cykl opóźnienia wejścia: od kliknięcia, przez przetwarzanie zdarzeń wejściowych, aż po moment, gdy przeglądarka pokazuje użytkownikowi rezultat na ekranie (czyli wyrenderowanie następnej klatki). Brzmi technicznie, ale sprowadza się do pytania: „Kliknąłem — jak długo muszę czekać, aż strona odpowie?”. I właśnie ta chwila robi różnicę w satysfakcji użytkownika.
Ocenę INP Google dzieli na trzy progi:
| Wartość INP | Ocena |
|---|---|
| do 200 ms | bardzo dobra (zielona strefa) |
| 200–500 ms | średnia (żółta strefa) |
| >500 ms | słaba (czerwona strefa) |
| mierzona z realnych użytkowników | dane z RUM – Real User Monitoring |
| w testach deweloperskich | Lighthouse, Web Vitals extension |
Tak naprawdę różnica kilkuset milisekund może zdecydować, czy klient zostanie na stronie, czy stuknie w „wstecz”. Sam więc widzisz, że nie ma co tego lekceważyć. Jeśli chcesz podejrzeć, jak Twoja strona wygląda w wynikach Google pod kątem CWV – sprawdzaj dane w Google Search Console dla Core Web Vitals.
Krok 2: Sprawdź swoje wyniki INP w praktyce i odczytaj dane z realnych użytkowników
Zanim cokolwiek poprawisz, musisz sprawdzić aktualny stan rzeczy. Najgorszym błędem jest „optymalizować na ślepo”. Tutaj do gry wchodzą zarówno narzędzia deweloperskie Chrome, jak i realne dane z użytkowników (tzw. Real User Monitoring – RUM). To one pokazują prawdziwy obraz. Często w testach na własnym komputerze wynik jest świetny, a w realu – dramat.
Lighthouse i Chrome DevTools
Odpal stronę, kliknij F12, a potem zakładkę „Performance”. Tu zobaczysz, jak wygląda kolejka zadań przeglądarki i które fragmenty JavaScriptu blokują reakcję strony. W Lighthouse też znajdziesz raport o „długich zadaniach” i rekomendacje narzędziowe.
Web Vitals extension
Dla szybkiej diagnozy polecam rozszerzenie Web Vitals – od razu pokazuje wynik INP, LCP i CLS, ale pamiętaj, że to tylko test laboratoryjny. Nie zastąpi pełnej analizy.
Dane z Google Search Console
Najważniejsze są dane polowe – zbierane od faktycznych użytkowników. To one decydują o pozycji strony w wynikach. W sekcji Core Web Vitals GSC zobaczysz czy Twoje wyniki są w zielonej, żółtej czy czerwonej strefie.
Jeśli tam palą się ostrzeżenia, to musisz działać.
Tutaj rada — zawsze zestawiaj wyniki z kilku źródeł. Performance.now(), kolejka interakcji, Web Performance API – każde narzędzie mówi trochę innym językiem. A warto ogarniać pełen obraz. Sam często zaczynam od Lighthouse, a kończę na danych RUM.
Zresztą, jeśli chcesz dokładniej poznać narzędzia testowania stron, sprawdź to zestawienie narzędzi do mierzenia performance.
Krok 3: Ogranicz obciążenie głównego wątku i rozbij czasochłonne operacje JavaScript
Najczęstszy problem z INP to tzw. długie zadania JavaScript blokujące główny wątek. Jeśli kliknięcie użytkownika wpadnie do kolejki, a przeglądarka akurat mieli 2-sekundowy blok kodu, to interakcja „czeka” – i to właśnie psuje Twój wynik.
Co można zrobić? Fragmentacja kodu i Lazy loading komponentów to podstawa. Zamiast ładować całe biblioteki od razu, wczytuj je tylko wtedy, kiedy są potrzebne. Podobnie z funkcjami – jeśli jakiś event handler wykonuje kilkadziesiąt instrukcji, rozbij go na mniejsze części i wykorzystaj programowanie asynchroniczne.
Najlepiej podejść do tego iteracyjnie: w Chrome DevTools patrzysz, które zadania trwają powyżej 50 ms, a potem rozbijasz je tak, by żadne nie przekraczało tego progu. Dzięki temu strona nie zamula przy kliknięciu. Poniżej kilka przykładów dla porównania:
| Sytuacja | Problem | Rozwiązanie |
|---|---|---|
| Długa pętla for() | Blokada wątku głównego | Użyj requestIdleCallback() |
| Wielka biblioteka JS | Nieużywane funkcje | Code splitting / import on demand |
| Event listener robi za dużo | Zamrożenie UI | Podział na async taski |
| Zbyt dużo renderów w React | Niepotrzebne przebudowy | Memoization / Pure Components |
| Ciągłe zapytania AJAX | Przeładowanie CPU | Debouncing i throttling |
Wbrew pozorom to nie jest „czarna magia”. Wystarczy podejrzeć raport performance i ogarnąć największe bloki. Moja rada – zacznij od największego problemu, a nie od kosmetyki.
Jak skalp szkodliwego kodu zrobisz na starcie, wskaźnik sam podskoczy. O tym szerzej jeszcze wyjaśniam tutaj: optymalizacja serwera i kodu strony.
Krok 4: Stosuj techniki programowania asynchronicznego i zadbaj o responsywność interfejsu
Druga strona medalu to responsywność interfejsu użytkownika. Jeśli główna logika aplikacji webowej jest napisana synchronicznie, to użytkownik przy każdym kliknięciu doświadcza blokady. To dlatego Google tak mocno pcha deweloperów w stronę asynchronicznego JavaScriptu i technik jak Promise, async/await czy Web Workers.
Oddzielaj to, co krytyczne
Każdy element UI, na którym użytkownik klika, powinien być priorytetem. Tło, widgety, dodatkowe analityki – to może poczekać w kolejce. Jeśli interakcje krytyczne wykonujesz od razu, a reszta ląduje w planie późniejszym, użytkownik ma wrażenie zauważalnej responsywności.
Nieblokujące skrypty JavaScript
Kolejna rzecz to sposób wczytywania kodu: jeśli nie korzystasz z atrybutów defer i async w skryptach, to blokujesz krytyczne ścieżki renderowania. Mało kto zdaje sobie sprawę, ale zwykły zewnętrzny skrypt JS potrafi zatrzymać cały renderowanie przeglądarki.
UI testuj oczami użytkownika
Pamiętaj – klikanie na komputerze deweloperskim z i7 i 32 GB RAM to nie to samo, co realny użytkownik na średnim smartfonie. Dlatego zawsze testuj na słabszym sprzęcie i patrz na opóźnienie zdarzeń użytkownika. To prawdziwy obraz.
Na koniec – dbając o interaktywność strony myślisz nie tylko o INP, ale też o tym, jak klient czuje Twoją stronę. A to przekłada się realnie na konwersję. Warto poczytać też o tym, jak nowe standardy HTTP przyspieszają ładowanie pod kątem interakcji – opisałem to w poradniku o HTTP/2 i HTTP/3.
Krok 5: Minimalizuj opóźnienia w interakcji poprzez optymalizację zasobów i renderowania
Ostatni krok to „sprzątanie” na poziomie zasobów. Nie ma szybkiego INP, jeśli Twoja strona ładuje dziesiątki MB obrazków, skryptów i fontów.Minimalizacja opóźnień startuje już od ograniczenia zasobów blokujących renderowanie. Styl CSS? Wczytuj tylko krytyczne na start, resztę ładuj później.
Obrazy? Obowiązkowo lazy loading.
Nie lekceważ też optymalizacji fontów – zbyt wiele rodzin i wag powoduje, że stabilność wizualna potrafi wariować, a to także wpływa na odbiór interakcji. Podobnie z animacjami – one muszą działać płynnie, najlepiej w oparciu o CSS, a nie o ciężkie biblioteki JS.
Kiedy już wszystkie „ciężary” wyrzucisz z początkowego ładowania, Twoja strona zacznie reagować szybciej. Sam często zaczynam od tego miejsca i dopiero potem biorę się za kod. W końcu ile razy widziałem strony, gdzie INP przekracza sekundę nie przez JS, a przez dwa niepotrzebne fonty Google.
I jeszcze jedno – przy monitorowaniu INP korzystaj z automatycznego śledzenia interakcji. Dzięki Web Performance API możesz mierzyć wydajność w czasie rzeczywistym i na bieżąco poprawiać to, co psuje wynik. I to naprawdę robi różnicę. Po więcej praktycznych wskazówek odnośnie eliminacji nadmiarowych requestów zajrzyj tutaj: redukcja zapytań HTTP.
Twoja strona może reagować szybciej niż myślisz
Optymalizacja INP to proces, ale nie jakaś kosmiczna wiedza. To suma małych kroków – od zrozumienia, po sprawdzenie wyników i konsekwentne krojenie kodu oraz zasobów. A efekt?
Strona, która nie tylko ładnie wygląda, ale realnie działa wtedy, gdy użytkownik coś od niej chce. I dokładnie tak Google to ocenia.
A skoro jesteśmy przy stronach – uwierz, że najłatwiej jest od razu zbudować projekt zgodnie z tymi zasadami. Dlatego jeśli rozważasz nową www, zerknij co oferujemy w zakresie tworzenia stron internetowych w Białymstoku – przygotujemy stronę, która będzie działała szybko z marszu.
FAQ – najczęstsze pytania o INP
Czy INP dotyczy tylko stron mobilnych?
Nie – INP obejmuje i desktop, i mobile. Google jednak większy nacisk kładzie na urządzenia mobilne, bo stamtąd pochodzi większość ruchu.
Czy wpływ INP na SEO jest duży?
Tak, od 2024 roku to oficjalny wskaźnik w ramach Core Web Vitals, dlatego jeśli jest w czerwonym zakresie, możesz odczuć spadki widoczności.
Jak często powinienem mierzyć INP?
Najlepiej stale – dzięki integracji z RUM i narzędziami monitorującymi jak Web Performance API możesz śledzić to w czasie rzeczywistym.
Czy frameworki typu React czy Angular pogarszają INP?
Nie same w sobie, ale źle użyte potrafią narobić problemów. Chodzi głównie o zbyt częste renderowanie i ciężkie obliczenia na głównym wątku.
Czy hosting ma wpływ na INP?
Pośredni. Słaby serwer wydłuża odpowiedzi i czas renderu, co w efekcie dociąża wątek główny. Dlatego szybki hosting jest kluczowy.
Czy muszę zmieniać cały kod, jeśli INP jest słaby?
Nie zawsze. Często wystarczy zoptymalizować JS, dodać async/defer do skryptów i zoptymalizować fonty czy obrazki.
Czy optymalizacja INP poprawi też inne wskaźniki Core Web Vitals?
Tak, bo większość działań wokół INP (np. usunięcie blokujących skryptów) pozytywnie wpływa też na LCP i CLS.
