قصة ما تم إطلاقه وكيف تم قياس التأثير والمقايضات التي تم إجراؤها
تاريخ النشر: 20 يونيو 2019
ابحث عن أي موضوع تقريبًا على Google، وستظهر لك صفحة يمكن التعرّف عليها على الفور تتضمّن نتائج مفيدة وذات صلة. ربما لم تدرك أنّ صفحة نتائج البحث هذه يتم عرضها، في سيناريوهات معيّنة، باستخدام تكنولوجيا ويب فعّالة تُعرف باسم عامل الخدمة.
تطلّب طرح ميزة "برامج الخدمة" في "بحث Google" بدون التأثير سلبًا في الأداء عمل عشرات المهندسين في فرق متعددة. هذه هي قصة ما تم إطلاقه، وكيف تم قياس الأداء، والتسويات التي تم إجراؤها.
الأسباب الرئيسية لاستكشاف Service Workers
يجب إضافة عامل خدمة إلى تطبيق ويب، تمامًا مثل إجراء أي تغيير معماري على موقعك الإلكتروني، مع وضع مجموعة واضحة من الأهداف في الاعتبار. بالنسبة إلى فريق "بحث Google"، كانت هناك بضعة أسباب رئيسية تستحق استكشاف إمكانية إضافة عامل خدمة.
التخزين المؤقت المحدود لنتائج البحث
لاحظ فريق "بحث Google" أنّ المستخدمين كثيرًا ما يبحثون عن العبارات نفسها أكثر من مرة خلال فترة زمنية قصيرة. بدلاً من إرسال طلب جديد إلى الخلفية للحصول على النتائج نفسها على الأرجح، أراد فريق "بحث Google" الاستفادة من التخزين المؤقت وتلبية طلبات البحث المتكرّرة محليًا.
لا يمكن الاستهانة بأهمية المحتوى الحديث، ففي بعض الأحيان، يبحث المستخدمون عن العبارات نفسها بشكل متكرر لأنّها موضوع متطوّر، ويتوقّعون رؤية نتائج حديثة. يتيح استخدام عامل الخدمة لفريق "بحث Google" تنفيذ منطق دقيق للتحكّم في مدة بقاء نتائج البحث المخزّنة مؤقتًا على الجهاز، وتحقيق التوازن الدقيق بين السرعة والحداثة الذي يعتقد الفريق أنّه الأنسب للمستخدمين.
تجربة مفيدة بلا اتصال بالإنترنت
بالإضافة إلى ذلك، أراد فريق "بحث Google" توفير تجربة مفيدة بدون اتصال بالإنترنت. عندما يريد المستخدم معرفة معلومات حول موضوع معيّن، يريد الانتقال مباشرةً إلى صفحة "بحث Google" والبدء في البحث، بدون القلق بشأن توفّر اتصال نشط بالإنترنت.
بدون عامل الخدمة، ستؤدي زيارة صفحة البحث من Google أثناء عدم الاتصال بالإنترنت إلى عرض صفحة خطأ الشبكة العادية للمتصفح، وسيكون على المستخدمين تذكُّر العودة والمحاولة مجددًا بعد استعادة الاتصال. باستخدام Service Worker، يمكنك عرض استجابة HTML مخصّصة بلا اتصال بالإنترنت، والسماح للمستخدمين بإدخال طلب البحث على الفور.
لن تتوفّر النتائج إلى أن يتم الاتصال بالإنترنت، ولكن يتيح عامل الخدمة تأجيل البحث وإرساله إلى خوادم Google فور عودة الجهاز إلى الإنترنت باستخدام واجهة برمجة التطبيقات للمزامنة في الخلفية.
تخزين رموز JavaScript مؤقتًا وعرضها بشكل أكثر ذكاءً
كان الدافع الآخر هو تحسين التخزين المؤقت وتحميل رمز JavaScript المجزّأ الذي يتيح تشغيل أنواع مختلفة من الميزات على صفحة نتائج البحث. تقدّم عملية تجميع JavaScript عددًا من المزايا التي تكون مفيدة عندما لا يكون هناك أي مشاركة من عامل الخدمة، لذا لم يرِد فريق "بحث Google" إيقاف عملية التجميع بالكامل.
من خلال الاستفادة من قدرة مشغّل الخدمات على تحديد إصدارات من أجزاء JavaScript الدقيقة وتخزينها مؤقتًا أثناء وقت التشغيل، توقّع فريق "بحث Google" أن يتمكّن من تقليل معدّل تغيير ذاكرة التخزين المؤقت وضمان إمكانية تخزين JavaScript التي سيتم إعادة استخدامها في المستقبل بشكل فعّال. يمكن للمنطق داخل عامل الخدمة تحليل طلب HTTP صادر لحزمة تحتوي على وحدات JavaScript متعددة، وتلبية الطلب من خلال تجميع وحدات متعددة مخزّنة مؤقتًا محليًا، ما يؤدي فعليًا إلى "فك الحزمة" عند الإمكان. يؤدي ذلك إلى توفير معدل نقل البيانات للمستخدمين وتحسين الاستجابة بشكل عام.
هناك أيضًا مزايا متعلقة بالأداء عند استخدام JavaScript المخزّن مؤقتًا والذي يقدّمه مشغّل الخدمات: في Chrome، يتم تخزين تمثيل محلّل لرمز البايت الخاص بـ JavaScript وإعادة استخدامه، ما يؤدي إلى تقليل العمل المطلوب تنفيذه في وقت التشغيل من أجل تنفيذ JavaScript على الصفحة.
التحديات والحلول
في ما يلي بعض العقبات التي كان يجب التغلّب عليها لتحقيق الأهداف المحدّدة للفريق. مع أنّ بعض هذه التحديات خاصّة بـ "بحث Google"، إلا أنّ العديد منها ينطبق على مجموعة كبيرة من المواقع الإلكترونية التي قد تفكّر في نشر عامل خدمة.
المشكلة: الحمل الزائد لبرنامج عامل الخدمة
كان التحدي الأكبر، وهو العائق الحقيقي أمام إطلاق عامل الخدمة على "بحث Google"، هو التأكّد من أنّه لن يؤدي إلى أي شيء قد يزيد من وقت الاستجابة الذي يلاحظه المستخدم. يولي محرّك بحث Google أهمية كبيرة للأداء، وقد سبق له أن حظر إطلاق وظائف جديدة إذا أدّت إلى تأخير إضافي ولو كان بمقدار عشرات الملّي ثانية بالنسبة إلى مجموعة معيّنة من المستخدمين.
عندما بدأ الفريق بجمع بيانات الأداء خلال تجاربه الأولى، تبيّن أنّ هناك مشكلة. إنّ رمز HTML الذي يتم عرضه استجابةً لطلبات التنقّل لصفحة نتائج البحث هو رمز ديناميكي، ويختلف بشكل كبير حسب المنطق الذي يجب تنفيذه على خوادم الويب الخاصة بمحرّك بحث Google. لا تتوفّر حاليًا طريقة تتيح لبرنامج عامل الخدمة تكرار هذه المنطقية وعرض HTML المخزَّن مؤقتًا على الفور، وأفضل ما يمكنه فعله هو تمرير طلبات التنقّل إلى خوادم الويب الخلفية، ما يستلزم إجراء طلب شبكة.
بدون عامل الخدمة، يحدث طلب الشبكة هذا فور انتقال المستخدم إلى صفحة أخرى. عند تسجيل عامل خدمة، يجب دائمًا بدء تشغيله وإتاحة الفرصة له لتنفيذ معالجات أحداث fetch، حتى عندما لا يكون هناك أي فرصة لأن تنفّذ معالجات الجلب أي شيء آخر غير الانتقال إلى الشبكة. مقدار الوقت الذي يستغرقه بدء تشغيل رمز Service Worker وتنفيذه هو عبء إضافي خالص يتم إضافته إلى كل عملية تنقّل:
يؤدي ذلك إلى تأخُّر كبير في تنفيذ عامل الخدمة، ما يقلّل من أهمية أي مزايا أخرى. بالإضافة إلى ذلك، تبيّن للفريق، استنادًا إلى قياس أوقات تشغيل عامِل الخدمة على أجهزة حقيقية، أنّ هناك توزيعًا واسعًا لأوقات بدء التشغيل، إذ تستغرق بعض الأجهزة الجوّالة المنخفضة المواصفات وقتًا أطول لبدء تشغيل عامِل الخدمة، وهو الوقت نفسه الذي قد يستغرقه إجراء طلب الشبكة لرمز HTML الخاص بصفحة النتائج.
الحلّ: استخدام ميزة "التحميل المُسبَق للتنقّل"
إنّ الميزة الوحيدة والأكثر أهمية التي سمحت لفريق "بحث Google" بالمضي قدمًا في إطلاق عامل الخدمة هي التحميل المُسبَق للتنقّل. يُعدّ استخدام ميزة "التحميل المُسبَق للتنقّل" تحسّنًا كبيرًا في الأداء لأي عامل خدمة يحتاج إلى استخدام ردّ من الشبكة لتلبية طلبات التنقّل. تقدّم هذه الميزة تلميحًا للمتصفّح لبدء طلب التنقّل على الفور، وذلك في الوقت نفسه الذي تبدأ فيه عملية تشغيل عامل الخدمة:
طالما أنّ مقدار الوقت الذي يستغرقه بدء عمل عامل الخدمة أقل من مقدار الوقت الذي يستغرقه تلقّي رد من الشبكة، لن يكون هناك أي وقت إضافي للانتظار بسبب عامل الخدمة.
كان على فريق "بحث Google" أيضًا تجنُّب استخدام عامل الخدمة على الأجهزة الجوّالة المنخفضة المواصفات التي قد يتجاوز فيها وقت تشغيل عامل الخدمة طلب الانتقال. بما أنّه لا توجد قاعدة ثابتة تحدّد مواصفات الأجهزة "المنخفضة الأداء"، فقد تم وضع قاعدة إرشادية للتحقّق من إجمالي ذاكرة الوصول العشوائي المثبّتة على الجهاز. وكانت أي ذاكرة أقل من 2 غيغابايت تندرج ضمن فئة الأجهزة المنخفضة المواصفات، حيث يكون وقت بدء تشغيل عامل الخدمة غير مقبول.
مساحة التخزين المتاحة هي عامل آخر يجب أخذه في الاعتبار، لأنّ المجموعة الكاملة من الموارد التي سيتم تخزينها مؤقتًا لاستخدامها في المستقبل يمكن أن تصل إلى عدة ميغابايت. تسمح
واجهة navigator.storage
لصفحة "بحث Google" بأن تحدّد مسبقًا ما إذا كانت محاولاتها لتخزين البيانات مؤقتًا ستفشل بسبب عدم توفّر مساحة تخزين كافية.
نتيجةً لذلك، أصبح لدى فريق "بحث Google" معايير متعدّدة يمكنه استخدامها لتحديد ما إذا كان سيتم استخدام عامل خدمة أم لا. فإذا انتقل المستخدم إلى صفحة "بحث Google" باستخدام متصفّح يتيح ميزة "التحميل المُسبَق للتنقّل"، وكان لديه ذاكرة وصول عشوائي (RAM) بسعة 2 غيغابايت على الأقل ومساحة تخزين كافية، سيتم تسجيل عامل خدمة. لن تحصل المتصفّحات أو الأجهزة التي لا تستوفي هذا المعيار على برنامج service worker، ولكن سيظل بإمكانها الاستفادة من تجربة "بحث Google" نفسها التي اعتادت عليها.
من المزايا الجانبية لهذا التسجيل الانتقائي إمكانية إرسال عامل خدمة أصغر حجمًا وأكثر فعالية. يؤدي استهداف المتصفّحات الحديثة نسبيًا لتشغيل رمز عامل الخدمة إلى إلغاء النفقات العامة للتحويل البرمجي وpolyfills للمتصفّحات القديمة. وقد أدّى ذلك إلى تقليل حجم رمز JavaScript غير المضغوط بمقدار 8 كيلوبايت تقريبًا من الحجم الإجمالي لتنفيذ عامل الخدمة.
المشكلة: نطاقات مشغّل الخدمات
بعد أن أجرى فريق "بحث Google" عددًا كافيًا من التجارب المتعلقة بوقت الاستجابة، وتأكّد من أنّ استخدام ميزة "التحميل المُسبَق للتنقّل" يوفّر مسارًا مناسبًا لا يؤثر في وقت الاستجابة لاستخدام عامِل الخدمة، بدأت بعض المشاكل العملية تبرز. تتعلّق إحدى هذه المشاكل بقواعد تحديد النطاق الخاصة ببرنامج عامل الخدمة. يحدّد نطاق مشغّل الخدمات الصفحات التي يمكنه التحكّم فيها.
يعمل تحديد النطاق استنادًا إلى بادئة مسار عنوان URL. بالنسبة إلى النطاقات التي تستضيف تطبيق ويب واحدًا، لا تشكّل هذه المشكلة أي عائق، إذ يمكنك عادةً استخدام مشغّل خدمات بنطاق / الأقصى، ما يتيح له التحكّم في أي صفحة ضمن النطاق.
لكنّ بنية عناوين URL في "بحث Google" أكثر تعقيدًا بعض الشيء.
إذا تم منح مشغّل الخدمات النطاق الأقصى /، سيتمكّن من التحكّم في أي صفحة مستضافة ضمن www.google.com (أو النطاق الإقليمي المكافئ)، وهناك عناوين URL ضمن هذا النطاق لا صلة لها بمحرّك بحث Google. نطاق أكثر منطقية وتقييدًا هو /search، والذي سيؤدي على الأقل إلى إزالة عناوين URL غير ذات الصلة تمامًا بنتائج البحث.
مع الأسف، تتم مشاركة مسار عنوان URL /search هذا بين أنواع مختلفة من نتائج البحث من Google، وتحدّد مَعلمات طلب البحث في عنوان URL نوع نتيجة البحث المحدّد الذي يتم عرضه. تستخدم بعض هذه النكهات قواعد رموز مختلفة تمامًا عن صفحة نتائج البحث التقليدية على الويب. على سبيل المثال، يتم عرض كلّ من "بحث الصور" و"بحث التسوّق" ضمن مسار عنوان URL /search مع مَعلمات طلب بحث مختلفة، ولكن لم تكن أيّ من هاتين الواجهتَين جاهزة لتوفير تجربة عامل الخدمة الخاصة بها (بعد).
الحلّ: إنشاء إطار عمل للإرسال والتوجيه
على الرغم من وجود بعض الاقتراحات التي تسمح باستخدام ميزة أكثر فعالية من بادئات مسار عناوين URL لتحديد نطاقات Service Worker، واجه فريق "بحث Google" صعوبة في نشر Service Worker لا يقدّم أي فائدة لمجموعة فرعية من الصفحات التي يتحكّم فيها.
لحلّ هذه المشكلة، أنشأ فريق "بحث Google" إطار عمل مخصّصًا للإرسال والتوجيه يمكن ضبطه للتحقّق من معايير مثل مَعلمات طلب البحث في صفحة العميل، واستخدامها لتحديد مسار الرمز البرمجي المحدّد الذي يجب اتّباعه. بدلاً من ترميز القواعد بشكل ثابت، تم تصميم النظام ليكون مرنًا ويسمح للفرق التي تشارك مساحة عناوين URL، مثل "بحث الصور" و"بحث التسوّق"، بإضافة منطق عامل الخدمة الخاص بها في وقت لاحق، إذا قررت تنفيذه.
المشكلة: النتائج والمقاييس المخصّصة
يمكن للمستخدمين تسجيل الدخول إلى "بحث Google" باستخدام حساباتهم على Google، وقد يتم تخصيص تجربة نتائج البحث استنادًا إلى بيانات حساباتهم. يتم تحديد المستخدمين المسجّلين من خلال ملفات تعريف الارتباط الخاصة بالمتصفّح، وهي معيار قديم ومتوافق على نطاق واسع.
مع ذلك، من سلبيات استخدام ملفات تعريف الارتباط في المتصفح أنّها لا تكون متاحة داخل مشغّل الخدمات، ولا توجد طريقة لفحص قيمها تلقائيًا والتأكّد من أنّها لم تتغيّر بسبب تسجيل المستخدم الخروج أو تبديل الحسابات. (هناك جهود جارية لإتاحة الوصول إلى ملفات تعريف الارتباط من خلال عاملي الخدمة، ولكن حتى تاريخ كتابة هذه المقالة، لا يزال هذا الأسلوب تجريبيًا ولا يتوافق مع العديد من المتصفحات).
قد يؤدي عدم تطابق بين طريقة عرض عامل الخدمة للمستخدم الحالي الذي سجّل الدخول والمستخدم الفعلي الذي سجّل الدخول إلى واجهة الويب الخاصة بـ "بحث Google" إلى عرض نتائج بحث مخصّصة بشكل غير صحيح أو تسجيل مقاييس غير صحيحة. في حال حدوث أي من سيناريوهات التعذّر هذه، ستكون مشكلة خطيرة بالنسبة إلى فريق "بحث Google".
الحل: إرسال ملفات تعريف الارتباط باستخدام postMessage
بدلاً من انتظار إطلاق واجهات برمجة التطبيقات التجريبية وتوفير إمكانية الوصول المباشر إلى ملفات تعريف الارتباط الخاصة بالمتصفح داخل أحد عاملي الخدمة، اختار فريق "بحث Google" حلاً مؤقتًا: عندما يتم تحميل صفحة يتحكّم فيها عامل الخدمة، تقرأ الصفحة ملفات تعريف الارتباط ذات الصلة وتستخدم postMessage() لإرسالها إلى عامل الخدمة.
بعد ذلك، يتحقّق عامل الخدمة من قيمة ملف تعريف الارتباط الحالي مقارنةً بالقيمة المتوقّعة، وإذا كان هناك عدم تطابق، يتّخذ خطوات لمحو أي بيانات خاصة بالمستخدم من مساحة التخزين، ويعيد تحميل صفحة نتائج البحث بدون أي تخصيص غير صحيح.
تختلف الخطوات المحدّدة التي يتّخذها عامل الخدمة لإعادة ضبط الإعدادات إلى الوضع الأساسي باختلاف متطلبات "بحث Google"، ولكن قد يكون النهج العام نفسه مفيدًا للمطوّرين الآخرين الذين يتعاملون مع البيانات المخصّصة التي يتم تفعيلها من خلال ملفات تعريف الارتباط في المتصفحات.
المشكلة: التجارب والديناميكية
كما ذكرنا سابقًا، يعتمد فريق "بحث Google" بشكل كبير على إجراء تجارب في بيئة الإنتاج واختبار تأثيرات الرموز والميزات الجديدة في العالم الحقيقي قبل تفعيلها تلقائيًا. قد يكون ذلك صعبًا بعض الشيء مع عامل خدمة ثابت يعتمد بشكل كبير على البيانات المخزّنة مؤقتًا، لأنّ السماح للمستخدمين بالمشاركة في التجارب أو إيقافها غالبًا ما يتطلّب التواصل مع خادم الخلفية.
الحل: نص برمجي لبرنامج عامل الخدمة يتم إنشاؤه ديناميكيًا
وقد اختار الفريق استخدام نص برمجي لوحدة الخدمة يتم إنشاؤه بشكل ديناميكي، ويخصّصه خادم الويب لكل مستخدم على حدة، بدلاً من استخدام نص برمجي واحد وثابت لوحدة الخدمة يتم إنشاؤه مسبقًا. يتم تضمين معلومات حول التجارب التي قد تؤثر في سلوك عامل الخدمة أو طلبات الشبكة بشكل عام مباشرةً في نصوص برامج عامل الخدمة المخصّصة هذه. يتم تغيير مجموعات التجارب النشطة للمستخدم من خلال مزيج من التقنيات التقليدية، مثل ملفات تعريف الارتباط في المتصفح، بالإضافة إلى عرض رمز معدَّل في عنوان URL الخاص بخدمة Service Worker المسجّلة.
يؤدي استخدام نص برمجي لبرنامج عامل الخدمة يتم إنشاؤه ديناميكيًا إلى تسهيل توفير آلية احتياطية في حال حدوث خطأ فادح في تنفيذ برنامج عامل الخدمة يجب تجنُّبه. قد يكون ردّ العامل في الخدمة من الخادم الديناميكي عملية غير نشطة، ما يؤدي إلى إيقاف العامل في الخدمة لبعض المستخدمين الحاليين أو جميعهم.
المشكلة: تنسيق التحديثات
من أصعب التحديات التي تواجه أي عملية نشر لبرامج الخدمة في العالم الحقيقي هو إيجاد حل وسط معقول بين تجنُّب الشبكة لصالح ذاكرة التخزين المؤقت، مع ضمان حصول المستخدمين الحاليين في الوقت نفسه على التحديثات والتغييرات المهمة بعد نشرها في بيئة الإنتاج بوقت قصير. يعتمد التوازن الصحيح على الكثير من العوامل، بما في ذلك:
- ما إذا كان تطبيق الويب الخاص بك هو تطبيق من صفحة واحدة طويل الأمد يبقيه المستخدم مفتوحًا إلى أجل غير مسمى، بدون الانتقال إلى صفحات جديدة.
- تحديد وتيرة نشر التحديثات على خادم الويب الخلفي
- ما إذا كان المستخدم العادي سيتقبّل استخدام إصدار قديم قليلاً من تطبيقك على الويب، أو ما إذا كانت الأولوية القصوى هي الحصول على أحدث إصدار
أثناء تجربة عاملي الخدمة، حرص فريق "بحث Google" على استمرار التجارب في عدد من التعديلات المجدوَلة على الخلفية، وذلك لضمان تطابق المقاييس وتجربة المستخدم بشكل أكبر مع ما سيراه المستخدمون المتكرّرون في العالم الحقيقي.
الحلّ: تحقيق التوازن بين الحداثة واستخدام ذاكرة التخزين المؤقت
بعد اختبار عدد من خيارات الإعداد المختلفة، تبيّن لفريق "بحث Google" أنّ الإعداد التالي يحقّق التوازن المناسب بين الحداثة والاستفادة من ذاكرة التخزين المؤقت.
يتم عرض عنوان URL لبرنامج نصي خاص بعامل الخدمة مع عنوان الاستجابة Cache-Control: private, max-age=1500 (1500 ثانية أو 25 دقيقة)، ويتم تسجيله مع ضبط updateViaCache على "all" لضمان الالتزام بالعنوان. إنّ الخلفية المستندة إلى الويب في "بحث Google" هي، كما تتوقّع، مجموعة كبيرة من الخوادم الموزّعة على مستوى العالم، ويجب أن تكون مدة تشغيلها قريبة من% 100 قدر الإمكان. يتم طرح أي تغيير يؤثر في محتوى البرنامج النصي الخاص ببرنامج عامل الخدمة بشكل متتابع.
إذا وصل المستخدم إلى خادم خلفي تم تعديله، ثم انتقل بسرعة إلى صفحة أخرى تصل إلى خادم خلفي لم يتلقَّ بعد عامل الخدمة المعدَّل، سينتهي به الأمر بالتبديل بين الإصدارات عدة مرات. لذلك، لن يكون هناك أي عيب كبير في توجيه المتصفّح إلى التحقّق من توفّر نص برمجي معدَّل فقط إذا مرّت 25 دقيقة على آخر عملية تحقّق. تتمثّل الميزة في الموافقة على هذا السلوك في تقليل عدد الزيارات بشكل كبير إلى نقطة النهاية التي تنشئ نص برمجيًا لعامل الخدمة.
بالإضافة إلى ذلك، يتم ضبط عنوان ETag على استجابة HTTP لبرنامج نصي خاص بعامل الخدمة، ما يضمن أنّه عند إجراء عملية البحث عن التحديثات بعد مرور 25 دقيقة، يمكن للخادم الاستجابة بكفاءة من خلال استجابة HTTP 304 إذا لم يتم إجراء أي تحديثات على عامل الخدمة الذي تم نشره في الفترة المؤقتة.
في حين أنّ بعض التفاعلات ضمن تطبيق الويب "بحث Google" تستخدم عمليات تنقّل على غرار تطبيقات الصفحة الواحدة (أي من خلال History API)، فإنّ "بحث Google" هو في معظمه تطبيق ويب تقليدي يستخدم عمليات تنقّل "حقيقية". يصبح هذا الأمر مهمًا عندما يقرّر الفريق أنّ استخدام خيارَين يسرّعان دورة حياة تعديل عامل الخدمة سيكون فعّالاً، وهما:
clients.claim()
و
skipWaiting().
يؤدي النقر على عناصر واجهة "بحث Google" عادةً إلى الانتقال إلى مستندات HTML جديدة. يضمن استدعاء skipWaiting أن تتاح للعامل الجديد في الخدمة فرصة معالجة طلبات التنقّل الجديدة هذه فورًا بعد التثبيت. وبالمثل، يعني استدعاء clients.claim() أنّ عامل الخدمة المعدَّل سيحصل على فرصة لبدء التحكّم في أي صفحات مفتوحة من "بحث Google" غير خاضعة للتحكّم، وذلك بعد تفعيل عامل الخدمة.
إنّ الأسلوب الذي اتّبعه محرّك بحث Google ليس بالضرورة حلاً مناسبًا للجميع، بل هو نتيجة اختبار أ/ب دقيق لمختلف مجموعات خيارات العرض إلى أن تم العثور على الأسلوب الأنسب.
قد يفضّل المطوّرون الذين تسمح لهم البنية الأساسية للخادم الخلفي بنشر التحديثات بشكل أسرع أن يتحقّق المتصفّح من توفّر نص معدَّل لبرنامج عامل الخدمة بأسرع ما يمكن، وذلك من خلال تجاهل ذاكرة التخزين المؤقت لبروتوكول HTTP دائمًا.
إذا كنت بصدد إنشاء تطبيق من صفحة واحدة قد يتركه المستخدمون مفتوحًا لفترة طويلة، من المحتمل ألا يكون استخدام skipWaiting() هو الخيار المناسب لك، لأنّك تخاطر بمواجهة حالات عدم اتساق في ذاكرة التخزين المؤقت إذا سمحت بتفعيل عامل الخدمة الجديد أثناء وجود برامج عملاء طويلة الأمد.
الخلاصات الرئيسية
لا تكون ملفات تشغيل الخدمات محايدة من حيث الأداء بشكل تلقائي
تتضمّن إضافة عامل خدمة إلى تطبيق الويب إدراج جزء إضافي من JavaScript يجب تحميله وتنفيذه قبل أن يتلقّى تطبيق الويب ردودًا على طلباته. إذا كانت هذه الردود تأتي من ذاكرة تخزين مؤقت محلية بدلاً من الشبكة، يكون العبء الناتج عن تشغيل عامل الخدمة ضئيلاً عادةً مقارنةً بتحسّن الأداء الناتج عن استخدام ذاكرة التخزين المؤقت أولاً. ولكن إذا كنت تعلم أنّ عامل الخدمة يجب أن يستشير الشبكة دائمًا عند معالجة طلبات التنقّل، فإنّ استخدام ميزة "التحميل المُسبَق للتنقّل" يحقّق تحسّنًا كبيرًا في الأداء.
لا تزال برامج Service Worker من التحسينات التدريجية
أصبحت إمكانية استخدام عاملي الخدمة أفضل بكثير اليوم مما كانت عليه قبل عام. تتضمّن جميع المتصفّحات الحديثة الآن بعض الميزات المتوافقة مع عاملي الخدمة، ولكن للأسف، هناك بعض الميزات المتقدّمة لعامل الخدمة، مثل المزامنة في الخلفية والتحميل المُسبَق للتنقّل، التي لم يتم طرحها على نطاق واسع. لا يزال التحقّق من توفّر الميزات في المجموعة الفرعية المحدّدة التي تحتاج إليها، وعدم تسجيل عامل الخدمة إلا عند توفّر هذه الميزات، أسلوبًا منطقيًا.
وبالمثل، إذا أجريت تجارب في بيئة حقيقية، وعرفت أنّ الأجهزة المنخفضة المواصفات لا تعمل بشكل جيد مع الحمل الزائد الذي يفرضه عامل الخدمة، يمكنك أيضًا تجنُّب تسجيل عامل الخدمة في هذه السيناريوهات.
عليك مواصلة التعامل مع عاملي الخدمة باعتبارهم تحسينًا تدريجيًا يتم إضافته إلى تطبيق الويب عند استيفاء جميع المتطلبات الأساسية، وعندما يضيف عامل الخدمة قيمة إيجابية إلى تجربة المستخدم وأداء التحميل العام.
قياس كل شيء
الطريقة الوحيدة التي يمكنك من خلالها معرفة ما إذا كان نشر عامل الخدمة قد أحدث تأثيرًا إيجابيًا أو سلبيًا في تجارب المستخدمين هي إجراء تجربة وقياس النتائج.
تعتمد تفاصيل إعداد القياسات الهادفة على مقدّم خدمة الإحصاءات الذي تستخدمه، وعلى الطريقة التي تجري بها التجارب عادةً في إعدادات النشر. يتم تفصيل إحدى الطرق، وهي استخدام "إحصاءات Google" لجمع المقاييس، في دراسة الحالة هذه استنادًا إلى تجربة استخدام عاملي الخدمة في تطبيق Google I/O على الويب.
الأهداف غير المكتملة
على الرغم من أنّ العديد من مطوّري الويب يربطون مشغّلي الخدمات بتطبيقات الويب التقدّمية، لم يكن إنشاء "تطبيق ويب تقدّمي خاص بمحرّك بحث Google" هدفًا أوليًا للفريق. لا يوفّر تطبيق الويب "بحث Google" بيانات وصفية في بيان تطبيق الويب، ولا يشجّع المستخدمين على اتّباع خطوات الإضافة إلى الشاشة الرئيسية. يرى فريق "بحث Google" أنّ المستخدمين يصلون إلى تطبيق الويب من خلال نقاط الدخول الكلاسيكية في "بحث Google".
بدلاً من محاولة تحويل تجربة الويب في "بحث Google" إلى ما تتوقّعه من تطبيق مثبَّت، كان التركيز في الإصدار الأوّلي على تحسين الموقع الإلكتروني الحالي بشكل تدريجي.
الإقرارات
نشكر فريق تطوير الويب بالكامل في "بحث Google" على جهوده في تنفيذ Service Worker وعلى مشاركة المواد الأساسية التي تم الاستناد إليها في كتابة هذه المقالة. نودّ أن نخصّ بالشكر "فيليب غول" و"راجيش جاغانانثان" و"آر. "صامويل كلاتشكو" و"آندي مارتون" و"ليوناردو بينيا" و"راشيل شيرر" و"غريغ تيرونو" و"كلاي وولام"
تعديل (أكتوبر 2021): منذ نشر هذه المقالة في الأصل، أعاد فريق "بحث Google" تقييم مزايا وعيوب بنية عامل الخدمة الحالية. سيتم إيقاف عامل الخدمة الموضّح أعلاه نهائيًا. مع تطوّر البنية الأساسية لشبكة "بحث Google"، قد يعيد الفريق النظر في تصميم مشغّل الخدمات.