Cloudflare Pages, nebo GitHub Pages: rychlost je remíza, limity nikoli

V publikovaném testu GTmetrix měla stejná HTML šablona na Cloudflare Pages a GitHub Pages ve většině zkoušených lokalit podobné časy. Cloudflare vedl v Hongkongu o 1,1 sekundy, ale v San Antoniu autor opakovaně naměřil u Cloudflare přibližně 12 sekund. Jeden test šablony proto nedává spolehlivý důvod označit některou službu za obecně rychlejší.

Pro menší statický web jsou použitelné obě. Cloudflare Pages dává větší smysl, pokud chcete obsluhovat některé požadavky serverovým kódem nebo čekáte vysokou návštěvnost statických stránek. GitHub Pages vyhovuje dokumentaci či portfoliu publikovanému z repozitáře, pokud výsledný web a přenos dat zůstanou v jeho mezích. Rozhodnutí zpřesní jednoduchý výpočet: zvlášť posuďte počet sestavení, počet a velikost souborů a objem stažených dat.

Jaké hranice mají obě služby

Limity Cloudflare Pages uvádějí pro tarif Free 500 sestavení měsíčně na účet, jedno současně probíhající sestavení, nejvýše 20 000 souborů na web, maximálně 25 MiB na jednotlivý soubor a časový limit sestavení 20 minut. Měsíční kvóta se vztahuje k sestavením, nikoli k návštěvám. Strop počtu souborů se naopak týká výsledného webu: dokumentace může vytvořit mnoho malých stránek a narazit na něj, přestože celkem nezabírá mnoho místa.

Limity GitHub Pages stanoví maximální velikost publikovaného webu na 1 GB, měkký limit přenosu 100 GB měsíčně, měkký limit deseti sestavení za hodinu a časový limit nasazení 10 minut. Hodinový limit sestavení se nevztahuje na web sestavený a publikovaný vlastním postupem v GitHub Actions. Měkký limit ale není příslib další kapacity: při překročení kvót může GitHub přestat web obsluhovat nebo doporučit změnu způsobu publikování. Jeho pravidla navíc vylučují použití Pages jako bezplatného hostingu pro e-shop či web zaměřený především na obchodní transakce.

Hranice popisují různé věci, a proto z nich nevznikne jedno pořadí služeb. U Cloudflare může rozhodovat počet sestavení za celý měsíc nebo počet souborů na webu; u GitHubu velikost publikovaného výsledku, hodinový rytmus sestavování či měsíční přenos. Web s mnoha krátkými stránkami a malou návštěvností tak může řešit jiný problém než malé portfolio s velkými fotografiemi nebo často čtená dokumentace.

Kalkulačka pro časté publikování a velké soubory

Následující situace jsou podmíněné výpočty, nikoli naměřený provoz. Předpokládají, že každá změna vyvolá nové sestavení a že uvedené velikosti odpovídají skutečně publikovaným souborům. Díky tomu lze určit, která mez se ozve jako první, aniž by se počet návštěv zaměňoval za počet sestavení.

• Redakce publikuje 25 změn v každém z 22 pracovních dnů. To znamená 550 sestavení měsíčně, tedy o 50 více, než dovoluje Cloudflare Free. Na GitHub Pages by stejně rozložené změny nemusely překročit měkkou hodinovou mez. Pokud by však redakce spustila jedenáct sestavení během jedné hodiny, už by ji překročila. Vlastní postup v GitHub Actions tuto konkrétní mez nemá, jeho provoz se však řídí pravidly Actions.
• Podmíněná dokumentace obsahuje 21 000 výsledných souborů o průměrné velikosti 30 kB. Dohromady jde přibližně o 630 MB: na Cloudflare Free přesáhne počet souborů, zatímco celková velikost zůstane pod hranicí publikovaného webu na GitHub Pages. Při výběru podle pouhých megabajtů by tak rozhodující omezení zůstalo skryté.
• Jiné portfolio má málo souborů, ale jeden fotografický soubor o velikosti 30 MiB. Ten se nevejde do limitu jednotlivého souboru Cloudflare Pages, i kdyby zbytek webu zabíral zanedbatelné místo. Pro větší soubory Cloudflare uvádí možnost použít samostatné úložiště R2; tím se ovšem mění uspořádání webu, ne limit souboru v Pages.

U redakčního webu má smysl počítat také náhledová a produkční sestavení, pokud je pracovní postup vytváří. Malé úpravy textu mohou spotřebovat stejnou položku měsíční kvóty jako rozsáhlá změna designu. Naopak počet návštěv kvótu sestavení sám o sobě nezvyšuje. Právě oddělení publikačního rytmu od velikosti výsledku pomáhá předejít volbě podle nesprávné metriky.

Vysoký přenos není vysoký počet požadavků

Uvažujme podmíněný web, jehož úplné načtení přenese 2 MB. Padesát tisíc takových načtení představuje přibližně 100 GB dat, tedy úroveň měkkého měsíčního limitu GitHub Pages. Skutečný provoz se může lišit: prohlížeč může některé soubory použít z mezipaměti a návštěvník nemusí stáhnout všechny stránky nebo fotografie. Pro odhad přenosu je proto užitečnější objem skutečně stažených dat než velikost samotné úvodní stránky.

Pravidla Cloudflare pro Pages Functions uvádějí, že požadavky na statické soubory, které nespouštějí funkci, jsou zdarma a bez početního limitu. Požadavky na funkce se na tarifu Free započítávají do společné kvóty Workers Free ve výši 100 000 požadavků denně. Nejde o metriku přímo srovnatelnou s měsíčním objemem přenesených dat u GitHubu: jeden požadavek může přenést malý dokument i velký soubor.

Pro hojně čtenou statickou dokumentaci je proto podstatné, zda se požadavky obslouží přímo jako soubory, nebo spouštějí funkci. Přidání serverové logiky na vybrané cesty neznamená, že se do kvóty Workers počítá každé načtení statického webu. Současně nelze z neomezeného počtu statických požadavků vyvozovat neomezený přenos dat; jde o odlišné veličiny.

Kdy volbu rozhodnou serverové funkce

Návod GitHubu k vytvoření webu popisuje publikování statických souborů, možnost vlastního sestavení přes GitHub Actions a uvádí, že GitHub Pages při obsluze webu nepodporuje serverové jazyky jako PHP, Ruby nebo Python. Na bezplatném plánu GitHubu musí být zdrojový repozitář veřejný. Sestavit stránku před publikováním je přitom něco jiného než spustit kód v okamžiku, kdy návštěvník odešle formulář.

Cloudflare Pages může požadavek návštěvníka zpracovat pomocí Pages Functions. Pokud web potřebuje vlastní zpracování formuláře, ověření uživatele nebo odpověď závislou na aktuálních datech, jde o podstatný rozdíl: na samotném GitHub Pages by taková část vyžadovala další službu. Pokud naopak publikujete pouze předem připravené soubory, rozhodnou spíše konkrétní hranice, ke kterým se váš web nebo publikační rytmus přiblíží nejdřív.

Přečtěte si také:

• Webflow, nebo Framer: levnější web může narazit na limity CMS
• AI agent, nebo RPA: flexibilita prohrává tam, kde rozhoduje rychlost
• Reservio, nebo SimplyBook.me: stejné hodnocení skrývá jiné limity