Pomalý e-shop není jen technický problém — je to problém obchodní. Výzkum Googlu z roku 2023 ukázal, že každých 100 ms zpoždění načítání stránky snižuje konverzní poměr o 0,3 až 1 %. Studie Deloitte zjistila, že zlepšení rychlosti o 0,1 vteřiny vedlo u maloobchodních e-shopů ke zvýšení konverzí o 8,4 % a průměrné hodnoty objednávky o 9,2 %. Přesto se většina majitelů e-shopů řeší slow loading teprve ve chvíli, kdy jim začnou klesat tržby — a i tehdy hledají řešení na špatném místě.
Nejdřív měřte, pak opravujte
Před každou optimalizací potřebujete vědět, kde přesně problém leží. Nejčastější chyba je nasadit nový hosting nebo zkomprimovat pár obrázků a pak se divit, proč se nic nezlepšilo.
Základní nástroje, které byste měli znát:
Google PageSpeed Insights (pagespeed.web.dev) — zadejte URL e-shopu a dostanete skóre od 0 do 100 pro mobilní i desktopovou verzi. Důležitá jsou data z reálných uživatelů (CrUX data), ne jen laboratorní test. Skóre pod 50 na mobilu je kritický stav.
Core Web Vitals jsou tři metriky, které Google používá jako signál pro řazení ve vyhledávání:
| Metrika | Co měří | Dobrá hodnota |
|---|---|---|
| LCP (Largest Contentful Paint) | Jak rychle se načte hlavní obsah stránky | pod 2,5 s |
| INP (Interaction to Next Paint) | Jak rychle stránka reaguje na kliknutí | pod 200 ms |
| CLS (Cumulative Layout Shift) | Jak moc se stránka "skáče" při načítání | pod 0,1 |
Google Search Console → sekce "Prostředí pro web" zobrazí, jak si stojíte na základě dat od reálných návštěvníků vašeho webu — ne simulovaného testu.
Příklad z praxe: Autodíly Procházka z Pardubic měli PageSpeed skóre 38 na mobilu. Po auditu zjistili, že hlavní problém je LCP 6,8 s způsobený obrázkem prvního produktu v hero sekci, který měl 2,1 MB a nebyl přednačítán. Samotná oprava tohoto jednoho problému posunula LCP na 2,9 s a celkové skóre na 61.
Optimalizace obrázků: největší rychlostní zisk za nejméně práce
Obrázky tvoří průměrně 50–70 % celkové váhy stránky e-shopu. Jsou to produktové fotky, bannery, ikony, loga. A drtivá většina e-shopů je servíruje špatně.
Formát: Přejděte na WebP. Je to formát podporovaný všemi moderními prohlížeči a průměrně je o 25–35 % menší než JPEG při stejné vizuální kvalitě. Pokud máte Shoptet nebo WooCommerce, existují pluginy, které konverzi udělají automaticky. Vlastní řešení by mělo konvertovat obrázky při uploadu.
Velikost: Servírujte obrázky v rozlišení, ve kterém se skutečně zobrazí. Produktová fotka, která se zobrazuje 400×400 px, nemusí mít 2000×2000 px. Použijte atribut srcset pro různé velikosti obrazovek.
Lazy loading: Obrázky, které jsou pod viditelnou částí stránky, není třeba načítat okamžitě. Atribut loading="lazy" na <img> tagách říká prohlížeči, ať s nimi počká, dokud se uživatel nescrolluje blíž. Výjimka: první obrázek na stránce (hero nebo první produkt) nikdy nedávejte do lazy loadingu — ten naopak přednačtěte pomocí <link rel="preload">.
Komprese: Nástroje jako Squoosh, ImageOptim nebo automatizované pipeline (Sharp pro Node.js) dokáží zmenšit soubory o 40–80 % bez viditelné ztráty kvality.
Praktický tip: Proveďte rychlý audit: otevřete DevTools v Chrome (F12), záložka Network, filtr Img, reload stránky. Seřaďte obrázky podle velikosti. Horní pětka pravděpodobně tvoří 80 % váhy obrázků — a právě tam začněte.
JavaScript bloat: co sekýruje váš e-shop
Průměrná stránka e-shopu dnes obsahuje 400–600 kB JavaScriptu. Před deseti lety to bylo 50–80 kB. Většina tohoto nárůstu nepřináší žádnou hodnotu pro zákazníka — jsou to analytické skripty, chatboty, skripty A/B testovacích nástrojů, widgety recenzí a tracking pixely.
Každý z těchto skriptů:
- blokuje nebo zpomaluje vykreslování stránky
- spotřebovává procesor zařízení (kritické na starších telefonech)
- přidává síťové požadavky
Co auditovat a kdo je viník:
| Typ skriptu | Typická váha | Opravdu ho potřebujete? |
|---|---|---|
| Google Tag Manager (s 15 tagy) | 80–150 kB | Auditujte, co v GTM máte |
| Facebook Pixel | 50 kB | Jen pokud aktivně inzerujete |
| Hotjar / Microsoft Clarity | 60–120 kB | Jen pokud data aktivně čtete |
| Live chat widget | 80–200 kB | Zvažte, kolik konverzí generuje |
| Page builder (Elementor, apod.) | 200–400 kB | Největší problém |
| Recenzní widgety třetích stran | 30–80 kB | Zvažte vlastní implementaci |
Page buildery jsou speciální kategorie. Nástroje jako Elementor nebo Divi generují obrovské množství zbytečného CSS a JavaScriptu. Pokud váš e-shop stojí na WordPressu s Elementorem, samotný page builder může za 30–50 % celkové váhy stránky.
Příklad z praxe: Módní butik Elegance Praha přešel z WooCommerce s Elementorem na vlastní šablonu psanou "natvrdo". Bez jakékoli jiné změny klesla váha JavaScriptu z 890 kB na 180 kB. PageSpeed skóre na mobilu vzrostlo ze 41 na 79. Konverzní poměr se zlepšil o 14 % za první měsíc.
Server-side rendering vs. client-side pro produktové stránky
Toto je architekturální rozhodnutí, které zásadně ovlivňuje výkon — a mnoho e-shopů ho dělá špatně.
Client-side rendering (CSR): Prohlížeč stáhne prázdný HTML soubor, stáhne JavaScript, spustí ho, JavaScript teprve načte produktová data a vykreslí stránku. Výsledek: pomalé první načtení, špatné LCP, problémy s indexováním.
Server-side rendering (SSR): Server vrátí hotový HTML s produktovými daty přímo v odpovědi. Prohlížeč vykreslí stránku ihned. JavaScript se přidá až potom pro interaktivitu.
Pro produktové stránky e-shopu je SSR téměř vždy správná volba. Data se mění relativně málo (sklad, cena), stránky jsou indexovány Googlem, a zákazníci je navštěvují poprvé — nemají nic v cache.
Praktický tip: Pokud používáte Next.js, používejte getStaticProps pro produktové stránky s revalidací každých 60–300 sekund (ISR). Pro produkty s velmi dynamickými cenami nebo zásobami použijte getServerSideProps. Vyvarujte se useEffect pro načítání základních produktových dat — to je klasická CSR chyba.
Optimalizace pokladny: kde zákazníci odcházejí
Průměrné opuštění košíku je 70 %. Část z toho je nevyhnutelná (lidé nakupní okna zavírají, srovnávají ceny). Ale velká část je způsobena špatnou pokladnou.
Faktory, které zákazníky odradí:
Povinná registrace je zabijákem konverzí. Studie Baymard Institute zjistila, že 26 % zákazníků opustí pokladnu, když jsou nuceni si vytvořit účet. Vždy nabídněte možnost nákupu jako host — registraci můžete nabídnout po dokončení objednávky.
Počet kroků pokladny: ideál jsou 2–3 kroky (košík → doprava a platba → potvrzení). Každý extra krok způsobuje odchody. Informace o dopravě a platbě, kontaktní údaje a fakturační adresa mohou být na jedné stránce.
Transparentnost nákladů: zákazníci nesnáší překvapení. Poštovné a poplatky ukažte co nejdřív — ideálně už v košíku. Pokud se zákazník dozví o poplatku za platbu kartou až v posledním kroku, pravděpodobně odejde.
Platební metody: V ČR jsou klíčové:
- Platební karty (Visa, Mastercard)
- Bankovní převod / platba QR kódem
- Dobírka (stále 15–25 % objednávek u řady segmentů)
- Apple Pay / Google Pay (rychle roste, zejména na mobilu)
- Odložená platba (Twisto, Splitpay) pro vyšší průměrné hodnoty objednávky
Příklad z praxe: Sportovní e-shop RunCzech přidal Apple Pay a Google Pay tlačítka. Na mobilních zařízeních vzrostla konverze v pokladně o 22 % — zákazníci nemuseli opisovat číslo karty na malé klávesnici.
Mobilní výkon: priorita číslo jedna
V průměru pochází 60–70 % návštěvnosti e-shopů z mobilních zařízení. Přesto je většina e-shopů optimalizována primárně pro desktop.
Mobilní testování musí probíhat na skutečných zařízeních, ne jen v Chrome DevTools simulaci. Telefon za 4 000 Kč s průměrným 4G připojením je realistický model vašeho zákazníka. PageSpeed test v "Mobile" režimu simuluje právě tyto podmínky.
Specifické mobilní problémy:
Tapové cíle příliš malé: tlačítka a odkazy musí mít minimálně 44×44 px plochu pro kliknutí. Malé "přidat do košíku" tlačítko znamená, že zákazník na něj musí mí přiklepnout a to otravuje.
Font loading: systemové fonty se načítají okamžitě, vlastní webfonty přidávají 50–300 ms latence. Omezte se na 1–2 vlastní fonty a použijte font-display: swap.
Zbytečné redirecty: přesměrování z http:// na https://, ze www. na bez www., z /mobil na hlavní doménu — každý redirect přidává 100–300 ms. Servery by měly odpovídat přímo bez redirectů.
Rychlé výhry vs. dlouhodobé opravy
Ne každá optimalizace stojí stejnou investici. Tady je přehled, co lze udělat rychle a co vyžaduje větší práci:
| Problém | Náročnost opravy | Potenciální dopad na výkon |
|---|---|---|
| Komprese a převod obrázků na WebP | Nízká (plugin nebo skript) | Vysoký |
| Přidání lazy loadingu na obrázky | Nízká (1 atribut) | Střední |
| Odstranění nepoužívaných tracking skriptů | Nízká (GTM audit) | Střední až vysoký |
| Přidání guest checkout | Nízká (konfigurace) | Vysoký (konverze) |
| Přidání Apple/Google Pay | Nízká (integrace platební brány) | Vysoký (mobile konverze) |
| Přechod na CDN pro statické soubory | Střední | Střední |
| Preload kritických fontů a obrázků | Střední | Střední |
| Přechod z CSR na SSR pro produktové stránky | Vysoká | Velmi vysoký |
| Přepsání šablony bez page builderu | Vysoká | Velmi vysoký |
| Optimalizace databázových dotazů | Vysoká | Velmi vysoký (u velkých katalogů) |
Začněte vždy s nízkou náročností a vysokým dopadem — to je kvadrant, kde dostanete nejlepší výsledky za nejméně peněz. Přepsání architektury má smysl až poté, co jste vyčerpali jednodušší možnosti.
Praktický tip: Nastavte si automatické měsíční sledování Core Web Vitals přes Google Search Console nebo nástroje jako Sentry Performance nebo Datadog. Výkon se časem degraduje — každý nový plugin, každý nový tracking skript přidává trochu váhy. Bez měření to nezjistíte, dokud problém není velký.
V BASAD Studios stavíme e-shopy s důrazem na výkon od první řádky kódu — žádné zbytečné page buildery, optimalizované obrázky, SSR tam, kde má smysl. Pokud máte pocit, že váš e-shop mohl by vydělávat víc, ozvěte se nám nebo se podívejte na naši službu e-shopy.