Gotowość INP

Gotowość na INP to skrót myślowy określający, jak przygotowana jest strona, by przejść Interaction to Next Paint (interakcja do kolejnego wyrenderowania) w warunkach rzeczywistych, a nie tylko w teście laboratoryjnym. Dla zespołów SEO ma to znaczenie, ponieważ INP jest jednym z Core Web Vitals oraz dlatego, że opóźnione interfejsy psują ukończenie formularzy, współczynnik dodawania do koszyka i jakość pozyskiwanych leadów.

Co tak naprawdę oznacza gotowość na INP

INP mierzy opóźnienie interakcji użytkownika do kolejnej aktualizacji wizualnej. Kliknięcie. Stuknięcie. Wciśnięcie klawisza. Google klasyfikuje 200 ms lub mniej jako dobre, 200–500 ms jako wymaga poprawy oraz 500 ms+ jako słabe.

Kluczowe jest to, że to w dużej mierze dane z pola. Google Search Console i PageSpeed Insights w dużej mierze opierają się na danych z Chrome UX Report, gdy istnieje wystarczający ruch. Lighthouse może wskazać prawdopodobne przyczyny, ale nie dowodzi, że Twoja strona jest gotowa w środowisku produkcyjnym.

Dlaczego SEO powinno się tym przejmować

INP zastąpiło FID jako jeden z Core Web Vitals w marcu 2024 roku. Ta zmiana miała znaczenie, ponieważ FID był zbyt wyrozumiały. Strona mogła reagować szybko na pierwsze stuknięcie, a potem „zamarzać” na drugim, trzecim lub czwartym — i nadal wyglądać dobrze w ocenie według FID. INP jest bardziej restrykcyjne. Lepsza metryka. Trudniej ją „udawać”.

Jednocześnie nie przesadzaj z wpływem na ranking. Google nigdy nie stwierdziło, że Core Web Vitals to ciężki czynnik rankingowy. John Mueller z Google wielokrotnie przedstawiał sygnały związane z doświadczeniem użytkownika jako rozstrzygające (tie-breakers), gdy inne sygnały są podobne. Zwykle argument biznesowy jest silniejszy niż argument rankingowy.

Jak ocenić gotowość

• Google Search Console: Sprawdź raport Core Web Vitals dla grup adresów URL w wersji mobilnej i desktopowej. To Twój najbardziej ogólny widok SEO.
• PageSpeed Insights: Porównaj dane CrUX z diagnostyką Lighthouse. Jeśli INP w polu wynosi 280 ms, a w labie 90 ms, to realni użytkownicy napotykają problemy, których nie wykryła maszyna testowa.
• Chrome DevTools: Użyj panelu Performance, aby znaleźć długie zadania (long tasks), opóźnienia w obsłudze zdarzeń (event handler delays) oraz wąskie gardła renderowania.
• Screaming Frog: Przeskanuj szablony i mapuj, które typy stron ładują ciężkie JS, widgety firm trzecich lub rozdęte biblioteki komponentów.
• Ahrefs lub Semrush: Priorytetyzuj poprawki na szablonach generujących najwięcej organicznych wejść, a nie na losowych stronach o niskim ruchu.

Co najczęściej psuje INP

• Długie zadania w głównym wątku (main thread) trwające ponad 50 ms
• Ciężkie renderowanie po stronie klienta w aplikacjach React, Vue lub Angular
• Skrypty firm trzecich, takie jak czat, testy A/B, narzędzia do zgód i mapy ciepła
• Drogie aktualizacje DOM oraz „thrashing” układu po wprowadzeniu danych
• Tanie urządzenia z Androidem na słabszych procesorach, gdzie „działa OK na desktopie” nie znaczy nic

Uczciwe zastrzeżenie: dane INP mogą być zaszumione. Strony z małym ruchem mogą nie mieć wystarczającej ilości danych CrUX. Grupowanie adresów URL w GSC potrafi ukryć, który konkretnie szablon faktycznie zawodzi. I niektóre interakcje po prostu nie występują na tyle często, by dało się je zauważyć, dopóki funkcja nie zdobędzie realnego użycia.

Co robią dobre zespoły