Audyt Magento 2: najczęstsze błędy w polskim e-commerce

Co dokładnie weryfikujemy podczas inspekcji sklepu na Magento 2?

Podczas audytu weryfikujemy kod źródłowy, architekturę bazy danych MySQL/MariaDB, konfigurację serwera (OpenSearch 2.x, Redis, Varnish) oraz stabilność integracji zewnętrznych. Nie oceniamy estetyki szablonu, lecz szukamy wąskich gardeł, które generują błędy 504 Gateway Timeout, drenują budżet serwerowy i obniżają konwersję w koszyku. Rzetelny audyt techniczny Magento to jedyny sposób, by precyzyjnie zlokalizować dług technologiczny, zanim kolejna aktualizacja do wersji 2.4.7 zablokuje cały proces zakupowy.

Prześwietlamy środowisko produkcyjne warstwa po warstwie: od poprawności deklaracji w plikach di.xml i obecności ryzykownych wtyczek typu around, przez kolejki RabbitMQ i zadania w cron_schedule, aż po integracje logistyczne i systemy ERP.

Dlaczego sklep zwalnia po dodaniu 20 tysięcy produktów na Magento 2.4.7?

Podstawowym problemem nie jest sam silnik Magento, lecz błędnie zaprojektowane atrybuty EAV oraz niepoprawna konfiguracja warstwy wyszukiwania i indeksowania. Sklepy migrujące na Magento 2.4.7 przy użyciu PHP 8.2 lub 8.3 często borykają się z problemami na poziomie silnika OpenSearch 2.x. Jeśli atrybuty produktów mają bezrefleksyjnie włączone flagi is_filterable = 1 oraz is_searchable = 1 dla kilkudziesięciu pól tekstowych, zapytania agregujące generują potężne narzuty pamięciowe.

Najczęstsze błędy architektury danych, które wykrywamy w bazach o rozmiarze powyżej 50 GB:

• Brak czyszczenia logów i tabel tymczasowych: Tabele customer_visitor, report_event czy quote potrafią urosnąć do milionów rekordów, spowalniając operacje I/O dysków NVMe.
• Zablokowane indeksy w trybie Update on Save: Zamiast bezpiecznego Update by Schedule na środowiskach produkcyjnych, zapis pojedynczego produktu w panelu administracyjnym wymusza synchroniczny reindeks, blokując tabelę catalog_product_flat lub tabele indeksów cenowych.
• Niewydolna konfiguracja Redis: Współdzielenie jednej instancji Redis dla cache i session zamiast rozbicia ich na osobne sockety UNIX z dedykowanymi limitami maxmemory. Efekt? Wyrzucanie kluczy sesyjnych użytkowników w momentach pików odwiedzin.

W SISL regularnie trafiamy na projekty, w których czas ładowania kategorii na poziomie 4-6 sekund udaje się zredukować poniżej 400 ms bez zmiany hostingu — wyłącznie poprzez wyczyszczenie indeksów i naprawę zapytań SQL generowanych przez warstwę repozytoriów.

Co najczęściej psują komercyjne moduły od Amasty, Mirasvit czy MageWorx?

Rynek gotowych modułów Magento pozwala na szybkie wdrożenie zaawansowanych funkcji, ale jest głównym źródłem długu technologicznego. Typowy polski sklep ma zainstalowanych od 35 do nawet 90 modułów zewnętrznych. Gdy deweloperzy instalują wtyczki bez weryfikacji ich wpływu na cykl życia obiektu (object lifecycle), sklep staje się niestabilny.

Nadużywanie wtyczek typu around w plikach di.xml to technologiczna zbrodnia. Pojedynczy interceptor potrafi wielokrotnie podwoić zużycie pamięci procesu PHP-FPM, zamieniając prosty rendering strony produktu w serię 300 ukrytych zapytań do bazy danych.

Do najczęstszych grzechów zewnętrznych wtyczek należą:

1. N+1 queries w pętlach: Ładowanie modeli danych metodą $product->load() wewnątrz pętli szablonu zamiast wykorzystania ProductCollection z predefiniowanymi atrybutami (EAV).
2. Konflikty kompilacji Dependency Injection: Błędy podczas uruchamiania bin/magento setup:di:compile wynikające z niekompatybilnych typów parametrów w konstruktorach po aktualizacji PHP do 8.2/8.3.
3. Przeładowany DOM w szablonach Luma: Setki niepotrzebnych kontenerów Knockout.js i komponentów UI, które dramatycznie obniżają wskaźniki Core Web Vitals (LCP, INP). Rozwiązaniem staje się często dopiero refaktoryzacja do czystego frontendu opartego o Hyvä Themes.

Gdzie leży problem, gdy integracja z Subiektem GT lub ERP Optima blokuje bazę?

Polski handel opiera się na integracjach z systemami Comarch ERP Optima, InsERT Subiekt GT/nexo czy Navireo. Powszechną praktyką wątpliwej jakości integratorów jest bezpośrednie zapisywanie stanów magazynowych do bazy MySQL z pominięciem API Magento lub zmasowane uderzenia w standardowe endpointy REST bez buforowania.

Przekłada się to na zjawisko deadlocków na tabelach Multi-Source Inventory (inventory_source_item) oraz sales_order_grid. Gdy w tle odbywa się synchronizacja 50 000 stanów magazynowych, a klient próbuje opłacić zamówienie w koszyku, transakcja bazodanowa zostaje odrzucona z błędem Lock wait timeout exceeded.

Prawidłowo zoptymalizowana integracja, którą weryfikujemy w audycie, musi opierać się na asynchronicznych endpointach (Magento Bulk API) lub dedykowanych kolejkach RabbitMQ z kontrolowanym narzutem (rate limiting), co chroni proces zakupowy przed zakłóceniami ze strony ERP.

Jak audytujemy polski checkout: InPost, BLIK, Przelewy24 i KSeF?

Ścieżka zakupowa w Polsce rządzi się swoimi prawami. Klienci oczekują błyskawicznego wyboru Paczkomatu przez Geowidget, płatności one-click BLIK oraz automatycznej weryfikacji NIP na białej liście VAT w przypadku zakupów B2B. Każdy z tych elementów może zerwać sesję zakupową.

Podczas audytu modułów płatności (Przelewy24, PayU, Autopay) sprawdzamy:

• Obsługę webhooków asynchronicznych: Czy status zamówienia zmienia się poprawnie w przypadku opóźnionej odpowiedzi banku, nie powodując duplikacji stanów magazynowych ani wysyłki podwójnych powiadomień transakcyjnych.
• Session locking w PHP: Czy asynchroniczne zapytania AJAX z widgetu mapy InPost (API ShipX) nie blokują wątku sesji użytkownika, uniemożliwiając równoległe przejście do wyboru metody płatności.
• Gotowość na KSeF (Krajowy System e-Faktur): Czy moduły generujące faktury korzystają z asynchronicznych observerów i nie spowalniają eventu sales_order_place_after podczas komunikacji z ministerialnym API.
• Zgodność z JPK i walidacją VIES/Biała Lista: Czy weryfikacja statusu podatnika nie generuje timeoutów przy chwilowej niedostępności rządowych bramek API.

Ile kosztuje ignorowanie długu technologicznego na produkcji?

Ignorowanie błędów w architekturze Magento generuje realne straty finansowe. Nie chodzi wyłącznie o utracone koszyki, ale o comiesięczne koszty utrzymania infrastruktury i serwisu.

W jednym z audytowanych przez nas sklepów B2B klient płacił miesięcznie ponad 4 200 PLN za rozbudowany klaster dedykowany w chmurze AWS, ponieważ serwery nie radziły sobie z generowaniem raportów i importem cenników. Po optymalizacji konfiguracji Varnish (Full Page Cache), naprawie 4 pętli zapytań SQL w niestandardowym module wyliczania cen B2B oraz poprawnym wdrożeniu Redis, całe środowisko zostało przeniesione na stabilną instancję w Hetznerze za niespełna 900 PLN miesięcznie — przy jednoczesnym skróceniu czasu odpowiedzi serwera (TTFB) z 1,8 s do 180 ms.

Do tego dochodzi koszt prac deweloperskich. W zabałaganionym kodzie proste wdrożenie nowej metody dostawy zajmuje 40 godzin zamiast 8, ponieważ każda zmiana wywołuje regresję w innych częściach aplikacji.

Co otrzymujesz w raporcie po audycie i co robimy z tym dalej?

U nas w projektach raport z audytu nie jest 80-stronicowym dokumentem wygenerowanym z automatycznych skanerów. Automaty wyłapują ułamek problemów; reszta wymaga ręcznej analizy profilera Blackfire, logów exception.log, system.log oraz inspekcji commitów w repozytorium Git.

Dostarczamy zestawienie z podziałem na trzy poziomy priorytetów:

1. Krytyczne (Blokery): Luki bezpieczeństwa, błędy uniemożliwiające finalizację transakcji, procesy ubijające bazę danych podczas szczytów ruchowych.
2. Średnie (Optymalizacyjne): Błędy w konfiguracji pamięci podręcznej, przestarzałe pluginy zwalniające TTFB, brak optymalizacji obrazów WebP/AVIF.
3. Niskie (Dług technologiczny): Niezgodności ze standardami PSR-12, brak deklaracji typów w PHP, martwy kod po odinstalowanych modułach.

Każdy punkt zawiera precyzyjną ścieżkę do pliku, numer linii, opis problemu i gotowy sposób naprawy (rekomendację techniczną dla Twojego software house'u lub naszego zespołu). Jeśli chcesz wiedzieć, co naprawdę dzieje się pod maską Twojego sklepu, napisz do nas i prześlij specyfikację swojego środowiska.