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

Jeff Posnick

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

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

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

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

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

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

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

عرض الموارد المخزّنة مسبقًا

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

كفاءة في التحديثات

يوفّر بيان التخزين المؤقت المسبق تمثيلاً دقيقًا لذاكرة التخزين المؤقت المتوقعة state; إذا تغيرت تركيبة عنوان 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 طرق عرض تطبيق الويب مسبقًا، دون الحاجة إلى الانتظار حتى يزور كل العرض الفردي.

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

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

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

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

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

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

يستفيد الزائرون المتكررون لتطبيق الويب على المدى الطويل من التكلفة الأولية التذكير المسبق، حيث إن القدرة التي يوفرها على تجنب دفع الشبكة مقابل نفسه في النطاق الترددي المحفوظ بمرور الوقت.