Hosting, CDN a doručení obsahu

Vývojář nasadil svůj web na Vercel, bezplatný tarif, a šel spát. Boti ho našli. Za měsíc proteklo serverem 1,1 TB dat a přišel účet na 1 100 dolarů. Jiný případ: studentský projekt schytal DDoS, tisíce požadavků, účet 3 200 dolarů. Meta crawler udělal na jeden web 11 milionů požadavků za třicet dní a každý se počítal. Podstata není „Vercel je drahý". Podstata je, že Vercel neumožňuje tvrdý limit útraty, takže návštěvnostní špička, DDoS nebo chybná funkce ženou účet nahoru a nic ho automaticky nevypne.

To je první lekce o hostingu, a jde proti intuici. „Spravovaný hosting = bez starostí" platí jen napůl. Spravovaný hosting sundá z hlavy provozní zátěž — patchování, TLS, deploy. Nákladovou kontrolu ti nesundá. Hosting totiž není sklad, kam nahraješ soubory. Je to soubor provozních vlastností. Kdo platí za přenosy, kdo řeší rollback, kde leží origin, kdo čistí cache. Jednovětou definici má slovník. Tahle kapitola ty vlastnosti rozebírá.

Předchozí rozhodnutí už padlo jinde. Rendering určuje, co hosting musí umět. SSG: stačí statický hosting. SSR/ISR: potřebuješ serverový nebo edge runtime. Tahle kapitola na to navazuje. Neřeší, kdy zvolit který rendering, ale kam ho pak postavit.

Origin a edge nejsou tři krabice, je to vztah

Origin je centrální zdroj originálních dat. Tvůj hosting. Drží originální HTML, obrázky, skripty, případně databázi. Edge je první kontaktní bod u uživatele, síť serverů rozprostřená po světě, blíž k návštěvníkovi než tvůj origin. Edge drží cachované kopie. Když má edge kopii toho, co uživatel chce, vrátí ji rovnou a k originu vůbec necestuje.

To je celé kouzlo CDN. Místo jednoho serveru někde v Německu máš obsah ve stovkách měst. Cloudflare jich má přes 330 a peeruje ve všech velkých internetových uzlech. Návštěvník z Brazílie dostane stránku z brazilského edge uzlu, ne přes oceán.

Klasická CDN je ale jen distribuované úložiště. Cachuje statiku, nic víc. Edge computing je něco jiného. Spouští kód na edge uzlu. Kontrola cookie relace, směrování, personalizace. Aktivní prodloužení originu, ne jen jeho kopie. Tady se origin a edge potkávají: origin počítá to těžké, edge to lehké hned u uživatele.

A protože edge doručuje cache, dá se změřit, jak dobře to dělá. Cache hit ratio = zásahy / (zásahy + minutí). Web složený hlavně ze statiky se snadno dostane na 95–99 %. Přesnější metrika je ale origin offload, podíl bajtů doručených z cache, ne požadavků. Jeden velký obrázek z cache ušetří víc přenosu než sto malých požadavků a účtuje se ti za bajty, ne za požadavky. Cachování statiky srazí datový přenos o víc než 50 %, chytřejší CDN cachující i dynamické HTML jde na 60–80 % a výš.

CDN ti necachuje web. Cachuje soubory.

Tady žije nejodolnější mýtus: „mám Cloudflare, takže mám web rychlý." Ne tak rychle.

Cloudflare ve výchozím stavu necachuje HTML. Rozhoduje se podle přípony souboru — .jpg, .css, .js cachuje, HTML a JSON ne. Ve výchozím nastavení jsou prakticky necachovatelné. Aby se cachovalo i HTML, musíš nastavit Cache Rule.

Z toho plyne věc, kterou si lidi pletou. Statický web je rychlý ne proto, že nad ním CDN dělá magii. Je rychlý proto, že jeho HTML je statický soubor — a statické soubory CDN cachuje sama od sebe. SSG a edge cache si sednou přirozeně. Dynamické HTML potřebuje, abys cachování explicitně zapnul a hlídal. Konkrétní nastavení proxy, cache a TLS u jednoho poskytovatele řeší Cloudflare v praxi; tady jde o princip.

Cache invalidace je jeden ze dvou těžkých problémů

Phil Karlton to shrnul: „V informatice jsou jen dva těžké problémy. Invalidace cache a pojmenovávání věcí." Není to vtip pro vtip.

Kód na vyčištění cache je triviální, jedno volání API. Těžké je vědět kdy a mít jistotu, že se vyčistily všechny kopie na edge. Vydáš opravený článek, ale tři edge uzly pořád doručují starou verzi, protože jejich cache ještě nevypršela. Strategie na to existují: purge, refresh, ban, cache tags neboli surrogate keys, kterými označíš skupinu objektů a čistíš je dohromady. Ale „kdy cache vyčistit" zůstává rozhodnutí, ne automatika.

Proto vyčištění cache patří do plánu spuštění, ne až k řešení incidentu.

Osa, ne dvojice: čtyři typy hostingu

„Statický hosting vs. VPS" je stejně falešná dichotomie jako „statický vs. dynamický web". Reálně je to osa podle toho, kolik provozu na sebe bereš.

Statický spravovaný hosting. Cloudflare Pages, Netlify, Vercel, GitHub Pages. Nahraješ build, poskytovatel řeší CDN, TLS, deploy, preview i rollback. Žádný server k údržbě. Sedí na SSG obsahové weby. Tady je provozní zátěž nejnižší.

Serverless / functions. AWS Lambda, Vercel Functions, Netlify Functions. Kód běží na vyžádání a škáluje na nulu, takže neplatíš za nečinnost. Daň je cold start. Když funkce dlouho neběžela, musí se nastartovat. Node.js typicky 200–400 ms, Java s velkými závislostmi i přes dvě vteřiny. A k tomu účtování za každé spuštění, tedy riziko účtu při návštěvnostní špičce.

Edge runtime. Cloudflare Workers, Vercel Edge, Deno Deploy. Kód běží ve 330+ městech u uživatele. Workers běží jako V8 isolates, takže cold start je prakticky nulový, proti Lambdě řádový rozdíl. Za to platíš omezeným API runtime a dalšími limity. Výpočetně náročné nebo na ekosystém AWS vázané úlohy patří spíš na origin nebo Lambdu. Edge vyhrává na latenci a I/O, ne na všem.

VPS. DigitalOcean, Hetzner, Linode. Vlastní server, plná kontrola. A plná odpovědnost. U vlastního VPS dostaneš holý OS a řešíš firewall, bezpečnostní záplaty „v okamžiku, kdy vyjdou", monitoring. Jedna zapomenutá aktualizace vystaví celý server riziku. „Potřebuju VPS, abych měl kontrolu" zní dobře, ale pro obsahový web je kontrola nad OS spíš závazek než výhoda. Kontrola má cenu v provozní práci, kterou málokdo nacení dopředu.

TLS dnes řešit nemusíš

Jedna věc, která bývala bolest a přestala. TLS certifikáty jsou automatizované a zdarma. Let's Encrypt přes protokol ACME (klient Certbot, nebo vestavěné u Pages/Netlify/Vercel) vydává i obnovuje certifikáty bez zásahu. Certifikát platí 90 dní, obnova po 60. A životnost se zkracuje dál. Let's Encrypt jde na 45–64 dní, takže automatizace přestává být volba a stává se nutností. U statického spravovaného hostingu je TLS zapnuté hned po založení. Ručně cosi obnovovat dnes znamená, žes špatně zvolil hosting.

Jak vybrat hosting pro obsahový web

Místo „statický, nebo VPS?" si polož čtyři otázky.

• Kdo to bude spravovat? Netechnický tým bez kapacity na DevOps → spravovaná statika. Máš v týmu člověka na záplaty a monitoring → VPS přichází v úvahu.
• Jaké renderování web potřebuje? Čisté SSG → statický spravovaný hosting. SSR/ISR → potřebuješ serverový nebo edge runtime.
• Jaké je riziko špičky a nákladu? Hrozí viralita nebo crawler? Hlídej, jestli hosting umí limit útraty. Vercel ho neumí (viz úvod).
• Potřebuješ serverový výpočet? Ne → statika stačí. Trochu, blízko uživateli → edge runtime. Hodně, vázané na ekosystém → origin/serverless.

A pozor na bezplatné tarify. Hobby tarif Vercelu je nekomerční — komerční web na něm porušuje podmínky. Stropy jsou reálné: Vercel 100 GB přenosů měsíčně, Netlify 100 GB plus 300 build minut (komerce povolená), Cloudflare Pages neomezený datový přenos. „Bezplatný tarif stačí navždy" platí, dokud nepřijde viralita.

Tabulka fit / no-fit

Typ hostingu	Sedne na	Nesedne na	Provozní zátěž
Statický spravovaný	SSG obsahové weby, blog, dokumentace	nutný serverový runtime (SSR/ISR bez edge)	nejnižší
Serverless	občasné API, škálování na nulu	požadavky citlivé na latenci (cold start), riziko účtu při špičce	nízká, ale nákladově nejistá
Edge runtime	personalizace a routing u uživatele, nízká latence	výpočetně náročné nebo na AWS vázané úlohy	nízká
VPS	tým s kapacitou na DevOps, plná kontrola	netechnický tým, „nechci nic řešit"	nejvyšší (OS, záplaty, bezpečnost)

Tři typické záměny

• Spravovaný = bez starostí. Spravovaný hosting sundá provozní zátěž, ne nákladovou kontrolu. Bez limitu útraty je návštěvnostní špička nebo DDoS finanční riziko.
• CDN mi cachuje web. CDN ve výchozím stavu necachuje HTML. Statický web je rychlý proto, že jeho HTML je soubor, ne kvůli magii CDN nad dynamikou.
• Edge je vždycky lepší. Edge runtime má omezené API a limity. Vyhrává na latenci a I/O, ne na výpočtech. Těžké úlohy patří na origin.

Praktický checklist

• Je sepsaný seznam kritérií pro výběr hostingu (kdo spravuje, jaké renderování, riziko špičky, serverový výpočet).
• Je určeno, kde vzniká build, kde leží origin a kdo řeší vyčištění cache a TLS.
• Hosting umí limit útraty, nebo je riziko nákladu při špičce jinak ošetřené.
• Existuje rollback a ladicí logy pro případ incidentu.
• Je jasné, co se cachuje (HTML jen s explicitním pravidlem) a jak se cache čistí při publikaci.

Zdroje

• Imperva, Cloudways, ioRiver — origin vs. edge server, CDN vs. edge computing.
• Cloudflare — cache hit ratio, default cache behavior (necachuje HTML, rozhoduje podle přípony), síť 330 měst.
• Fastly — origin offload jako přesnější metrika efektivity CDN než CHR.
• Ddosify, Morphllm — cold start AWS Lambda (200–400 ms, Java 2 s+) vs. Cloudflare Workers (V8 isolates, ~nulový cold start).
• Let's Encrypt — ACME, certifikát 90 dní / obnova po 60, trend zkracování na 45–64 dní.
• ioRiver, Enterno — cache invalidace, Phil Karlton, purge/refresh/ban, cache tags.
• Liquid Web, Bluehost — spravované vs. nespravované VPS, odpovědnost za patche a bezpečnost.
• DeployBase, Medium — Vercel bill shock: 1,1 TB / 1 100 USD, DDoS / 3 200 USD, Meta crawler / 11 M requestů, chybějící spending cap.
• AI-Infra-Link, DevToolReviews — limity bezplatných tarifů 2025/2026 (Vercel 100 GB nekomerční, Netlify 100 GB, Cloudflare Pages neomezený datový přenos).

Hosting je místo, kam renderování staví svůj výstup a kam build a deploy pipeline doručuje artefakty. Na doménu ho navazuje DNS, konkrétní edge/cache/TLS nastavení řeší Cloudflare. Edge cache a image CDN doručují varianty z médií a podkladů, edge cache a komprese přímo zlepšují výkon a Core Web Vitals. Připravenost TLS, vyčištění cache a přepnutí DNS patří do plánu spuštění. Že každý podklad z cizí CDN posílá IP návštěvníka třetí straně, a proč vlastní hostování řeší i právní soulad, ne jen výkon, rozvádí právo, soukromí a souhlas. Pojmy sjednocuje slovník.