Cloudflare Pages یا Netlify؛ یک جهش مصرف می‌تواند همهٔ پروژه‌ها را متوقف کند

برای سایتی که بیشتر فایل ایستا تحویل می‌دهد و ترافیکش ممکن است ناگهان رشد کند، Cloudflare Pages از نظر هزینهٔ تحویل فایل انتخاب قابل‌پیش‌بینی‌تری است. در طرح‌های اعتباری Netlify، مصرف پروژه‌ها از اعتبار مشترک تیم کم می‌شود و پایان اعتبار تیم می‌تواند همهٔ پروژه‌های وب آن را متوقف کند: بازدیدکنندگان صفحهٔ در دسترس نبودن سایت را می‌بینند و انتشار نسخهٔ اصلی تازه نیز ممکن نیست. این قاعده را نباید به حساب‌هایی که همچنان در طرح قدیمی Netlify هستند تعمیم داد.

در Cloudflare Pages، محدودیت برجسته برای چنین انتخابی به ساخت نسخه مربوط می‌شود. محدودیت‌های رسمی Pages برای طرح رایگان، ۵۰۰ ساخت در ماه، یک ساخت هم‌زمان در هر حساب و مهلت ۲۰ دقیقه برای هر ساخت را تعیین می‌کند. پس تفاوت عملی این است: Netlify مصرف انتشار و ترافیک را از یک بودجهٔ مشترک کم می‌کند؛ Cloudflare Pages برای تحویل فایل ایستا مزیت دارد، اما گردش‌کار انتشار باید در ظرفیت ساخت آن جا بگیرد.

اعتبار Netlify چگونه به هزینه و توقف تبدیل می‌شود؟

در مدل اعتباری Netlify، واحد تصمیم‌گیری کل تیم است، نه یک سایت منفرد. قیمت‌گذاری Netlify برای طرح رایگان ۳۰۰ اعتبار ماهانه، برای Personal ماهانه ۱۰۰۰ اعتبار با قیمت ۹ دلار و برای پایهٔ Pro ماهانه ۳۰۰۰ اعتبار با قیمت ۲۰ دلار نشان می‌دهد. بنابراین حتی پروژه‌ای که به‌تنهایی کم‌مصرف است، از مصرف سایر پروژه‌های همان تیم جدا نمی‌ماند.

نرخ‌ها نیز فقط به شمار بازدیدکنندگان وابسته نیستند: روش محاسبهٔ اعتبار برای هر استقرار موفق در محیط اصلی ۱۵ اعتبار، برای هر گیگابایت پهنای باند خروجی ۲۰ اعتبار، برای هر ۱۰ هزار درخواست وب ۲ اعتبار و برای هر گیگابایت‌ساعت پردازش ۱۰ اعتبار در نظر می‌گیرد. ساخت نسخهٔ پیش‌نمایش و شاخه‌ای به‌خودی‌خود اعتبار استقرار اصلی مصرف نمی‌کند؛ درخواست‌ها و منابعی که آن نسخه‌ها مصرف می‌کنند همچنان در حساب ترافیک و پردازش می‌آیند.

یک بازدید صفحه می‌تواند چند درخواست جدا برای تصویر، قلم، CSS و جاوااسکریپت ایجاد کند. برعکس، دانلود یک فایل بزرگ ممکن است تعداد درخواست‌ها را چندان تغییر ندهد ولی پهنای باند را بالا ببرد. برای همین برآوردی که فقط «بازدید ماهانه» را می‌سنجد، ممکن است زمان رسیدن تیم به سقف اعتبار را اشتباه نشان دهد.

در طرح رایگان، پس از پایان اعتبار باید تا چرخهٔ بعدی منتظر ماند یا طرح را ارتقا داد. در Personal و Pro می‌توان بستهٔ اعتبار خرید یا شارژ خودکار را برای کل تیم فعال کرد؛ شارژ خودکار به‌طور پیش‌فرض خاموش است. فعال کردن آن خطر وقفه بر اثر تمام‌شدن اعتبار را کاهش می‌دهد، اما هزینهٔ ماه پرترافیک را متغیر می‌کند.

سایت ایستا: چه زمانی ترافیک تعیین‌کننده است؟

یک مثال فرضی را در نظر بگیرید: سایتی در یک ماه چهار بار در محیط اصلی منتشر می‌شود، ۵ گیگابایت فایل تحویل می‌دهد و ۵۰ هزار درخواست وب دریافت می‌کند. با نرخ‌های بالا، استقرارها ۶۰ اعتبار، پهنای باند ۱۰۰ اعتبار و درخواست‌ها ۱۰ اعتبار مصرف می‌کنند؛ جمع ۱۷۰ اعتبار است. این سایت به‌تنهایی در سهمیهٔ طرح رایگان Netlify جا می‌گیرد، اما برای پروژه‌های دیگر تیم و مصرف احتمالی تابع‌ها فقط ۱۳۰ اعتبار باقی می‌گذارد.

در Cloudflare Pages همان چهار انتشار از ظرفیت ساخت کم می‌کند. قیمت‌گذاری Pages Functions تصریح می‌کند که درخواست فایل ایستایی که تابعی را اجرا نکند، در طرح رایگان و پولی رایگان و نامحدود است؛ درخواست تابع جداگانه در سهمیهٔ Workers حساب می‌شود. در نتیجه افزایش بازدید از صفحه‌های واقعاً ایستا، به‌تنهایی همان فشار اعتباری Netlify را برای تحویل فایل ایجاد نمی‌کند.

مرز «واقعاً ایستا» مهم است. اگر درخواست صفحه یا فایل از مسیر یک Pages Function عبور کند، دیگر صرفاً درخواست فایل ایستا محسوب نمی‌شود. برای سایت محتوایی یا صفحهٔ معرفی محصول، تفاوت میان فایل آماده و مسیری که کد سمت سرور اجرا می‌کند، بیش از نام فریم‌ورک در پیش‌بینی مصرف اهمیت دارد.

فروشگاه پرترافیک: یک جهش کدام پروژه‌ها را درگیر می‌کند؟

فرض کنید بخش میزبانی‌شدهٔ یک فروشگاه فقط ویترین ایستا باشد و پرداخت و داده‌های پویای آن بیرون از این دو سرویس انجام شود. اگر در یک ماه ۱۲ انتشار اصلی، ۳۰ گیگابایت خروجی و ۳۰۰ هزار درخواست وب داشته باشد، مصرف فرضی Netlify به‌ترتیب ۱۸۰، ۶۰۰ و ۶۰ اعتبار است؛ در مجموع ۸۴۰ اعتبار. این مقدار از سقف طرح رایگان عبور می‌کند و در طرح Personal، پیش از حساب کردن سایر پروژه‌های تیم، ۱۶۰ اعتبار باقی می‌گذارد.

حالا فرض کنید یک کمپین فقط ۲۰ گیگابایت خروجی اضافی ایجاد کند و سایر ورودی‌های محاسبه ثابت بمانند. هزینهٔ آن ۴۰۰ اعتبار دیگر است و جمع مثال به ۱۲۴۰ اعتبار می‌رسد؛ پس سهمیهٔ Personal نیز کافی نخواهد بود. اگر تیم اعتبار اضافه یا شارژ خودکار نداشته باشد، توقف به همان ویترین محدود نمی‌ماند و دیگر پروژه‌های وب تیم را هم دربرمی‌گیرد. این یک محاسبهٔ فرضی از نرخ‌های منتشرشده است، نه نتیجهٔ آزمون ترافیک.

در Cloudflare Pages، خروجی بیشترِ فایل‌های ایستای این ویترین به‌خودی‌خود اعتبار تحویل فایل مصرف نمی‌کند. اما اگر جست‌وجوی کالا، شخصی‌سازی یا مسیرهای دیگر از Pages Functions استفاده کنند، درخواست‌های آن‌ها وارد سهمیهٔ Workers می‌شود. بنابراین برای فروشگاه، نسبت ترافیک ایستا به درخواست‌های پویا تعیین می‌کند مزیت میزبانی ایستا تا چه اندازه در صورت‌حساب واقعی دیده شود.

مونوریپو: تعداد انتشار یا صف ساخت؟

در یک مونوریپوی فرضی با سه سایت، اگر هر سایت هفته‌ای دو بار و در یک ماه چهار هفته‌ای در محیط اصلی منتشر شود، ۲۴ استقرار اصلی به دست می‌آید. در Netlify، این انتشارها به‌تنهایی ۳۶۰ اعتبار می‌خواهند و از سهمیهٔ طرح رایگان بیشترند؛ هنوز هیچ بازدید یا پردازشی در محاسبه نیست. نسخه‌های پیش‌نمایش هزینهٔ استقرار اصلی ندارند، اما انتشار نهایی هر سایت همچنان از اعتبار مشترک تیم کم می‌کند.

در Cloudflare Pages، ۲۴ ساخت از سقف ماهانهٔ طرح رایگان فاصله دارد. مسئلهٔ محتمل‌تر در این مثال، صف و مدت ساخت است: اگر تغییرات چند سایت نزدیک به هم برسند، در حساب رایگان فقط یک ساخت هم‌زمان اجرا می‌شود و بقیه منتظر می‌مانند. ساختی که بیش از مهلت مجاز طول بکشد نیز کامل نمی‌شود. بنابراین مونوریپویی با ساخت‌های سنگین ممکن است با وجود تعداد انتشار کم، در تحویل نسخهٔ تازه تأخیر داشته باشد.

این دو سقف را نمی‌توان با مقایسهٔ عدد خامشان رتبه‌بندی کرد. ظرفیت ساخت Cloudflare تعداد اجرای ماهانه و هم‌زمانی آن‌ها را محدود می‌کند؛ اعتبار Netlify بودجه‌ای است که هم انتشار اصلی و هم ترافیک و پردازش از آن مصرف می‌کنند. برای تیمی که چند سایت را از یک مخزن منتشر می‌کند، تعداد ساخت‌های ناشی از هر تغییر و تعداد انتشارهای نهایی دو ورودی متفاوت‌اند.

توابع سمت سرور چه چیزی را در محاسبه عوض می‌کنند؟

وقتی یک مسیر کد سمت سرور اجرا می‌کند، قیمت میزبانی فایل ایستا دیگر کل هزینه را نشان نمی‌دهد. در Netlify، زمان اجرای تابع در حافظهٔ تخصیص‌یافته به گیگابایت‌ساعت تبدیل می‌شود؛ درخواست وب و پهنای باند خروجی آن هم می‌توانند جداگانه اعتبار مصرف کنند. برای یک مثال صرفاً حسابی، اگر ۱۰۰ هزار فراخوانی هرکدام با حافظهٔ تخصیص‌یافتهٔ ۲۵۶ مگابایت به مدت ۰٫۲ ثانیه اجرا شوند، مصرف پردازش حدود ۱٫۳۹ گیگابایت‌ساعت، یا نزدیک به ۱۴ اعتبار، می‌شود. خود این فراخوانی‌ها نیز در صورت شمارش به‌عنوان درخواست وب حدود ۲۰ اعتبار دیگر مصرف می‌کنند؛ خروجی داده هنوز به این جمع افزوده نشده است.

در Cloudflare Pages، درخواست‌های Functions از سهمیهٔ Workers استفاده می‌کنند. در طرح رایگان، Pages Functions و Workers سهمیهٔ مشترک روزانه دارند که در مستندات قیمت‌گذاری برای مجموع آن‌ها ۱۰۰ هزار درخواست ذکر شده است. این حد روزانه را نباید با اعتبار ماهانهٔ Netlify یکی گرفت: یک اوج کوتاه در مسیر پویا می‌تواند زودتر از آنچه میانگین ماهانه نشان می‌دهد به حد اجرای تابع برسد.

برای سایت عمدتاً ایستا با ترافیک نامطمئن، مزیت Cloudflare Pages در تحویل فایل روشن است، مشروط به آنکه ساخت‌ها در ظرفیت و مهلت طرح جا بگیرند. Netlify برای تیمی که هزینهٔ انتشار، ترافیک و پردازش را در سطح همهٔ پروژه‌ها برآورد کرده و برای ماه‌های شلوغ اعتبار کافی در نظر گرفته است، انتخاب قابل‌محاسبه‌ای می‌ماند. اگر بخش بزرگی از درخواست‌ها تابع اجرا می‌کنند، سهمیهٔ Workers و مصرف پردازش Netlify باید جدا از هزینهٔ فایل‌های ایستا مقایسه شوند.

بیشتر بخوانید:

• Cloudflare Workers یا Vercel؛ پهنای باند می‌تواند هزینه را ۳۲ برابر کند
• Cloudflare R2 یا Amazon S3؛ خروج داده می‌تواند صورت‌حساب را عوض کند
• Hugging Face یا Replicate؛ ترافیک پراکنده هزینه را برعکس می‌کند