الإعداد المسبق باستخدام Workbox

جيف بوسنيك

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

لماذا يجب عليك استخدام Workbox؟

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

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

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

[{
  url: 'app.abcd1234.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

بعد تثبيت مشغّل الخدمات، يتم إنشاء ثلاثة إدخالات لذاكرة التخزين المؤقت في مساحة تخزين ذاكرة التخزين المؤقت، لكل عنوان من عناوين URL الثلاثة المدرجة. تحتوي مادة العرض الأولى على معلومات تحديد الإصدارات مضمّنة مسبقًا في عنوان URL الخاص بها (يمثل app اسم الملف الفعلي، ويحتوي .abcd1234 على معلومات تحديد الإصدارات قبل امتداد الملف .js مباشرةً). يمكن لأدوات تصميم Workspace اكتشاف ذلك واستبعاد حقل مراجعة. لا تتضمّن مادتا العرض الأخريان أي معلومات حول الإصدارات في عناوين URL الخاصة بهما، لذا تنشئ أدوات إنشاء Workbox حقل revision منفصلاً يحتوي على تجزئة من محتوى الملف المحلي.

عرض الموارد المخزنة مؤقتًا بشكل مسبق

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

التحديثات الفعّالة

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

تعديلات على الموارد التي تم تخزينها مؤقتًا بشكل مسبق

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

إذا كان هناك عنوان URL حالي يحتوي على حقل مراجعة جديد، أو إذا تمت إضافة أي عناوين URL أو إسقاطها من البيان، يشير ذلك إلى ضرورة إجراء تحديثات، كجزء من معالِجات أحداث install وactivate. على سبيل المثال، إذا أجريت بعض التغييرات على موقعك الإلكتروني وأعدت تصميمه، قد يكون آخر بيان تخزين مؤقت قد خضع للتغييرات التالية:

[{
  url: 'app.ffaa4455.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

يخبر كل من هذه التغييرات مشغّل الخدمات أنّه يجب إجراء طلبات جديدة لتعديل الإدخالات التي تم تخزينها مؤقتًا في السابق ('offline.svg' و'index.html') وتخزين عناوين URL الجديدة ('app.ffaa4455.js') في ذاكرة التخزين المؤقت، بالإضافة إلى عمليات الحذف لإزالة عناوين URL التي لم تعُد مستخدَمة ('app.abcd1234.js').

تجربة تثبيت صحيحة من "متجر التطبيقات"

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

عندما يثبّت المستخدم تطبيقًا، يتوقع أن يتم عرض كل جزء بسرعة، وليس فقط المشاهدات التي انتقل إليها في الماضي. يوفر التخزين المسبق نفس التجربة لتطبيقات الويب.

أي من مواد العرض يجب أن يتم تخزينها مؤقتًا بشكل مسبق؟

ارجع إلى دليل تحديد ما يتم تحميله للحصول على صورة جيدة لعناوين URL الأكثر ملاءمةً لتخزينها مؤقتًا. تتمثل القاعدة العامة في التخزين المؤقت لأي HTML أو JavaScript أو CSS يتم تحميله في وقت مبكر وهي ضرورية لعرض البنية الأساسية لصفحة معينة.

يُفضَّل تجنُّب التخزين المؤقت للوسائط أو غيرها من الأصول التي يتم تحميلها لاحقًا (ما لم تكن ضرورية لوظيفة تطبيق الويب). يمكنك بدلاً من ذلك استخدام استراتيجية التخزين المؤقّت في وقت التشغيل لضمان تخزين مواد العرض في ذاكرة التخزين المؤقت أثناء التنقّل.

ضع في اعتبارك دائمًا أن التخزين المؤقت يتضمن استخدام معدل نقل البيانات للشبكة والتخزين على جهاز المستخدم (تمامًا مثل تثبيت تطبيق من متجر التطبيقات). الأمر متروك لك كمطور للتخزين المؤقت بشكل مسبق بحكمة وتجنب بيان التخزين المؤقت المتضخم.

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

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