التخزين المؤقت لعامل الخدمات والتخزين المؤقت باستخدام بروتوكول HTTP

مزايا وعيوب استخدام منطق انتهاء صلاحية ثابت أو مختلف على مستوى ذاكرة التخزين المؤقت لعامل الخدمة وطبقات ذاكرة التخزين المؤقت لبروتوكول HTTP

Jonathan Chen

مع أنّ مهام الخدمة وتطبيقات الويب التقدمية أصبحت معايير لتطبيقات الويب الحديثة، أصبح تخزين الموارد مؤقتًا أكثر تعقيدًا من أي وقت مضى. تتناول هذه المقالة الصورة الكبيرة لتخزين المحتوى المؤقت في المتصفّح، بما في ذلك:

• حالات استخدام ذاكرة التخزين المؤقت لعامل الخدمة وذاكرة التخزين المؤقت لبروتوكول HTTP والاختلافات بينهما
• الإيجابيات والسلبيات لاستراتيجيات انتهاء صلاحية ذاكرة التخزين المؤقت لعامل الخدمة المختلفة مقارنةً باستراتيجيات ذاكرة التخزين المؤقت العادية لبروتوكول HTTP

نظرة عامة على عملية التخزين المؤقت

بشكل عام، يتّبع المتصفّح ترتيب التخزين المؤقت أدناه عند طلب مرجع:

1. ذاكرة التخزين المؤقت لخدمة Worker: يتحقّق Worker مما إذا كان المورد متوفرًا في ذاكرة التخزين المؤقت ويحدد ما إذا كان سيتم عرض المورد نفسه استنادًا إلى استراتيجيات التخزين المؤقت المبرمَجة. يُرجى العِلم أنّ هذا الإجراء لا يتم تلقائيًا. عليك إنشاء معالِج لحدث الجلب في عامل الخدمة واعتراض طلبات الشبكة حتى يتم عرض الطلبات من ذاكرة التخزين المؤقت لعامل الخدمة بدلاً من الشبكة.
2. ذاكرة التخزين المؤقت على بروتوكول HTTP (المعروفة أيضًا باسم ذاكرة التخزين المؤقت للمتصفّح): إذا تم العثور على المورد في ذاكرة التخزين المؤقت على بروتوكول HTTP ولم تنته صلاحيته بعد، يستخدم المتصفّح تلقائيًا المورد من ذاكرة التخزين المؤقت على بروتوكول HTTP.
3. من جهة الخادم: إذا لم يتم العثور على أي محتوى في ذاكرة التخزين المؤقت لخدمة Worker أو ذاكرة التخزين المؤقت لبروتوكول HTTP، ينتقل المتصفّح إلى الشبكة لطلب المورد. إذا لم يكن المورد محفوظًا مؤقتًا في شبكة توصيل المحتوى (CDN)، يجب أن يتم توجيه الطلب إلى خادم المصدر.

تخزين الطبقات مؤقتًا

التخزين المؤقت لمشغِّل الخدمات

يرصد عامل الخدمة طلبات HTTP من النوع "الشبكة" ويستخدم استراتيجية التخزين المؤقت لتحديد الموارد التي يجب عرضها في المتصفّح. تخدم ذاكرة التخزين المؤقت لخدمة Worker وذاكرة التخزين المؤقت لبروتوكول HTTP الغرض العام نفسه، ولكنّ ذاكرة التخزين المؤقت لخدمة Worker توفّر المزيد من إمكانات التخزين المؤقت، مثل التحكّم الدقيق في المحتوى الذي يتم تخزينه مؤقتًا وطريقة إجراء التخزين المؤقت.

التحكّم في ذاكرة التخزين المؤقت لخدمة Worker

يعترض عامل الخدمة طلبات HTTP باستخدام مستمعي الأحداث (عادةً الحدث fetch). يوضّح مقتطف الرمز هذا منطق استراتيجية ملف التخزين المؤقت Cache-First.

ننصح بشدة باستخدام Workbox لتجنُّب إعادة اختراع العجلة. على سبيل المثال، يمكنك تسجيل مسارات عناوين URL للموارد باستخدام سطر واحد من رمز التعبير العادي.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

استراتيجيات التخزين المؤقت في مهام الخدمة وحالات استخدامها

يوضِّح الجدول التالي استراتيجيات التخزين المؤقت الشائعة لعامل الخدمة والحالات التي تكون فيها كل استراتيجية مفيدة.

مزايا إضافية لتخزين الخدمة

بالإضافة إلى التحكّم الدقيق في منطق التخزين المؤقت، يوفّر التخزين المؤقت لمشغّل الخدمة أيضًا ما يلي:

• مساحة تخزين وذاكرة إضافية لمصدرك: يخصّص المتصفّح موارد التخزين المؤقت لبروتوكول HTTP على أساس كل مصدر. بعبارة أخرى، إذا كانت لديك عدة نطاقات فرعية، ستتشارك جميعها ذاكرة التخزين المؤقت لخدمة HTTP نفسها. لا يمكن أبدًا ضمان بقاء محتوى مصدرك/نطاقك في ذاكرة التخزين المؤقت لبروتوكول HTTP لفترة طويلة. على سبيل المثال، يمكن للمستخدم تنظيف ذاكرة التخزين المؤقت يدويًا من واجهة مستخدم إعدادات المتصفّح، أو بدء إعادة تحميل صفحات الويب. باستخدام ذاكرة التخزين المؤقت لخدمة عامل الخدمة، تزداد احتمالية بقاء المحتوى المخزّن مؤقتًا في الذاكرة. اطّلِع على مساحة التخزين الدائمة لمعرفة المزيد من المعلومات.
• مرونة أكبر في الشبكات غير المستقرة أو التجارب بلا إنترنت: باستخدام ذاكرة التخزين المؤقت لبروتوكول HTTP، لن يكون لديك سوى خيار ثنائي: إما تخزين المورد في ذاكرة التخزين المؤقت أو عدم تخزينه. باستخدام ميزة التخزين المؤقت لعامل الخدمة، يمكنك تخفيف بعض "المشاكل البسيطة" بسهولة أكبر (باستخدام استراتيجية "البيانات القديمة أثناء إعادة التحقق من الصحة")، وتقديم تجربة كاملة بلا إنترنت (باستخدام استراتيجية "الخزين فقط") أو حتى إجراء ما بين هذين الخيارين، مثل واجهات مستخدم مخصّصة تتضمّن أجزاء من الصفحة تأتي من ذاكرة التخزين المؤقت لعامل الخدمة وبعض الأجزاء المستبعَدة (باستخدام استراتيجية "ضبط معالِج الأخطاء") عند الاقتضاء.

التخزين المؤقت لبروتوكول HTTP

في المرة الأولى التي يحمّل فيها المتصفّح صفحة ويب والموارد ذات الصلة، يخزّن هذه الموارد في ملف التخزين المؤقت لبروتوكول HTTP. تفعِّل المتصفّحات عادةً ذاكرة التخزين المؤقت لبروتوكول HTTP تلقائيًا، ما لم يتم إيقافها صراحةً من قِبل المستخدم النهائي.

يعني استخدام ميزة التخزين المؤقت في HTTP الاعتماد على الخادم لتحديد وقت تخزين مورد معيّن مؤقتًا ومدّة ذلك.

التحكّم في انتهاء صلاحية ذاكرة التخزين المؤقت في HTTP باستخدام عناوين استجابة HTTP

عندما يستجيب الخادم لطلب متصفّح للحصول على مورد، يستخدم الخادم رؤوس استجابة HTTP لتحديد المدة التي يجب أن يحتفظ فيها المتصفّح بالمورد في ذاكرة التخزين المؤقت. اطّلِع على رؤوس الاستجابة: ضبط ملف تكوين الخادم لمعرفة المزيد.

استراتيجيات التخزين المؤقت في HTTP وحالات الاستخدام

إنّ ميزة التخزين المؤقت لبروتوكول HTTP أبسط بكثير من ميزة التخزين المؤقت لمشغّل الخدمة، لأنّ ميزة التخزين المؤقت لبروتوكول HTTP لا تتعامل إلا مع منطق انتهاء صلاحية المورد المستنِد إلى الوقت (TTL). اطّلِع على ما هي قيم عناوين الاستجابة التي يجب استخدامها؟ والملخّص لمعرفة المزيد من المعلومات عن استراتيجيات التخزين المؤقت لبروتوكول HTTP.

تصميم منطق انتهاء صلاحية ذاكرة التخزين المؤقت

يوضّح هذا القسم مزايا وعيوب استخدام منطق انتهاء صلاحية متّسق على مستوى ذاكرة التخزين المؤقت لعامل الخدمة وطبقات ذاكرة التخزين المؤقت لبروتوكول HTTP، بالإضافة إلى مزايا وعيوب منطق انتهاء الصلاحية المنفصل على مستوى هذه الطبقات.

يوضّح Glitch أدناه كيفية عمل ميزة التخزين المؤقت لعامل الخدمة وميزة التخزين المؤقت لبروتوكول HTTP في سيناريوهات مختلفة:

منطق انتهاء صلاحية متّسق لجميع طبقات ذاكرة التخزين المؤقت

لتوضيح الإيجابيات والسلبيات، سننظر في 3 سيناريوهات: على المدى الطويل والمتوسط والقصير.

السيناريو: التخزين المؤقت على المدى الطويل (التخزين المؤقت، الرجوع إلى الشبكة)

• عندما يكون المورد المخزَّن مؤقتًا صالحًا (<= 30 يومًا): يعرض عامل الخدمة المورد المُخزَّن على الفور بدون الاتصال بالشبكة.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت (> 30 يومًا): يتصل عامل الخدمة بالشبكة ل retrieving the resource. لا يتضمّن المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى الخادم للحصول على المورد.

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

السيناريو: التخزين المؤقت على المدى المتوسط (Stale-while-revalidate)

• عندما يكون المورد المخزّن مؤهّلاً (<= يوم واحد): يعرض عامل الخدمة المورد المُخزّن على الفور، وينتقل إلى الشبكة لتحميل المورد. يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يعرض هذه النسخة لمشغّل الخدمة.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت (> يوم واحد): يعرض عامل الخدمة المورد المحفوظ في ذاكرة التخزين المؤقت على الفور، وينتقل إلى الشبكة لتحميل المورد. لا يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى الخادم لتحميل المورد.

العيب: يتطلّب مشغّل الخدمة ميزة إضافية لإزالة ذاكرة التخزين المؤقت من أجل إلغاء ذاكرة التخزين المؤقت لبروتوكول HTTP للاستفادة إلى أقصى حد من خطوة "إعادة التحقّق من الصحة".

السيناريو: التخزين المؤقت على المدى القصير (الشبكة تعود إلى ذاكرة التخزين المؤقت)

• عندما يكون المورد المخزّن مؤهّلاً (<= 10 دقائق): ينتقل عامل الخدمة إلى الشبكة لاسترداد المورد. يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يعرضه على مشغّل الخدمة بدون الانتقال إلى الخادم.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت (> 10 دقائق): يعرض عامل الخدمة المورد المحفوظ في ذاكرة التخزين المؤقت على الفور، وينتقل إلى الشبكة لتحميل المورد. لا يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى الخادم لتحميل المورد.

العيوب: على غرار سيناريو التخزين المؤقت على المدى المتوسط، يتطلّب مشغّل الخدمة مزيدًا من منطق إلغاء ذاكرة التخزين المؤقت لإلغاء ذاكرة التخزين المؤقت لبروتوكول HTTP من أجل جلب أحدث مورد من جانب الخادم.

Service worker في جميع السيناريوهات

في جميع السيناريوهات، يمكن أن تستمر ذاكرة التخزين المؤقت لمشغّل الخدمة في عرض الموارد المخزّنة مؤقتًا عندما تكون الشبكة غير مستقرة. من ناحية أخرى، لا يمكن الاعتماد على ذاكرة التخزين المؤقت لبروتوكول HTTP عندما تكون الشبكة غير مستقرة أو غير متاحة.

منطق مختلف لانتهاء صلاحية ذاكرة التخزين المؤقت في طبقتَي ذاكرة التخزين المؤقت لعامل الخدمة وHTTP

لتوضيح إيجابيات الإجراء وسلبياته، سننظر مرة أخرى في سيناريوهات الأجل الطويل والمتوسط والقصير.

السيناريو: التخزين المؤقت على المدى الطويل (التخزين المؤقت، الرجوع إلى الشبكة)

• عندما يكون المرجع المخزّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت لمشغّل الخدمة (<= 90 يومًا): يعرض مشغّل الخدمة المرجع المخزّن مؤقتًا على الفور.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت لخدمة worker (> 90 يومًا): ينتقل service worker إلى الشبكة لجلب المورد. لا يتضمّن المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يتم نقله إلى جهة الخادم.

الإيجابيات والسلبيات

• المزايا: يحصل المستخدمون على استجابة فورية لأنّ الخدمة العاملة تعرض الموارد المخزّنة مؤقتًا على الفور.
• المزايا: يمكن لعامل الخدمة التحكّم بشكل أدق في وقت استخدام ذاكرة التخزين المؤقت ووقت طلب إصدارات جديدة من الموارد.
• العيب: يجب تحديد استراتيجية تخزين مؤقت لمشغّل الخدمة بشكل جيد.

السيناريو: التخزين المؤقت على المدى المتوسط (Stale-while-revalidate)

• عندما يكون المورد المخزّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت لمشغّل الخدمة (<= 30 يومًا): يعرض مشغّل الخدمة المورد المخزّن مؤقتًا على الفور.
• عند انتهاء صلاحية أحد الموارد المخزّنة مؤقتًا في ذاكرة التخزين المؤقت لخدمة worker (> 30 يومًا): يتصل لخدمة worker بالشبكة للحصول على المورد. لا يتضمّن المتصفّح نسخة من المورد في ملف التخزين المؤقت لبروتوكول HTTP، لذا يتم إرسال الطلب من جهة الخادم.

الإيجابيات والسلبيات

• المزايا: يحصل المستخدمون على استجابة فورية لأنّ الخدمة العاملة تعرض الموارد المخزّنة مؤقتًا على الفور.
• الإيجابيات: يمكن لعامل الخدمة ضمان أنّ الطلب القادم لعنوان URL معيّن يستخدم استجابة جديدة من الشبكة، وذلك بفضل إعادة التحقّق التي تتم "في الخلفية".
• العيب: يجب تحديد استراتيجية تخزين مؤقت لمشغّل الخدمة بشكل جيد.

السيناريو: التخزين المؤقت على المدى القصير (الشبكة تعود إلى ذاكرة التخزين المؤقت)

• عندما يكون المورد المخزّن مؤهّلاً في ذاكرة التخزين المؤقت لخدمة worker (أقل من يوم واحد): ينتقل لخدمة worker إلى الشبكة للحصول على المورد. يعرض المتصفّح المورد من ملف التخزين المؤقت لبروتوكول HTTP إذا كان متوفّرًا. في حال انقطاع الاتصال بالشبكة، يعرض مشغّل الخدمة المورد من ملف التخزين المؤقت الخاص به.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت لخدمة worker (> يوم واحد): يتصل لخدمة worker بالشبكة لتحميل المورد. يُجلب المتصفّح الموارد عبر الشبكة لأنّ النسخة المخزّنة مؤقتًا في ذاكرة التخزين المؤقت لبروتوكول HTTP قد انتهت صلاحيتها.

الإيجابيات والسلبيات

• المزايا: عندما تكون الشبكة غير مستقرة أو متوقّفة، يعرض عامل الخدمة موارد التخزين المؤقت على الفور.
• العيب: يتطلّب مشغّل الخدمة ميزة إضافية لإلغاء ميزة التخزين المؤقت في HTTP و تقديم طلبات "الشبكة أولاً".

الخاتمة

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

• لا يلزم أن يكون منطق التخزين المؤقت لعامل الخدمة متناسقًا مع منطق انتهاء صلاحية التخزين المؤقت لبروتوكول HTTP. استخدِم منطق انتهاء صلاحية أطول في مشغّل الخدمة إن أمكن، وذلك لمنحه مزيدًا من التحكّم.
• لا يزال التخزين المؤقت لبروتوكول HTTP يلعب دورًا مهمًا، ولكنّه غير موثوق به عندما تكون الشبكة غير مستقرة أو متوقّفة.
• راجِع استراتيجيات التخزين المؤقت لكل مورد للتأكّد من أنّ استراتيجية التخزين المؤقت لعامل الخدمة توفّر قيمتها بدون تعارض مع ذاكرة التخزين المؤقت لبروتوكول HTTP.

مزيد من المعلومات

• موثوقية الشبكة
• منع الطلبات غير الضرورية من الشبكة باستخدام ذاكرة التخزين المؤقت عبر HTTP
• دورة تدريبية حول رمز ذاكرة التخزين المؤقت لبروتوكول HTTP
• قياس تأثير أداء خدمات Worker في الاستخدام الفعلي
• Cache-Control مقارنةً بـ Expires
• معلومات حول ذاكرة التخزين المؤقت: فحص ذاكرات التخزين المؤقت ومحو بياناتها وإيقافها