Interaction to Next Paint: co to jest i dlaczego zastąpiło First Input Delay
Kiedy klikasz przycisk na stronie internetowej, Twój mózg oczekuje natychmiastowej reakcji. Psychologicznie "natychmiastowe" oznacza mniej niż 100 milisekund. Do 200ms reakcja wydaje się szybka. Powyżej 500ms zaczyna się frustracja.
Czym był First Input Delay
FID mierzył czas od pierwszej interakcji użytkownika ze stroną (najczęściej pierwsze kliknięcie) do momentu, gdy przeglądarka mogła zacząć przetwarzać tę interakcję. Brzmi rozsądnie. Problem polegał na tym, że FID mierzył tylko pierwszy klik i tylko czas oczekiwania na przetworzenie, nie czas do faktycznej odpowiedzi wizualnej.
Strona mogła mieć świetny FID, ale po kliknięciu przycisku akordeon otwierał się z 800ms opóźnieniem. Tego FID nie łapał.
INP robi to inaczej
Interaction to Next Paint mierzy czas od każdej interakcji (kliknięcie, dotknięcie, naciśnięcie klawisza) do momentu, gdy przeglądarka wyrenderuje wizualną zmianę w odpowiedzi na tę interakcję. Zbiera wszystkie interakcje podczas sesji i raportuje tę, która zajęła najdłużej (z pewnym marginesem tolerancji dla wartości odstających).
To fundamentalna zmiana perspektywy. Nie pierwsze wrażenie, lecz pełne doświadczenie. Strony z dużą ilością interaktywnych elementów, animacji i JavaScript mogą mieć INP znacznie gorszy niż sugerował FID.
Jak INP wpływa na pozycję
INP wszedł jako oficjalna metryka Core Web Vitals w marcu 2024. Progi: do 200ms to dobry wynik, 200-500ms wymaga poprawy, powyżej 500ms to słaby wynik. Google uwzględnia Core Web Vitals jako jeden z czynników Page Experience w algorytmie rankingowym.
Warto zachować perspektywę: Content i linki nadal mają większy wpływ na pozycję niż metryki techniczne. Ale przy równej jakości treści, strona z lepszymi CWV ma przewagę. A co ważniejsze, lepsza interaktywność bezpośrednio poprawia zachowanie użytkowników na stronie.
Co sprawdzić w pierwszej kolejności
Najczęstsze przyczyny wysokiego INP to długie zadania JavaScript blokujące główny wątek przeglądarki, nadmierne użycie event listenerów bez debouncingu, ciężkie operacje DOM wykonywane synchronicznie, oraz nieoptymalne animacje używające właściwości CSS powodujących reflow.
Narzędzie Chrome DevTools, zakładka Performance, pozwala nagrać sesję i zobaczyć dokładnie, które zadania blokują wątek. To dobry punkt startowy przed jakąkolwiek optymalizacją.