Web Worker — ভারী কাজ আলাদা thread-এ, পাতা থাকে সচল

১ · Main thread-এর ঘাড়ে সব কাজ — কেন পাতা জমে যায়

পর্ব ৩১-এ দেখেছেন, ব্রাউজারে আপনার JavaScript চলে main thread-এ। কিন্তু এই thread শুধু আপনার কোডের নয়। ক্লিক আর কী-চাপ সামলানো, style হিসাব, layout, পর্দা আঁকা — সব এখানেই হয়। ফলে কোনো একটি callback যদি দুই সেকেন্ড ধরে হিসাব করে, এই দুই সেকেন্ড ব্রাউজার আর কিছুই করতে পারে না। ঘুরতে থাকা লোডিং চিহ্ন (spinner) থেমে যায়, বোতাম চাপলে সাড়া আসে না। ৫০ ms-এর বেশি এমন কাজকে বলে long task, আর এতে পাতার INP খারাপ হয়।

পর্ব ৩১-এ একটি সমাধান দেখেছেন: কাজ টুকরো করে মাঝে মাঝে main thread ছেড়ে দেওয়া, যাকে বলে chunking. কিন্তু হিসাব যদি সত্যিই বিশাল হয় — দশ লাখ অর্ডারের বিক্রির রিপোর্ট, একটি ১২ মেগাপিক্সেল ছবিতে ফিল্টার, বড় ফাইলের hash — তখন টুকরো করলেও মোট কাজ একই thread-এই হয়। দরকার আরেকটি thread. সেটিই Web Worker.

Worker একটি সত্যিকারের আলাদা thread — অপারেটিং সিস্টেম তাকে আরেকটি CPU core-এ চালাতে পারে। তাই এটি concurrency নয়, সত্যিকারের parallelism: একই মুহূর্তে main thread পাতা আঁকছে, আর Worker হিসাব করছে। প্রতিটি Worker-এর আছে নিজের event loop, নিজের heap, নিজের global object. সে পাতার DOM ছুঁতে পারে না, main thread-এর variable-ও দেখতে পায় না। যোগাযোগের একটিই পথ: বার্তা পাঠানো।

নিচের ডায়াগ্রামে একই ঘটনা দুইভাবে দেখুন — একটি অনলাইন দোকানের অ্যাডমিন পাতায় “বিক্রির রিপোর্ট বানান” বোতাম, যার হিসাবে ২ সেকেন্ড লাগে। প্রথম তিন ধাপ Worker ছাড়া, পরের তিন ধাপ Worker দিয়ে।

২ · প্রথম Worker — new Worker, postMessage আর onmessage

সবচেয়ে সাধারণ ধরন হলো dedicated worker — একটি পাতা তাকে তৈরি করে, শুধু সেই পাতাই তার সাথে কথা বলে। দুটি ফাইল লাগে: পাতার নিজের কোড, আর Worker-এর কোড আলাদা একটি ফাইলে। আগের রিপোর্টের উদাহরণটাই লিখি:

// main.js — পাতার কোড (main thread)
const worker = new Worker("report-worker.js");

reportBtn.addEventListener("click", () => {
  spinner.hidden = false;
  worker.postMessage({ type: "sales-report", month: "2026-10" });
});

worker.addEventListener("message", (event) => {
  spinner.hidden = true;
  totalEl.textContent = `মোট বিক্রি: ${event.data.total} টাকা`;
});

// report-worker.js — আলাদা thread-এ চলে
self.addEventListener("message", (event) => {
  const { month } = event.data;
  const orders = loadOrders(month);        // ধরুন দশ লাখ অর্ডার
  let total = 0;
  for (const o of orders) total += o.price * o.qty;
  self.postMessage({ month, total });      // ফল ফেরত পাঠানো
});

Module worker — import ব্যবহার করতে

পুরোনো ধরনের (classic) Worker-এ অন্য ফাইল আনতে হয় importScripts("a.js") দিয়ে, যা synchronous আর সব নাম global-এ ঢেলে দেয়। আধুনিক উপায় হলো Worker-কে ES module হিসেবে চালানো:

// পাতায়
const worker = new Worker(new URL("./report-worker.js", import.meta.url), { type: "module" });

// report-worker.js-এর ভেতরে এখন import চলে
import { sumOrders } from "./math.js";

৩ · বার্তায় কী যায় — structured clone, তার খরচ আর transfer

Main thread আর Worker কোনো মেমরি ভাগ করে না। তাহলে postMessage({ orders }) করলে orders কীভাবে ওপারে যায়? ব্রাউজার ডেটাটির একটি গভীর কপি বানায় — পর্ব ১৯-এ দেখা structuredClone-এর একই নিয়মে, যার নাম structured clone algorithm. ফলে ওপারে যা পৌঁছায় তা সম্পূর্ণ আলাদা একটি object; Worker সেটি বদলালে main thread-এর আসলটা বদলায় না।

• যা কপি হয়: সাধারণ object, array, string, number, BigInt, Date, RegExp, Map, Set, ArrayBuffer, typed array, Blob, File, ImageData, Error, এমনকি circular reference.
• যা যায় না: function, DOM node — postMessage সাথে সাথে DataCloneError ছোড়ে। আর class-এর instance পৌঁছায় সাধারণ object হয়ে — method আর prototype হারিয়ে।
• খরচ: কপি করতে সময় লাগে, আর সেই কপি বানানো (serialize) চলে পাঠানো thread-এই। কয়েক KB-র বার্তা টেরই পাবেন না; কিন্তু দশ লাখ object-এর array পাঠালে কপি করতেই main thread শত মিলিসেকেন্ড আটকে থাকতে পারে, আর মেমরিও দ্বিগুণ লাগে।

বড় বাইনারি ডেটার (ছবির pixel, অডিও, ফাইলের bytes) জন্য আছে আরেকটি পথ: transferable object. postMessage(msg, [buffer]) — দ্বিতীয় argument-এ যে ArrayBuffer-এর তালিকা দেবেন, সেগুলো কপি হয় না, শুধু মালিকানা বদলায়। কাজটি প্রায় তাৎক্ষণিক, ডেটা যত বড়ই হোক। দাম একটাই: পাঠানোর পর আপনার হাতের buffer-টি detached হয়ে যায় — byteLength হয় ০, আর তার ওপর বানানো typed array-ও খালি।

এবার নিজে চালিয়ে দেখুন। এই পাতার কোড-রানার অন্য ফাইল আনতে পারে না, তাই Worker-এর কোড একটি string থেকে Blob URL বানিয়ে দেওয়া হয়েছে — আসল প্রজেক্টে আলাদা ফাইলই ভালো। Main thread একটি ভারী কাজ পাঠায় (২,০০,০০০-এর নিচে কয়টি মৌলিক সংখ্যা), সাথে একটি ছোট ArrayBuffer transfer করে:

const workerCode = `
  self.onmessage = (e) => {
    const { limit, buf } = e.data;
    let count = 0;
    outer: for (let n = 2; n < limit; n++) {
      for (let d = 2; d * d <= n; d++) if (n % d === 0) continue outer;
      count++;
    }
    self.postMessage({ count, got: buf.byteLength });
  };`;
const url = URL.createObjectURL(new Blob([workerCode], { type: "text/javascript" }));
const worker = new Worker(url);
worker.onmessage = (e) => {
  console.log("৩. worker-এর উত্তর:", e.data);
  worker.terminate();
  URL.revokeObjectURL(url);
};
worker.onerror = (e) => console.log("worker error:", e.message);
const buf = new ArrayBuffer(1024);
worker.postMessage({ limit: 200_000, buf }, [buf]);
console.log("১. কাজ পাঠানো হলো; buf.byteLength এখন", buf.byteLength);
console.log("২. main thread মুক্ত — ক্লিক, আঁকা সব চলছে");

৪ · Worker-এর ভেতরের জগৎ — কী আছে, কী নেই, ভুল হলে কী হয়

Worker-এর global object হলো WorkerGlobalScope (dedicated worker-এ DedicatedWorkerGlobalScope), যাকে self বা globalThis দিয়ে পাওয়া যায়। এখানে ভাষার সব কিছু আছে — Promise, async/await, class, Map — আর অনেক Web API-ও আছে। নেই শুধু সেগুলো, যা পাতা বা জানালার সাথে জড়িত:

DOM কেন নেই? কারণ DOM কোনো thread-safe কাঠামো নয়। দুই thread একসাথে একই node বদলাতে পারলে প্রতিটি node-এ lock লাগত — পর্ব ৩১-এর ভাবনার প্রশ্নে দেখেছেন, GUI-জগৎ ঠিক এটাই এড়াতে চায়। তাই নিয়ম: Worker হিসাব করে, main thread আঁকে। Worker ফল পাঠায়, আর main thread সেই ফল দিয়ে DOM বদলায়।

ভুল হলে — error আর messageerror

Worker-এর ভেতরে uncaught exception হলে Worker মরে না, কিন্তু পাতার কোডও কিছু জানে না — যদি আপনি না শোনেন। Main thread-এ Worker object-এ একটি error event আসে (ErrorEvent — message, filename, lineno সহ)। আর যদি কোনো বার্তা ওপারে গিয়ে আর deserialize করা না যায়, আসে messageerror event — এটি বিরল, কিন্তু চুপচাপ হারিয়ে যাওয়া বার্তার একমাত্র চিহ্ন।

worker.addEventListener("error", (e) => {
  e.preventDefault();               // পাতার window.onerror পর্যন্ত যাওয়া বন্ধ
  showToast(`রিপোর্ট বানানো গেল না: ${e.message}`);
});
worker.addEventListener("messageerror", () => showToast("বার্তা পড়া গেল না"));

// Worker-এর ভেতরে: নিজে ধরে কাঠামোবদ্ধ উত্তর পাঠানো আরও ভালো
self.onmessage = (e) => {
  try { self.postMessage({ ok: true, result: heavyWork(e.data) }); }
  catch (err) { self.postMessage({ ok: false, error: err.message }); }
};

বন্ধ করা — terminate() আর self.close()

একটি Worker নিজে থেকে বন্ধ হয় না; পাতা খোলা থাকা পর্যন্ত সে মেমরি ধরে রাখে। বন্ধ করার দুই উপায়: বাইরে থেকে worker.terminate() — সাথে সাথে থামায়, চলমান হিসাব মাঝপথে ফেলে দেয়, কোনো শেষ বার্তাও আসে না; আর ভেতর থেকে self.close() — Worker নিজের কাজ শেষ করে বিদায় নেয়। ব্যবহারকারী “বাতিল” চাপলে বা অন্য পাতায় চলে গেলে terminate() খুব কাজের — যেমন ১৫ সেকেন্ডের রিপোর্ট আর দরকার নেই, তাহলে CPU আর ব্যাটারি কেন খরচ হবে?

৫ · Worker-কে function-এর মতো ডাকা — id আর Promise দিয়ে ছোট RPC

এক ধরনের কাজ হলে onmessage-এ সরাসরি ফল বসানো চলে। কিন্তু বাস্তবে একই Worker-কে নানা কাজ দেওয়া হয়: রিপোর্ট, খোঁজা, export. একসাথে দুটি অনুরোধ পাঠালে আর ছোটটি আগে শেষ হলে, উত্তর আসে উল্টো ক্রমে। তখন কোন উত্তর কোন প্রশ্নের? সমাধান: প্রতিটি অনুরোধে একটি অনন্য id দিন, উত্তরেও সেই id ফেরত নিন, আর main thread-এ id অনুযায়ী অপেক্ষমাণ Promise পূর্ণ করুন। ফলে Worker-কে ডাকা যায় এভাবে: const r = await callWorker("report", data). একে বলে RPC (remote procedure call) — অন্য জায়গায় চলা কোডকে সাধারণ function-এর মতো ডাকা। Promise তৈরির খুঁটিনাটি পর্ব ৩৩-এ।

এবার পুরো ব্যবস্থাটা চালিয়ে দেখুন। Worker ইচ্ছা করে রিপোর্টে ৪০০ ms আর খোঁজায় ৫০ ms দেরি করে, যাতে উত্তর উল্টো ক্রমে আসে:

const src = `
  self.onmessage = ({ data: { id, type, payload } }) => {
    const result = type === "report"
      ? payload.reduce((sum, x) => sum + x, 0)
      : ["shirt", "shoe", "saree"].filter((p) => p.startsWith(payload));
    const delay = type === "report" ? 400 : 50;   // রিপোর্ট ধীর, খোঁজা দ্রুত
    setTimeout(() => self.postMessage({ id, result }), delay);
  };`;
const worker = new Worker(URL.createObjectURL(new Blob([src], { type: "text/javascript" })));
const pending = new Map(); let nextId = 1;        // id → resolve
worker.onmessage = ({ data: { id, result } }) => {
  console.log("উত্তর এল, id =", id);
  pending.get(id)(result);
  pending.delete(id);
};
const callWorker = (type, payload) => new Promise((resolve) => {
  const id = nextId++;
  pending.set(id, resolve);
  worker.postMessage({ id, type, payload });
});
callWorker("report", [1200, 850, 430]).then((r) => { console.log("রিপোর্ট:", r); worker.terminate(); });
callWorker("search", "sh").then((r) => console.log("খোঁজা:", r));

৬ · বাস্তব কাজে Worker — আর কখন Worker দরকার নেই

কোন কাজ Worker-এ যাওয়ার যোগ্য? যে কাজ CPU-bound (অপেক্ষা নয়, হিসাব করে সময় নেয়), DOM-এর দরকার নেই, আর শত মিলিসেকেন্ড বা তার বেশি লাগে। কয়েকটি বাস্তব উদাহরণ:

Worker pool — একাধিক core কাজে লাগানো

একটি Worker মানে একটি বাড়তি core. ২০টি ছবির থাম্বনেইল বানাতে হলে কয়েকটি Worker একসাথে চালানো যায় — একে বলে worker pool, Node.js-এর libuv-এর thread pool-এর মতোই চিন্তা। ব্রাউজার জানায় যন্ত্রে কয়টি logical core আছে: navigator.hardwareConcurrency. সাধারণ নিয়ম: core-এর সংখ্যা থেকে একটি কম (main thread-এর জন্য), আর একটি যুক্তিসঙ্গত সর্বোচ্চ সীমা। প্রতিটি কাজের জন্য নতুন Worker নয় — pool একবার বানিয়ে বারবার ব্যবহার।

কখন Worker-এর খরচ লাভের চেয়ে বেশি

• ছোট কাজ: একটি Worker চালু হতে (ফাইল আনা, parse, নতুন JavaScript পরিবেশ) কয়েক থেকে কয়েক দশ মিলিসেকেন্ড আর কয়েক MB মেমরি লাগে। প্রতিটি বার্তায় কপির খরচ আছে। ৫ ms-এর হিসাব Worker-এ পাঠালে আসা-যাওয়াতেই বেশি সময় যায়।
• DOM-নির্ভর কাজ: ধীরতার কারণ যদি হাজারটা DOM node বানানো বা layout হয়, Worker সাহায্য করতে পারে না — সেই কাজ main thread-এরই। সেখানে কম node বানানো, virtual list, বা পর্ব ৩১-এর chunking.
• অপেক্ষা-প্রধান কাজ: fetch বা timer-এর অপেক্ষা এমনিতেই main thread আটকায় না। শুধু নেটওয়ার্কের জন্য Worker লাগে না।
• বিশাল ডেটার বারবার আসা-যাওয়া: প্রতিবার ৫০ MB-র object কপি হলে লাভ শেষ। ডেটা Worker-এই রাখুন, বা transfer করুন।

৭ · আরও গভীরে — shared worker, SharedArrayBuffer, OffscreenCanvas আর Node.js

Shared worker

Shared worker (new SharedWorker("hub.js")) একই origin-এর একাধিক tab বা iframe ভাগ করে ব্যবহার করে। প্রতিটি সংযোগ পায় একটি port, আর Worker-এর ভেতরে connect event দিয়ে নতুন tab চেনা যায়। ব্যবহার: পাঁচটি tab খোলা থাকলেও সার্ভারের সাথে একটিমাত্র WebSocket সংযোগ রাখা। সমর্থন সমান নয় — বিশেষ করে Android-এর Chrome-এ দীর্ঘদিন এটি ছিল না — তাই feature detection আর fallback রাখতে হয়।

SharedArrayBuffer আর Atomics — সত্যিকারের ভাগ করা মেমরি

এতক্ষণের নিয়ম ছিল “কিছুই ভাগ হয় না”। ব্যতিক্রম SharedArrayBuffer: এটি postMessage করলে কপি বা transfer হয় না — দুই thread একই bytes দেখে। একজন লিখলে অন্যজন সাথে সাথে দেখে। তখনই ফিরে আসে C++ আর Java-র পুরোনো সমস্যা — দুজন একসাথে লিখলে ডেটা নষ্ট। তাই সাথে আছে Atomics: Atomics.add, Atomics.compareExchange ভাঙা যায় না এমন এক ধাপে পড়া-লেখা করে, আর Atomics.wait/Atomics.notify দিয়ে এক thread অন্যটির জন্য ঘুমিয়ে অপেক্ষা করতে পারে (main thread-এ wait নিষিদ্ধ — পাতা আটকে যাবে)।

২০১৮ সালে Spectre আবিষ্কারের পর ব্রাউজারগুলো SharedArrayBuffer বন্ধ করে দিয়েছিল (ভাবনার প্রশ্ন ২)। এখন এটি পাওয়া যায় শুধু পাতা cross-origin isolated হলে — সার্ভারকে এই দুটি HTTP header পাঠাতে হয়:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

প্রথমটি (COOP) আপনার পাতাকে অন্য origin-এর জানালা (popup বা যে পাতা আপনাকে খুলেছে) থেকে আলাদা করে — কেউ কারও window-এর reference পায় না, ফলে ব্রাউজার পাতাটিকে আলাদা process-এ রাখতে পারে; দ্বিতীয়টি (COEP) বলে, যে অন্য-origin ফাইল (ছবি, script, iframe) স্পষ্ট অনুমতি দেয়নি, তা লোড হবে না। কোডে যাচাই: self.crossOriginIsolated === true. দাম আছে — অনেক বিজ্ঞাপন বা বাইরের embed এতে ভেঙে যায়। এটি উন্নত বিষয়; বেশিরভাগ অ্যাপের জন্য সাধারণ বার্তা আর transfer-ই যথেষ্ট। নিরাপত্তার header নিয়ে আরও কথা পর্ব ৪৩-এ।

OffscreenCanvas আর WebAssembly

OffscreenCanvas দিয়ে আঁকার কাজও Worker-এ নেওয়া যায়: canvas.transferControlToOffscreen() একটি OffscreenCanvas দেয়, সেটি Worker-এ transfer করলে Worker সরাসরি পর্দার সেই canvas-এ আঁকে — চার্ট, ম্যাপ বা গেমের রেন্ডারিং main thread-এর ভিড় থেকে মুক্ত থাকে। আর WebAssembly-র ভারী হিসাব (ভিডিও encode, PDF তৈরি, ছবি সম্পাদনা) প্রায় সবসময় Worker-এ চলে; একাধিক Worker আর SharedArrayBuffer মিলিয়ে WebAssembly thread — C/C++-এর pthread কোড ব্রাউজারে চলে এভাবেই।

Node.js-এ — worker_threads, cluster আর child_process

Node.js-এ একই চিন্তার নাম worker_threads (Node 12 থেকে stable). ব্রাউজারের মতোই আলাদা thread, আলাদা event loop, বার্তা দিয়ে যোগাযোগ, transfer আর SharedArrayBuffer — শুধু নামগুলো আলাদা: parentPort, workerData, আর event শোনা হয় .on("message") দিয়ে।

const { Worker } = require("node:worker_threads");

const code = `
  const { parentPort, workerData } = require("node:worker_threads");
  let total = 0;
  for (let i = 1; i <= workerData.count; i++) total += i % 1000; // নকল অর্ডারের দাম
  parentPort.postMessage(total);
`;
const w = new Worker(code, { eval: true, workerData: { count: 1_000_000 } });
w.on("message", (total) => console.log("worker-এর যোগফল:", total));
w.on("error", (err) => console.error("worker error:", err));
w.on("exit", (exitCode) => console.log("worker বন্ধ, exit code", exitCode));
console.log("main thread মুক্ত");

// প্রত্যাশিত আউটপুট:
// main thread মুক্ত
// worker-এর যোগফল: 499500000
// worker বন্ধ, exit code 0

Node-এ আরও দুটি পুরোনো উপায় আছে, যা thread নয়, আলাদা process: child_process দিয়ে অন্য প্রোগ্রাম (যেমন ffmpeg বা একটি Python script) চালানো, আর cluster দিয়ে একই সার্ভারের কয়েকটি কপি চালিয়ে একটি port ভাগ করা — প্রতিটি core-এ একটি process, প্রতিটির নিজের মেমরি। মোটা দাগে: একটি ভারী হিসাব → worker_threads; বাইরের প্রোগ্রাম → child_process; বেশি request সামলাতে সব core ব্যবহার → cluster, বা PM2-র মতো টুল, বা কয়েকটি container. Node-এর বিস্তারিত পর্ব ৪৯-এ।

তিন রকম “worker” — গুলিয়ে ফেলবেন না

সংক্ষেপে: service worker নেটওয়ার্কের পাহারাদার, Web Worker হিসাবের সহকারী, আর worklet ব্রাউজারের নিজের যন্ত্রের ভেতরে লাগানো ছোট যন্ত্রাংশ। তিনটিই আলাদা global scope-এ চলে আর DOM ছুঁতে পারে না — মিল ওইটুকুই।

৮ · AI-এর যুগে — Worker নিয়ে AI-এর পরিচিত ভুল

“পাতা ধীর, Worker দিয়ে ঠিক করো” — এমন অনুরোধে AI দ্রুত কোড দেয়, কিন্তু প্রায়ই নিচের ভুলগুলো করে। এগুলো চিনে রাখলে আপনার রিভিউ অনেক দ্রুত হবে:

AI-এর Worker কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Worker-এ পাঠানোর আগে মেপে দেখেছি কাজটি সত্যিই ৫০ ms-এর বেশি CPU নেয়
• Worker ফাইলে document, window, localStorage খুঁজে কিছু পাইনি
• বড় ArrayBuffer transfer হচ্ছে; পাঠানোর পর সেই variable কোথাও পড়া হয় না
• প্রতিটি অনুরোধে id আছে; ভুল হলে reject হয়, আর error listener আছে
• Worker একবারই তৈরি হয়; বাতিল বা পাতা ছাড়ার সময় terminate() ডাকা হয়
• DevTools-এর Performance প্যানেলে দেখেছি, main thread-এর long task সত্যিই চলে গেছে আর Worker-এর আলাদা সারিতে কাজ দেখা যাচ্ছে