JavaScript blokujący renderowanie: jak znaleźć ciężkie skrypty

Render blocking JavaScript w sklepie: od czego zacząć diagnozę

Gdy w narzędziach diagnostycznych sprawdzasz render blocking JavaScript w sklepie, nie chodzi wyłącznie o znalezienie największego pliku JS. Trzeba ustalić, w którym momencie skrypt jest pobierany, kiedy zostaje wykonany i czy jego działanie jest potrzebne do pokazania pierwszego widoku strony. Zwykły skrypt bez async lub defer może zatrzymać parser HTML, ponieważ przeglądarka musi pobrać, przeanalizować i wykonać kod, zanim będzie mogła kontynuować przetwarzanie dokumentu.

W sklepie internetowym problem jest bardziej złożony niż na prostej stronie firmowej. Kod może pochodzić z motywu, platformy sklepowej, modułu płatności, systemu analitycznego, narzędzia reklamowego, czatu, rekomendacji produktów albo zewnętrznego widgetu. Czasem właściciel sklepu nie wie nawet, że dany skrypt jest ładowany, ponieważ został dodany przez wtyczkę kilka miesięcy wcześniej.

Pierwszym krokiem jest więc nie usuwanie JavaScriptu, ale ustalenie jego pochodzenia i funkcji. Dopiero później można zdecydować, czy skrypt powinien zostać załadowany natychmiast, odroczony, uruchamiany po interakcji użytkownika albo całkowicie usunięty.

Jak znaleźć render blocking JavaScript

Najprościej rozpocząć od Chrome DevTools. Otwórz stronę sklepu, wybierz narzędzia deweloperskie i przejdź do zakładki Network. Włącz przeładowanie strony i obserwuj żądania typu JS. Dobrze wykonać test na stronie głównej, stronie kategorii oraz karcie produktu, ponieważ każda z tych stron może ładować inny zestaw skryptów.

W kolumnie z nazwą zasobu sprawdzisz adres pliku. Nazwa często od razu sugeruje źródło, ale nie zawsze. analytics, gtag, facebook, hotjar, chat, reviews czy recommendations mogą wskazywać na zewnętrzne integracje. Nazwy typu frontend, theme, bundle, main lub vendor częściej oznaczają kod motywu albo większy pakiet biblioteki.

Następnie sprawdź kolejność żądań oraz ich czas. Sam rozmiar pliku nie odpowiada jeszcze na pytanie, czy skrypt blokuje pierwszy render. Mały skrypt załadowany synchronicznie w <head> może być bardziej problematyczny dla początkowego renderowania niż większy plik uruchamiany później.

Warto również sprawdzić kod HTML strony i poszukać elementów <script>. Zwróć uwagę na różnicę między:

<script src="/js/sklep.js"></script>

a:

<script src="/js/sklep.js" defer></script>

oraz:

<script src="/js/analityka.js" async></script>

Pierwszy wariant jest synchroniczny. Przeglądarka zatrzymuje parser w miejscu wystąpienia skryptu i wykonuje kod przed dalszym przetwarzaniem dokumentu. defer pozwala pobierać plik podczas dalszego parsowania HTML, a wykonanie przesuwa na później. async również pozwala pobierać skrypt niezależnie od parsowania, ale po pobraniu kod może zostać wykonany od razu, bez zachowania kolejności innych skryptów.

To rozróżnienie ma znaczenie przy sklepie. Skrypt odpowiedzialny za element, który musi działać natychmiast, może wymagać wcześniejszego uruchomienia. Kod analityczny, widget opinii znajdujący się pod opisem produktu albo skrypt czatu niekoniecznie musi być gotowy przed wyświetleniem pierwszego widoku.

Jeżeli wykonujesz audyt techniczny sklepu internetowego, sprawdź JavaScript razem z HTML, CSS, obrazami i zasobami zewnętrznymi. Problem renderowania często wynika z zależności między tymi elementami, a nie z jednego pliku JS działającego w oderwaniu od reszty strony.

Które skrypty blokują renderowanie

Nie każdy skrypt znaleziony w raporcie wydajności należy traktować tak samo. Najpierw podziel kod na kilka grup według tego, co robi na stronie.

Kod potrzebny do pierwszego widoku powinien być ładowany tak, aby nie opóźniać bez potrzeby podstawowego działania strony. Przykładem może być niewielki skrypt odpowiadający za podstawową funkcję interfejsu, która jest widoczna natychmiast po wejściu na stronę. Jeżeli jego brak powoduje nieprawidłowe działanie widocznego elementu, odroczenie może być niewłaściwym rozwiązaniem.

Kod potrzebny dopiero po załadowaniu DOM często nadaje się do defer. Dotyczy to wielu skryptów, które wyszukują elementy strony, dodają obsługę zdarzeń albo uruchamiają komponenty po zakończeniu parsowania dokumentu. Trzeba jednak sprawdzić zależności. Jeżeli jeden skrypt korzysta z biblioteki załadowanej wcześniej, kolejność nadal ma znaczenie.

Niezależne skrypty zewnętrzne często mogą działać z async. Dotyczy to części narzędzi analitycznych i marketingowych, ale nie można stosować tej zasady bez sprawdzenia sposobu działania konkretnej integracji. async nie gwarantuje kolejności wykonania, więc dwa zależne od siebie pliki mogą przestać działać prawidłowo.

Skrypty uruchamiane po interakcji można ładować dopiero wtedy, gdy użytkownik faktycznie korzysta z funkcji. Dobrym przykładem jest rozbudowany widget, który pojawia się dopiero po kliknięciu, otwarciu formularza albo rozwinięciu sekcji. Nie ma powodu wykonywać całej jego logiki przed pierwszym kontaktem użytkownika z takim elementem.

Skrypty marketingowe i trackingowe wymagają osobnej analizy. Sam fakt, że kod pochodzi z Google, Meta albo innej popularnej usługi, nie oznacza, że powinien być wykonywany w pierwszych momentach ładowania. Sprawdź, jakie dane zbiera, kiedy są potrzebne i czy jego opóźnienie wpływa na działanie kampanii lub pomiar zdarzeń.

Co pokazuje Network i Performance w DevTools

Zakładka Network odpowiada przede wszystkim na pytanie, jakie zasoby są pobierane. Do analizy zachowania JavaScriptu przydaje się także zakładka Performance. Po nagraniu ładowania strony zobaczysz aktywność głównego wątku przeglądarki oraz momenty wykonywania kodu.

Jeżeli po pobraniu pliku pojawia się długi blok pracy JavaScriptu, trzeba sprawdzić, co dokładnie robi kod. Duży plik nie zawsze oznacza długie wykonanie. Z kolei niewielki skrypt może uruchamiać kosztowne operacje na DOM, wykonywać wiele obliczeń albo inicjalizować kolejne biblioteki.

Przy diagnozie sprawdzaj szczególnie:

• moment rozpoczęcia pobierania skryptu,
• czas pobierania,
• moment wykonania,
• czas pracy głównego wątku,
• zależności od innych bibliotek,
• źródło skryptu,
• elementy strony, które skrypt modyfikuje,
• zachowanie strony po opóźnieniu lub wyłączeniu skryptu w środowisku testowym.

Przydatny jest również raport Lighthouse lub PageSpeed Insights. Jeżeli pojawia się wskazanie dotyczące render-blocking resources, nie traktuj listy jako automatycznej instrukcji usuwania wszystkich wymienionych plików. Raport wskazuje zasoby uczestniczące w ścieżce ładowania, ale decyzja wymaga sprawdzenia funkcji konkretnego kodu.

Przy analizie warto wykonać kilka przeładowań. Zewnętrzne usługi mogą odpowiadać z różną szybkością, a wynik pojedynczego testu może nie pokazywać typowego zachowania strony. Porównuj również stronę na różnych typach urządzeń i połączeń, bo koszt wykonania JavaScriptu zależy nie tylko od szybkości pobierania pliku, ale również od możliwości urządzenia.

Jeżeli przed kampanią SEO chcesz uporządkować szerszą listę problemów, zakres audytu technicznego sklepu pozwala spojrzeć na wydajność razem z indeksowaniem, strukturą techniczną i konfiguracją strony.

Typowe źródła ciężkiego JavaScriptu w sklepie

W praktyce najwięcej problemów powstaje nie przez jeden świadomie napisany skrypt, ale przez dokładanie kolejnych integracji. Każda z nich może mieć własny kod, bibliotekę oraz dodatkowe żądania.

Moduły marketingowe są częstym źródłem obciążenia. Sklep może mieć osobne integracje dla analityki, reklam, remarketingu, konwersji i zarządzania zgodami. Każda może uruchamiać własne skrypty lub ładować następne zasoby.

Kolejna grupa to widgety. Czat, system opinii, rekomendacje produktów, popupy, mapy, formularze i narzędzia do obsługi klienta mogą ładować kod z zewnętrznych serwerów. Jeżeli widget nie jest potrzebny do pierwszego widoku, sprawdź, czy może zostać uruchomiony później.

Problemem bywają też rozbudowane biblioteki. Sklep nie zawsze wykorzystuje cały pakiet, który trafia do przeglądarki. Biblioteka może być używana przez jeden niewielki komponent, podczas gdy pobierany jest znacznie większy zestaw funkcji.

W WooCommerce dodatkowe skrypty mogą pochodzić z motywu oraz wtyczek. W PrestaShop podobną rolę pełnią moduły i elementy szablonu. W Shoperze część kodu może być dodawana przez konfigurację sklepu lub integracje zewnętrzne. Niezależnie od platformy sposób diagnozy pozostaje podobny: znajdź zasób, ustal źródło, sprawdź zależności i dopiero potem zmień sposób ładowania.

Szczególną uwagę zwróć na skrypty obecne na każdej podstronie. Jeżeli ciężki widget jest potrzebny wyłącznie na karcie produktu, jego ładowanie na stronie kategorii i stronie głównej jest dodatkowym kosztem. Analogicznie skrypt potrzebny tylko przy koszyku nie powinien być bez potrzeby uruchamiany na całym sklepie.

Typy skryptów i możliwe sposoby optymalizacji

Typ skryptu	Typowy przykład	Co sprawdzić	Możliwa optymalizacja
Skrypt synchroniczny	kod motywu w <head>	czy jest potrzebny przed pierwszym renderem	defer, przeniesienie lub ograniczenie kodu
Biblioteka frontendowa	biblioteka używana przez komponent	ile funkcji jest faktycznie wykorzystywanych	ograniczenie biblioteki, podział kodu, defer
Analityka	pomiar wizyt i zdarzeń	moment wymagany do pomiaru	async, późniejsze uruchomienie lub konfiguracja tagów
Reklamy i remarketing	piksel, tag reklamowy	wymagania platformy i moment rejestracji zdarzenia	async, opóźnienie, kontrola wywołań
Czat	widget obsługi klienta	czy użytkownik potrzebuje go natychmiast	opóźnienie lub ładowanie po interakcji
Opinie	widget opinii produktu	miejsce i moment wyświetlenia	ładowanie na żądanie lub po głównej treści
Mapy i elementy interaktywne	mapa punktu odbioru	czy element znajduje się w pierwszym widoku	lazy loading lub inicjalizacja po interakcji
Kod koszyka	obsługa koszyka i wariantów	czy działa na wszystkich typach stron	ładowanie tylko tam, gdzie jest potrzebny
Kod nieużywany	pozostałość po usuniętej funkcji	czy jest jeszcze wykorzystywany	usunięcie integracji lub modułu

Tabela nie oznacza, że każdy skrypt z danej kategorii trzeba opóźnić. Sposób optymalizacji wynika z funkcji kodu, zależności i miejsca jego użycia.

Jak ograniczyć JavaScript w sklepie bez zgadywania

Najbezpieczniejsza praca zaczyna się od listy skryptów. Zapisz nazwę pliku, jego źródło, strony, na których się pojawia, oraz funkcję, którą obsługuje. Przy każdym wpisie dodaj informację, czy użytkownik potrzebuje tej funkcji przed pierwszym przewinięciem strony.

Następnie sprawdź, czy kod może zostać załadowany po zakończeniu parsowania HTML. W wielu przypadkach odpowiednim kandydatem jest defer. Jeżeli skrypt działa niezależnie od innych i nie wymaga określonego momentu wykonania, można rozważyć async. Nie zamieniaj jednak mechanicznie każdego <script> na async.

Przykładowo, jeżeli kod wygląda tak:

<script src="/js/vendor.js"></script>
<script src="/js/sklep.js"></script>

i sklep.js korzysta z funkcji z vendor.js, zastosowanie async do obu plików może zaburzyć kolejność wykonania. W takim przypadku defer może lepiej odpowiadać zależnościom, ponieważ odroczone skrypty zachowują kolejność w dokumencie.

Kolejny krok to ograniczenie zakresu. Jeżeli moduł dodaje kod tylko do karty produktu, sprawdź, czy platforma pozwala ładować go wyłącznie na tych stronach. To często daje bardziej logiczny efekt niż próba optymalizowania pojedynczego pliku bez usuwania niepotrzebnych wywołań.

Sprawdź także duplikaty. Czasem motyw ładuje bibliotekę, a następnie robi to ponownie moduł. Innym razem dwie integracje wykorzystują różne wersje tej samej biblioteki. W Network łatwo zauważyć powtarzające się pliki, domeny i podobne żądania.

Po każdej zmianie wykonaj test funkcjonalny. Sprawdź menu, wyszukiwarkę, warianty produktu, koszyk, formularze, popupy, zgody cookies i proces zakupowy. Optymalizacja JavaScriptu nie polega na uzyskaniu pustej listy skryptów, tylko na usunięciu pracy, której przeglądarka nie musi wykonywać w krytycznym momencie.

Kiedy usunąć skrypt zamiast go odraczać

Opóźnienie nie rozwiązuje problemu, jeżeli dana integracja nie jest już potrzebna. W sklepach często zostają stare moduły analityczne, fragmenty kodu po zakończonych kampaniach, nieużywane widgety oraz skrypty instalowane tymczasowo.

Jeżeli nie potrafisz wskazać funkcji konkretnego pliku, nie usuwaj go od razu z produkcji. Najpierw ustal, który moduł go generuje i sprawdź, czy dana funkcja jest używana. Możesz również porównać zachowanie strony w środowisku testowym po wyłączeniu integracji.

Szczególnie ostrożnie podchodź do kodu związanym z koszykiem, płatnościami, logowaniem, wariantami produktów oraz formularzami. Skrypt może nie wpływać na pierwszy widok, ale może być konieczny kilka sekund później. Wtedy jego odroczenie wymaga sprawdzenia momentu inicjalizacji.

W przypadku zewnętrznych usług dodatkowym problemem jest serwer dostawcy. Nawet dobrze przygotowany kod może czekać na odpowiedź z obcej domeny. Jeżeli integracja nie ma znaczenia dla pierwszego widoku, ograniczenie jej udziału w początkowym ładowaniu może być prostsze niż próba przyspieszania zewnętrznego serwera.

Kolejność ładowania HTML, CSS i JavaScript

Najpierw przeglądarka pobiera HTML i rozpoczyna jego parsowanie. W trakcie tego procesu odkrywa kolejne zasoby, w tym arkusze CSS i skrypty. CSS potrzebny do zbudowania widoku może blokować renderowanie, a synchroniczny JavaScript może zatrzymać parser HTML. Po zastosowaniu defer skrypt może być pobierany w czasie parsowania, ale jego wykonanie zostaje przesunięte. async pozwala na niezależne pobieranie, lecz wykonanie następuje po zakończeniu pobierania i może przerwać dalszą pracę parsera. Na końcu przychodzi moment, w którym przeglądarka może zbudować i wyświetlić pierwszy widok.

Dlatego samo zmniejszenie rozmiaru pliku JavaScript nie zawsze rozwiązuje problem. Liczy się również miejsce skryptu w ścieżce ładowania i moment jego wykonania.

Jeżeli pracujesz nad większą przebudową techniczną, analiza Core Web Vitals dla sklepu pomaga połączyć obserwacje z DevTools z metrykami dotyczącymi rzeczywistego doświadczenia użytkownika.

Jak sprawdzić efekt zmian

Po zmianie sposobu ładowania JavaScriptu nie oceniaj efektu tylko na podstawie jednego wyniku Lighthouse. Porównaj te same adresy przed i po zmianie, przy podobnych warunkach testowych.

Najpierw sprawdź, czy zmieniła się kolejność zasobów i czy skrypt przestał blokować parser. Następnie przejdź do Performance i zobacz, czy zmniejszyła się ilość pracy wykonywanej przez główny wątek w początkowej fazie ładowania.

Później przeprowadź test funkcjonalny. Otwórz stronę produktu, zmień wariant, dodaj produkt do koszyka, przejdź do koszyka i sprawdź formularze. Jeżeli masz wdrożone zdarzenia analityczne, sprawdź również, czy nadal są rejestrowane.

Na końcu wykonaj test na kilku typach stron. Sklep może wyglądać dobrze na stronie głównej, a jednocześnie mieć ciężki JavaScript na kategorii lub produkcie. Z tego powodu optymalizację należy prowadzić według szablonów stron, a nie tylko według jednego adresu.

Jeżeli po analizie nadal masz dużą liczbę bibliotek, modułów i zewnętrznych integracji, audyt szybkości sklepu pozwala uporządkować źródła obciążenia i ustalić kolejność prac technicznych.

JavaScript w sklepie trzeba oceniać według funkcji

Ciężki JavaScript nie oznacza automatycznie, że trzeba usunąć dużą bibliotekę albo wyłączyć moduł. Najpierw trzeba ustalić, kiedy kod jest potrzebny i co dokładnie robi podczas pierwszego ładowania strony.

Zacznij od Network, potem przejdź do Performance i kodu HTML. Ustal źródło skryptu, jego zależności oraz moment wykonania. Następnie podziel kod na ten potrzebny natychmiast, możliwy do odroczenia i niepotrzebny.

Dopiero wtedy wybierz sposób działania: defer, async, ładowanie po interakcji, ograniczenie skryptu do konkretnych podstron albo całkowite usunięcie integracji. Takie podejście pozwala ograniczyć JavaScript w sklepie bez zgadywania, które funkcje użytkownik rzeczywiście potrzebuje podczas pierwszego wejścia na stronę.