- Dlaczego długi main thread pogarsza INP i co to naprawdę oznacza
- INP nie jest tym samym co TBT, ale oba wskaźniki są ze sobą powiązane
- Najczęstsze przyczyny długiego main thread na współczesnych stronach
- Jak mierzyć długi main thread i poprawę INP bez błędnej interpretacji danych
- Jak czytać PageSpeed Insights, Lighthouse i Search Console przy diagnozie INP
- Dlaczego dane laboratoryjne i dane rzeczywistych użytkowników bywają sprzeczne
- Co wdrażać w pierwszej kolejności, aby realnie skrócić pracę main thread
- Ograniczanie ciężkiego JavaScript, hydration i skryptów zewnętrznych
- Usprawnienie interakcji, eventów i operacji na DOM
- Jak połączyć poprawę INP z LCP, CLS i ogólną strategią wydajności
- CSS, fonty, serwer i zasoby krytyczne też wpływają na odczuwaną responsywność
- Stały monitoring, testy regresji i decyzje biznesowe po wdrożeniu zmian
Fraza „Jak ograniczyć długi main thread i poprawić INP?” pojawia się dziś bardzo często w audytach technicznych, bo nowoczesne strony i aplikacje coraz częściej cierpią nie tyle na sam czas ładowania, ile na opóźnioną reakcję interfejsu. W tym artykule wyjaśnię, skąd bierze się przeciążenie głównego wątku przeglądarki, jak mierzyć problem w narzędziach takich jak PageSpeed Insights i Lighthouse, oraz które działania realnie poprawiają Interaction to Next Paint, czyli INP, bez psucia funkcji strony.
Dlaczego długi main thread pogarsza INP i co to naprawdę oznacza
Jeśli ktoś pyta, jak ograniczyć długi main thread i poprawić INP, to w praktyce pyta o to, dlaczego strona reaguje z opóźnieniem na kliknięcie, dotknięcie ekranu albo wpisywanie tekstu. Główny wątek przeglądarki, czyli JavaScript main thread, obsługuje bardzo wiele zadań naraz: wykonuje kod JavaScript, przelicza style, układa layout, uruchamia część logiki interakcji i przygotowuje kolejne etapy renderowanie strony. Gdy ten wątek jest przeciążony, przeglądarka nie może od razu odpowiedzieć na działanie użytkownika, nawet jeśli sam interfejs wydaje się już „załadowany”.
To właśnie tutaj wchodzi Core Web Vitals. W ramach podstawowych wskaźników internetowych każdy wskaźnik mierzy inny aspekt doświadczenia użytkownika. Largest Contentful Paint, czyli LCP, dotyczy tego, jak szybko pojawia się kluczowa treść na pierwszym ekranie. Cumulative Layout Shift, czyli CLS, mówi o stabilności wizualnej i o tym, czy elementy nie przeskakują podczas ładowania. Natomiast INP koncentruje się na responsywności interakcji. Użytkownik nie ocenia strony wyłącznie po tym, czy coś się pokazało, ale po tym, czy da się z nią sprawnie wejść w interakcję. Właśnie dlatego można mieć przyzwoite FCP albo niezły LCP, a mimo to słabe odczucie szybkości.
W praktyce długi main thread najczęściej oznacza zbyt ciężki frontend. Problem pojawia się w serwisach opartych o rozbudowane frameworki, w aplikacjach typu Single Page Application, w projektach z agresywną hydration po stronie klienta, a także tam, gdzie bez kontroli dodawano kolejne skrypty analityczne, marketingowe, chaty, testy A/B, piksele reklamowe i widżety zewnętrzne. Każdy taki element może wydawać się drobny, ale suma obciążeń zabiera czas procesora użytkownika, szczególnie na słabszych telefonach i przy gorszym mobile performance.
Masz pytania? Porozmawiajmy o Twoim marketingu
Skontaktuj się ze mną!
Katarzyna Toboła
INP nie jest tym samym co TBT, ale oba wskaźniki są ze sobą powiązane
W raportach laboratoryjnych często widzisz Total Blocking Time, czyli TBT, i zastanawiasz się, czy wysoki TBT oznacza słaby INP. Odpowiedź brzmi: często tak, ale nie zawsze. TBT to wskaźnik z lab data, który pokazuje, ile czasu przeglądarka była blokowana przez długie zadania na main thread podczas ładowania strony. Z kolei INP jest wskaźnikiem opartym przede wszystkim o dane rzeczywistych użytkowników, czyli field data, i mierzy opóźnienie reakcji na interakcję w realnych warunkach użytkowania.
Wysoki TBT jest bardzo dobrym sygnałem ostrzegawczym. Pokazuje, że JavaScript długo blokuje możliwość reakcji. Jeżeli jednak problem z interakcją pojawia się już po pełnym załadowaniu widoku, na przykład po otwarciu filtrów, koszyka, modułu opinii albo menu mobilnego, to samo TBT nie musi oddać skali problemu. Dlatego Lighthouse i PageSpeed Insights są świetne diagnostycznie, ale nie dają pełnego obrazu tego, co naprawdę odczuwają użytkownicy przez cały cykl korzystania ze strony.
Najczęstsze przyczyny długiego main thread na współczesnych stronach
Najczęściej winne są zbyt duże paczki JavaScript, nieefektywna optymalizacja JavaScript, nadmiar bibliotek, ciężkie komponenty UI oraz skrypty zewnętrzne uruchamiane zbyt wcześnie. Częstym problemem jest również pełna hydration interfejsu, gdy przeglądarka po stronie klienta musi odtworzyć logikę dla ogromnej liczby komponentów, zanim strona stanie się naprawdę interaktywna. Dotyczy to zwłaszcza frameworków, które źle zarządzają podziałem kodu, kolejnością inicjalizacji i zależnościami.
Druga grupa problemów to kosztowne operacje DOM. Jeśli kliknięcie przycisku wywołuje wiele obliczeń, modyfikuje setki elementów, wymusza synchronizację layoutu albo uruchamia kilka niezależnych listenerów, reakcja będzie opóźniona. Trzecia grupa to skrypty niezwiązane bezpośrednio z funkcją użytkownika, ale działające stale w tle: monitorowanie zachowań, reklamy, rekomendacje, personalizacja, popupy, moduły recenzji czy osadzone narzędzia zewnętrzne. W e-commerce to bardzo częsty scenariusz, bo każda kolejna integracja może pogarszać UX, nawet jeśli biznesowo wydaje się uzasadniona.
Jak mierzyć długi main thread i poprawę INP bez błędnej interpretacji danych
Skuteczna optymalizacja zaczyna się od dobrego pomiaru. Jeśli chcesz wiedzieć, jak ograniczyć długi main thread i poprawić INP, nie możesz patrzeć wyłącznie na jeden test syntetyczny ani na pojedynczy wynik 100/100. Trzeba rozumieć różnicę między danymi laboratoryjnymi i terenowymi oraz między sygnałami diagnostycznymi a realnym doświadczeniem użytkownika. To szczególnie ważne w 2026 roku, gdy strony są bardziej dynamiczne, częściej korzystają z aplikacyjnego frontendu, a ścieżki użytkowników są rozproszone między stronami listingu, kartami produktu, wyszukiwarką, koszykiem i checkoutem.
PageSpeed Insights łączy dwa światy. Pokazuje field data z Chrome UX Report, znanego też jako CrUX, jeśli dla danej strony lub grupy adresów jest dostępna odpowiednia próbka użytkowników Chrome. Pokazuje też lab data oparte o Lighthouse, czyli kontrolowany test w warunkach symulowanych. Dane rzeczywiste są świetne do oceny, czy użytkownicy naprawdę odczuwają problem z INP, LCP lub CLS. Dane laboratoryjne są potrzebne, by zrozumieć, gdzie i dlaczego przeglądarka się blokuje oraz które zasoby są temu winne.
Jak czytać PageSpeed Insights, Lighthouse i Search Console przy diagnozie INP
W PageSpeed Insights warto zacząć od sekcji field data. Tam sprawdzasz, czy problem dotyczy rzeczywistego INP, a nie tylko laboratoryjnego TBT. Jeśli widać słabe wyniki dla urządzeń mobilnych, jest to mocny sygnał, że użytkownicy na realnych telefonach cierpią przez przeciążony frontend. Następnie przechodzisz do danych laboratoryjnych i patrzysz na long tasks, treemap bundli, blokowanie main thread, zbędne skrypty oraz czas wykonania JavaScript.
Google Search Console z raportem Core Web Vitals pomaga spojrzeć szerzej. To nie jest narzędzie do śledzenia pojedynczej interakcji, ale dobrze pokazuje, które typy stron mają problem systemowy. Często okazuje się, że nie wszystkie adresy cierpią tak samo. Strona główna może być względnie lekka, a strony kategorii z filtrami, listingi produktów albo rozbudowane landing pages marketingowe mają wyraźnie gorsze parametry. Taka segmentacja jest ważniejsza niż poprawianie „wszystkiego po trochu”.
W Chrome DevTools i profilerze wydajności warto nagrać konkretną interakcję. Widać wtedy, co dzieje się po kliknięciu: czy problemem jest event handler, kosztowne przeliczanie layoutu, długi task JavaScript, opóźnione malowanie, czy może łańcuch asynchronicznych zadań uruchamianych po kolei. Taka analiza bywa znacznie cenniejsza niż samo odczytanie zaleceń z Lighthouse, ponieważ pokazuje realny mechanizm problemu, a nie tylko objaw.
Dlaczego dane laboratoryjne i dane rzeczywistych użytkowników bywają sprzeczne
Różnice między lab data a field data są czymś normalnym. Test Lighthouse uruchamiasz w określonym środowisku, na jednej konfiguracji sprzętowej i jednej ścieżce ładowania. Tymczasem rzeczywisty użytkownik korzysta z różnych urządzeń, sieci, regionów geograficznych, ma inne obciążenie CPU, inne zachowania i inne momenty interakcji. Strona może wypaść nieźle w laboratorium, a słabo w CrUX, jeśli największy problem pojawia się po kilku sekundach lub na etapie używania filtrów, galerii, mapy czy formularza.
Możliwa jest też sytuacja odwrotna: słaby syntetyczny wynik nie musi oznaczać katastrofy biznesowej, jeśli użytkownicy na kluczowych ścieżkach nie odczuwają opóźnień. Dlatego audyt Core Web Vitals powinien być połączony z analizą zachowania użytkowników, danymi o konwersji oraz priorytetami biznesowymi. SEO techniczne i wydajność mają znaczenie, ale nie działają w próżni. Lepsze wskaźniki pomagają stronie, jednak nie zastąpią trafnej treści, dobrej architektury informacji, dopasowania do intencji wyszukiwania ani sensownego UX.
Co wdrażać w pierwszej kolejności, aby realnie skrócić pracę main thread
W praktyce największy błąd polega na optymalizowaniu wszystkiego naraz. Jeśli chcesz naprawdę poprawić wydajność strony, musisz ustawić priorytety. Najpierw identyfikujesz zasoby i interakcje, które generują największy koszt CPU. Dopiero potem decydujesz, co usunąć, co opóźnić, co przepisać i co przenieść poza krytyczną ścieżkę renderowania. To podejście jest znacznie skuteczniejsze niż przypadkowa minifikacja plików czy ślepe wdrażanie kolejnych pluginów „na szybkość”.
Pierwszym obszarem jest redukcja JavaScript dostarczanego na start. Jeśli użytkownik widzi prosty widok, nie powinien pobierać i wykonywać kodu od zaawansowanych modułów, które uruchomią się dopiero później. Kod należy dzielić według widoków, komponentów i akcji użytkownika. Lazy loading skryptów, importy dynamiczne i opóźniona inicjalizacja funkcji to często najszybsza droga do zysku. Nie chodzi o usunięcie wszystkich skryptów, lecz o rozdzielenie krytycznych i niekrytycznych zależności.
Ograniczanie ciężkiego JavaScript, hydration i skryptów zewnętrznych
Najwięcej zysku zwykle daje audyt bundli JavaScript. Warto sprawdzić, czy framework, biblioteki UI, polyfille, walidatory, edytory, moduły wyszukiwania i analityka nie są ładowane tam, gdzie nie są potrzebne. Czasem ogromną poprawę daje zamiana jednej ciężkiej biblioteki na lżejszy odpowiednik albo przeniesienie części logiki na backend. Dotyczy to zwłaszcza zaawansowanych filtrów, rekomendacji, konfiguratorów i modułów personalizacji.
Jeżeli serwis korzysta z pełnej hydration po stronie klienta, warto rozważyć bardziej selektywne podejście. Coraz częściej stosuje się partial hydration, islands architecture, server-side rendering albo static site generation tam, gdzie zawartość nie wymaga rozbudowanej interakcji. Dzięki temu użytkownik szybciej widzi treść, a przeglądarka ma mniej pracy na starcie. To ważne nie tylko dla INP, ale pośrednio także dla LCP i ogólnej płynności działania.
Osobny temat to skrypty zewnętrzne. Piksele reklamowe, tag manager, narzędzia heatmap, live chat, testy A/B, osadzone recenzje, mapy, player wideo i zewnętrzne widżety bardzo często odpowiadają za długi main thread. Nie oznacza to, że trzeba je wszystkie usuwać. Trzeba natomiast sprawdzić, które są krytyczne biznesowo, które można ładować po interakcji, które można opóźnić do momentu bezczynności przeglądarki i które powodują najwięcej szkód na mobile. To jest prawdziwa optymalizacja, a nie ideologiczne „mniej skryptów za wszelką cenę”.
Usprawnienie interakcji, eventów i operacji na DOM
Nawet przy umiarkowanej liczbie skryptów można mieć słaby INP, jeśli pojedyncza interakcja uruchamia zbyt dużo pracy. Warto uprościć event handlery, ograniczyć liczbę re-renderów komponentów, batchingować aktualizacje stanu i unikać wymuszania synchronicznego layoutu. Jeśli aplikacja po każdym kliknięciu przelicza duże fragmenty DOM albo odświeża cały widok zamiast małego komponentu, główny wątek będzie blokowany.
Dobrą praktyką jest też rozdzielanie cięższych zadań na mniejsze porcje. Jeśli jakaś funkcja nie musi wykonać się natychmiast, można ją odłożyć na później lub rozbić tak, aby nie tworzyć jednego długiego taska. W niektórych przypadkach warto użyć Web Workers do zadań obliczeniowych niezwiązanych bezpośrednio z UI. Dzięki temu przeglądarka może szybciej odpowiedzieć na interakcję, a użytkownik widzi reakcję interfejsu bez frustrującej zwłoki.
Jak połączyć poprawę INP z LCP, CLS i ogólną strategią wydajności
Optymalizacja INP nie powinna być oderwana od reszty strony. Wiele problemów z responsywnością ma wspólne źródła z problemami dotyczącymi zasobów krytycznych, ładowania fontów, CSS czy odpowiedzi serwera. Jeśli na starcie pobierasz ciężkie obrazy, blokujące style i duże porcje JavaScript, cierpi nie tylko LCP, ale również późniejsza interaktywność. Dlatego skuteczny audyt musi patrzeć na cały critical rendering path, a nie tylko na jeden wskaźnik z dashboardu.
W przypadku LCP ważne są hero image, preload kluczowego obrazu, odpowiednie formaty takie jak format WebP lub format AVIF, właściwe wymiary, srcset i sizes. Gdy największy element na ekranie ładuje się zbyt późno, użytkownik już na wejściu ma poczucie ociężałości. Jeśli dodatkowo duże obrazy walczą o pasmo z plikami JavaScript, pogarsza się zarówno szybkość ładowania strony, jak i gotowość do interakcji. Dlatego optymalizacja obrazów nadal ma znaczenie, nawet jeśli główny temat dotyczy main thread.
CSS, fonty, serwer i zasoby krytyczne też wpływają na odczuwaną responsywność
Blokujące renderowanie arkusze stylów wydłużają moment, w którym użytkownik widzi stabilny interfejs. Nadmiar CSS, nieużywany kod, zła kolejność ładowania stylów i ciężkie frameworki frontendowe zwiększają koszt renderowania. Dobrze przygotowany critical CSS, odłożenie mniej ważnych stylów i sensowna minifikacja plików pomagają nie tylko w ładowaniu, ale także w sprawniejszym działaniu na słabszych urządzeniach. To samo dotyczy fontów: preload tylko dla naprawdę potrzebnych plików, ograniczenie liczby wariantów i właściwe font-display zmniejszają ryzyko opóźnień oraz nagłych przesunięć elementów.
Z perspektywy zaplecza technicznego nie można ignorować serwera. Słaby TTFB, brak efektywnego cache, przeciążony hosting, wolna baza danych i nieoptymalne odpowiedzi API sprawiają, że frontend dłużej czeka na dane, a potem często w krótkim czasie musi przetworzyć ich dużą porcję. Lepsza konfiguracja backendu, cache serwera, edge caching i dobrze ustawiony CDN skracają czas oczekiwania i stabilizują działanie serwisu dla użytkowników z różnych lokalizacji. W nowoczesnych wdrożeniach wydajność to nie tylko frontend, ale cały łańcuch dostarczenia treści.
Stały monitoring, testy regresji i decyzje biznesowe po wdrożeniu zmian
Poprawa INP nie kończy się na jednym wdrożeniu. Każda nowa integracja marketingowa, przebudowa komponentu, aktualizacja frameworka czy zmiana sposobu ładowania danych może przywrócić problem. Dlatego po wdrożeniach potrzebny jest monitoring. Warto śledzić nie tylko Lighthouse w CI, ale też realne field data, sygnały z CrUX, raporty z Search Console, własne web-vitals w analityce oraz wydajność kluczowych szablonów na urządzeniach mobilnych.
Coraz większą rolę odgrywa też automatyzacja. Narzędzia oparte o AI mogą pomóc porządkować raporty, wskazywać anomalie, wykrywać wzrost czasu wykonania JavaScript czy generować checklisty dla zespołu. Trzeba jednak zachować ostrożność. Automatyczne rekomendacje bywają zbyt ogólne i nie rozumieją kontekstu biznesowego. Nie należy wdrażać ich bez środowiska testowego, kopii zapasowej i kontroli wpływu na funkcjonalność. Wydajność ma wspierać produkt, a nie go okaleczać.
W serwisach e-commerce szczególnie ważne jest to, aby mierzyć wpływ optymalizacji na strony kategorii, karty produktów, koszyk i checkout. Czasem skrypt, który lekko pogarsza wskaźniki, jest potrzebny do działania sprzedaży, a czasem odwrotnie: moduł uznawany za „niezbędny” realnie obniża konwersję przez wolne filtry lub opóźnione reakcje przy dodawaniu do koszyka. Dlatego najlepsza strategia to połączenie analizy technicznej, UX, danych o zachowaniu użytkowników i priorytetów biznesowych. Wtedy pytanie „Jak ograniczyć długi main thread i poprawić INP?” przestaje być tylko zagadnieniem deweloperskim, a staje się elementem świadomego rozwoju jakości serwisu i jego widoczności w Google.
Masz pytania? Porozmawiajmy o Twoim marketingu
Skontaktuj się ze mną!
Jacek Kałuża