Przykładowy raport z audytu wydajności

To jest wzór. Klient „Acme Outdoor s.r.o.” nie istnieje, a dane identyfikujące zostały zmienione. Ustalenia i liczby to zanonimizowane dane złożone z prawdziwych audytów wydajności, które Luboš Zápotočný przeprowadził przez dziesięć lat pracy inżynierskiej w e-commerce, jeszcze przed powstaniem tej praktyki. Nie są to zlecenia zrealizowane pod marką Zapolu, która nie ma jeszcze własnej historii klienckiej; potwierdzenie tej wcześniejszej pracy znajdziesz na stronie O nas. Wzór pokazuje formę: czym poparte jest ustalenie, ile kosztuje jego naprawa i jak uszeregowana jest praca. Raport, który dostaje klient, omawia każde ustalenie z taką samą szczegółowością jak F1 poniżej; ten wzór skraca sześć z jedenastu, żeby pozostał czytelny.


Klient	Acme Outdoor s.r.o. (fikcyjny)
Sklep	acme-outdoor.example (Magento 2.4.6, frontend Luma)
Stack	Varnish 7, Redis 7, MySQL 8, 2 nody aplikacyjne za load balancerem
Data raportu	5 czerwca 2026
Dane z realnego ruchu	7 maja do 3 czerwca 2026 (28 dni)
Trace’y APM	21 maja do 3 czerwca 2026 (14 dni) i jeden test obciążeniowy
Narzędzia	New Relic, CrUX, Lighthouse, k6, varnishstat, MySQL slow log
Autor	Luboš Zápotočný, Zapolu s.r.o.
Zlecenie	Deep dive, 7 dni roboczych, stała cena

Dla szybkiego przeglądu przeczytaj rozdział 1 i rozdział 5. Wszystko pomiędzy nimi to materiał źródłowy.

1. Podsumowanie

Spowolnienie sklepu ma źródło po stronie serwera. LCP z realnego ruchu na stronach katalogu to 4,6 s na p75 (cel: ≤ 2,5 s), a stoi za tym TTFB 1,9 s. TTFB jest wysokie, bo full-page cache jest faktycznie wyłączony: Varnish obsługuje tylko 34% żądań katalogowych, a 38% całego czasu serwera idzie na renderowanie stron produktowych, średnio 2,2 s na żądanie. Podczas wieczoru kampanii 26 maja checkout p95 sięgnął 6,1 s, a 3,4% żądań kończyło się błędem, podczas gdy CPU serwerów aplikacyjnych nie przekroczyło 12%.

Poniżej przedstawiono jedenaście ustaleń. Siedem z nich kosztuje dzień pracy lub mniej, a dwa z tych siedmiu (F2 i F8) to zmiany wyłącznie w plikach konfiguracyjnych. Wiersze od 1 do 6 planu napraw usuwają każdą awarię, którą klient może poczuć: checkout przestaje zawodzić w szczycie, a checkout p95 w trakcie kampanii spada z 6,1 s do 1,9 s. Largest Contentful Paint na samych tych wierszach nie zejdzie poniżej progu 2,5 s wyznaczonego przez Google. Budżet:

Stan	Co się zmienia	LCP kategorii	LCP produktu
dziś		4,6 s	4,6 s
po wierszu 2	F1, TTFB katalogu 1,9 s → 1,2 s	3,9 s	3,9 s
po wierszu 5	F5, zdjęcia hero produktów	3,9 s	3,3 s
po wierszu 7	F4 doraźnie, martwe tagi i odroczenie	3,5 s	2,9 s
po wierszu 8	F4, przebudowa frontendu	2,7 s	2,1 s

Strony produktowe schodzą poniżej progu dopiero po przebudowie z wiersza 8. Kategorie kończą na 2,7 s, więc wciąż powyżej progu; tego, co pozwoliłoby zejść niżej, nie zbadaliśmy (rozdział 6). Wiersze są uszeregowane według zwrotu, więc realizację planu można przerwać w dowolnym miejscu.

W przeliczeniu na pieniądze: w ciągu trzech godzin wieczornej kampanii 26 maja błędem zakończyło się około 230 checkoutów. Przy średniej wartości zamówienia 1 800 CZK to 414 000 CZK w zamówieniach, które się nie udały, czyli około 17 000 € po kursie 24,3 CZK za euro, i nie obejmuje to klientów, którzy porzucili checkout po sześciu sekundach oczekiwania. Pozostałe ustalenia podajemy w milisekundach; podanie kwoty byłoby przy nich spekulacją, więc z niej rezygnujemy.

2. Co i jak mierzyliśmy

Metryki realnych użytkowników: Core Web Vitals z 28-dniowego zapytania do CrUX, segmentowane po typie strony (strona główna / kategoria / produkt / checkout). Syntetyczne przebiegi Lighthouse służyły tylko do reprodukcji ustaleń, nie do ich oceniania. Jak sklep wypada na tle progów Google:

Metryka (p75, dane z realnego ruchu) Sklep Próg Werdykt
LCP 4,6 s < 2,5 s nie zdaje
INP 280 ms < 200 ms nie zdaje
CLS 0,04 < 0,1 zdaje
FCP 2,9 s < 1,8 s nie zdaje
TTFB 1,9 s < 0,8 s nie zdaje
Trace po stronie serwera: profil transakcji z New Relic za 14 dni, czyli dokąd naprawdę idzie czas serwera:

Transakcja Udział w czasie serwera Śr. odpowiedź
catalog/product/view 38% 2,2 s
catalog/category/view 17% 1,8 s
checkout REST (koszyk + dostawa) 11% 1,4 s (6,1 s p95 w szczycie)

Do tego MySQL slow query log, profil wywołań usług zewnętrznych i statystyki hit/miss Varnisha per wzorzec URL z varnishstat.
Test obciążeniowy: replay przebiegu ruchu z wieczoru kampanii 26 maja (0 → 420 req/s w 20 minut) na stagingu, z tym samym stanem cache co na produkcji.
Przegląd konfiguracji: ustawienia PHP i OPcache, autoloader Composera, env.php, VCL Varnisha i ustawienia MySQL, wszystko porównane z udokumentowanymi zaleceniami dla Magento, podwyższonymi tam, gdzie baza kodu wyrasta ponad udokumentowaną wartość.
Audyt bundli i assetów: co wysyła się przy pierwszym wyświetleniu strony produktu, co blokuje render, a co jest zbędnym obciążeniem.

Metryka (p75, dane z realnego ruchu)	Sklep	Próg	Werdykt
LCP	4,6 s	< 2,5 s	nie zdaje
INP	280 ms	< 200 ms	nie zdaje
CLS	0,04	< 0,1	zdaje
FCP	2,9 s	< 1,8 s	nie zdaje
TTFB	1,9 s	< 0,8 s	nie zdaje

Transakcja	Udział w czasie serwera	Śr. odpowiedź
`catalog/product/view`	38%	2,2 s
`catalog/category/view`	17%	1,8 s
checkout REST (koszyk + dostawa)	11%	1,4 s (6,1 s p95 w szczycie)

Przy większości ustaleń cytujemy dokładne polecenie albo zapytanie, którego użyliśmy: po pierwsze, żeby Twój zespół mógł sprawdzić naszą pracę, po drugie dlatego, że te same sondy zadziałają na każdym sklepie Magento, także na Twoim. Rozdział 7 zbiera je tak, żeby dało się je uruchomić bez zmian. Przy każdej liczbie niżej napisano, skąd pochodzi, a tabela ustaleń ma kolumnę mówiącą, czy oczekiwany efekt został zmierzony, odtworzony pod obciążeniem, czy oszacowany.

3. Przegląd ustaleń

Wysoka: dotyka klientów albo zależy od niej przychód. Średnia: zespół odczuwa ją codziennie albo po cichu uszkadza dane. Niska: niewielki nakład, a usuwa realne ryzyko operacyjne.

#	Ustalenie	Waga	Praca	Oczekiwany efekt	Podstawa
F1	Full-page cache jest faktycznie wyłączony i nie da się go unieważnić	Wysoka	1–2 dni	−700 ms TTFB na p75 w katalogu	zmierzone
F2	PHP runtime i autoloader źle skonfigurowane pod Magento	Wysoka	0,5 dnia	−400 ms na każdym niecache’owanym żądaniu	szacunek
F3	Checkout blokuje się na synchronicznym odpytaniu ERP o stany	Wysoka	3–5 dni	−2,8 s checkout p95 w szczycie; koniec błędów timeout	test obciążeniowy
F4	Frontend wysyła 2,3 MB JavaScriptu, blokując render	Wysoka	projekt	−1,2 s LCP (rozwiązania przejściowe: −0,4 s)	szacunek
F5	Zdjęcia produktów: 1,6 MB PNG, bez responsywnych rozmiarów	Średnia	1 dzień	−0,6 s LCP na stronach produktów	zmierzone
F6	Indeksery zostawione na „Update on Save”	Średnia	0,5 dnia	Zapis w adminie 30 s → ~2 s; koniec rozbieżności stanów magazynowych	szacunek
F7	Pula PHP-FPM wyczerpana przez session locki w szczycie	Wysoka	2 dni	Checkout przeżywa ruch kampanii	test obciążeniowy
F8	Varnish bez trybu grace	Niska	0,5 dnia	Amortyzuje falę po każdym flushu cache	szacunek
F9	Dwa rozszerzenia nasłuchują tego samego eventu; jedno porzucone	Średnia	1 dzień	−300 ms na dodaniu do koszyka	zmierzone
F10	41 GB martwych tabel temp po indekserach w MySQL	Niska	0,5 dnia	Backupy mniejsze o 60%; restore w około połowę czasu	zmierzone
F11	Grid zamówień w adminie filtruje po niezindeksowanej kolumnie	Niska	0,5 dnia	Grid zamówień 12 s → poniżej 1 s	szacunek

Podstawa mówi, skąd bierze się oczekiwany efekt. Zmierzone: zobaczyliśmy to na tym sklepie. Test obciążeniowy: odtworzyliśmy to na stagingu przy obciążeniu jak podczas kampanii. Szacunek: wynika z profilu i konfiguracji, a nikt tego jeszcze nie zaobserwował.

4. Ustalenia szczegółowo

F1: Full-page cache jest faktycznie wyłączony i nie da się go unieważnić (Wysoka)

Co zobaczyliśmy. Varnish raportuje na URL-ach katalogowych hit rate 34%. Dla katalogu tej wielkości, przy tym udziale crawlerów, normą jest ponad 90%. Każda strona kategorii i produktu niesie X-Magento-Cache-Debug: MISS. Przyczyny są dwie, niezależne od siebie:

Zmodyfikowany default.xml oznacza jeden blok w nagłówku (przełącznik store view czytający sesję klienta) jako cacheable="false". W Magento jeden niecache’owalny blok w layoucie czyni niecache’owalną całą stronę. Blok pojawił się z aktualizacją rozszerzenia w listopadzie 2025; hit rate załamał się w tym samym tygodniu.
Varnish jest włączony w adminie (system/full_page_cache/caching_application = 2), ale w env.php nie ma sekcji http_cache_hosts, więc Magento w ogóle nie umie wysyłać żądań purge do Varnisha. Zespół obchodzi to restartem Varnisha po każdym deployu; właśnie dlatego deploye są problematyczne (zob. F8).

Jak to zweryfikowaliśmy:

$ curl -sI https://acme-outdoor.example/namioty | grep -i cache-debug
X-Magento-Cache-Debug: MISS
# tak samo na każdym sprawdzonym URL-u

$ grep -R 'cacheable="false"' app/design app/code | wc -l
1
# przełącznik store view w default.xml

$ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));'
false
# Magento nie umie purge'ować Varnisha

Naprawa. Renderować przełącznik przez private content (customer data JS), żeby sama strona pozostała cache’owalna (udokumentowany wzorzec dla fragmentów zależnych od sesji), i dodać http_cache_hosts do env.php, żeby działało unieważnianie po tagach, a restarty mogły się skończyć.

Praca / efekt / ryzyko. 1–2 dni z testami regresyjnymi. Oczekiwane −700 ms TTFB na p75 katalogu (zmierzone: cache’owana odpowiedź katalogowa wraca w 80 ms, niecache’owana w 1,9 s). Ryzyko: niskie; obie zmiany są ograniczone i odwracalne per deploy.

F2: PHP runtime i autoloader źle skonfigurowane pod Magento (Wysoka)

Co zobaczyliśmy. Baza kodu zawiera ~125 000 plików PHP; OPcache jest ustawiony na 10 000. Autoloader Composera nigdy nie był optymalizowany: vendor/composer/autoload_static.php nie zawiera class mapy, a trace’y New Relic pokazują całe sekundy spędzone w rozwiązywaniu ObjectManager factory na zimnych ścieżkach. Obecne kontra zalecane:

Ustawienie	Obecne	Zalecane
`opcache.max_accelerated_files`	10 000	100 000
`opcache.memory_consumption`	128	512
`opcache.validate_timestamps`	On, rewalidacja co 2 s	Off; reset przy deployu
`opcache.enable_cli`	Off	On (indeksery i crony to też PHP)
`realpath_cache_size`	4M	32M
`realpath_cache_ttl`	120	7200
Autoloader Composera	nieoptymalizowany	`dump-autoload --optimize` w buildzie

Jak to zweryfikowaliśmy:

$ find . -type f -name '*.php' | wc -l
124862
# plików PHP w codebase

$ php -i | grep 'opcache.max_accelerated_files'
opcache.max_accelerated_files => 10000
# mieści 8% z nich

$ grep -c 'classMap' vendor/composer/autoload_static.php
0
# autoloader nigdy nie był optymalizowany

Dlaczego. Przy tych wartościach PHP na bieżąco od nowa sprawdza i kompiluje dużą część codebase; profile przypisują ponad połowę czasu niecache’owanego renderu ładowaniu klas i składaniu strony, a nie logice biznesowej.

Naprawa. Jedna zmiana konfiguracji plus jeden krok w buildzie. Jedyne sprzężenie do uszanowania: przy wyłączonym validate_timestamps pipeline deployu musi przy release resetować OPcache. Dokładny krok dla Twojego obecnego pipeline’u opisaliśmy w planie napraw.

Praca / efekt / ryzyko. 0,5 dnia. Szacunkowo −400 ms na każdym niecache’owanym żądaniu (plus szybsze crony i indeksery jako efekt uboczny). Ryzyko: niskie, o ile krok w deployu wyląduje razem z konfiguracją.

F3: Checkout blokuje się na synchronicznym odpytaniu ERP o stany (Wysoka)

Co zobaczyliśmy. Na kroku dostawy trace pokazuje synchroniczne wywołanie HTTPS do endpointu stanów ERP z 3-sekundowym timeoutem i jednym ponowieniem; profil usług zewnętrznych przypisuje temu jednemu endpointowi 92% całego czekania na systemy zewnętrzne. Pod obciążeniem kampanii ERP zwalnia, wywołania wybierają cały timeout, a żądania checkoutu zaczynają się piętrzyć. Dokładnie stąd bierze się p95 6,1 s i 3,4% błędów. Test obciążeniowy odtwarza to na stagingu.

Dlaczego. Potwierdzanie stanów w czasie rzeczywistym doszło po incydencie z nadsprzedażą w 2025 roku. Zamiar jest słuszny, tylko wprowadza opóźnienie cudzego systemu do każdego checkoutu.

Naprawa. Wyprowadzić uzgadnianie stanów poza ścieżkę żądania: rezerwować na lokalnym magazynie, potwierdzać asynchronicznie i alarmować przy rozbieżności. Nadsprzedaż pozostaje pod kontrolą, a checkout przestaje czekać na ERP. Ten sam wzorzec opisujemy w tekście dlaczego ERP i sklep różnią się stanami.

Praca / efekt / ryzyko. 3–5 dni z alertem rozbieżności stanów. Zdejmuje ~2,8 s z checkout p95 w szczycie i całkowicie usuwa błędy timeout (jedno i drugie zmierzone w teście obciążeniowym z zaślepionym wywołaniem). Ryzyko: średnie; wymaga pisemnej akceptacji nowego okna nadsprzedaży (szacunkowo < 0,1% zamówień kampanijnych, wobec dzisiejszych 3,4% nieudanych checkoutów).

F4: Frontend wysyła 2,3 MB JavaScriptu (Wysoka)

Co zobaczyliśmy. Pierwsze wyświetlenie strony produktu ładuje 2,3 MB JavaScriptu w 61 plikach; blokowanie głównego wątku na średniej klasy telefonie to 2,9 s. Za czterema z czternastu tagów marketingowych nie stoi już działające konto.

Dlaczego. Po części architektura frontendu Luma, po części osiem lat przyrastania tagów; żaden pojedynczy tag nie przeważa w sumie.

Naprawa, krótkoterminowo (ten kwartał). Usunąć cztery martwe tagi, odroczyć bundle analityki, a widget opinii poniżej widocznego obszaru ekranu ładować dopiero wtedy, gdy jest potrzebny. Szacunkowo −0,4 s LCP, 2 dni.

Naprawa, właściwa (osobna decyzja). Przebudowa frontendu na Hyvä. Zastępuje warstwę JavaScriptu Lumy, zamiast tylko odraczać jej części, więc o wielkości payloadu decyduje architektura, a nie pielęgnowanie pojedynczych tagów. To projekt na 6–10 tygodni i zasługuje na własną wycenę, nie na wiersz na liście napraw. Wspominamy o nim tutaj, aby krótkoterminowy szacunek powyżej nie był traktowany jako osiągalne maksimum.

F7: Pula PHP-FPM wyczerpana przez session locki w szczycie (Wysoka)

Co zobaczyliśmy. Podczas testu obciążeniowego błędy zaczynają się około 280 req/s, podczas gdy CPU siedzi na 12%. Strona statusu FPM pokazuje wszystkie workery zajęte; trace’y pokazują czekanie na session locki w Redisie: klienci odpytujący stronę potwierdzenia zamówienia trzymają blokady, które kolejkują każde kolejne żądanie tej samej sesji.

Naprawa. Wyłączyć blokowanie sesji dla endpointów pollingu, podnieść liczbę workerów do tego, na co realnie pozwala zapas pamięci (obecna liczba pochodzi z mniejszego typu instancji), i dodać alert nasycenia FPM; ta awaria pozostała niezauważona, bo wykresy CPU nie budziły podejrzeń.

Praca / efekt / ryzyko. 2 dni z powtórką testu obciążeniowego. Razem z F3 staging przeżywa 420 req/s z checkout p95 1,9 s. Ryzyko: niskie.

F5, F6, F8, F9, F10, F11 w skrócie

F5 Zdjęcia: hero produktów to 1,6 MB PNG dostarczane w jednym rozmiarze każdemu urządzeniu. Konwersja do WebP + responsywne rozmiary przez CDN: 1 dzień, −0,6 s LCP na stronach produktów (zmierzone na przekonwertowanej próbce).
F6 Indeksery: przełączone na „Update on Save” przy imporcie masowym w lutym 2026 i nigdy z powrotem. Zapis produktu w adminie trwa 30 s, a rozbieżność między stanami w sklepie a rzeczywistością magazynu wynika z wyścigów przy reindeksie. Przywrócić indeksowanie z harmonogramu: 0,5 dnia. Te 30 s jest zmierzone; liczba po naprawie to szacunek.
F8 Varnish grace: każdy flush cache wysyła dziś całą falę ruchu na PHP. Tryb grace zwraca stare obiekty, dopóki cache się nie zapełni na nowo: 0,5 dnia. Efekt jest szacunkiem.
F9 Zduplikowane observery: dwa rozszerzenia subskrybują ten sam event checkoutu; jedno jest porzucone przez vendora od 2023 roku i przy każdym wywołaniu od nowa ładuje quote. Usunąć je (jego funkcja jest nieużywana): 1 dzień z weryfikacją, −300 ms na dodaniu do koszyka (zmierzone w trace).
F10 Porządki w bazie: baza niesie 41 GB tabel catalogrule_product__temp* (pozostałości przerwanych przebiegów indekserów ze starszej wersji Magento, która po sobie nie sprzątała) plus własną tabelę kolejki z 12 milionami wierszy bez żadnej retencji. Znajduje je jedno zapytanie do information_schema:
```
mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length)
    -> /1024/1024/1024, 1) gb FROM information_schema.tables
    -> WHERE table_name LIKE 'catalogrule\_product\_\_temp%';
+--------+------+
| tables | gb   |
+--------+------+
|     96 | 41.2 |
+--------+------+
```
Usunięcie pozostałości i dodanie czyszczenia: 0,5 dnia. Backupy maleją z 68 GB do 27 GB; restore trwa potem mniej więcej połowę czasu, co jest szacunkiem ze zmiany rozmiaru i liczy się głównie w dniu, w którym restore jest naprawdę potrzebny.
F11 Grid zamówień w adminie: kolumna dodana dla zespołu wysyłek filtruje po niezindeksowanym atrybucie; grid ładuje się 12 s i za każdym razem wiąże jednego workera. Jedna migracja indeksu: 0,5 dnia. Te 12 s jest zmierzone; liczba po naprawie to szacunek.

5. Plan posortowany według zwrotu z nakładu

Kolejność	Pozycje	Praca	Co dostajesz
1	F2 + F8	1 dzień	Każde niecache’owane żądanie −400 ms; flushe cache nie wywołują już skoku obciążenia
2	F1	1–2 dni	TTFB katalogu −700 ms; deploye nie wymagają już restartu Varnisha
3	F6 + F10 + F11	1,5 dnia	Admin znowu używalny; koniec rozbieżności stanów magazynowych; backupy o połowę
4	F7	2 dni	Checkout przestaje zawodzić w szczycie
5	F5 + F9	2 dni	LCP strony produktu −0,6 s; dodanie do koszyka −300 ms
6	F3	3–5 dni	Checkout p95 poniżej 2 s w trakcie kampanii
7	F4 krótkoterminowo	2 dni	LCP −0,4 s, zanim zapadnie decyzja o froncie
8	F4 przebudowa	osobna wycena	LCP stron produktów poniżej progu 2,5 s

Wiersze 1–6 to razem 10,5 do 13,5 dnia inżynierskiego i rozwiązują każdą awarię, którą klient może poczuć. Po dowolnym wierszu możesz skończyć, a praca do tego momentu broni się sama. Wiersz 6 jako jedyny dotyka architektury ścieżki zamówienia; niezależnie od tego, kto go wykona, zleć przegląd projektu doświadczonemu inżynierowi.

Po wierszu 6 zmierz ponownie tym samym zapytaniem o dane z realnego ruchu, od którego ten raport się zaczął. Jeśli liczby nie ruszą się zgodnie z przewidywaniem, skontaktuj się z nami, a ustalimy przyczynę.

6. Czego nie sprawdzaliśmy

Bezpieczeństwo, SEO, dostępność i jakość kodu poza profilowanymi najbardziej obciążonymi miejscami w kodzie są poza zakresem tego zlecenia. Audyt obejmuje domyślny store view; store view B2B dzieli stack, ale nie był osobno mierzony. Budżet z rozdziału 1 zostawia kategorie 0,2 s powyżej progu 2,5 s i nie ustaliliśmy, z czego ta różnica wynika: wymaga to przejścia przez szablony kategorii, którego to zlecenie nie obejmowało. Jedno ograniczenie dostępów: nasz użytkownik audytowy nie miał w oknie pomiarowym dostępu do admin socketu Varnisha, więc liczniki runtime Varnisha pochodzą ze snapshotów varnishstat wyeksportowanych przez hosting, a nie z bezpośredniego podglądu w czasie rzeczywistym.

7. Załącznik: sondy do uruchomienia na własnym sklepie

To są kontrole read-only, od których zaczynał ten audyt. Zadziałają na każdym Magento 2 i nie potrzebują niczego poza shellem i klientem bazy danych. Uruchom je, zanim zamówisz audyt u kogokolwiek, u nas również: jeśli wszystkie wypadną w porządku, problem jest gdzieś, gdzie ten raport nie sięga.

1. Czy full-page cache naprawdę obsługuje ruch? Pobierz URL katalogowy dwa razy i przeczytaj nagłówek debug.

$ curl -sI https://twoj-sklep.example/jakas-kategoria | grep -i cache-debug

W porządku: HIT za drugim razem. MISS za każdym razem to F1.

2. Czy coś czyni strony niecache’owalnymi? Jeden blok z cacheable="false" gdziekolwiek w layoucie czyni niecache’owalną całą stronę.

$ grep -R 'cacheable="false"' app/design app/code | wc -l

W porządku: 0.

3. Czy Magento w ogóle umie purge’ować Varnisha?

$ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));'

W porządku: true, jeśli skonfigurowanym cache jest Varnish.

4. Czy OPcache mieści całą bazę kodu? Porównaj obie liczby.

$ find . -type f -name '*.php' | wc -l
$ php -i | grep 'opcache.max_accelerated_files'

W porządku: druga liczba jest większa od pierwszej.

5. Czy build optymalizuje autoloader Composera?

$ grep -c 'classMap' vendor/composer/autoload_static.php

W porządku: cokolwiek innego niż 0.

6. Czy indeksery działają zgodnie z harmonogramem?

$ php bin/magento indexer:show-mode

W porządku: każdy wiersz mówi „Update by Schedule”. Cokolwiek na „Update on Save” to F6. (Nazwa polecenia i nazwy trybów za referencją CLI indekserów Adobe, sprawdzone 1 sierpnia 2026.)

7. Ile martwego balastu leży w bazie?

mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length)
    -> /1024/1024/1024, 1) gb FROM information_schema.tables
    -> WHERE table_name LIKE '%\_\_temp%';

W porządku: kilka tabel. Sklep w tym raporcie miał ich 96, o 41 GB.

8. Na co czeka checkout? Ta sonda potrzebuje APM, nie shella: otwórz transakcję checkoutu, pogrupuj po usłudze zewnętrznej i przeczytaj udział w całym czasie. W tym raporcie na jeden endpoint przypadało 92 % tego czasu, i to jest F3.

8. Kolejne kroki

Plan napraw wykona każdy kompetentny zespół, łącznie z Twoim: każde ustalenie nazywa konkretną zmianę do wykonania. Jeśli mamy go wykonać my, wiersze 1–6 mieszczą się w dwu-, trzytygodniowym zleceniu za stałą cenę na naszych standardowych warunkach współpracy.

Pytania o poszczególne ustalenia: info@zapolu.com, albo umów rozmowę i przynieś własne liczby; podczas rozmowy powiemy Ci, czy audyt ma sens.