INP Core Web Vitals – co mierzy i jak poprawić na Twojej stronie

Klikasz „Dodaj do koszyka” i… nic. Sekunda, dwie, lekki nerw. Właśnie w takich momentach wchodzi całe na biało INP – metryka, która pokazuje, jak szybko strona reaguje na działania użytkownika. Nie chodzi o sam czas ładowania, ale o wrażenie płynności, kiedy ktoś klika, wpisuje, rozwija menu. INP Core Web Vitals uczy, że to, co dzieje się po interakcji, jest równie ważne jak pierwsze wrażenie. I jeśli masz e‑commerce, ta różnica często decyduje o konwersji.

Google zastąpił FID nową metryką, bo zwykłe „klikło się szybko” to za mało – liczy się, kiedy użytkownik zobaczy realną odpowiedź interfejsu. Co to oznacza w praktyce? Mierzysz nie tylko opóźnienie samego kliknięcia, ale cały cykl: reakcję skryptu, przeliczenia i moment, w którym UI naprawdę się odświeży. Brzmi technicznie? Jasne. Ale przekłada się na bardzo konkretne rzeczy: sprawny koszyk, filtry bez zadyszki, wyszukiwarkę, która nie myśli dłużej niż Ty.

INP Core Web Vitals w skrócie: co naprawdę mierzy

INP (Interaction to Next Paint) zbiera czasy wszystkich istotnych interakcji użytkownika na stronie: kliknięć, tapnięć i wpisywania z klawiatury. Dla każdej z nich liczy łączną latencję zdarzenia – od momentu akcji, przez obsługę w JS, aż po kolejny widoczny repaint interfejsu. W skrócie: kiedy użytkownik coś robi, INP patrzy, jak szybko UI na to zareaguje widoczną zmianą. To metryka „od akcji do efektu na ekranie”, a nie tylko „od akcji do startu skryptu”.

Aby oddać realne doświadczenie, INP raportuje jedną z najgorszych interakcji w trakcie wizyty (dokładniej: blisko skrajnego percentyla wszystkich interakcji w sesji). Właśnie dlatego pojedynczy „zacięty” klik potrafi zepsuć wynik, nawet jeśli pozostałe były szybkie. To zachęta, by poprawiać szczególnie te miejsca, gdzie użytkownicy naprawdę działają: dodawanie do koszyka, stosowanie filtrów, otwieranie mega‑menu czy wywołanie wyszukiwarki.

W praktyce na INP wpływają trzy składniki: Input Delay (gdy główny wątek jest zajęty i nie odbiera zdarzenia), czas wykonywania handlera (Twoje skrypty) oraz Presentation Delay (kiedy przeglądarka finalnie maluje zmiany). Jeśli którykolwiek z nich „puchnie”, użytkownik czuje lag. I choć to brzmi jak domena programistów, biznes widzi to jako porzucone koszyki czy krótszy czas sesji.

Progi jakości i interpretacja wyniku – kiedy jest dobrze?

Progi są proste: dobry wynik to ≤ 200 ms, do poprawy 200–500 ms, a powyżej 500 ms – słabo. To wartości, przy których większość ludzi czuje już „chropowatość” interfejsu. Jeśli więc Twoje krytyczne interakcje mieszczą się w dwóch setnych sekundy, jesteś w zielonej strefie i użytkownik postrzega stronę jako żwawą.

Uwaga na sposób agregacji danych. W raportach Core Web Vitals liczy się 75. percentyl danych z realnych użytkowników (tzw. field data), osobno dla mobile i desktop. To oznacza, że nie wystarczy „czasem jest szybko” – większość wizyt musi widzieć dobry rezultat. Dlatego optymalizujesz nie tylko na testowym laptopie, ale w warunkach zbliżonych do prawdziwego ruchu.

Jeszcze jedno: nie każda poprawa w ogólnym performance od razu przesunie INP. Możesz mieć świetny LCP i CLS, a wciąż wolny feedback po kliknięciu „Zastosuj filtr”. INP Core Web Vitals patrzy konkretnie na odpowiedź UI na interakcję – to osobna warstwa pracy obok klasycznego „przyspiesz ładowanie”.

Jak zmierzyć INP: PageSpeed Insights, Lighthouse i Search Console

Zacznij od PageSpeed Insights. Zobaczysz tam dwie perspektywy: dane z laboratorium (symulacja) oraz dane z pola (Chrome UX Report). Lab pokaże potencjał i regresje w kontrolowanych warunkach, a field powie, jak realni użytkownicy faktycznie odczuwają stronę. Jeśli lab wygląda dobrze, a field kuleje, masz sygnał: problem dotyczy konkretnych urządzeń, sieci albo scenariuszy użycia.

Lighthouse (np. w DevTools) pomaga zlokalizować winowajców: długie zadania JS, kosztowne style, powolne renderowanie. Uruchom test, a potem przejrzyj sekcję „Long Tasks” i waterfalle – szukaj fragmentów, które blokują główny wątek po akcji użytkownika. Brzmi skomplikowanie? W praktyce to prostsze niż się wydaje, szczególnie gdy testujesz konkretny scenariusz: klik w „Dodaj do koszyka”, rozwinięcie mega‑menu, wpisywanie w search.

Search Console daje widok strategiczny: raport Core Web Vitals grupuje podobne adresy i pokazuje, gdzie INP odstaje. Dzięki temu polujesz nie na pojedynczą podstronę, ale na cały typ stron – np. listing kategorii czy karty produktu. Dodatkowo rozważ wdrożenie real-user monitoring (np. biblioteka web‑vitals) i logowanie interakcji, które wypadają najgorzej. Szybko zobaczysz, czy problemem jest filtr, koszyk, czy może wyszukiwarka.

Równolegle do technicznych testów warto ogarnąć fundamenty SEO i treści – zwłaszcza gdy korzystasz z bloga do ruchu long‑tail. Tu przydaje się szybka analiza strony AI, która wyłapuje luki treściowe i mapuje priorytety. Szybka strona nie naprawi słabych treści, ale słabe treści nie przykryją wolnych interakcji – oba obszary muszą zagrać razem.

Co najczęściej psuje INP w e‑commerce

Sklepy mają wspólne grzechy: skomplikowane filtry, ciężkie skrypty koszyka, chaty, A/B testy, karuzele na pół ekranu. Każdy z tych elementów potrafi zająć główny wątek dokładnie wtedy, gdy użytkownik klika. Widzimy to raz po raz: pojedynczy widget analytics czy sprytny pop‑up potrafi zawyżyć INP o setki milisekund. Poniżej trzy obszary, które najczęściej wymagają interwencji.

Interakcje krytyczne: koszyk, filtry, wyszukiwarka

Dodawanie do koszyka często robi zbyt wiele naraz: walidacje, kalkulacje, fetch do API, odświeżenie mini‑koszyka, baner potwierdzenia. Rozdziel to na etapy. Najpierw minimalny feedback (zmiana stanu przycisku, badge w koszyku), a cięższe operacje odłóż poza krytyczną ścieżkę – krótkim timeoutem albo po repaint. W filtrach zastosuj debounce (np. 200–300 ms) i anulowanie poprzednich zapytań, żeby każde szybkie kliknięcie nie wywoływało nowego renderu. Serio, to często 5 linijek kodu.

Wyszukiwarka? Autocomplete bywa zabójczy. Ogranicz liczbę jednoczesnych zapytań, renderuj listę wirtualnie (tylko widoczne elementy), a wyniki pierwszej strony trzymaj w pamięci podręcznej. Najważniejsze, by po naciśnięciu klawisza szybko pojawił się sygnał działania: kursor, spinner w polu, subtelna zmiana placeholdera. Użytkownik widzi, że system żyje, a INP rejestruje szybką odpowiedź interfejsu.

Długie zadania JS i skrypty zewnętrzne

„Long Task” to każdy kawałek JS trwający > 50 ms na głównym wątku – a podczas interakcji to wieczność. Winni? Bundel z całym frameworkiem na każdej podstronie, biblioteki, które ładujesz „na wszelki wypadek”, oraz wtryski z tag managera. Rozwiązanie: code‑splitting per widok, wczytywanie modułów on‑demand i twardy przegląd tagów – co nie jest krytyczne, wczytuj po pierwszym malowaniu albo po interakcji.

Zewnętrzne skrypty (chat, heatmapy, A/B) uruchamiaj asynchronicznie i z priorytetem niższym niż interfejs. Obserwuj, czy nie blokują event loopa w momencie kliknięcia – to częsty wzorzec, gdy skrypt nasłuchuje na całym dokumencie. Jeśli musisz liczyć zdarzenia, rób to po szybkiej aktualizacji UI, nie przed nią. Czasem przeniesienie kosztownego liczenia do web workera potrafi uwolnić główny wątek na decydujące milisekundy.

Renderowanie UI: karuzele, mega‑menu, modale

Karuzele i rozbudowane menu miewają ciężkie layouty: setki węzłów DOM, obrazy bez wstępnych wymiarów, animacje oparte na właściwościach zmieniających układ. Zmieniaj transform i opacity zamiast height/width/top/left – wtedy przeglądarka użyje kompozytora zamiast pełnego przeliczania layoutu. Upewnij się też, że obrazy mają zdefiniowane rozmiary i są dekodowane asynchronicznie, by nie blokować repaintu.

Modale i mega‑menu warto inicjalizować leniwie i trzymać w DOM gotowe do pokazania, zamiast konstruować od zera po kliknięciu. Minimalny stan „otwarte” powinien malować się błyskawicznie, a dopiero potem dociągaj cięższe elementy (np. podgląd koszyka). Po stronie stylów przydatne są containment i unikanie kosztownych cieni/blurów na dużych obszarach – to detale, które realnie skracają czas do kolejnego paintu.

Szybkie wygrane: praktyczne sposoby na niższy INP

Jeśli chcesz zobaczyć efekt w tym tygodniu, celuj w działania, które dotykają głównego wątku tuż po interakcji. Najpierw zrób listę krytycznych akcji (koszyk, filtr, search), potem mierz każdą z nich osobno. W praktyce większość sklepów widzi największą poprawę po odchudzeniu handlerów i odłożeniu niekrytycznych efektów do chwili po pierwszym repaint. Oto lista ruchów, które zwykle zwracają się natychmiast.

• Debounce i throttle w filtrach oraz autosugestii (200–300 ms) + anulowanie poprzednich zapytań.
• Po kliknięciu najpierw minimalny feedback UI (zmiana stanu, skeleton), potem sieć/logika.
• Odłóż niekrytyczne skrypty zewnętrzne na idle lub po pierwszej interakcji.
• Code‑splitting i ładowanie modułów na żądanie dla widoków rzadko używanych.
• Animacje na transform/opacity, bez właściwości wymuszających relayout.
• Asynchroniczne dekodowanie obrazów i z góry ustawione wymiary elementów.

Stawiaj sobie budżet: pojedynczy handler nie powinien przekraczać ~50 ms. Jeśli nie schodzisz poniżej, podziel zadanie na etapy i pozwól przeglądarce pomalować UI pomiędzy nimi. Po takiej refaktoryzacji często widzimy spadek o 150–300 ms dla najcięższych interakcji – a to już różnica, którą czuć pod palcem.

INP na WordPressie, Shopify i Shoper – wskazówki wdrożeniowe

WordPress: ogranicz liczbę wtyczek i ładuj skrypty warunkowo tylko tam, gdzie są potrzebne. Zadbaj, by motyw i builder nie renderowały setek zbędnych węzłów w elementach interaktywnych (menu, karuzele). W Woo‑komponentach rozbij logikę koszyka: szybki feedback UI najpierw, cięższe przeliczenia chwilę później. Przenieś śledzące skrypty na asynchroniczne ładowanie i sprawdź, czy nie nasłuchują globalnie na całym dokumencie podczas kliknięć.

Shopify: przejrzyj aplikacje – wiele z nich wstrzykuje skrypty na wszystkich podstronach. Wyłącz te, których nie używasz, a pozostałe wczytuj asynchronicznie. W szablonie ogranicz kosztowne sekcje w krytycznych interakcjach (mini‑cart, menu), a autosugestię w search oprzyj na cache i debounce. Realnie, największe zyski daje usunięcie 1–2 ciężkich aplikacji i uproszczenie logiki koszyka.

Shoper: upewnij się, że dodatki nie ładują pełnych bibliotek JS na listingu i karcie produktu bez potrzeby. W interaktywnych elementach trzymaj minimalny DOM i pre‑inicjalizuj modale, by po kliknięciu tylko je pokazać. Jeśli korzystasz z zewnętrznych integracji, sprawdź ich wpływ przy pomocy testów Lighthouse uruchamianych na konkretnych scenariuszach (klik w koszyk, filtr). To szybki sposób, by namierzyć blokady głównego wątku.

Automatyzując treści i techniczne prace wokół sklepu, łatwiej łączysz SEO z wydajnością. Jeżeli chcesz mieć to spięte w jednym ekosystemie, zerknij na dostępne integracje – dzięki nim procesy nie rozchodzą się w różnych narzędziach. A kiedy uporasz się z wydajnością, dopnij też porządek w strukturze – zadbaj o sensowne linkowanie wewnętrzne, żeby ruch z bloga trafiał do kategorii i produktów.

Dla kogo to nie ma sensu? Jeśli masz statyczny landing z jedną sekcją i bez interakcji, gonitwa za ułamkami milisekund w INP nie przyniesie spektakularnych efektów – lepiej zainwestować czas w treści i dystrybucję. Z kolei jeśli Twój biznes wymaga ciężkich skryptów personalizacji na każdym kliknięciu, licz się z kompromisem i budżetuj UI tak, by użytkownik dostał szybki feedback, a reszta wykonała się w tle. W praktyce większość sklepów po przeglądzie krytycznych interakcji znajduje 2–3 miejsca, które „trzymają” cały wynik – a ich poprawa od razu widać w konwersji.