يستخدم Firebase Hosting شبكة توصيل محتوى (CDN) عالمية فعّالة لجعل موقعك الإلكتروني سريعًا بقدر الإمكان.
يتم تخزين أي محتوى ثابت مطلوب تلقائيًا في ذاكرة التخزين المؤقت على شبكة توصيل المحتوى (CDN). في حال إعادة نشر محتوى موقعك الإلكتروني، يعمل Firebase Hosting تلقائيًا على محو كل المحتوى المخزّن مؤقتًا في شبكة توصيل المحتوى إلى أن يتم تقديم الطلب التالي.
ومع ذلك، بما أنّ خدمات Cloud Functions وCloud Run تنشئ محتوًى ديناميكيًا، يمكن أن يختلف محتوى عنوان URL معيّن استنادًا إلى عوامل مثل مدخلات المستخدم أو هويته. ولمعالجة هذه المشكلة، فإنّ الطلبات التي تتم معالجتها من خلال رمز الخلفية لا يتم تخزينها مؤقتًا في شبكة توصيل المحتوى (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
الأداة الرئيسية التي تستخدمها لإدارة ذاكرة التخزين المؤقت للمحتوى الديناميكي هي عنوان
Cache-Control
. من خلال ضبط هذا العنوان، يمكنك إبلاغ كل من المتصفّح وشبكة توصيل المحتوى (CDN) بمدة تخزين المحتوى في ذاكرة التخزين المؤقت. في الدالة،
يمكنك ضبط Cache-Control
على النحو التالي:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
في مثال العنوان هذا، تُنفِّذ التوجيهات ثلاثة إجراءات:
public
: يضع علامة على ذاكرة التخزين المؤقتpublic
. وهذا يعني أنّه يمكن للمتصفّح و الخوادم الوسيطة (أي شبكة توصيل المحتوى (CDN) لموقع Firebase Hosting) تخزين محتوى الويب في ذاكرة التخزين المؤقت.
max-age
: يُستخدم هذا المقياس لإعلام المتصفّح وشبكة توصيل المحتوى (CDN) بعدد الثواني التي يمكنهم فيها تخزين المحتوى مؤقتًا. عند انتهاء الوقت المحدّد، على المتصفّح وشبكة توصيل المحتوى إعادة التحقّق من صحة المحتوى مع خادم المصدر. في مثال العنوان، نسمح للمتصفّح وشبكة CDN بتخزين المحتوى مؤقتًا لمدة خمس دقائق (اطّلِع علىs-maxage
أدناه للاطّلاع على عناصر التحكّم المحدّدة لتخزين المحتوى مؤقتًا في شبكة CDN).
s-maxage
: تلغي توجيهmax-age
لميزة التخزين المؤقت في شبكة توصيل المحتوى فقط، وتُعلم شبكة توصيل المحتوى بعدد الثواني التي يمكنها خلالها تخزين المحتوى مؤقتًا. عند انتهاء المهلة المحدّدة، يجب أن تعيد شبكة توصيل المحتوى التحقّق من صحة المحتوى مع خادم المصدر. في مثال العنوان، يتم إلغاء الإعدادmax-age
لشبكة CDN فقط والسماح لشبكة CDN بتخزين المحتوى مؤقتًا لمدة عشر دقائق.
بالنسبة إلى max-age
وs-maxage
، اضبط قيمهما على أطول مدة
يناسبك أن يتلقّى المستخدمون خلالها محتوى قديمًا. إذا كانت الصفحة تتغيّر
كل بضع ثوانٍ، استخدِم قيمة زمنية صغيرة. ومع ذلك، يمكن تخزين أنواع أخرى من المحتوى في ذاكرة التخزين المؤقت بأمان لعدة ساعات أو أيام أو حتى شهور.
يمكنك الاطّلاع على مزيد من المعلومات حول عنوان Cache-Control
على
Mozilla Developer Network
ومستندات Google الخاصة بمطوّري الويب.
متى يتم عرض المحتوى المخزّن مؤقتًا؟
يخزّن المتصفّح وشبكة توصيل المحتوى (CDN) المحتوى الخاص بك استنادًا إلى ما يلي:
- اسم المضيف
- المسار
- سلسلة طلب البحث
- محتوى عناوين الطلب المحدّدة في عنوان
Vary
عناوين Vary
يحدِّد Vary
header
رؤوس الطلبات التي يجب استخدامها لتقديم
استجابة مناسبة (سواء كان المحتوى المخزّن مؤهّلاً أو يجب
إعادة التحقّق من صلاحيته مع خادم المصدر).
تضبط Firebase Hosting تلقائيًا عنوان 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
مختلفة بشكل منفصل في ذاكرة التخزين المؤقت. يُرجى العِلم أنّ Hosting تُضيف
Cookie
وAuthorization
إلى عنوان Vary
تلقائيًا عند تقديم طلب
للمحتوى الديناميكي. يضمن ذلك أنّ أي عنوان ملف تعريف ارتباط أو جلسة مصادقة
تستخدمه يصبح جزءًا من مفتاح ذاكرة التخزين المؤقت، ما يمنع تسرُّب محتوى
غير مقصود.
يُرجى العلم أيضًا بما يلي:
لا يمكن تخزين طلبات
GET
وHEAD
إلا في ذاكرة التخزين المؤقت. لا يتم الاحتفاظ بطلبات HTTPS التي تستخدم غيرها من الطرق في ذاكرة التخزين المؤقت.يُرجى توخي الحذر عند إضافة إعدادات إلى عنوان
Vary
. وكلما زاد عدد الإعدادات التي تضيفها، قلّ احتمال أن يتمكّن نظام توصيل المحتوى (CDN) من عرض المحتوى المخزّن مؤقتًا. تذكَّر أيضًا أنّVary
يستند إلى رؤوس الطلبات، وليس رؤوس الاستجابات.
استخدام ملفات تعريف الارتباط
عند استخدام Firebase Hosting مع Cloud Functions أو
Cloud Run، تتم إزالة ملفات تعريف الارتباط بشكل عام من الطلبات الواردة. هذا الإجراء ضروري للسماح بفعالية سلوك ذاكرة التخزين المؤقت في شبكة توصيل المحتوى (CDN).
لا يُسمح إلا بمرور ملف تعريف الارتباط __session
الذي يحمل اسمًا خاصًا من أجل
تنفيذ تطبيقك.
عند توفّر ملف تعريف الارتباط __session
، يتم تلقائيًا جعله جزءًا من مفتاح ملف التخزين المؤقت، ما يعني أنّه من المستحيل أن يتلقّى مستخدمان لديهما ملفات تعريف ارتباط مختلفة
الاستجابة المخزّنة مؤقتًا للمستخدم الآخر. لا تستخدِم ملف تعريف الارتباط __session
إلا إذا كان
تطبيقك يعرض محتوى مختلفًا استنادًا إلى تفويض المستخدم.