حجم حزمة Cloudflare Workers لم يعد يفرض الترقية المدفوعة

لم يعد حجم حزمة Cloudflare Workers سببًا للانتقال إلى Workers Paid. ففي 4 سبتمبر 2026، استبدلت Cloudflare فحصي الحزم المضغوطة القديمين، 3 MB لخطة Free و10 MB لخطة Paid، بحد موحّد قدره 64 MiB للحزمة غير المضغوطة في الخطتين؛ وبذلك أصبحت ميزانية النشر تُقاس بسطر Total Upload في Wrangler بدلًا من gzip.

ما الذي تغيّر في حجم حزمة Cloudflare Workers؟

حزمة Worker هي الشفرة والوحدات المساندة التي تتلقاها Cloudflare عند النشر. ويتولى Wrangler، أداة سطر الأوامر التابعة لـ Cloudflare، تجهيز ملف الرفع باستخدام esbuild افتراضيًا، وإدراج حزم npm التي تستوردها الشفرة، ثم عرض حجمه.

حتى 4 سبتمبر، كانت Cloudflare تضغط الحزمة وترفضها إذا تجاوز حجمها المضغوط 3 MB في Workers Free أو 10 MB في Workers Paid. أما فحص الحجم المضغوط هذا فقد أُلغي.

أصبحت المنصة تتحقق الآن من شرط واحد: ألا يتجاوز حجم الحزمة غير المضغوطة 64 MiB. وينطبق الحد نفسه على Free وPaid.

يلخّص العمود الأخير آلية العمل كاملة. فقيمة Total Upload تمثل الحجم غير المضغوط. وما زالت قيمة gzip تظهر للرجوع إليها، لكن Cloudflare لم تعد تستخدمها بوابةً لقبول النشر أو رفضه.

لا تختزل هذا التغيير في معامل ضرب بسيط. كانت الأرقام القديمة تقيس وحدات بايت مضغوطة بوحدة MB، بينما يقيس الرقم الجديد وحدات بايت غير مضغوطة بوحدة MiB. لذا تعتمد كمية الشفرة الإضافية التي تتسع لها الحزمة على قابلية JavaScript والاعتماديات والوحدات الثنائية في مشروعك للضغط.

تغيّر قرار الاشتراك بخطة $5

الأثر التجاري المباشر محدد ومفيد. فالحد الأدنى لتكلفة Workers Paid هو $5 USD لكل حساب شهريًا. وإذا كان فريق ما يخطط للترقية فقط لأن حجم حزمته تجاوز حد Free القديم البالغ 3 MB، فقد زال هذا السبب ما دامت قيمة Total Upload لا تتجاوز 64 MiB.

لكن ذلك لا يجعل الخطتين متساويتين. فما زالت Workers Free تشمل 100,000 طلب يوميًا، و10 مللي ثانية من وقت CPU لكل استدعاء، و50 طلبًا فرعيًا لكل استدعاء. أما Workers Paid فتشمل 10 ملايين طلب و30 مليون مللي ثانية من وقت CPU شهريًا، وتسمح بـ10,000 طلب فرعي لكل استدعاء، ويمكنها تشغيل ما يصل إلى 5 دقائق من وقت CPU لكل طلب، مع قيمة افتراضية قدرها 30 ثانية.

وهكذا يصبح قرار الميزانية أوضح: ادفع مقابل حركة المرور ووقت CPU والطلبات الفرعية والإمكانات الحصرية لخطة Paid، لا لمجرد أن حزمة قابلة للضغط تجاوزت حد Free الذي أُلغي.

لن ترى الفرق التي تستخدم Paid بالفعل لأحمال إنتاج فعلية انخفاضًا مباشرًا في الفاتورة. كذلك لن يتغير سير عمل الفرق التي كانت حزمها أدنى بكثير من الحد القديم. وتتركز الفائدة لدى المشاريع التي كانت تقلّص حزمها أو تقسّمها أو ترقي خطتها بسبب حجم النشر.

أما بقية حسابات التكلفة وحدود التشغيل، فتشرحها مراجعة Cloudflare الأشمل، بما في ذلك موقع Workers ضمن خطط Cloudflare ورسوم الاستخدام الأخرى. والأرقام القديمة لحدود الحزم في تلك المراجعة هي الجزء الذي يستبدله تغيير سبتمبر هذا.

أربعة أنواع من المشاريع أصبحت أسهل

يستطيع مؤسس SaaS منفرد فصل اختيار الخطة عن اختيار إطار العمل

لنفترض أن مؤسسًا يطلق تطبيقًا متكاملًا على Workers Free. قد ينتج محوّل إطار العمل وشفرة العرض على الخادم واعتماديات الإنتاج حزمةً يتجاوز حجمها المضغوط حد Free القديم، حتى عندما تظل حركة التطبيق ضمن حدود Free.

يمكن الآن تقييم ذلك البناء وفق قيمة Total Upload البالغة 64 MiB. فإذا كان ضمن الحد، فلن يفرض حجم الحزمة وحده الحد الأدنى البالغ $5 لخطة Paid. ولا يعني ذلك تشغيل الإنتاج مجانًا مهما كان الحجم، بل يتيح التحقق من وجود الطلب قبل دفع تكلفة استخدام تشغيلية لا يحتاج إليها المشروع بعد.

تستطيع الوكالة حذف بوابة CI الخاطئة

ربما نسخ مسؤول البناء في وكالة ما حد gzip القديم إلى كل مستودعات العملاء. والإبقاء على هذا الفحص يؤدي إلى فشل عمليات البناء بسبب قاعدة لم تعد Cloudflare تطبقها.

استبدل به فحصًا لقيمة Total Upload غير المضغوطة، وحدد سقفًا داخليًا أدنى من 64 MiB لترك هامش احتياطي. عندها ستفشل مشاريع العملاء بسبب قيد المنصة الحالي، لا بسبب قيد أصبح من الماضي.

يحصل فريق Rust أو WebAssembly على مساحة أكبر، لا بيئة تشغيل جديدة

تتيح WebAssembly، التي تُختصر عادةً إلى Wasm، لـ Worker تشغيل شفرة ثنائية جُمّعت من لغات مثل Rust أو Go أو C. وتشير Cloudflare إلى أن Wasm Workers تكون عادةً أكبر من نظيراتها المكتوبة بـJavaScript، لأن الملف الثنائي غالبًا ما يحمل اعتماديات تشغيل إضافية.

يمنح حد النشر الأكبر ذلك الفريق مساحة أوسع لوحدة Wasm والشفرة المحيطة بها. ويدعم Wrangler رفع ملفات .wasm و.wasm?module مباشرةً. ومع ذلك يظل تحسين الحجم مهمًا، كما توصي Cloudflare باستخدام wasm-opt لتقليص الملف الثنائي.

يستطيع فريق المنصة إلغاء بنية صُممت للتحايل على الحد

ربما اضطر مهندس منصة يستخدم Workers Paid إلى تقسيم خدمة مترابطة، أو حذف اعتماد مفيد، أو إنشاء مسار مخصص للوحدات الخارجية لمجرد البقاء تحت حد 10 MB المضغوط. هذا القرار يستحق المراجعة من جديد.

ينبغي أن تبقى بعض التقسيمات لأنها ترسم حدودًا واضحة للملكية أو للأعطال. أما التقسيم الذي لا مبرر له سوى فحص الرفع الملغى، فقد أصبح تعقيدًا لا يستند إلى متطلب من المنصة.

افحص حجم حزمة Cloudflare Workers الحقيقي قبل النشر التالي

لا داعي للتخمين اعتمادًا على حجم node_modules أو مجلد الشفرة المصدرية أو الأرشيف الذي ينشئه بناء مستقل لإطار العمل. شغّل نشر Wrangler التجريبي من مشروع Worker نفسه، كي يبني الملف الذي ستتلقاه Cloudflare فعلًا.

1. 1

   أنشئ الحزمة من دون نشر

   شغّل أمر الاختبار الموثّق لدى Cloudflare:

   wrangler deploy --outdir bundled/ --dry-run

   يبني Wrangler ملف Worker ويحفظ المخرجات محليًا من دون نشرها.

2. 2

   اقرأ Total Upload

   ابحث عن Total Upload في مخرجات الأمر. فهي تمثل حجم الحزمة غير المضغوطة الذي تقارنه Cloudflare الآن بحد 64 MiB. احتفظ بقيمة gzip للسياق التشخيصي إن كانت مفيدة، لكن لا تستخدمها للحكم على قبول المنصة للنشر أو رفضه.

3. 3

   غيّر ميزانية CI

   استبدل أي قاعدة للحجم المضغوط تبلغ 3 MB في Free أو 10 MB في Paid بقاعدة تعتمد Total Upload. وحدد لفريقك سقفًا أدنى من الحد الأقصى للمنصة حتى لا يستهلك تحديث واحد لاعتماد ما كامل الهامش المتاح.

4. 4

   راقب بدء التشغيل في النشر الفعلي

   عند تنفيذ النشر العادي التالي أو رفع إصدار جديد، سجّل قيمة startup_time_ms التي يعرضها Wrangler. فقد تكون الحزمة ضمن حد الرفع، ومع ذلك تفشل في فحص بدء التشغيل المستقل لدى Cloudflare.

الخطأ الشائع هو مراقبة قيمة gzip التي تبدو أصغر، لأنها كانت تحسم قرار النشر سابقًا. لكنها لم تعد تفعل ذلك؛ فقيمة Total Upload هي سطر الميزانية الآن.

الحدود الفعلية لم تزد بمقدار 64 MiB

قد تستغرق الحزم الأكبر وقتًا أطول للتحليل والتهيئة. والشفرة التي تنفذ عملًا مكلفًا في النطاق العام، أي خارج معالج الطلب، قد تظل تفشل في التحقق مع الرسالة Script startup exceeded CPU time limit ورمز الخطأ 10021. فالسماح لحزمة دون 64 MiB باجتياز بوابة الحجم لا يضمن لها بدء تشغيل سليمًا.

يظهر هذا الأثر بوضوح أكبر مع أطر العمل الثقيلة وWasm. كان الحد القديم يوقف الرفع أولًا في كثير من الأحيان، أما الحد الجديد فيسمح لمزيد من الشفرة بالوصول إلى القيد التالي، حيث يظهر أثر الذاكرة وسلوك التهيئة.

إذا ظل حجم Worker أكبر من اللازم، فتقدم الوثائق الحالية ثلاثة مخارج عملية:

• احذف الحزم والاعتماديات التي لا يستخدمها مسار النشر.
• خزّن الإعدادات والأصول الثابتة والبيانات الثنائية في Workers Static Assets أو KV أو R2 أو D1 بدلًا من وضعها داخل حزمة Worker.
• قسّم الوظائف بين عدة Workers باستخدام Service Bindings.

لا تضيف استدعاءات Service Binding رسوم طلب ثانٍ. تحاسب Cloudflare على الاستدعاء الأول لـ Worker وإجمالي وقت CPU المستهلك عبر جميع Workers المشاركة. لذلك يُعد التقسيم أداة عملية لضبط الحجم، لكن ينبغي قبول الحد الإضافي بين الخدمات عن قصد.

ماذا تفعل يوم الاثنين؟

تحرّك هذا الأسبوع إذا فشل Worker مؤخرًا في فحص الحجم القديم، أو إذا قلّص فريقك اعتماديات إطار العمل للبقاء تحته، أو إذا كان حجم الحزمة السبب الوحيد المرتبط بالترقية إلى Paid. شغّل النشر التجريبي، وسجّل Total Upload، ثم أعد فتح ذلك القرار.

انتظر إذا كان Worker أدنى بكثير من الحد القديم أصلًا، ولم يتضمن مسار النشر بوابة ثابتة لقيمة gzip. فلم يتغير شيء في تشغيل التطبيق نفسه.

ابقَ على Paid إذا كانت الطلبات أو وقت CPU أو الطلبات الفرعية أو إحدى إمكانات Paid الأخرى تبررها. فارتفاع حد الرفع في Free ليس سببًا لنقل حمل إنتاج إلى خطة لا تلائم حدوده التشغيلية.

خطوة الاثنين بسيطة: غيّر فحص البناء من gzip إلى Total Upload، ثم اتخذ قرار الخطة وفق الاستخدام بدلًا من حجم الحزمة.

تابع التغيير العملي التالي في عالم المنصات عبر النشرة البريدية.