
„Vercel“ ar „Cloudflare Pages“: panašus greitis slepia skirtingas ribas

Statinei svetainei, kuri lankytojams pateikia iš anksto paruoštus failus, dažnai palankesnė „Cloudflare Pages“: augantis failų užklausų skaičius savaime nenaudoja funkcijų kvotos. Sudėtingai „Next.js“ programai, kuriai svarbus tiesioginis karkaso palaikymas arba daugiau atminties vienai funkcijai, dažnai paprasčiau rinktis „Vercel“. Talpykloje esančių puslapių atsako laikas šio skirtumo neatskleidžia.
Mažai Lietuvos komandai svarbu atskirti, kas vyksta kiekvieno apsilankymo metu. Statiniame projekte naršyklė parsisiunčia puslapį ir jo failus; dinaminėje programoje gali būti vykdomas serverio kodas, laukiama duomenų bazės ir atnaujinama talpykla. Šie veiksmai platformose turi skirtingas ribas ir skirtingai veikia augimo kainą.
Kiek apie greitį pasako TTFB bandymas
2026 m. rugpjūčio 29 d. „StackVerified“ bandyme iš vieno JAV namų interneto ryšio taško keturi vieši puslapiai buvo pasiekti po aštuonis kartus. Visų atsakymų talpyklos būsena buvo HIT: „vercel.com“, „nextjs.org“ ir „developers.cloudflare.com“ medianinis laikas iki pirmojo baito, arba TTFB, siekė atitinkamai 108, 110 ir 111 ms, o „pages.cloudflare.com“ – 205 ms. Leidinys nurodo, kad pats naudoja „Vercel“.
Matavimas rodo panašų trijų konkrečių talpykloje buvusių puslapių atsaką iš tos vietos. Tai nebuvo vienodo projekto diegimas abiejose platformose: skyrėsi patys puslapiai, o serverio kodas ir duomenų bazės užklausos atskirai nematuoti. Lankytojo Lietuvoje rezultatas taip pat gali skirtis nuo JAV matavimo. Todėl šie TTFB skaičiai padeda įvertinti bandymo ribas, bet neleidžia išrinkti greitesnės platformos dinaminei programai.
Talpyklos HIT ypač svarbu atskirti nuo užklausos, kuriai puslapį tenka sugeneruoti. Pirmuoju atveju atsakymą gali pateikti jau paruošta kopija; antruoju laukimo laiką papildys vykdomas kodas ir išorinės paslaugos. Projektui, kuriame dauguma lankytojų gauna statinius failus, šis skirtumas mažesnis negu projektui su individualizuotais puslapiais.
Statinė svetainė: užklausos ir perduodami duomenys
„Cloudflare Workers“ kainodaroje statinių išteklių užklausos nurodomos kaip nemokamos ir neribojamos, o „Pages Functions“ apskaitomos kaip „Workers“ užklausos. Nemokamame plane funkcijoms taikoma 100 000 užklausų per dieną ir 10 ms procesoriaus laiko vienam iškvietimui riba. Mokamas planas prasideda nuo 5 JAV dolerių per mėnesį ir apima 10 mln. užklausų bei 30 mln. procesoriaus milisekundžių per mėnesį; už duomenų perdavimą papildomas mokestis netaikomas.
„Vercel“ kainodaroje asmeniniam, nekomerciniam naudojimui skirtas „Hobby“ planas apima 1 mln. CDN užklausų ir 100 GB perduodamų duomenų per mėnesį. Komandoms skirtas „Pro“ kainuoja 20 JAV dolerių per mėnesį, apima 20 JAV dolerių naudojimo kreditą ir siūlo fiksuoto tarifo CDN. Taigi „Hobby“ kvotų nepakanka vertinant komercinės komandos pasirinkimą: jai aktualus mokamas planas ir kiti naudojami ištekliai.
Imkime sąlyginę statinę svetainę, kuri per mėnesį sulaukia 250 000 apsilankymų. Jei vienam apsilankymui tenka keturios HTTP užklausos ir perduodama vidutiniškai 0,2 MB duomenų, susidaro 1 mln. užklausų ir apie 50 GB srauto. Toks užklausų kiekis pasiektų nurodytą „Hobby“ CDN kvotą, nors duomenų kiekis liktų mažesnis už jos ribą. „Cloudflare Pages“ atveju tie patys statiniai failai funkcijų užklausų kvotos nenaudotų.
Šis palyginimas galioja tik tada, kai atsakymus galima pateikti kaip statinius išteklius. Jei kontaktų forma, prisijungimas ar individualizuotas maršrutas iškviečia funkciją, tą srautą reikia skaičiuoti atskirai. Net ir statiniame projekte puslapio peržiūrų skaičius nėra tapatus HTTP užklausų skaičiui: kiekvienas vaizdas, scenarijus ar šrifto failas gali pridėti užklausą.
„Next.js“: statinis eksportas ar serverio programa
„Cloudflare Pages“ „Next.js“ instrukcija statiniam eksportui nurodo „Pages“, o pilnai programai su serverio atvaizdavimu, „React Server Components“, „Server Actions“ ir maršrutų funkcijomis rekomenduoja „vinext“ aplinkoje „Workers“. Todėl pilną „Next.js“ programą lyginant su „Vercel“ reikia vertinti „Workers“ vykdymą ir suderinamumą, o ne vien statinių „Pages“ failų tiekimą.
„Vercel“ techniniame palyginime funkcijai nurodoma iki 4 GB konfigūruojamos atminties, o „Cloudflare Workers“ izoliatui – fiksuota 128 MB riba. Palyginimas nagrinėja „OpenNext“ adapterį: naudojant jį laipsniškam statinio turinio atnaujinimui ir atnaujinimui pagal žymas reikia papildomai sukonfigūruoti talpyklos paslaugas. „Cloudflare“ rekomenduojamas „vinext“ yra kitas diegimo kelias, todėl „OpenNext“ konfigūracijos reikalavimų negalima automatiškai priskirti jam.
Atminties skirtumas tampa lemiamas, jei vienas serverio maršrutas turi vienu metu laikyti didelį duomenų rinkinį, o ne jį apdoroti dalimis. Sąlyginiam maršrutui, kuriam vykdant kodą atmintyje būtini 200 MB duomenų, nurodytos „Workers“ izoliato ribos nepakaktų net esant mažam mėnesio srautui. Duomenų srautinis apdorojimas galėtų pakeisti tokios programos poreikį, todėl svarbu vertinti konkrečią funkciją, o ne vien įkeliamo failo dydį.
Mažesnei programai atmintis gali būti visai ne pagrindinis klausimas. Jei naudojami konkretūs „Node.js“ API, vaizdų optimizavimas ar turinio atnaujinimas pagal žymas, pasirinkimą lems ir jų veikimas pasirinktame „Cloudflare“ suderinamumo sluoksnyje. „Vercel“ pranašumas tokioje situacijoje yra tiesioginis „Next.js“ vykdymo kelias; „Cloudflare“ patrauklumas priklauso nuo to, ar programos funkcijos telpa į pasirinktą „Workers“ sprendimą.
Kai funkcija laukia išorinės paslaugos
Duomenų bazės ar API laukimo laikas nėra tas pats, kas aktyvus procesoriaus darbas. „Cloudflare Workers“ užklausai skaičiuoja procesoriaus laiką, o laukimo trukmė pati savaime jo nedidina. „Vercel Fluid Compute“ taip pat atskirai apskaito aktyvų procesorių, tačiau rezervuota funkcijos atmintis skaičiuojama tol, kol užklausos vykdomos. Dėl to dvi funkcijos, kurios procesorių naudoja vienodai, gali skirtingai paveikti atminties apskaitą, jei viena ilgai laukia atsakymo.
Sąlyginis pavyzdys: per mėnesį funkcija iškviečiama 200 000 kartų; kiekvienas iškvietimas trunka penkias sekundes, iš kurių penkias milisekundes aktyviai naudoja procesorių. Iš viso susidarytų 1 mln. procesoriaus milisekundžių, arba apie 0,28 valandos. Tolygiai paskirsčius užklausas per 30 dienų, jų būtų apie 6 667 per dieną, taigi vien užklausų kiekis nepasiektų nurodytos nemokamo „Workers“ plano dienos ribos. Staigus vienos dienos srauto šuolis ar didesnis procesoriaus poreikis vienam iškvietimui šią išvadą pakeistų.
Jei tam pačiam sąlyginiam darbui „Vercel“ funkcijos egzemplioriui būtų rezervuoti 2 GB atminties, o kiekviena užklausa būtų vykdoma atskirai, penkių sekundžių laukimas sudarytų apie 556 GB valandas rezervuotos atminties per mėnesį. Tai apskaitos iliustracija, o ne prognozuojama sąskaita: vienas egzempliorius gali aptarnauti kelias persidengiančias užklausas, todėl tikrasis atminties kiekis gali būti gerokai mažesnis. Šiame scenarijuje svarbiausias skirtumas yra laukiančioms užklausoms rezervuota atmintis, o ne vien jų procesoriaus laikas.
Renkantis platformą verta skaičiuoti kiekvieną apkrovos dalį pagal jos paskirtį: statinių failų tiekimą, serverio funkcijų iškvietimus, aktyvų procesorių, atmintyje laikomus duomenis ir perduodamą srautą. Statinei svetainei didėjantis lankytojų skaičius pirmiausia keičia failų tiekimo apimtį; „Next.js“ programai papildomai svarbu, ką turi atlikti kiekvienas dinaminis maršrutas. Būtent tas darbo pobūdis lemia, kurios ribos komandai bus svarbios.
Taip pat skaitykite:
Susiję straipsniai


„Turnstile“ ar „reCAPTCHA“: mažiau trinties dar nereiškia stipresnės apsaugos

OpenAI ar Claude talpykla: mažesnė kaina ne visada reiškia greitį

„GitHub Actions“ ar „GitLab CI“: pigesnę minutę nustelbia komandos planas

Make ar Zapier: pigi automatizacija priklauso nuo skaičiuojamo veiksmo

YouTube ar Spotify tinklalaidei: RSS importas dar nereiškia platinimo
Prenumeruokite mūsų naujienlaiškį
Gaukite naujausias Web3, DI ir kriptovaliutų naujienas tiesiai į savo el. pašto dėžutę.