Audit výkonu

Audit má dvě úrovně. První má nízkou pevnou cenu, domluvenou předem, a nepotřebujeme k ní od vás nic než adresu e-shopu.

Vstupní audit

Pošlete nám adresu vašeho e-shopu a my ho změříme zvenku: Lighthouse, Core Web Vitals z dat z reálného provozu (field data), pokud jsou k dispozici, a písemný seznam tří úprav, které bychom provedli jako první. Zjištění vám vysvětlíme na 30–60minutovém hovoru. Pokud jsou naměřené hodnoty v pořádku, sdělíme vám i to.

Detailní analýza

Týdenní vymezená spolupráce, na jejímž konci není generické PDF z Lighthouse, ale písemná zpráva a konkrétní plán oprav.

• Real-user metriky. Core Web Vitals z reálného provozu místo syntetického testu v jedné instanci Chromu. Čerpáme z Cloudflare Web Analytics, Vercel Speed Insights nebo jednorázového dotazu do CrUX.
• Server-side trace. Rozpad TTFB podle jednotlivých route, časy databázových dotazů, profil volání třetích stran, cache hit rate.
• Audit bundlů a assetů. Co se posílá, co blokuje vykreslení a co by mělo být načítáno se zpožděním (lazy), přednačteno (preload) nebo úplně odstraněno: obrázky, fonty, JS, CSS, celý transfer.
• Plán oprav podle priority. U každého problému odhad práce, očekávaný dopad v milisekundách (a v konverzi tam, kde se odhad dá opřít o data) a míra rizika. Položky řadíme podle návratnosti, takže realizaci lze při vyčerpání rozpočtu ukončit u kteréhokoli řádku.

Přečtěte si vzorovou zprávu celou, nebo si stáhněte PDF. Klient v ní je smyšlený; struktura a úroveň detailu odpovídají skutečné dodávce.

Co audit dokáže odhalit

Nálezy z deseti let inženýrské práce v e-commerce, na kterých tato praxe stojí, anonymizovaně:

• Každá produktová stránka strávila ~300 ms, občas i celé sekundy, synchronním serverovým voláním marketingového API, a to při každém jednotlivém zobrazení. Odhalilo to trasování transakcí; přesun volání do fronty problém odstranil a rozdíl doložila čísla před a po.
• Cache hit rate zaseknutá na 20–30 %, protože rozšíření pro skladovou dostupnost mazalo po každé objednávce celou Varnish cache. Dodavatel to popíral, takže spor rozhodla reprodukce na čisté instalaci se záznamy z varnishlogu.
• Pokladna selhala na celém webu u objednávky #65 536: tabulka jednoho dodavatele měla SMALLINT jako primární klíč a jeho rozsah se vyčerpal.
• Katalogový dotaz 110× pomalejší, než měl být, se třemi navrstvenými příčinami: platforma si od vyhledávače záměrně žádá 10 000 ID, regrese v nové verzi databáze to zesílila a modul třetí strany navrch rozbil schéma API.
• Noční import, který se prodloužil z 6 na 48 minut. Příčinou byl úklidový cron, který v minulosti selhal bez chybového hlášení a zanechal v databázi o 13 GB staging tabulku o 8 GB.
• Výpis objednávek zákazníka zrychlený z 3,5 s na 800 ms poté, co dotaz přestal pro každý vypsaný řádek načítat kompletní detail objednávky.

Pomalé e-shopy bývají pomalé málokdy z důvodu, který všichni předpokládají. Právě proto se nejdříve měří.

Kdy je audit na místě

• LCP přesahuje 2,5 s, tedy hranici, kterou Google v 75. percentilu označuje za dobrou (web.dev, ověřeno 13. července 2026), a vývoj konverzního poměru naznačuje problém
• Zvažujete replatform a chcete vědět, jestli je problém opravdu ve výkonu
• Po nasazení nové funkce kleslo skóre a příčina není známa
• Před podpisem větší smlouvy potřebujete technický druhý názor

Cena

Cena vstupního auditu je nízká, pevná a znáte ji předem. Detailní analýza má také fixní cenu, tentokrát podle velikosti stacku; je vymezená na 5–10 pracovních dnů a končí plánem oprav. Realizovat ho pak můžete s námi, nebo vlastními silami.