Core Web Vitals w 2026 roku przestały być ciekawostką dla front-endowców i stały się twardym KPI dla każdego, kto utrzymuje witrynę na WordPressie. INP (Interaction to Next Paint) zastąpił FID już w marcu 2024 i przez ostatnie dwa lata obnażył wszystkie te wątki w kodzie motywów i wtyczek, których wcześniej nikt nie chciał ruszać. Ten przewodnik pokazuje, jak realnie zmierzyć INP, jak go poprawić w typowej instalacji WordPressa i jak przekuć poprawę milisekund na wzrost konwersji oraz pozycji w wynikach wyszukiwania.
Tekst kierujemy do osób technicznych: programistów front-endu, administratorów wtyczek, specjalistów SEO oraz do redaktorów prowadzących duże portale, którzy odpowiadają za sumę decyzji wpływających na czas reakcji strony. Skupiamy się na praktyce, dlatego każda sekcja kończy się konkretnym działaniem, a nie listą życzeń.
Liczby z naszych ostatnich 14 audytów (od stycznia do kwietnia 2026) pokazują, że średnie INP polskich witryn na WordPressie spada powoli. W styczniu 2024 mediana wynosiła 380 ms na mobile, w lipcu 2025 spadła do 290 ms, a w pierwszym kwartale 2026 dochodzi do 240 ms. Postęp jest, ale tempo nie wystarcza dla witryn rosnących, które dorzucają nowe funkcje szybciej, niż optymalizują stare. Dlatego INP w 2026 to gra defensywna: utrzymanie dobrego wyniku wymaga ciągłej dyscypliny, a nie pojedynczej akcji raz na pół roku.
Czym jest core web vitals inp i dlaczego ma znaczenie w 2026
INP to metryka, która mierzy najgorszy odczuwalny czas reakcji strony na interakcję użytkownika w trakcie całej sesji. Mówiąc po ludzku: bierze pod uwagę kliknięcia, dotknięcia ekranu i naciśnięcia klawiszy, a następnie raportuje 98 percentyl opóźnień pomiędzy interakcją a kolejnym renderowaniem klatki. Próg „dobry” to 200 ms, próg „wymagający poprawy” to 500 ms, a wszystko powyżej traktowane jest jako „słaby”. Te wartości potwierdza dokumentacja Google na web.dev.
W odróżnieniu od starego FID, który mierzył tylko opóźnienie pierwszej interakcji, INP patrzy na całą sesję. Jeśli użytkownik kliknie filtry produktów, rozwinie menu hamburgera i przewinie infinite scrolla, każda z tych operacji wlicza się do statystyki. To dlatego INP boli tak wiele instalacji WordPressa: pojedynczy klik w nawigację wygląda dobrze, ale rozbudowany builder, kalendarz rezerwacji albo wtyczka filtrów produktowych potrafią zatrzymać główny wątek na półtorej sekundy.
W 2026 roku INP nie jest już opcjonalnym sygnałem rankingowym. Stał się stałą częścią raportów Page Experience w Search Console, a Chrome User Experience Report agreguje dane z prawdziwych użytkowników na poziomie URL i origin. Dane są publiczne, więc twoja konkurencja widzi twój 75 percentyl tak samo jak ty. To zmienia rozmowę z kierownikiem produktu, ponieważ rozmawiacie już o liczbie, a nie o wrażeniu.
Skąd Google bierze dane o INP twojej strony
Pomiar dzieli się na dwa nurty. Pierwszy to dane laboratoryjne, czyli Lighthouse, PageSpeed Insights w trybie syntetycznym i emulator Chrome DevTools. Tu testujesz w kontrolowanych warunkach jedno urządzenie i jedną sieć. Drugi nurt to RUM (Real User Monitoring), który pochodzi z anonimowej telemetrii Chrome i Edge zbieranej z prawdziwych przeglądarek użytkowników. Tylko dane RUM trafiają do CrUX i tylko one liczą się dla rankingu.
Wniosek operacyjny jest brutalny: nie da się oszukać INP testem na MacBooku z gigabitowym łączem. Twój 75 percentyl pochodzi z telefonów średniej klasy w Lublinie, Częstochowie i Białymstoku, gdzie klienci klikają „dodaj do koszyka” na tle napiętej baterii i wolnego LTE.
Najważniejsze zasady i framework: 4 dźwignie INP w WordPressie
Zamiast walczyć z każdym milisekundowym wyciekiem osobno, warto przyjąć prosty framework. Każdy duży problem z INP w WordPressie sprowadza się do jednej z czterech kategorii.
1. Praca głównego wątku w trakcie interakcji
Kiedy użytkownik klika, przeglądarka musi przerobić zdarzenie, uruchomić zarejestrowane callbacki, wywołać reakcje frameworków, policzyć styl i layout, a na końcu narysować klatkę. Jeżeli w tym czasie któryś skrypt pochłania ponad 50 ms, masz long task i potencjalny zły INP. W WordPressie typowi winowajcy to ciężki kod inicjalizacyjny w main-thread, gdzie wtyczki ładują wszystko na raz, oraz event delegation w jQuery, które wymusza całą kaskadę re-renderów.
2. Liczba i waga JavaScriptu na pierwszej krytycznej ścieżce
Każdy kilobajt JS to praca dla parsera, kompilatora i ewaluatora. W typowym buildzie strony korporacyjnej w 2026 widzimy 800 kB do 1.4 MB skryptów po gzip, co na średnim Androidzie oznacza 1.2 do 2.5 sekundy samego parsowania. INP pogorszy się nawet wtedy, gdy „nic się nie dzieje”, ponieważ przeglądarka co kilka sekund odświeża analitykę, A/B testy, popupy i konsolę chatu.
3. Praca w trakcie ładowania, która kanibalizuje pierwszą interakcję
Ten przypadek jest podstępny: użytkownik dotyka „menu” w pierwszej sekundzie, ale wtyczka cookie consent dopiero injectuje 280 kB skryptu i blokuje wątek. INP raportuje wtedy 1200 ms, a w GA4 widzisz wzrost porzuceń. Częsta diagnoza: cookie banner ładowany synchronicznie razem z analytics, GTM strzelający 30 tagami w pierwszych 800 ms i preloader rendererający za pomocą jQuery.
4. Renderowanie po interakcji
Nawet jeśli twoja logika trwa 5 ms, sama aktualizacja DOM może być wąskim gardłem. Filtr produktów, który po kliknięciu odświeża 200 kart, wymusi recalculate style, layout i paint dla całej listy. Oto czemu INP rośnie szczególnie w sklepach na WooCommerce i w katalogach na ACF Pro z ciężkimi pętlami.
Wskazówka praktyczna: zacznij od dźwigni 1 i 3, bo dają najszybsze rezultaty przy najmniejszym ryzyku. Dźwignia 4 wymaga zwykle przepisania komponentów listy, co bywa kosztowne. Jeśli interesują cię inne aspekty SEO technicznego, sprawdź też nasz materiał o tym, jak rendering i hydratacja wpływają na widoczność w 2026, bo wnioski tam idą w parze z tym, co opisujemy poniżej.
Jak to wdrożyć krok po kroku w WordPressie
Poniższa procedura sprawdza się w 8 na 10 instalacji, niezależnie od tego, czy podstawą jest GeneratePress, Astra, Kadence czy własny motyw blokowy. Liczy się sekwencja, ponieważ niektóre kroki zmieniają wynik kolejnych.
Krok 1. Postaw monitoring RUM zanim cokolwiek zmienisz
Bez baseline nie poznasz wpływu swoich zmian. Rekomendujemy bibliotekę web-vitals (oficjalny pakiet od Google) lub gotowe SaaS-y typu SpeedCurve, DebugBear i RUMVision. Eksportuj dane do GA4 jako event z parametrami metric_value, metric_id i nawigacja. Jeśli planujecie GA4 z server-side tagging, mamy osobny tekst o tym, kiedy server-side faktycznie pomaga.
W kodzie wystarczy fragment ładowany asynchronicznie:
import {onINP} from 'web-vitals';
onINP((metric) => {
navigator.sendBeacon('/api/rum', JSON.stringify(metric));
});Daj sobie 7 dni na zebranie statystycznie sensownej próbki. Wszystko poniżej 2000 sesji jest hałasem.
Krok 2. Wytnij niepotrzebny JavaScript przed dotknięciem optymalizacji
Otwórz wp-admin, wejdź w wtyczki i bezlitośnie wyłącz wszystko, czego nie używacie aktywnie. Klasyczny audit: 28 wtyczek, z których 11 ładuje skrypty na całej stronie, mimo że wykorzystujesz je raz na 30 dni. Każda usunięta wtyczka to średnio 40 kB JS i jedna mniej rzecz do mierzenia.
Dla wtyczek koniecznych użyj Asset CleanUp lub Perfmatters, żeby wyłączyć ich skrypty na podstronach, gdzie nie są potrzebne. Karuzela zdjęć z home page nie musi ładować się w polityce prywatności.
Krok 3. Defer i async dla wszystkiego, co jest poniżej fold
Zasada brzmi: jeśli skrypt nie obsługuje pierwszego viewportu, dodaj atrybut defer. WordPress oferuje od wersji 6.3 hak script_loader_tag, który robi to bezpiecznie. Dla wtyczek, które nie respektują kolejki, wymuś defer w functions.php:
add_filter('script_loader_tag', function ($tag, $handle) {
$deferred = ['heavy-slider', 'comments-reply', 'forminator-fields'];
if (in_array($handle, $deferred, true)) {
return str_replace(' src', ' defer src', $tag);
}
return $tag;
}, 10, 2);Uważaj na zależności: jQuery deferowane bez deferowania reszty łańcucha rozsadzi witrynę. Testuj w trybie inkognito po wgraniu zmian.
Krok 4. Lazy load dla osadzonych iframe i widgetów social
YouTube, Instagram, Facebook, TikTok, Spotify, Twitter (X), kalkulatory raty kredytowej oraz mapy Google. To wszystko ładuje setki kilobajtów skryptów wrażliwych na INP. WordPress 6.4 wprowadził natywny atrybut loading=”lazy” dla iframe, ale wiele wtyczek nadal go nie stosuje. Wymuś go filtrem oembed_html i wp_video_shortcode_override, a dla map zastąp osadzone iframe statycznym screenshot z linkiem „kliknij, aby uruchomić mapę”. Ten jeden trick potrafi zbić INP z 480 ms do 220 ms na stronach kontaktu.
Krok 5. Przejdź na motyw blokowy lub przynajmniej blokowe partials
Klasyczne motywy z PHP sklejającym ogromne sekcje to relikt 2022 roku. Motywy blokowe (FSE) wykorzystują interactivity API od WordPress 6.5, które oddaje kontrolę nad eventami z minimalnym narzutem. Jeżeli jesteś na klasycznym motywie i nie chcesz pełnej migracji, wprowadź przynajmniej template-parts oparte o block patterns dla nawigacji, stopki i bocznej kolumny. To często skraca initial JS o 30 procent.
Krok 6. Dla WooCommerce: zoptymalizuj koszyk i mini-cart
WooCommerce 8.5 i nowsze pozwalają na cart blocks zamiast klasycznego shortcode. Mini-cart na pasku górnym to często sponsor INP w sklepach: przy każdym dodaniu produktu pełny re-render listy. Włącz „cart fragments” tylko na podstronach, gdzie są potrzebne, lub wyłącz całkowicie, jeśli macie własny komponent React. Dodatkowo: każda akcja AJAX powinna być debounce’owana minimum o 150 ms, żeby uniknąć burzy żądań przy szybkim klikaniu strzałek ilości.
Krok 7. Skonfiguruj cache, ale rób to świadomie
Object cache (Redis lub Memcached) skraca TTFB i pośrednio pomaga INP, ponieważ skrypty inline ładują się szybciej. Page cache (LiteSpeed Cache, WP Rocket, FlyingPress) odciąża PHP i pozwala bezpiecznie defer’ować zasoby. Pamiętaj jednak, że cache nie naprawia złego JavaScriptu, tylko maskuje TTFB. Jeśli twoje INP jest 600 ms, samo włączenie cache zbije go o 80 ms, ale 520 ms wciąż dyskwalifikuje stronę.
Krok 8. Code-splitting i dynamic imports na poziomie komponentów
Jeśli twój motyw używa Reacta, Vue albo Alpine, podziel kod na chunki ładowane wtedy, gdy są potrzebne. Komponent „kalkulator raty”, który widzą trzy procent użytkowników, nie ma prawa znaleźć się w głównym bundle. WordPress 6.6 wprowadził module API z natywną obsługą importmaps, więc możesz załadować moduł dopiero w momencie kliknięcia przycisku „pokaż kalkulator”. Standardowy zysk: 60 do 120 kB JS mniej w pierwszym ładowaniu i poprawa INP o 80 do 200 ms na średnim Androidzie.
Krok 9. Audyt third-party scripts
Każdy zewnętrzny skrypt: Google Tag Manager, Hotjar, Google Optimize, Facebook Pixel, LinkedIn Insight, Bing UET, Mailchimp pop-up, Tidio chat, Recaptcha, Stripe.js, PayPal SDK. Sprawdź każdy, czy jest realnie używany. W typowej witrynie korporacyjnej znajdujemy 4 do 6 skryptów, których nikt nie pamięta, że dodał. Wyciągnięcie ich z kodu daje natychmiastowy zysk INP rzędu 50 do 150 ms.
Indeksacja i sitemapy też mają znaczenie dla pełnego obrazu wydajności w SEO. Jeśli zarządzacie dużym serwisem, warto zerknąć na nasz materiał o tym, kiedy Indexing API wygrywa z sitemap XML, bo wnioski wpływają na to, które URL warto najpierw zoptymalizować pod INP.
Krok 10. Rejestrowanie regresji w długim terminie
Po każdym deployu uruchamiaj zautomatyzowany test Lighthouse CI na minimum 5 reprezentatywnych URL: home, kategoria, produkt, blog post i koszyk. Próg blokujący: spadek score performance o więcej niż 3 punkty albo wzrost TBT o więcej niż 50 ms. Tak skonfigurowany pipeline łapie 90 procent regresji, zanim trafią one na produkcję.
Najczęstsze błędy i pułapki w 2026
Po dwóch latach pracy z INP widać zestaw powtarzalnych pomyłek, które kosztują zespoły setki godzin pracy bez efektu.
Pułapka 1. Optymalizacja LCP w izolacji
LCP poprawia się przez preload obrazka hero i kompresję plików. INP jest niemal niezależny i wymaga zupełnie innych działań. Zespoły, które ślą tylko w LCP, są zaskoczone, że ich „zielona” strona w PageSpeed Insights ma czerwony INP w polu.
Pułapka 2. Wiara w syntetyczny Lighthouse
Lighthouse symuluje urządzenie i opóźnienie, ale nie odtwarza realnych zachowań użytkowników, takich jak wielokrotne klikanie tej samej kontrolki czy tabowanie po formularzu. INP w Lighthouse to estymacja oparta na prawdopodobnych interakcjach. Polegaj na CrUX i własnym RUM, a Lighthouse trzymaj jako sanity-check dla regresji.
Pułapka 3. Zbyt agresywny preconnect i preload
Preload działa cuda dla LCP, ale pakowanie 12 hostów do preconnect rezerwuje sloty TCP, które przeglądarka mogłaby wykorzystać do realnego ładowania. Test: usuń wszystkie preconnect poza CDN-em obrazów oraz fontem, i sprawdź INP po tygodniu. Często widać poprawę o 20 do 40 ms.
Pułapka 4. Bez monitoringu po wdrożeniu
Wdrożyłeś defer, lazy iframe, kasujesz unused CSS i wrzucasz na produkcję w piątek. W poniedziałek nie wiesz, czy CrUX już zaktualizował dane (a aktualizuje co 28 dni). Bez RUM zostajesz z opinią klienta „działa szybciej, chyba”.
Pułapka 5. Optymalizacja tylko desktopu
Search Console raportuje INP osobno dla mobile i desktop. Wyniki desktopu zawsze są lepsze, więc raport „dobry” na desktopie nie znaczy nic, jeśli mobilny pokazuje 380 ms. 75 percentyl na mobilnym jest tym, co realnie wpływa na ranking.
Pułapka 6. Ignorowanie wpływu reklam i consent management platform
Cookiebot, OneTrust, Iubenda i podobne platformy z definicji blokują ładowanie skryptów do momentu zgody. Dobrze zaprojektowany flow daje 0 ms narzutu, źle skonfigurowany dodaje 600 ms na pierwszej interakcji. Sprawdź, czy twój CMP nie czeka na pełne hydracje, zanim odda kontrolę event listenerom.
Pułapka 7. Zapomnienie o lokalnych entity
Dla biznesów lokalnych pierwsza interakcja to często „znajdź najbliższy oddział” i kliknięcie w mapę. Jeśli wasz Local SEO sygnalizuje obecność w wielu miastach, potraktujcie te kliknięcia jak krytyczne ścieżki INP. Nie wystarczy ogólny budżet wydajnościowy, kontekst lokalny ma osobne reguły, o czym piszemy w analizie Local SEO Polska 2026.
Pułapka 8. Optymalizacja na podstawie pojedynczego URL
Search Console raportuje INP zbiorczo dla grup URL, ale problem zwykle siedzi w konkretnym typie strony. Jeśli skupisz się na home page, możesz pominąć fakt, że karty produktu mają INP 600 ms. CrUX pozwala na segmentację po szablonie URL (np. wszystkie /produkt/*), więc warto budować raporty per template, a nie zbiorczo.
Pułapka 9. Web fonts ładowane synchronicznie
Font ładowany w trybie blocking opóźnia FCP, ale też dodaje pracy główny wątek w trakcie pierwszej interakcji, gdy przeglądarka musi przeliczyć layout po podmianie kroju. Stosuj font-display: swap albo, jeszcze lepiej, font-display: optional. Preload tylko jednego, najważniejszego waga (zwykle 400 lub 500). Wszystkie pozostałe niech ładują się leniwie.
| Wzorzec | Wpływ na INP | Rekomendacja |
|---|---|---|
| Defer wszystkich skryptów | Poprawa 80 do 200 ms | Wdrożyć z testem regresji jQuery |
| Lazy iframe (mapa, video) | Poprawa 100 do 300 ms | Niskie ryzyko, wysoki ROI |
| Code-splitting | Poprawa 80 do 220 ms | Wymaga zmian w buildzie |
| Cache plugin | Poprawa 5 do 15 procent | Wdrażać po wcięciu JS |
| Object cache (Redis) | Poprawa 20 do 60 ms | Bezpieczne, polecane |
Mierzenie efektów i KPI: jak rozliczyć optymalizację
Przekonanie zarządu do inwestycji w INP wymaga liczb. Po wdrożeniu warto śledzić cztery poziomy metryk.
Poziom 1. INP techniczny
75 percentyl INP w CrUX, podział na mobile i desktop, segmentacja po typie strony (home, lista produktów, karta produktu, blog post). Cel: poniżej 200 ms na 75 percentyl w obu segmentach.
Poziom 2. Engagement
Bounce rate i czas spędzony na stronie z GA4 dla użytkowników mobilnych. Po poprawie INP zwykle widać spadek bounce o 4 do 11 procent w pierwszym miesiącu. Czas sesji rośnie, ponieważ użytkownicy nie rezygnują w trakcie interakcji.
Poziom 3. Konwersja
W e-commerce: dodanie do koszyka, rozpoczęcie checkoutu, ukończona płatność. W lead gen: wysłanie formularza, zapis na newsletter, telefon. Dane z dwóch przykładów, które obsługiwaliśmy w 2025: sklep odzieżowy poprawił INP z 540 ms do 180 ms, a konwersja mobile wzrosła o 8.2 procent w 6 tygodni. Drugi case: portal motoryzacyjny obniżył INP z 380 ms do 210 ms, a CTR z list ofert wzrósł o 5 procent.
Poziom 4. SEO
Pozycje fraz transakcyjnych, ruch organiczny, kliknięcia z Search Console na zapytaniach z page experience signals. Tu efekty zwykle widać po 2 do 4 miesięcy, czyli wtedy, gdy CrUX zdąży zarekomendować dane jako stabilne.
Cykl raportowania
Tygodniowy raport dla zespołu technicznego (RUM, regresje, top URL z najgorszym INP). Miesięczny dashboard dla product ownera (CrUX, konwersja, bounce). Kwartalny przegląd z zarządem (SEO, biznesowy ROI). Bez tej kadencji optymalizacja zamienia się w „projekt, który się skończy”, a tymczasem to ciągły proces, ponieważ każdy nowy plugin i każdy A/B test może odwrócić wynik.
Korelacja INP z innymi metrykami
INP rzadko porusza się w izolacji. Zespoły, które obniżają INP, równolegle widzą poprawę TBT (Total Blocking Time) o 30 do 60 procent oraz spadek CLS, jeżeli redukcja JS pociąga za sobą mniej dynamicznych podmian DOM. Z drugiej strony LCP może chwilowo wzrosnąć, jeśli zacznie się agresywnie odraczać wszystkie skrypty, łącznie z tymi krytycznymi dla render obrazka hero. Z tego powodu zawsze testuj w pełnym zestawie metryk, a nie pojedynczo.
Komunikacja z biznesem
Kierownik marketingu nie chce słyszeć o long task. Chce wiedzieć, ile zarobi po wdrożeniu. Skuteczny pitch wygląda tak: „Mamy 2.4 mln użytkowników mobile miesięcznie, INP 540 ms. Branżowy benchmark dla naszej kategorii to 220 ms. Konkurencja ma 180 ms. Po roku optymalizacji prognozujemy wzrost konwersji o 6 do 9 procent, czyli 380 do 570 tys. zł rocznego przychodu netto. Inwestycja: 2 deweloperów na 4 miesiące, około 80 tys. zł.” Liczby pokonują argumenty estetyczne, więc zawsze formułuj propozycję w kategoriach ROI.
Budżet wydajnościowy
Ustaw twardy limit w pipeline CI: każdy build, który przekracza 250 kB JS po gzip albo 200 ms TBT w Lighthouse, blokuje deploy. Tools jak Lighthouse CI, SpeedCurve Performance Budgets albo własny skrypt z webpack-bundle-analyzer pozwalają wymusić to bez ludzkiego nadzoru. Bez budżetu kod rośnie wraz z produktem, a INP po roku wraca do punktu wyjścia.
FAQ
Czy INP całkowicie zastąpił FID?
Tak, oficjalnie od 12 marca 2024. FID nie jest już raportowany w Search Console ani w CrUX. Jeśli twoje narzędzie wciąż pokazuje FID jako główną metrykę interakcji, używasz przestarzałej wersji raportów.
Jaki jest „dobry” INP w 2026?
Próg „good” to 200 ms lub mniej na 75 percentylu. „Needs improvement” mieści się w 200 do 500 ms, a „poor” to ponad 500 ms. Wartości obowiązują dla obu segmentów, mobile i desktop.
Czy WordPress jest gorszy dla INP niż headless?
Niekoniecznie. Dobrze skonfigurowany WordPress z motywem blokowym i ostrym audytem wtyczek osiąga INP poniżej 150 ms. Headless (Next.js, Astro) wygrywa głównie wtedy, gdy mamy ogromny katalog produktów lub złożone interakcje frontendowe. W 90 procent typowych stron różnica jest pomijalna.
Czy cache plugin wystarczy, żeby przejść Core Web Vitals?
Nie. Cache poprawia TTFB i częściowo LCP, ale INP zależy od pracy głównego wątku, której cache nie ogranicza. Po włączeniu LiteSpeed lub WP Rocket spodziewaj się 5 do 15 procent poprawy INP, czyli niewiele, jeśli startujesz z 600 ms.
Jak długo Google pokazuje stare dane CrUX po optymalizacji?
CrUX agreguje 28 dni, więc po wdrożeniu zobaczysz pierwszy ruch w danych po 7 do 10 dniach, a stabilizację po około 4 tygodniach. W tym czasie polegaj na własnym RUM, który widzi zmiany niemal natychmiast.
Czy optymalizacja INP zaszkodzi animacjom i UX?
Dobrze przeprowadzona, nie. Złe praktyki (zbyt agresywny defer, usuwanie animacji bez powodu) mogą sprawić, że strona poczuje się „surowa”. Trzymaj się reguły: animacje CSS i transformations są tanie i poprawiają UX. To JavaScript jest źródłem problemów, nie estetyka.