Optymalizacja INP WordPress 2026 | Przewodnik Interaction to... | WPPoland

Mariusz Szatkowski

INP w WordPressie: jak optymalizować Interaction to Next Paint w 2026

Ostatnio zweryfikowano: 12 października 2026

15 min czytania

Przewodnik

Core Web Vitals

Techniczne SEO

W 2026 roku szybka strona to już nie tylko taka, na której pierwszy obraz pojawia się błyskawicznie. Dziś o szybkości decyduje także responsywność.

Kiedy użytkownik klika przycisk na Twojej stronie WordPress, czy reakcja jest natychmiastowa, czy pojawia się wyczuwalne „szarpnięcie”? Tę lukę, czyli czas między działaniem użytkownika a wizualną reakcją przeglądarki, mierzy właśnie Interaction to Next Paint (INP). INP to jeden z trzech wskaźników Core Web Vitals, a dokumentacja Google Search podaje, że Core Web Vitals są wykorzystywane przez jej systemy rankingowe. Ta sama dokumentacja dodaje, że nie istnieje jeden sygnał page experience, a trafność treści ma pierwszeństwo, więc INP rozstrzyga między przydatnymi stronami, zamiast pozwalać je wyprzedzić na skróty. Mocniejszym powodem do poprawy jest odwiedzający: wolne menu albo zamrożony przycisk „Dodaj do koszyka” odczuwa się przy każdym wyświetleniu strony.

Ten przewodnik uzupełnia nasz przewodnik po Core Web Vitals 2026 i wyjaśnia, jak liczony jest INP, co spowalnia każdą fazę interakcji na typowej stronie WordPress, jak znaleźć winny skrypt za pomocą Long Animation Frames oraz które API WordPressa w tym pomagają.

#Czym jest INP i kiedy zastąpił FID

INP stał się stabilnym wskaźnikiem Core Web Vitals 12 marca 2024 roku, zastępując First Input Delay (FID). Wpis na web.dev zapowiadający zmianę dawał deweloperom czas do 9 września 2024 roku na przeniesienie kodu, który odczytywał FID z API CrUX lub PageSpeed Insights. Po tej dacie dostępność FID nie była już gwarantowana. PageSpeed Insights ocenia dziś w sekcji Core Web Vitals INP zamiast FID.

Obie metryki różnią się zakresem. FID mierzył wyłącznie opóźnienie wejściowe pierwszej interakcji na stronie. INP obserwuje pełne opóźnienie (opóźnienie wejściowe, przetwarzanie i prezentację) każdego kliknięcia, dotknięcia i naciśnięcia klawisza w trakcie całej wizyty. Strona, która ładuje się dobrze, ale dławi się przy trzeciej interakcji, przestaje więc przechodzić ocenę.

#Jak liczony jest wskaźnik INP

Definicja INP na web.dev wyznacza trzy progi, oceniane na 75. percentylu wczytań strony, osobno dla urządzeń mobilnych i komputerów:

Wartość INP	Ocena
200 ms lub mniej	Dobra
Powyżej 200 ms do 500 ms	Wymaga poprawy
Powyżej 500 ms	Słaba

Dla każdego wyświetlenia strony przeglądarka zapisuje opóźnienie każdej zaobserwowanej interakcji. Raportowany INP to najdłuższa z nich, z jedną regułą dla bardzo intensywnie używanych stron: na każde 50 interakcji pomijana jest jedna najwyższa. Większość wyświetleń ma mniej niż 50 interakcji, więc w praktyce najgorsza interakcja zwykle staje się INP danej wizyty. Jeśli zbierasz INP samodzielnie w JavaScripcie, web.dev sugeruje brać 98. percentyl interakcji w momencie opuszczania strony, co w przybliżeniu odwzorowuje tę samą regułę.

Liczą się tylko kliknięcia myszą, dotknięcia ekranu i naciśnięcia klawiszy. Najechanie kursorem, przewijanie i powiększanie nie są obserwowane, choć kliknięcie lub naciśnięcie klawisza w trakcie tych gestów już tak. Ma to praktyczną konsekwencję: strona może w ogóle nie mieć wartości INP. Dzieje się tak, gdy odwiedzający nic nie klika, nie dotyka ekranu i nie pisze, gdy tylko przewija albo gdy wizyta pochodzi od bota, na przykład robota wyszukiwarki, który nie został zaprogramowany do interakcji. Wpis na blogu, który większość czytelników tylko przewija, często ma skromniejsze dane INP niż strona produktu z wyborem wariantu.

#Jakie są trzy fazy INP

Każda interakcja mierzona przez INP jest sumą trzech części, opisanych w przewodniku web.dev po optymalizacji INP:

Opóźnienie wejściowe (input delay): od chwili, gdy użytkownik rozpoczyna interakcję, do momentu, w którym zaczyna działać pierwsza funkcja obsługi zdarzenia. Rośnie, gdy główny wątek jest zajęty czymś innym, na przykład parsowaniem skryptu, uruchomionym timerem albo obsługą poprzedniej interakcji.
Czas przetwarzania (processing duration): czas wykonania wszystkich funkcji obsługi zdarzeń dla tej interakcji.
Opóźnienie prezentacji (presentation delay): od zakończenia tych funkcji do chwili, gdy przeglądarka wyrenderuje kolejną klatkę, w tym ponowne obliczenie stylów, układ i malowanie.

Aby uzyskać ocenę „Dobra”, każda interakcja, od kliknięcia w menu nawigacji po naciśnięcie klawisza w polu wyszukiwania, musi zakończyć się wizualnie w 200 ms lub szybciej. Naprawienie jednej wolnej interakcji często odsłania kolejną, dlatego optymalizację INP warto traktować jako powtarzaną pętlę, a nie jednorazowe zadanie.

#Jak zmniejszyć opóźnienie wejściowe w WordPressie

Opóźnienie wejściowe zwykle wynika z tego, że główny wątek jest zajęty w chwili, gdy użytkownik próbuje kliknąć. Na stronach WordPress najczęstsze źródła to wykonywanie skryptów podczas ładowania (parsowanie, kompilacja i uruchamianie JavaScriptu wtyczek i motywu) oraz skrypty zewnętrzne, które cyklicznie wykonują pracę bez względu na działania użytkownika.

#Jak oddać główny wątek za pomocą scheduler.yield()

Artykuł web.dev o długich zadaniach definiuje długie zadanie jako każde zadanie trwające ponad 50 ms. Rozwiązaniem jest podzielenie długiej pracy JavaScriptu na mniejsze zadania, tak aby przeglądarka mogła obsłużyć interakcję pomiędzy nimi. scheduler.yield() zwraca obietnicę rozwiązywaną w nowym zadaniu, a jej kontynuacja ma priorytet: reszta Twojej pracy wznawia się przed innymi zakolejkowanymi zadaniami tego samego rodzaju, więc skrypt zewnętrzny nie wciśnie się między Twoje porcje.

Liczy się tu wsparcie przeglądarek. scheduler.yield() jest dostępne w Chrome 129, Edge 129 i Firefoksie 142, a Safari go nie obsługuje. web.dev zaleca rozwiązanie zastępcze z setTimeout(), które nadal oddaje wątek, tylko bez priorytetowej kontynuacji:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processLargeList(items) {
  for (const item of items) {
    expensiveOperation(item);
    await yieldToMain();
  }
}

Starsze poradniki uzależniają oddawanie wątku od navigator.scheduling.isInputPending(). web.dev nie zaleca już tego API: może zwrócić false tuż po interakcji użytkownika, a dane wejściowe nie są jedynym powodem, by oddać wątek, bo animacje i inne aktualizacje renderowania też go potrzebują. Oddawaj wątek niezależnie od oczekujących zdarzeń.

#Jak usunąć nieużywany JavaScript w WordPressie

Ładować powinien się tylko JavaScript potrzebny w bieżącym widoku. Jeśli użytkownik czyta wpis na blogu, nie ma powodu, by na stronie była biblioteka obsługująca zamówienie. Warunkowe ładowanie zasobów, według szablonu lub bloku, to pierwsza rzecz, którą sprawdzamy w audycie INP strony WordPress, bo kod, który się nie załaduje, nigdy nie zablokuje interakcji. Więcej na ten temat w naszym przewodniku jak przyspieszyć stronę WordPress.

#Jak odroczyć skrypty strategią ładowania z WordPressa 6.3

WordPress 6.3 dodał strategię ładowania do wp_register_script() i wp_enqueue_script(), opisaną w notatce Make WordPress Core o async i defer. Piąty parametr przyjmuje teraz tablicę z dwoma kluczami, strategy (defer lub async) i in_footer:

wp_enqueue_script(
  'wppoland-filters',
  get_theme_file_uri( 'assets/filters.js' ),
  array(),
  '1.4.2',
  array(
    'strategy'  => 'defer',
    'in_footer' => true,
  )
);

Strategia jest prośbą, a nie gwarancją. WordPress sprawdza drzewo zależności: odroczony skrypt, od którego zależy skrypt blokujący, sam staje się blokujący, aby zachować kolejność wykonania. Skrypt inline dodany z pozycją after również przywraca swojemu skryptowi nadrzędnemu tryb blokujący, a ta zmiana może przenieść się dalej po drzewie. Dlatego po przełączeniu motywu lub wtyczki na defer zajrzyj do źródła strony i upewnij się, że atrybut rzeczywiście tam jest. Ta sama notatka zaleca zastąpienie starych obejść opartych na filtrze script_loader_tag właśnie tym API.

#Jak skrócić czas przetwarzania w INP

Tu sprawdza się wydajność Twojego własnego kodu. Ogólna rada web.dev brzmi: w funkcjach obsługi zdarzeń wykonuj jak najmniej pracy.

#Jak pisać lekkie funkcje obsługi zdarzeń

Unikaj złożonej logiki w obsłudze kliknięć. Zaktualizuj tę część interfejsu, na którą czeka użytkownik, potem oddaj wątek, a resztę uruchom w późniejszym zadaniu. Przykład web.dev dotyczy pola tekstowego: wpisany znak pojawia się od razu, a liczenie słów, sprawdzanie pisowni i zapis są odraczane przez requestAnimationFrame() z setTimeout() w środku, więc wykonują się po wyrenderowaniu następnej klatki.

button.addEventListener('click', () => {
  const price = calculatePrice(product, variant);
  priceElement.textContent = formatPrice(price);

  requestAnimationFrame(() => {
    setTimeout(() => {
      sendAnalytics('price_calculated', price);
      saveCartDraft(product, price);
    }, 0);
  });
});

Widoczna zmiana zachodzi w funkcji obsługi, a analityka i zapis czekają, aż klatka z nową ceną zostanie wyrenderowana.

#Jak uniknąć layout thrashingu

Layout thrashing, nazywany też wymuszonym synchronicznym układem, występuje, gdy kod zmienia style, a potem w tym samym zadaniu odczytuje właściwość układu, na przykład offsetWidth. Przeglądarka musi wtedy przeliczyć układ natychmiast, a nie raz na końcu klatki, a w pętli dzieje się to przy każdej iteracji. Najpierw odczytaj wszystkie wartości, potem zapisuj:

// Wymusza układ przy każdej iteracji: unikaj
elements.forEach((el) => {
  const width = el.offsetWidth;
  el.style.width = width + 10 + 'px';
});

// Najpierw odczyty, potem zapisy
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
  el.style.width = widths[i] + 10 + 'px';
});

#Jak przenieść skrypty zewnętrzne poza główny wątek

Mniej istotne skrypty zewnętrzne, takie jak widżety czatu i tagi analityczne, można przenieść do Web Workera za pomocą biblioteki w rodzaju Partytown, dzięki czemu przestają konkurować z funkcjami obsługi zdarzeń o główny wątek. Nie nadaje się to do każdego skryptu, bo niektóre tagi potrzebują synchronicznego dostępu do DOM. Kompromisy, w tym to, które tagi przestają działać w workerze, opisujemy w przewodniku o ograniczaniu wpływu skryptów zewnętrznych na WordPress.

#Jak obsłużyć długie listy

Na stronach z długimi listami, takich jak archiwa bloga, strony kategorii WooCommerce czy tabele danych, renderowanie setek elementów od razu sprawia, że każda późniejsza interakcja płaci za duży DOM. Wirtualizacja renderuje tylko elementy w pobliżu widocznego obszaru i tworzy oraz usuwa je w miarę przewijania. Paginacja lub przyciski „Wczytaj więcej” osiągają ten sam cel przy mniejszej ilości JavaScriptu.

#Jak naprawić opóźnienie prezentacji

Nawet gdy Twój kod kończy się szybko, przeglądarka może mieć kłopot z wyrenderowaniem wyniku, jeśli DOM jest duży albo przeliczanie stylów jest kosztowne.

#Jak rozmiar DOM wpływa na INP

web.dev zauważa, że praca związana z renderowaniem rośnie wraz z rozmiarem DOM, choć nie liniowo, a duży DOM spowalnia zarówno pierwsze renderowanie, jak i renderowanie po każdej interakcji. Są dwie możliwości: spłaszczyć DOM, co w WordPressie zwykle oznacza mniej elementów opakowujących z motywu lub page buildera, oraz dodawać węzły dopiero wtedy, gdy interakcja ich potrzebuje, zamiast renderować z góry każdą zakładkę, okno modalne i mega menu.

#Jak używać content-visibility i contain

content-visibility: auto pozwala przeglądarce pominąć układ i malowanie elementu, dopóki nie zbliży się on do widocznego obszaru. Według artykułu web.dev o content-visibility w demonstracyjnym blogu podróżniczym początkowy czas renderowania spadł z 232 ms do 30 ms, a właściwość ma status Baseline newly available od 15 września 2025 roku (Chrome 85, Firefox 125, Safari 18). Połącz ją z contain-intrinsic-size, aby pomijane sekcje zachowały zastępczą wysokość; słowo kluczowe auto sprawia, że przeglądarka zapamiętuje ostatnio wyrenderowany rozmiar:

.comments-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 2000px;
}

.sidebar {
  contain: layout style paint;
}

Właściwość contain na niezależnych sekcjach, takich jak pasek boczny czy blok komentarzy, informuje przeglądarkę, że zmiana w ich wnętrzu nie wpłynie na resztę strony. Ogranicza to obszar, który trzeba przeliczyć przed kolejnym malowaniem.

#Dlaczego renderowanie HTML po stronie klienta wydłuża opóźnienie prezentacji

Gdy HTML jest przesyłany strumieniowo z serwera, przeglądarka parsuje go porcjami i oddaje wątek między nimi. Gdy skrypt buduje duże ilości HTML po stronie klienta, przeglądarka nie oddaje wątku, dopóki ten HTML nie zostanie sparsowany i wyrenderowany, co może opóźnić następną klatkę. W WordPressie widać to w filtrach AJAX i przyciskach „Wczytaj więcej”, które wstrzykują naraz duży ciąg HTML. Wstawianie mniejszych porcji, z oddaniem wątku pomiędzy nimi, skraca klatkę po kliknięciu.

#Co powoduje słaby wynik INP w WordPressie

To winowajcy, których spotykamy najczęściej, gdy strona WordPress nie przechodzi oceny INP. Żaden z nich nie jest wyłączną przypadłością WordPressa, ale wtyczki pozwalają zainstalować je niepostrzeżenie.

#Ciężkie page buildery

Divi i Elementor często dodają głębokie zagnieżdżenie DOM, z kilkoma elementami opakowującymi wokół każdego widżetu, co spowalnia przeliczanie układu po interakcji. Sprawdź głębokość w panelu Elements w DevTools przed zastąpieniem sekcji natywnymi blokami i po nim.

#Widżety czatu

Większość skryptów czatu na żywo mocno obciąża główny wątek: ładują się i zaczynają pracę na każdej stronie. Wzorzec click-to-load, w którym lekki przycisk ładuje właściwy widżet dopiero wtedy, gdy użytkownik prosi o pomoc, usuwa tę pracę ze stron, na których nikt nie czatuje.

#Automatycznie przewijane slidery

Przejścia uruchamiane co kilka sekund mogą zbiec się z kliknięciami użytkownika. Jeśli przeglądarka jest w trakcie przejścia slidera, gdy użytkownik dotyka linku w menu, interakcja musi poczekać na tę pracę, co widać jako opóźnienie wejściowe.

#Skrypty WooCommerce poza sklepem

Fragmenty koszyka i inne skrypty sklepu mogą ładować się na stronach bez żadnych funkcji sklepowych, na przykład we wpisach na blogu. Sprawdź, które skrypty WooCommerce dołącza każdy szablon, a poprawki typowe dla sklepów znajdziesz w naszym przewodniku po wydajności WooCommerce.

#Osadzone Mapy Google

Osadzona Mapa Google ładuje sporo JavaScriptu i utrzymuje aktywne nasłuchiwacze zdarzeń. Statyczny obraz, który ładuje interaktywną mapę po kliknięciu, oszczędza ten koszt odwiedzającym, którzy z mapy nie korzystają.

#Najlepsze narzędzia do pomiaru INP w 2026

Aby naprawić INP, potrzebujesz danych od prawdziwych użytkowników i sposobu na odtworzenie wolnej interakcji w warunkach laboratoryjnych.

#CrUX API i PageSpeed Insights

Dokumentacja CrUX API opisuje dane jako 28-dniową średnią kroczącą, aktualizowaną codziennie około 04:00 UTC i opóźnioną o mniej więcej dwa dni względem bieżącej daty. Każda metryka ma histogram i wartość p75, a dane można filtrować według PHONE, DESKTOP lub TABLET. Dane pochodzą wyłącznie od użytkowników Chrome na komputerach i Androidzie, którzy wyrazili na to zgodę, więc Chrome na iOS i inne przeglądarki oparte na Chromium, takie jak Edge, nie są w nich uwzględnione. Strony o małym ruchu często nie mają rekordu na poziomie strony i korzystają z danych dla całej domeny (origin). PageSpeed Insights i raport Core Web Vitals w Search Console pokazują te same dane terenowe.

#Jak znaleźć wolny skrypt za pomocą Long Animation Frames (LoAF)

Long Animation Frames API pojawiło się w Chrome 123. Raportuje każdą klatkę, której aktualizacja renderowania opóźnia się o ponad 50 ms, i w odróżnieniu od Long Tasks API grupuje pracę według klatek, co odpowiada temu, jak odczuwa się INP. Long Tasks nie znika: Chrome deklaruje, że nie planuje go wycofywać, ale LoAF daje znacznie lepszą atrybucję. Każdy wpis zawiera duration, blockingDuration, renderStart, styleAndLayoutStart i tablicę scripts. Skrypty dłuższe niż 5 ms dostają atrybucję z sourceURL, sourceFunctionName, invokerType i forcedStyleAndLayoutDuration, co często wystarcza, by wskazać winną wtyczkę.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('LoAF', entry.duration, entry.blockingDuration,
      entry.scripts.map((s) => ({
        sourceURL: s.sourceURL,
        sourceFunctionName: s.sourceFunctionName,
        duration: s.duration,
        forcedLayout: s.forcedStyleAndLayoutDuration,
      })));
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

LoAF jest obsługiwane w Chrome i Edge. Firefox i Safari go nie udostępniają, więc dane atrybucji z monitoringu terenowego będą pochodzić wyłącznie z przeglądarek opartych na Chromium.

#Dane terenowe z wersją attribution biblioteki web-vitals

Biblioteka web-vitals ma wersję attribution, która mówi, dlaczego interakcja była wolna. Przewodnik web.dev o wyszukiwaniu wolnych interakcji w terenie wymienia pola: interactionTarget (selektor CSS elementu), interactionType, inputDelay, processingDuration, presentationDelay oraz, od wersji 4, longAnimationFrameEntries. Wysyłaj je do swojego punktu analitycznego przez sendBeacon:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  navigator.sendBeacon('/analytics', JSON.stringify({
    value,
    rating,
    target: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
  }));
});

Podział na fazy wskazuje, gdzie szukać: duże opóźnienie wejściowe oznacza pracę wykonywaną przed kliknięciem, długi czas przetwarzania wskazuje na Twoje funkcje obsługi zdarzeń, a duże opóźnienie prezentacji na rozmiar DOM i renderowanie.

#Rozszerzenie Web Vitals i DevTools

Rozszerzenie Web Vitals i panel Performance w Chrome DevTools pokazują INP każdej interakcji w chwili, gdy ją wykonujesz. Klikaj każdy przycisk, link i pole formularza w kluczowych szablonach i obserwuj wartości. Testy laboratoryjne na szybkim laptopie zaniżają opóźnienia na telefonach, więc odtwarzając wolną interakcję zgłoszoną z danych terenowych, włącz w DevTools spowolnienie procesora. Ograniczenia specyficzne dla urządzeń mobilnych omawiamy w przewodniku po strategiach wydajności mobile-first.

#Jak poprawić INP w WordPressie krok po kroku

#Krok 1: audyt stanu wyjściowego

Pobierz dane CrUX dla swojej domeny i głównych szablonów (strona główna, wpis na blogu, produkt, kategoria) i zanotuj INP osobno dla telefonów i komputerów. Zacznij od szablonów z najgorszą wartością p75 i wystarczającym ruchem, by miało to znaczenie.

#Krok 2: znalezienie wolnych interakcji

Dodaj do strony wersję attribution biblioteki web-vitals albo użyj powyższego obserwatora LoAF i zbieraj interactionTarget oraz podział na fazy dla wolnych interakcji. Dzięki temu ogólne wrażenie, że strona działa wolno, zamienia się w listę konkretnych elementów.

#Krok 3: inwentaryzacja skryptów

Spisz wszystkie skrypty ładowane w każdym szablonie. Przy każdym zanotuj, czy jest potrzebny w tym szablonie, czy może korzystać ze strategii defer, czy może ładować się dopiero przy interakcji oraz czy da się go przenieść do workera albo usunąć.

#Krok 4: dzielenie długich zadań

W skryptach, którym LoAF przypisuje wolne klatki, dziel długie zadania za pomocą scheduler.yield() i rozwiązania zastępczego z setTimeout(), zaczynając od pracy wykonywanej w trakcie interakcji lub tuż po niej.

#Krok 5: ograniczenie kosztu DOM i renderowania

Spłaszcz najgłębsze sekcje, dodaj content-visibility: auto do długich obszarów poniżej pierwszego ekranu i rozważ zastąpienie sekcji z page buildera natywnymi blokami Gutenberga tam, gdzie DOM jest najgłębszy.

#Krok 6: stały monitoring

Utrzymuj monitoring terenowy także po wprowadzeniu poprawek. CrUX potrzebuje 28 dni, by w pełni odzwierciedlić zmianę, więc porównuj własne dane terenowe tydzień po tygodniu i ustaw alert, gdy INP na p75 przekroczy 200 ms.

#Usługi optymalizacji INP w WPPoland

W WPPoland specjalizujemy się w metryce wydajności, która stawia człowieka na pierwszym miejscu.

Refaktoryzacja JavaScriptu: przepisujemy rozdęty kod wtyczek na lekkie zamienniki, które zachowują funkcje bez zbędnego ciężaru.
Diagnostyka LoAF: korzystamy z telemetrii terenowej z atrybucją LoAF, aby wskazać skrypt i funkcję powodujące opóźnienie.
Projektowanie interaktywności: dbamy o to, by widoczna reakcja na kliknięcie następowała jako pierwsza, a wszystko inne czekało na wyrenderowanie klatki.

#Podsumowanie optymalizacji INP

Core Web Vitals dotyczą tego, jak użytkownik odczuwa kontakt z Twoją marką. Interaction to Next Paint to metryka zaufania. Gdy strona reaguje natychmiast, użytkownik ma poczucie kontroli. Gdy się zacina, wydaje się zepsuta, a na telefonie menu, które nie reaguje, często bywa traktowane jak zepsute. Żadne opublikowane badanie nie wiąże progu INP ze stałym odsetkiem odrzuceń czy konwersji, więc zmierz własne wyniki przed zmianami i po nich.

Twoja strona na WordPressie działa ociężale? Skontaktuj się z WPPoland, a zdiagnozujemy INP i naprawimy interakcje, które go zawyżają.