تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

مشغّلو الخدمات الجُدد تلقائيًا

Jeff Posnick

النص المختصر

بدءًا من الإصدار 68 من Chrome، لن يتم إيقاف طلبات HTTP التي تبحث عن تحديثات للنص البرمجي لمشغّل الخدمات. أطول من خلال ذاكرة التخزين المؤقت لـ HTTP بشكل افتراضي. ويحل هذا الأمر في ما يتعلق بالمشكلات الشائعة لدى المطوِّرين، الذي يمكن أن يؤدي فيه ضبط عنوان Cache-Control غير مقصود في النص البرمجي لمشغِّل الخدمات إلى إلى تحديثات متأخرة.

إذا سبق لك إيقاف التخزين المؤقت لبروتوكول HTTP للنص البرمجي /service-worker.js من خلال عرضه. باستخدام Cache-Control: max-age=0، لن تظهر لك أي تغييرات بسبب الإعدادات التلقائية الجديدة السلوك.

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

الخلفية

في كل مرة تنتقل فيها إلى صفحة جديدة تقع ضمن نطاق مشغّل الخدمات، عليك طلب registration.update() صراحةً. من JavaScript أو عند "استيقاظ" عامل الخدمة من خلال حدث push أو sync، يمكِّن المتصفح بالتوازي، يطلبون مورد JavaScript الذي تم تمريره في الأصل إلى navigator.serviceWorker.register() للبحث عن تحديثات النص البرمجي لمشغِّل الخدمات.

للأغراض المتعلّقة بهذه المقالة، لنفترض أنّ عنوان URL الخاص بها هو /service-worker.js وأنّه يحتوي على مكالمة واحدة إلى importScripts()، الذي يحمّل رمزًا إضافيًا يتم تشغيله داخل مشغّل الخدمات:

// Inside our /service-worker.js file:
importScripts('path/to/import.js');

// Other top-level code goes here.

ما الذي سيتغيّر؟

قبل الإصدار Chrome 68، كان يتم تقديم طلب تحديث /service-worker.js من خلال ذاكرة التخزين المؤقت لـ HTTP. (كما هو الحال في معظم عمليات الجلب). وهذا يعني أنه إذا تم إرسال النص البرمجي في الأصل باستخدام Cache-Control: max-age=600، فلن يتم إرسال التحديثات خلال الـ 600 ثانية التالية (10 دقائق) إلى الشبكة، وبالتالي قد لا يتلقى المستخدم أحدث إصدار من مشغّل الخدمة. ومع ذلك، إذا كانت max-age أكبر من 86400 (24 ساعة)، يتم التعامل معه كما لو كان 86400، لتجنب تعطّل المستخدمين بإصدار معين إلى الأبد.

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

updateViaCache

يمكن للمطوّرين الآن ضبط خيار جديد عند طلب navigator.serviceWorker.register(): مَعلمة updateViaCache. ويتم استخدام إحدى القيم الثلاث: 'imports' أو 'all' أو 'none'.

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

عند الضبط على 'imports'، لن يتم أبدًا الرجوع إلى ذاكرة التخزين المؤقت HTTP عند البحث عن تحديثات نص برمجي /service-worker.js، ولكن سيتم استشارته عند جلب أي نصوص برمجية تم استيرادها (path/to/import.js، في المثال). هذا هو الخيار التلقائي، ويتطابق مع السلوك الذي يبدأ في الإصدار 68 من Chrome.
عند الضبط على 'all'، سيتم الرجوع إلى ذاكرة التخزين المؤقت HTTP عند إجراء طلبات لكل من نص برمجي /service-worker.js من المستوى الأعلى، بالإضافة إلى أي نصوص برمجية تم استيرادها داخل الخدمة عام، مثل path/to/import.js. ويتوافق هذا الخيار مع السلوك السابق في Chrome، التي تسبق Chrome 68.
عند الضبط على 'none'، لن يتم الرجوع إلى ذاكرة التخزين المؤقت HTTP عند إجراء طلبات لأي من من /service-worker.js من المستوى الأعلى أو لأي نصوص برمجية تم استيرادها، مثل القيم الافتراضية path/to/import.js

على سبيل المثال، ستسجِّل التعليمة البرمجية التالية عامل خدمة، وتتأكد من أن ذاكرة التخزين المؤقت HTTP لم تتم استشارته مطلقًا عند البحث عن تحديثات لنص /service-worker.js البرمجي أو عن أي النصوص البرمجية المشار إليها عبر importScripts() داخل /service-worker.js:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js', {
    updateViaCache: 'none',
    // Optionally, set 'scope' here, if needed.
  });
}

البحث عن تعديلات على النصوص البرمجية التي تم استيرادها

قبل الإصدار Chrome 78، كان يتم تحميل أي نص برمجي لمشغّل الخدمات عبر importScripts() سيتم استردادها مرة واحدة فقط (التحقق أولاً من ذاكرة التخزين المؤقت HTTP، أو عبر استنادًا إلى إعدادات updateViaCache). بعد ذلك العنوان الأولي لاستردادها، فقد يتم تخزينها داخليًا من خلال المتصفح، ولن تتم إعادة جلبها مطلقًا.

وهي الطريقة الوحيدة لإجبار مشغّل الخدمات المثبَّت مسبقًا على اختيار التغييرات التي تم إجراؤها عليه. نص برمجي تم استيراده هو تغيير عنوان URL للنص البرمجي، عادةً عن طريق إضافة قيمة النبات (مثل importScripts('https://example.com/v1.1.0/index.js')) أو من خلال تضمين تجزئة من المحتوى (مثل importScripts('https://example.com/index.abcd1234.js')). حاسمة إن الآثار الجانبية لتغيير عنوان URL المستورد هو أن مشغّل الخدمات ذو المستوى الأعلى يتغير محتوى النص البرمجي، ما يؤدي بدوره إلى تشغيل مسار تعديل مشغّل الخدمات

بدءًا من الإصدار 78 من Chrome، يتم إجراء بحث عن تحديثات في كل مرة مشغّل الخدمات، سيتم إجراء عمليات التحقق في نفس الوقت لتحديد ما إذا كان تم تغيير محتويات أي نصوص برمجية مستوردة أو لم يتم تغييرها. استنادًا إلى تم استخدام Cache-Control عنوان، ويمكن تنفيذ عمليات فحص النص البرمجي المستورَدة هذه عن طريق ذاكرة التخزين المؤقت HTTP في حالة ضبط updateViaCache على 'all' أو 'imports' (وهي مع القيمة الافتراضية)، أو قد تحدث عمليات التحقق ضد الشبكة مباشرةً إذا تم ضبط updateViaCache على 'none'.

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

يتطابق سلوك Chrome 78 مع الإجراءات التي implemented Firefox. قبل عدة سنوات، في Firefox 56. ينفِّذ Safari هذا السلوك من قبل أيضًا.

ما هو الإجراء المطلوب من المطوّرين اتّخاذه؟

إذا اخترت إيقاف التخزين المؤقت لبروتوكول HTTP في نص /service-worker.js البرمجي من خلال عرضه باستخدام Cache-Control: max-age=0 (أو قيمة مشابهة)، من المفترض ألا تظهر لك أي تغييرات بسبب السلوك الافتراضي الجديد.

إذا كنت تعرض نص /service-worker.js البرمجي مع تفعيل التخزين المؤقت لـ HTTP، إما عن قصد أو لأنه مجرد الإعداد التلقائي لبيئة الاستضافة قد تبدأ في ملاحظة ارتفاع في عدد طلبات HTTP الإضافية للموقع الإلكتروني /service-worker.js التي تم إجراؤها على خادمك - هذه هي الطلبات التي كان يتم تنفيذها بواسطة ذاكرة التخزين المؤقت HTTP. إذا كنت ترغب في مواصلة السماح لقيمة العنوان Cache-Control بالتأثير على حداثة /service-worker.js، عليك بدء إعداد updateViaCache: 'all' بشكلٍ صريح عند تسجيل مشغّل الخدمات.

ونظرًا لأنه قد يكون هناك عدد كبير من المستخدمين في إصدارات المتصفح القديمة، فمن الأفضل مواصلة إعداد عنوان HTTP Cache-Control: max-age=0 في النصوص البرمجية لمشغِّل الخدمات، على الرغم من فقد تتجاهلها المتصفحات الجديدة.

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

عرض النصوص البرمجية المستوردة

بدءًا من الإصدار 78 من Chrome، قد يرى المطوّرون المزيد من طلبات HTTP الواردة تم تحميل الموارد عبر importScripts()، لأنّه سيتم الآن التحقّق منها. التحديثات.

إذا أردت تجنُّب زيارات HTTP الإضافية هذه، اضبط الإعدادات الطويلة الأجل عناوين Cache-Control عند عرض نصوص برمجية تتضمّن semver أو تجزئات في عناوين URL الخاصة بها، وتعتمد على سلوك updateViaCache التلقائي، وهو 'imports'.

بدلاً من ذلك، إذا كنت تريد فحص النصوص البرمجية المستوردة بشكل متكرر. ثم تأكَّد من أنّك تعرضها باستخدام Cache-Control: max-age=0 أو استخدام updateViaCache: 'none'.

محتوى إضافي للقراءة

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