تسجيل مشغّلي الخدمات

أفضل الممارسات لتحديد توقيت تسجيل الخدمة

Jeff Posnick

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

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

النص النموذجي الشائع للتسجيل

إذا سبق لك الاطّلاع على معلومات عن خدمات Service Worker، من المرجّح أن تكون قد صادفت نموذجًا مشابهًا بشكل أساسي لما يلي:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js');
}

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

هل هناك أيّ تفاصيل دقيقة حول navigator.serviceWorker.register؟ هل هناك أي أفضل الممارسات التي يجب اتّباعها؟ من غير المستغرب أن تكون الإجابة عن كليهما "نعم" (مع الأخذ بعين الاعتبار أنّ هذه المقالة لا تنتهي هنا)

الزيارة الأولى للمستخدِم

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

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

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

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

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

تحسين النصوص النموذجية

يكمن الحل في التحكّم في بدء الخدمة من خلال اختيار وقت استدعاء navigator.serviceWorker.register(). من القواعد البسيطة التي يمكن اتّباعها تأخير تسجيل العلامة التجارية إلى ما بعد بدء load event في window، على النحو التالي:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}

ولكن يمكن أن يعتمد الوقت المناسب لبدء تسجيل الخدمة العاملة أيضًا على ما يفعله تطبيق الويب مباشرةً بعد تحميله. على سبيل المثال، يعرض تطبيق الويب لعام 2016 الخاص بمؤتمر Google I/O صورة متحركة قصيرة قبل الانتقال إلى الشاشة الرئيسية. تبيّن لفريقنا أنّ إيقاف تسجيل worker الخدمة أثناء عرض الصورة المتحركة قد يؤدي إلى حدوث تقطُّع في الأداء على الأجهزة الجوّالة المنخفضة التكلفة. بدلاً من تقديم تجربة سيئة للمستخدمين، أرجأنا تسجيل worker service إلى ما بعد انتهاء عرض الصورة المتحركة، عندما يكون المتصفّح في وضع السكون لبضع ثوانٍ على الأرجح.

وبالمثل، إذا كان تطبيق الويب يستخدم إطار عمل يُجري إعدادًا إضافيًا بعد loading الصفحة، ابحث عن حدث خاص بالإطار العمل الذي يشير إلى اكتمال هذا العمل.

الزيارات اللاحقة

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

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

وبالتالي، بعد تعيين عامل خدمة نشط، لا يهمّ وقت الاتصال بأحد موظفي فريق navigator.serviceWorker.register()، أو ما إذا كنت ستتصل به على الإطلاق. ما لم يتم تغيير عنوان URL للنص البرمجي لمشغّل الخدمات، يعتبر navigator.serviceWorker.register() حرفيًا no-op خلال الزيارات اللاحقة. عندما يتم استدعاؤها غير ذي صلة.

أسباب التسجيل مبكرًا

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

اختبار العناصر

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

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

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

في لقطة الشاشة أعلاه، تم تأخير تسجيل مشغّل الخدمة إلى ما بعد loading الصفحة. يمكنك ملاحظة أنّ طلبات التخزين المؤقت المُسبَق لا تبدأ إلا بعد جلب كل الموارد من الشبكة، ما يزيل أي تنافس على النطاق الترددي. علاوة على ذلك، ولأن بعض العناصر التي نخزّنها مسبقًا متوفّرة في ذاكرة التخزين المؤقت لبروتوكول HTTP على المتصفّح، أي العناصر التي تتضمّن (from disk cache) في عمود "الحجم"، يمكننا تعبئة ذاكرة التخزين المؤقت لعامل الخدمة بدون الحاجة إلى الانتقال إلى الشبكة مرة أخرى.

يمكنك الحصول على نقاط إضافية إذا أجريت هذا النوع من الاختبارات من جهاز منخفض المستوى على شبكة جوّالة حقيقية. يمكنك الاستفادة من إمكانات تصحيح الأخطاء عن بُعد في Chrome لتوصيل هاتف Android بجهاز سطح المكتب عبر USB والتأكد من أن الاختبارات التي تجريها تعكس التجربة الفعلية للعديد من المستخدمين.

الخاتمة

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

لضمان تأخير التسجيل الأولي لمشغّل الخدمة إلى ما بعد تحميل الصفحة الأولى، يمكنك استخدام ما يلي:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}