جذب عاملي الخدمات إلى "بحث Google"

قصة ما تم شحنه، وكيف تم قياس التأثير، والمقايضات التي تم إجراؤها.

الخلفية

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

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

الأسباب الرئيسية لاستكشاف عمال الخدمة

يجب وضع مجموعة واضحة من الأهداف في الاعتبار عند إضافة عامل خدمات إلى تطبيق ويب، تمامًا مثل إجراء أي تغيير معماري على موقعك الإلكتروني. بالنسبة إلى فريق "بحث Google"، كانت هناك بضعة أسباب رئيسية تجعل إضافة عامل خدمات تستحق الاستكشاف.

تخزين مؤقت محدود لنتيجة البحث

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

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

تجربة مفيدة بلا إنترنت

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

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

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

التخزين المؤقت وعرض محتوى JavaScript بشكل أذكى

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

باستخدام قدرة مشغّل الخدمة على إصدار وتخزين أجزاء دقيقة من JavaScript في وقت التشغيل، شكك فريق "بحث Google" في أنّ بإمكانهم تقليل مقدار إيقاف ذاكرة التخزين المؤقت والتأكّد من إمكانية تخزين JavaScript المُعاد استخدامها في المستقبل بكفاءة. ويمكن لمنطق عامل الخدمة التابع له تحليل طلب HTTP صادر لحزمة تحتوي على وحدات JavaScript متعددة، وتنفيذه من خلال تجميع وحدات متعددة مخزنة مؤقتًا محليًا، ما يؤدي إلى "إلغاء التجميع" بشكل فعال إن أمكن. ويوفر هذا النطاق الترددي للمستخدم، ويحسن الاستجابة العامة.

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

التحديات والحلول

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

المشكلة: النفقات العامة لعامل الخدمات

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

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

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

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

الحل: استخدام ميزة "التحميل المُسبَق" للتنقّل

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

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

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

مساحة التخزين المتاحة هي اعتبار آخر، نظرًا لأن المجموعة الكاملة من الموارد التي سيتم تخزينها مؤقتًا لاستخدامها في المستقبل يمكن أن تصل إلى عدة ميغابايت. تتيح واجهة navigator.storage لصفحة "بحث Google" أن تحدد مقدمًا ما إذا كانت محاولات المستخدمين للتخزين المؤقت للبيانات عرضة للفشل بسبب عدم اكتمال حصة التخزين.

نتيجةً لذلك، توفّر لفريق "بحث Google" عدة معايير يمكنهم استخدامها لتحديد ما إذا كان سيتم الاستعانة بمشغّل خدمات أم لا: إذا انتقل المستخدم إلى صفحة "بحث Google" باستخدام متصفّح متوافق مع ميزة "التحميل المُسبق للتنقل" ويشتمل على ذاكرة وصول عشوائي (RAM) بسعة 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 Search، في خفض منطق ظهور عاملي الخدمات إذا قرّروا تنفيذه.

المشكلة: النتائج والمقاييس المخصصة

يمكن للمستخدمين تسجيل الدخول إلى "بحث Google" باستخدام حساباتهم على Google، وقد يتم تخصيص تجربة نتائج البحث استنادًا إلى بيانات حساباتهم الخاصة. يتم تحديد المستخدمين الذين سجّلوا الدخول من خلال ملفات تعريف ارتباط محدّدة في المتصفّح، وهو معيار مرموق ومتوافق على نطاق واسع.

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

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

الحل: إرسال ملفات تعريف الارتباط باستخدام postMessage

وبدلاً من الانتظار إلى أن يتم إطلاق واجهات برمجة التطبيقات التجريبية وتوفير إمكانية الوصول المباشر إلى ملفات تعريف الارتباط في المتصفِّح داخل مشغّل الخدمات، استخدم فريق "بحث Google" حلاً لوقت إصلاح الأخطاء وهو: عندما يتم تحميل صفحة يتحكم فيها عامل الخدمة، تقرأ الصفحة ملفات تعريف الارتباط ذات الصلة وتستخدم postMessage() لإرسالها إلى مشغّل الخدمة.

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

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

المشكلة: التجارب والديناميكية

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

الحل: نص برمجي لمشغِّل الخدمات الذي تم إنشاؤه ديناميكيًا

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

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

المشكلة: تنسيق التحديثات

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

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

أثناء إجراء التجارب على مقدِّمي الخدمات، حرص فريق "بحث Google" على تنفيذ التجارب عبر عدد من التحديثات المجدولة في الخلفية بهدف ضمان تطابُق المقاييس وتجربة المستخدم مع ما قد يراه المستخدمون العائدون في نهاية المطاف.

الحل: تحقيق التوازن بين حداثة المحتوى واستخدام ذاكرة التخزين المؤقت

بعد اختبار عدد من خيارات الإعداد المختلفة، تبيّن لفريق "بحث Google" أنّ الإعداد التالي يوفّر التوازن الصحيح بين الحداثة واستخدام ذاكرة التخزين المؤقت.

يتم عرض عنوان URL للنص البرمجي لمشغّل الخدمات مع عنوان الاستجابة Cache-Control: private, max-age=1500 (1500 ثانية أو 25 دقيقة)، ويتم تسجيله من خلال updateViacache مع ضبطه على "all" للتأكّد من مراعاة العنوان. إنّ الواجهة الخلفية للويب في "بحث Google" هي كما تتخيل، مجموعة كبيرة وموزّعة على مستوى العالم من الخوادم التي تتطلّب مدة تشغيل تصل إلى% 100 تقريبًا. يتم نشر تغيير من شأنه أن يؤثر في محتوى النص البرمجي لعامل الخدمة بشكل منتظم.

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

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

في حين أنّ بعض التفاعلات داخل تطبيق الويب "بحث Google" تستخدم عمليات التنقّل بنمط التطبيق من صفحة واحدة (أي عبر واجهة برمجة التطبيقات للسجلّ)، إنّ "بحث Google" في معظم الأحيان هو تطبيق ويب تقليدي يستخدم التنقّل "الحقيقي". بدأت هذه العملية عندما قرر الفريق أن استخدام خيارين يسرّع من وتيرة عملية تحديث عاملي الخدمات سيكون مفيدًا وclients.claim() وskipWaiting(). يؤدي النقر حول واجهة "بحث Google" بشكل عام إلى الانتقال إلى مستندات HTML جديدة. إنّ طلب البيانات من خلال الرقم skipWaiting يضمن حصول عامل الخدمة المحدَّث على فرصة معالجة طلبات التنقّل الجديدة هذه على الفور بعد التثبيت. وبالمثل، يعني استدعاء الدالة clients.claim() أنّ عامل الخدمة الذي تم تحديثه سيحصل على فرصة لبدء التحكّم في أي صفحات مفتوحة على "بحث Google" لا يمكن التحكّم فيها بعد تفعيل مشغّل الخدمات.

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

الخلاصات الرئيسية

وفقًا للإعدادات التلقائية، لا يتعامل موظفو الخدمة بالحياد للأداء.

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

عاملو الخدمة (لا يزالون) عبارة عن تحسين تدريجي

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

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

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

قياس كل شيء

الطريقة الوحيدة التي يمكنك من خلالها معرفة ما إذا كان الشحن لمشغِّل الخدمات قد كان له تأثير إيجابي أو سلبي على تجارب المستخدمين هي إجراء التجارب وقياس النتائج.

تعتمد تفاصيل إعداد قياسات مفيدة على مزوّد التحليلات الذي تستعين به، والطريقة التي تجري بها عادةً التجارب في إعداد النشر. إحدى المناهج هي استخدام "إحصاءات Google" لجمع المقاييس، وقد تم توضيحها بالتفصيل في دراسة الحالة هذه بناءً على تجربة استخدام موظفي الخدمات في تطبيق الويب لمؤتمر Google I/O.

عدم الأهداف

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

وبدلاً من محاولة تحويل تجربة الويب على "بحث Google" إلى تجربة مماثلة لما كنت تتوقّعه من أحد التطبيقات المثبّتة، ركّزنا على عملية الطرح الأولي في تحسين الموقع الإلكتروني الحالي تدريجيًا.

شكر وتقدير

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

تعديل (تشرين الأول/أكتوبر 2021): بما أنّه تم نشر هذه المقالة في الأصل، أعاد فريق "بحث Google" تقييم المزايا والمفاضلات بين بنية موظفي الخدمات الحالية. ستتم إزالة مشغّل الخدمات المذكور أعلاه. مع تطوّر البنية الأساسية على الويب في "بحث Google"، قد يراجع الفريق تصميم العاملين في مجال الخدمات.