Ile modułów to realnie za dużo w Magento 2?
Granica rozsądku w standardowym sklepie kończy się w okolicach 30–40 rozszerzeń zewnętrznych, a degradacja TTFB (Time to First Byte) zaczyna się już przy 15 nieoptymalnych pluginach. Jeśli Twój plik composer.json mieści 70 czy 90 paczek od zewnętrznych dostawców, platforma przestaje być stabilnym silnikiem e-commerce, a staje się zlepiekiem wzajemnie nadpisujących się klas, gdzie każdy deployment to loteria. Kiedy w SISL audytujemy działające sklepy, standardem jest widok instancji Magento 2.4.7 z PHP 8.3, gdzie sam backend mieli zapytanie przez 1,2 sekundy tylko dlatego, że kilkanaście modułów wpina się w te same procesy kalkulacji cen i renderowania layoutu.
Gdy dobieramy komercyjne moduły Magento 2 pod polski rynek, szybko okazuje się, że sam bazowy pakiet integracji wymusza sporą liczbę rozszerzeń. Pytanie nie brzmi, czy możesz zainstalować 60 modułów — bo silnik to przyjmie — ale ile zapłacisz za to w sekundach ładowania koszyka, rachunkach za serwery i roboczogodzinach programistów przy najbliższym upgrade do kolejnej wersji.
Ile rozszerzeń faktycznie potrzebuje polski sklep na Magento 2?
Polski rynek e-commerce ma specyficzne wymagania podatkowo-logistyczne, przez co czysta instalacja Magento zaraz po uruchomieniu wymaga doposażenia. Czysty silnik Magento 2.4.7 z bazowym OpenSearch 2.12 nie obsłuży specyfiki rodzimych płatności ani etykiet kurierskich bez dodatkowego kodu.
Minimalny, zdrowy pakiet integracji dla średniej wielkości sklepu w Polsce obejmuje:
- Płatności: integracja z bramką Przelewy24 lub PayU (obsługa BLIK, szybkich przelewów, ratalnych);
- Logistyka: wtyczka InPost (Paczkomaty, ShipX API), DPD lub broker typu Apaczka;
- ERP i księgowość: moduł dwukierunkowej synchronizacji stanów i zamówień z Comarch ERP Optima, Subiekt GT/nexo albo integracja z Baselinkerem;
- Fiskalizacja i podatki: generowanie faktur zgodnych z polskim prawem, weryfikacja NIP na białej liście VAT, raportowanie JPK_V7 oraz przygotowanie pod bramkę KSeF (Krajowy System e-Faktur);
- Marketing i marketplace: dwukierunkowy connector do Allegro, Google Tag Manager (Server-Side) oraz moduł feedów produktowych (Google Merchant, Ceneo).
Taki zestaw to około 8–12 solidnych rozszerzeń. Jeśli dodasz do tego zaawansowany moduł promocji (np. od Amasty), rozszerzone zarządzanie SEO (Mirasvit lub MageWorx) i mechanizm bloga, zamykasz się w 20–25 modułach. Każda kolejna wtyczka kupiona na marketplace typu „Quick View za 49 EUR” czy „Custom Popup” to bezpośredni dług technologiczny, który prędzej czy później uderzy w metryki Core Web Vitals.
Dlaczego każdy kolejny moduł niszczy TTFB i spowalnia silnik?
Magento 2 opiera się na architekturze wstrzykiwania zależności (Dependency Injection) oraz systemie pluginów (Interceptorów). W teorii pozwala to modyfikować zachowanie niemal każdej metody bez dotykania kodu źródłowego. W praktyce oznacza to gigantyczny narzut na procesor serwera przy każdym żądaniu HTTP.
1. Piekło wtyczek typu around
Najgroźniejszym elementem modułów komercyjnych są interceptory typu around. O ile pluginy before i after wykonują się sekwencyjnie, o tyle around opakowuje wywołanie metody w łańcuch domknięć (closures). Gdy w sklepie 5 modułów (np. moduł B2B, moduł promocji Amasty, moduł reguł ratalnych, moduł prowizji i konwerter walut) dopisze swój plugin aroundGetFinalPrice do kalkulacji ceny produktu, wyrenderowanie kategorii z 32 produktami wymusza wykonanie tysięcy dodatkowych operacji na poziomie PHP 8.3.
// Klasyczny błąd w vendor/amasty/.../Plugin/Product/AroundGetPrice.php
public function aroundGetPrice($subject, callable $proceed)
{
// Wywołanie logiki sprawdzającej bazę przed przejściem dalej
if ($this->customValidation->check()) {
return $this->calculateCustomPrice($subject);
}
return $proceed(); // Łańcuch closure obciąża call-stack
}Nawet z aktywnym OPcache i procesorem AMD EPYC, warstwa kalkulacji zaczyna generować opóźnienia rzędu 300–600 ms przed wysłaniem pierwszego bajtu do przeglądarki.
2. Przeładowanie Layout XML i bloków bez cache
Wielu twórców tanich modułów zapomina o poprawnym tagowaniu cache w blokach widoku. Wystarczy jeden moduł timera odliczającego promocję, który w pliku default.xml wstrzyknie blok z parametrem cacheable="false", aby całkowicie wyłączyć Full Page Cache (FPC) oraz Varnish dla całego sklepu. Efekt? TTFB skacze z 80 ms do 1400 ms, a serwer zaczyna się dusić przy zaledwie 30 użytkownikach online jednocześnie.
Ile kosztuje utrzymanie 60 modułów podczas aktualizacji do nowej wersji?
Aktualizacja Magento to nie jest kliknięcie przycisku „Update” w panelu. To proces inżynierski. Im więcej rozszerzeń w projekcie, tym wyższy koszt maintenance'u i większe ryzyko regresji.
Przejście ze starszych wydań (np. 2.4.4) do Magento 2.4.7 wiąże się ze zmianami w deklaracjach typów PHP 8.2/8.3, podbiciem wersji bibliotek JS, a także restrykcjami w bezpieczeństwie (np. CSP – Content Security Policy). Jeśli masz w sklepie 60 modułów od 15 różnych vendorów:
- Opłaty abonamentowe za licencje: Wielu dostawców (Amasty, Mirasvit, Webkul) wymaga opłacania rocznych subskrypcji za dostęp do aktualizacji kodu (zwykle od 150 do 450 EUR netto rocznie za moduł). Przy 25 płatnych wtyczkach sam roczny koszt prawa do aktualizacji może przekroczyć 18 000–25 000 PLN.
- Konflikty podczas kompilacji DI: Komenda
bin/magento setup:di:compilezaczyna sypać błędami o niekompatybilności sygnatur metod (type hinting) albo brakujących argumentach w konstruktorach klas potomnych. - Czas wdrożenia: W SISL aktualizacja zadbanego sklepu z 15 modułami zajmuje zazwyczaj 20–35 godzin roboczych wraz z testami regresyjnymi. Ten sam proces dla sklepu-potwora z 70 wtyczkami pochłania 80–140 godzin (od 16 000 do ponad 30 000 PLN netto za sam dev), ponieważ programiści muszą ręcznie debugować konflikty, pisać patche przez cweagans/composer-patches i czekać tygodniami na poprawki od zagranicznych autorów modułów.
Zasada jest prosta: każdy moduł komercyjny wrzucony do projektu generuje stały, ukryty roczny koszt serwisowy. Jeżeli wtyczka zarabia na siebie mniej, niż wynosi koszt jej rocznego utrzymania przy update'ach, jest dla biznesu czystą stratą.
Jak sprawdzić, które moduły zarzynają wydajność Twojego sklepu?
Zamiast zgadywać, które rozszerzenie odpowiada za powolny TTFB, należy użyć twardych danych profilera. Podstawowym narzędziem diagnostycznym jest Tideways lub Blackfire.io podpięte bezpośrednio pod środowisko stagingowe lub produkcyjne z ruchem testowym.
- Analiza ścieżki krytycznej (Call Tree): Sprawdź metody
Magento\Framework\Interception\Interceptor:::___callPlugins. Profiler pokaże czarno na białym, który moduł spędza 400 ms na odpytywaniu bazy danych o reguły koszykowe w trakcie zwykłego listowania produktów. - Monitorowanie logów bazy danych: Włącz MySQL Slow Query Log (próg 0.2s). Zobaczysz, czy wtyczka do śledzenia zachowań użytkowników nie wykonuje synchronicznych zapytań
INSERTdo bazy przy każdym odświeżeniu strony zamiast odkładać dane asynchronicznie przez Message Queue (RabbitMQ). - Weryfikacja błędu kompilacji i czasu budowania: Czas wykonywania komend CLI to świetny barometr długu. Jeśli
bin/magento setup:di:compiletrwa u Ciebie dłużej niż 3 minuty na szybkim serwerze CI/CD, to wyraźny sygnał, że baza kodu jest zaśmiecona zbędnymi klasami i zależnościami.
Jak zredukować liczbę modułów i odzyskać kontrolę nad sklepem?
Optymalizacja nie polega na wyłączeniu wszystkiego przez bin/magento module:disable, co najczęściej natychmiast położy bazę danych z powodu brakujących kolumn i zależności w schemacie XML. W projektach realizowanych w SISL stosujemy uporządkowany proces refaktoryzacji:
1. Zastąpienie ciężkich wtyczek rozwiązaniem frontendowym (Hyvä Themes)
Większość modułów z Marketplace instaluje ze sobą masę przestarzałego kodu JavaScript bazującego na RequireJS, Knockout.js i jQuery. Zmiana warstwy prezentacji na Hyvä Themes pozwala wyrzucić dziesiątki modułów poprawiających UX, ponieważ nowoczesny, lekki frontend oparty na Alpine.js i Tailwind CSS natywnie ładuje się w ułamku sekundy, a specyficzne widoki (np. modale, slidery, proste walidacje) pisze się w kilku linijkach kodu bez instalowania zewnętrznych kobył.
2. Napisanie dedykowanych mikro-modułów zamiast kombajnów
Często klient kupuje moduł ważący 15 MB z panelem administracyjnym zawierającym 80 opcji konfiguracyjnych tylko po to, by wykorzystać jedną funkcję — np. dodanie niestandardowego pola do formularza rejestracji B2B z weryfikacją numeru NIP w bazie GUS. Dedykowany, napisany od zera mikro-moduł realizujący dokładnie to zadanie zajmuje kilkadziesiąt linii kodu, nie posiada warstwy zbędnych interceptorów i wykonuje się w 2 milisekundy.
3. Asynchroniczność i integracje przez API
Przeniesienie ciężkich operacji (jak fakturowanie, wysyłka danych o transakcjach do ERP Subiekt/Optima czy generowanie listów przewozowych) poza główny wątek żądania klienta. Zamiast modułów działających synchronicznie w trakcie składania zamówienia, stosujemy kolejki RabbitMQ lub bezpośrednie integracje przez webhooki i REST API. Checkout ma zapisać zamówienie i zwolnić klienta, a nie czekać na odpowiedź zewnętrznego API kuriera przez 4 sekundy.
Podsumowanie
Więcej modułów w Magento 2 nigdy nie oznacza lepszego sklepu. Każda kolejna pozycja w sekcji require pliku composer.json to potencjalny punkt awarii, spadek w wynikach PageSpeed i wyższy rachunek za wsparcie techniczne. Jeśli masz wątpliwości, czy Twoja obecna instalacja nie dźwiga zbyt dużego balastu technologicznego, napisz do nas — przeprowadzimy bezlitosny audyt kodu i pomożemy odchudzić silnik z modułów, które generują koszty zamiast przychodów.