W marcu 2024 Google podmieniło FID na INP w Core Web Vitals. Brzmi mało dramatycznie, ale w praktyce 70% witryn na WordPressie + Elementor pęka w nowej metryce, mimo że FID było zielone. Pokażę Ci, co INP dokładnie mierzy, dlaczego psuje strony i jak go naprawić.
W skrócie
- INP = czas między kliknięciem/dotknięciem użytkownika a następnym przemalowaniem strony.
- Cel: < 200 ms (dobry), 200–500 ms (wymaga poprawy), > 500 ms (słaby).
- INP mierzy najgorszą interakcję w sesji (98. percentyl).
- Najczęstsi winowajcy: Elementor Pro motion effects, livechaty, Tag Manager, ciężkie sliders.
Dlaczego INP, a nie FID
FID (First Input Delay)
Stara metryka mierzyła opóźnienie pierwszego inputu. Bardzo łatwo było ją oszukać:
– Strona zamarza dopiero po kliknięciu w produkt
– Pierwszy input = scroll po wejściu = 0 ms = „świetnie”
– W rzeczywistości aplikacja całkowicie nieresponsywna
INP (Interaction to Next Paint)
Mierzy wszystkie interakcje i bierze najgorszą (98. percentyl). Jeśli kliknięcie w mobilne menu zamraża stronę na 800 ms — INP = 800 ms, niezależnie od tego, że reszta jest szybka.
Surowsza metryka. Trudniej oszukać.
Co dokładnie mierzy INP
Każda interakcja użytkownika:
– Klik w przycisk
– Tap w mobilne menu
– Wpisanie znaku w input
– Najechanie na rozwijalne menu
– Kliknięcie w slider
dla każdej Google mierzy:
– Input delay — czas, aż przeglądarka zauważy interakcję (zwykle <50 ms)
– Processing time — czas na wykonanie JS event handlera
– Presentation delay — czas na przemalowanie strony
Suma tych 3 = INP dla tej interakcji.
Jak go zmierzyć
W locie (Chrome DevTools)
- F12 → Performance
- Kliknij Record
- Wykonaj typowe interakcje (kliknij menu, slider, przycisk)
- Stop → szukaj długich tasków (>50 ms = czerwone)
Field data (GSC)
GSC → Core Web Vitals → INP. Pokazuje % stron z dobrym/słabym INP.
PageSpeed Insights
Lab data nie ma INP w formie liczby (bo nie ma realnych interakcji w lab teście). Patrz tylko na field data.
Real-time
Wtyczka Web Vitals Extension (Chrome) pokazuje INP w prawym górnym rogu podczas surfowania.
Główne winowajce w WordPressie
1. Elementor Pro motion effects
Każdy element z animacją scroll-trigger, parallax, mouse track = JavaScript wykonuje się przy każdym ruchu myszą.
Skala problemu: strona z 20 elementami z motion effects = 40–80 ms processing per scroll event.
Rozwiązanie:
– Wyłącz motion effects globally
– Pozostaw 2–3 świadome animacje na home page
– Zostaw „FadeIn na scroll” tylko dla 1–2 sekcji
2. Livechat (Tidio, Tawk, LiveChat, Smartsupp)
Livechat ładuje 100–300 KB JS na każdej stronie. Kliknięcie w button = uruchomienie ciężkiego widget initialization.
Rozwiązanie:
– Lazy-load livechat po pierwszej interakcji użytkownika (scroll, klik)
– Pokazuj tylko na stronach kontaktowych / zamówieniowych
– Lekkie alternatywy: Crisp (mały bundle), Plain HTML form
3. Google Tag Manager + Pixel + GA4
Każdy event tracker = osobny event listener. GTM z 30 tagami = chaos.
Rozwiązanie:
– Server-side GTM (zaawansowane, ale realnie redukuje INP o 100–200 ms)
– Lazy-load GTM po pierwszej interakcji (Perfmatters ma to wbudowane)
– Czyść tagi z GTM raz na kwartał — usuwaj nieużywane
4. Slick Slider, Owl Carousel, Swiper
Sliders w WordPressie ładują pełne biblioteki (~50–80 KB). Kliknięcie strzałki = ciężka operacja DOM.
Rozwiązanie:
– Użyj natywnego CSS-only slidera (scroll-snap)
– Albo Swiper.js z minimalną konfiguracją
– Wyrzuć Slick (przestarzały, ciężki)
5. Modale / popupy
Każdy popup w Elementor Pro = pełen widget z own JavaScript.
Rozwiązanie:
– Limit: 1 popup na całej witrynie
– Nie ładuj popupu globalnie (włącz tylko na stronach gdzie jest)
– Asset CleanUp / Perfmatters
6. Mobile menu z hamburger animacją
Niektóre motywy/builders robią mobile menu z 200 ms transition + JavaScript zamykający na klik na zewnątrz.
Rozwiązanie:
– Skróć animację do 100 ms
– Sprawdź, czy event handler na „click outside” jest debounced
– Najprostsze rozwiązanie często najlepsze
7 kroków poprawy INP
Krok 1: Pomiar baseline
Zapisz current INP z PageSpeed (field data) i Chrome DevTools (lab).
Krok 2: Wyłącz motion effects
W Elementor → Site Settings → Motion Effects → Disable Globally. Zostaw tylko świadome animacje na 2–3 elementach.
Krok 3: Lazy-load third-party
Perfmatters → Script Manager → ustaw GTM, livechat, Pixel jako „Lazy load on user interaction”.
Krok 4: Server-side GTM
Jeśli masz dużo tagów — server-side GTM przesuwa wykonywanie z przeglądarki użytkownika na Twój serwer. Setup 4–8 godzin, ale ROI duży.
Krok 5: Wyłącz niekrytyczne wtyczki
Każda aktywna wtyczka = potencjalny event listener. Sprawdź wtyczki, które ostatnio nie używałeś, i wyłącz.
Krok 6: Code splitting
Dla zaawansowanych — rozdziel JavaScript na „krytyczny” (ładowany od razu) i „niekrytyczny” (ładowany leniwie).
Krok 7: Web Workers dla ciężkich obliczeń
Jeśli masz np. kalkulator z dużą logiką — przenieś go do Web Workera (osobny wątek przeglądarki, nie blokuje UI).
Prawdziwa case study z naszej praktyki
Klient #1: sklep WooCommerce z mobile INP = 680 ms.
Diagnoza:
– Elementor Pro motion effects na 30 elementach (240 ms)
– Tidio livechat ładowany na każdej stronie (180 ms)
– GTM z 22 tagami (140 ms)
– Slick Slider na home page (120 ms)
Co zrobiliśmy:
– Wyłączenie motion effects (-200 ms)
– Lazy-load Tidio po pierwszej interakcji (-150 ms)
– Wyczyszczenie GTM, defer (-90 ms)
– Wymiana Slick na CSS scroll-snap (-100 ms)
Wynik po 4 tygodniach: mobile INP = 180 ms (kategoria „Dobry”).
Co dalej
W tym tygodniu:
- Wejdź do GSC → Core Web Vitals → INP
- Otwórz raport „Słabe URL-e” i wybierz 3 najgorsze
- Otwórz każdy w Chrome DevTools → Performance
- Zidentyfikuj long tasks (>200 ms)
- Wprowadź 1 poprawkę z tej listy
INP to nasz speciality — robimy diagnostykę i optymalizację za 1 500 zł, gwarantujemy poprawę z „Słaby” na „Dobry”. Zamów audyt.
