Dlaczego Magento 2 bez bundlingu generuje 200 zapytań o JavaScript?
Magepack to narzędzie, które rozwiązuje największą bolączkę frontendu Magento 2: pobieranie setek pojedynczych plików RequireJS przy każdym przeładowaniu podstrony. W październiku 2022 roku oryginalny projekt został jednak całkowicie porzucony przez twórców i przestał uruchamiać się na nowoczesnych systemach oraz nowych wersjach platformy. Przygotowaliśmy działające rozwiązanie — Magepack — darmowy fork SISL — w pełni przystosowane do Magento 2.4.9, PHP 8.4 i nowoczesnego środowiska Node.js.
Domyślna architektura frontendu Magento 2 opiera się na RequireJS i RequireJS-text. Kiedy użytkownik wchodzi na stronę kategorii, przeglądarka zaczyna sekwencyjnie odkrywać zależności. Pobiera plik konfiguracyjny, ten wskazuje na kolejne 15 skryptów, a każdy z nich żąda następnych komponentów UI, widoków Knockout.js i szablonów HTML. Zanim przeglądarka wyrenderuje w pełni interaktywny interfejs, wykonuje wodospad (waterfall) złożony z 200–300 odrębnych zapytań HTTP.
Mimo że standard HTTP/2 i HTTP/3 radzi sobie z multipleksowaniem połączeń, narzut na parsowanie setek małych plików oraz opóźnienia sieciowe (RTT) dramatycznie obniżają wskaźniki Core Web Vitals, w szczególności Interaction to Next Paint (INP) oraz Total Blocking Time (TBT). Wbudowany w Magento 2 mechanizm łączenia plików (core bundling) produkuje potężne, kilkunastomegabajtowe monolity, które blokują wątek główny procesora na długie sekundy. Dlatego społeczność tak chętnie sięgała po Magepacka — pakiet notuje wciąż około 28 tysięcy instalacji miesięcznie na Packagist, mimo że przez lata nikt go nie aktualizował.
Co właściwie popsuło się w oryginalnym Magepacku po 2022 roku?
Zasada działania Magepacka polega na uruchomieniu bezgłowej przeglądarki (headless browser), która symuluje ruch użytkownika na kluczowych typach podstron (strona główna, kategoria, karta produktu, koszyk oraz checkout), rejestruje faktycznie wykorzystane moduły JavaScript, a następnie buduje z nich dedykowane paczki per typ widoku. Porzucona wersja magesuite/magepack opierała się na bibliotece Puppeteer 2.1.1 z 2020 roku, powiązanej na stałe ze skompilowanym Chromium 80.
Próba uruchomienia tego zestawu na współczesnych dystrybucjach Linuksa (Ubuntu 22.04/24.04, Debian 12) kończy się natychmiastowym błędem systemowym. Nowoczesne systemy operacyjne nie posiadają już przestarzałych bibliotek współdzielonych, których wymagał archaiczny Chromium. Ponadto Puppeteer w tej wersji nie potrafił poprawnie współpracować z Node.js w wersjach 18, 20 i 22 LTS.
Do problemów ze stabilnością doszła kwestia krytycznego bezpieczeństwa. Stare zależności Puppeteera odpytywały łańcuch pakietów zawierający odwołania do zewnętrznych polyfilli. Jedna ze starych domen serwisujących te skrypty została przejęta przez podmiot dystrybuujący złośliwe oprogramowanie i adware. Pozostawienie porzuconego narzędzia w procesie CI/CD stało się bezpośrednim zagrożeniem dla infrastruktury wdrożeniowej.
Co zmieniliśmy w forku SISL pod Magento 2.4.9 i PHP 8.4?
Zamiast łatać przestarzały kod prowizorycznymi skryptami, przebudowaliśmy silnik zbierania metryk i pakowania od podstaw. Głównym celem była pełna zgodność ze stosem technologicznym Magento 2.4.9, interpretera PHP 8.4 oraz aktualnych wersji Node.js (18+).
- Puppeteer 24 i Chrome for Testing: Zastąpiliśmy archaiczny silnik najnowszym wydaniem Puppeteer 24 korzystającym ze standaryzowanego Chrome for Testing. Narzędzie pobiera właściwe binaria automatycznie i działa od ręki na każdym serwerze bez konieczności ręcznego doinstalowywania brakujących bibliotek
.so. - Rygorystyczna obsługa błędów HTTP: Oryginalny Magepack w przypadku błędu 404 lub 500 na analizowanej podstronie po cichu generował pusty lub uszkodzony bundle, co skutkowało awarią frontendu dopiero na produkcji. Nasz fork natychmiast przerywa proces i jasno raportuje kod odpowiedzi.
- Null-safe dla swatchy i komponentów UI: Zabezpieczyliśmy parsowanie dynamicznych komponentów (np. próbek kolorów i rozmiarów), które przy nietypowej strukturze atrybutów rzucały wyjątki uniemożliwiające dokończenie rejestracji modułów.
- Niezależność od BASE_URL w procesie kasy: Poprawiliśmy mechanizm analizy checkoutu, eliminując twarde założenia dotyczące struktury globalnego adresu URL sklepu.
- Deterministyczne sortowanie konfiguracji: Wyeliminowaliśmy losowe różnice w wyjściowych plikach konfiguracyjnych RequireJS pomiędzy kolejnymi buildami, co pozwala na efektywne cachowanie assetów w sieciach CDN.
- Zwiększone limity czasowe: Domyślny timeout oczekiwania na załadowanie zasobów został podniesiony do stabilnych 60 sekund, co zapobiega zrywaniu generowania na ciężkich środowiskach deweloperskich i stagingowych.
Jakie są realne wyniki wydajności na czystym Magento 2.4.9?
Przetestowaliśmy działanie forka na czystej instalacji Magento 2.4.9 z przykładowymi danymi Luma. Wyniki pomiarów na typowej stronie kategorii pokazują skalę optymalizacji, jakiej nie da się osiągnąć żadnymi wbudowanymi przełącznikami w panelu administracyjnym.
Przed wdrożeniem bundlingu: 200 zapytań HTTP o pojedyncze moduły JS na widoku kategorii.
Po wdrożeniu SISL Magepack: 11 zapytań HTTP (spadek o ~95%).
Wszystkie skrypty zostały pogrupowane w logiczne paczki: pliki wspólne (common), moduły specyficzne dla kategorii, zasoby karty produktu oraz odseparowany, zoptymalizowany pakiet dla procesu zamówienia. Testy konsoli przeglądarki na podstronach CMS, widokach katalogu, koszyku oraz na całej ścieżce zakupowej (One Page Checkout) wykazały zero błędów JavaScript i brak brakujących definicji modułów w RequireJS.
Dlaczego nawet nowe moduły psują się na Magento 2.4.9?
Wdrożenie Magento 2.4.9 na środowisku z PHP 8.4 brutalnie weryfikuje jakość całego ekosystemu modułów open source. Silnik PHP 8.4 oraz komponenty Symfony Console w wersji 7.4 wymuszają ścisłą typizację metod, w tym jawne zwracanie typu całkowitego (int) w metodzie execute() poleceń CLI.
Przekonaliśmy się o tym podczas testów integracyjnych na sklepie wyposażonym w popularny i stale utrzymywany moduł snowdog/module-menu (z wydaniem z 2025 roku). Mimo aktywnego rozwoju, uruchomienie poleceń konsolowych w środowisku PHP 8.4 skutkowało błędem krytycznym Fatal Error z powodu braku deklaracji typu zwracanego. To doskonały dowód na to, że nawet aktywne moduły wymagają gruntownego audytu przy migracji na nową wersję Magento, a porzucone narzędzia bez dedykowanych forków stają się całkowicie bezużyteczne.
Jak wdrożyć naprawiony bundling krok po kroku?
Proces wdrożenia składa się z dwóch etapów: wygenerowania mapy modułów na działającej instancji sklepu oraz włączenia etapu pakowania do standardowego procesu budowania statyków.
- Instalacja narzędzia: Zainstaluj globalnie nasz fork prosto z GitHuba (publikacja w rejestrze npm wkrótce):
npm install -g github:SISL-source/magepack - Generowanie konfiguracji (faza analizy): Uruchom zbieranie modułów, wskazując adresy URL poszczególnych typów stron w Twoim sklepie:
magepack generate --cms-url="https://twoj-sklep.test/" --category-url="https://twoj-sklep.test/kategoria.html" --product-url="https://twoj-sklep.test/produkt.html"
Polecenie wygeneruje plikmagepack.config.jsw katalogu głównym projektu. - Budowanie paczek produkcyjnych: Wykonaj standardowe wdrożenie assetów Magento, a następnie przetwórz wygenerowane pliki poleceniem packera:
bin/magento setup:static-content:deploy -f pl_PL en_USmagepack bundle pub/static/frontend/Vendor/theme/pl_PL
Moduł PHP integrujący wygenerowane paczki z RequireJS podmienia ścieżki w locie, dzięki czemu przeglądarka zamiast setek zapytań pobiera wyłącznie zdefiniowane pakiety zbiorcze.
Czemu reanimujemy porzucone moduły open source?
W SISL regularnie spotykamy się z sytuacją, w której kluczowe narzędzia optymalizacyjne dla Magento 2 przestają działać, ponieważ ich pierwotni autorzy zmienili stack technologiczny lub porzucili projekty. Zamiast zmuszać klientów do kosztownych i ryzykownych migracji na niestabilne alternatywy, bierzemy odpowiedzialność za kod i przywracamy go do życia w standardach PHP 8.4 i Magento 2.4.9.
Nasz fork udostępniliśmy całkowicie bezpłatnie na zasadach open source w repozytorium GitHub pod adresem github.com/SISL-source/magepack. Jeśli Twój sklep na Magento zmaga się z wolnym ładowaniem frontendu lub planujesz bezpieczną migrację do najnowszej wersji silnika, napisz do nas — pomożemy dobrać właściwe rozwiązania bez zbędnego narzutu technologicznego.