INP w Core Web Vitals: czym jest i jak go poprawić

INP (Interaction to Next Paint) to metryka Core Web Vitals, która mierzy, jak szybko strona reaguje na kliknięcie, tapnięcie lub naciśnięcie klawisza. Liczy się czas od akcji użytkownika do chwili, gdy przeglądarka narysuje kolejną klatkę, czyli gdy widać jakąkolwiek reakcję. Od 12 marca 2024 r. INP jest stabilnym Core Web Vital i zastąpił FID. Dobry wynik to 200 ms lub mniej. W tym artykule wyjaśniam, co dokładnie wchodzi w ten czas, jak go zmierzyć na własnej stronie i co realnie go obniża, z przykładami ze sklepów, formularzy i paneli CRM.

Krótko mówiąc

• INP mierzy opóźnienie interakcji w całej wizycie, a nie tylko pierwsze kliknięcie. Do oceny trafia najgorsza istotna interakcja z sesji.
• Progi: do 200 ms dobrze, 200–500 ms do poprawy, powyżej 500 ms słabo. Ocenia się 75. percentyl, osobno dla telefonów i komputerów.
• FID mierzył tylko opóźnienie startu pierwszej interakcji. INP dolicza też czas obsługi zdarzenia i rysowania, dlatego jest znacznie bardziej wymagający.
• Diagnozę zaczynam od danych terenowych (PageSpeed Insights, Search Console, biblioteka web-vitals), a przyczynę odtwarzam w DevTools.
• Najwięcej daje rozbijanie długich zadań JavaScript, odraczanie niekrytycznych skryptów i ograniczanie renderowania po kliknięciu.

Co dokładnie mierzy INP

INP opiera się na Event Timing API i obserwuje opóźnienie wszystkich interakcji użytkownika ze stroną, a na koniec podaje jedną wartość. Ta wartość odpowiada najdłuższej istotnej interakcji, z pominięciem pojedynczych skrajnych obserwacji na stronach z bardzo dużą liczbą interakcji. Średnia nie ma tu znaczenia: jeden wolny filtr w sklepie potrafi zepsuć wynik całej podstrony.

Do INP liczą się:

• kliknięcia myszą,
• tapnięcia na ekranie dotykowym,
• naciśnięcia klawiszy (fizycznej lub ekranowej klawiatury).

Nie liczą się przewijanie i najechanie kursorem. Jeśli jednak przewijanie uruchamia ciężki kod, który zajmuje główny wątek, kolejne kliknięcie i tak będzie musiało poczekać.

Trzy etapy jednej interakcji

Każdą interakcję warto rozłożyć na czynniki. Czas mierzony przez INP składa się z trzech części:

1. Opóźnienie wejścia (input delay). Użytkownik kliknął, ale przeglądarka jest zajęta czymś innym, np. wykonywaniem skryptu analitycznego albo hydracją komponentów. Kliknięcie czeka w kolejce.
2. Czas przetwarzania (processing duration). Wykonują się funkcje obsługi zdarzenia, czyli Twój kod: walidacja formularza, przeliczenie koszyka, filtrowanie listy.
3. Opóźnienie prezentacji (presentation delay). Przeglądarka przelicza style i układ, a potem rysuje nową klatkę. Duże drzewo DOM i zmiany wymuszające przeliczenie całej strony wydłużają ten etap.

Ten podział jest najważniejszy w całej optymalizacji. Częsty błąd polega na dopieszczaniu samego handlera, podczas gdy problem siedzi w opóźnieniu wejścia albo w renderowaniu.

Progi INP i sposób oceny

Google podaje progi dla wszystkich trzech Core Web Vitals. Dla INP dobry wynik to 200 ms lub mniej, a ocena dotyczy 75. percentyla wizyt, liczonego osobno dla urządzeń mobilnych i desktopowych.

Co oznacza 75. percentyl w praktyce? Żeby strona przeszła test, co najmniej trzy na cztery wizyty muszą mieć INP w zielonym zakresie. Jeśli Twoi klienci korzystają głównie ze starszych telefonów z Androidem, wynik mobilny będzie zwykle wyraźnie gorszy niż to, co widzisz na swoim laptopie.

Jeżeli LCP też jest u Ciebie problemem, zajrzyj do mojego tekstu o optymalizacji obrazów: WebP, AVIF, srcset i LCP. INP i LCP mają inne przyczyny, więc warto je naprawiać osobno.

INP a FID: co się zmieniło

FID (First Input Delay) był poprzednią metryką responsywności. Wsparcie dla FID zakończyło się 9 września 2024 r. i dziś nie ma sensu się na niego powoływać. Mimo to wciąż spotykam raporty, w których dobry FID jest przedstawiany jako dowód, że strona reaguje szybko. To błąd.

Powód zmiany wyjaśnił zespół Google Search: FID nie pokazywał problemów pojawiających się po pierwszej interakcji. Dla prostej wizytówki to niewielka różnica. Dla sklepu, aplikacji webowej czy CRM, gdzie użytkownik klika dziesiątki razy w jednej sesji, to zupełnie inna miara jakości.

Czy INP wpływa na pozycje w Google

Tak, ale ostrożnie z oczekiwaniami. Core Web Vitals są jednym z sygnałów, z których korzystają systemy wyszukiwania Google, a INP jest częścią oceny doświadczenia strony. Google jednocześnie podkreśla, że dobry wynik nie gwarantuje wysokiej pozycji: trafność i jakość treści ważą więcej.

Jak to przekłada się na decyzje? Moim zdaniem tak:

• jeśli masz słabe treści i dobry INP, poprawa INP nie wyciągnie Cię na pierwszą stronę,
• jeśli konkurujesz z podobnie dobrymi stronami, sprawna strona może być jednym z elementów, które przechylą szalę,
• niezależnie od SEO wolne kliknięcia irytują użytkowników, a to bezpośrednio odbija się na porzuconych koszykach i niewysłanych formularzach.

Dlatego traktuję INP przede wszystkim jako metrykę biznesową, a dopiero potem jako czynnik SEO. Jeśli chcesz zobaczyć, gdzie INP mieści się w szerszej diagnozie strony, opisałem to w tekście Audyt SEO strony: co sprawdza i jakie da Ci wyniki.

Jak zmierzyć INP na swojej stronie

Dane dzielą się na terenowe (od prawdziwych użytkowników) i laboratoryjne (symulacja na jednym urządzeniu). Do oceny Core Web Vitals liczą się te pierwsze. Oto kolejność, w jakiej sam pracuję.

1. PageSpeed Insights. Wpisujesz adres i w górnej części raportu widzisz dane z CrUX, czyli z rzeczywistych wizyt użytkowników Chrome z ostatnich 28 dni. Dolna część to test Lighthouse, który INP nie mierzy bezpośrednio, bo w symulacji nikt nie klika.
2. Google Search Console. Raport Podstawowe wskaźniki internetowe grupuje podobne adresy i pokazuje, które grupy stron mają INP do poprawy. To najlepszy widok dla większych serwisów i sklepów.
3. Chrome DevTools. W panelu Performance nagrywasz sesję, klikasz problematyczny element i widzisz, co blokowało główny wątek. Tu odtwarzam przyczynę.
4. Biblioteka web-vitals. Mierzy INP u Twoich użytkowników i wysyła wyniki do Twojej analityki.

Jedna ważna uwaga dla mniejszych polskich firm. CrUX obejmuje tylko witryny z wystarczającym ruchem, więc strona lokalnej firmy często nie ma w PageSpeed Insights żadnych danych terenowych. Wtedy jedynym sposobem na realny pomiar jest własny monitoring.

Własny pomiar z biblioteką web-vitals

Wersja „attribution” biblioteki dodaje informacje diagnostyczne: który element kliknięto i ile trwał każdy z trzech etapów. Opisuje to oficjalne ćwiczenie Google o mierzeniu INP. Przykładowa implementacja wygląda tak:

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

onINP(({ value, rating, attribution }) => {
  const dane = JSON.stringify({
    inp: Math.round(value),
    ocena: rating,
    element: attribution.interactionTarget,
    inputDelay: Math.round(attribution.inputDelay),
    przetwarzanie: Math.round(attribution.processingDuration),
    prezentacja: Math.round(attribution.presentationDelay),
  });
  navigator.sendBeacon('/analityka', dane);
});

Po tygodniu zbierania danych zwykle widać wyraźny wzorzec: dwa lub trzy elementy odpowiadają za większość słabych wyników. To konkretna lista zadań, a nie ogólne „przyspieszmy stronę”.

Różnica między danymi terenowymi a wynikiem z DevTools nie oznacza błędu pomiaru. Twój komputer jest szybszy od telefonu przeciętnego klienta, a w laboratorium nie odtworzysz wszystkich ścieżek, którymi ludzie chodzą po stronie. Dlatego w DevTools warto włączyć spowolnienie procesora (np. 4x), żeby zbliżyć się do warunków mobilnych.

Gdzie INP najczęściej się psuje

Z mojego doświadczenia problem rzadko dotyczy całej strony. Zwykle siedzi w kilku konkretnych miejscach:

• Filtry i sortowanie w sklepie. Kliknięcie w kategorię przelicza i renderuje od nowa setki kafelków produktów.
• Wyszukiwarka z podpowiedziami. Każde naciśnięcie klawisza uruchamia zapytanie i przebudowę listy wyników.
• Menu mobilne i modale. Otwarcie menu animuje dużą część strony albo wymusza przeliczenie układu całego dokumentu.
• Koszyk. Zmiana ilości przelicza ceny, rabaty, dostawę i jednocześnie odpala kilka skryptów marketingowych.
• Długie formularze. Walidacja wszystkich pól przy każdym znaku.
• Panele CRM i aplikacje. Tabele z tysiącami wierszy, edycja inline, dashboardy z wieloma wykresami odświeżanymi naraz.
• Skrypty zewnętrzne. Czaty, mapy ciepła, piksele reklamowe i widżety opinii, które zajmują główny wątek dokładnie wtedy, gdy użytkownik chce kliknąć.

Te miejsca warto przejrzeć także pod kątem użyteczności. Wolny interfejs i błędy UX często występują razem, o czym piszę w artykule Audyt UX strony: jak wykryć błędy, które kosztują Cię konwersje.

Jak poprawić INP krok po kroku

Kolejność ma znaczenie. Zaczynam od danych, nie od narzędzi do minifikacji.

1. Znajdź najwolniejszą interakcję. Z danych terenowych wybierz element i typ interakcji z najgorszym wynikiem. Bez tego kroku optymalizujesz na ślepo.
2. Sprawdź, który etap dominuje. Duże opóźnienie wejścia, długie przetwarzanie czy wolna prezentacja? Każdy wymaga innego leczenia.
3. Przy dużym opóźnieniu wejścia odciąż główny wątek. Odrocz skrypty, które nie są potrzebne od razu (atrybut defer, ładowanie po interakcji lub po załadowaniu strony). Przejrzyj skrypty zewnętrzne i usuń te, z których nikt nie korzysta.
4. Przy długim przetwarzaniu rozbij long tasks. Long task to zadanie trwające ponad 50 ms, które blokuje przeglądarkę. Najpierw wykonaj to, co użytkownik ma zobaczyć, a resztę (analityka, zapis do pamięci, przeliczenia w tle) przesuń na później.
5. Przy wolnej prezentacji zmniejsz zakres renderowania. Aktualizuj tylko te fragmenty interfejsu, które faktycznie się zmieniły. Długie listy renderuj partiami albo wirtualizuj. Pomaga też właściwość CSS content-visibility dla sekcji poza ekranem i ogólnie mniejsze drzewo DOM.
6. Daj natychmiastową informację zwrotną. Po kliknięciu „Dodaj do koszyka” najpierw zmień stan przycisku, a dopiero potem wysyłaj żądanie i przeliczaj koszyk.
7. Zmierz ponownie w terenie. Dane CrUX zbierają się z 28 dni, więc efekt w PageSpeed Insights i Search Console zobaczysz z opóźnieniem. Własny monitoring pokaże go od razu.

Oddawanie sterowania przeglądarce

Najskuteczniejsza technika przy długim przetwarzaniu to częste „oddawanie” głównego wątku, żeby przeglądarka mogła w międzyczasie obsłużyć kliknięcie i narysować klatkę. Google opisuje to szczegółowo w poradniku o optymalizacji długich zadań. W nowszych przeglądarkach służy do tego metoda scheduler.yield(), a dla pozostałych stosuję prosty zamiennik:

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

async function renderujProdukty(produkty) {
  for (let i = 0; i < produkty.length; i++) {
    renderujKafelek(produkty[i]);
    if (i % 20 === 0) await oddajWatek();
  }
}

Zwróć uwagę, że ten kod nie zmniejsza ilości pracy. Zmienia tylko to, że praca nie blokuje użytkownika. Z tego samego powodu sam rozmiar pliku JavaScript nie mówi wszystkiego: ciężki skrypt, który nie wchodzi w drogę interakcjom, może mieć mniejszy wpływ na INP niż mały, ale źle zaplanowany handler.

Moje podejście do INP w projektach

W mojej pracy INP rzadko jest problemem, który naprawia się na końcu jedną wtyczką. Najczęściej wynika z decyzji podjętych dużo wcześniej: z wyboru gotowego szablonu z kilkunastoma skryptami, z rozbudowanego kreatora stron, z dodawania kolejnych widżetów marketingowych bez sprawdzenia, ile kosztują przy każdym kliknięciu.

Dlatego projektuję strony, sklepy i aplikacje bez szablonów, a design, kod i SEO prowadzę w jednym procesie. Kiedy w Figmie powstaje filtr produktów albo tabela w panelu CRM, od razu wiem, jak zostanie zbudowana i ile pracy będzie wykonywać przeglądarka po kliknięciu. Nie ma etapu, na którym grafik projektuje efekt, a programista później walczy z jego wydajnością.

W istniejących serwisach zaczynam od pomiaru u realnych użytkowników, a dopiero potem proponuję zmiany. Czasem wystarczy usunąć dwa zbędne skrypty i przepisać jeden handler. Czasem uczciwie mówię, że platforma ogranicza dalsze poprawki i trzeba rozważyć migrację. W obu przypadkach klient dostaje konkretne liczby przed i po, a nie ogólną obietnicę „szybszej strony”.

— Marcin

Potrzebujesz pomocy z INP?

Jeśli Twoja strona lub sklep ma INP w żółtym albo czerwonym zakresie, mogę przeanalizować dane, wskazać interakcje, które psują wynik, i wdrożyć poprawki. Optymalizacja Core Web Vitals jest częścią mojej usługi SEO i pozycjonowania z naciskiem na SEO techniczne. Jeśli planujesz nowy projekt, zbuduję sklep internetowy lub panel CRM dopasowany do Twojego procesu sprzedaży tak, żeby responsywność była założeniem od pierwszego dnia, a nie poprawką po wdrożeniu.

Najczęstsze pytania o INP

Jaki wynik INP jest dobry?

Dobry INP to 200 ms lub mniej, mierzone na 75. percentylu wizyt. Wynik od 200 do 500 ms wymaga poprawy, a powyżej 500 ms jest słaby. Telefony i komputery ocenia się osobno, więc sprawdzaj oba wyniki.

Dlaczego PageSpeed Insights nie pokazuje INP dla mojej strony?

Najczęściej strona ma za mały ruch, żeby trafić do raportu CrUX, z którego korzysta PageSpeed Insights. Test Lighthouse w dolnej części raportu nie mierzy INP, bo w symulacji nikt nie klika. W takiej sytuacji warto wdrożyć bibliotekę web-vitals i zbierać dane od własnych użytkowników.

Czym INP różni się od FID?

FID mierzył tylko opóźnienie rozpoczęcia pierwszej interakcji. INP obejmuje wszystkie kliknięcia, tapnięcia i naciśnięcia klawiszy w trakcie wizyty oraz czas ich obsługi i narysowania odpowiedzi. FID nie jest już częścią Core Web Vitals, więc dobry FID nic dziś nie mówi o responsywności strony.

Po jakim czasie zobaczę poprawę INP w Search Console?

Dane terenowe Google obejmują okres 28 dni, więc pełny efekt zmian widać zwykle po około miesiącu. Search Console może potrzebować dodatkowego czasu na ponowną ocenę grup adresów. Własny monitoring pokaże zmianę już w dniu wdrożenia.

Czy poprawa INP podniesie moją stronę w Google?

INP jest jednym z sygnałów doświadczenia strony, ale nie zastąpi trafnych i wartościowych treści. Poprawa może pomóc, zwłaszcza gdy konkurujesz z podobnie dobrymi stronami. Pewniejszy i szybszy efekt zobaczysz zwykle w zachowaniu użytkowników: mniej porzuceń formularzy i koszyków.

Źródła

• Interaction to Next Paint becomes a Core Web Vital on March 12 (web.dev)
• Interaction to Next Paint (INP) (web.dev)
• Web Vitals (web.dev)
• First Input Delay (FID) (web.dev)
• Introducing INP to Core Web Vitals (Google Search Central Blog)
• Find slow interactions in the field (web.dev)
• Measuring Interaction to Next Paint (Google Codelabs)
• The most effective ways to improve Core Web Vitals (web.dev)
• Optimize long tasks (web.dev)
• Scheduler: yield() method (MDN)

Rekomendacje

• Optymalizacja obrazów na stronie: WebP, AVIF, srcset i LCP
• Audyt UX strony: jak wykryć błędy, które kosztują Cię konwersje
• Audyt SEO strony: co sprawdza i jakie da ci wyniki
• Audyt WCAG: jak zamówić go i wykorzystać raport do poprawy konwersji