نظرة عامة على العاملين

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

Andrew Guan

Demián Renzulli

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

كيف يمكن للعاملين تحسين موقعك الإلكتروني؟

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

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

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

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

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

مشغِّلو الويب ومشغِّلو الخدمات

أوجه التشابه

مشغِّلات الويب ومشغِّلات الخدمات هما نوعان من المشغِّلات المتاحة للمواقع الإلكترونية. لديهم بعض الأشياء المشتركة:

• ويتم تشغيل كليهما في سلسلة محادثات ثانوية، ما يسمح بتنفيذ رمز JavaScript بدون حظر سلسلة المحادثات الرئيسية وواجهة المستخدم.
• ولا يمكنها الوصول إلى العنصرَين Window وDocument، لذا لا يمكنها التفاعل مع نموذج DOM مباشرةً، كما أنّ وصولها إلى واجهات برمجة التطبيقات في المتصفّح محدود.

أوجه الاختلاف

قد يعتقد البعض أنّ معظم المهام التي يمكن تفويضها إلى Web Worker يمكن تنفيذها في Service Worker والعكس صحيح، ولكن هناك اختلافات مهمة بينهما:

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

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

حالات الاستخدام

تشير الاختلافات بين كلا النوعَين من العاملين إلى الحالات التي قد يرغب فيها المستخدم في استخدام أحدهما أو الآخر:

حالات استخدام Web Workers ترتبط عادةً بنقل العمل (مثل العمليات الحسابية الثقيلة) إلى سلسلة محادثات ثانوية لتجنُّب حظر واجهة المستخدم.

• مثال: أراد الفريق الذي أنشأ لعبة الفيديو PROXX ترك سلسلة التعليمات الرئيسية خالية قدر الإمكان للاهتمام بإدخالات المستخدم والرسوم المتحركة. لتحقيق ذلك، استخدموا Web Workers لتشغيل منطق اللعبة وصيانة الحالة في سلسلة محادثات منفصلة.

مهام مشغّلي الخدمات ترتبط بشكل عام بالعمل كخادم وكيل للشبكة، والتعامل مع المهام التي تعمل في الخلفية، وأشياء مثل التخزين المؤقت والعمل بلا إنترنت.

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

يتم تعديل واجهة المستخدم للإشارة إلى مستوى تقدّم عملية التنزيل (على اليمين). بفضل مشغّلي الخدمات، يمكن أن تستمر العملية في العمل عند إغلاق جميع علامات التبويب (على اليمين).

الأدوات والمكتبات

يمكن تنفيذ الاتصال بين النافذة والعامل باستخدام واجهات برمجة تطبيقات مختلفة ذات مستوى أدنى. لحسن الحظ، هناك مكتبات تلخّص هذه العملية، وتهتم بحالات الاستخدام الأكثر شيوعًا. في هذا القسم، سنتناول اثنين من هذه الأدوات التي تهتم بالاتصال بين النافذة وعاملي الويب وعاملي الخدمة على التوالي: Comlink وWorkbox.

Comlink

Comlink هي مكتبة RPC صغيرة (1.6 ألف) تهتم بالعديد من التفاصيل الأساسية عند إنشاء مواقع إلكترونية تستخدم Web Workers. وقد تم استخدامها في مواقع إلكترونية مثل PROXX وSquoosh. يمكنك الاطّلاع على ملخّص لدوافع هذه الميزة وعيّنات من التعليمات البرمجية هنا.

Workbox

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

الخطوات التالية

تركّز بقية هذه السلسلة على أنماط التواصل بين النافذة ومشغّل الخدمات:

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

للاطّلاع على أنماط التواصل بين النافذة وعامل الويب، يمكنك مراجعة: استخدام عمال الويب لتشغيل JavaScript خارج سلسلة التعليمات الرئيسية للمتصفّح.