Jak poprawić wynik INP na stronie internetowej? Krótka odpowiedź brzmi: trzeba ograniczyć obciążenie głównego wątku przeglądarki, które opóźnia kolejne odmalowanie ekranu po kliknięciu, dotknięciu lub użyciu klawiatury przez użytkownika. W praktyce oznacza to dzielenie długich zadań JavaScript na mniejsze części, usuwanie zbędnych skryptów, upraszczanie obsługi zdarzeń, optymalizację zasobów blokujących renderowanie, kontrolę kodu firm trzecich oraz pomiar na podstawie danych prawdziwych użytkowników. Dobry wynik INP to 200 ms lub mniej; zakres 200-500 ms wymaga poprawy, a wartości powyżej 500 ms są uznawane za słabe.
INP, czyli Interaction to Next Paint, jest jedną z kluczowych metryk Core Web Vitals w działaniach SEO i UX w 2026 roku. Google nie patrzy już wyłącznie na to, czy strona szybko się otwiera. Coraz większe znaczenie ma również to, jak płynnie użytkownik może korzystać z witryny po jej załadowaniu. Opóźnione otwieranie filtra produktów, przycisk „dodaj do koszyka”, który przez chwilę nie reaguje, wolno działające menu mobilne albo pole formularza zacinające się podczas pisania to typowe objawy problemów z INP.
W tym poradniku dowiesz się, jak mierzyć INP, jak znaleźć techniczne wąskie gardła odpowiedzialne za słaby wynik oraz jakie konkretne kroki optymalizacyjne możesz wdrożyć jako programista, właściciel strony lub administrator WordPressa. Omówimy też pośredni wpływ hostingu, CDN i bezpiecznego połączenia na wydajność, korzystając z praktycznych przykładów. Jeśli chcesz wybrać infrastrukturę nastawioną na szybkość, sprawdź Pakiety hostingu WWW, a dla projektów opartych na WordPressie rozważ Hosting WordPress.
Czym jest INP i dlaczego ma znaczenie?
INP mierzy ogólną responsywność strony podczas interakcji użytkownika. Użytkownik klika przycisk, zmienia zakładkę, otwiera menu, wpisuje dane w formularzu albo dotyka elementu na telefonie. Przeglądarka musi obsłużyć tę interakcję, uruchomić JavaScript, przeliczyć style i układ strony, a następnie wyświetlić nowy stan wizualny. Czas od interakcji do tej widocznej aktualizacji ekranu jest oceniany w ramach INP.
W poprzednich latach ważną metryką był First Input Delay, czyli FID. Problem w tym, że FID koncentrował się tylko na opóźnieniu pierwszej interakcji. INP ocenia interakcje w całym cyklu życia strony, dlatego lepiej odzwierciedla realne doświadczenie użytkownika w sklepach internetowych, blogach, panelach SaaS, serwisach firmowych i systemach członkowskich.
Progi zalecane przez Google wyglądają następująco:
| Wartość INP | Status | Co oznacza | Priorytet |
|---|---|---|---|
| 0-200 ms | Dobry | Interakcje użytkownika sprawiają wrażenie płynnych | Utrzymanie i monitoring |
| 200-500 ms | Do poprawy | Część kliknięć i dotknięć jest odczuwalnie opóźniona | Średni-wysoki |
| 500 ms i więcej | Słaby | Strona wydaje się zawieszać albo reagować z dużym opóźnieniem | Pilny |
INP ma znaczenie nie tylko dla SEO, ale również dla konwersji. Jeśli na stronie kategorii w wersji mobilnej przycisk filtra otwiera się z opóźnieniem 700 ms, użytkownik może uznać, że funkcja nie działa, kliknąć ponownie lub opuścić stronę. Z kolei interfejsy reagujące w granicach 150-180 ms są odbierane jako szybsze, bardziej profesjonalne i godne zaufania.
Jak mierzyć wynik INP?
Zanim zaczniesz optymalizować INP, potrzebujesz rzetelnego pomiaru. Narzędzia laboratoryjne pokazują przewidywane problemy, natomiast dane od realnych użytkowników uwzględniają faktyczne urządzenia, połączenia internetowe i przeglądarki. Najlepsze podejście polega na łączeniu obu typów danych.
1. Zrób szybki test w PageSpeed Insights
PageSpeed Insights pokazuje wartość INP pochodzącą z Chrome User Experience Report, jeśli dla danej strony dostępne są dane rzeczywistych użytkowników. Analizuj osobno wyniki dla urządzeń mobilnych i komputerów. Szczególnie traktuj priorytetowo dane mobilne, ponieważ na telefonach ze słabszym procesorem główny wątek przeglądarki blokuje się znacznie łatwiej. Jeśli INP strony przekracza 200 ms, zapisz wskazówki z sekcji diagnostyki i rekomendacji.
2. Monitoruj raport Core Web Vitals w Search Console
Raport Core Web Vitals w Google Search Console grupuje problemy według podobnych adresów URL. Dzięki temu możesz zobaczyć, czy kłopot dotyczy pojedynczej podstrony, czy całego szablonu. Jeśli na przykład wszystkie strony produktów mają słaby INP, przyczyną najpewniej jest motyw, skrypt koszyka, wtyczka opinii albo kod obsługujący warianty produktów.
3. Użyj panelu Performance w Chrome DevTools
Panel Performance w Chrome DevTools pozwala sprawdzić, które funkcje JavaScript uruchamiają się w chwili kliknięcia i które zadania trwające ponad 50 ms tworzą tak zwane długie zadania. Nagraj interakcję, na przykład kliknięcie menu, a następnie przeanalizuj fioletowe, żółte i zielone bloki w głównym wątku. Długie wykonywanie skryptów, powtarzające się przeliczanie stylów i kosztowne operacje layoutu to bardzo ważne sygnały przy diagnozowaniu INP.
4. Wdróż monitoring prawdziwych użytkowników
W projektach o większym ruchu bardzo wartościowy jest RUM, czyli Real User Monitoring. Za pomocą biblioteki Web Vitals możesz zbierać dane INP i analizować je według adresu URL, typu urządzenia, przeglądarki, kraju oraz konkretnego celu interakcji. Dane mogą na przykład pokazać, że tylko u użytkowników Androida kliknięcie menu mobilnego trwa 620 ms. Taka informacja pozwala naprawiać problem punktowo, zamiast robić ogólną optymalizację „na ślepo”.
Najczęstsze przyczyny słabego wyniku INP
Większość problemów z INP nie wynika bezpośrednio z czasu odpowiedzi serwera, lecz z tego, że przeglądarka ma zbyt dużo pracy w momencie interakcji użytkownika. Mimo to infrastruktura, sposób dostarczania plików, cache i zależności zewnętrzne mogą pośrednio zwiększać to obciążenie.
Ciężkie pliki JavaScript
Nowoczesne strony internetowe ładują wiele plików JavaScript: motyw, slider, czat na żywo, reklamy, analitykę, testy A/B, mapy i komponenty społecznościowe. Pliki te nie tylko się pobierają. Przeglądarka musi je sparsować, skompilować i wykonać. Jeśli ten proces zajmuje główny wątek, odpowiedź na kliknięcie użytkownika zostanie opóźniona.
Długie zadania
Zadania wykonywane w głównym wątku dłużej niż 50 ms są traktowane jako long tasks. Jedno zadanie trwające 300 ms może zatrzymać reakcję na kliknięcie. Przykładowo skrypt, który po naciśnięciu filtra przelicza po stronie klienta wszystkie 1000 produktów, może bez trudu podnieść INP powyżej 500 ms.
Złożony DOM i kosztowne operacje layoutu
Zbyt duża liczba węzłów HTML, głęboko zagnieżdżone komponenty, częste zmiany stylów i błąd znany jako layout thrashing, czyli naprzemienne odczytywanie i zapisywanie wymiarów elementów, pogarszają INP. Szczególnie narażone są megamenu, strony list produktów oraz długie aplikacje typu single page application.
Skrypty firm trzecich
Sieci reklamowe, piksele śledzące, narzędzia do map ciepła, kody live chatu i osadzenia z mediów społecznościowych uruchamiają kod, nad którym nie masz pełnej kontroli. Jeśli taki kod korzysta z głównego wątku w chwili interakcji, nawet dobrze napisany interfejs może reagować z opóźnieniem.
Przeładowane motywy i wtyczki WordPressa
Na stronach WordPress każda wtyczka może dodawać własne pliki CSS i JS. Jeśli skrypt wtyczki formularza kontaktowego jest potrzebny tylko na stronie kontaktu, ale ładuje się w całym serwisie, powstaje zbędny narzut. Podobnie edytory wizualne, slidery i wtyczki pop-up mogą znacząco obniżać mobilny wynik INP.
Jak poprawić wynik INP? Plan działania krok po kroku
Praktyczna odpowiedź na pytanie, jak poprawić wynik INP, brzmi: mierz, izoluj, ograniczaj, dziel i mierz ponownie. Poniższe kroki są ułożone według priorytetów, które zespoły techniczne najczęściej stosują w realnych projektach.
1. Znajdź najbardziej problematyczną interakcję
Najpierw ustal, która interakcja generuje słaby INP. Czy jest to menu mobilne, przycisk dodania do koszyka, panel filtrów, wyszukiwarka, a może wysłanie formularza? Podczas nagrywania w DevTools Performance powtórz daną czynność kilka razy. W nagraniu, w sekcji Event Timing lub Interaction, sprawdź cel kliknięcia oraz czas obsługi.
Konkretny przykład: w jednym sklepie internetowym przycisk filtra kategorii generował INP na poziomie 740 ms. Analiza pokazała, że po kliknięciu ponownie renderowane były wszystkie karty produktów, a jednocześnie aktualizowano 1800 węzłów DOM. Po przeniesieniu panelu filtra do osobnego komponentu i odroczeniu aktualizacji listy INP spadł do około 190 ms.
2. Zmniejsz rozmiar pakietów JavaScript
Usuwanie nieużywanego kodu to jeden z najskuteczniejszych sposobów poprawy INP. Użyj bundle analyzera, aby sprawdzić, które biblioteki najbardziej powiększają pliki. Zamiast importować całą bibliotekę, pobieraj tylko potrzebny moduł. Na przykład dużą bibliotekę do obsługi dat można czasem zastąpić lżejszą alternatywą albo natywnym API Intl.
- Wyłącz nieużywane funkcje motywu.
- Nie ładuj sliderów, galerii i skryptów animacji na stronach, gdzie nie są potrzebne.
- Korzystaj z nowoczesnych narzędzi build, które obsługują tree shaking.
- Nie wysyłaj kodu panelu administracyjnego do części widocznej dla odwiedzających.
- Stare polyfille serwuj tylko tym przeglądarkom, które faktycznie ich potrzebują.
3. Podziel długie zadania na mniejsze fragmenty
Aby przeglądarka mogła odpowiadać na interakcje użytkownika, główny wątek musi regularnie się zwalniać. Zamiast wykonywać duże obliczenia za jednym razem, podziel je na części. Możesz wykorzystać setTimeout, scheduler.postTask, requestIdleCallback albo mechanizmy harmonogramowania dostępne w używanym frameworku. Celem jest zastąpienie jednego zadania trwającego 300 ms serią mniejszych zadań po 20-40 ms.
Jeśli na przykład trzeba przefiltrować i ponownie narysować tabelę z 5000 wierszy, najpierw zaktualizuj pierwsze 50 wierszy widocznych dla użytkownika, a resztę obsłuż przez wirtualizację lub zadania w tle. Dzięki temu efekt kliknięcia pojawi się szybko, a dalsze przetwarzanie nie zablokuje doświadczenia użytkownika.
4. Uprość obsługę zdarzeń
Uruchamianie ciężkich funkcji przy każdym click, input, scroll czy keydown szybko psuje INP. Szczególnie problematyczne jest wysyłanie zapytania API po każdym znaku wpisanym w polu wyszukiwania albo przeliczanie całej listy przy każdym naciśnięciu klawisza. Zastosuj debounce i throttle, aby zmniejszyć częstotliwość wykonywania operacji.
- W polu wyszukiwania zastosuj debounce na poziomie około 300 ms.
- Dla zdarzeń scroll preferuj passive listener.
- Zamiast dodawać listener do setek pojedynczych elementów, użyj event delegation.
- Po kliknięciu najpierw pokaż wizualną informację zwrotną, a cięższą pracę uruchom później.
5. Daj użytkownikowi natychmiastowy feedback wizualny
INP jest powiązane z kolejnym odmalowaniem ekranu, dlatego po interakcji użytkownika warto jak najszybciej pokazać choćby niewielką zmianę wizualną. Aktywny stan przycisku, wskaźnik ładowania, skeleton screen albo pierwsza klatka otwierającego się panelu dają użytkownikowi sygnał, że system działa. Zamiast czekać na ciężką odpowiedź API i zmieniać cały interfejs naraz, zaprojektuj szybki feedback i stopniową aktualizację widoku.
6. Ogranicz koszt renderowania i layoutu
Na INP wpływa nie tylko JavaScript, ale również CSS i layout. Zmiana rozmiaru, położenia i stylu wielu elementów po kliknięciu bywa kosztowna. W animacjach CSS zwykle lepiej używać transform i opacity zamiast width, height, top oraz left. Przy dużych listach stosuj wirtualizację; nie trzymaj w DOM setek kart, których użytkownik aktualnie nie widzi.
Unikaj layout thrashing. Nie twórz pętli, w której najpierw odczytujesz szerokość elementu, potem zapisujesz styl, a następnie znów wykonujesz odczyt. Grupuj operacje odczytu i zapisu. Taka prosta zmiana na złożonych stronach potrafi zaoszczędzić dziesiątki milisekund.
7. Skontroluj kod firm trzecich
Dla każdego zewnętrznego skryptu zadaj pytanie: czy ten kod bezpośrednio wspiera konwersję? Jeśli jego wartość jest niska, usuń go, opóźnij albo ładuj tylko na wybranych podstronach. Kod live chatu na stronie płatności może mieć sens, ale jego uruchamianie przy pierwszym ładowaniu każdego wpisu blogowego nie zawsze jest potrzebne. Skrypty reklamowe i analityczne, jeśli to możliwe, ładuj z defer lub async i nie pozwalaj im blokować krytycznych interakcji.
8. Przenieś ciężkie obliczenia do Web Workera
Jeśli filtrowanie produktów, przetwarzanie dużego JSON-a, szyfrowanie, transformacja danych albo złożone obliczenia blokują główny wątek, rozważ użycie Web Workera. Worker wykonuje takie zadania w tle, a główny wątek może nadal reagować na interakcje użytkownika. Nie każdą operację trzeba przenosić do Workera, ale dla zadań zużywających ponad 100 ms CPU korzyści mogą być bardzo wyraźne.
9. Zoptymalizuj koszt frameworka i hydration
W aplikacjach opartych na React, Vue, Angular, Next.js czy Nuxt koszt hydration po pierwszym załadowaniu może wpływać na INP. Zamiast zamieniać całą stronę w interaktywną aplikację, rozważ island architecture, partial hydration albo server components. Treści, które nie wymagają interakcji, pozostaw statyczne. Elementy takie jak modal, sekcja komentarzy lub komponent rekomendacji często lepiej ładować dopiero wtedy, gdy użytkownik ich potrzebuje.
10. Zmniejsz obciążenie wtyczkami na stronach WordPress
Jeśli korzystasz z WordPressa, zacznij optymalizację INP od inwentaryzacji wtyczek. Usuń rozszerzenia, które robią to samo. Sprawdź, czy wtyczki formularzy, galerii, sliderów i pop-upów nie ładują swoich plików na wszystkich podstronach. Wtyczki wydajnościowe z funkcją asset unload pozwalają wyłączać niepotrzebne pliki CSS i JS na poziomie konkretnych stron.
Przykład z praktyki: na stronie firmowej WordPress wynik INP strony głównej na urządzeniach mobilnych wynosił 560 ms. Usunięto wtyczkę slidera i zbudowano sekcję hero jako lekkie HTML/CSS, opóźniono skrypt pop-upu o 5 sekund, a plik JS formularza kontaktowego ładowano tylko na stronie kontaktu. W efekcie mobilny INP spadł do 210 ms, a po kolejnych drobnych poprawkach do 175 ms.
Jak hosting i infrastruktura wpływają na wynik INP?
INP jest przede wszystkim metryką responsywności po stronie klienta, więc decydujące znaczenie ma obciążenie głównego wątku w przeglądarce. Nie oznacza to jednak, że hosting nie ma żadnego znaczenia. Szybka odpowiedź serwera, prawidłowe cache, aktualna wersja PHP, obsługa HTTP/2 lub HTTP/3, CDN i kompresja sprawiają, że pliki są dostarczane szybciej i bardziej przewidywalnie. To pomaga utrzymać główny wątek pod większą kontrolą szczególnie podczas pierwszego ładowania.
Na słabej infrastrukturze wysokie TTFB, późno docierające zasoby, niestabilne działanie cache i duże obciążenie serwera pogarszają doświadczenie użytkownika. WordPress bez cache, który przy każdym żądaniu wykonuje ciężkie operacje PHP i zapytania do bazy danych, później osiąga stan gotowości do interakcji. Dlatego optymalizacji INP nie warto całkowicie oddzielać od optymalizacji LCP i TTFB.
- Korzystaj z cache po stronie serwera.
- Wybieraj PHP 8.x i aktualne wersje bazy danych.
- Serwuj pliki statyczne przez CDN.
- Włącz kompresję Brotli lub Gzip.
- Utrzymuj aktualną konfigurację SSL/TLS; w sprawie bezpiecznego połączenia sprawdź Certyfikat SSL.
- Jeśli uruchamiasz nowy projekt lub stronę marki, użyj narzędzia Sprawdzanie domen, aby wybrać właściwą domenę.
Tabela priorytetów dla optymalizacji INP
Poniższa tabela podsumowuje, które usprawnienia zwykle warto wdrażać w pierwszej kolejności na typowej stronie internetowej. W każdym projekcie efekty mogą być inne, dlatego po zmianach ponownie sprawdzaj PageSpeed Insights, Search Console i dane rzeczywistych użytkowników.
| Problem | Objaw | Rozwiązanie | Oczekiwany wpływ |
|---|---|---|---|
| Ciężki JavaScript | Kliknięcia reagują z opóźnieniem | Code splitting, usuwanie nieużywanego kodu, defer | Wysoki |
| Długie zadania | W DevTools widać bloki powyżej 50 ms | Dzielenie zadań, API harmonogramowania | Wysoki |
| Skrypty firm trzecich | Analityka, reklamy lub czat zajmują główny wątek | Opóźnienie, ładowanie zależne od strony, usunięcie | Średni-wysoki |
| Złożony DOM | Menu, filtry lub aktualizacje list działają wolno | Uproszczenie DOM, wirtualizacja list | Średni-wysoki |
| Nadmiar wtyczek WordPress | Na każdej stronie ładują się zbędne CSS/JS | Porządki we wtyczkach, asset unload | Średni |
| Słaba infrastruktura | Zasoby docierają późno, cache działa niestabilnie | Dobry hosting, CDN, cache | Pośredni, ale ważny |
Techniczna checklista dla programistów
Usprawnianie INP warto zamienić w checklistę, którą zespół może regularnie kontrolować. W przeciwnym razie jednorazowa optymalizacja szybko zostanie zniweczona przez nowe wtyczki, kody kampanii i zmiany projektowe.
- Dla każdego krytycznego szablonu ustaw cel mobilnego INP poniżej 200 ms.
- W procesie pull request kontroluj wzrost rozmiaru bundle.
- Przed dodaniem nowego skryptu firm trzecich testuj jego wpływ na wydajność.
- Za pomocą DevTools Performance mierz przynajmniej menu mobilne, wyszukiwarkę, formularze i interakcje zakupowe.
- Staraj się skracać długie zadania poniżej 50 ms; jeśli to niemożliwe, dziel je na mniejsze fragmenty.
- W animacjach preferuj transform i opacity.
- Dla dużych list stosuj paginację, infinite scroll albo virtualization.
- Raportuj dane RUM co miesiąc i monitoruj ostrzeżenia w Search Console.
Najczęstsze błędy przy optymalizacji INP
Instalowanie wyłącznie wtyczki cache
Cache jest ważny, ale nie jest jedynym lekarstwem na słaby INP. Pamięć podręczna może przyspieszyć dostarczenie strony, lecz nie naprawi automatycznie ciężkiego kodu JavaScript wykonywanego po kliknięciu użytkownika. Dlatego cache trzeba traktować jako element większej optymalizacji kodu.
Patrzenie tylko na wynik laboratoryjny i ignorowanie użytkowników
Testy Lighthouse są przydatne, ale same w sobie nie wystarczają. Prawdziwi użytkownicy korzystają z różnych urządzeń, sieci i przeglądarek. Szczególnie tańsze telefony z Androidem potrafią ujawnić problemy z INP, których nie widać w testach na komputerze.
Losowe opóźnianie wszystkich skryptów
Techniki defer i delay trzeba stosować ostrożnie. Zła konfiguracja może zepsuć menu, koszyk, formularz albo proces płatności. Skrypty odpowiedzialne za krytyczne interakcje należy chronić, a kod zbędny i zewnętrzny opóźniać w kontrolowany sposób.
Skupienie na obrazach i pomijanie interakcji
Kompresja obrazów jest bardzo cenna dla LCP, ale nie zawsze rozwiązuje problem INP. Jeśli kłopotem jest kod uruchamiany po kliknięciu, sama optymalizacja grafik nie wystarczy. Core Web Vitals należy traktować całościowo.
Strategia SEO z naciskiem na INP w 2026 roku
W podejściu SEO na 2026 rok techniczna wydajność, jakość treści i niezawodna infrastruktura są oceniane razem. Google AI Overviews i coraz bardziej zaawansowane doświadczenia wyszukiwania premiują strony, które dostarczają użytkownikowi najszybszą i najbardziej satysfakcjonującą odpowiedź. Dlatego optymalizacja INP nie jest wyłącznie zadaniem programistów. To wspólna odpowiedzialność zespołów SEO, UX, contentu i infrastruktury.
We wpisie blogowym spis treści, filtr kategorii lub formularz komentarzy powinny działać szybko. W sklepie internetowym wybór rozmiaru, zmiana wariantu i dodanie do koszyka muszą reagować niemal natychmiast. Na stronach firmowych formularz wyceny, menu mobilne i przyciski kontaktowe nie powinny się opóźniać. Jeśli użytkownik czuje, że strona działa szybko, zostaje dłużej, odwiedza więcej podstron i częściej konwertuje.
Po stronie Hostragons możesz zbudować solidną podstawę pod techniczne SEO, wybierając hosting nastawiony na wydajność, aktualne technologie serwerowe i bezpieczną infrastrukturę. Zarządzanie domeną, hostingiem i konfiguracją bezpieczeństwa z jednego miejsca zmniejsza obciążenie operacyjne, dzięki czemu zespół może bardziej skupić się na doświadczeniu użytkownika i jakości treści. Sprawdź powiązane rozwiązania: Hosting dla firm, Serwer VPS oraz Certyfikat SSL.
Podsumowanie
Sednem poprawy wyniku INP jest niedopuszczanie do tego, aby w chwili interakcji użytkownika przeglądarka wykonywała niepotrzebnie dużo pracy. Najpierw znajdź najwolniejsze interakcje na podstawie realnych danych, a następnie zmniejsz obciążenie JavaScript, podziel długie zadania, uprość obsługę zdarzeń, ogranicz koszt renderowania i przejmij kontrolę nad kodem firm trzecich. Hosting, cache, CDN i aktualna konfiguracja bezpieczeństwa tworzą mocną podstawę, która wspiera cały proces.
Jeśli chcesz, aby Twoja strona była szybsza, bardziej niezawodna i przyjaźniejsza dla użytkowników, zacznij od małego pomiaru: sprawdź mobilny INP najważniejszej podstrony i wdroż pierwsze trzy kroki z tego poradnika. Po stronie infrastruktury możesz przejrzeć rozwiązania Hostragons i spokojnie porównać plany hostingowe dopasowane do potrzeb Twojego projektu.
Najczęściej zadawane pytania
Jaki powinien być dobry wynik INP?
Dobry wynik INP to 200 ms lub mniej. Zakres 200-500 ms oznacza obszar wymagający poprawy, a wartości powyżej 500 ms wskazują na słabe doświadczenie użytkownika. Szczególnie ważne są dane od użytkowników mobilnych.
Czym różni się INP od FID?
FID mierzy wyłącznie opóźnienie pierwszej interakcji użytkownika, natomiast INP ocenia jakość reakcji na interakcje w całym cyklu życia strony. Dlatego INP znacznie pełniej odzwierciedla rzeczywiste doświadczenie użytkowników.
Dlaczego strony WordPress często mają słaby INP?
Najczęściej przyczyną jest nadmiar wtyczek, ciężki motyw, zbędne pliki CSS/JS ładowane na wszystkich stronach, slidery, skrypty pop-up i kod firm trzecich. Dużą poprawę dają porządki we wtyczkach, wyłączanie plików per podstrona i używanie lekkiego motywu.
Czy zmiana hostingu poprawi wynik INP?
Hosting sam w sobie nie naprawi ciężkiego JavaScriptu ani długich zadań w przeglądarce. Szybki serwer, dobre cache, CDN, aktualne PHP i stabilne dostarczanie zasobów wspierają jednak optymalizację INP. Wpływ jest więc pośredni, ale szczególnie na stronach WordPress bardzo istotny.
Po jakim czasie widać efekty optymalizacji INP?
Po poprawkach w kodzie i wtyczkach efekty w testach laboratoryjnych można zobaczyć od razu. W Search Console i danych rzeczywistych użytkowników Chrome zmiana zwykle pojawia się po kilku tygodniach, ponieważ system musi zebrać wystarczającą liczbę nowych danych.