INP vs FID — co się zmieniło?

FID mierzył tylko pierwszą interakcję i tylko opóźnienie do startu processingu. INP mierzy najgorszą interakcję z całej sesji i pełną ścieżkę aż do renderu. Strony, które miały dobre FID, nagle dostały słabe INP po marcu 2024 — bo INP łapie problemy, których FID nie widział.

Co robić, jeśli third-party skrypty psują INP, a nie mogę ich usunąć?

1) Załaduj je z atrybutem async/defer. 2) Opóźnij ładowanie do interakcji użytkownika (np. chat widget pojawia się dopiero po scrollu lub kliknięciu). 3) Sprawdź, czy dostawca ma „lite" wersję bez ciężkich funkcji. 4) Rozważ zamianę na lżejszą alternatywę.

Czy INP dotyczy też scrollowania?

Nie — INP mierzy tylko interakcje wymagające reakcji systemu (klik, tap, klawisz). Scrolling jest osobno mierzony w Core Web Vitals przez CLS (przesunięcia layoutu) i nie jest interakcją w sensie INP.

Jak debugować INP w Chrome DevTools?

Otwórz DevTools → Performance → włącz nagrywanie → wykonaj interakcję. W timeline zobaczysz „Interaction" markery z czasem trwania. Długie zadania są zaznaczone na czerwono. Alternatywnie: zainstaluj Web Vitals extension, która pokazuje INP na żywo podczas korzystania ze strony.

INP (Interaction to Next Paint)

INP (Interaction to Next Paint) to metryka mierząca opóźnienie reakcji strony na interakcje użytkownika — kliknięcie, tap, klawisz. Zastąpiła FID w Core Web Vitals w marcu 2024 i jest dziś jedną z trzech głównych metryk Page Experience.

Co dokładnie mierzy

Od momentu interakcji do pierwszego renderu odpowiedzi wizualnej — w skali całej sesji. W przeciwieństwie do FID, który mierzył tylko pierwsze zdarzenie i tylko opóźnienie do startu processingu, INP bierze pod uwagę najgorszą obserwowaną interakcję w trakcie wizyty i pełną ścieżkę aż do renderu. To bardziej rygorystyczny i bardziej reprezentatywny test.

Progi

Dobry: ≤ 200 ms.
Wymaga poprawy: 200–500 ms.
Słaby: > 500 ms.
Google ocenia po 75 percentylu z CrUX. Próg 200 ms oznacza, że 75% interakcji u realnych użytkowników musi mieścić się poniżej tej wartości.

Co psuje INP

Long tasks w JavaScript (skrypty blokujące główny wątek na > 50 ms — wszystko ponad to opóźnia reakcję). Heavy event handlery — onClick, który robi za dużo (parsuje JSON, modyfikuje DOM, robi fetch). Third-party skrypty — chat widgety, analytics, tag manager, pixele reklamowe. Brak debounce na input handlerach (każdy znak wywołuje pełny re-render). Synchroniczne setState w React bez startTransition.

Jak poprawić

Rozbij long tasks na mniejsze chunks (setTimeout, requestIdleCallback, scheduler.yield jeśli dostępne). Przenieś ciężkie obliczenia do Web Workerów. Defer / async dla third-party. Użyj React 18 concurrent features (transitions, deferred values). Audytuj event handlery — co naprawdę musi się wydarzyć synchronicznie, a co może poczekać.