إيجابيات وسلبيات استخدام منطق انتهاء صلاحية متسق أو مختلف في طبقات ذاكرة التخزين المؤقت لعامل الخدمة وذاكرة التخزين المؤقت لبروتوكول HTTP
مع أنّ تقنيات "مشغّل الخدمات" و"تطبيقات الويب التقدّمية" أصبحت من معايير تطبيقات الويب الحديثة، أصبح تخزين الموارد مؤقتًا أكثر تعقيدًا من أي وقت مضى. تتناول هذه المقالة الصورة الكبيرة للتخزين المؤقت في المتصفّح، بما في ذلك:
- حالات الاستخدام والاختلافات بين التخزين المؤقت لبرنامج الخدمة والتخزين المؤقت لبروتوكول HTTP
- إيجابيات وسلبيات استراتيجيات انتهاء صلاحية التخزين المؤقت المختلفة لـ Service Worker مقارنةً باستراتيجيات التخزين المؤقت العادية في HTTP
نظرة عامة على عملية التخزين المؤقت
على مستوى عالٍ، يتّبع المتصفّح ترتيب التخزين المؤقت أدناه عندما يطلب موردًا:
- ذاكرة التخزين المؤقت لمشغّل الخدمات: يتحقّق مشغّل الخدمات مما إذا كان المورد متوفّرًا في ذاكرة التخزين المؤقت الخاصة به، ويقرّر ما إذا كان سيعرض المورد نفسه استنادًا إلى استراتيجيات التخزين المؤقت المبرمَجة. لاحظ أن هذا لا يحدث تلقائيًا. عليك إنشاء معالج أحداث جلب في مشغّل الخدمات واعتراض طلبات الشبكة ليتم عرض الطلبات من ذاكرة التخزين المؤقت لمشغّل الخدمات بدلاً من الشبكة.
- ذاكرة التخزين المؤقت لبروتوكول HTTP (المعروفة أيضًا باسم ذاكرة التخزين المؤقت للمتصفّح): إذا تم العثور على المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP ولم تنتهِ صلاحيته بعد، يستخدم المتصفّح تلقائيًا المورد من ذاكرة التخزين المؤقت لبروتوكول HTTP.
- جهة الخادم: إذا لم يتم العثور على أي محتوى في ذاكرة التخزين المؤقت لمشغّل الخدمات أو ذاكرة التخزين المؤقت لبروتوكول HTTP، ينتقل المتصفّح إلى الشبكة لطلب المورد. إذا لم يتم تخزين المورد مؤقتًا في شبكة توصيل المحتوى، يجب أن يعود الطلب إلى خادم المصدر.
طبقات التخزين المؤقت
التخزين المؤقت لمشغّل الخدمات
يعترض مشغّل الخدمات طلبات HTTP من نوع الشبكة ويستخدم استراتيجية تخزين مؤقت لتحديد الموارد التي يجب عرضها للمتصفّح. تخدم ذاكرة التخزين المؤقت لمشغّل الخدمات وذاكرة التخزين المؤقت لبروتوكول HTTP الغرض العام نفسه، ولكن توفّر ذاكرة التخزين المؤقت لمشغّل الخدمات المزيد من إمكانات التخزين المؤقت، مثل التحكّم الدقيق في ما يتم تخزينه مؤقتًا بالضبط وكيفية إجراء التخزين المؤقت.
التحكّم في ذاكرة التخزين المؤقت لمشغّل الخدمات
يعترض مشغّل الخدمات طلبات HTTP باستخدام متتبِّعات الأحداث (عادةً الحدث fetch). يوضّح مقتطف الرمز هذا منطق استراتيجية التخزين المؤقت "التخزين المؤقت أولاً".
ننصح بشدة باستخدام Workbox لتجنُّب إعادة ابتكار العجلة. على سبيل المثال، يمكنك تسجيل مسارات عناوين URL للموارد باستخدام سطر واحد من رمز التعبير العادي.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
استراتيجيات التخزين المؤقت لـ Service Worker وحالات الاستخدام
يوضّح الجدول التالي استراتيجيات التخزين المؤقت الشائعة لبرامج الخدمة والحالات التي تكون فيها كل استراتيجية مفيدة.
| الاستراتيجيات | السبب المتعلّق بالحداثة | حالات الاستخدام |
|---|---|---|
| الشبكة فقط | يجب أن يكون المحتوى محدّثًا في جميع الأوقات. |
|
| الشبكة تعود إلى ذاكرة التخزين المؤقت | من الأفضل عرض المحتوى الجديد. ومع ذلك، إذا تعذّر الاتصال بالشبكة أو كان الاتصال غير مستقر، من المقبول عرض محتوى قديم بعض الشيء. |
|
| Stale-while-revalidate | لا بأس بعرض المحتوى المخزَّن مؤقتًا على الفور، ولكن يجب استخدام المحتوى المخزَّن مؤقتًا والمعدَّل في المستقبل. |
|
| استخدام ذاكرة التخزين المؤقت أولاً، ثم الرجوع إلى الشبكة | المحتوى ليس بالغ الأهمية ويمكن عرضه من ذاكرة التخزين المؤقت لتحسين الأداء، ولكن يجب أن يتحقّق مشغّل الخدمات من التحديثات من حين لآخر. |
|
| ذاكرة التخزين المؤقت فقط | نادرًا ما يتغيّر المحتوى. |
|
مزايا إضافية للتخزين المؤقت في مشغّل الخدمات
بالإضافة إلى التحكّم الدقيق في منطق التخزين المؤقت، يوفّر التخزين المؤقت لعاملي الخدمة أيضًا ما يلي:
- مزيد من الذاكرة ومساحة التخزين لمصدرك: يخصّص المتصفّح موارد ذاكرة التخزين المؤقت لبروتوكول HTTP لكل مصدر. بعبارة أخرى، إذا كانت لديك نطاقات فرعية متعددة، ستتشارك جميعها ذاكرة التخزين المؤقت نفسها لبروتوكول HTTP. ما مِن ضمانات بأنّ محتوى المصدر/النطاق سيبقى في ذاكرة التخزين المؤقت لبروتوكول HTTP لفترة طويلة. على سبيل المثال، قد يمحو المستخدم ذاكرة التخزين المؤقت من خلال تنظيفها يدويًا من واجهة مستخدم إعدادات المتصفّح أو إعادة تحميل الصفحة بشكل كامل. باستخدام ذاكرة التخزين المؤقت لـ Service Worker، تزداد احتمالية بقاء المحتوى المخزَّن مؤقتًا في الذاكرة. لمزيد من المعلومات، يُرجى الاطّلاع على مساحة التخزين الدائمة.
- مرونة أكبر في التعامل مع الشبكات غير المستقرة أو التجارب بلا إنترنت: باستخدام ذاكرة التخزين المؤقت لبروتوكول HTTP، يكون لديك خيار ثنائي فقط: إما أن يتم تخزين المورد مؤقتًا أو لا. باستخدام التخزين المؤقت في مشغّل الخدمات، يمكنك تخفيف "المشاكل" البسيطة بسهولة أكبر (باستخدام استراتيجية "stale-while-revalidate")، أو تقديم تجربة كاملة بلا إنترنت (باستخدام استراتيجية "التخزين المؤقت فقط") أو حتى تجربة تجمع بين الاثنين، مثل واجهات المستخدم المخصّصة التي تتضمّن أجزاء من الصفحة واردة من ذاكرة التخزين المؤقت لمشغّل الخدمات وبعض الأجزاء المستبعَدة (باستخدام استراتيجية "ضبط معالج الالتقاط") حيثما كان ذلك مناسبًا.
التخزين المؤقت عبر HTTP
عندما يحمّل المتصفّح صفحة ويب والموارد ذات الصلة للمرة الأولى، يخزّن هذه الموارد في ذاكرة التخزين المؤقت لبروتوكول HTTP. يتم عادةً تفعيل ذاكرة التخزين المؤقت لبروتوكول HTTP تلقائيًا من خلال المتصفّحات، ما لم يتم إيقافها صراحةً من قِبل المستخدم النهائي.
يعني استخدام التخزين المؤقت عبر HTTP الاعتماد على الخادم لتحديد وقت تخزين المورد مؤقتًا ومدة تخزينه.
التحكّم في انتهاء صلاحية ذاكرة التخزين المؤقت لبروتوكول HTTP باستخدام عناوين استجابة HTTP
عندما يستجيب خادم لطلب متصفّح للحصول على مورد، يستخدم الخادم عناوين استجابة HTTP لإعلام المتصفّح بالمدة التي يجب أن يخزّن فيها المورد مؤقتًا. لمزيد من المعلومات، يمكنك الاطّلاع على عناوين الاستجابة: ضبط خادم الويب.
استراتيجيات التخزين المؤقت لبروتوكول HTTP وحالات الاستخدام
يُعدّ التخزين المؤقت لبروتوكول HTTP أبسط بكثير من التخزين المؤقت لمشغّل الخدمات، لأنّ التخزين المؤقت لبروتوكول HTTP يتعامل فقط مع منطق انتهاء صلاحية الموارد المستند إلى الوقت (TTL). يمكنك الاطّلاع على قيم عناوين الاستجابة التي يجب استخدامها ومنع طلبات الشبكة غير الضرورية باستخدام ذاكرة التخزين المؤقت لبروتوكول HTTP (ملخّص) لمعرفة المزيد حول استراتيجيات التخزين المؤقت لبروتوكول HTTP.
تصميم منطق انتهاء صلاحية ذاكرة التخزين المؤقت
يشرح هذا القسم إيجابيات وسلبيات استخدام منطق انتهاء صلاحية متّسق في طبقات ذاكرة التخزين المؤقت لبرنامج الخدمة وذاكرة التخزين المؤقت لبروتوكول HTTP، بالإضافة إلى إيجابيات وسلبيات منطق انتهاء الصلاحية المنفصل في هذه الطبقات.
منطق انتهاء صلاحية متّسق لجميع طبقات ذاكرة التخزين المؤقت
لتوضيح الإيجابيات والسلبيات، سنلقي نظرة على 3 سيناريوهات: على المدى الطويل والمتوسط والقصير.
| السيناريوهات | التخزين المؤقّت الطويل الأجل | التخزين المؤقت على المدى المتوسط | التخزين المؤقّت القصير الأجل |
|---|---|---|---|
| استراتيجية التخزين المؤقت لمشغّل الخدمات | ذاكرة التخزين المؤقت، الرجوع إلى الشبكة | Stale-while-revalidate | الشبكة تعود إلى ذاكرة التخزين المؤقت |
| مدة البقاء (TTL) في ذاكرة التخزين المؤقت لمشغّل الخدمات | 30 يومًا | يوم واحد | 10 دقائق |
| الحد الأقصى لعمر ذاكرة التخزين المؤقت عبر HTTP | 30 يومًا | يوم واحد | 10 دقائق |
السيناريو: التخزين المؤقت الطويل الأجل (التخزين المؤقت، والرجوع إلى الشبكة)
- عندما يكون المورد المخزَّن مؤقتًا صالحًا (أقل من أو يساوي 30 يومًا): يعرض مشغّل الخدمات المورد المخزَّن مؤقتًا على الفور بدون الانتقال إلى الشبكة.
- عند انتهاء صلاحية مورد مخزَّن مؤقتًا (بعد أكثر من 30 يومًا): ينتقل مشغّل الخدمات إلى الشبكة لجلب المورد. لا يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم للحصول على المورد.
السلبيات: في هذا السيناريو، يقدّم التخزين المؤقت لبروتوكول HTTP قيمة أقل لأنّ المتصفّح سيمرّر الطلب دائمًا إلى جهة الخادم عند انتهاء صلاحية ذاكرة التخزين المؤقت في مشغّل الخدمات.
السيناريو: التخزين المؤقت على المدى المتوسط (stale-while-revalidate)
- عندما يكون المورد المخزَّن مؤقتًا صالحًا (لمدة يوم واحد أو أقل): يعرض مشغّل الخدمات المورد المخزَّن مؤقتًا على الفور، وينتقل إلى الشبكة لاسترجاع المورد. يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يعرض هذه النسخة إلى مشغّل الخدمات.
- عند انتهاء صلاحية مورد مخزّن مؤقتًا (أكثر من يوم واحد): يعرض مشغّل الخدمات المورد المخزّن مؤقتًا على الفور، وينتقل إلى الشبكة لجلب المورد. لا يتوفّر لدى المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم لجلب المورد.
السلبيات: يتطلّب مشغّل الخدمات استخدام تقنية إضافية لتجاوز ذاكرة التخزين المؤقت من أجل تجاوز ذاكرة التخزين المؤقت لبروتوكول HTTP من أجل الاستفادة إلى أقصى حد من خطوة "إعادة التحقّق".
السيناريو: التخزين المؤقت القصير المدى (الشبكة تعود إلى ذاكرة التخزين المؤقت)
- عندما يكون المورد المخزَّن مؤقتًا صالحًا (أقل من أو يساوي 10 دقائق): ينتقل مشغّل الخدمات إلى الشبكة لاسترجاع المورد. يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يعرضها لمشغّل الخدمات بدون الانتقال إلى جهة الخادم.
- عند انتهاء صلاحية مورد مخزَّن مؤقتًا (أكثر من 10 دقائق): يعرض مشغّل الخدمات المورد المخزَّن مؤقتًا على الفور، وينتقل إلى الشبكة لجلب المورد. لا يتوفّر لدى المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم لجلب المورد.
السلبيات: على غرار سيناريو التخزين المؤقت على المدى المتوسط، يتطلّب مشغّل الخدمات منطقًا إضافيًا لتجاوز ذاكرة التخزين المؤقت من أجل إلغاء ذاكرة التخزين المؤقت لبروتوكول HTTP وجلب أحدث الموارد من جهة الخادم.
عامل الخدمة في جميع السيناريوهات
في جميع السيناريوهات، يمكن لذاكرة التخزين المؤقت لمشغّل الخدمات عرض الموارد المخزّنة مؤقتًا عندما تكون الشبكة غير مستقرة. من ناحية أخرى، لا يمكن الاعتماد على ذاكرة التخزين المؤقت لبروتوكول HTTP عندما تكون الشبكة غير مستقرة أو معطّلة.
منطق انتهاء صلاحية ذاكرة التخزين المؤقت مختلف في طبقات HTTP وذاكرة التخزين المؤقت لـ Service Worker
لتوضيح الإيجابيات والسلبيات، سنلقي نظرة مرة أخرى على السيناريوهات طويلة الأجل ومتوسطة الأجل وقصيرة الأجل.
| السيناريوهات | التخزين المؤقّت الطويل الأجل | التخزين المؤقت على المدى المتوسط | التخزين المؤقّت القصير الأجل |
|---|---|---|---|
| استراتيجية التخزين المؤقت لمشغّل الخدمات | ذاكرة التخزين المؤقت، الرجوع إلى الشبكة | Stale-while-revalidate | الشبكة تعود إلى ذاكرة التخزين المؤقت |
| مدة البقاء (TTL) في ذاكرة التخزين المؤقت لمشغّل الخدمات | 90 يومًا | 30 يومًا | يوم واحد |
| الحد الأقصى لعمر ذاكرة التخزين المؤقت عبر HTTP | 30 يومًا | يوم واحد | 10 دقائق |
السيناريو: التخزين المؤقت الطويل الأجل (التخزين المؤقت، والرجوع إلى الشبكة)
- عندما يكون المورد المخزَّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت لمشغّل الخدمات (أقل من أو يساوي 90 يومًا): يعرض مشغّل الخدمات المورد المخزَّن مؤقتًا على الفور.
- عند انتهاء صلاحية مورد مخزّن مؤقتًا في ذاكرة التخزين المؤقت لـ Service Worker (أكثر من 90 يومًا): ينتقل Service Worker إلى الشبكة لجلب المورد. لا يتوفّر لدى المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم.
الإيجابيات والسلبيات
- المزايا: يحصل المستخدمون على استجابة فورية لأنّ مشغّل الخدمات يعرض الموارد المخزّنة مؤقتًا على الفور.
- الميزة: يمتلك مشغّل الخدمات تحكّمًا أكثر دقة في وقت استخدام ذاكرة التخزين المؤقت ووقت طلب إصدارات جديدة من الموارد.
- السلبيات: يجب وضع استراتيجية واضحة لتخزين البيانات مؤقتًا في مشغّل الخدمات.
السيناريو: التخزين المؤقت على المدى المتوسط (stale-while-revalidate)
- عندما يكون المورد المخزَّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت لمشغّل الخدمات (لمدة 30 يومًا أو أقل): يعرض مشغّل الخدمات المورد المخزَّن مؤقتًا على الفور.
- عند انتهاء صلاحية مورد مخزَّن مؤقتًا في ذاكرة التخزين المؤقت لـ Service Worker (بعد أكثر من 30 يومًا): ينتقل Service Worker إلى الشبكة للحصول على المورد. لا يتوفّر لدى المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم.
الإيجابيات والسلبيات
- المزايا: يحصل المستخدمون على استجابة فورية لأنّ مشغّل الخدمات يعرض الموارد المخزّنة مؤقتًا على الفور.
- الإيجابيات: يمكن لبرنامج الخدمة التأكّد من أنّ الطلب التالي لعنوان URL معيّن يستخدم استجابة جديدة من الشبكة، وذلك بفضل إعادة التحقّق التي تحدث "في الخلفية".
- السلبيات: يجب وضع استراتيجية واضحة لتخزين البيانات مؤقتًا في مشغّل الخدمات.
السيناريو: التخزين المؤقت القصير المدى (الشبكة تعود إلى ذاكرة التخزين المؤقت)
- عندما يكون المورد المخزَّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت الخاصة بنصوص مشغِّل الخدمات البرمجية (<= يوم واحد): ينتقل مشغِّل الخدمات البرمجية إلى الشبكة للحصول على المورد. يعرض المتصفّح المورد من ذاكرة التخزين المؤقت لبروتوكول HTTP إذا كان متوفّرًا فيها. إذا كانت الشبكة معطّلة، يعرض مشغّل الخدمات المورد من ذاكرة التخزين المؤقت لمشغّل الخدمات
- عند انتهاء صلاحية مورد مخزّن مؤقتًا في ذاكرة التخزين المؤقت لبرنامج الخدمة (> يوم واحد): ينتقل برنامج الخدمة إلى الشبكة لجلب المورد. يجلب المتصفّح الموارد عبر الشبكة لأنّ النسخة المخزّنة مؤقتًا في ذاكرة التخزين المؤقت لبروتوكول HTTP قد انتهت صلاحيتها.
الإيجابيات والسلبيات
- المزايا: عندما تكون الشبكة غير مستقرة أو معطّلة، يعرض مشغّل الخدمات الموارد المخزّنة مؤقتًا على الفور.
- السلبيات: يتطلّب مشغّل الخدمات استخدام ميزة "إبطال ذاكرة التخزين المؤقت" الإضافية لتجاوز ذاكرة التخزين المؤقت لبروتوكول HTTP وإرسال طلبات "الشبكة أولاً".
الخاتمة
نظرًا لتعقيد مجموعة سيناريوهات التخزين المؤقت، لا يمكن تصميم قاعدة واحدة تغطي جميع الحالات. ومع ذلك، استنادًا إلى النتائج الواردة في الأقسام السابقة، هناك بعض الاقتراحات التي يجب مراعاتها عند تصميم استراتيجيات التخزين المؤقت:
- ليس من الضروري أن يكون منطق التخزين المؤقت في مشغّل الخدمات متوافقًا مع منطق انتهاء صلاحية التخزين المؤقت عبر HTTP. إذا أمكن، استخدِم منطق انتهاء صلاحية أطول في مشغّل الخدمات لمنحه مزيدًا من التحكّم.
- لا يزال التخزين المؤقت لبروتوكول HTTP يؤدي دورًا مهمًا، ولكنه غير موثوق به عندما تكون الشبكة غير مستقرة أو معطّلة.
- راجِع استراتيجيات التخزين المؤقت لكل مورد للتأكّد من أنّ استراتيجية التخزين المؤقت في مشغّل الخدمات تقدّم قيمتها، بدون أن تتعارض مع ذاكرة التخزين المؤقت لبروتوكول HTTP.