Web, který se načítá pět sekund, přijde o třetinu návštěvníků ještě před tím, než zobrazí první obsah. Google opakovaně měřil závislost mezi rychlostí načítání a mírou okamžitého opuštění: každá další sekunda přidává desítky procent k bounce rate. Amazon spočítal, že každých 100 milisekund zpoždění stojí firmu 1 % z prodejů. Rychlost webu není technický detail — je to přímý vliv na obrat.
Zvlášť to platí na mobilu, kde návštěvníci často přicházejí z pomalejšího připojení a jejich trpělivost je nižší než u počítače. Rychlost přitom není jen o prvním dojmu — ovlivňuje, jak daleko se návštěvník na webu dostane, jestli doscrolluje k nabídce a jestli vůbec dojde k formuláři. Pomalý web ztrácí zákazníky v každém kroku cesty, ne jen na začátku.
Jak rychlost ovlivňuje vaše čísla
Spojení rychlosti a konverzí je dobře zdokumentované. Web načítající se do dvou sekund má výrazně vyšší konverzi než web načítající se pět sekund, i když jsou jinak identické. Konkrétní čísla závisí na vašem odvětví a publiku, ale jako hrubý odhad: zkrácení načítání ze čtyř na dvě sekundy typicky zlepší konverzi o 15–25 %.
Přeložme si to do korun na příkladu firmy poskytující služby. Řekněme, že web má měsíčně 3 000 návštěv a konverzní poměr kontaktního formuláře 2 % — to je 60 poptávek měsíčně. Zrychlení z pěti na dvě sekundy zvedne konverzi o 20 %, tedy na zhruba 72 poptávek. To je 12 poptávek navíc každý měsíc bez jediné koruny za reklamu. Pokud z pěti poptávek vznikne jedna zakázka v hodnotě 25 000 Kč, znamená to zhruba 60 000 Kč obratu navíc měsíčně. Investice do optimalizace rychlosti ve výši 40 000–80 000 Kč se v takovém případě vrátí za pár týdnů.
SEO je druhý dopad. Google od roku 2021 používá Core Web Vitals (metriky rychlosti a stability načítání) jako přímý ranking faktor. Pomalý web ranky ztrácí nezávisle na kvalitě obsahu. Technicky pomalý web s jinak dobrým SEO nikdy nedosáhne potenciálu, který by mohl mít. A protože se pozice a rychlost ovlivňují navzájem — vyšší pozice přináší víc návštěvníků, rychlejší web z nich udělá víc zákazníků — je optimalizace rychlosti jednou z mála investic, která zabírá na obou stranách rovnice zároveň.
Core Web Vitals podrobně: LCP, CLS, INP
Core Web Vitals jsou tři metriky, kterými Google měří reálnou zkušenost uživatele. Nejde o abstraktní skóre, ale o to, co člověk u obrazovky skutečně zažívá: jak rychle uvidí obsah, jestli mu pod rukama neposkakuje layout a jak svižně web reaguje na kliknutí. Vyplatí se každou znát jménem, protože se řeší jinými zásahy.
LCP — Largest Contentful Paint
LCP měří, za jak dlouho se zobrazí největší prvek nad ohybem stránky — obvykle hlavní obrázek, nadpis nebo blok textu. Je to nejlepší ukazatel toho, „kdy uživatel cítí, že se stránka načetla". Cílová hodnota je pod 2,5 sekundy, pásmo 2,5–4 sekundy je „vyžaduje zlepšení" a nad 4 sekundy je špatně.
Nejčastější viníci pomalého LCP: pomalá odezva serveru, velké neoptimalizované obrázky, render-blocking CSS a JavaScript a příliš mnoho práce na straně prohlížeče u webů, které se vykreslují až v prohlížeči. Řešení míří přesně na tyto příčiny — rychlý hosting, statické generování stránek, komprese hlavního obrázku a jeho přednačtení (preload).
CLS — Cumulative Layout Shift
CLS měří vizuální stabilitu — jak moc obsah „poskakuje" během načítání. Znáte to: chcete kliknout na tlačítko, ale v tu chvíli se doloadne obrázek nad ním, obsah se posune a vy trefíte něco jiného. Cílová hodnota je pod 0,1, nad 0,25 je to špatně.
Typické příčiny: obrázky a videa bez uvedených rozměrů (prohlížeč pro ně nerezervuje místo), reklamy nebo vložené prvky, které se doloadnou dodatečně, a webové fonty, které při načtení překreslí text. Řešení je nenápadné, ale účinné — u každého obrázku uvádět šířku a výšku, rezervovat prostor pro dynamické prvky a fonty načítat tak, aby nezpůsobovaly přeskok. Špatný CLS nejenom frustruje, ale přímo snižuje konverze, protože lidé odesílají formuláře omylem nebo klikají mimo.
INP — Interaction to Next Paint
INP od března 2024 nahradil dřívější metriku FID a je přísnější. Měří, jak rychle web reaguje na interakce uživatele — kliknutí, ťuknutí, psaní — v průběhu celé návštěvy, ne jen u první akce. Cílová hodnota je pod 200 ms, pásmo 200–500 ms „vyžaduje zlepšení" a nad 500 ms je špatně.
Hlavní příčina špatného INP je těžký JavaScript, který zablokuje hlavní vlákno prohlížeče, takže web na chvíli „zamrzne" a nereaguje. Čím víc pluginů, widgetů a trackovacích skriptů web nese, tím hůř. Řešení: rozdělit JavaScript na menší části (code-splitting), odložit načítání nepodstatných skriptů a odstranit vše, co reálně nepoužíváte. Weby postavené na moderním frameworku jako Next.js s minimálním JavaScript bundlem mají INP obvykle v pořádku už z principu.
Jak vypadá zlepšení v praxi
Vezměme typický firemní web na WordPressu s těžkou šablonou. Vstupní měření na mobilu v PageSpeed Insights: LCP 4,8 sekundy (hlavní obrázek 2,3 MB), CLS 0,28 (reklamní banner a fonty posouvají obsah), INP 420 ms (šest pluginů a tři trackovací skripty blokují vlákno). Souhrnné skóre 38 — vše ve červeném pásmu.
Po zásazích: hlavní obrázek převeden do WebP a přednačten (LCP klesne na 2,1 s), obrázkům doplněny rozměry a fonty načteny přes font-display: swap (CLS spadne na 0,05), nepoužívané pluginy odstraněny a zbylé skripty odloženy (INP na 180 ms). Souhrnné skóre 92 — vše v zeleném. Žádná z těchto úprav neměnila obsah ani design, jen odstranila zátěž. Přesně tohle je typický rozdíl mezi webem, který návštěvníky ztrácí, a webem, který je udrží.
Jak rychlost měřit
Google PageSpeed Insights (pagespeed.web.dev) je základní nástroj — zdarma, přímo od Googlu, měří Core Web Vitals na reálných uživatelských datech i laboratorně. Cílové hodnoty: LCP pod 2,5 sekundy, CLS pod 0,1, INP pod 200 ms. Rozlišujte přitom dvě části reportu — laboratorní data (Lighthouse) simulují ideální podmínky, zatímco terénní data (Chrome UX Report) ukazují, co reálně zažívají vaši návštěvníci za posledních 28 dní. Rozhodující jsou terénní data.
GTmetrix a WebPageTest dávají detailnější pohled na waterfall načítání — vidíte přesně, co a jak dlouho trvá. Užitečné při hledání konkrétních problémů. Průběžný stav Core Web Vitals napříč celým webem sledujte v Google Search Console, v sekci Core Web Vitals — ta ukáže, které skupiny stránek jsou v pořádku a které vyžadují zásah.
Měřte vždy na mobilním připojení, ne jen na desktopu. Mobile First Index znamená, že Google hodnotí vaši mobilní verzi — a ta je vždy pomalejší kvůli síťovým podmínkám.
Kde čas načítání mizí
Obrázky jsou nejčastější příčina pomalých webů. Neoptimalizované PNG nebo JPEG v plném rozlišení mohou zabírat megabajty tam, kde stačí desítky kilobajtů. Řešení: konverze do formátu WebP nebo AVIF, správné rozměry pro každé zobrazení (responsivní obrázky), lazy loading pro obrázky mimo viewport a komprese bez viditelné ztráty kvality. Jedna fotka v plném rozlišení z foťáku může mít 4 MB — po správné optimalizaci klidně 80 kB, tedy padesátkrát méně.
JavaScript je druhý velký problém. Každý plugin, widget, tracking skript a third-party integrace přidávají JavaScript, který musí prohlížeč stáhnout, zparsovat a spustit. Unbundle velké knihovny, code-split na menší chunky, načítejte skripty asynchronně a odstraňte vše, co reálně nepoužíváte. Právě přebujelý JavaScript nejčastěji kazí metriku INP.
Hosting a server určují základní rychlost. Sdílený hosting za 200 Kč měsíčně nikdy nebude rychlý. Moderní weby patří na CDN (Cloudflare, Vercel, Netlify) nebo VPS s dobrým zázemím. Staticky generované stránky jsou řádově rychlejší než server-side renderování pro každý request. U českých projektů má navíc smysl řešit, aby obsah běžel z uzlu blízko návštěvníkům — CDN s evropskými servery zkrátí odezvu pro tuzemské publikum.
CSS může blokovat renderování. Nepoužívané CSS pravidla, velké frameworky načítané celé — to vše zdržuje. Critical CSS (styly nutné pro zobrazení nad-the-fold obsahu) může být inlinován přímo v HTML, zbytek načítán asynchronně.
Fonty jsou přehlížený zdroj zpoždění. Načítání fontů z Google Fonts přidává HTTP request a může způsobit FOUT (Flash of Unstyled Text), který zároveň zhoršuje CLS. Self-hosting fontů, preload direktivy a nastavení font-display: swap tento problém eliminují.
Prioritizace — co řešit první
Ne všechno má stejný dopad. Nejčastější pořadí podle efektu:
Obrázky — největší win pro nejmenší effort. Komprimujte a převeďte do WebP, přidejte lazy loading, doplňte rozměry (zlepší LCP i CLS zároveň). Dá se zvládnout za odpoledne.
JavaScript audit — projděte, co reálně načítáte. Odstraňte nepoužívané pluginy, odložte načítání third-party skriptů. Tohle je hlavní páka na INP.
Hosting — pokud běžíte na sdíleném hostingu a web je pro vás obchodně důležitý, přechod na lepší infrastrukturu je rozhodnutí, které se vrátí. Zlepší hlavně odezvu serveru, a tím LCP.
Cache a CDN — statické assety (obrázky, CSS, JS) by měly mít long-term cache headers a být servírované z CDN co nejblíže uživateli.
Nejčastější chyby při optimalizaci rychlosti
- Optimalizace jen pro desktop. Web má na počítači skóre 95, ale na mobilu 40 — a přitom většina návštěvníků chodí z telefonu. Vždy měřte a laďte mobilní verzi.
- Honba za číslem 100 v Lighthouse. Skóre v laboratoři je vodítko, ne cíl. Rozhodují reálná terénní data a to, jestli zákazník cítí web jako svižný. Poslední body do stovky často nestojí za vynaloženou práci.
- Ignorování CLS a INP. Firmy hlídají rychlost načtení (LCP), ale poskakující layout a zamrzávání při kliknutí přehlížejí. Přitom právě tyhle dvě metriky nejvíc kazí pocit z webu.
- Přidávání skriptů bez rozmyslu. Každý chat widget, heatmapa, A/B testovací nástroj a pixel navíc přidává zátěž. Přidejte jen to, co reálně používáte a vyhodnocujete.
- Jednorázová optimalizace. Web se jednou zrychlí a pak se rok přidávají fotky a skripty, až se vrátí tam, kde byl. Rychlost je disciplína, ne jednorázový úkol.
Jak udržet rychlost
Rychlost webu není jednorázová optimalizace — je to průběžná disciplína. Každý nový plugin, každý přidaný tracking skript, každý banner navíc přidává načítací čas. Pravidelné měření (měsíčně nebo po každém větším nasazení) a budget na performance (cílové hodnoty, které chcete udržet) jsou nutné pro to, aby se web nezpomaloval postupně a nepozorovaně.
Praktický návyk: před přidáním jakéhokoli nového nástroje na web si položte otázku, jestli přínos vyváží zpomalení, a po nasazení zkontrolujte Core Web Vitals v Search Console. Nastavte si jednoduchý performance budget — například „mobilní LCP nesmí přes 2,5 s a stránka nesmí vážit víc než 1 MB" — a držte se ho. Web, který zůstává rychlý roky, není náhoda, ale výsledek pravidla, že se rychlost hlídá stejně samozřejmě jako obsah.
Časté dotazy
Jaké skóre v PageSpeed Insights je dobré? Zaměřte se na Core Web Vitals v terénních datech: LCP pod 2,5 s, CLS pod 0,1 a INP pod 200 ms znamená „dobré". Souhrnné skóre Lighthouse je vodítko — nad 90 na mobilu je výborné, 50–90 je prostor ke zlepšení, pod 50 je problém. Důležitější než honit stovku je dostat všechny tři hlavní metriky do zeleného pásma.
Co je INP a proč nahradil FID? INP (Interaction to Next Paint) měří odezvu webu na všechny interakce v průběhu návštěvy, zatímco starší FID hodnotil jen tu první. INP je přísnější a lépe vystihuje reálný pocit z webu — jak svižně reaguje na klikání a psaní. Od března 2024 je jednou ze tří oficiálních Core Web Vitals metrik.
Kolik stojí zrychlení webu? Optimalizace existujícího webu se obvykle pohybuje v rozmezí 40 000–80 000 Kč podle rozsahu problémů. U webu, který přináší poptávky, se taková investice díky vyšší konverzi vrátí často za několik týdnů. Pokud je ale web pomalý z principu (zastaralá technologie, těžká šablona), bývá dlouhodobě levnější postavit ho znovu na rychlém základu.
Proč je web pomalý, i když mám dobrý hosting? Hosting je jen jedna část rovnice. I na rychlém serveru web zpomalí velké neoptimalizované obrázky, přebujelý JavaScript, desítky trackovacích skriptů a špatně načítané fonty. Nejčastějším viníkem bývají právě obrázky a cizí skripty, ne server sám.
Jak rychlost souvisí s pozicemi v Googlu? Google používá Core Web Vitals jako jeden z ranking faktorů, takže pomalý web se hůř umisťuje. Rychlost sama o sobě nevytáhne slabý obsah nahoru, ale u srovnatelných stránek rozhoduje — a navíc nepřímo pomáhá SEO tím, že lidé na rychlém webu zůstávají déle a méně se vracejí do vyhledávání.
V Appitect stavíme weby na Next.js s výkonem jako první prioritou — statické generování, optimalizace obrázků, minimální JavaScript bundle. Průměrný PageSpeed skór našich webů je přes 90. Pokud váš web ztrácí zákazníky kvůli rychlosti, ozvěte se.
