Autor a kontrola: Bc. Petr Kučera, MSc., MBA
Můžete mít ten nejkrásnější web od špičkového designéra, ale když ho pohání motor z traktoru, k zákazníkům včas nedojede. Rozhodli jsme se proto skoncovat s mýtem, že „na hostingu nezáleží“, a vyhlásili jsme bitvu o milisekundy: vzali jsme jeden web, udělali z něj dvě identická dvojčata a poslali je do souboje na dvou různých serverech.
Aby souboj dával smysl, byl web na obou stranách stejný. Lišil se jen hosting, tedy server a jeho object cache.
test proběhl 19. 03. 2026 v PageSpeed Insights, každou variantu jsme změřili nejméně pětkrát a uvádíme medián. Laboratorní test PageSpeed Insights běží v datacentru Googlu v Severní Americe, Evropě nebo Asii, odezvu serveru tedy měří odtamtud, ne ze zařízení návštěvníka. Data skutečných uživatelů pro testovací adresy PageSpeed Insights neukázal („Žádná data“), výsledek je proto čistě laboratorní.
Testovaný WordPress web dnes už neběží, ppcone.cz mezitím přešel na jinou technologii. Čísla níže tedy popisují tehdejší web, ne dnešní ppcone.cz.
Na desktopu vypadaly obě varianty podobně. Jenže dnešní internet se odehrává hlavně na mobilech a tam se z vyrovnaného souboje stal jednoznačný výsledek. Všechna čísla v tabulce jsou mediány z PageSpeed Insights z 19. 03. 2026.
| Metrika | Sdílený hosting | Vlastní server | Rozdíl |
|---|---|---|---|
| Výkon na mobilu | 62 bodů | 95 bodů | 33 bodů |
| Výkon na desktopu | 96 bodů | 98 bodů | 2 body |
| Čas do prvního bajtu (TTFB) | zhruba 940 ms | méně než 50 ms | zhruba 890 ms a víc |
| Vykreslení hlavního obsahu na mobilu (LCP) | 5,7 s | 1,2 s | 4,5 s |
Na desktopu měl i sdílený hosting 96 bodů. Kdo se dívá jen na desktop, snadno usoudí, že je hotovo. Mobil ukázal opak: rozdíl 33 bodů a hlavní obsah o 4,5 s později.
Neviditelný zloděj času se jmenuje TTFB (Time to First Byte, čas do prvního bajtu). Měří čas od začátku navigace do prvního bajtu odpovědi a zahrnuje i přesměrování, DNS, navázání spojení a TLS, nejen práci serveru.
Proč na něm tolik záleží: dokud nepřijde první bajt odpovědi, prohlížeč nemůže začít stahovat obrázky, styly ani skripty, na které stránka odkazuje. Vysoké TTFB proto přidává čas všem metrikám, které po něm následují. LCP (Largest Contentful Paint, vykreslení největšího prvku obsahu) se skládá z TTFB, zpoždění a trvání načtení hlavního prvku a zpoždění vykreslení.
web.dev doporučuje jako hrubé vodítko TTFB 0,8 s nebo méně, nad 1,8 s je hodnota špatná. TTFB přitom není Core Web Vital. Zhruba 940 ms na sdíleném hostingu je nad vodítkem 0,8 s a pod hranicí 1,8 s, tedy v pásmu „potřebuje zlepšit“. Vlastní server odpověděl za méně než 50 ms, tedy zhruba devatenáctkrát a víc rychleji.
rozdíl TTFB je zhruba 890 ms a víc, rozdíl LCP na mobilu 4,5 s. Odezva serveru tedy vysvětluje jen část rozdílu, zbytek připadá na další fáze načtení hlavního prvku a jeho vykreslení. Celých 4,5 s proto hostingu nepřipisujeme.
Na sdíleném hostingu se o výkon serveru dělí víc webů a web.dev ho mezi příčinami pomalé odezvy uvádí výslovně: sdílený hosting bývá obecně pomalejší. Kolik pomůže výkonnější procesor, rychlejší disk nebo object cache, záleží podle nás na tom, co je u konkrétního webu úzké hrdlo.
Náš výsledek proto neznamená, že každý vlastní server porazí každý sdílený hosting. Znamená, že u tohoto webu hrál hosting velkou roli.
Bonus, který v tabulce nenajdete: na vlastním serveru byla výrazně rychlejší i administrace WordPressu. Práce v ní přestala být za trest.
Častá představa zní: „Mám Cloudflare, rychlost řešit nemusím.“ Jenže Cloudflare ve výchozím nastavení HTML necachuje; cachovat ho může až s odpovídajícím nastavením pravidel cache nebo se službou APO. V našem testu běžely oba weby za stejným Cloudflare s vypnutou cache stránek a rozdíl mezi hostingy stejně zůstal.
Redis object cache ve WordPressu ukládá data aplikace mezi požadavky, není to hotová kopie celé stránky. Stránku pořád skládá WordPress, object cache mu jen drží připravená data. Je to jedna z pák, ne kouzlo, které z pomalého webu udělá rychlý.
Core Web Vitals jsou tři metriky zážitku z webu. Google je hodnotí na 75. percentilu návštěv, tedy z dat skutečných uživatelů, ne z jednoho testu.
| Metrika | Co znamená zkratka | Dobré podle Googlu |
|---|---|---|
| LCP | Largest Contentful Paint, vykreslení největšího prvku obsahu | do 2,5 s |
| INP | Interaction to Next Paint, odezva na interakci | do 200 ms |
| CLS | Cumulative Layout Shift, posun rozvržení stránky | do 0,1 |
| TTFB (není Core Web Vital) | Time to First Byte, čas do prvního bajtu | vodítko web.dev do 0,8 s |
INP nahradil FID 12. 03. 2024. U LCP Google rozlišuje i další pásma: nad 2,5 s až do 4 s potřebuje zlepšit, nad 4 s je špatné. Naše laboratorní LCP 5,7 s na sdíleném hostingu by tedy bylo nad hranicí 4 s (špatné), 1,2 s na vlastním serveru pod hranicí 2,5 s (dobré).
Co to znamená pro SEO:
Rychlost je jeden ze signálů, obsah zůstává základem. Jak se obsah propisuje do viditelnosti v AI odpovědích, jsme rozebrali zvlášť.
Oblíbené pravidlo zní: „každá sekunda navíc snižuje konverze o 7 %“. Podívali jsme se, odkud pochází: z průzkumu Aberdeen Group mezi více než 160 organizacemi z listopadu 2008. Je to tedy historické číslo z jednoho průzkumu, ne pravidlo pro rok 2026. Totéž platí pro další často citovaná čísla, proto je uvádíme i s rokem, autorem a typem studie.
sekunda zpoždění znamenala o 7 % méně konverzí
zpoždění o 100 ms bylo spojeno s nižšími konverzemi: na mobilu o 7,1 %, na desktopu o 2,4 %
bounce rate 14,1 % při načtení za 0,7 s, téměř 29 % při 2,7 s
53 % návštěv mobilního webu odejde, když se stránka načítá déle než 3 s
prodloužení načtení z 1 na 7 sekund zvýší pravděpodobnost odchodu o 113 %
zlepšení každé ze čtyř sledovaných metrik rychlosti o 0,1 sekundy souviselo v retailu s konverzemi vyššími o 8,4 %, v cestovním ruchu o 10,1 %
LCP vstupní stránky lepší o 31 %, prodeje vyšší o 8 %
B2B web načtený za 1 s měl třikrát vyšší konverzní poměr než web načtený za 5 s
podíl obchodů s dobrým LCP z 57 % na 96 %, se splněnými Core Web Vitals z 48 % na 72 %; mobilní konverzní poměr z organického vyhledávání vyšší o 8,9 %
tržba na návštěvníka vyšší o 53,37 %, konverzní poměr o 33,13 %
experimenty v Amazonu podle nich ukázaly pokles tržeb o 1 % při zpoždění o 100 ms
Jak tato čísla číst:
Shodují se ale ve směru: rychlejší načtení, hlavně na mobilu, v nich jde ruku v ruce s lepšími výsledky.
Pokud platíte reklamu v Google Ads, Skliku nebo na Metě, rychlost webu se vás týká i mimo SEO. V Google Ads se klik započítá, i když se člověk na web vůbec nedostane. Pomalý mobil s LCP 5,7 s, jako měla naše varianta na sdíleném hostingu, tak znamená placené kliky, které na vaši nabídku nemusí vůbec dohlédnout. Jak do sebe zapadá cílení, aukce a vstupní stránka, popisujeme v článku jak fungují PPC kampaně.
Rychlost je jedna ze složek dojmu ze vstupní stránky, ne vzorec pro cenu.
Ve Skliku je sloupec Kvalita jen informativní a pozici reklamy přímo neovlivňuje. O umístění rozhoduje hlavně maximální cena za proklik a koeficient kvality, rychlost vstupní stránky nápověda neuvádí. Přímou vazbu rychlosti na cenu kliku tedy nápověda Skliku nepopisuje. Placený klik ale přijde vniveč stejně, když návštěvník odejde dřív, než stránku uvidí. Víc o specifikách Seznamu najdete v článku reklama v Seznamu.
U Mety jde hlavně o měření. Meta doporučuje vložit kód pixelu do hlavičky stránky, protože se spustí dřív a zvýší šanci zaznamenat návštěvníka, než stránku opustí. Na pomalém webu tak část návštěv může v datech chybět. Proč doplnit měření i o serverové měření, jsme popsali samostatně.
80 recenzí klientůcf-cache-status: hodnota HIT znamená, že stránka přišla z cache Cloudflare, MISS a DYNAMIC, že ji musel poslat váš server. Bez pravidel cache nebo APO Cloudflare HTML ve výchozím nastavení necachuje.Z naší zkušenosti s tímto testem bychom se při výběru hostingu ptali na čtyři věci. Nejde o zákon, ale o to, čím se náš rychlejší server lišil:
než hosting vyměníte, změřte, kde je úzké hrdlo. Pokud jde o server, může pomoct výkonnější hosting. Pokud jde o web samotný, je na řadě úprava webu. S webem samotným vám pomůžeme v rámci tvorby webů a dalších služeb.
Ano, hlavně přes odezvu serveru. V našem testu měl stejný web na sdíleném hostingu TTFB zhruba 940 ms, na vlastním serveru méně než 50 ms; v laboratorním testu (medián z nejméně pěti běhů) měl mobilní skóre 62 proti 95 bodům a LCP 5,7 proti 1,2 s, přičemž odezva serveru vysvětluje jen část rozdílu LCP. Na sdíleném hostingu se o výkon serveru dělí víc webů. TTFB ale zahrnuje i přesměrování, DNS, navázání spojení a TLS, takže ne každé pomalé TTFB je vina hostingu.
web.dev doporučuje jako hrubé vodítko 0,8 s nebo méně, nad 1,8 s je hodnota špatná. TTFB není Core Web Vital, ale přidává čas všem metrikám, které po něm následují.
Google uvádí, že Core Web Vitals používají jeho systémy hodnocení. Dobré hodnoty ale nezaručují vysoké pozice, dobrý zážitek nepřebije kvalitní obsah a snaha o perfektní skóre jen kvůli SEO podle Googlu nemusí být dobře využitý čas.
Lighthouse testuje mobil a desktop za odlišných podmínek a s odlišným bodováním, skóre obou režimů se proto přímo nesrovnává. V našem testu měl sdílený hosting na desktopu 96 bodů, na mobilu jen 62; vlastní server 98 a 95.
V Google Ads nepřímo, a to jako možnost, ne pravidlo. Skóre kvality v Google Ads je diagnostický ukazatel a jednou z jeho složek je dojem ze vstupní stránky, se kterým Google počítá i v aukci; kvalitnější reklamy mohou často vést k nižší ceně za proklik. Zrychlení načítání Google uvádí mezi doporučeními ke zlepšení dojmu ze vstupní stránky. Pevný převod rychlosti na cenu kliku nezveřejňuje.
Nápověda Skliku ji neuvádí. Sloupec Kvalita je jen informativní a pozici reklamy přímo neovlivňuje; o umístění rozhoduje hlavně maximální cena za proklik a koeficient kvality.
Náš test ukázal, že i dobře optimalizovaný web může narazit na strop, když ho brzdí server. Stejný kód, stejné obrázky, stejný Cloudflare, a přesto na mobilu 62 proti 95 bodům a hlavní obsah o 4,5 s později. Na desktopu přitom vypadalo všechno v pořádku.
Pokud to se svým online byznysem a placenou reklamou myslíte vážně, nehodnoťte web podle desktopového skóre. Změřte mobil, TTFB a LCP a zjistěte, kde se načítání zdržuje.
Rádi pro vás uděláme podobnou analýzu a ukážeme, kde se načítání zdržuje a co to může znamenat pro vaši reklamu i SEO.
O autorovi
Bc. Petr Kučera, MSc., MBA
AI Systems & Marketing Strategist, zakladatel PPC ONE
Petr objevil kouzlo výkonnostních kampaní již v roce 2011 a od té doby je neodmyslitelnou součástí jeho profesionálního života. Jeho jedinečná síla spočívá ve zkušenostech získaných ve spolupráci s více než stovkou firem.
Údaje ověřeny k 02. 10. 2026.