Dla większości właścicieli stron internetowych Core Web Vitals to temat, który powinien być domkniety. LCP, FID, CLS weszły w życie w 2021 roku, wszyscy zdążyli się już przyzwyczaić. Problem w tym, że w marcu 2024 Google po cichu wymienił FID na INP, a po dwóch latach od tej zmiany większość polskich stron nadal wypada na tym wskaźniku słabo. W 2026 roku nie można dłużej ignorować tego faktu, ponieważ INP jest jedną z trzech głównych metryk decydujących o tym, czy strona jest gotowa do rankowania w konkurencyjnych frazach.
Czym różni się INP od FID
FID mierzył tylko jedną rzecz: opóźnienie pierwszej interakcji użytkownika z witryną. Jeżeli strona reagowała szybko na pierwsze kliknięcie, zdawała test. INP idzie znacznie dalej. Mierzy opóźnienie każdej interakcji podczas całej sesji użytkownika i wybiera wartość na poziomie 98 centyla jako reprezentatywną. Innymi słowy, wystarczy, że dwadzieścia pierwszych kliknięć było szybkich, ale dwudzieste pierwsze, które uruchamia wolny handler JavaScript, może zrujnować wynik.
Różnica jest fundamentalna, bo INP obnaża problemy, które FID zamiatał pod dywan. Ciężkie skrypty analityczne, third-party widgety, slow React re-rendery, bloatowane GTM-y i niepotrzebne animacje są widoczne w INP od razu. Próg dobrego wyniku to 200 milisekund, przeciętnego 500 milisekund, wszystko powyżej to wynik słaby. Strony, które miały idealny FID, potrafią mieć INP na poziomie 800 milisekund i nawet o tym nie wiedzieć.
Jak sprawdzić swój wynik
INP mierzy się wyłącznie na danych z prawdziwych użytkowników, a nie w laboratorium. Oznacza to, że PageSpeed Insights pokazuje dwie wartości: wynik z Chrome User Experience Report, czyli realne dane z ostatnich 28 dni, oraz wynik lab, który jest tylko szacunkiem. Do diagnozy używa się danych terenowych, do testowania poprawek używa się DevTools z funkcją Performance panel i nowej sekcji Interaction.
Dobrym punktem startowym jest raport Core Web Vitals w Google Search Console, który pokazuje rozkład wyników po URL-ach i urządzeniach. Jeżeli mobilne wyniki są znacznie gorsze od desktopowych, problem prawie zawsze leży w JavaScript, a nie w CSS czy obrazach. Kolejnym krokiem jest uruchomienie własnego narzędzia typu web-vitals-js na stronie i wysyłanie danych do swojej analityki, żeby widzieć korelację z konwersją.
Pięć najczęstszych przyczyn słabego INP
- Ciężkie handlery onClick, które wykonują obliczenia synchronicznie zamiast delegować je do requestIdleCallback
- Third-party skrypty marketingowe i analityczne ładowane bez defer i bez priorytetyzacji
- React i inne frameworki renderujące całe poddrzewa komponentów przy każdej zmianie stanu
- Animacje oparte na setInterval zamiast requestAnimationFrame, które blokują wątek główny
- Content Security Policy i obsługa A/B testów realizowana przez JavaScript zamiast przez edge
Jak naprawić INP bez przepisywania aplikacji
Większość poprawek INP nie wymaga głębokiej refaktoryzacji. Pierwszy krok to audyt skryptów zewnętrznych i wyrzucenie wszystkiego, co nie jest absolutnie niezbędne. Typowa strona korporacyjna ładuje 8-12 skryptów trackujących, z czego większość nikt nie używa od roku. Drugi krok to opóźnienie ładowania pozostałych za pomocą atrybutu defer oraz użycie Facebook Pixela i Google Analytics w trybie sendBeacon, żeby nie blokowały wątku głównego.
Kolejny krok dotyczy własnego kodu aplikacji. W React i Vue trzeba sprawdzić, czy komponenty używają memoizacji tam, gdzie trzeba, i czy stan globalny nie wywołuje niepotrzebnych re-renderów. W praktyce pomaga rozdrobnienie kontekstów, zastąpienie useState przez useReducer w złożonych formularzach i przeniesienie ciężkich obliczeń do Web Workera. Każda z tych zmian robi niewielką różnicę, ale po kilku razem INP spada z 800 do 300 milisekund w tydzień pracy.
INP nie karze za pojedynczy wolny klik. Karze za to, że budujesz aplikację, w której nigdy nie wiadomo, który klik będzie wolny.
Co zmienia wdrożenie Cloudflare albo Vercel
Infrastruktura edge, taka jak Cloudflare Workers czy Vercel Edge Runtime, ma zaskakująco duży wpływ na INP. Powód jest prosty: część logiki, która wcześniej była wykonywana w przeglądarce użytkownika, przenosi się do węzła edge, który jest fizycznie bliżej użytkownika i ma znacznie większą moc obliczeniową. Personalizacja na podstawie kraju, A/B testy, feature flagi i redirecty przestają blokować wątek JavaScript w przeglądarce.
Dla typowej polskiej firmy wdrożenie Cloudflare przed istniejącą stroną WordPress albo sklepem Shopify to zmiana rzędu 100-200 milisekund na INP bez jednej linijki zmian w kodzie aplikacji. Ten sam efekt uzyskuje się, migrując hosting z tradycyjnego VPS w Niemczech na sieć edge z presence w Warszawie i Frankfurcie. To jedna z nielicznych decyzji infrastrukturalnych, które zwracają się w mniej niż miesiąc.
Kiedy warto zlecić to zewnętrznie
Jeżeli masz jedną prostą stronę i czas, optymalizację INP można zrobić samodzielnie w kilka dni, korzystając z dokumentacji Google i narzędzi web.dev. Jeżeli masz złożoną aplikację, sklep e-commerce z setkami SKU albo SaaS z wieloma ekranami, warto od razu skorzystać z zewnętrznej ekspertyzy. Dobra agencja zrobi audyt w tydzień, przedstawi priorytety oraz koszty i wdroży najważniejsze poprawki w kolejnych dwóch tygodniach. Koszty mieszczą się zwykle w przedziale od kilku do kilkunastu tysięcy złotych i zwracają się wzrostem ruchu organicznego w ciągu kwartału.
Studium przypadku: sklep WooCommerce w cztery tygodnie
Jeden z naszych klientów, średniej wielkości sklep internetowy z branży home and living, w listopadzie 2025 roku miał INP na poziomie 720 milisekund na mobile i stracił w czasie Black Friday około 18 procent konwersji w porównaniu z rokiem poprzednim. Google Search Console pokazywał spadek pozycji w kluczowych frazach komercyjnych. Zamiast planować przepisywanie sklepu, zdecydowaliśmy się na czterotygodniowy audyt i optymalizację pod INP bez zmiany platformy.
Pierwszy tydzień poświęciliśmy na audyt. Zidentyfikowaliśmy 14 aktywnych skryptów trackujących, z których faktycznie używane były trzy. Wyłączenie reszty zajęło dwa dni i natychmiast obniżyło INP do 510 milisekund. Drugi tydzień to optymalizacja handlerów onClick w koszyku i na stronie produktu, gdzie pojedyncze kliknięcie wywoływało pełny re-render komponentu z listą rekomendacji. Trzeci tydzień to migracja plików statycznych do Cloudflare R2 i wprowadzenie cache na poziomie edge dla stron kategorii. Czwarty tydzień to testy i korekty. Finalny wynik INP wyniósł 190 milisekund, CLS poprawiony z 0.18 do 0.04, a ruch organiczny wrócił do poprzednich poziomów w ciągu sześciu tygodni.
Całkowity budżet projektu wyniósł kilkanaście tysięcy złotych i był znacząco niższy niż potencjalny koszt kolejnego sezonu zakupowego z gorszą konwersją. To typowy rachunek zwrotu dla dobrze przeprowadzonego audytu INP, jeżeli problem tkwi w warstwie frontendu i zewnętrznych skryptach, a nie w architekturze aplikacji.
Podsumowanie
INP nie jest kolejną techniczną metryką, która ma znaczenie tylko dla developerów. To wskaźnik, który w 2026 roku decyduje o pozycji w Google i o tym, czy użytkownik zostanie na stronie po pierwszym kliknięciu. Firmy, które podejdą do tego poważnie w pierwszym półroczu, wejdą w drugie z przewagą, której trudno będzie dogonić w kolejnych miesiącach. Pierwszym krokiem nie musi być duża inwestycja, a rzetelny audyt tego, co faktycznie ładuje się na stronie i jakie skrypty blokują wątek główny.