أدى نقل عملية إنشاء الصور المصغرة (thumbnails) من خلفية PHP إلى Cloudflare Workers إلى القضاء تماماً على حمل المعالج (CPU load) في الخادم الأصلي (origin server) لموقع استضافة فيديو يخدم ملايين الصور يومياً. كما نقل هذا التحول زمن انتقال معالجة الصور (latency) من مركز البيانات إلى الحافة (the edge)، مما أدى إلى تقليص أوقات الاستجابة وجعل تكاليف عرض النطاق الترددي (bandwidth) قابلة للتنبؤ.

لماذا فشل النموذج القديم

الموقع، وهو منصة تعرض عشرات الآلاف من الفيديوهات، يدرج ما يصل إلى 40 صورة مصغرة في الصفحة الواحدة. يتم تغيير حجم كل صورة مصغرة عند الطلب بواسطة سكربت PHP يقرأ الملف الأصلي ويعيد تحجيمه. وعندما كانت عناكب الزحف (crawlers) تزور الموقع، كان خادم الخلفية يتوقف عن العمل (stall).

المعالجة عند الحافة (Edge processing) تحل المتطلبات الخمسة الأساسية

يجب أن تتعامل واجهة برمجة تطبيقات (API) الصور المصغرة ذات المستوى الإنتاجي مع:

  • Fan-in – سحب الصور المصدرية من العديد من المستضيفين الخارجيين (third-party hosts).
  • Fan-out – إنتاج أحجام متعددة (مثل بطاقات بحجم 320 بكسل، وصور رئيسية بحجم 640 بكسل).
  • Format negotiation – التفاوض على التنسيق عبر تقديم تنسيقات WebP أو AVIF عندما يدعمها المتصفح لتقليل استهلاك عرض النطاق الترددي.
  • Cache – التخزين المؤقت لضمان أن الطلب الأول قد يكون مكلفاً، ولكن كل طلب لاحق يكون مجانياً.
  • Security – الأمان لمنع أي شخص من إساءة استخدام الخدمة لمعالجة صور عشوائية.

تعالج Cloudflare Workers كل نقطة دون المساس بمعالج الخادم الأصلي:

  1. القرب (Proximity) – تعمل الـ Workers في مراكز بيانات قريبة من المستخدم، لذا تقطع الصورة المعالجة مساراً أقصر.
  2. تغيير حجم الصور المدمج (Built-in Image Resizing) – تقوم ميزة Image Resizing في المنصة بالعمل على مستوى البكسل، مما يلغي الحاجة إلى مكتبة مخصصة.
  3. واجهة برمجة تطبيقات التخزين المؤقت (Cache API) – تقوم الـ Workers بتخزين الصورة المعاد تحجيمها عند الحافة؛ وبعد الطلب الأول، تقوم الحافة بتقديمها مباشرة.
  4. الأمان القابل للبرمجة (Programmable security) – يقوم سكربت صغير بالتحقق من تواقيع HMAC، وفرض قائمة مسموح بها (allow-list) لأسماء المضيفين والعروض، وتوحيد مفاتيح التخزين المؤقت (cache keys) لتجنب تسميم التخزين المؤقت (cache poisoning).

كيف يعمل النظام

  1. الخادم الأصلي ينشئ روابط موقعة (signed URLs) – تحتفظ الخلفية بمفتاح سري وتضيف توقيع HMAC إلى كل طلب صورة مصغرة. يتضمن الرابط أيضاً العرض والتنسيق المطلوبين.
  2. الـ Worker يتحقق من التوقيع – عند الاستلام، تعيد الـ Worker حساب HMAC باستخدام السر المشترك. إذا كان التوقيع مفقوداً أو خاطئاً، يتم رفض الطلب، مما يمنع إساءة الاستخدام.
  3. فرض القائمة المسموح بها (Allow-list enforcement) – يتحقق السكربت من أن اسم المضيف المصدر موجود في قائمة محددة مسبقاً وأن العرض المطلوب هو أحد الأحجام المدعومة. هذا يمنع تخزين المضيفين الضارين في الذاكرة المؤقتة.
  4. توحيد مفتاح التخزين المؤقت (Cache key normalization) – يتم تجريد التوقيع نفسه من مفتاح التخزين المؤقت؛ حيث يحتوي المفتاح فقط على رابط المصدر، والعرض، والتنسيق. وهذا يزيد من احتمالية وصول مستخدمين مختلفين يطلبون نفس الصورة إلى نفس الإدخال المخزن مؤقتاً.
  5. الجلب وتغيير الحجم عند الحافة (Edge fetch and resize) – إذا لم تكن الصورة مخزنة مؤقتاً بالفعل، تقوم الـ Worker بجلب الأصل من المضيف الخارجي، وتشغيل Image Resizing API، وتخزين النتيجة في ذاكرة التخزين المؤقت عند الحافة.
  6. تحمية التخزين المؤقت (Cache warming) – بعد كل عملية زحف، يقوم سكربت Python خفيف بطلب الصور المصغرة الجديدة مسبقاً. وبالتالي، يتلقى أول مستخدم حقيقي استجابة مخزنة مؤقتاً بدلاً من الانتظار لإتمام عملية تغيير الحجم.

التأثير الملموس بعد شهر واحد

  • استهلاك معالج الخادم الأصلي للصور – انخفض إلى الصفر؛ لم تعد الخلفية تعالج بايتات الصور أبداً.
  • سرعة تقديم صفحات HTML – تحسنت بشكل ملحوظ لأن الخادم لم يعد يتوقف بسبب مهام الصور.
  • معدل إصابة التخزين المؤقت عند الحافة (Edge cache hit rate) – وصل إلى 96%، مما يعني أن كل طلب تقريباً تم تلبيته من الحافة دون الحاجة لجلب البيانات من الخلفية.
  • زمن الانتقال (Latency) – انخفض لأن الصور تُقدم الآن من مركز بيانات قريب من المستخدم بدلاً من خادم أصلي مركزي.
  • قابلية التنبؤ بعرض النطاق الترددي – مع التخزين المؤقت عند الحافة، تصبح حركة المرور الصادرة من الخادم الأصلي مستقرة وسهلة التوقع.

الخلاصة

أدى نقل عبء إنشاء الصور المصغرة إلى Cloudflare Workers إلى تحويل عنق الزجاجة المرتبط بالمعالج إلى ذاكرة تخزين مؤقت عند الحافة بتكلفة تقترب من الصفر. أصبح الخادم الأصلي الآن يكتفي بإصدار روابط موقعة فقط، بينما تتولى الحافة مهام الجلب، وتغيير الحجم، والتفاوض على التنسيقات، وتقديم النتائج المخزنة مؤقتاً. بالنسبة لأي موقع يعتمد بشكل كبير على الصور — وخاصة منصات الفيديو التي تعرض عشرات الصور المصغرة في الصفحة الواحدة — فإن نهج "الحافة أولاً" (edge-first) يوفر صفحات أسرع، وتكاليف قابلة للتنبؤ، وفصلاً أكثر وضوحاً بين "ما يجب عرضه" (الخادم الأصلي) و"كيفية تقديمه" (الحافة).