INP (Interaction to Next Paint) 2026 — Core Web Vitals guide

INP (Interaction to Next Paint) to metryka Core Web Vitals mierząca opóźnienie reakcji strony na interakcję użytkownika (klik, tap, keypress). Mierzona jest w milisekundach. W marcu 2024 Google zastąpił FID (First Input Delay) przez INP jako ranking signal, bo FID mierzył TYLKO pierwszą interakcję — użytkownicy zazwyczaj wchodzą w interakcję wiele razy (scroll, 3 kliknięcia, 2 submit), każdy z potencjalnym opóźnieniem. INP mierzy NAJGORSZĄ interakcję w sesji, co lepiej odzwierciedla realne UX. FID threshold był <100ms good, <300ms poor. INP jest surowsze: <200ms good, 200-500ms needs improvement, >500ms poor.

INP jest mierzony przez Chrome User Experience Report (CrUX) na podstawie real-user data (RUM — Real User Monitoring) przez 28-dniowe okno. Każda interakcja ma 3 fazy: (1) Input Delay — czas od zdarzenia (click event) do rozpoczęcia handler, (2) Processing Time — czas wykonania handler (React re-render, state update), (3) Presentation Delay — czas od końca handler do paint następnej klatki. INP to suma tych 3 dla najgorszej interakcji (percentyl 98 dla większości URL, lub najgorsza jeśli <50 interakcji). Sprawdzasz INP w: (a) Google Search Console Core Web Vitals report (real user data 28-day), (b) PageSpeed Insights (field data + lab), (c) Chrome DevTools Performance tab (lab test).

5 głównych strategii: (1) BREAK LONG TASKS — każda task >50ms to long task. Rozbij na yieldToMain() lub setTimeout(0). Przykład: sortowanie 10k elementów w 1 synchronous call = 200ms INP. Batch processing 100 elements per frame = 5ms INP. (2) DEBOUNCE/THROTTLE — input event listeners (search, filter) debounce 150-300ms żeby nie triggerować re-render na każdy keystroke. Lodash debounce lub native. (3) WEB WORKERS — offload heavy computation (JSON parsing >5MB, image processing, encryption) do background thread. Main thread free dla UI. (4) REACT OPTIMIZATIONS — useMemo/useCallback dla expensive calculations, React.memo dla components, virtualizacja długich list (react-window). Avoid unnecessary re-renders. (5) LAZY LOADING + CODE SPLITTING — dynamic imports Next.js, lazy images, defer non-critical JS. Smaller bundle = faster execution. BUDZĘCIE: nie wszystkie strony potrzebują <200ms (prosty blog 150ms easily). Problematyczne: e-commerce z filtrami, SPA dashboards, edytory online — wymagają aktywnej optymalizacji.

FID (First Input Delay, 2020-2024) mierzył tylko input delay (fazę 1) pierwszej interakcji. Threshold: <100ms good, <300ms poor. Problem FID: (a) mierzył tylko PIERWSZĄ interakcję, ignorował kolejne (użytkownik klika 5 razy na stronie, tylko 1 raz mierzone), (b) nie mierzył processing time ani presentation delay (całość experience nie odzwierciedlona). INP (Interaction to Next Paint, 2024+) mierzy: (1) processing time + input delay + presentation delay, (2) najgorsza interakcja w całej sesji (percentyl 98). Threshold surowsze: <200ms good, <500ms poor. BOTTOM LINE: INP lepiej odzwierciedla realny UX. Strona która przeszła FID może FAIL INP — bo INP łapie słabe interakcje które FID ignorował. Efekt: 30-40% stron które były "green" pod FID jest teraz "needs improvement" pod INP (Q1 2024 data).

6 narzędzi per use case: (1) GOOGLE SEARCH CONSOLE — Core Web Vitals report, real user data 28 days, best source of truth dla ranking. Free. (2) PAGESPEED INSIGHTS — field data + lab data per page. Pokazuje konkretne rekomendacje. Free. (3) CHROME DEVTOOLS — Performance tab, record interaction, analyze processing time. Real-time debugging. Free. (4) WEB VITALS EXTENSION (Chrome) — live INP metric display while browsing. Free. (5) RUM TOOLS — New Relic, DataDog, Sentry, SpeedCurve — continuous monitoring, alerty. $20-500/mies. (6) LIGHTHOUSE CI — automated testing w CI/CD pipeline, fail build if INP regression. Open source. DEBUGGING WORKFLOW: GSC real user data → identify slow URLs → PageSpeed Insights per URL → Chrome DevTools recording → fix → Lighthouse CI dla regression test.

TAK. Od marca 2024 INP jest w Core Web Vitals ranking signal (razem z LCP i CLS). 30-40% stron straciły "green" status po zmianie FID → INP, co oznacza bezpośredni downgrade rankingu. Dla competitive branż (SaaS, e-commerce) = spadek 2-5 pozycji w SERP. RECOVERY PROCESS: (1) sprawdź GSC Core Web Vitals po URL, (2) priorytetyzuj URL z traffic × INP_poor_score (high traffic + poor INP = high priority), (3) fix per lista optymalizacji (break long tasks, debounce, React memo), (4) deploy + monitoring 28 dni (CrUX window), (5) verify w GSC → "Passed" status. Typical timeline fix → ranking recovery: 4-8 tygodni. DLA STRON PL 2026: WordPress z wieloma wtyczkami często ma INP 300-600ms (poor). Minimal Gutenberg WP + cache = INP 100-200ms (good). Next.js 16 + React 19 native ma INP <100ms dzięki automatic batching.

NEXT.JS 16 + React 19 (current) — native INP <100ms out-of-box dla większości stron dzięki: (1) automatic batching React 18+ — grupuje state updates w 1 render, (2) Concurrent rendering — break long renders on task boundary, (3) Suspense + streaming SSR — incremental hydration, (4) Server Components — mniej JS na klient. Typowa strona GMWEB Next.js: INP 50-150ms. WORDPRESS — INP 200-500ms out-of-box (zależy od themes + plugins). Problemy: (1) Gutenberg z wieloma blokami = ciężkie JS bundle, (2) wtyczki (form builders, page builders Elementor/Divi) dodają 500kb-2MB JS, (3) brak automatic code splitting. Optymalizacja WP: (a) użyj theme Astra/GeneratePress (minimalne JS), (b) page builder ONLY gdy niezbędny (rezygnacja z Divi/Elementor = -1MB JS), (c) cache plugin WP Rocket lub W3 Total Cache, (d) lazy load all images, (e) minify JS/CSS. Dobrze zoptymalizowany WP: INP 150-250ms. Default WP: 400-600ms INP poor. DECYZJA: dla performance-critical sites Next.js wygrywa, dla content-heavy + edit convenience WP z opmitalizacją wystarcza.