قصة ما تم شحنه وكيفية قياس التأثير والمفاضلات التي تم إجراؤها
الخلفية
ابحث عن أي موضوع على Google، وستظهر لك صفحة يمكن التعرّف عليها على الفور وتعرض نتائج مفيدة وذات صلة. ما قد يكون لم تدركه هو أنّ صفحة نتائج البحث هذه، في سيناريوهات معيّنة، يتم عرضها من خلال تقنية ويب فعّالة تُعرف باسم خدمة عامل.
تطلب طرح ميزة "خدمة عامل التشغيل" في "بحث Google" بدون التأثير سلبًا في الأداء جهودًا مكثفة من عشرات المهندسين الذين يعملون في عدة فِرق. هذه هي قصة ما تم طرحه وكيفية قياس الأداء والحلول البديلة التي تمّت.
الأسباب الرئيسية لاستكشاف مهام الخدمة
يجب أن يتمّ وضع مجموعة واضحة من الأهداف في الاعتبار عند إضافة عامل خدمة إلى تطبيق ويب، تمامًا مثل إجراء أيّ تغيير على البنية الأساسية لموقعك الإلكتروني. بالنسبة إلى فريق "بحث Google"، كانت هناك بضعة أسباب رئيسية تجعل إضافة عامل خدمة يستحق الفحص.
ميزة التخزين المؤقت المحدود لنتائج البحث
تبيّن لفريق "بحث Google" أنّه من الشائع أن يبحث المستخدمون عن العبارات نفسها أكثر من مرّة خلال فترة زمنية قصيرة. بدلاً من إرسال طلب جديد للخلفية للحصول على النتائج نفسها على الأرجح، أراد فريق "بحث Google" الاستفادة من ميزة التخزين المؤقت وتنفيذ هذه الطلبات المتكررة محليًا.
لا يمكن التقليل من أهمية حداثة المحتوى، وفي بعض الأحيان يبحث المستخدمون عن المصطلحات نفسها بشكل متكرّر لأنّها موضوع متطور، ويتوقعون الاطّلاع على نتائج جديدة. يتيح استخدام موظّف الخدمة لفريق "بحث Google" تنفيذ منطق مفصّل للتحكّم في مدة صلاحية نتائج البحث المخزّنة مؤقتًا على الجهاز، وتحقيق التوازن الدقيق بين السرعة وحداثة البيانات، ما يعتقدون أنّه يخدم مستخدمي محرّك البحث على أفضل نحو.
تجربة مفيدة بلا إنترنت
بالإضافة إلى ذلك، أراد فريق "بحث Google" توفير تجربة مفيدة في وضع عدم الاتّصال بالإنترنت. عندما يريد المستخدم الاطّلاع على معلومات عن موضوع معيّن، يريد الانتقال مباشرةً إلى صفحة "بحث Google" وبدء البحث بدون القلق بشأن اتصال الإنترنت النشط.
بدون موظّف خدمة، يؤدي الانتقال إلى صفحة بحث Google بلا إنترنت إلى توجيهك إلى صفحة الخطأ العادية للشبكة في المتصفّح، وعلى المستخدمين تذكُّر العودة وإعادة المحاولة بعد استعادة الاتصال بالإنترنت. باستخدام عامل تدخّل الخدمة، من الممكن عرض استجابة HTML مخصّصة بلا إنترنت والسماح للمستخدمين بإدخال طلب البحث على الفور.
لن تتوفّر النتائج إلا بعد الاتصال بالإنترنت، ولكن يسمح العامل المعني بالخدمة بتأجيل عملية البحث وإرسالها إلى خوادم Google بمجرد إعادة اتصال الجهاز بالإنترنت باستخدام Background Sync API.
تحسين ذاكرة التخزين المؤقت وعرض JavaScript
كان أحد الدوافع الأخرى هو تحسين ميزة التخزين المؤقت وتحميل رمز JavaScript المُجزّأ الذي يشغّل الأنواع المختلفة من الميزات في صفحة نتائج البحث. هناك عدد من المزايا التي يوفّرها تجميع JavaScript والتي تبدو منطقية في حال عدم استخدام موظّف الخدمة، لذلك لم يكن فريق محرّك بحث Google يريد ببساطة إيقاف التجميع بالكامل.
من خلال استخدام قدرة مشغّل الخدمة على إنشاء نُسخ من أجزاء محددة من برمجة JavaScript وتخزينها مؤقتًا أثناء وقت التشغيل، توقّع فريق "بحث Google" أن يتمكّن من تقليل كمية عمليات إزالة ذاكرة التخزين المؤقت والتأكّد من أنّه يمكن تخزين JavaScript الذي تتم إعادة استخدامه في المستقبل بكفاءة. يمكن للمنطق داخل الخدمة العاملة تحليل طلب HTTP مُرسَل للحصول على حِزمة تحتوي على عدة وحدات JavaScript، وتنفيذه من خلال تجميع عدة وحدات مخزّنة مؤقتًا على الجهاز، ما يؤدي إلى "إزالة الحِزمة" بشكل فعّال كلما أمكن ذلك. ويؤدي ذلك إلى توفير معدل نقل البيانات للمستخدمين، ويؤدي بدوره إلى تحسين الاستجابة بشكل عام.
هناك أيضًا مزايا للأداء عند استخدام JavaScript المخزّن مؤقتًا الذي يقدّمه مشغّل الخدمة: في Chrome، يتم تخزين تمثيل ترميز ثنائي مُحلَّل لرمز JavaScript هذا وإعادة استخدامه، ما يؤدي إلى تقليل العمل الذي يجب إجراؤه أثناء التشغيل لتنفيذ JavaScript على الصفحة.
التحديات والحلول
في ما يلي بعض العقبات التي كان يجب التغلب عليها لتحقيق أهداف الفريق المُعلَن عنها. على الرغم من أنّ بعض هذه التحديات مرتبطة بخدمة "بحث Google"، إلا أنّ العديد منها ينطبق على مجموعة كبيرة من المواقع الإلكترونية التي قد تفكر في استخدام موظّف خدمة.
المشكلة: تكاليف الخدمة غير الضرورية
كان التحدي الأكبر، والعامل الوحيد الذي يمنع إطلاق عامل خدمة على "بحث Google"، هو التأكّد من أنّه لا ينفّذ أي إجراء قد يؤدي إلى زيادة وقت الاستجابة الذي يلاحظه المستخدم. يتعامل محرّك بحث Google مع الأداء بجدية كبيرة، وقد منع في السابق إطلاق وظائف جديدة إذا كانت تساهم في زيادة وقت الاستجابة بمقدار عشرات المللي ثانية لشريحة معيّنة من المستخدمين.
عندما بدأ الفريق في جمع بيانات الأداء خلال تجاربه المبكرة، تبيّن له أنّه ستظهر مشكلة. إنّ ملف HTML الذي يتم إرجاعه استجابةً ل طلبات التنقّل لصفحة نتائج البحث هو ملف ديناميكي، ويختلف كثيرًا حسب المنطق الذي يجب تشغيله على خوادم الويب في "بحث Google". لا تتوفّر حاليًا طريقة لخدمة worker لإعادة تطبيق هذا المنطق وعرض ملف HTML المخزّن مؤقتًا على الفور. إنّ أفضل ما يمكن أن تفعله هو إعادة توجيه طلبات التنقّل إلى ملفّات خادم الويب في الخلفية، ما يستلزم تقديم طلب إلى الشبكة.
في حال عدم توفّر عامل خدمة، يتم إرسال طلب الشبكة هذا فورًا عند
تنقّل المستخدم. عند تسجيل عامل خدمة، يجب دائمًا بدؤه
وإعطائه فرصة لتنفيذ
معالجات أحداث fetch،
حتى في حال عدم توفّر فرصة لإجراء هذه المعالجات لأيّ شيء سوى الانتقال
إلى الشبكة. إنّ الوقت الذي يستغرقه بدء تشغيل رمز worker
الخدمة وتنفيذه هو وقت إضافي يتم إضافته إلى كل عملية تنقّل:
ويؤدي ذلك إلى زيادة وقت الاستجابة بدرجة كبيرة في تنفيذ الخدمة العاملة، ما ينفي أي فوائد أخرى. بالإضافة إلى ذلك، تبيّن للفريق أنّه، استنادًا إلى قياس أوقات بدء تشغيل مهام الخدمة على الأجهزة الحقيقية، كان هناك اختلاف كبير في أوقات بدء التشغيل، حيث يستغرق بعض الأجهزة الجوّالة المنخفضة التكلفة تقريبًا نفس الوقت الذي يستغرقه إرسال طلب الشبكة لرمز HTML لصفحة النتائج.
الحلّ: استخدام ميزة التحميل المُسبَق لبيانات التنقّل
إنّ التحميل المُسبَق للتنقّل هو الميزة الأكثر أهمية التي سمحت لفريق "بحث Google" بالمضي قدمًا في إطلاق الخدمة العاملة. يُعدّ استخدام التحميل المُسبَق للتنقّل أحد العوامل الرئيسية التي تساهم في تحسين الأداء لأي عامل خدمة يحتاج إلى استخدام استجابة من الشبكة لتلبية طلبات التنقّل. ويقدّم تلميحًا للمتصفح لبدء تقديم طلب التنقّل على الفور، في الوقت نفسه الذي يبدأ فيه تشغيل الخدمة العاملة:
طالما أنّ الوقت الذي يستغرقه تشغيل worker الخدمة هو أقل من الوقت الذي يستغرقه تلقّي استجابة من الشبكة، يجب ألا يكون هناك أي وقت انتظار إضافي يُقدّمه worker الخدمة.
كان على فريق "بحث Google" أيضًا تجنُّب استخدام عامل خدمة على الأجهزة المنخفضة الأداء الجوّالة، حيث يمكن أن يتجاوز وقت تشغيل عامل الخدمة طلب التنقّل. وبما أنّه لا تتوفّر قاعدة صارمة لتحديد ما يُعدّ جهازًا "منخفض المستوى"، ابتكر الفريق طريقة تقريبية للتحقّق من إجمالي ذاكرة الوصول العشوائي المُثبَّتة على الجهاز. أما الأجهزة التي تقل ذاكرتها عن 2 غيغابايت، فكانت تندرج ضمن فئة الأجهزة المنخفضة المستوى، حيث يكون وقت بدء تشغيل الخدمة غير مقبول.
ويجب أيضًا مراعاة مساحة التخزين المتاحة، لأنّ المجموعة الكاملة من
الموارد التي سيتم تخزينها مؤقتًا لاستخدامها في المستقبل يمكن أن تصل إلى عدة ميغابايت. تسمح
واجهةnavigator.storage
لصفحة "بحث Google" بمعرفة ما إذا كانت محاولاتها ل
تخزين البيانات مؤهلة للنجاح أو أنّها قد تؤدي إلى تعذُّر ذلك بسبب عدم توفّر مساحة تخزين كافية.
نتيجةً لذلك، حصل فريق "بحث Google" على عدة معايير يمكنه استخدامها لتحديد ما إذا كان سيتم استخدام عامل خدمة أم لا: إذا وصل مستخدم إلى صفحة "بحث Google" باستخدام متصفّح يتيح تحميل التنقّل مسبقًا، وكان لديه ما لا يقل عن 2 غيغابايت من ذاكرة الوصول العشوائي ومساحة تخزين مجانية كافية، يتم تسجيل عامل خدمة. لن تحصل المتصفّحات أو الأجهزة التي لا تستوفي هذه المعايير على عامل تدخّل، ولكن سيظل بإمكانها الاستفادة من تجربة "بحث Google" نفسها التي كانت تحصل عليها في السابق.
من المزايا الجانبية لهذا التسجيل الانتقائي هي إمكانية شحن عامل خدمة أصغر حجمًا وأكثر فعالية. إنّ استهداف المتصفّحات الحديثة إلى حدٍ ما لتشغيل код الخدمة العاملة يزيل النفقات العامة لعملية التحويل البرمجي وعمليات polyfill في المتصفّحات القديمة. وقد أدّى ذلك إلى إزالة حوالي 8 كيلوبايت من رمز JavaScript غير المضغوط من الحجم الإجمالي لتنفيذ الخدمة.
المشكلة: نطاقات مشغِّل الخدمات
بعد أن أجرى فريق "بحث Google" عددًا كافيًا من تجارب وقت الاستجابة وأصبحوا واثقين من أنّ استخدام ميزة "التحميل المُسبَق للتنقّل" يقدّم لهم مسارًا قابلاً للتطبيق وغير متأثر بوقت الاستجابة لاستخدام عامل الخدمة، بدأت بعض المشاكل العملية بالظهور في المقدّمة. ترتبط إحدى هذه المشاكل بقواعد تحديد النطاق في الخدمة العاملة. يحدِّد نطاق مشغّل الخدمات الصفحات التي يمكنه التحكّم فيها.
تعمل ميزة تحديد النطاق استنادًا إلى بادئة مسار عنوان URL. بالنسبة إلى النطاقات التي تستضيف
تطبيق ويب واحدًا، لا يشكّل ذلك مشكلة، لأنّك عادةً ما تستخدِم مشغّل خدمات يملك
النطاق الأقصى الذي يبلغ /، والذي يمكنه التحكّم في أي صفحة ضمن النطاق.
ولكن بنية عناوين URL في محرّك بحث Google أكثر تعقيدًا بعض الشيء.
إذا تم منح مشغّل الخدمة النطاق الأقصى /، سينتهي الأمر بتمكينه
من التحكّم في أي صفحة مستضافة ضمن www.google.com (أو العنوان الإقليمي
المعادل)، وهناك عناوين URL ضمن هذا النطاق لا علاقة لها
ببحث Google. سيكون النطاق الأكثر معقولية وتقييدًا هو /search، ما سيؤدي على الأقل إلى إزالة عناوين URL غير ذات الصلة بنتائج البحث.
يُرجى العِلم أنّه يتم أيضًا مشاركة مسار عنوان URL /search مع تنسيقات مختلفة
من نتائج "بحث Google"، مع تحديد مَعلمات طلب البحث في عنوان URL لنوع
معيّن من نتائج البحث المعروضة. وتستخدم بعض هذه الإصدارات
قواعد بيانات مختلفة تمامًا عن صفحة نتائج البحث التقليدية على الويب. على سبيل المثال، يتم عرض "بحث الصور"
و"بحث Shopping" ضمن مسار عنوان URL /search باستخدام مَعلمات طلب بحث مختلفة، ولكن لم تكن أي من هاتين الواجهات جاهزة لطرح تجربتها الخاصة
باستخدام مهام الخدمة (حتى الآن).
الحلّ: إنشاء إطار عمل للإرسال والتوجيه
على الرغم من توفّر بعض الاقتراحات التي تسمح بإجراء أكثر فعالية من بادئات مسار عنوان URL لتحديد نطاقات مشغّل الخدمة، واجه فريق "بحث Google" مشكلة في نشر مشغّل خدمة لم يُنفِّذ أي إجراء لمجموعة فرعية من الصفحات التي كان يتحكّم فيها.
لحلّ هذه المشكلة، أنشأ فريق "بحث Google" إطار عمل مخصّصًا للإرسال والتوجيه يمكن ضبطه للتحقّق من معايير مثل مَعلمات الطلبات في صفحة العميل، واستخدامها لتحديد مسار الرمز المبرمَج المحدد الذي يجب اتّباعه. بدلاً من الترميز الثابت للقواعد، تم تصميم النظام ليكون مرنًا ويسمح للفرق التي تشارك مساحة عنوان URL، مثل "بحث الصور" و "بحث Shopping"، بإدراج منطق الخدمة الخاص بها لاحقًا، إذا قرّرت تنفيذه.
المشكلة: النتائج والمقاييس المخصّصة
يمكن للمستخدمين تسجيل الدخول إلى "بحث Google" باستخدام حساباتهم على Google، وقد يتم تخصيص تجربة نتائج البحث استنادًا إلى بيانات حساباتهم المحدّدة. يتم تحديد المستخدمين الذين سجّلوا الدخول من خلال ملفات تعريف الارتباط للمتصفّح المحدّدة، وهي معيار قديم ومتوافق على نطاق واسع.
من سلبيات استخدام ملفات تعريف الارتباط للمتصفّح أنّها لا تظهر داخل مشغّل الخدمة، ولا تتوفّر طريقة لفحص قيمها تلقائيًا والتأكّد من عدم تغيُّرها بسبب تسجيل خروج المستخدم أو تبديل الحسابات. (يجري حاليًا جهد لمحاولة منح موظّفي الخدمة إذن الوصول إلى ملفات تعريف الارتباط، ولكن اعتبارًا من وقت كتابة هذه السطور، يُعدّ هذا النهج تجريبيًا ولا يتوفّر على نطاق واسع).
قد يؤدي عدم التطابق بين عرض عامل الخدمة للمستخدم الحالي الذي سجّل الدخول والمستخدم الفعلي الذي سجّل الدخول إلى واجهة الويب في "بحث Google" إلى ظهور نتائج بحث مخصّصة بشكل غير صحيح أو تسجيل مقاييس وعمليات تسجيل غير صحيحة. سيكون أيّ من سيناريوهات الأعطال هذه مشكلة خطيرة لفريق "بحث Google".
الحل: إرسال ملفات تعريف الارتباط باستخدام postMessage
بدلاً من انتظار إطلاق واجهات برمجة التطبيقات التجريبية وتوفير إمكانية الوصول المباشر إلى
ملفات تعريف الارتباط للمتصفّح داخل الخدمة العاملة، اتّبع فريق "بحث Google"
حلًا مؤقتًا: عند تحميل صفحة يتحكّم فيها العامل الخدمي، تقرأ الصفحة ملفات تعريف الارتباط ذات الصلة وتستخدم
postMessage()
لإرسالها إلى العامل الخدمي.
بعد ذلك، يتحقّق عامل الخدمة من قيمة ملف تعريف الارتباط الحالي مقارنةً بالقيمة التي يتوقّعها، وإذا حدث تعارض، يتّخذ خطوات لإزالة أي بيانات خاصة بالمستخدم من مساحة التخزين، ويعيد تحميل صفحة نتائج البحث بدون أي تخصيص غير صحيح.
إنّ الخطوات المحدّدة التي يتّخذها عامل الخدمة لإعادة ضبط الإعدادات إلى قاعدة أساسية هي خاصة بمتطلبات "بحث Google"، ولكن قد يكون النهج العام نفسه مفيدًا للمطوّرين الآخرين الذين يتعاملون مع البيانات المخصّصة المستندة إلى ملفات تعريف الارتباط للمتصفّحات.
المشكلة: التجارب والديناميكية
كما ذكرنا سابقًا، يعتمد فريق "بحث Google" بشكل كبير على إجراء التجارب في مرحلة الطرح، واختبار تأثيرات الرموز البرمجية والميزات الجديدة في العالم الحقيقي، قبل تفعيلها تلقائيًا. قد يكون هذا الأمر صعبًا بعض الشيء مع عامل الخدمة الثابت الذي يعتمد بشكل كبير على البيانات المخزّنة مؤقتًا، لأنّ تفعيل التجارب وتفعيلها لدى المستخدمين غالبًا ما يتطلّب التواصل مع خادم الخلفية.
الحل: نص عامل الخدمة الذي يتم إنشاؤه ديناميكيًا
كان الحل الذي اتّبعه الفريق هو استخدام نص برمجي لعامل الخدمة يتم إنشاؤه ديناميكيًا، والذي يخصّص خادم الويب لكل مستخدم فردي، بدلاً من نص برمجي واحد ثابت لعامل الخدمة يتم إنشاؤه مسبقًا. يتم تضمين معلومات عن التجارب التي قد تؤثّر في سلوك worker الخدمة أو طلبات الشبكة بشكل عام مباشرةً في نصوص worker الخدمة المخصّصة هذه. يتم تغيير مجموعات التجارب النشطة للمستخدم من خلال مزيج من الأساليب التقليدية، مثل ملفات تعريف الارتباط للمتصفّح، بالإضافة إلى عرض الرمز المعدَّل في عنوان URL المسجَّل لعامل الخدمة.
يسهّل استخدام نص برمجي لعامل الخدمة تم إنشاؤه ديناميكيًا أيضًا توفير طريقة للخروج من مشكلة في حال حدوث خطأ فادح في تنفيذ عامل الخدمة يجب تجنّبه. يمكن أن يكون استجابة العامل الديناميكي للخدمة على الخادم تنفيذًا بدون إجراء، مما يؤدي إلى إيقاف العامل بشكل فعّال لبعض المستخدمين الحاليين أو جميعهم.
المشكلة: تنسيق التعديلات
إنّ أحد أصعب التحديات التي تواجه أي عملية نشر لخدمة عامل الخدمة في الحياة الواقعية هو وضع مفاضلة معقولة بين تجنُّب استخدام الشبكة لصالح ذاكرة التخزين المؤقت، وفي الوقت نفسه، ضمان حصول المستخدمين الحاليين على التحديثات والتغييرات المهمة بعد نشرها في قناة الإصدار العلني. تعتمد قيمة الرصيد الصحيحة على الكثير من العوامل:
- ما إذا كان تطبيق الويب هو تطبيق صفحة واحدة يبقى مفتوحًا لفترة طويلة بدون الانتقال إلى صفحات جديدة
- وتيرة نشر التعديلات على خادم الويب في الخلفية
- ما إذا كان المستخدم العادي سيقبل استخدام إصدار قديم قليلاً من تطبيق الويب الخاص بك، أو ما إذا كانت الحداثة هي أهم أولوياتك
أثناء تجربة مهام الخدمة، حرص فريق محرّك بحث 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 يجب تحميلها وتنفيذها قبل أن يتلقّى تطبيق الويب ردودًا على طلباته. إذا كانت هذه الردود تأتي من ذاكرة تخزين مؤقت محلي بدلاً من الشبكة، تكون النفقات العامة لتشغيل الخدمة العاملة عادةً ضئيلة مقارنةً بتحسين الأداء من خلال استخدام ذاكرة التخزين المؤقت أولاً. ولكن إذا كنت تعلم أنّه على الخدمة العاملة دائمًا الرجوع إلى الشبكة عند معالجة طلبات التنقّل، فإنّ استخدام ميزة "التحميل المُسبَق للتنقّل" يؤدي إلى تحسين الأداء بشكل كبير.
لا تزال مهام الخدمة تحسينًا تدريجيًا
لقد تحسّنت قصة دعم "خدمة Worker" كثيرًا اليوم مقارنةً بما كانت عليه قبل عام. تتضمّن جميع المتصفحات الحديثة الآن بعض الميزات التي تتيح استخدام مهام الخدمة، ولكن لا يتم طرح بعض ميزات مهام الخدمة المتقدّمة، مثل مزامنة الخلفية وتحميل التنقّل مسبقًا، بشكل موحّد. يبقى التحقّق من الميزات للمجموعة الفرعية المحدّدة من الميزات التي تحتاج إليها، وتسجيل عامل الخدمة فقط عند توفّرها، هو نهج معقول اتّباعه.
وبالمثل، إذا أجريت تجارب على الأجهزة المتوفّرة في السوق، وكنت تعلم أنّ الأداء على الأجهزة المنخفضة التكلفة ينتهي بشكلٍ سيئ بسبب النفقات الإضافية لعامل الخدمة، يمكنك الامتناع عن تسجيل عامل خدمة في هذه السيناريوهات أيضًا.
يجب مواصلة التعامل مع مهام الخدمة على أنّها تحسين تدريجي تُضاف إلى تطبيق ويب عند استيفاء جميع المتطلبات الأساسية وإضافة مهام الخدمة إلى تجربة المستخدم والأداء العام لتحميل المحتوى.
قياس كل شيء
إنّ الطريقة الوحيدة لمعرفة ما إذا كان طرح عامل خدمة قد أدى إلى أثر إيجابي أو سلبي على تجارب المستخدمين هي إجراء التجربة وقياس النتائج.
تعتمد تفاصيل إعداد القياسات المفيدة على مقدّم خدمة الإحصاءات الذي تستخدمه، وطريقة إجراء التجارب عادةً في إعداد عملية النشر. أحد النهجَين، وهو استخدام "إحصاءات Google" لجمع المقاييس، يتم شرحه بالتفصيل في هذه الدراسة الحالة استنادًا إلى تجربة استخدام مهام الخدمة في تطبيق الويب Google I/O.
الصفحات غير المقصودة
على الرغم من أنّ الكثيرين في منتدى تطوير الويب يربطون مشغّلات الخدمات بتطبيقات الويب التقدّمية، لم يكن إنشاء "تطبيق ويب تقدّمي من "بحث Google" هدفًا أوليًا للفريق. لا يقدّم تطبيق الويب "بحث Google" حاليًا بيانات وصفية من خلال ملف بيان تطبيق الويب، ولا يشجّع المستخدمين على تنفيذ عملية الإضافة إلى الشاشة الرئيسية. يشعر فريق "بحث Google" حاليًا بالرضا عن المستخدمين الذين ينتقلون إلى تطبيق الويب من خلال نقاط الدخول التقليدية لمحرك بحث Google.
بدلاً من محاولة تحويل تجربة الويب في "بحث Google" إلى ما يعادل التجربة التي تتوقّعها من تطبيق مثبّت، كان التركيز في عملية الطرح الأولية على تحسين الموقع الإلكتروني الحالي بشكل تدريجي.
الشكر والتقدير
نشكر فريق تطوير الويب في "بحث Google" بأكمله على عمله في تنفيذ مهام الخدمة، وعلى مشاركة المواد الأساسية التي تم استخدامها في كتابة هذه المقالة. نشكر بشكل خاص "فيليب غول" و"راجيش جاغاناثان" و"آر". سامويل كلاتشكو، وأندي مارتون، وليونارد بينيا، وراشيل شيرر، وغريج تيرونو، وكلاي وولام
تعديل (تشرين الأول/أكتوبر 2021): منذ نشر هذه المقالة في الأصل، أعاد فريق "بحث Google" تقييم مزايا بنية "عامل الخدمة" الحالية ومفاضلاتها. سيتم إيقاف الخدمة الموضّحة أعلاه نهائيًا. مع تطور البنية الأساسية لصفحات الويب في "بحث Google"، قد يعيد الفريق النظر في تصميم مشغّل الخدمة.