Server Shopify odpověděl za 0,73 sekundy a první obsah se vykreslil za 1,8 sekundy. Hlavní prvek stránky ale naskočil až v 19,2 sekundy a načítání skončilo ve 27,4 sekundy. Naměřeno na jednom e-shopu, který dlouhodobě spravujeme, nástrojem WebPageTest: Chrome, mobilní profil, studená cache, měřicí bod Tokio, 24. 6. 2026.
Ta čtyři čísla jsou celý článek. Platforma byla rychlá, pomalá byla stránka. To je jiná diagnóza, jiný viník a hlavně jiná oprava - a rozdíl mezi nimi rozhoduje o tom, jestli utratíte peníze za migraci, která nic nevyřeší.
Nejdřív rozdělte měření na dvě čísla, jinak opravujete špatnou věc
Metriky rychlosti se dělí na ty, které patří platformě, a ty, které patří vaší stránce. Když se čtou dohromady, vyjde z toho „Shopify je pomalý“, což je závěr, který se nedá opravit ničím kromě stěhování.
| Metrika | Naměřeno | Cíl | Co ve skutečnosti měří |
|---|---|---|---|
| TTFB | 0,73 s | - | odpověď serveru platformy |
| FCP | 1,8 s | - | první vykreslený obsah |
| LCP | 19,2 s | do 2,5 s | hlavní prvek první obrazovky |
| CLS | 1,00 | do 0,1 | posun rozložení během načítání |
| Fully Loaded | 27,4 s | - | dokončení všech požadavků |
První dvě čísla jsou dobrá. Kdyby byl problém v infrastruktuře, byl by pomalý už TTFB - server by se ozval za dvě nebo tři sekundy a všechno ostatní by se posunulo za ním. Tady se ozval za 0,73 sekundy.
Měřicí bod v Tokiu je pro evropský obchod netypický a TTFB by z Prahy vyšel jinak. Na poměr mezi 1,8 a 19,2 sekundy to ale vliv nemá: obě čísla vznikla ve stejném běhu, na stejné lince.
Třetí metrika Core Web Vitals, INP, v tomhle auditu naměřená nebyla, protože se počítá z interakcí návštěvníka. Uvádíme jen to, co jsme měřili.
Rozdíl mezi 1,8 a 19,2 sekundy váží 10,6 MB
Na jediném zobrazení té stránky si prohlížeč stáhl 10,6 MB dat v 548 požadavcích z 57 cizích domén (tentýž běh WebPageTestu, 24. 6. 2026). Padesát sedm domén znamená padesát sedm DNS dotazů, TLS spojení a cizích serverů, na jejichž dostupnost nemáte vliv.
Víc než polovinu té váhy dělal jediný prvek: video 5,7 MB na první obrazovce, vložené s autoplay: true. Takový atribut spustí stahování okamžitě, bez ohledu na kvalitu připojení, a dokud nenaskočí první snímek, LCP se nezapočítá. Jedna řádka v šabloně přebije všechnu ostatní práci.
Vlastní kód tématu měl 635 kB. Na živé stránce jich byly tři megabajty
Když jsme rozebrali lokální kopii téhož tématu (27. 8. 2026), našli jsme v něm 32 vlastních skriptů o velikosti 635 kB a ani jeden z nich nebyl připojený bez atributu defer. Vlastní kód byl v pořádku.
Na živé stránce přitom měřicí nástroj napočítal řádově 3 MB JavaScriptu ve 236 souborech. Rozdíl mezi 635 kB a 3 MB nepřineslo téma. Přinesly ho aplikace a jejich externí skripty.
Praktický důsledek pro rozpočet: kdo zaplatí za refaktoring tématu a neřeší aplikace, kupuje si menší část problému. Co po aplikacích v tématu zůstává, rozebíráme v článku o auditu aplikací.
CLS 1,00 znamená, že se stránka postaví dvakrát
Hodnota posunu rozložení 1,00 při cíli 0,1 není zhoršená metrika, to je jiná stránka, než jakou návštěvník viděl o sekundu dřív. Dva měřitelné důvody, oba z rozboru tématu 27. 8. 2026:
- 577 tagů <img> v tématu, z toho 13 s atributem width (2 %) a 29 s loading (5 %). Prohlížeč neví, kolik místa má obrázku nechat, tak mu nenechá žádné a po dotažení všechno posune.
- 171 volání stylesheet_tag v sekcích a snippetech. Každé z nich vloží <link rel="stylesheet"> do těla dokumentu, tedy až za začátek vykreslování.
U druhého bodu jsme opatrní: souvislost se změřeným CLS 1,00 je pravděpodobná, ale nepotvrdili jsme ji. Kontrolní měření po přesunu stylů do layoutu jsme zatím neudělali, takže to zůstává hypotéza, ne nález.
Filtr image_tag doplní rozměry i srcset sám a otázku zavře na úrovni šablony. V tomhle tématu byl použitý v pěti souborech ze všech.
Dvanáct cizích skriptů bez defer je dvanáct cizích výpadků
Ve stejném tématu jsme napočítali 12 externích skriptů bez atributu defer nebo async ze sedmi cizích hostitelů. Dva z nich jsou synchronní přímo v <head> - tam parser zastaví zpracování dokumentu, dokud se soubor nestáhne z cizího serveru.
To není jen otázka rychlosti. Je to jediný bod selhání: když ten cizí server neodpoví, nevykreslí se nic. Jeden z hostitelů v tom tématu, polyfill.io, vracel při naší kontrole 27. 8. 2026 chybu HTTP 520.
PageSpeed Insights míchá dvě různá měření a jen jedno je o vaší stránce
Nástroj ukazuje dvě sady čísel: laboratorní simulaci, která proběhne teď a na definovaném zařízení, a terénní data od skutečných návštěvníků za posledních 28 dní. Když se hodnoty rozcházejí, není to chyba nástroje.
Znamená to, že vaši návštěvníci mají jiná zařízení a jinou linku než simulace - a pro rozhodování platí terénní data, protože v nich sedí vaši zákazníci. Laboratorní číslo je dobré na to, aby se dvě verze stránky daly porovnat mezi sebou ve stejných podmínkách.
Pořadí oprav, ve kterém se to dělá
Pořadí není libovolné. Prvních pět položek na téhle stránce představovalo většinu ztraceného času, zbytek byla kosmetika.
- První obrazovka. Video a hlavní obrázek: postery, rozměry, loading="eager" a fetchpriority="high" na LCP prvek.
- Inventura aplikací. Které běží, které jsou zaplacené a které jen zbyly.
- Externí skripty. Co jde odložit, co jde hostovat u sebe, co musí pryč.
- Styly do layoutu. Kritické inline, zbytek asynchronně.
- Rozměry obrázků v celém tématu, přes image_tag.
- Kontrolní měření za stejných podmínek, jinak nevíte, co pomohlo.
Poslední bod je ten, který se nejčastěji vynechává. Měření před opravou a po opravě musí proběhnout na stejném profilu, ze stejného místa a se studenou cache, jinak porovnáváte dvě různé věci.
Co se za zrychlení platí
Tuhle stranu je potřeba říct nahlas, protože ji nabídky na zrychlení obvykle vynechávají. Když sundáte aplikaci, zmizí s ní funkce, kterou jste platili - věrnostní program, hodnocení produktů, upsell v košíku.
Rozhodnutí proto nepatří vývojáři. Patří tomu, kdo ví, kolik ta funkce vydělává. Naše práce je dodat druhou půlku rovnice: kolik stojí v datech, v sekundách a v riziku výpadku.
Měříme i vlastní web a nevychází nám to
Vlastním nástrojem jsme 30. 8. 2026 změřili tenhle web na třech šířkách obrazovky a vyšlo 5,3 až 5,6 MB v 55 až 69 požadavcích. Na agenturu, která prodává rychlost, je to nepříjemné číslo a je na seznamu k opravě.
Uvádíme ho tady schválně. Text o rychlosti, ve kterém autor vychází dobře, si přečtete všude; užitečný je ten, kde jsou vidět podmínky měření a datum, protože jen podle nich si můžete ověřit, jestli čísla platí i pro vás.
Chcete vědět, které tři věci brzdí právě váš e-shop
Pošlete nám adresu obchodu. Vrátíme rozdělení na to, co dělá platforma, a to, co dělá stránka, se změřenými čísly a s pořadím oprav podle poměru efekt ku ceně.
Co v rámci auditu a zrychlení webu konkrétně měříme, najdete na stránce služby. Když řešíte rychlost jako součást většího zásahu do tématu, začněte článkem o tom, jak se šablony vymknou.
Napište na info@lamapixel.com nebo volejte +420 775 599 009.
