Vercel თუ Cloudflare Pages: სიჩქარის ფრეს ხშირად ბილინგი წყვეტს

სტატიკური საიტისთვის Cloudflare Pages ძლიერი არჩევანია, როცა ვიზიტორთა რაოდენობა შეიძლება მოულოდნელად გაიზარდოს: სტატიკური ფაილების მიწოდება მოთხოვნების რაოდენობისა და გადაცემული მონაცემების მიხედვით არ ფასდება. დინამიკური Next.js პროექტისთვის Vercel-სა და Cloudflare-ს შორის არჩევანი უფრო რთულია. CDN-ის დარიცხვასთან ერთად მნიშვნელოვანია, სად შესრულდება სერვერული კოდი და რამდენი სამუშაო დასჭირდება მის გადატანას.

სიჩქარის ერთი გაზომვა ამ არჩევანს ვერ ასრულებს. StackVerified-ის ერთწერტილიან ტესტში vercel.com-ის, nextjs.org-ისა და developers.cloudflare.com-ის ქეშირებული პასუხების მედიანური TTFB შესაბამისად 108, 110 და 111 მილიწამი იყო, ხოლო უფრო მძიმე pages.cloudflare.com-ის — 205 მილიწამი. თითო გვერდზე რვა თანმიმდევრული მოთხოვნა აშშ-ის ერთი საცხოვრებელი კავშირიდან გაიგზავნა. ეს ოთხი განსხვავებული საჯარო გვერდის შედეგია და არა საქართველოში განთავსებული ერთნაირი პროექტების შეჯიბრი.

რას ზომავს TTFB და სად მთავრდება მისი ძალა

TTFB აჩვენებს დროს მოთხოვნის გაგზავნიდან პასუხის პირველი ბაიტის მიღებამდე. ახლოს მდგომი მედიანები მხოლოდ იმაზე მიუთითებს, რომ ამ ტესტში სამი კონკრეტული ქეშირებული გვერდის პირველი პასუხი მსგავსი სისწრაფით მოვიდა. გვერდის სრულად გამოჩენა სხვა რამეზეცაა დამოკიდებული: HTML-ის შემდეგ შეიძლება ჩაიტვირთოს სურათები, სკრიპტები და შრიფტები, ხოლო დინამიკურ მარშრუტს პასუხის მომზადებამდე გამოთვლა ან მონაცემთა ბაზასთან კავშირი დასჭირდეს.

საქართველოსა და ევროპის აუდიტორიისთვის ტესტის ადგილიც მნიშვნელოვანია. აშშ-იდან მიღებული TTFB თბილისის, ქუთაისის ან ბერლინის ვიზიტორის დაყოვნებას არ უდრის: ქსელის მარშრუტი, ქეშის მდგომარეობა და მოთხოვნილი გვერდი იცვლება. თანაც შედარებულ გვერდებს ერთნაირი შიგთავსი არ ჰქონდათ; უფრო მაღალი შედეგი ავტომატურად Cloudflare Pages-ის პლატფორმის სისუსტეს ვერ მიეწერება. თუ პროექტისთვის რამდენიმე მილიწამი მართლაც გადამწყვეტია, აზრი აქვს ორივე სერვისზე ერთი და იმავე გვერდების გაზომვას იმ რეგიონებიდან, საიდანაც რეალური ვიზიტორები შემოდიან.

რისთვის იხდის საიტი და რისთვის — ფუნქცია

Vercel-ის მოხმარებაზე დაფუძნებულ CDN-ვარიანტში გადაცემული მონაცემები და CDN-მოთხოვნები ცალკე აღირიცხება. Vercel-ის ფასების ცხრილში ნაჩვენებია $0.15 თითო გიგაბაიტ Fast Data Transfer-ზე და $2 მილიონ CDN-მოთხოვნაზე; Pro-ზე დამატებითი ფასიანი გუნდის ადგილი თვეში $20 ღირს. Pro-ს ყოველთვიური მოხმარების კრედიტიც აქვს, ხოლო CDN-ისთვის ფიქსირებული მოცულობის ტარიფის არჩევაც შეიძლება. ამიტომ ერთეულების გამრავლება ჯერ კიდევ არ არის გადასახდელი ინვოისი: საბოლოო თანხას არჩეული ვარიანტი, კრედიტი, სხვა რესურსები და რეგიონული ტარიფი ცვლის.

Cloudflare Pages-ზე ჩვეულებრივი სტატიკური ფაილის მოთხოვნა უფასოა, მაგრამ Pages Functions-ის გამოძახება Workers-ის მოხმარებად ითვლება. Cloudflare Workers-ის ტარიფში უფასო გეგმის ზღვარი დღეში 100 000 მოთხოვნაა; ფასიანი გეგმა ანგარიშზე თვეში მინიმუმ $5 ღირს და მოიცავს 10 მილიონ მოთხოვნასა და 30 მილიონ მილიწამ CPU-ის დროს. ზედმეტი მოთხოვნები და CPU-ის დრო ცალ-ცალკე ფასდება, მონაცემების გატანაზე კი დამატებითი საფასური არ არის. თუ ფუნქცია სტატიკური მისამართის მოთხოვნასაც ამუშავებს, უფასო ფაილის მიწოდების ნაცვლად დინამიკური გამოძახება აღირიცხება; ამიტომ მარშრუტების მოწყობა ფასის ნაწილია.

ეს სხვაობა განსაკუთრებით შესამჩნევია საინფორმაციო ან კამპანიის საიტზე, სადაც ერთი გამოქვეყნებული გვერდი ბევრმა ადამიანმა შეიძლება ერთდროულად გახსნას. წმინდა სტატიკური მიწოდებისას Cloudflare-ის ხარჯი მხოლოდ ასეთი ნახვების გამო არ იმატებს. Vercel-ზე მოხმარებაზე დაფუძნებული ტარიფის შემთხვევაში მონაცემთა მოცულობა და მოთხოვნები იზრდება, თუმცა ფიქსირებული CDN-ვარიანტი ამ ზრდის ფინანსურ შედეგს სხვაგვარად განსაზღვრავს. თუ გვერდი ყოველ გახსნაზე პერსონალიზებულ პასუხს ამზადებს, სტატიკური საიტის შედარება უკვე არასრულია.

დაბალი, საშუალო და ვირუსული ტრაფიკის პირობითი ანგარიში

ავიღოთ პირობითი საიტი, რომლის ერთი ნახვა საშუალოდ 1 მბ მონაცემს გადასცემს და 10 CDN-მოთხოვნას წარმოქმნის. აქ გიგაბაიტი ათობითი წესითაა დათვლილი. Vercel-ის თანხები მხოლოდ ზემოთ მოცემული მოხმარებითი განაკვეთების ნამრავლია, კრედიტის, სააბონენტო ნაწილისა და ფიქსირებული CDN-ვარიანტის გარეშე; ისინი Vercel-ის ანგარიშის პროგნოზი არ არის. Cloudflare-ის მხარეს ვვარაუდობთ, რომ ყველა ეს მოთხოვნა სტატიკურ ფაილს ეხება და Pages Functions საერთოდ არ იძახება.

• დაბალი ტრაფიკი: თვეში 20 000 ნახვა წარმოქმნის დაახლოებით 20 გბ გადაცემას და 200 000 მოთხოვნას. Vercel-ის მითითებული ერთეულების ნამრავლი $3.40 გამოდის; Cloudflare Pages-ზე ამ სტატიკური მიწოდების დამატებითი საფასური $0-ია.
• საშუალო ტრაფიკი: 200 000 ნახვა დაახლოებით 200 გბ-სა და 2 მილიონ მოთხოვნას ნიშნავს. იმავე ნამრავლით Vercel-ის თანხა $34-ია, Cloudflare Pages-ის სტატიკური მოთხოვნებისთვის კი კვლავ $0.
• ვირუსული ზრდა: 2 მილიონი ნახვა დაახლოებით 2 000 გბ-სა და 20 მილიონ მოთხოვნას წარმოქმნის. Vercel-ის განაკვეთების ნამრავლი $340-მდე აღწევს; Cloudflare Pages-ზე მხოლოდ სტატიკური ფაილების მიწოდება ისევ უფასოა.

ამ მოდელში ფაილის საშუალო ზომა ისეთივე მნიშვნელოვანი დაშვებაა, როგორიც ნახვების რაოდენობა. თუ სურათები და სკრიპტები ერთ ნახვაზე ორჯერ მეტ მონაცემს გადასცემს, გადაცემის ნაწილი შესაბამისი პროპორციით გაიზრდება; თუ ბრაუზერი ფაილების ნაწილს საკუთარი ქეშიდან იღებს, განმეორებითი ნახვის მოთხოვნები შემცირდება. პირობითი ანგარიში ასევე არ მოიცავს დომენს, გადასახადებს, სურათების გარდაქმნას, მონაცემთა ბაზას ან სერვერულ გამოთვლას. სწორედ ამიტომ $340-ის Vercel-ის გადასახდელ თანხად წარმოდგენა შეცდომა იქნებოდა.

დინამიკური ნაწილის შესაფასებლად გვერდის ნახვები ფუნქციის გამოძახებებისგან უნდა გაიყოს. პირობითად, თუ თითო ნახვა ერთ API-მოთხოვნას ქმნის, ვირუსული სცენარი თვეში 2 მილიონ დინამიკურ გამოძახებასაც წარმოქმნის, მიუხედავად იმისა, რომ გვერდის დანარჩენი ფაილები სტატიკურია. თვიური ჯამი მარტო უფასო გეგმის დღიურ ზღვარზე ვერაფერს გვეუბნება: თანაბრად განაწილებული ტრაფიკი და ერთ დღეში თავმოყრილი პიკი განსხვავებულ შედეგს იძლევა. ფასიან Workers გეგმაზე კი მხოლოდ მოთხოვნების რაოდენობა არ კმარა — ფუნქციის CPU-ის დროც უნდა ჩაითვალოს.

Next.js: სტატიკური ექსპორტი და დინამიკური მარშრუტები

Next.js-ის სტატიკური ექსპორტი Cloudflare Pages-ზე განთავსების მარტივი შემთხვევაა: შექმნილი ფაილები სტატიკურ შიგთავსად მიეწოდება ვიზიტორს. სერვერული რენდერი, route handlers და Server Actions სხვა გზას მოითხოვს. Cloudflare-ის Next.js გზამკვლევი სრული აპლიკაციისთვის Workers-ზე vinext-ს ურჩევს და მის სტატუსს beta-დ ასახელებს; სტატიკური ექსპორტისთვის Pages ცალკე განთავსების ვარიანტად რჩება. ეს განსხვავება მნიშვნელოვანია: Pages-ის სტატიკური ფაილების ფასი ვერ აღწერს დინამიკური Next.js აპის მთლიან ხარჯს.

უკვე Vercel-ზე მომუშავე Next.js პროექტის გადატანას შეიძლება დასჭირდეს მარშრუტების, დამოკიდებულებებისა და ქეშირების ქცევის გადამოწმება. Cloudflare-ის გზამკვლევში vinext-ისთვის ფართო მხარდაჭერაა ჩამოთვლილი, მაგრამ არსებული საწარმოო აპისთვის თავსებადობის შემოწმებაც რეკომენდებულია; ზოგი შესაძლებლობა ნაწილობრივაა მხარდაჭერილი. ამიტომ დაბალი ტრაფიკის ფასი მარტო ვერ ფარავს გადატანის დროსა და შესაძლო ცვლილებებს. ამ გადაწყვეტილების მეორე მხარეს უფრო ვრცლად ეხება Workers-ზე მიგრაციის ხარჯის შედარება.

როდის ხდება პროექტების ზღვარი მნიშვნელოვანი

ბევრი დამოუკიდებელი საიტის მქონე გუნდისთვის Cloudflare Pages-ის ანგარიშის ლიმიტიც არჩევანის ნაწილია. Cloudflare Pages-ის ლიმიტებით ერთ ანგარიშზე 100 პროექტია დაშვებული; ფასიან Workers ანგარიშს ცალკე 500 Worker-მდე შეუძლია, მაგრამ ეს Pages-ის პროექტების ზღვარს არ ზრდის. უფასო Pages გეგმაზე თვეში 500 build და ერთდროულად ერთი build არის გათვალისწინებული. ხშირი განახლებების ან მრავალი კლიენტის პროექტის შემთხვევაში ეს შეზღუდვები შეიძლება უფრო ადრე გახდეს საგრძნობი, ვიდრე სტატიკური ტრაფიკის ფასი.

ამრიგად, არჩევანის საზომი პროექტის აგებულებაა: წმინდა სტატიკურ საიტს Cloudflare Pages-ის უფასო მიწოდება ერგება, განსაკუთრებით ტრაფიკის მკვეთრი ზრდისას; დინამიკური Next.js აპისთვის კი runtime-ის თავსებადობა და გადატანის მოცულობა იმავე წონით უნდა შეფასდეს, როგორც დარიცხვა. ერთი ადგილიდან მიღებული ქეშირებული TTFB ამ განსხვავებებს ვერ ანაცვლებს.

ასევე წაიკითხეთ:

• Cloudflare Workers თუ Vercel: დაბალი ფასი მიგრაციას მარტივს არ ხდის
• Cloudflare R2 თუ Amazon S3: ნულოვანი egress ყოველთვის იაფი არაა
• Cloudflare Turnstile ჩასვით? სერვერული შემოწმების გარეშე დაცვა არ მუშაობს