إدارة سلوك ذاكرة التخزين المؤقت

تستخدم استضافة Firebase شبكة CDN عالمية قوية لجعل موقعك سريعًا قدر الإمكان.

يتم تخزين أي محتوى ثابت مطلوب تلقائيًا في ذاكرة التخزين المؤقت على شبكة CDN . إذا قمت بإعادة نشر محتوى موقعك، فستقوم استضافة Firebase تلقائيًا بمسح كل المحتوى المخزن مؤقتًا عبر شبكة CDN حتى الطلب التالي.

ومع ذلك، نظرًا لأن خدمات Cloud Functions وCloud Run تنشئ المحتوى ديناميكيًا، فقد يختلف محتوى عنوان URL المحدد بناءً على أشياء مثل إدخال المستخدم أو هوية المستخدم. ولمراعاة ذلك، لا يتم تخزين الطلبات التي تتم معالجتها بواسطة كود الواجهة الخلفية على شبكة CDN بشكل افتراضي.

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

يمكنك بالمثل تكوين سلوك التخزين المؤقت لتقليل تكاليف تنفيذ الوظيفة لأنه يتم تقديم المحتوى من CDN بدلاً من وظيفة تم تشغيلها. اقرأ المزيد حول تحسين تنفيذ الوظائف والخدمات في وثائق Cloud Functions و Cloud Run .

الاستثناء هو الطلبات التي تُرجع أخطاء 404. تقوم شبكة CDN بتخزين استجابة الخدمة 404 مؤقتًا لعنوان URL غير موجود لمدة 10 دقائق، بحيث يتم تقديم الطلبات اللاحقة لعنوان URL هذا خارج شبكة CDN. إذا قمت بتغيير الخدمة الخاصة بك بحيث يكون المحتوى موجودًا الآن على عنوان URL هذا، فستستمر شبكة CDN في تقديم أي رسائل 404 مخزنة مؤقتًا لمدة 10 دقائق (على الأكثر)، ثم تقدم المحتوى من عنوان URL هذا بشكل طبيعي.

إذا كانت الاستجابة 404 تحتوي بالفعل على رؤوس التخزين المؤقت التي تم تعيينها بواسطة Cloud Functions أو خدمة Cloud Run، فإنها تتجاوز الإعداد الافتراضي وهو 10 دقائق وتحدد سلوك التخزين المؤقت لشبكة CDN بشكل كامل.

تعرف على المزيد حول سلوك التخزين المؤقت في وثائق مطور الويب الخاصة بـ Google.

ضبط التحكم في ذاكرة التخزين المؤقت

الأداة الرئيسية التي تستخدمها لإدارة ذاكرة التخزين المؤقت للمحتوى الديناميكي هي رأس Cache-Control . من خلال تكوين هذا الرأس، يمكنك إبلاغ المتصفح وشبكة CDN بالمدة التي يمكن خلالها تخزين المحتوى الخاص بك مؤقتًا. في وظيفتك، يمكنك ضبط Cache-Control كما يلي:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

في هذا المثال للرأس، تقوم التوجيهات بثلاثة أشياء:

  • public - وضع علامة على ذاكرة التخزين المؤقت على أنها public . وهذا يعني أن كلاً من المتصفح والخوادم الوسيطة (أي CDN لاستضافة Firebase) يمكنها تخزين المحتوى مؤقتًا.

  • max-age - يخبر المتصفح وشبكة CDN بعدد الثواني التي يمكنهم تخزين المحتوى فيها مؤقتًا. عند انتهاء الوقت المحدد، يجب على المتصفح وشبكة CDN إعادة التحقق من صحة المحتوى مع الخادم الأصلي. في رأس المثال، نسمح للمتصفح وشبكة CDN بتخزين المحتوى مؤقتًا لمدة خمس دقائق (راجع s-maxage أدناه للحصول على عناصر تحكم محددة للتخزين المؤقت لـ CDN).

  • s-maxage — يتجاوز توجيه max-age للتخزين المؤقت لـ CDN فقط؛ يخبر CDN بعدد الثواني التي يمكنه تخزين المحتوى فيها مؤقتًا. عند انتهاء الوقت المحدد، يجب على CDN إعادة التحقق من صحة المحتوى مع الخادم الأصلي. في رأس المثال، نتجاوز إعداد max-age شبكة CDN فقط ونسمح لشبكة CDN بتخزين المحتوى مؤقتًا لمدة عشر دقائق.

بالنسبة إلى max-age و s-maxage ، قم بتعيين قيمهما على أطول فترة زمنية تشعر بالارتياح مع تلقي المستخدمين لمحتوى قديم. إذا تغيرت الصفحة كل بضع ثوانٍ، فاستخدم قيمة زمنية صغيرة. ومع ذلك، يمكن تخزين أنواع أخرى من المحتوى بشكل آمن مؤقتًا لساعات أو أيام أو حتى أشهر.

يمكنك معرفة المزيد حول رأس Cache-Control على شبكة مطوري Mozilla وفي وثائق مطوري الويب من Google.

متى يتم تقديم المحتوى المخزن مؤقتًا؟

يقوم المتصفح وشبكة CDN بتخزين المحتوى الخاص بك بناءً على:

  • اسم المضيف
  • الطريق
  • سلسلة الاستعلام
  • محتوى رؤوس الطلب المحددة في رأس Vary

تختلف الرؤوس

يحدد رأس Vary رؤوس الطلب التي يجب استخدامها لتوفير الاستجابة المناسبة (ما إذا كان المحتوى المخزن مؤقتًا صالحًا أو إذا كان يجب إعادة التحقق من صحة المحتوى باستخدام الخادم الأصلي).

تقوم استضافة Firebase تلقائيًا بتعيين رأس Vary المناسب على استجابتك للمواقف الشائعة. في معظم الأحيان، لا داعي للقلق بشأن رأس Vary . ومع ذلك، في بعض حالات الاستخدام المتقدمة، قد يكون لديك رؤوس أخرى تحتاجها للتأثير على ذاكرة التخزين المؤقت. في هذه الحالة، يمكنك تعيين رأس Vary على استجابتك. على سبيل المثال:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

في هذه الحالة، قيمة رأس Vary هي:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

باستخدام هذه الإعدادات، يتم تخزين طلبين متطابقين برؤوس X-My-Custom-Header مختلفة بشكل منفصل. لاحظ أن الاستضافة تضيف Cookie Authorization إلى رأس Vary بشكل افتراضي عند تقديم طلب لمحتوى ديناميكي. وهذا يضمن أن أي جلسة أو رأس ترخيص ملف تعريف الارتباط تستخدمه يصبح جزءًا من مفتاح ذاكرة التخزين المؤقت، مما يمنع التسريب غير المقصود للمحتوى.

لاحظ أيضًا:

  • يمكن تخزين طلبات GET و HEAD فقط مؤقتًا. لا يتم تخزين طلبات HTTPS التي تستخدم طرقًا أخرى في ذاكرة التخزين المؤقت مطلقًا.

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

استخدام ملفات تعريف الارتباط

عند استخدام استضافة Firebase مع Cloud Functions أو Cloud Run، يتم بشكل عام إزالة ملفات تعريف الارتباط من الطلبات الواردة. يعد هذا ضروريًا للسماح بسلوك ذاكرة التخزين المؤقت لـ CDN الفعال. يُسمح فقط لملف تعريف الارتباط __session المسمى خصيصًا بالمرور إلى تنفيذ تطبيقك.

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