30 tipů, jak vybrat hosting a CDN pro rychlý a stabilní web

01Jaký hosting vybrat podle skutečné práce webu

Kampaň přivede návštěvníky, ale košík čeká na databázi. Hosting nabízí neomezený prostor, jenže import produktů narazí na limit běhu skriptu. Podobným překvapením předejdete, když nejprve popíšete, co má web zvládnout, a teprve potom porovnáte nabídky.

Pro běžný firemní web začněte kvalitním spravovaným hostingem. Pro aplikaci vybírejte podle jejího běhového prostředí, databáze a provozní odpovědnosti. CDN přidejte tam, kde pomůže doručování a ochraně konkrétního obsahu. Značka ani počet procesorů samy o sobě neříkají, zda zákazník dokončí objednávku.

Hosting provozuje soubory a případně aplikaci. Origin je původní server, ze kterého CDN obsah získává. CDN rozmisťuje jeho vhodné kopie blíže návštěvníkům. DNS převádí doménové jméno na potřebné síťové údaje. Registrátor spravuje registraci domény. Tyto služby mohou mít různé dodavatele, proto musí být jasné, kdo ovládá kterou část.

Následující srovnání vychází z veřejné dokumentace ověřené 11. října 2026. Nejde o vlastní výkonnostní test ani pořadí vítězů. Odkazy vedou přímo na oficiální stránky bez partnerských identifikátorů. Doporučené využití a rozhodovací postup jsou redakční doporučení; před objednáním ověřte konkrétní tarif.

02Tipy 1 až 6: Projekt a odpovědnost

1. Sepište jeden skutečný provozní scénář

Místo zadání „rychlý hosting“ napište: návštěvník otevře katalog, vyfiltruje nabídku, přihlásí se a odešle objednávku. Přidejte práci administrátora a noční import. U každého kroku uveďte závislosti a dopad selhání. Tím odlišíte web, který hlavně předává hotové stránky, od aplikace, která při každém kliknutí počítá a zapisuje data. Stejný scénář potom použijte při porovnávání všech kandidátů.

2. Zvažte statický web dříve, než koupíte server

Pokud publikujete prezentaci, články a reference bez osobního účtu, můžete obsah připravit při sestavení webu a veřejnosti doručovat hotové soubory. Formulář nebo vyhledávání ovšem stále potřebují své řešení. Sepište, co se musí stát při publikaci nového článku a jak dlouho může trvat sestavení. Statický výstup je vhodná možnost pro jednoduchý provoz, nikoli automatická odpověď na každý obsahový projekt.

3. Rozhodněte, kdo bude spravovat systém

U spravovaného hostingu si nechte potvrdit rozsah služby: operační systém, databázi, aplikaci, pluginy i zásahy při incidentu. U vlastního VPS určete správce a zastupování. Hetzner u cloudových a dedikovaných serverů výslovně přenáší správu a zabezpečení serveru na zákazníka. Levný pronájem bez člověka pro aktualizace tak může mít pro firmu vyšší celkové náklady než dražší spravovaná služba.

4. Ověřte runtime a potřebná rozšíření

Dodejte poskytovateli seznam: PHP, Node.js, Python či jiné prostředí, jeho podporovanou verzi, databázi, potřebná rozšíření a způsob spuštění. React v prohlížeči sám neurčuje typ hostingu; serverové vykreslování už vlastní běh potřebovat může. Pro WordPress porovnejte nabídku s oficiálními požadavky a s požadavky vašich pluginů. Ověřte také termín povinného přechodu na novou verzi a možnost bezpečné zkoušky.

5. Umístěte aplikaci a databázi rozumně blízko

Nerozhodujte podle adresy fakturační společnosti. Zjistěte skutečný region aplikace, databáze a úložiště. Pro české a slovenské publikum porovnejte dostupné evropské regiony, pro další země měřte jejich reálné návštěvnické cesty. CDN může pomoci se soubory, ale každý dynamický požadavek na vzdálenou databázi tím nezmizí. Vyžádejte i umístění záloh, provozních logů a pravidla přístupu podpory.

6. Počítejte se špičkou, nejen měsíční návštěvností

Deset tisíc návštěv rozložených do měsíce představuje jinou zátěž než jejich příchod během kampaně. Popište souběžné přihlášení, vyhledávání, nákup a import. Přidejte očekávaný podíl návštěv bez cache. Požádejte o plán navýšení kapacity a podmínky zátěžové zkoušky. Testujte jen prostředí, pro které máte oprávnění, a předem stanovte hranici, při níž zkoušku ukončíte.

03Tipy 7 až 12: Výkon, limity a růst

7. Porovnávejte limity procesů, paměti a souborů

„Neomezený disk“ neznamená neomezený výkon. Zajímejte se o souběžné PHP procesy, paměť na proces, dobu běhu, připojení k databázi, počet souborů a limity přenosu. U VPS rozlišujte sdílené a vyhrazené CPU. Seznam skutečných limitů přiložte k nabídce. Nestačí, že se web vejde na disk, pokud se další návštěvníci musí řadit do fronty na volný proces.

8. Změřte odpověď serveru i hotovou stránku

TTFB podle web.dev zahrnuje také přesměrování, DNS a navázání spojení. Není to čistý čas práce aplikace ani samostatná metrika Core Web Vitals. Při pomalém webu porovnejte čas do prvního bajtu, načtení důležitého obsahu a odezvu ovládání. Uchovejte stejné URL, zařízení a podmínky testu. Samotný rychlý prázdný HTML dokument vám neřekne, kdy návštěvník skutečně uvidí nabídku. Diagnostiku rozvíjí náš průvodce rychlostí webu, Core Web Vitals a SEO.

9. Testujte studenou i zahřátou cache

První otevření a opakovaná návštěva nejsou totožný test. Změřte novou stránku po publikaci, běžnou navštěvovanou stránku i přihlášeného uživatele. Zaznamenejte, zda odpověď přišla z CDN nebo z originu. Nejlepší jednotlivý výsledek nepovažujte za typickou zkušenost. Doporučujeme opakování v různých časech a porovnání mediánu i pomalé části výsledků, například 95. percentilu, vždy se stejnou metodikou.

10. Prověřte databázi na reálných dotazech

Připravte anonymizovanou nebo syntetickou kopii s odpovídajícím množstvím produktů a vazeb. Otestujte vyhledávání, filtraci, zápis objednávky a administrativní export. Při čekání zjistěte, zda chybí index, roste počet spojení nebo se blokují zápisy. Změna značky hostingu sama neopraví nevhodný dotaz. U spravované databáze ověřte verze, rozšíření, limity připojení a postup obnovy.

11. Oddělte dlouhé úlohy od čekání návštěvníka

Import katalogu, generování PDF a odesílání velkého množství zpráv nemusí probíhat během otevřeného HTTP požadavku. Vyžádejte podporu front, plánovaných úloh a samostatných workerů podle architektury projektu. Ověřte nejdelší běh i chování při opakování neúspěšné úlohy. Limity Vercel Functions například určují maximální dobu běhu funkce; nelze předpokládat, že každý proces poběží libovolně dlouho.

12. Ptejte se, co znamená automatické škálování

Zapište minimální a maximální počet instancí, způsob spuštění další kapacity a omezení databáze. Zkontrolujte, kde aplikace uchovává relace a nahrané soubory, aby se při přepnutí na jinou instanci neztratily. Přidejte finanční výstrahu i rozhodnutí, co se stane při dosažení rozpočtu. Automatické navýšení kapacity pomáhá jen tam, kde na něj aplikace, data a provozní postupy opravdu navazují.

04Tipy 13 až 18: CDN a správná cache

13. Pojmenujte konkrétní úkol CDN

Vyberte, zda chcete rychlejší obrázky, statické soubory, veřejné HTML, ochranu před útoky, nebo kombinaci. Každá funkce potřebuje vlastní nastavení a ověření. Cloudflare ve výchozím nastavení neukládá do cache HTML ani JSON. Pouhé zapnutí proxy proto není důkazem, že se celý web doručuje z cache. Změřte konkrétní URL a hlavičky odpovědi ještě před vyhodnocením přínosu.

14. Nedovolte sdílení soukromého obsahu

Rozdělte stránky na veřejné, personalizované a citlivé. Účet, košík a soukromé dokumenty nesmějí omylem sdílet uloženou odpověď mezi lidmi. MDN vysvětluje rozdíl mezi private, no-cache a no-store. Ověřte také pravidla CDN, která mohou chování hlaviček změnit. Praktická zkouška musí zahrnout dva rozdílné účty, odhlášení a další otevření stejné adresy z čistého prohlížeče.

15. Určete, jak rychle se má změna projevit

Pro článek, cenu a sklad stanovte odlišnou toleranci zastaralosti. TTL popisuje čas platnosti cache; purge znamená její zneplatnění. Po publikaci opravy ověřte hlavní stránku, jazykové varianty a související výpisy. Verzované soubory pomohou s novým CSS a JavaScriptem, ale nevyřeší automaticky starou cenu v HTML. Popište také postup, když zneplatnění selže nebo se provede jen v části infrastruktury.

16. Zkontrolujte klíč cache a jazykové varianty

CDN musí rozlišit odpovědi, které se obsahově liší. Prověřte cestu, parametry, jazyk, měnu a případná pravidla pro cookies. Naopak marketingové parametry mohou zbytečně vytvářet mnoho kopií stejného veřejného obsahu. Klíč upravujte až po testu správnosti. Vyšší úspěšnost cache je užitečná jen tehdy, když českému čtenáři nepředá slovenský text a zákazníkovi nesprávnou variantu nabídky.

17. Ověřte HTTPS až k původnímu serveru

Šifrované spojení návštěvníka s CDN neověřuje samo o sobě spojení mezi CDN a originem. Nastavte kontrolu certifikátu i na této trase a sledujte jeho obnovu. Cloudflare Full (strict) je konkrétní režim pro takové ověření. Zároveň zvažte omezení přímého přístupu k originu podle možností infrastruktury. Ochranná vrstva ztrácí část účinku, když lze server snadno oslovit mimo ni.

18. Vyhodnoťte cache podle práce, kterou ušetří

Sledujte podíl požadavků obsloužených z cache, přenos dat, latenci a zatížení originu. Oddělte obrázky od API: vysoký celkový podíl může zakrýt pomalou databázi při nákupu. Níže uvedený model ukazuje pouze počty požadavků, nikoli slib rychlosti nebo ceny. Před objednáním CDN spočítejte, jaký obsah skutečně může být sdílen a jak často se mění. U interní aplikace může být přínos úplně jiný než u magazínu.

05Tipy 19 až 24: Dostupnost, obnova a podpora

19. Čtěte dostupnost společně s podmínkami SLA

Zeptejte se, co se počítá jako nedostupnost, odkud se měří, které výjimky platí a jak se uplatňuje kompenzace. V čistě matematickém modelu třicetidenního měsíce odpovídá 99,9 % času 43,2 minuty nedostupnosti a 99,99 % 4,32 minuty. Nejde o předpověď incidentů ani náhradu smluvní metodiky. Dostupnost infrastruktury navíc není totéž co úspěšné dokončení objednávky.

20. Stanovte, kolik dat a času můžete ztratit

RPO je cíl přijatelné ztráty dat vyjádřený časem, RTO cíl doby obnovy. Rozdíl popisuje také dokumentace AWS k obnově. Přeložte je do práce firmy: kolik nových objednávek dokážete znovu dohledat a jak dlouho smí být příjem zastaven. Potom ověřte, zda tomu odpovídá četnost záloh, rychlost obnovy a přístup lidí. Záloha jednou denně nemusí vyhovět provozu, ve kterém vznikají průběžně neobnovitelné změny.

21. Vyzkoušejte obnovu celého projektu

Nechte obnovit databázi, soubory a konfiguraci do odděleného prostředí. Změřte čas a projděte kontrolní objednávku nebo jinou klíčovou úlohu. CIS Control 11 zahrnuje i ověřování obnovy. Zjistěte, kdo smí zálohy smazat, jak dlouho existují a zda mají oddělenou kopii. Označení „automatické zálohy“ bez rozsahu, historie a vyzkoušené obnovy je pro výběr nedostatečné.

22. Oddělte produkci od zkoušení změn

Chtějte staging, tedy prostředí pro ověření nové verze. Musí mít řízený přístup a nesmí omylem odesílat skutečné objednávky či platby. Vyzkoušejte nasazení i návrat aplikace na předchozí verzi. U změny databáze si vyjasněte zvláštní postup, protože starší kód nemusí rozumět nové struktuře. Podpora jednoho kliknutí je pohodlná, ale přijetí změny stále potřebuje funkční kontrolu.

23. Zapněte monitoring obchodní funkce

Vedle dostupnosti hlavní stránky ověřujte přihlášení, vyhledávání a dokončení důležitého kroku bezpečným testem. Přidejte sledování chyb, expirace certifikátů, volného místa a selhání záloh. Výstrahu musí obdržet konkrétní člověk i jeho zástupce. Ověřte cestu upozornění simulací problému. Zelená stránka hostingu neznamená, že se zpráva z poptávkového formuláře dostala do vašeho systému.

24. Vyzkoušejte podporu konkrétním dotazem

Ještě před nákupem pošlete popis vašeho runtime, velikosti databáze a požadované obnovy. Posuzujte srozumitelnost odpovědi, rozsah pomoci a způsob předání složitějšího případu. Zjistěte dostupnost o víkendu, jazyk a rozdíl mezi přijetím hlášení a řešením. Nepřidělujte poskytovateli body za logo „24/7“ bez porozumění tomu, zda jde o monitoring, chat, nebo technický zásah.

06Tipy 25 až 30: Náklady, kontrola a bezpečný přesun

25. Spočítejte plnou cenu na dva roky

Sečtěte zavedení, obnovovací cenu tarifu, zálohy, CDN, databázi, přenos, úložiště, placenou podporu a práci správce. Ceny porovnávejte při stejném období, měně a režimu DPH. Samostatně napište cenu po skončení slevy a možné překročení limitů. Pokud nabídka uvádí měsíční částku při roční platbě, zapište i skutečnou částku splatnou předem. Nejlevnější úvodní měsíc není celkový provozní rozpočet.

26. Pohlídejte přenosy a proměnlivé účtování

U cloudu a CDN požadujte model běžného měsíce a kampaně. Zahrňte přenos ven, počet požadavků, funkce, transformace obrázků a ukládání logů podle konkrétního ceníku. Výstraha o útratě nemusí být tvrdý limit. Ověřte, zda služba při jeho dosažení zastaví provoz, nebo dál účtuje. Se správcem dohodněte, kdo smí zvýšit rozpočet a jak zjistí, že špičku nezpůsobuje chyba nebo bot.

27. Držte doménu a účty pod kontrolou firmy

Firemní vlastník má mít přístup k registrátorovi, DNS, fakturaci, hostingu a zálohám. Dodavateli udělte potřebnou roli pod jeho vlastním účtem. Zapněte vícefaktorové ověření a uložte obnovovací prostředky řízeně. Převod domény není nutnou součástí každého přesunu hostingu. Při úpravě DNS zachovejte poštovní záznamy, pokud e-mail zůstává na původní službě, a ověřte příjem i odesílání.

28. Vyžádejte umístění dat a podmínky odchodu

Sepište, kdo zpracovává provozní data, kde jsou uložena a jak se exportují. Vyžádejte smluvní podmínky, dokumentaci zpracování, seznam relevantních dodavatelů a dostupné regionální nastavení. Export vyzkoušejte včetně databáze a nahraných souborů. U proprietárních funkcí zjistěte, co budete při odchodu přepisovat. Technickou přenositelnost posuzujte samostatně od odpovědi, zda lze zrušit předplatné.

29. Připravte přesun a návrat před změnou DNS

Nový hosting nejprve ověřte na testovací adrese. Naplánujte konečný přenos dat, omezení souběžných zápisů, změnu DNS a kontrolu pošty. DNS TTL ovlivňuje uchování záznamů v cache, takže změna není jednotný okamžik pro všechny návštěvníky. Zachovejte funkční původní prostředí a určete, jak při návratu zachytíte objednávky vytvořené na novém serveru. Pouhé přepnutí adresy zpět nemusí zachránit nová data. Postup většího přesunu rozebírá návod na migraci do cloudu bez výpadku.

30. Vyberte vítěze podle zkoušky a důkazů

Vyřaďte nabídky, které nesplní povinné požadavky. Zbylé dvě nebo tři ověřte stejným projektem a tabulkou: funkce, rychlost, obnova, podpora, celkové náklady a odchod. Váhy stanovte podle firmy předem. E-shop může více vážit obnovu, magazín doručování obrázků. Archivujte nabídku, výsledky a odpovědné osoby. Rozhodnutí pak dokážete vysvětlit i znovu přezkoumat, až provoz vyroste.

07Konkrétní hostingy: Výhody, omezení a vhodné projekty

Tabulka nabízí kandidáty pro český, slovenský, britský, americký i mezinárodní provoz. Země zákazníka není totéž co region serveru. Výhody vycházejí z dokumentované nabídky, omezení a vhodnost z jejího posouzení pro daný typ projektu. Neuvádíme srovnávací rychlost ani cenový žebříček bez společného měření.

08Kterou CDN zařadit do porovnání

Pokud už má hosting CDN v ceně, nejdřív ověřte její funkce. Dvě vrstvy cache bez jasného důvodu komplikují hledání chyb a publikaci změn. Samostatnou službu přidejte s konkrétním cílem a odpovědností za nastavení.

09Modelový příklad: Kolik požadavků dojde na origin

Předpokládejme 100 000 požadavků na veřejný obsah a model, ve kterém každé netrefení cache vyvolá právě jeden požadavek na origin. Při 0% úspěšnosti cache jich dojde 100 000, při 70 % 30 000 a při 90 % 10 000. Výpočet je 100 000 × (1 − podíl obsloužený z cache).

Jde o ilustraci, nikoli naměřený výsledek některého poskytovatele. Model nezohledňuje revalidace, seskupování požadavků, různou velikost odpovědí ani cenu jejich zpracování. Z devadesátiprocentní úspěšnosti proto nevyplývá devadesátiprocentní zrychlení nebo úspora peněz. Pro rozhodnutí doplňte skutečné logy a fakturační pravidla.

10Výběrová tabulka, kterou můžete poslat dodavatelům

K tabulce přiložte seznam nepřekročitelných podmínek. Pokud potřebujete konkrétní databázové rozšíření nebo obnovu v určeném čase, další body nemají chybějící schopnost přebít. Nejasnou odpověď označte „neověřeno“ a vyžádejte doplnění, místo abyste ji automaticky považovali za splněnou.

11Časté otázky k hostingu, CDN a SEO

Potřebujete výběr převést do zadání pro vlastní web nebo aplikaci? Připravte současné parametry, provozní špičky, důležité zákaznické cesty a rozpočet. Nad těmito podklady lze navrhnout konkrétní infrastrukturu i zkoušku, která doloží, že volba vašemu projektu vyhovuje.