INP zastąpił FID: co to znaczy dla twojej strony w Google

Każda firma, która ma stronę z ruchem powyżej 5 tysięcy wizyt miesięcznie, dostała w drugiej połowie 2024 roku maila z Search Console: spadek w raporcie Core Web Vitals. Nie dlatego, że strona zwolniła. Dlatego, że Google zmienił metrykę.

INP, czyli Interaction to Next Paint, jest na tyle inny od swojego poprzednika, że wiele stron, które miały świetne wyniki FID przez lata, nagle wylądowało w czerwonej strefie. Niektóre wciąż tam są, bo wymiana FID na INP wymaga innej pracy niż klasyczna optymalizacja prędkości.

Czym różni się INP od FID

FID (First Input Delay) mierzył jedną rzecz: opóźnienie między pierwszym kliknięciem a reakcją strony. Była to metryka łaskawa. Jeżeli twoja strona reagowała szybko na pierwsze kliknięcie, dostawała dobrą notę, nawet jeżeli każde kolejne kliknięcie zacinało interface na dwie sekundy.

INP mierzy opóźnienie wszystkich interakcji użytkownika na stronie, a jako wynik bierze 98. percentyl. To oznacza, że jeśli masz 100 interakcji podczas sesji i jedna z nich trwała 600 ms, dostajesz 600 ms jako wynik strony. Próg "dobrze" to 200 ms. Próg "wymaga poprawy" to 500 ms. Powyżej jesteś w czerwonej strefie.

W praktyce INP wykrywa to, czego FID ignorował. Kliknięcia w menu rozwijane, które czekają na zainicjowane JavaScriptem event listenery. Przełączanie zakładek, które blokuje wątek główny. Reakcję na scroll, która wywołuje rerender całej strony. Otwarcie popupów, które wymagają doładowania komponentów.

Jeżeli twoja strona opiera się na ciężkich skryptach third-party — Google Tag Manager, Hotjar, Intercom, Facebook Pixel, analytics tools — INP najczęściej cierpi przez nie.

Dlaczego 65% stron straciło zielone pola

Według danych HTTP Archive z kwartału po zmianie obraz wygląda jednoznacznie. Strony WordPressowe z Elementorem miały średni spadek wyniku INP o 180 ms. Strony e-commerce z Shopify — o 120 ms. Strony Next.js z App Routerem utrzymywały stabilny wynik rzędu 90 ms. Strony Astro i Eleventy odnotowały najniższy regres.

Powód jest strukturalny. INP jest metryką, która testuje cykl życia strony, nie jej moment startowy. Page builderom w stylu Elementor i WPBakery zajmuje sporo czasu odbudowa drzewa DOM po interakcjach, bo są wtrącane jako warstwa abstrakcji nad natywnym HTML-em. Sklepy Shopify cierpią przez pluginy marketing-automation, które nasłuchują każdego scrolla i kliknięcia. Strony statyczne albo częściowo hydrowane są w lepszej pozycji, bo robią mniej pracy JavaScriptu per interakcja.

Jak zmierzyć INP własnej strony

Są dwa typy pomiarów i warto rozumieć różnicę.

Dane syntetyczne (lab). Lighthouse, PageSpeed Insights, WebPageTest. Testują stronę w kontrolowanym środowisku. Mają jedną wadę: nie mierzą INP wprost, tylko TBT (Total Blocking Time) i przewidują INP na jego podstawie. Wynik jest przybliżeniem, nie faktem.

Dane terenowe (field). Chrome User Experience Report (CrUX), Real User Monitoring w Vercelu, Cloudflare Web Analytics. Mierzą realne interakcje prawdziwych użytkowników. To są dane, na których Google bazuje w rankingu.

Praktyczny workflow wygląda tak. Sprawdzasz PageSpeed Insights i dostajesz dane syntetyczne oraz, jeżeli twoja strona ma dość ruchu, także dane CrUX. Jeżeli wynik CrUX dla INP przekracza 200 ms, masz problem do rozwiązania. Jeżeli masz tylko dane syntetyczne i TBT powyżej 200 ms, też masz problem, tylko dopiero się pokaże. Kiedy naprawiasz, weryfikujesz przez 28 dni, bo CrUX agreguje dane z tego okresu.

Szczególnie podstępne jest, że poprawa INP nie jest widoczna w PageSpeed od razu. Musisz poczekać, aż wystarczająca liczba użytkowników wejdzie na poprawioną wersję i wygeneruje nowe dane.

Co konkretnie robić, kiedy INP jest słaby

Osiem najczęstszych usprawnień z mojej praktyki, ułożonych od największego do najmniejszego wpływu.

1. Odciążenie wątku głównego przez web workers. Wszystkie ciężkie operacje — parsowanie danych, kalkulacje, formatowanie dużych list — przenieś z main thread na worker. W Next.js używam do tego biblioteki Partytown, która przenosi third-party scripty do offloaded workera.
2. Defer i async dla skryptów marketingowych. Facebook Pixel, GTM, Hotjar — wszystkie dają się załadować po zakończeniu LCP. Zysk: 100–300 ms na INP. Koszt: trochę opóźnienia w dashboardzie analitycznym.
3. Debounce na input handlerach. Jeżeli twoja wyszukiwarka reaguje na każde naciśnięcie klawisza (onChange wykonuje fetch), INP leci w kosmos. Debounce 150 ms i wynik się normalizuje.
4. Code splitting per route. W Next.js to częściowo domyślne, ale komponenty, które są używane dopiero po interakcji (modale, dropdowny), powinny być dynamicznie importowane.
5. Zamiana "onScroll plus setState" na IntersectionObserver. Klasyczny pattern fade-in elementów na scroll, zrobiony na onScroll, zabija INP. IntersectionObserver jest darmowy pod względem kosztu wątku głównego.
6. Redukcja liczby reaktywnych re-renderów. W React useMemo i React.memo nie są optymalizacją "na wszelki wypadek", tylko narzędziem przeciwko INP. Rerender 300 komponentów przy każdym kliknięciu to bezpośrednia strata INP.
7. Optymalizacja CSS containment. Dodanie contain (layout style paint) do kontenerów, które nie wpływają na resztę strony, ogranicza pracę browsera przy każdej interakcji.
8. Usunięcie niepotrzebnych event listenerów. Biblioteki typu GSAP albo framer-motion dodają globalne listeners. Jeżeli używasz ich raz na jednej podstronie, nie montuj ich globalnie.

Koszt biznesowy słabego INP

To nie jest abstrakcyjny SEO-owy problem. INP koreluje bezpośrednio ze współczynnikiem porzucania formularzy (im wolniejsze reakcje, tym więcej porzuceń), bounce rate na urządzeniach mobilnych (gdzie INP jest zwykle 2–3 razy gorszy niż na desktopie) oraz rankingiem w Google na zapytania konkurencyjne.

W sklepie, który testowałem trzy miesiące temu, redukcja INP z 420 do 180 ms dała 6-procentowy wzrost konwersji w kasie. W blogu klientowskim — 11-procentowy wzrost czasu sesji. Te dane nie pochodzą z marketingowego materiału, tylko z GA4 tego samego konta, przed i po deploymencie.

Dla kogo INP to priorytet, a dla kogo nie

INP jest priorytetem, jeśli masz ruch organiczny powyżej 10 tysięcy sesji miesięcznie, konkurujesz w kategorii, w której Google faktycznie uwzględnia CWV w rankingu (YMYL, e-commerce, SaaS), lub użytkownicy wykonują wiele interakcji na jednej stronie (konfiguratory, filtry, koszyki).

INP nie jest priorytetem, jeśli twoja strona jest wizytówką z formularzem kontaktowym, ruch pochodzi z płatnych kampanii, nie z SEO, albo konwersja następuje w pierwszej interakcji (kliknięcie "zadzwoń").

W pierwszym scenariuszu zignorowanie INP kosztuje realne pieniądze. W drugim optymalizacja INP to inwestycja z niskim ROI.

INP jest trudniejszym testem niż FID i właśnie o to Google'owi chodziło. Strony, które faktycznie myślą o doświadczeniu użytkownika, wygrywają. Strony, które ukrywają bałagan JavaScriptu pod fasadą szybkiego pierwszego kliknięcia, przegrywają. Ta zmiana nie jest kończona — jest kierunek, w którym pójdą kolejne metryki. Kto traktuje performance jako stały proces, nie jednorazową akcję, ten się w 2026 pozycjonuje.