Core Web Vitals 2026 – INP zastąpił FID, co to znaczy dla Twojej strony

Od marca 2024 roku Google oficjalnie zastąpił metrykę FID (First Input Delay) nowym wskaźnikiem – INP (Interaction to Next Paint). Zmiana ta weszła w życie jako część Core Web Vitals i bezpośrednio wpływa na ranking stron w wynikach wyszukiwania. Jeśli Twoja strona nie jest zoptymalizowana pod kątem INP, tracisz pozycje w Google – nawet jeśli inne wskaźniki masz w zieleni. Według danych web.dev, tylko ok. 65% stron spełnia próg „dobrego” INP.

W tym artykule wyjaśniamy, czym jest INP, jakie progi obowiązują, jak mierzyć tę metrykę i – co najważniejsze – jak ją poprawić. Stosujemy te techniki w projektach dla klientów z Piaseczna i Warszawy. Jeśli chcesz wiedzieć, czy Twoja strona jest gotowa na wymagania Google 2026, czytaj dalej.

Co się dowiesz:

• Czym różni się INP od FID i dlaczego ta zmiana ma znaczenie
• Jakie progi definiuje Google (dobry / wymaga poprawy / słaby)
• Jak mierzyć INP za pomocą PageSpeed Insights, CrUX i biblioteki web-vitals.js
• 5-7 konkretnych technik optymalizacji, które działają w praktyce
• Odpowiedzi na najczęstsze pytania o Core Web Vitals i INP

Czym jest INP i dlaczego zastąpił FID

FID (First Input Delay) mierzył opóźnienie tylko pierwszej interakcji użytkownika ze stroną – na przykład pierwszego kliknięcia przycisku. Problem polegał na tym, że po tym pierwszym kliknięciu strona mogła reagować fatalnie na kolejne interakcje, a metryka tego w ogóle nie wychwytywała. Google zdawało sobie z tego sprawę od kilku lat.

INP – Interaction to Next Paint – mierzy opóźnienie wszystkich interakcji przez cały czas trwania wizyty na stronie: kliknięcia, naciśnięcia klawiszy i dotknięcia ekranu dotykowego. Wynik INP to czas od momentu interakcji użytkownika do momentu, kiedy przeglądarka wyrenderuje wizualną odpowiedź na tę interakcję. Jako wartość raportowana jest 98. percentyl ze wszystkich zebranych interakcji – co oznacza, że nawet kilka wolnych interakcji może „zepsuć” wynik.

Zmiana jest kluczowa: o ile FID mierzył tylko „wejście” (kiedy przeglądarka zaczęła przetwarzać zdarzenie), INP mierzy pełny cykl – od interakcji do wyrenderowania odpowiedzi na ekranie. To znacznie bardziej miarodajne odzwierciedlenie doświadczenia użytkownika.

Historia zmian Core Web Vitals

Core Web Vitals zostały wprowadzone przez Google w 2020 roku jako zestaw metryk UX. Pierwotny zestaw składał się z LCP (Largest Contentful Paint), FID i CLS (Cumulative Layout Shift). W marcu 2024 FID został oficjalnie zastąpiony przez INP, który był dostępny w trybie eksperymentalnym już od 2022. Aktualny zestaw Core Web Vitals to: LCP, INP i CLS.

Progi INP – co oznaczają „dobry”, „wymaga poprawy” i „słaby”

Google definiuje trzy zakresy dla metryki INP, wyrażone w milisekundach:

Cel dla większości stron to wynik poniżej 200 ms. Badania Google pokazują, że strony z INP powyżej 500 ms notują statystycznie wyższy wskaźnik porzuceń i niższy czas sesji. Progi te są mierzone na urządzeniach mobilnych w sieci 4G – czyli warunkach typowych dla użytkownika smartfona w Polsce.

Ważne: INP jest mierzony na bazie rzeczywistych danych użytkowników (CrUX – Chrome User Experience Report), nie danych laboratoryjnych. Oznacza to, że wynik zależy od zachowania Twoich realnych odwiedzających – nie od wyniku jednego testu PageSpeed.

Jak mierzyć INP – narzędzia i metody

Mierzenie INP wymaga kombinacji narzędzi terenowych (field data, rzeczywiste dane) i laboratoryjnych (lab data, symulacja). Poniżej przedstawiamy trzy główne metody używane przez nasz zespół przy pozycjonowaniu stron.

PageSpeed Insights

PageSpeed Insights (PSI) to narzędzie Google dostępne bezpłatnie. Dla każdej URL pokazuje dane terenowe (z CrUX) i dane laboratoryjne (Lighthouse). W sekcji „Core Web Vitals Assessment” zobaczysz aktualny INP Twojej strony – o ile Twoja strona zbiera wystarczająco dużo ruchu przez Chrome.

Ograniczenie PSI: jeśli Twoja strona ma mały ruch, dane CrUX mogą być niedostępne („Insufficient data”). W takim przypadku polegasz wyłącznie na danych laboratoryjnych Lighthouse, które nie odzwierciedlają INP zbyt dokładnie – bo INP wymaga rzeczywistych interakcji.

Chrome UX Report (CrUX)

CrUX to baza danych Google zawierająca zagregowane dane o wydajności stron zebranych przez przeglądarkę Chrome. Dostęp przez:

• Google Search Console – raport „Podstawowe wskaźniki internetowe” (Core Web Vitals Report)
• CrUX Dashboard na Looker Studio – darmowy szablon od Google
• CrUX API – dla zaawansowanych, integracja z własnymi dashboardami
• BigQuery – publiczny dataset z pełnymi danymi historycznymi

CrUX aktualizuje dane co 28 dni i pokazuje wyniki dla 75. percentyla użytkowników. To „złote źródło” dla Core Web Vitals – Google Search Console opiera się właśnie na CrUX.

Biblioteka web-vitals.js

Biblioteka web-vitals.js od Google umożliwia zbieranie metryk INP (i pozostałych Core Web Vitals) bezpośrednio z kodu Twojej strony i wysyłanie ich do własnej analityki. Przykład implementacji:

import { onINP } from 'web-vitals';

onINP(({ value, rating, entries }) => {
  // Wyslij wynik do GA4 lub wlasnego endpointu
  console.log('INP:', value, 'ms - ocena:', rating);
  // entries zawiera szczegoly kazdej interakcji
});

To rozwiązanie idealne dla stron z małym ruchem lub gdy chcesz mieć własne dane historyczne, niezależne od CrUX. Sprawdzamy je rutynowo przy audytach technicznych w ramach naszych usług projektowania stron.

Chrome DevTools i rozszerzenia

W Chrome DevTools panel „Performance” pozwala nagrywać interakcje i analizować ich czas. Rozszerzenie „Web Vitals” od Google pokazuje INP w czasie rzeczywistym podczas przeglądania strony. Do szybkiego sprawdzenia podczas tworzenia stron internetowych to wygodna metoda – choć dane laboratoryjne.

5 technik poprawy INP – co faktycznie działa

Na podstawie doświadczeń z optymalizacją stron dla klientów wyróżniamy kilka obszarów, w których poprawa INP jest najbardziej efektywna. Każda z poniższych technik może samodzielnie przynieść kilkadziesiąt milisekund poprawy.

1. Redukcja input delay – eliminacja blokowania głównego wątku

Input delay to czas od momentu interakcji do momentu, kiedy przeglądarka zaczyna ją przetwarzać. Główna przyczyna wysokiego input delay to długie zadania JavaScript (long tasks) blokujące main thread – wątek główny przeglądarki.

Jak sprawdzić: w Chrome DevTools / Performance nagrasz interakcję i zobaczysz, czy przed jej obsłużeniem jest długi „blok” głównego wątku (czerwone paski). Każde zadanie JS trwające ponad 50 ms to potencjalny problem.

Rozwiązanie: rozbij długie funkcje na mniejsze kawałki. Używaj setTimeout(fn, 0) lub scheduler.postTask() do podziału pracy na fragmenty nieprzekraczające 50 ms.

2. Optymalizacja event handlerów

Event handlery (obsługa kliknięć, naciśnięć klawiszy) powinny wykonywać jak najmniej pracy synchronicznej. Typowe błędy:

• Obliczenia w handlerze, które mogłyby być wykonane wcześniej (memoizacja)
• Synchroniczne pobieranie danych (fetch powinien być asynchroniczny)
• Zbyt częste manipulacje DOM powodujące reflow
• Brak debounce/throttle na handlery scroll i resize

// Zle - cala logika synchronicznie w handlerze
button.addEventListener('click', () => {
  const data = heavyComputation(); // blokuje main thread
  updateDOM(data);
});

// Lepiej - defer ciezka prace
button.addEventListener('click', () => {
  // natychmiastowe feedback wizualny
  button.classList.add('loading');
  setTimeout(() => {
    const data = heavyComputation();
    updateDOM(data);
    button.classList.remove('loading');
  }, 0);
});

3. Code splitting i lazy loading JavaScriptu

Duże bundle JavaScript to jedna z głównych przyczyn wysokiego INP. Każdy kilobajt kodu, który musi zostać sparsowany i skompilowany przy ładowaniu strony, zajmuje cenny czas na main thread. Rozwiązania:

• Dynamic import() – ładuj moduły dopiero gdy są potrzebne
• Route-based code splitting – każda podstrona ładuje tylko swój kod
• Tree shaking – usuń nieużywany kod z bundla
• Bundle analyzer (webpack-bundle-analyzer, Rollup visualizer) – znajdź co zajmuje miejsce

W projektach Next.js, które realizujemy dla klientów, code splitting działa automatycznie per route, ale wciąż warto sprawdzać, czy komponenty nie importują zbędnych bibliotek.

4. Używanie requestIdleCallback i scheduler API

Nie każda praca musi dziać się natychmiast. Zadania niekrytyczne – ładowanie analityki, prerendering komponentów, synchronizacja danych w tle – można przenieść do requestIdleCallback:

// Zaladuj analityke kiedy przegladarka ma czas
requestIdleCallback(() => {
  loadAnalyticsScript();
  prefetchNextPageData();
}, { timeout: 3000 });

Nowsze API – scheduler.postTask() – oferuje jeszcze lepszą kontrolę priorytetów zadań i jest dostępne w Chrome od wersji 94. Pozwala oznaczyć zadania jako 'user-blocking', 'user-visible' lub 'background', co pomaga przeglądarce zarządzać kolejką.

5. Optymalizacja renderowania – unikaj layout thrashing

Layout thrashing to sytuacja, kiedy JavaScript wielokrotnie naprzemiennie odczytuje i zapisuje właściwości DOM wymuszające layout (reflow), np. offsetWidth, getBoundingClientRect(). Każde takie przeplatanie kosztuje czas renderowania.

// Zle - layout thrashing
elements.forEach(el => {
  const width = el.offsetWidth; // wymusza reflow
  el.style.width = width * 2 + 'px'; // modyfikuje DOM
});

// Dobrze - batch odczyty, potem zapisy
const widths = elements.map(el => el.offsetWidth); // wszystkie odczyty
elements.forEach((el, i) => {
  el.style.width = widths[i] * 2 + 'px'; // wszystkie zapisy
});

6. Weryfikacja wtyczek i skryptów zewnętrznych

Skrypty analityki, chatbotów, widgetów i reklam mogą znacząco podnosić INP. Warto sprawdzić, które z nich blokują main thread w niekorzystnym momencie. Techniki ograniczenia wpływu zewnętrznych skryptów:

• Ładowanie skryptów z atrybutem async lub defer
• Facade pattern – zamiast prawdziwego widgetu najpierw statyczny placeholder, skrypt ładuj po pierwszej interakcji
• Analiza w Chrome DevTools zakładka „Third-party scripts” w raporcie Performance Insights

7. Optymalizacja animacji i przejść CSS

Animacje CSS bazujące na właściwościach transform i opacity działają na GPU i nie blokują main thread. Animacje zmieniające width, height, top, left wymuszają layout – unikaj ich w interaktywnych elementach. Sprawdź dokumentację MDN Web Docs w zakresie wydajności animacji.

Checklist optymalizacji INP

• Sprawdź INP w PageSpeed Insights i Google Search Console
• Zidentyfikuj long tasks w Chrome DevTools (Performance)
• Zmierz input delay dla kluczowych interakcji (przyciski, formularze)
• Zredukuj rozmiar bundle JavaScript (code splitting, tree shaking)
• Przenieś nieistotne zadania do requestIdleCallback lub scheduler.postTask()
• Usuń lub zoptymalizuj blokujące skrypty zewnętrzne
• Zastąp animacje CSS layout properties przez transform/opacity
• Wdróż web-vitals.js do monitorowania INP w produkcji

INP a ranking Google – jak to wpływa na SEO

Core Web Vitals są oficjalnym czynnikiem rankingowym od 2021 roku. INP wszedł do zestawu w marcu 2024. Google nie podaje dokładnej wagi tego sygnału, ale zgodnie z danymi opublikowanymi przez Google Search Central, strony spełniające wszystkie trzy wskaźniki CWV mają statystycznie lepsze pozycje przy zbliżonej jakości treści.

W praktyce oznacza to: jeśli konkurujesz o frazę z kilkoma innymi stronami o podobnej jakości treści, dobry INP może być czynnikiem przesądzającym. Szczególnie ważne to jest dla stron e-commerce i SaaS, gdzie interaktywność jest kluczowa. Jeśli potrzebujesz pomocy z technicznym SEO, sprawdź naszą ofertę pozycjonowania stron.

Według danych HTTP Archive (Web Almanac 2024), na urządzeniach mobilnych ok. 35% stron nadal nie spełnia progu „dobrego” INP. Na desktopie wyniki są lepsze – ponad 80% stron jest w zieleni. To oznacza, że mobilna optymalizacja INP to jeden z bardziej wartościowych obszarów technicznego SEO w 2026 roku.

Najczęstsze błędy przy optymalizacji Core Web Vitals

• Skupianie się tylko na danych laboratoryjnych – Lighthouse i DevTools pokazują symulację, nie rzeczywiste zachowanie użytkowników. INP wymaga danych terenowych (CrUX, Search Console).
• Optymalizacja wyłącznie pod desktop – Google indeksuje strony mobile-first. INP na telefonie może być 3x gorszy niż na laptopie.
• Ignorowanie skryptów third-party – chatboty, widgety map, rozbudowane formularze rezerwacji potrafią dodać 200+ ms do INP.
• Jednorazowy audyt bez monitorowania – INP może się pogorszyć po każdej aktualizacji JS lub nowej wtyczce. Monitoruj ciągłe dane z CrUX.
• Mylenie input delay z processing time i presentation delay – INP to suma trzech faz. Optymalizacja tylko jednej z nich może być niewystarczająca.

FAQ – najczęstsze pytania o INP i Core Web Vitals

Czy INP wpływa bezpośrednio na pozycje w Google?

Tak – INP jest oficjalnym składnikiem Core Web Vitals od marca 2024 i stanowi sygnał rankingowy. Google nie podaje jego dokładnej wagi w algorytmie, ale strony z „dobrym” INP (poniżej 200 ms) mają przewagę nad stronami ze „słabym” wynikiem przy zbliżonej jakości treści i linkowaniu.

Moja strona WordPress ma INP 400 ms – od czego zacząć?

Zacznij od sprawdzenia, które skrypty blokują main thread – najczęściej winowajcą są wtyczki ładujące duże biblioteki JS (page buildery, chatboty, slidery). Następnie sprawdź, czy skrypty mają atrybut async/defer. W WordPressie przydatne są wtyczki optymalizacji jak WP Rocket lub Perfmatters. Jeśli potrzebujesz profesjonalnego audytu, skontaktuj się z nami przez stronę kontaktową.

Jak mierzyć INP na stronie z małym ruchem?

Jeśli strona ma mało odwiedzin przez Chrome, CrUX nie będzie miał danych („Insufficient data” w PageSpeed Insights i Search Console). Zainstaluj bibliotekę web-vitals.js i zbieraj dane do GA4 jako własne zdarzenia. Możesz też ręcznie testować interakcje w Chrome DevTools – rejestruj performance i analizuj sekcje „Interaction” w nagraniu.

Czym różni się INP od FID?

FID mierzył tylko opóźnienie pierwszej interakcji i tylko fazę „input delay” (czas do rozpoczęcia przetwarzania). INP mierzy wszystkie interakcje przez całą sesję i uwzględnia pełny cykl: input delay + processing time + presentation delay (czas do wyrenderowania odpowiedzi na ekranie). INP jest znacznie bardziej kompleksowy i trudniejszy do spełnienia.

Czy Next.js pomaga w osiągnięciu dobrego INP?

Tak – Next.js oferuje wiele wbudowanych mechanizmów korzystnych dla INP: automatyczny code splitting per route, lazy loading obrazów, optymalizację fontów, Server Components (React 18/19) które przenoszą obliczenia na serwer. Jednak nawet w Next.js można napisać kod z długimi tasks JS. Dlatego zawsze warto monitorować INP po wdrożeniu nowych funkcji. Więcej o korzyściach Next.js przy tworzeniu stron znajdziesz w naszej ofercie.

Ile kosztuje optymalizacja INP?

To zależy od punktu wyjścia. Prosta optymalizacja (audyt + usunięcie blokujących skryptów + code splitting) to zazwyczaj kilka godzin pracy developera. Kompleksowy refactoring kodu z głęboką optymalizacją event handlerów i architektury JS to projekt na kilka dni. Sprawdź nasz cennik lub napisz przez formularz kontaktowy po indywidualną wycenę.

Podsumowanie

INP zastąpił FID jako składnik Core Web Vitals i jest dziś jedną z ważniejszych metryk technicznych SEO. Próg „dobrego” wyniku to 200 ms – wszystko powyżej 500 ms Google klasyfikuje jako „słabe”. Mierzysz INP przez PageSpeed Insights, Google Search Console (dane CrUX) lub własne zbieranie danych przez web-vitals.js.

Najskuteczniejsze techniki poprawy INP to: eliminacja długich tasks JS, code splitting, przenoszenie zadań do requestIdleCallback, optymalizacja event handlerów i kontrola wpływu skryptów zewnętrznych. Każda z tych technik może samodzielnie przynieść znaczącą poprawę.

W Studio Kalmus regularnie optymalizujemy Core Web Vitals dla klientów z Warszawy, Piaseczna i całej Polski – zarówno w projektach WordPress, jak i Next.js. Jeśli chcesz sprawdzić, jak Twoja strona wypada pod kątem INP i innych wskaźników, skontaktuj się z nami. Przeprowadzimy audyt techniczny i wskażemy konkretne działania do poprawy.