Web Workers في JavaScript للمتوسط: شغّل خوارزمية ثقيلة بدون ما تجمّد الواجهة 4 ثواني

خلال الـ 4.1 ثانية، الزرار مش هيرد على ضغطة تانية، ولا الـ scroll هيشتغل. افتح Chrome DevTools → Performance → سجّل، هتلاقي شريط أحمر اسمه "Long Task" طوله ~4 ثواني.

دلوقتي بـ Worker:

ركّز هنا: الـ worker بياخد نفس الزمن تقريباً (4.1 ثانية)، لكن خلال الـ 4 ثواني دول الواجهة حية. المستخدم يعمل scroll، يكتب في input، يدوس على زراير تانية، animations شغّالة. المكسب مش زمن أقل — المكسب إن الواجهة مش متجمدة.

أرقام مقاسة من إنتاج

على dashboard داخلي بيعمل filtering لـ 120 ألف صف بـ 14 column (قياس على Chrome 122 / MacBook Pro M2):

• قبل: 4.1 ثانية تجمّد كامل، الـ INP (Interaction to Next Paint) عند 4080ms — مرفوض حسب Core Web Vitals (الحد المقبول ≤ 200ms).
• بعد: نفس الـ 4.1 ثانية حسابياً تتمّ في worker، الـ INP نزل لـ 24ms.
• تأثير على السلوك: 18% من المستخدمين كانوا بيقفلوا التبويب أثناء التجمّد، النسبة دي نزلت لـ 1.2% بعد نقل العملية للـ worker.
• تكلفة postMessage: 6ms ذهاب + 4ms عودة (نقل integer واحد). لو بترجّع array كبيرة، الزمن يزيد طبقاً للحجم.

الـ trade-offs الأربعة اللي لازم تعرفهم

1. تكلفة نقل البيانات. postMessage بيعمل deep clone كامل للبيانات (Structured Clone). لو بتبعت array فيه 50MB، الـ clone بياخد 200ms+ ويستهلك ضعف الذاكرة لحظياً. الحل: استخدم Transferable Objects زي ArrayBuffer — بتنتقل ownership بدل clone، الزمن يقرب من صفر بس الـ buffer الأصلي بيتعطّل في الـ main thread.
2. ما فيش وصول للـ DOM. الـ worker مش هيقدر يلمس عناصر HTML. لو محتاج تعدّل DOM بعد كل خطوة حساب، لازم ترجع للـ main thread، وكل رحلة ذهاب وإياب فيها تكلفة postMessage. لو الحساب نفسه قصير، التكلفة دي بتاكل المكسب.
3. تكلفة إنشاء الـ worker. new Worker() بياخد 5–30ms أول مرة (تحميل الملف + إنشاء الـ isolate). لو بتنشئ worker جديد لكل ضغطة زرار، خسرت المكسب. الحل: pool من 2–4 workers يبدأ مع تحميل الصفحة وفضلوا حيين.
4. التشخيص أصعب. الأخطاء في الـ worker مش بتظهر في نفس الـ console اللي انت متعوّد عليه إلا لو ربطت worker.onerror. الـ debugger في DevTools بيدعم workers بس الـ flow أعقد من الكود العادي.

متى لا تستخدم Web Worker

الـ worker مش حل سحري. تجنّبه في الحالات دي:

• العملية بتاخد أقل من 50ms — تكلفة postMessage هتكون قريبة من المكسب أو أكبر منه.
• محتاج تعديل DOM متكرر بعد كل خطوة — هتقعد ترجع للـ main thread كل ثانية، خسرت المكسب وكسبت تعقيد.
• محتاج وصول لـ localStorage أو document.cookie — مش متاحين داخل worker (في حدود محدودة فقط).
• بتعمل I/O خفيف زي fetch واحد بيرجع 200KB — استخدم async/await في الـ main thread، الـ I/O أصلاً non-blocking وما بيجمّد حاجة.
• بتشتغل على متصفحات أو بيئات embedded قديمة جداً ما بتدعمش Workers (نادر جداً في 2026).

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

افتح أي صفحة عندك فيها زرار بياخد أكتر من ثانية. شغّل Chrome DevTools → Performance → سجّل أثناء الضغط على الزرار. لو لقيت "Long Task" أحمر طوله أكتر من 200ms، نقّل الـ logic لـ worker.js بنفس النمط فوق. اقيس الـ INP قبل وبعد عبر web-vitals library. لو الفرق أقل من 100ms، الـ worker مش الحل عندك — راجع الـ render أو الـ network. لو الفرق ضخم، عمّمه على باقي الـ blocking buttons في التطبيق.

المصادر

• WHATWG HTML Living Standard — Web Workers (المرجع الرسمي للمواصفة)
• MDN Web Docs — Using Web Workers
• MDN — Transferable Objects (لتجنّب تكلفة الـ clone)
• web.dev — Interaction to Next Paint (INP) كمقياس Core Web Vitals
• Chrome DevTools — Performance Panel وكشف Long Tasks
• V8 Engine — Isolates و heap منفصل لكل worker