Cloudflare أم Fastly: ما الذي تختاره فعلًا

الجواب لا يتعلق بمن يملك شبكة أكبر. كلتاهما تقفان أمام موقعكم، وتنهيان اتصال TLS، وتُسمَّيان شبكة توصيل محتوى (CDN)، وموقع من خمس صفحات يعمل مع أي منهما. الفرق في حجم ما تسلّمونه لحساب واحد: Cloudflare تأخذ DNS والشهادات والذاكرة المؤقتة وجدار الحماية ومنطقًا بجافاسكربت على الطرف، وFastly تنتظر أن تأتي DNS والشهادات من مكان آخر، وتمنحكم طرفًا قابلًا للبرمجة مقابل ذلك الفصل. وينقلب الاختيار على مقدار السطح التشغيلي الذي تريدون أن يملكه مورّد واحد، وعلى مكان زوّاركم.

ما الذي يُخزَّن فعلًا؟

الملفات الثابتة هي النصف السهل: الصور وCSS وجافاسكربت والخطوط تُخزَّن بحسب الامتداد عند كلتاهما، فيبدو النشر الأول نجاحًا والموقع سريعًا في المكتب.

أما HTML واستجابات API فهي النصف الآخر، وهنا لا تفعل الشبكة شيئًا في صمت. صفحة تضع كوكي أو تعيد Cache-Control: private لا تُخزَّن عند أي منهما، ولا يجب أن تُخزَّن. والفخ في الصفحة التي كان يمكن تخزينها ولم تُخزَّن: قائمة منتجات أو مقال يعيد الخادم الأصل بناءها مع كل طلب، والمشغّل يظن أن الطرف يتولاها. سجل الخادم الأصل هو الحكم: إن كان يستقبل طلبًا لكل زائر فليس هناك تخزين، أيًا كان ما تقوله لوحة القواعد.

أين يجري منطقكم؟

Cloudflare تشغّل جافاسكربت على الطرف في وحدات قصيرة العمر، والكود نفسه يقرأ الذاكرة المؤقتة ويعيد التوجيه بحسب البلد أو يعدّل استجابة. وFastly تجمع خدمة بلغة Rust أو JavaScript أو Go إلى WebAssembly وتضعها في مسار الطلب مع واجهة صريحة للذاكرة.

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

وسؤال آخر: هل يرى كود الطرف الاستجابة المخزنة، أم الطلب فقط؟ هذا يحدد إمكان إضافة ترويسة تخصيص دون تعطيل التخزين للصفحة.

من يملك DNS والشهادة؟

هذا الاعتماد تُغفله معظم المقارنات، وهو مصدر الانقطاع.

Cloudflare مسجّل نطاقات ومضيف DNS مرجعي، فالتوكيل والسجلات والشهادة وجدار الحماية في لوحة واحدة. مريح، ويجمع الخطر: سجل واحد خاطئ يزيل الموقع عن الجميع في اللحظة نفسها، ويصبح DNS جزءًا مما تبحثون فيه عن العطل.

وFastly خدمة تُربط بموقعكم: يبقى DNS عند مزوّدكم وتوجّهون سجلًا إلى الطرف، فتنفصل الأعطال. لكن دورة حياة الشهادة وتذكير التجديد تصبح مسؤوليتكم، والنطاق الأعلى يحتاج مزوّدًا يدعم تسطيح CNAME أو ما يعادله.

لا ترتيب منهما أأمن بطبيعته. سمّوا من يجدّد الشهادة قبل النشر الأول.

ماذا يحصل عليه زائر المغرب الكبير؟

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

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

والقياس نفسه ستأخذونه على أي حال: Core Web Vitals يحدد ما يعيشه الزائر، وأرقام الميدان تأتي من جلسات حقيقية لا من صفحة حالة.

ما ثمن المغادرة؟

أكثر مما تعترف به خطة الترحيل، والكلفة في الضبط لا في البيانات.

قواعد التخزين وجدار الحماية وإعادة التوجيه مكتوبة بلغة كل مورّد، ولا صيغة محمولة بينهما، فالانتقال يعني إعادة كتابتها من السلوك الذي ترصدونه، والسلوك الذي لا ترصدونه هو ما ينكسر. ودوال الطرف تُعاد كتابتها كذلك، فـ Worker ليس خدمة Compute، ومعها تتغير مسارات السجلات وحدود التنبيه وقائمة عناوين الخادم الأصل والشهادة.

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

كيف يبدو الاختيار كاملًا؟

البعد	Cloudflare	Fastly
ما تتولاه	DNS والشهادات والتخزين وجدار الحماية وكود الطرف	التخزين وكود الطرف وإنهاء TLS
أين يجري المنطق	وحدات جافاسكربت ترى الذاكرة	خدمات WebAssembly بواجهة تخزين صريحة
DNS والشهادة	لوحة واحدة للاثنين	DNS في مكان آخر، والدورة لكم
السؤال الذي يُطرح	أي المواقع تخدم الجزائر، وكيف	السؤال نفسه، والقياس نفسه
ما تتحققون منه	ما تشمله الخطة قبل الاعتماد عليها	كيف تُجدَّد الشهادة ومن يجدّدها

كيف يقرر الفريق؟

1. قيسوا الموقع الحالي من مدينة عملائكم، على بيانات الهاتف، واحفظوا الرقم.
2. اكتبوا ما يجب تخزينه صفحةً صفحة، وما يجب ألا يُخزَّن أبدًا.
3. قرّروا هل سيحمل الطرف منطقًا. إن لم يحمل، فالقرار في DNS والشهادة.
4. سمّوا مالك DNS ومالك الشهادة كتابةً قبل أن ينتقل أي منهما.
5. جرّبوا على نطاق فرعي، ثم انقلوا النطاق الأعلى بمدة TTL قصيرة وخطة تراجع مكتوبة.

أين يخطئ الفريق؟

• صفحة مخزَّنة تحمل جلسة. يخزّن أحدهم كل شيء لعلاج البطء، فيرى أحد العملاء سلة عميل آخر.
• شهادة لم يجدّدها أحد. وصل التذكير إلى بريد مقاول غادر العمل.
• قاعدة جدار حماية تحجب إشعار الدفع. الموقع قائم والدفع متوقف، ويدرك الدعم المشكلة قبل اللوحة.
• شبكة أمام خادم أصل بطيء. كل طلب ينتظر قاعدة البيانات كما كان، والطرف لا يقدّم موعد وصول البيانات.
• قواعد لا يشرحها أحد. يعدّل شخصان مجموعة واحدة سنة، ثم يكسر تغييرٌ مسارًا لم يتذكره أحد.

ما لا يغطيه هذا الرأي

لا أسعار ولا أرقام أداء هنا. المورّدان يسعّران بالحركة وبالميزات، والمللي ثانية المقيسة في مكان آخر لا تقول شيئًا عن الجزائر. الصف الأخير في الجدول هو ما يستحق فتحه في تبويب آخر.

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

نبني الأصل وقواعد الطرف معًا، لأن قرار التخزين يخصّ التطبيق قبل أن يخصّ لوحة مورّد.