Jak rychlost webu ovlivňuje konverze: kompletní průvodce 2026

Každá sekunda, o kterou se váš web načítá pomaleji, vás stojí konkrétní peníze. Amazon spočítal, že 100 ms zpoždění = 1 % méně tržeb. Google ukazuje data, že pokud načítání trvá 1–3 sekundy, pravděpodobnost bounce raste o 32 %. Při 5 sekundách: 90 %. Tento průvodce vám ukáže přesně, jak změřit rychlost svého webu, kde jsou nejčastější brzdy a jak je řešit — pro firmy, marketéry a začínající developery.

Pomalý web = ztracené peníze. Konkrétní čísla

Pro českou firmu s 10 000 návštěv měsíčně a konverzním poměrem 2 % (200 leadů) by zlepšení rychlosti o 1 vteřinu znamenalo zhruba o 16 leadů více měsíčně. Při hodnotě leadu 1000 Kč = 16 000 Kč/měsíc. Za rok 192 000 Kč. To je důvod, proč performance optimalizace patří k nejlepším investicím v digitálu.

Co jsou Core Web Vitals (LCP, INP, CLS)

V roce 2020 Google zavedl Core Web Vitals jako oficiální ranking faktor. V 2024 nahradil FID za INP. Aktuálně jsou tři klíčové metriky:

LCP — Largest Contentful Paint

Čas, za který se uživateli zobrazí největší prvek stránky (obvykle hero obrázek nebo nadpis). Cíl: pod 2,5 s. Nad 4 s už je problém.

INP — Interaction to Next Paint

Odezva na uživatelskou akci (kliknutí, tap). Měří se nejhorší interakce v session. Cíl: pod 200 ms. Nad 500 ms uživatel cítí, že web „lágne“.

CLS — Cumulative Layout Shift

Jak často se obsah náhle přeskupuje (obrázek se načte a posune text, atd.). Cíl: pod 0,1. Vyšší = otravné a vede k mis-clickům.

Jak změřit rychlost svého webu

Tři nejdůležitější nástroje, všechny zdarma:

1. PageSpeed Insights (pagespeed.web.dev) — Google nástroj. Zadáte URL, dostanete skóre 0–100 a konkrétní doporučení. Měří mobilní i desktopovou verzi. Nejlepší pro rychlou diagnózu.

2. Google Search Console → Core Web Vitals — ukáže reálná data od skutečných návštěvníků (Field Data) za posledních 28 dní. To je to, co Google používá pro hodnocení.

3. Chrome DevTools → Lighthouse — F12 v Chromu, tab Lighthouse. Detailní audit včetně Performance, Accessibility, SEO, Best Practices. Pro pokročilou analýzu nejlepší.

Pro pokročilé měření: WebPageTest.org (různé lokace, připojení, video průběhu), GTmetrix, nebo placené monitoring nástroje jako SpeedCurve a Calibre.

10 nejčastějších brzd rychlosti

1. Nezoptimalizované obrázky. JPEG/PNG ve formátu pro tisk, nahrané přímo z fotoaparátu. Hlavní příčina 80 % pomalých webů.
2. Velké JS bundly. Hlavně u WordPress webů s mnoha pluginy. Každý plugin = 50–200 KB extra.
3. Third-party skripty. Facebook Pixel, Hotjar, chatboty, A/B testing, GA, GTM — každý zpomalí.
4. Vlastní fonty bez optimalizace. Načítání 4–6 font-faces po 100 KB blokuje render.
5. Pomalý hosting. Sdílený hosting za 100 Kč/měsíc má TTFB 800–2000 ms.
6. Nepoužitý CSS a JS. Bootstrap full version, jQuery když ho nepoužíváte, atd.
7. Žádné cachování. Server přepočítává stejnou stránku pokaždé.
8. Render-blocking resources. CSS/JS, který blokuje první vykreslení.
9. Layout shift bez deklarovaných rozměrů. img bez width/height = CLS issue.
10. Žádný CDN. Návštěvníci z USA stahují z pražského serveru = 200+ ms zpoždění.

Optimalizace obrázků: největší výhra

Obrázky tvoří typicky 50–70 % objemu stránky. Optimalizace obrázků je proto nejúčinnější jeden krok pro zrychlení webu.

1. Použijte moderní formáty. WebP úspora 25–35 % proti JPEG při stejné kvalitě. AVIF úspora 50 %. Většina prohlížečů už AVIF podporuje.

2. Responzivní obrázky. srcset atribut nebo Next.js <Image> komponenta — uživatel s mobilem stáhne menší variantu.

3. Lazy loading. loading="lazy" atribut — obrázky pod fold se načítají až při skrolování.

4. Deklarujte rozměry. Vždy width a height. Zabrání layout shift.

5. Komprese před uploadem. Squoosh.app, TinyPNG — stáhnou velikost o 60–80 % bez viditelné ztráty kvality.

6. SVG pro ikony a loga. Vektor, malý, škálovatelný.

Optimalizace fontů

Vlastní fonty (Google Fonts, Adobe Fonts, vlastní soubory) jsou krásné, ale často zpomalují. Klíčové techniky:

1. font-display: swap. Zobrazí systémový font dokud se vlastní nestáhne. Render se neblokuje.

2. Preload kritických fontů. <link rel="preload" as="font" type="font/woff2"> urychlí jejich načtení.

3. Subset fontů. Načítejte jen znaky, které potřebujete (latin + latin-ext). Google Fonts subset uměje automaticky.

4. Omezte počet vah a stylů. 8 vah × 2 styly (regular + italic) = 16 souborů. Reálně potřebujete 2–3 váhy.

5. Hostujte si fonty lokálně. Google Fonts CDN je sice rychlý, ale extra DNS lookup. Pro maximum lokálně.

Optimalizace JavaScriptu

JS je dnes největší kategorie problémů. Řešení:

• Code splitting. Načítejte jen JS pro aktuální stránku, ne celou aplikaci.
• Tree shaking. Webpack/esbuild odstraní nepoužitý kód.
• Lazy load třetích stran. Hotjar, Facebook Pixel, chatboti — načítejte až po interakci uživatele, ne hned.
• Defer non-critical JS. defer atribut nebo async.
• Server-side rendering (SSR). Místo SPA použijte Next.js / Remix — uživatel vidí obsah hned.
• Odstraňte nepoužité pluginy. Pravidelně auditujte WordPress / Shopify pluginy.

CDN a hosting: kdy záleží

CDN (Content Delivery Network) ukládá kopie vašeho webu na servery po celém světě. Návštěvník z USA stahuje z amerického serveru, ne z pražského. Doporučené: Cloudflare (free tier zdarma), Vercel (vestavěné), Fastly.

Kdy potřebujete CDN? Pokud máte návštěvníky mimo ČR/EU, nebo když máte 5000+ návštěv měsíčně. Pro lokální firmu s českou klientelou nutné není.

Hosting rozhoduje o TTFB (Time To First Byte). Pro rychlý web hledejte hosting s SSD discs, HTTP/2, edge cache. Doporučení pro různé scénáře:

• Malý prezentační web: Vercel, Netlify (zdarma) + Next.js
• WordPress firemní web: Wedos Hosting, Forpsi, Stable.cz (české)
• Větší e-shop: Stable Cloud, AWS, DigitalOcean
• Headless / aplikace: Vercel, Railway, Render

Mobilní rychlost: nejčastěji ignorovaná

Mobilní web musí být rychlejší než desktopový, protože mobilní zařízení mají slabší CPU a často horší internet. Přesto 70 % firem optimalizuje jen desktop verzi.

Specifika mobilní optimalizace:

• Menší obrázky. Mobilní viewport potřebuje obrázky jen 360–768 px široké.
• Méně JS. CPU na mobilu je 4–6× pomalejší. JS, který v desktopu běží 100 ms, na mobilu 500 ms.
• Mobile-first CSS. Pište CSS od mobilu nahoru, ne naopak.
• Test na reálných zařízeních. ne emulátorech. Chrome DevTools Throttling = „Slow 4G“ simuluje realitu.
• Touch targets. Min 44×44 px pro tlačítka. Menší = mis-clicks a frustrace.

Case study: 3 sekundy → 1 sekunda = +47 % konverzí

Český e-shop s domácí kosmetikou. Po 6 týdnech performance optimalizace:

Často kladené dotazy

Jaké PageSpeed skóre je dost dobré?

Pro většinu firem cílíme na 85+ na mobilu a 95+ na desktopu. Pod 70 je problém — Google penalizuje a uživatelé odcházejí.

Stojí za to měnit WordPress za moderní stack jen kvůli rychlosti?

Záleží na rozsahu. Pokud máte WordPress s 5+ pluginy a PageSpeed pod 60, migrace na headless (WordPress + Next.js) nebo úplně jiný stack se vyplatí. Pro statický prezentační web ano. Pro funkce, které potřebují WP admin, zvažte WordPress Multisite + LiteSpeed cache.

Pomůže mi instalace „rychlostního pluginu“ ve WordPressu?

Trochu, ale ne zázračně. LiteSpeed Cache, WP Rocket, FlyingPress mohou zlepšit skóre o 10–20 bodů. Pro skutečný skok je potřeba audit a strukturální změny.

Zpomalí mě Google Analytics a Tag Manager?

Ano, ale méně, než si lidé myslí (10–30 ms při správné implementaci). GTM se serverside trackováním (sGTM) zpomalení eliminuje. Hotjar a Facebook Pixel jsou výrazně horší.

Co dál?

Pokud máte podezření, že váš web brzdí prodeje, podívejte se na naši SEO optimalizaci — rychlost je součást technického SEO. Nebo si přečtěte, proč se profesionální webdesign vyplatí. Konzultace je zdarma.