Proč se Vercel může u Next.js prodražit

Vercel cena často nevypadá problémově při prvním deployi, ale účet roste s provozem, architekturou i tím, jak používáte Next.js. Projdeme, kde náklady vznikají, jak je odhadnout před spuštěním a kdy je Vercel pořád nejlepší volba.

Kde u Vercelu vzniká účet mimo tarif

Vercel prodává jednoduchý vývojový zážitek: push do Gitu, preview deploy pro každou větev, automatické škálování a výbornou podporu pro Next.js. To je reálná hodnota. Problém nastává, když tým čte jen cenu tarifu a nepočítá s měřenými položkami provozu.

Náklady typicky nevzniknou jednou velkou položkou, ale kombinací: bandwidth, výpočet serverless funkcí, edge middleware, optimalizace obrázků, počet členů týmu, logy a preview prostředí. Aktuální položky je nutné ověřit v oficiálním ceníku Vercelu, protože limity se mění.

Traffic a edge cache: kdy škáluje i faktura

U marketingového webu s dobrým cachováním může být provoz dlouho levný. U aplikace s velkými obrázky, exporty, videi, PDF nebo veřejným API ale roste přenesený objem dat. Vercel umí škálovat bez zásahu administrátora, ale účet škáluje s ním.

Pozor na provoz, který nevypadá jako návštěvnost: boti, náhledy z chatů, crawler pro SEO, opakované stahování souborů nebo špatně nastavené cache hlavičky. Jestli vracíte stejná data pro tisíce uživatelů bez dlouhé cache, platíte za pohodlí, které šlo vyřešit návrhem vrstvy před aplikací.

Serverless funkce nejsou náhrada za každý backend

Serverless je skvělý pro krátké požadavky: formulář, autorizaci, lehkou agregaci dat, callback z platební brány. Horší je pro úlohy, které běží dlouho, pracují s velkými soubory nebo potřebují stabilní spojení. Tam se jednoduchý deploy může změnit v drahou obezličku.

Typický anti-pattern je import dat z ERP, generování rozsáhlých reportů nebo synchronizace produktů přímo v API routě. Lepší bývá fronta, worker mimo Vercel, databázová úloha nebo specializovaná služba. Vercel cena pak zůstane pod kontrolou a backend nebude narážet na limity běhu.

Next.js funkce, které umí účet nenápadně zvednout

Next.js nabízí komfortní nástroje, ale nejsou zadarmo. Image Optimization může šetřit výkon frontendu, zároveň ale vytváří měřenou práci na infrastruktuře. Podobně Middleware běží na každém odpovídajícím requestu, takže drobná logika se při velkém provozu násobí.

Doporučujeme rozlišovat, co musí běžet dynamicky a co může být statické. Produktový katalog, obsahové stránky a landing pages často patří do SSG nebo ISR. Uživatelský účet, košík a administrace dávají smysl dynamicky, ale i tam má být cache strategie vědomé rozhodnutí, ne default.

Nákladový model hostingu před spuštěním

Ještě před produkcí si napište jednoduchý model. Kolik čekáte návštěv měsíčně, kolik stránek na návštěvu, jak velké jsou assety, kolik požadavků jde na API a co dělá middleware. Nemusí to být finanční audit; stačí tabulka, která odhalí hlavní násobiče.

Do modelu přidejte tři scénáře: běžný měsíc, úspěšná kampaň a incident. Incident není jen výpadek. Může to být chybný crawler, nekonečný retry webhooku nebo špatně nastavený obrázek v newsletteru. Právě tyto situace vysvětlují, proč se Vercel cena někdy utrhne nečekaně.

V administraci sledujte usage metriky a nastavte interní limit, při kterém se tým zastaví a analyzuje provoz. Prakticky používáme hranice 50 %, 80 % a 100 % plánovaného měsíčního rozpočtu. Nejde o přesnost na korunu, ale o včasný signál před tím, než problém dorazí do fakturace.

Kdy zůstat na Vercelu a kdy jít jinam

Na Vercelu bychom zůstali u produktů, kde je důležitá rychlost vývoje, preview prostředí, globální doručení frontendu a malý provozní tým. Startup, nový SaaS modul nebo prezentační web s Next.js z toho často vytěží víc, než kolik zaplatí navíc proti ruční správě serveru.

Jiný hosting zvažte, pokud máte těžký backend, dlouhé joby, vysoký odchozí traffic nebo stabilní provoz, který lze levněji držet na vlastních instancích. Pro širší kontext jsme rozebrali i srovnání Vercelu a Renderu pro Next.js. U větších aplikací řešíme hosting už při návrhu vývoje webové aplikace, ne až po první faktuře.

Technická kontrola před produkčním deployem

Před spuštěním projděte každou route a označte ji jako statickou, cachovanou, dynamickou nebo výpočetně těžkou. Zkontrolujte cache hlavičky, velikost odpovědí, obrázky nad ohybem stránky a middleware matcher. Jeden špatný matcher umí poslat na edge logiku i requesty, které ji vůbec nepotřebují.

U API route měřte dobu běhu a počet volání už v testovacím provozu. Pokud endpoint čeká na externí systém, přidejte timeout, idempotenci a ochranu proti opakovaným pokusům. Detaily ke spotřebě a limitům je dobré průběžně kontrolovat v dokumentaci k účtování Vercelu.

Co si z výběru platformy odnést

Vercel není drahý automaticky. Drahý je tehdy, když na něm běží úlohy, pro které není ekonomicky vhodný, nebo když tým nezná provozní profil aplikace. Největší rozdíl dělá architektura: cache, statické stránky, oddělené workery a rozumné hranice pro serverless.

Pokud řešíte Vercel cenu včas, získáte rychlý deployment bez zbytečného rizika. Pokud ji řešíte až po růstu návštěvnosti, bývá migrace dražší než původní optimalizace. Hosting proto neberte jako položku na konci projektu, ale jako součást návrhu produktu.