--- title: "Vzorová zpráva z výkonnostního auditu" description: "Kompletní výstup výkonnostního auditu Magenta na smyšleném e-shopu: jedenáct nálezů, u každého doklad, cena opravy a plán seřazený podle návratnosti. Na konci jsou sondy, abyste si stejné kontroly pustili na svém e-shopu." language: "cs" canonical: "https://zapolu.com/cs/downloads/sample-audit-report/" --- # Výkonnostní audit: deep dive (vzorová zpráva) > **Toto je vzor.** Klient „Acme Outdoor s.r.o.“ neexistuje a > identifikační údaje jsou změněné. Nálezy i čísla jsou anonymizovaná > a poskládaná ze skutečných výkonnostních auditů, které Luboš Zápotočný > odvedl během deseti let inženýrské práce v e-commerce, ještě před > vznikem této praxe. Nejde o zakázky realizované pod značkou Zapolu, ta > vlastní klientskou historii zatím nemá; doklady o té dřívější práci > najdete na stránce [O nás](https://zapolu.com/cs/about/). Vzor > ukazuje formát: čím je nález doložen, co stojí jeho oprava a jak je > práce seřazená. Zpráva, kterou dostane klient, rozebírá každý nález > stejně podrobně jako níže F1; tento vzor šest z jedenácti zkracuje, > aby zůstal čitelný. | | | |---|---| | **Klient** | Acme Outdoor s.r.o. (smyšlený) | | **E-shop** | acme-outdoor.example (Magento 2.4.6, frontend Luma) | | **Stack** | Varnish 7, Redis 7, MySQL 8, 2 aplikační nody za load balancerem | | **Datum zprávy** | 5. června 2026 | | **Data z provozu** | 7. května až 3. června 2026 (28 dní) | | **APM trace** | 21. května až 3. června 2026 (14 dní) a jeden zátěžový test | | **Nástroje** | New Relic, CrUX, Lighthouse, k6, varnishstat, MySQL slow log | | **Autor** | Luboš Zápotočný, Zapolu s.r.o. | | **Zakázka** | Deep dive, 7 pracovních dní, fixní cena | **Pro stručný přehled** si přečtěte kapitolu 1 a kapitolu 5. Text mezi nimi tvoří podklady k jednotlivým nálezům. ## 1. Shrnutí Pomalost e-shopu vzniká na straně serveru. LCP z field dat je na katalogových stránkách **4,6 s na p75** (cíl: ≤ 2,5 s); hlavní příčinou je **TTFB 1,9 s**. TTFB je vysoké proto, že full-page cache je fakticky vypnutá: Varnish obsluhuje jen **34 %** katalogových požadavků a 38 % veškerého serverového času připadá na vykreslování produktových stránek, v průměru 2,2 s na požadavek. Během kampaňového večera 26. května dosáhl checkout p95 **6,1 s** a **3,4 % požadavků selhalo**, zatímco CPU aplikačních serverů nepřekročilo 12 %. Následuje jedenáct nálezů. Sedm z nich stojí den práce nebo méně a dva z těch sedmi (F2 a F8) jsou změny jen v konfiguračních souborech. Řádky 1 až 6 plánu oprav odstraní všechna selhání, která zákazník pocítí: checkout přestane ve špičce selhávat a checkout p95 během kampaní klesne z 6,1 s na 1,9 s. Largest Contentful Paint se jen s těmito řádky pod hranici 2,5 s stanovenou Googlem nedostane. Rozpočet: | Stav | Co se mění | LCP kategorie | LCP produktu | |---|---|---|---| | dnes | | 4,6 s | 4,6 s | | po řádku 2 | F1, TTFB katalogu 1,9 s → 1,2 s | 3,9 s | 3,9 s | | po řádku 5 | F5, hero obrázky produktů | 3,9 s | 3,3 s | | po řádku 7 | F4 dočasně, mrtvé tagy a odklad | 3,5 s | 2,9 s | | po řádku 8 | F4, přestavba frontendu | 2,7 s | 2,1 s | Pod práh dostane produktové stránky až přestavba v řádku 8. Kategorie končí na 2,7 s, tedy stále nad prahem; co by zbytek dorovnalo, jsme nezjišťovali (kapitola 6). Řádky jsou seřazené podle návratnosti, takže plán lze kdykoli ukončit. Přepočteno na peníze: během tří hodin kampaně večer 26. května skončilo chybou zhruba 230 checkoutů. Při průměrné hodnotě objednávky 1 800 Kč to dělá 414 000 Kč v objednávkách, které selhaly, tedy asi 17 000 € při kurzu 24,3 Kč za euro, a nezapočítává to zákazníky, kteří checkout po šesti sekundách čekání opustili. Ostatní nálezy uvádíme v milisekundách; částka v korunách by u nich byla spekulativní, proto ji neuvádíme. ## 2. Co a jak jsme měřili - **Metriky reálných uživatelů:** Core Web Vitals z 28denního CrUX dotazu, segmentované podle typu stránky (homepage / kategorie / produkt / checkout). Syntetické Lighthouse běhy sloužily jen k reprodukci nálezů, ne k jejich hodnocení. Jak si e-shop stojí proti prahovým hodnotám Googlu: | Metrika (p75, field data) | E-shop | Práh | Verdikt | |---|---|---|---| | LCP | 4,6 s | < 2,5 s | neprošlo | | INP | 280 ms | < 200 ms | neprošlo | | CLS | 0,04 | < 0,1 | prošlo | | FCP | 2,9 s | < 1,8 s | neprošlo | | TTFB | 1,9 s | < 0,8 s | neprošlo | - **Trasování na serveru:** transakční profil z New Relic za 14 dní, tedy kam serverový čas doopravdy jde: | Transakce | Podíl serverového času | Průměrná odpověď | |---|---|---| | `catalog/product/view` | 38 % | 2,2 s | | `catalog/category/view` | 17 % | 1,8 s | | checkout REST (košík + doprava) | 11 % | 1,4 s (6,1 s p95 ve špičce) | K tomu MySQL slow query log, profil volání externích služeb a statistiky hit/miss Varnishe podle URL vzorů z `varnishstat`. - **Zátěžový test:** replay průběhu provozu z kampaně večer 26. května (0 → 420 req/s během 20 minut) proti stagingu se stejným stavem cache jako v produkci. - **Revize konfigurace:** nastavení PHP a OPcache, Composer autoloader, `env.php`, Varnish VCL a nastavení MySQL, každé proti dokumentovaným doporučením pro Magento, navýšeným tam, kde kódová základna dokumentovanou hodnotu přerůstá. - **Audit bundlů a assetů:** co se posílá při prvním zobrazení produktové stránky, co blokuje vykreslení a co je zbytečná zátěž. U většiny nálezů citujeme přesný příkaz nebo dotaz, který jsme použili, jednak aby si váš tým mohl naši práci překontrolovat, jednak proto, že stejné sondy poběží na kterémkoli Magento e-shopu, včetně toho vašeho. Kapitola 7 je sbírá tak, aby se daly spustit beze změny. U každého čísla níže je uvedeno, odkud pochází, a tabulka nálezů má sloupec, který říká, zda byl očekávaný dopad změřen, reprodukován v zátěži, nebo odhadnut. ## 3. Přehled nálezů **Vysoká**: dopadá na zákazníky, nebo na ní závisí tržby. **Střední**: denně ji pociťuje tým, nebo tiše poškozuje data. **Nízká**: malé úsilí, které odstraní reálné provozní riziko. | # | Nález | Závažnost | Pracnost | Očekávaný dopad | Podklad | |---|-------|-----------|----------|-----------------|---------| | F1 | Full-page cache je fakticky vypnutá a nejde invalidovat | Vysoká | 1–2 dny | −700 ms TTFB na p75 v katalogu | změřeno | | F2 | PHP runtime a autoloader špatně nastavené pro Magento | Vysoká | 0,5 dne | −400 ms na každém necachovaném požadavku | odhad | | F3 | Checkout blokuje synchronní dotaz na sklad v ERP | Vysoká | 3–5 dní | −2,8 s checkout p95 ve špičce; konec timeoutových chyb | zátěžový test | | F4 | Frontend posílá 2,3 MB JavaScriptu, blokuje vykreslení | Vysoká | projekt | −1,2 s LCP (dočasná zmírnění: −0,4 s) | odhad | | F5 | Produktové obrázky: 1,6MB PNG, bez responzivních velikostí | Střední | 1 den | −0,6 s LCP na produktových stránkách | změřeno | | F6 | Indexery ponechané na „Update on Save“ | Střední | 0,5 dne | Uložení v adminu 30 s → ~2 s; konec nesouladu skladových stavů | odhad | | F7 | PHP-FPM pool vyčerpaný session locky ve špičce | Vysoká | 2 dny | Checkout přežije kampaňový provoz | zátěžový test | | F8 | Varnish bez grace módu | Nízká | 0,5 dne | Ztlumí nápor po každém flushi cache | odhad | | F9 | Dvě extenze poslouchají stejný event; jedna je opuštěná | Střední | 1 den | −300 ms na přidání do košíku | změřeno | | F10 | 41 GB mrtvých indexerových temp tabulek v MySQL | Nízká | 0,5 dne | Zálohy o 60 % menší; obnova zhruba za polovinu času | změřeno | | F11 | Order grid v adminu filtruje přes neindexovaný sloupec | Nízká | 0,5 dne | Grid objednávek 12 s → pod 1 s | odhad | **Podklad** říká, odkud očekávaný dopad pochází. *Změřeno*: viděli jsme to na tomto e-shopu. *Zátěžový test*: reprodukovali jsme to na stagingu při zátěži odpovídající kampani. *Odhad*: plyne z profilu a konfigurace a nikdo to zatím nepozoroval. ## 4. Nálezy podrobně ### F1: Full-page cache je fakticky vypnutá a nejde invalidovat (Vysoká) **Co jsme viděli.** Varnish hlásí na katalogových URL hit rate 34 %. Pro katalog této velikosti a s tímto podílem crawlerů je běžná hodnota nad 90 %. Každá kategorie i produktová stránka nese `X-Magento-Cache-Debug: MISS`. Příčiny jsou dvě nezávislé: 1. Upravený `default.xml` označuje jeden blok v hlavičce (přepínač store view, který čte zákaznickou session) jako `cacheable="false"`. V Magentu jediný necachovatelný blok v layoutu udělá necachovatelnou **celou stránku**. Blok přibyl s aktualizací extenze v listopadu 2025; hit rate se zhroutil ve stejném týdnu. 2. Varnish je zapnutý v administraci (`system/full_page_cache/caching_application = 2`), ale v `env.php` chybí sekce `http_cache_hosts`, takže Magento vůbec neumí posílat purge požadavky do Varnishe. Tým to obchází restartem Varnishe po každém deployi, a právě proto jsou deploye problematické (viz F8). Jak jsme to ověřili: ``` $ curl -sI https://acme-outdoor.example/stany | grep -i cache-debug X-Magento-Cache-Debug: MISS # stejně na každé katalogové URL $ grep -R 'cacheable="false"' app/design app/code | wc -l 1 # přepínač store view v default.xml $ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));' false # Magento neumí poslat purge do Varnishe ``` **Oprava.** Vykreslit přepínač přes private content (customer data JS), takže stránka zůstane cachovatelná (dokumentovaný vzor pro fragmenty závislé na session), a doplnit `http_cache_hosts` do `env.php`, aby fungovala invalidace přes tagy a restarty mohly skončit. **Pracnost / dopad / riziko.** 1–2 dny včetně regresních testů. Očekávaných −700 ms TTFB na p75 katalogu (změřeno: cachovaná katalogová odpověď se vrací za 80 ms, necachovaná za 1,9 s). Riziko: nízké; obě změny jsou ohraničené a vratné po jednotlivých deployích. ### F2: PHP runtime a autoloader špatně nastavené pro Magento (Vysoká) **Co jsme viděli.** Základna kódu obsahuje ~125 000 PHP souborů; OPcache je nastavená na 10 000. Composer autoloader nebyl nikdy optimalizován: `vendor/composer/autoload_static.php` neobsahuje mapu tříd a v New Relic trace jsou vidět celé sekundy, které stráví `ObjectManager` sestavováním instancí při prvních požadavcích, než se naplní cache tříd. Aktuální stav a doporučení: | Nastavení | Aktuální | Doporučené | |---|---|---| | `opcache.max_accelerated_files` | 10 000 | 100 000 | | `opcache.memory_consumption` | 128 | 512 | | `opcache.validate_timestamps` | On, revalidace každé 2 s | Off; reset při deployi | | `opcache.enable_cli` | Off | On (indexery a crony jsou také PHP) | | `realpath_cache_size` | 4M | 32M | | `realpath_cache_ttl` | 120 | 7200 | | Composer autoloader | neoptimalizovaný | `dump-autoload --optimize` v buildu | Jak jsme to ověřili: ``` $ find . -type f -name '*.php' | wc -l 124862 # PHP souborů v codebase $ php -i | grep 'opcache.max_accelerated_files' opcache.max_accelerated_files => 10000 # pojme 8 % z nich $ grep -c 'classMap' vendor/composer/autoload_static.php 0 # autoloader nebyl nikdy optimalizován ``` **Proč.** S těmito hodnotami PHP průběžně znovu statuje a překládá velkou část codebase; profily připisují přes polovinu času necachovaného renderu načítání tříd a sestavování stránky místo obchodní logiky. **Oprava.** Jedna změna konfigurace plus jeden krok v buildu. Jediná vazba, kterou je nutné respektovat: s vypnutým `validate_timestamps` musí deploy pipeline při release resetovat OPcache. Přesný krok pro vaši současnou pipeline jsme popsali v plánu oprav. **Pracnost / dopad / riziko.** 0,5 dne. Odhadem −400 ms na každém necachovaném požadavku (a rychlejší crony a indexery jako vedlejší efekt). Riziko: nízké, pokud krok v deployi přistane spolu s konfigurací. ### F3: Checkout blokuje synchronní dotaz na sklad v ERP (Vysoká) **Co jsme viděli.** Ve fázi dopravy ukazuje trace synchronní HTTPS volání na skladový endpoint ERP s 3sekundovým timeoutem a jedním opakováním; profil externích služeb připisuje tomuto jedinému endpointu 92 % veškerého čekání na externí systémy. Při kampaňové zátěži se ERP zpomalí, volání si vyberou celý timeout a požadavky checkoutu se začnou hromadit. Přesně odsud pochází p95 6,1 s i 3,4 % selhání. Zátěžový test to na stagingu reprodukuje. **Proč.** Potvrzování skladu v reálném čase přibylo po incidentu s přeprodejem v roce 2025. Záměr je správný, jen vkládá latenci cizího systému do každého checkoutu. **Oprava.** Přesunout srovnávání skladu mimo request: rezervovat proti lokální inventuře, potvrzovat asynchronně a upozorňovat na nesoulad skladových stavů. Ochrana proti přeprodeji zůstane zachována a checkout přestane na ERP čekat. Stejný vzor rozebíráme v článku [proč se ERP a e-shop neshodnou na skladu](https://zapolu.com/cs/blog/proc-se-erp-a-eshop-neshodnou-na-sklade/). **Pracnost / dopad / riziko.** 3–5 dní včetně alertu na nesoulad stavů. Odstraní ~2,8 s z checkout p95 ve špičce a timeoutová selhání úplně (obojí změřeno v zátěžovém testu se zaslepeným voláním). Riziko: střední; vyžaduje písemné odsouhlasení nového okna přeprodeje (odhadem < 0,1 % kampaňových objednávek, proti dnešním 3,4 % selhávajících checkoutů). ### F4: Frontend posílá 2,3 MB JavaScriptu (Vysoká) **Co jsme viděli.** První zobrazení produktové stránky stáhne 2,3 MB JavaScriptu v 61 souborech; blokování hlavního vlákna dělá na běžném telefonu 2,9 s. Čtyři ze čtrnácti marketingových tagů už nemají za sebou funkční účet. **Proč.** Zčásti architektura frontendu Luma, zčásti osm let přirůstání tagů; žádný jednotlivý tag v součtu nepřevažuje. **Oprava, krátkodobě (toto čtvrtletí).** Odstranit čtyři mrtvé tagy, odložit analytický bundle a widget recenzí níže na stránce načítat až ve chvíli, kdy je potřeba. Odhadem −0,4 s LCP, 2 dny. **Oprava, skutečná (samostatné rozhodnutí).** Přestavba frontendu na Hyvä. Nahrazuje javascriptovou vrstvu Lumy, místo aby její části jen odkládala, takže o objemu payloadu rozhoduje architektura, ne správa jednotlivých tagů. Je to projekt na 6–10 týdnů a zaslouží si vlastní nacenění, ne řádek v seznamu oprav. Zmiňujeme ho zde, aby krátkodobý odhad výše nebyl chápán jako dosažitelné maximum. ### F7: PHP-FPM pool vyčerpaný session locky ve špičce (Vysoká) **Co jsme viděli.** Během zátěžového testu začínají selhání kolem 280 req/s, zatímco CPU sedí na 12 %. Status FPM ukazuje všechny workery obsazené; trace ukazují čekání na session locky v Redisu: zákazníci, kteří se opakovaně dotazují stránky potvrzení objednávky, drží zámky, které řadí do fronty všechny další požadavky téže session. **Oprava.** Vypnout zamykání session pro endpointy opakovaného dotazování, zvednout počet workerů na to, co paměťová rezerva reálně dovolí (dnešní číslo pochází z menšího typu instance), a přidat alert na saturaci FPM; tento výpadek zůstal nezpozorován, protože grafy CPU vypadaly zdravě. **Pracnost / dopad / riziko.** 2 dny včetně opakování zátěžového testu. Spolu s F3 přežije staging 420 req/s s checkout p95 1,9 s. Riziko: nízké. ### F5, F6, F8, F9, F10, F11 stručně - **F5 Obrázky:** hlavní (hero) obrázky produktů jsou PNG o 1,6 MB doručované v jedné velikosti všem zařízením. Konverze do WebP + responzivní velikosti přes CDN: 1 den, −0,6 s LCP na produktových stránkách (změřeno na převedeném vzorku). - **F6 Indexery:** přepnuté na „Update on Save“ při hromadném importu v únoru 2026 a už nikdy zpět. Uložení produktu v adminu trvá 30 s a nesoulad mezi skladem na webu a realitou ve skladu pochází z race conditions při reindexu. Vrátit plánované indexování: 0,5 dne. Těch 30 s je změřených; číslo po opravě je odhad. - **F8 Varnish grace:** každý flush cache dnes pošle celou vlnu provozu na PHP. Grace mód vrací staré objekty, dokud se cache znovu nenaplní: 0,5 dne. Dopad je odhad. - **F9 Duplicitní observery:** dvě extenze odebírají stejný checkout event; jednu z nich její dodavatel opustil v roce 2023 a při každém volání znovu načítá quote. Odstranit ji (její funkce se nepoužívá): 1 den včetně ověření, −300 ms na přidání do košíku (změřeno v trace). - **F10 Úklid databáze:** databáze nese 41 GB tabulek `catalogrule_product__temp*` (pozůstatky nedoběhnutých indexerů ze starší verze Magenta, která po sobě neuklízela) plus vlastní frontovou tabulku s 12 miliony řádků bez jakékoli retence. Najde je jedna query 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 | +--------+------+ ``` Smazání pozůstatků a nastavení pravidelného čištění: 0,5 dne. Zálohy se zmenší z 68 GB na 27 GB; obnova pak trvá zhruba polovinu času, což je odhad ze změny velikosti a počítá se hlavně v den, kdy obnovu opravdu potřebujete. - **F11 Order grid v adminu:** sloupec přidaný pro expedici filtruje přes neindexovaný atribut; grid se načítá 12 s a pokaždé blokuje jeden worker. Jedna indexová migrace: 0,5 dne. Těch 12 s je změřených; číslo po opravě je odhad. ## 5. Plán seřazený podle návratnosti | Pořadí | Položky | Pracnost | Co získáte | |--------|---------|----------|------------| | 1 | F2 + F8 | 1 den | Každý necachovaný požadavek −400 ms; flushe cache už nevyvolají špičku zátěže | | 2 | F1 | 1–2 dny | TTFB katalogu −700 ms; deploye přestanou vyžadovat restart Varnishe | | 3 | F6 + F10 + F11 | 1,5 dne | Použitelný admin; konec nesouladu skladových stavů; zálohy na polovinu | | 4 | F7 | 2 dny | Checkout přestane ve špičce selhávat | | 5 | F5 + F9 | 2 dny | LCP produktové stránky −0,6 s; přidání do košíku −300 ms | | 6 | F3 | 3–5 dní | Checkout p95 pod 2 s během kampaní | | 7 | F4 krátkodobě | 2 dny | LCP −0,4 s, než padne rozhodnutí o frontendu | | 8 | F4 přestavba | samostatné nacenění | LCP produktových stránek pod prahem 2,5 s | Řádky 1–6 dají dohromady 10,5 až 13,5 inženýrského dne a řeší všechna selhání, která zákazník pocítí. Po kterémkoli řádku můžete skončit a práce do té chvíle obstojí sama o sobě. Řádek 6 jako jediný zasahuje do architektury objednávkové cesty; ať už ho provede kdokoli, nechte návrh posoudit seniorním inženýrem. Po řádku 6 přeměřte stejným dotazem na field data, kterým tato zpráva začala. Pokud se čísla nepohnou podle predikce, kontaktujte nás a zjistíme příčinu. ## 6. Co jsme nekontrolovali Bezpečnost, SEO, přístupnost a kvalita kódu mimo profilovaná nejvytíženější místa kódu jsou mimo rozsah této zakázky. Audit pokrývá výchozí store view; B2B store view sdílí stack, ale neměřili jsme ho zvlášť. Rozpočet z kapitoly 1 nechává kategorie 0,2 s nad prahem 2,5 s a nezjišťovali jsme, čím je ten rozdíl daný: vyžaduje to průchod šablonami kategorií, na který se tato zakázka nezaměřila. Jedno omezení přístupů: náš auditní uživatel se během okna nedostal k admin socketu Varnishe, takže runtime čítače Varnishe pocházejí ze snapshotů `varnishstat`, které nám exportoval hosting, ne z přímé kontroly v reálném čase. ## 7. Příloha: sondy, které si můžete pustit sami Toto jsou read-only kontroly, kterými tento audit začínal. Poběží na kterémkoli Magentu 2 a nepotřebují nic než shell a databázového klienta. Pusťte si je dříve, než si u kohokoli objednáte audit, u nás také: pokud jsou všechny výsledky v pořádku, problém je někde, kam tato zpráva nesahá. **1. Obsluhuje full-page cache doopravdy?** Vyžádejte si katalogovou URL dvakrát a přečtěte si debug hlavičku. ``` $ curl -sI https://vas-eshop.example/nejaka-kategorie | grep -i cache-debug ``` V pořádku: `HIT` na druhý pokus. `MISS` pokaždé je F1. **2. Nedělá něco stránky necachovatelné?** Jediný blok s `cacheable="false"` kdekoli v layoutu udělá necachovatelnou celou stránku. ``` $ grep -R 'cacheable="false"' app/design app/code | wc -l ``` V pořádku: `0`. **3. Umí Magento vůbec purgovat Varnish?** ``` $ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));' ``` V pořádku: `true`, pokud je nastavenou cache Varnish. **4. Pojme OPcache celou codebase?** Porovnejte obě čísla. ``` $ find . -type f -name '*.php' | wc -l $ php -i | grep 'opcache.max_accelerated_files' ``` V pořádku: druhé číslo je větší než první. **5. Optimalizuje build Composer autoloader?** ``` $ grep -c 'classMap' vendor/composer/autoload_static.php ``` V pořádku: cokoli jiného než `0`. **6. Běží indexery podle plánu?** ``` $ php bin/magento indexer:show-mode ``` V pořádku: každý řádek hlásí „Update by Schedule“. Cokoli na „Update on Save“ je F6. (Název příkazu i názvy režimů podle [referenční příručky Adobe k indexerům](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/manage-indexers), ověřeno 1. srpna 2026.) **7. Kolik mrtvé váhy je v databázi?** ``` mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length) -> /1024/1024/1024, 1) gb FROM information_schema.tables -> WHERE table_name LIKE '%\_\_temp%'; ``` V pořádku: pár tabulek. E-shop v této zprávě jich měl 96, o 41 GB. **8. Na co čeká checkout?** Tato sonda potřebuje APM, ne shell: otevřete transakci checkoutu, seskupte podle externí služby a přečtěte si podíl na celkovém čase. V této zprávě připadalo na jediný endpoint 92 % toho času, což je F3. ## 8. Další kroky Plán oprav zvládne provést kterýkoli kompetentní tým včetně vašeho: každý nález pojmenovává konkrétní změnu, kterou je třeba udělat. Pokud ho máme provést my, řádky 1–6 se vejdou do dvou- až třítýdenní zakázky za fixní cenu podle našich standardních [podmínek spolupráce](https://zapolu.com/cs/downloads/zapolu-engagement-template.pdf). Dotazy k jednotlivým nálezům: [info@zapolu.com](mailto:info@zapolu.com), nebo si [domluvte hovor](https://zapolu.com/cs/contact/) a přineste vlastní čísla; na hovoru vám rovnou sdělíme, zda se audit vyplatí.