Wolny WordPress i słaby INP? Zdiagnozuj opóźnienia interakcji

INP pokazuje, jak szybko strona przedstawia kolejną klatkę po interakcji użytkownika, takiej jak kliknięcie, stuknięcie lub naciśnięcie klawisza. Google ocenia dane terenowe na 75. percentylu: wynik do 200 ms jest dobry, od ponad 200 ms do 500 ms wymaga poprawy, a powyżej 500 ms jest słaby. Progi obowiązują tak samo dla WordPressa i innych platform. Google opisuje progi INP i sposób oceny.

INP mierzy responsywność, LCP czas wyświetlenia największego elementu treści, a CLS nieoczekiwane przesunięcia układu. Szybkie LCP nie oznacza więc, że menu, filtry lub formularze reagują szybko. INP obejmuje interakcje z całego czasu wizyty i uwzględnia opóźnienie wejściowe, czas przetwarzania oraz opóźnienie prezentacji wyniku.

Dane terenowe mogą różnić się od pojedynczego testu Lighthouse, ponieważ CrUX agreguje doświadczenia rzeczywistych użytkowników z ostatnich 28 dni, a test laboratoryjny odtwarza kontrolowane warunki dla konkretnego uruchomienia. PageSpeed Insights może pokazywać dane dla URL-a albo dla całej domeny, gdy konkretna strona nie ma wystarczającej próbki. Search Console grupuje podobne adresy i prezentuje dane dla grup, a nie pełną listę wszystkich URL-i. Google opisuje te różnice w dokumentacji PSI i raportu Core Web Vitals, stan na 10.2026: https://developers.google.com/speed/docs/insights/v5/about oraz https://support.google.com/webmasters/answer/9205520?hl=pl.

Poradnik o pomiarze i kolejności zmian w WordPressie pomaga rozdzielić opóźnienia interakcji od problemów z ładowaniem. Sam wynik INP nie wskazuje jeszcze, czy winny jest motyw, wtyczka, kod sklepu czy skrypt zewnętrzny.

PageSpeed Insights pokaże, czy problem występuje wśród użytkowników, a Chrome DevTools pozwoli odtworzyć i przeanalizować konkretną interakcję. Zacznij od tego samego adresu URL na mobile i desktopie; nie porównuj strony głównej z kartą produktu.

1. Wklej adres strony do PageSpeed Insights i sprawdź osobno dane mobilne oraz desktopowe. Sekcja danych rzeczywistych bazuje na CrUX, a diagnostyka laboratoryjna na Lighthouse. Brak danych terenowych nie oznacza dobrego wyniku: może oznaczać niewystarczającą próbkę.
2. W Google Search Console otwórz raport Podstawowe wskaźniki internetowe, wybierz urządzenie i sprawdź grupy URL-i z problemem INP. Otwórz przykład z grupy, a potem przetestuj reprezentatywną stronę w PSI.
3. W Chrome otwórz DevTools, wybierz Performance i włącz Live metrics, jeśli ta karta jest dostępna. Sprawdź interakcję lokalnie, a następnie nagraj jej przebieg w Performance.
4. Zapisz adres, typ urządzenia, rozmiar okna, akcję i wynik. Po zmianie powtórz pomiar w tych samych warunkach.

Wartość INP należy interpretować dla właściwego urządzenia i danych terenowych, a pomiar laboratoryjny wykorzystywać do diagnozy. Google wyjaśnia dane terenowe i laboratoryjne w PSI.

Najpierw sprawdź interakcje na ścieżce prowadzącej do kontaktu lub zakupu, ponieważ ich opóźnienie utrudnia wykonanie działania biznesowego. W sklepie zacznij od menu kategorii, wyszukiwarki, filtrów, wyboru wariantu, dodania do koszyka i przejścia przez checkout.

Wybierz jedną podstronę z danego typu, np. kategorię z filtrami, kartę produktu z wariantami i checkout. Jeżeli problem występuje tylko na telefonie, testuj na mobilnym urządzeniu lub kontroluj emulację w DevTools. Zapisuj nazwę interakcji i element, który ją uruchamia, zamiast opisywać wynik jako ogólne "strona jest wolna".

Najpierw testuj akcję, która blokuje dalszy krok użytkownika, a dopiero potem elementy nawigacyjne. Gdy opóźnienie dotyczy koszyka lub checkoutu i wymaga zmian w kodzie sklepu, optymalizacja szybkości WooCommerce może objąć diagnozę oraz poprawę wskazanych problemów. Gdy widać problem na kilku typach stron, zanotuj, czy wspólnym elementem jest ten sam skrypt, nagłówek lub wtyczka.

Chrome DevTools Performance pozwala połączyć konkretną akcję z zadaniami na głównym wątku przeglądarki, czyli miejscu, w którym JavaScript, obliczanie stylów i część renderowania konkurują o czas. Otwórz stronę, uruchom DevTools, przejdź do Performance, kliknij Record, wykonaj jedną powtarzalną interakcję i zatrzymaj nagranie. Dokumentacja Chrome opisuje rejestrowanie interakcji i analizę osi Main oraz Interactions: https://developer.chrome.com/docs/devtools/performance/reference.

Znajdź interakcję na ścieżce Interactions i sprawdź jej fazy: input delay, processing time oraz presentation delay. Na osi Main szukaj długich zadań oznaczonych przez DevTools. Długie zadanie to praca blokująca główny wątek przez ponad 50 ms; samo jego wystąpienie nie dowodzi, że odpowiada za opóźnienie, dlatego sprawdź stos wywołań, źródło skryptu i czas zdarzenia.

Przy nagraniu korzystaj z tego samego adresu, urządzenia, ustawień CPU oraz tej samej akcji. Wykonaj pomiar kilka razy, bo cache, reklamy i obciążenie komputera mogą zmienić przebieg. W razie potrzeby włącz wyszarzanie skryptów zewnętrznych w Performance, aby odróżnić pracę kodu własnego od podmiotów trzecich. Po znalezieniu podejrzanego skryptu przejdź z jego zdarzenia do pliku źródłowego i sprawdź, czy inicjuje go motyw, wtyczka, menedżer tagów, czat lub piksel reklamowy.

Perspektywa KC Mobile: diagnozę zapisujemy jako relację "akcja użytkownika → zdarzenie w Performance → źródło skryptu → potwierdzający test". Taki zapis pozwala odróżnić kosztowny skrypt od zadania, które tylko przypadkowo działało w tym samym czasie.

Winowajcę ustalisz przez kontrolowane wyłączenie jednego podejrzanego elementu na środowisku testowym i powtórzenie tej samej interakcji. Nie wyłączaj po kolei wtyczek na działającym sklepie: część z nich obsługuje płatności, cache, zabezpieczenia albo krytyczne funkcje checkoutu.

Staging powinien odzwierciedlać wersje WordPressa, WooCommerce, motywu i wtyczek z produkcji. Zmieniaj jeden element na raz i zapisuj wynik, bo jednoczesne wyłączenie kilku wtyczek utrudnia ustalenie przyczyny. Po teście przywróć ustawienia i sprawdź błędy JavaScript w Console oraz logi aplikacji.

Poprawiaj najpierw kod powiązany z opóźnioną interakcją, a po każdej zmianie sprawdzaj, czy funkcja nadal działa. Usunięcie skryptu może poprawić czas reakcji, ale także wyłączyć filtrowanie, analitykę, walidację formularza albo obsługę wariantów.

Zalecamy następującą kolejność, bo ogranicza ryzyko zmian, które poprawiają wynik laboratoryjny kosztem funkcji:

1. Usuń nieużywane skrypty i funkcje, które nie są potrzebne na danej podstronie.
2. Opóźnij ładowanie integracji, które nie są potrzebne do pierwszej interakcji, np. widgetu czatu.
3. Podziel długą pracę JavaScriptu na krótsze zadania albo ogranicz kod wykonywany po kliknięciu.
4. Ogranicz wielokrotne przeliczanie układu i aktualizowanie dużych fragmentów DOM po jednej akcji.
5. Ponownie zmierz INP i sprawdź funkcję na stronie, której dotyczy zmiana.

Odroczenie skryptu nie zawsze poprawia INP. Jeżeli dany kod blokuje obsługę akcji po kliknięciu albo inicjuje się dopiero wtedy, użytkownik może odczuć opóźnienie przy pierwszym użyciu. Każdą zmianę porównuj na tej samej podstronie, urządzeniu i interakcji oraz weryfikuj w Console. Przewodnik o diagnostyce szybkości WordPressa pomaga ustalić, czy równolegle występuje problem z ładowaniem albo serwerem.

Po zmianie sprawdź ten sam zestaw interakcji przed i po wdrożeniu, a następnie potwierdź, że ścieżka zakupowa nadal działa. Wybierz stronę produktu z wariantami, kategorię z filtrami, koszyk i checkout; testuj na urządzeniu mobilnym i desktopowym, jeśli problem dotyczy obu grup.

Zapisz wynik INP z DevTools oraz obserwowane błędy w Console. Porównaj nagrania na tym samym adresie i przy tych samych warunkach. Dane terenowe mogą zmienić się wolniej, bo obejmują kroczący okres 28 dni; pojedynczy pomiar laboratoryjny nie potwierdza zmiany w danych użytkowników.

Audyt warto zlecić, gdy dane terenowe pokazują słaby INP, opóźnienie dotyczy ważnej ścieżki zakupowej albo testy nie wskazują jednoznacznie źródła problemu. Potrzebna jest również analiza, gdy wyniki dla mobile i desktopu różnią się na tyle, że jedna poprawka może zaszkodzić drugiej grupie.

Audyt powinien wskazać URL-e i interakcje do poprawy, nagrania lub ślady z DevTools, podejrzane źródła skryptów, ryzyko zmian oraz plan pomiaru po wdrożeniu. Jeśli chcesz, by zespół przeprowadził pomiary i poprawki w sklepie, analiza wydajności i poprawki WooCommerce obejmują pracę nad problemami technicznymi.

Jeżeli sklep korzysta także z BaseLinkera, integracja systemu sprzedażowego z BaseLinkerem może uporządkować przepływ zamówień poza przeglądarką klienta. Nie zastępuje to diagnozy INP w witrynie, ponieważ pomiar dotyczy reakcji strony na interakcje.

• WordPress zużywa dużo CPU? Jak znaleźć przyczynę i ograniczyć obciążenie
• Jak CDN może poprawić wydajność Twojego sklepu internetowego
• EWWW Image Optimizer w WordPressie: jak skonfigurować i sprawdzić optymalizację obrazów
• Optymalizacja stron z dynamicznymi tabelami danych pod szybkość i SEO
• Core update Google: co oznacza dla SEO i jak ocenić wpływ aktualizacji na stronę