Web Workers في JavaScript للمتوسط: شغّل عمليات ثقيلة بدون ما تجمّد المتصفح

// csv-worker.js
self.onmessage = (event) => {
  const { fileText } = event.data;
  const rows = fileText.split('\n');
  const result = [];

  for (let i = 1; i < rows.length; i++) {
    const cols = rows[i].split(',');
    if (cols.length < 3) continue;
    result.push({
      date: cols[0],
      product: cols[1],
      amount: parseFloat(cols[2]),
    });

    if (i % 50000 === 0) {
      self.postMessage({ type: 'progress', percent: (i / rows.length) * 100 });
    }
  }

  self.postMessage({ type: 'done', result });
};

الخطوة 2: شغّل الـ Worker من الـ main thread

الخطوة 3: اقيس الفرق

على ملف CSV 82MB، Chrome 130، MacBook Air M2:

• بدون Worker: UI مجمّد 4,180ms، الـ scroll مش شغّال، 0 fps خلال الـ parsing.
• بـ Worker: UI شغّال 60fps طول الوقت، main thread واقف بس 18ms (بتاع الـ postMessage)، الـ progress bar شغّال طبيعي.

Trade-offs لازم تعرفها قبل ما تستخدمها

Web Workers مش حل سحري. كل توصية ليها ثمنها:

1. Serialization مش مجاني. postMessage بينسخ البيانات بـ Structured Clone. لو بتبعت array فيها مليون object، النسخ نفسه بياخد 200-400ms. الـ Transferable Objects (مثل ArrayBuffer) بتنقل الملكية بدون نسخ، بس مش كل البيانات بتدعمها.
2. مفيش DOM. الـ Worker مش هيقدر يعدّل HTML أو يقرا قيمة من input. لازم ترجّع البيانات للـ main thread وهو اللي يلمس الـ DOM.
3. تكلفة تشغيل. فتح Worker بياخد 5-15ms ثبات. لو هتعمل عملية أصلًا بتاخد 30ms، الـ Worker بيضيع وقت أكتر مما يوفّر.
4. Debugging أصعب. الـ stack trace في الـ Worker منفصل. لازم تفتح Sources tab في DevTools وتختار الـ Worker يدويًا.

أفضل حالات استخدام Web Workers

• Parsing ملفات كبيرة: CSV, JSON, XML أكتر من 5MB.
• Image processing: filters, resize, compression قبل الرفع.
• Cryptography: hashing, encryption لكميات بيانات كبيرة.
• تحليل بيانات: aggregations, sorting على آلاف الصفوف.
• WebAssembly heavy compute: physics simulations, video encoding.

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

الافتراض إن العملية ثقيلة فعلًا. لو الكود بتاعك:

• بياخد أقل من 50ms على main thread → سيب الكود مكانه. الـ Worker overhead أكبر من المكسب.
• محتاج DOM access مباشر → Worker مش هينفع. فكّر في requestIdleCallback أو تقسيم العمل لـ chunks بـ setTimeout.
• بيتم مرة واحدة في عمر الـ session → التعقيد الإضافي مش مبرّر.
• على بيانات حجمها أقل من 1MB والوقت أقل من 100ms → الفرق مش هيتحس بصريًا.

الـ trade-off الحقيقي: Web Worker بيشيل العبء عن main thread، بس بيضيف تعقيد في الـ build (Vite, webpack محتاجة config) وفي الـ debugging. لو dashboard بسيط بيشتغل تمام، متعقّدش الكود من غير سبب.

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

افتح المشروع بتاعك، دوّر على أبطأ عملية في الـ frontend (الأغلب parsing أو filtering على مصفوفة كبيرة)، وقيس زمنها بـ performance.now(). لو طلع أكتر من 100ms، انسخ الـ template اللي فوق وحوّلها لـ Worker. لو الزمن أقل من 50ms، اتركها — التوازي مش حل لكل مشكلة.

المصادر

• HTML Living Standard — Web Workers (WHATWG)
• MDN — Using Web Workers
• Structured Clone Algorithm — WHATWG
• MDN — Transferable Objects
• Vite Documentation — Web Workers
• web.dev — When to use Web Workers (Surma, Google)