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