--- title: "Przykładowy raport z audytu wydajności" description: "Pełny efekt audytu wydajności Magento na fikcyjnym sklepie: jedenaście ustaleń, przy każdym dowód, koszt naprawy i plan uszeregowany według zwrotu. Na końcu są sondy, żebyś te same kontrole uruchomił na własnym sklepie." language: "pl" canonical: "https://zapolu.com/pl/downloads/sample-audit-report/" --- # Audyt wydajności: deep dive (przykładowy raport) > **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](https://zapolu.com/pl/about/). 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. 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: 1. 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. 2. 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](https://zapolu.com/pl/blog/dlaczego-erp-i-sklep-roznia-sie-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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/manage-indexers), 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](https://zapolu.com/pl/downloads/zapolu-engagement-template.pdf). Pytania o poszczególne ustalenia: [info@zapolu.com](mailto:info@zapolu.com), albo [umów rozmowę](https://zapolu.com/pl/contact/) i przynieś własne liczby; podczas rozmowy powiemy Ci, czy audyt ma sens.