Sklep z INP 600 ms na tanich telefonach z Androidem
Dane z CrUX pokazują INP 600 ms na mobile, głównie przy dodawaniu do koszyka i otwieraniu filtrów. Na MacBookach zespołu wszystko działa płynnie. Google Search Console oznacza strony jako słabe, a marketing pyta, kiedy będzie zielono.
Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.
Moje rozwiązanie
Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.
Pokaż, czego szuka rekruter, i modelową odpowiedź
Co sprawdza rekruter
- Czy zaczynasz od danych z pola, a nie od Lighthouse
- Czy umiesz znaleźć długie zadania i ich źródło
- Czy znasz techniki dzielenia pracy i odchudzania głównego wątku
Odpowiedź seniora
Najpierw diagnoza na prawdziwych danych: biblioteka web-vitals z atrybucją (onINP z attribution) wysyła do analityki, która interakcja i który element jest wolny, z podziałem na input delay, processing i presentation delay. Do odtworzenia używam Performance panelu z CPU throttling 6x albo taniego telefonu przez remote debugging.
Typowe przyczyny przy koszyku: skrypty firm trzecich (tag manager, czaty) blokujące wątek, handler, który synchronicznie aktualizuje duży store i renderuje pół strony, oraz ciężkie wyliczenia w renderze. Naprawy: szybka odpowiedź wizualna od razu, a ciężka praca po await scheduler.yield() lub w startTransition, zawężenie re-renderów (selektory, kolokacja stanu), przeniesienie skryptów zewnętrznych do Partytown lub opóźnienie ich ładowania, Web Worker do obliczeń.
Cel i weryfikacja: INP p75 poniżej 200 ms w CrUX, ale ten ma 28-dniowe okno, więc postęp śledzę we własnym RUM z dnia na dzień. Każda poprawka idzie osobno, żeby wiedzieć, co dało efekt.
Typowe wpadki
- Optymalizowanie wyniku Lighthouse, który nie mierzy INP
- Testy tylko na szybkim laptopie
- Wyłączenie animacji jako jedyna poprawa
Dopytają o
- Jak negocjujesz z marketingiem o skryptach zewnętrznych?
- Czym różni się TBT od INP?
- Jak sprawdzisz, czy problem nie wróci?