Optymalizacja INP w 2026: scheduler.yield, dzielenie zadań i strategie poniżej 200 ms

Zaktualizowano: 22 czerwca 2026

Optymalizacja INP (Interaction to Next Paint) w 2026 roku polega na utrzymaniu czasu reakcji interfejsu poniżej 200 ms poprzez agresywne dzielenie długich zadań JavaScript, użycie API scheduler.yield() oraz przeniesienie ciężkich obliczeń poza główny wątek. W przeciwieństwie do FID, INP mierzy najwolniejszą interakcję na całej stronie, więc pojedyncze niezoptymalizowane zdarzenie potrafi zepsuć wyniki Core Web Vitals całej witryny. W tym przewodniku pokażę techniki, które sam stosowałem w produkcji, żeby zbić INP z ponad 600 ms do okolic 150 ms.

• INP zastąpił FID jako Core Web Vital w marcu 2024. Próg "Good" wynosi ≤200 ms, a "Poor" zaczyna się od 500 ms.
• API scheduler.yield() jest dostępne w Chrome 129+ i pozwala ustąpić głównemu wątkowi bez przeciągania zadania na koniec kolejki.
• Najczęstsze przyczyny wysokiego INP to ciężkie handlery zdarzeń, synchroniczna hydratacja React oraz skrypty firm trzecich blokujące główny wątek.
• Long Animation Frames API (LoAF) zastąpiło Long Tasks API jako standardowe narzędzie atrybucji opóźnień INP w produkcji.
• React 19 startTransition i useDeferredValue to wbudowane mechanizmy ustępowania, ale nie zastąpią ręcznego yieldingu w handlerach.
• Pomiar INP w polu (CrUX, biblioteka web-vitals) to jedyne źródło prawdy. Testy laboratoryjne często fałszywie zaniżają wyniki.

Czym jest INP i dlaczego jest ważny w 2026?

INP (Interaction to Next Paint) to metryka Core Web Vital, która mierzy opóźnienie między interakcją użytkownika (kliknięciem, dotknięciem lub naciśnięciem klawisza) a najbliższym malowaniem ramki wizualnej odzwierciedlającej skutek tej akcji. Google promował INP do statusu stabilnej metryki Core Web Vital w marcu 2024 roku, zastępując FID (First Input Delay), który mierzył tylko opóźnienie pierwszej interakcji i był łatwy do "oszukania" przez strony z lekkim początkowym ładowaniem, ale ciężkimi późniejszymi działaniami.

W praktyce INP raportuje 98 percentyl wszystkich interakcji w sesji, więc pojedyncze powolne kliknięcie w menu albo w rozwijane filtry produktów potrafi zepsuć ogólny wynik witryny. Według raportu HTTP Archive z Q1 2026, mediana INP na urządzeniach mobilnych w sklepach e-commerce wynosi 287 ms, czyli znacznie powyżej progu "Good" wynoszącego 200 ms. Witryny edytorialne (blogi, portale) osiągają medianę 178 ms, ponieważ mają mniej złożonych interakcji.

Co ważne, INP ma bezpośredni wpływ na pozycjonowanie organiczne. Od czerwca 2024 stanowi część oficjalnego zestawu Core Web Vitals używanego przez Google do oceny doświadczenia strony (Page Experience signal). Witryny w grupie "Poor INP" (>500 ms) notują mierzalny spadek CTR w wynikach wyszukiwania na zapytania konkurencyjne.

Jaki jest dobry wynik INP?

Próg "Good" dla INP wynosi 200 ms lub mniej, "Needs Improvement" mieści się w przedziale 200-500 ms, a "Poor" zaczyna się od 500 ms wzwyż. Te progi obowiązują dla 75 percentyla użytkowników z pola (CrUX), nie dla pomiarów laboratoryjnych. Oznacza to, że aby zaliczyć Core Web Vitals, co najmniej 75% sesji musi mieć INP ≤200 ms na obu typach urządzeń (desktop i mobile), bo Google ocenia je osobno.

Skąd akurat 200 ms? Z badań UX zespołu Chrome, które wykazały, że opóźnienia powyżej tej wartości są subiektywnie odbierane jako "zacinanie się" interfejsu, nawet jeśli użytkownik nie potrafi tego wprost wyartykułować. Jeśli aplikacja na 60 Hz wyświetlaczu ma 16,67 ms na ramkę, INP poniżej 200 ms gwarantuje, że odpowiedź pojawi się w ciągu maksymalnie 12 ramek od interakcji. Większość użytkowników odbiera to jako "płynne".

Warto pamiętać, że 200 ms to budżet całościowy obejmujący trzy fazy: input delay (czas oczekiwania zdarzenia w kolejce), processing time (wykonanie wszystkich handlerów) i presentation delay (renderowanie i malowanie wyniku). W większości realnych przypadków największy udział mają processing time i presentation delay; input delay rośnie tylko przy aktywnych długich zadaniach w tle.

Dlaczego mój INP jest wysoki? Najczęstsze przyczyny

W praktyce produkcyjnej wysoki INP najczęściej wynika z pięciu kategorii problemów: synchroniczna hydratacja po stronie klienta we frameworkach SSR (Next.js, Nuxt, SvelteKit), ciężkie handlery onClick wykonujące walidację, mutacje stanu lub zapisy do localStorage, skrypty śledzące i reklamowe trzecich stron rejestrujące własne nasłuchiwacze zdarzeń, długie operacje na DOM po zmianie stanu (np. rerenderowanie listy 1000+ elementów), oraz blokujące zadania w głównym wątku wywoływane przez requestAnimationFrame.

Szczerze mówiąc, w jednym z moich audytów dla sklepu e-commerce odkryłem, że INP 720 ms na kliknięciu "Dodaj do koszyka" wynikał z synchronicznego wywołania trzech tagów Google Tag Manager, które łącznie blokowały główny wątek na ponad 450 ms. Przeniesienie ich do Partytown z Web Workers obniżyło INP do 160 ms, bez zmiany jakiejkolwiek logiki biznesowej.

Druga częsta przyczyna to "kaskadowy state update" w React, gdzie pojedyncze kliknięcie wyzwala kilka setState, a każdy z nich rerendują drzewo komponentów. Bez useTransition lub startTransition React 18+ wykonuje wszystkie aktualizacje synchronicznie, blokując ramkę. Atrybucja przez Long Animation Frames API (LoAF) pokazuje wówczas dokładnie, który skrypt i która funkcja zajęła czas.

scheduler.yield(): nowoczesny sposób ustępowania głównemu wątkowi

API scheduler.yield(), dostępne w Chrome 129+ i Edge 129+ (od września 2025 jako Baseline Newly Available), to obietnica, która oddaje kontrolę głównemu wątkowi i wraca z najwyższym priorytetem natychmiast po obsłudze oczekujących zdarzeń wejściowych. To kluczowa różnica względem klasycznego setTimeout(fn, 0) lub await new Promise(r => setTimeout(r, 0)), które trafiają na koniec kolejki zadań i mogą zostać znacząco opóźnione przez inne timery.

Podstawowy wzorzec użycia w długim handlerze wygląda tak:

async function processItems(items) {
  for (const item of items) {
    processItem(item);

    // Ustąp wątkowi co 50 ms (próg "long task")
    if (performance.now() - lastYield > 50) {
      if ('scheduler' in window && 'yield' in scheduler) {
        await scheduler.yield();
      } else {
        // Fallback dla starszych przeglądarek
        await new Promise(r => setTimeout(r, 0));
      }
      lastYield = performance.now();
    }
  }
}

Ważne: scheduler.yield() zachowuje priorytet zadania (np. 'user-blocking', jeśli zostało zainicjowane przez interakcję), co oznacza, że po ustąpieniu wraca przed innymi oczekującymi zadaniami niższego priorytetu. To zachowanie nazywane jest "inheritance" i jest opisane w dokumentacji Chrome dla Scheduler API.

Dla bardziej skomplikowanych przypadków warto połączyć scheduler.yield() z scheduler.postTask(), który pozwala na jawne ustawienie priorytetu ('user-blocking', 'user-visible', 'background') i kolejkowanie pracy w tle bez blokowania interakcji.

Jak naprawić wysoki INP poprzez dzielenie długich zadań

Każde zadanie JavaScript dłuższe niż 50 ms jest klasyfikowane jako Long Task i automatycznie pogarsza INP, jeśli wystąpi podczas obsługi interakcji. Strategia polega na rozbiciu monolitycznej funkcji na mniejsze fragmenty z punktami ustępowania pomiędzy nimi. Klasyczny problem to przetwarzanie 5000 elementów koszyka w jednym tick'u. Refactor polega na batch'owaniu po 50-100 elementów i wywołaniu await scheduler.yield() między batchami.

Konkretny przykład, czyli optymalizacja sortowania dużej tabeli produktów:

async function sortAndRenderLargeList(items, comparator) {
  // 1. Najpierw pokaż użytkownikowi sygnał wizualny natychmiast
  showLoadingState();
  await scheduler.yield(); // pozwól na malowanie loadera

  // 2. Sortowanie batch'ami po 200 elementów
  const BATCH_SIZE = 200;
  const sorted = [];
  let lastYield = performance.now();

  for (let i = 0; i < items.length; i += BATCH_SIZE) {
    const batch = items.slice(i, i + BATCH_SIZE);
    sorted.push(...batch.sort(comparator));

    if (performance.now() - lastYield > 50) {
      await scheduler.yield();
      lastYield = performance.now();
    }
  }

  // 3. Renderuj w wirtualnym oknie zamiast całej listy naraz
  renderVirtualizedList(sorted);
  hideLoadingState();
}

Druga skuteczna technika to debouncing handlerów input. Pole wyszukiwania, które wykonuje filter na 10 000 produktach przy każdym znaku, ma katastrofalny INP. Dodanie 150 ms debounce'a redukuje liczbę wykonań filtra o około 80%, a perceptualnie nie pogarsza UX (i tak czekamy na zakończenie wpisywania).

Optymistyczne UI i wizualne potwierdzenia

INP mierzy czas do pierwszej zmiany wizualnej, nie do zakończenia całej logiki. Oznacza to, że nawet jeśli operacja musi wykonać 300 ms pracy w tle, możesz osiągnąć doskonały INP poprzez natychmiastowe pokazanie wizualnego potwierdzenia interakcji. To zasada "optymistycznego UI": przyciski powinny zmienić stan wizualny (loader, animacja, zmiana koloru) w pierwszej ramce po kliknięciu, a właściwa praca wykonuje się asynchronicznie.

Wzorzec implementacji dla przycisku "Dodaj do koszyka" wygląda tak:

button.addEventListener('click', async (event) => {
  // KROK 1: Natychmiastowy feedback wizualny (mniej niż 1 ramka)
  button.classList.add('is-loading');
  button.disabled = true;

  // KROK 2: Ustąp wątkowi, aby ramka się wyrenderowała
  await scheduler.yield();

  // KROK 3: Teraz wykonaj ciężką pracę
  await addToCart(productId);
  await trackAnalytics('add_to_cart', productId);
  await updateMiniCart();

  button.classList.remove('is-loading');
  button.disabled = false;
});

Liczby mówią same za siebie. W jednym z naszych projektów ta zmiana obniżyła P75 INP z 480 ms do 130 ms, przy identycznej całkowitej pracy. Z perspektywy użytkownika interakcja "kończy się" w momencie zobaczenia loadera, a nie w momencie aktualizacji koszyka.

Strategie INP dla React 19, Vue i Svelte

React 19, wydany w grudniu 2024, wprowadza Server Components i poprawiony useTransition, który jest natywnym mechanizmem ustępowania głównemu wątkowi. Kod opakowany w startTransition jest oznaczany jako "non-urgent" i React może go przerwać, jeśli przyjdzie nowa interakcja użytkownika.

// React 19 — non-blocking update
import { startTransition, useDeferredValue } from 'react';

function ProductSearch() {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);
  const results = useMemo(
    () => filterLargeCatalog(deferredQuery),
    [deferredQuery]
  );

  return (
    <input
      onChange={e => {
        // Pilne: aktualizuj wartość input natychmiast
        setQuery(e.target.value);
        // Mniej pilne: filtrowanie może czekać
        startTransition(() => {
          analytics.track('search', e.target.value);
        });
      }}
    />
  );
}

W Vue 3.5+ analogicznym mechanizmem jest defineAsyncComponent z opcją suspensible. W Svelte 5 nowa składnia runes ($state, $derived) automatycznie batchuje aktualizacje, ale dla ciężkich kalkulacji warto użyć $effect.pre z ręcznym yieldingiem.

Dla projektów wykorzystujących optymalizację bundle'a JavaScript kluczowe jest wczesne ładowanie kodu krytycznego dla interakcji (event handlery, walidacja formularzy) i opóźnione ładowanie kodu pomocniczego (analityka, czat support). Code-splitting na granicy interakcji jest skuteczniejszy niż code-splitting na granicy route'ów.

Jak zmierzyć INP w polu produkcyjnym

Pomiar INP w środowisku laboratoryjnym (Lighthouse, WebPageTest) ma ograniczoną wartość, ponieważ wymaga symulowania realnych interakcji użytkownika, czego narzędzia syntetyczne robią bardzo niedoskonale. Złotym standardem jest pomiar w polu, używając biblioteki web-vitals od Google Chrome w wersji 5.x lub nowszej.

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

onINP((metric) => {
  // metric.value zawiera czas INP w ms
  // metric.attribution zawiera szczegóły:
  //   - eventTarget: selektor CSS elementu
  //   - eventType: 'click', 'pointerdown', itd.
  //   - loafScripts: tablica skryptów LoAF, które blokowały wątek
  //   - longestScript: najgorszy skrypt z atrybucją URL

  navigator.sendBeacon('/rum', JSON.stringify({
    metric: 'INP',
    value: metric.value,
    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
    target: metric.attribution.eventTarget,
    loaf: metric.attribution.longestScript?.sourceURL,
    page: location.pathname,
  }));
}, { reportAllChanges: false });

Biblioteka web-vitals automatycznie integruje się z Long Animation Frames API (LoAF), co daje atrybucję na poziomie konkretnego skryptu, funkcji i URL. To informacje wystarczające do natychmiastowego namierzenia problemu. Dane warto agregować w dedykowanym dashboardzie RUM (Grafana, Datadog RUM, Sentry Performance) z segmentacją po typie urządzenia, połączeniu sieciowym i route'cie.

Dodatkowo CrUX (Chrome User Experience Report) udostępnia historyczne dane INP per URL przez PageSpeed Insights API i CrUX API. Te dane są oficjalnym źródłem oceny przez Google i powinny być monitorowane co najmniej raz w tygodniu jako sygnał trendu.

Często zadawane pytania

Czy INP zastąpił FID na stałe?

Tak. Od 12 marca 2024 INP zastąpił FID jako oficjalna metryka Core Web Vital. FID nie jest już raportowany w CrUX ani używany w Page Experience Signal Google.

Ile interakcji jest brane pod uwagę przy obliczaniu INP?

INP raportuje 98 percentyl interakcji na stronie. Dla stron z mniej niż 50 interakcjami zwracana jest najwolniejsza z nich; dla stron z większą liczbą interakcji odrzucane jest około 2% najwolniejszych (jedna na 50) jako outliers.

Czy scheduler.yield() działa we wszystkich przeglądarkach?

Nie. Na czerwiec 2026 scheduler.yield() jest dostępne w Chrome 129+, Edge 129+ i Opera 115+. Firefox i Safari jeszcze go nie wdrożyły, dlatego zawsze stosuj feature detection ('scheduler' in window && 'yield' in scheduler) i fallback do setTimeout.

Czy mogę zmierzyć INP w trakcie sesji bez czekania na jej zakończenie?

Tak. Biblioteka web-vitals 4.x+ wspiera tryb reportAllChanges: true, który raportuje każdą interakcję powyżej dotychczasowego maksimum. To pozwala na real-time monitoring bez utraty wczesnych sygnałów ostrzegawczych.

Jak INP różni się od Total Blocking Time (TBT)?

TBT jest metryką laboratoryjną liczoną tylko podczas ładowania strony (między FCP a TTI). INP jest metryką polową obejmującą całe życie strony i mierzy konkretne interakcje, a nie sumę długich zadań. TBT może być dobry, podczas gdy INP jest słaby, i odwrotnie.