يجعل CDN ملفاتك الثابتة تُحمَّل بسرعة كبيرة. الصور، وملفات CSS، وJavaScript، والخطوط، كلها تُقدَّم من عقدة قريبة من الزائر بدلاً من خادمك الأساسي الموجود في مكان بعيد. لكن بمجرد أن يضيف أحدهم سلة تسوق، أو نموذج تسجيل دخول، أو لوحة تحكم شخصية، يصبح الفريق خائفًا من لمس إعدادات CDN من الأساس. إذا خزّنت كل شيء في الكاش، سيرى المستخدمون أسعارًا قديمة. وإذا لم تخزّن شيئًا، ستخسر معظم فائدة استخدام CDN لتسريع الموقع.
الخبر الجيد: لست مضطرًا للاختيار بين السرعة والتحديث المستمر. كل ما تحتاجه هو قواعد caching تفهم الفرق بين المحتوى الذي لا يتغير أبدًا والمحتوى الذي يتغير مع كل زائر.
لماذا يفشل الإعداد البسيط لـ CDN مع المحتوى الديناميكي
معظم شبكات CDN تعتمد افتراضيًا على تخزين الكاش بناءً على الرابط وأحيانًا طريقة الطلب. هذا يعمل جيدًا مع /images/logo.png. لكنه يعمل بشكل سيئ جدًا مع /api/cart أو /account/orders، حيث تعتمد الاستجابة على من يطلب، وما الموجود في جلسته، أو ما حدث قبل خمس ثوانٍ فقط.
إذا خزّن CDN صفحة شخصية في الكاش وقدّمها للزائر التالي، فهذه ليست مجرد مشكلة تقنية. إنها مشكلة خصوصية وثقة. ولهذا السبب تلجأ فرق كثيرة إما لتعطيل التخزين المؤقت تمامًا على المسارات الديناميكية، أو لبناء قوائم استثناء معقدة بناءً على الروابط تنهار بمجرد إضافة صفحة جديدة.
الهدف الحقيقي: تخزين انتقائي، لا تخزين شامل
الحل ليس مفتاحًا يعمل بشكل كامل أو لا يعمل إطلاقًا. الحل هو تعليم CDN أي أجزاء من الاستجابة آمنة للتخزين المؤقت ولأي مدة، باستخدام إشارات يعرفها تطبيقك بالفعل.
استخدم رؤوس Cache-Control كأداتك الأساسية
كل استجابة يرسلها خادمك يمكن أن تحمل رأس Cache-Control، وهذا يجب أن يكون المصدر الموثوق الذي يعتمد عليه CDN، وليس إعدادًا تحاول تجاوزه.
- الملفات الثابتة: استخدم Cache-Control: public, max-age=31536000, immutable للملفات ذات الأسماء المُشفّرة مثل app.a1b2c3.js. بما أن اسم الملف يتغير عند تغير المحتوى، يمكنك تخزينها لسنة كاملة دون أي خطر.
- الصفحات شبه الديناميكية: استخدم Cache-Control: public, max-age=60, stale-while-revalidate=300 لصفحة رئيسية لمدونة أو قائمة تصنيف تتغير أحيانًا لكن لا تحتاج أن تكون فورية.
- المحتوى الشخصي الحقيقي: استخدم Cache-Control: private, no-store لصفحات الحساب، والسلة، وأي شيء مرتبط بكوكيز الجلسة.
توجيه stale-while-revalidate يستحق اهتمامًا خاصًا. فهو يخبر CDN بتقديم النسخة المخزنة فورًا، مع جلب نسخة محدثة في الخلفية في نفس الوقت. الزائر لا ينتظر التحديث أبدًا، والزائر التالي يحصل على النسخة الجديدة. هذا الرأس وحده يلغي معظم المفاضلة بين السرعة والتحديث للمحتوى الذي يتغير كل بضع دقائق بدلاً من كل بضع ثوانٍ.
غيّر التخزين المؤقت بناءً على المفاتيح الصحيحة
أحيانًا تكون الصفحة ثابتة في معظمها لكنها تختلف قليلًا حسب الكوكيز، أو اللغة، أو نوع الجهاز. بدلاً من اعتبار الصفحة كاملة غير قابلة للتخزين، استخدم رأس Vary لتخبر CDN بتخزين نسخ منفصلة لكل حالة.
Vary: Accept-Language, Cookieكن حذرًا هنا. تغيير التخزين بناءً على Cookie دون تحديد نطاقه بدقة يمكن أن يضخّم الكاش إلى آلاف النسخ شبه المتطابقة، واحدة لكل جلسة فريدة، مما يُفقد الفكرة معناها. معظم شبكات CDN تتيح لك تحديد أسماء الكوكيز المهمة فعلًا، لذا اجعل التغيير مقتصرًا على تلك التي تؤثر فعلاً على الاستجابة، مثل تفضيل العملة أو اللغة، وليس كوكيز التتبع التحليلية.
قسّم الصفحات إلى أجزاء قابلة للتخزين وأخرى غير قابلة له
قد تكون صفحة منتج متطابقة بنسبة 95% لكل زائر، مع اختلاف بسيط في شريط "أهلاً بعودتك يا سارة" وعدد عناصر السلة فقط. بدلاً من جعل الصفحة كلها غير قابلة للتخزين، تلجأ فرق كثيرة إلى تخزين هيكل الصفحة عند الحافة (edge)، وتحميل الأجزاء الشخصية عبر طلب JavaScript بسيط من جهة العميل إلى نقطة API غير مخزنة. هذا النمط، الذي يُسمى أحيانًا edge-side includes أو client-side hydration، يتيح لـ CDN لتسريع الموقع أن يقوم بعمله على 95% من وزن الصفحة، بينما يصل الجزء الصغير الشخصي فقط إلى خادمك الأساسي.
حدد مدة صلاحية (TTL) منطقية بناءً على سرعة تغيّر المحتوى فعليًا
من الأخطاء الشائعة اختيار مدة صلاحية واحدة للموقع بأكمله. بدلاً من ذلك، اجعل مدة التخزين متناسبة مع مدى تغيّر كل نوع من المحتوى فعليًا:
- صور المنتجات وملفات CSS: خزّنها لمدة سنة، واستخدم أسماء ملفات مرقّمة بالإصدار
- مقالات المدونة والصفحات التسويقية: خزّنها لمدة 5-15 دقيقة مع stale-while-revalidate
- صفحات التصنيفات ونتائج البحث: خزّنها لمدة 60-120 ثانية
- بيانات الأسعار والمخزون: خزّنها لمدة 10-30 ثانية، أو قدّمها دون تخزين مع خادم أساسي سريع
- صفحات السلة، والدفع، والحساب: لا تخزّنها إطلاقًا
هذه الأرقام ليست قواعد عامة، بل نقطة انطلاق. راقب تحليلات CDN الخاصة بك لمعدل إصابة الكاش (cache hit ratio) لكل مسار. معدل إصابة أعلى من 80% على المحتوى القابل للتخزين يعني عادةً أن مدد الصلاحية تعمل بشكل جيد. إذا كان المسار أقل من 50%، فإما أن مدة الصلاحية قصيرة جدًا أو أن هذا المسار لا ينبغي تخزينه عند الحافة أصلًا.
امسح الكاش بدلاً من الانتظار
مدد الصلاحية القصيرة هي شبكة أمان، وليست استراتيجية. إذا نشرت مقالًا في المدونة أو حدّثت سعرًا، لا ينبغي أن تنتظر خمس دقائق حتى يلحق الكاش بالتحديث. تدعم معظم شبكات CDN المسح البرمجي، سواء عبر الرابط، أو عبر وسم (tag)، أو عبر نمط عام (wildcard). ربط هذا بسير عمل النشر لديك، بحيث يؤدي الضغط على "نشر" إلى إطلاق طلب مسح تلقائيًا، يعني أنه يمكنك ضبط مدد صلاحية أطول في كل مكان دون التضحية بالتحديث عندما يكون ذلك مهمًا فعلًا.
المسح بالوسوم أفضل من المسح بالروابط
إذا كان CDN يدعم وسوم الكاش (cache tags)، استخدمها. بدلاً من تتبع كل رابط يحتوي على جزء معين من المحتوى (منتج يظهر في صفحته الخاصة، وصفحة تصنيف، وشريط عرض في الصفحة الرئيسية)، يمكنك وسم الاستجابات الثلاث بـ product-1234 ومسح هذا الوسم الواحد فقط عند تحديث المنتج. إنها تكلفة إعداد بسيطة توفر عليك الكثير من التصحيح لاحقًا.
لا تنسَ جانب الخادم الأساسي في المعادلة
لا شيء من هذا يهم إذا كان خادمك الأساسي بطيئًا عندما يحتاج CDN فعلًا للتحقق منه. تخزين الكائنات (object caching) على خادمك، باستخدام أداة مثل Redis لحفظ نتائج استعلامات قاعدة البيانات في الذاكرة، يجعل عملية التحقق في الخلفية سريعة حتى على المسارات الشخصية أو شبه الديناميكية. نحن نشغّل هذا النوع من التخزين المؤقت تلقائيًا لمواقع WordPress على منصتنا، مع لوحة تحكم تعرض معدلات الإصابة الفعلية، بحيث يبقى الخادم الأساسي سريعًا حتى عندما لا يستطيع CDN المساعدة. للاطلاع على تفاصيل أكثر عمقًا حول ما يحدث بين CDN وخادمك، راجع كيف يغيّر CDN جغرافيا أداء موقعك.
يستحق الأمر أيضًا أن تفهم لماذا يؤثر زمن أول بايت (Time to First Byte) على معدلات التحويل، لأن كل حالة عدم إصابة في الكاش تعتمد في النهاية على سرعة استجابة خادمك الأساسي. وإذا كنت بصدد اختيار CDN من الأساس، فدليلنا عن اختيار شبكة CDN تغطي جمهورك فعلًا محطة جيدة تاليًا.
خلاصة الموضوع
التحديث المستمر والسرعة ليسا نقيضين، بل يُحلّان معًا بالتحديد الدقيق. خزّن بقوة حيث يكون المحتوى ثابتًا فعلًا، واستخدم مددًا قصيرة مع stale-while-revalidate حيث يتغير المحتوى تدريجيًا، ولا تخزّن أبدًا أي شيء مرتبط بجلسة أو سلة. أعدّ نظام مسح جيد حتى لا تعتمد فقط على مدد الصلاحية في اللحظات المهمة. اضبط قواعد caching هذه بشكل صحيح، وسيتوقف CDN لتسريع الموقع عن كونه صندوقًا أسود محفوفًا بالمخاطر، ويصبح أحد أكثر التحسينات موثوقية في الأداء يمكنك تحقيقها.
للتخزين المؤقت من جهة الخادم الذي يتكامل جيدًا مع هذا الإعداد، راجع نظرة عامة على التخزين المؤقت على مستوى الخادم أو اطّلع على كيف يعمل تخزين Redis المؤقت على الاستضافة المُدارة.
