Web Workers বনাম Service Workers: কি এবং কেন

Web Workers vs Service Workers: সংক্ষিপ্ত ঝলক

ব্রাউজার আপনার অধিকাংশ জাভাস্ক্রিপ্ট মেইন থ্রেডে চালায়—একই জায়গায় যা ইউজার ইনপুট, অ্যানিমেশন, এবং পেজ পেইন্টিং নিয়ন্ত্রণ করে। যখন সেখানে ভারি কাজ হয় (বড় ডেটা পার্সিং, ইমেজ প্রসেসিং, জটিল হিসাব), UI আটকে বা “ফ্রিজ” করতে পারে। ওয়ার্কাররা কিছু কাজ মেইন থ্রেডের বাইরে বা পেজের সরাসরি কন্ট্রোলে না রেখে চালাতে দেয়, যাতে আপনার অ্যাপ রেসপন্সিভ থাকে।

ওয়ার্কাররা যে সমস্যা সমাধান করে

আপনার পেজ 200ms‑এর মতো কনপুটে ব্যস্ত হলে ব্রাউজার স্মুথলি স্ক্রল করতে, ক্লিক রেসপন্ড করতে, বা 60fps অ্যানিমেশন বজায় রাখতে পারে না। ওয়ার্কার আপনাকে ব্যাকগ্রাউন্ডে কাজ করতে দেয় যাতে মেইন থ্রেড ইন্টারফেসে ফোকাস রাখতে পারে।

দ্রুত সংজ্ঞা

একটি Web Worker হলো একটি ব্যাকগ্রাউন্ড জাভাস্ক্রিপ্ট থ্রেড যা আপনি একটি পেজ থেকে তৈরি করেন। এটি UI ব্লক করবে এমন CPU‑গুরুত্বপূর্ণ কাজে সেরা।

একটি Service Worker হলো বিশেষ ধরনের ওয়ার্কার যা আপনার ওয়েব অ্যাপ এবং নেটওয়ার্কের মধ্যে অবস্থান করে। এটি অনুরোধ ইন্টারসেপ্ট করতে, প্রতিক্রিয়া ক্যাশ করতে, এবং অফলাইন সাপোর্ট এবং পুশ নোটিফিকেশন মতো ফিচার সক্ষম করতে পারে।

সহজ মানসিক মডেল: “থ্রেড” বনাম “নেটওয়ার্ক প্রক্সি”

একজন Web Worker‑কে ভাবুন যেন অন্য একটি রুমে গননা করছে। আপনি এটাকে মেসেজ পাঠান, এটি কাজ করে, এবং ফিরে মেসেজ করে।

একজন Service Worker‑কে ভাবুন যেন সামনে দরজার গেটকিপার। পেজ, স্ক্রিপ্ট, এবং API অনুরোধগুলো তার পাশ দিয়ে যায়, এবং এটি সিদ্ধান্ত নিতে পারে নেটওয়ার্ক থেকে আনবে কি, ক্যাশ থেকে পরিবেশন করবে কি, বা কাস্টমভাবে প্রতিক্রিয়া দেবে কি।

এই আর্টিকেলে আপনি যা শিখবেন

শেষে আপনি জানবেন:

• কখন web worker পারফরম্যান্সের জন্য উপযুক্ত (এবং এর কোন অ্যাক্সেস নেই)\n- কি করে service worker অফলাইন ক্যাশিং, আপডেট, এবং PWA আচরণ সক্ষম করে\n- কিভাবে মেসেজিং (যেমন postMessage) ওয়ার্কার মডেলে ফিট করে, এবং কেন Cache Storage API অফলাইনের জন্য গুরুত্বপূর্ণ

এই ওভারভিউ ‘কেন’ এবং মানসিক মডেল স্থাপন করে—পরবর্তী অংশে আমরা প্রতিটি ওয়ার্কার টাইপ কিভাবে আচরণ করে এবং প্রকল্পে কোথায় ফিট করে তা বিস্তারিত দেখব।

কেন ব্রাউজারে ওয়ার্কার আছে

যখন আপনি একটি ওয়েব পেজ খুলেন, আপনি যা “অনুভব” করেন সেটির অধিকাংশই মেইন থ্রেডে ঘটে। এটি পিক্সেল ড্র করায় (রেন্ডারিং), ট্যাপ এবং ক্লিক রিয়্যাক্ট করে (ইনপুট), এবং অনেক জাভাস্ক্রিপ্ট চালায়।

মেইন থ্রেড একটি শেয়ার করা চেকআউট লাইন

রেন্ডারিং, ইনপুট হ্যান্ডলিং, এবং জাভাস্ক্রিপ্ট সাধারণত একই থ্রেডে পালা করে কাজ করে; এক ধীর কাজ সবকিছু অপেক্ষা করায়। এজন্য পারফরম্যান্স সমস্যা প্রায়শই রেসপন্সিভনেস সমস্যা হিসেবে ধরা পড়ে, কেবলমাত্র “স্লো কোড” না।

ব্লক হয়ে থাকা ব্যবহারকারীর জন্য কেমন লাগে:

• স্ক্রলিং জঙ্ক হয়\n- বাটন ততক্ষণে ক্লিক রেসপন্ড করে না\n- টাইপিং কিবোর্ডের পেছনে ল্যাগ করে\n- অ্যানিমেশন কয়েক মুহূর্তের জন্য ফ্রিজ করে

অ্যাসিঙ্ক নয় মানেই প্যারালাল নয়

জাভাস্ক্রিপ্টে অনেক অ্যাসিঙ্ক্রোনাস API আছে—fetch(), টাইমার, ইভেন্ট—যা আপনাকে সক্রিয়ভাবে অপেক্ষা না করতে সাহায্য করে। কিন্তু অ্যাসিঙ্ক মানে এই নয় যে ভারি কাজ রেন্ডারিং‑এর সাথে একই সময়ে চলে।

যদি আপনি মেইন থ্রেডে ব্যয়বহুল ক্যালকুলেশন করেন (ইমেজ প্রসেসিং, বড় JSON ক্রাঞ্চিং, ক্রিপ্টো, জটিল ফিল্টারিং), তা তখনও UI আপডেটের সাথে প্রতিযোগিতা করে। “অ্যাসিঙ্ক” কাজ চালানোর সময় পরিবর্তন করতে পারে, কিন্তু তা মেইন থ্রেডেই চললে একে কখনও‑কখনও জঙ্ক সৃষ্টি করে।

ব্রাউজার আর্কিটেকচারে ওয়ার্কারদের স্থান

ওয়ার্কাররা আছে যেন ব্রাউজার পেজটি রেসপন্সিভ রাখে এবং তবুও অর্থপূর্ন কাজ করতে পারে।

• Web Workers আপনাকে ব্যাকগ্রাউন্ড থ্রেডে জাভাস্ক্রিপ্ট চালাতে দেয় CPU‑গুরুত্বপূর্ণ কাজের জন্য।\n- Service Workers কোনো এক পেজের বাইরে চলে এবং নেটওয়ার্ক ও ক্যাশিং লেয়ার হিসেবে কাজ করে, এমনকি পেজ খোলা না থাকলেও।

সংক্ষেপে: ওয়ার্কার হলো একটি উপায় মেইন থ্রেডকে রক্ষা করার, যাতে আপনার অ্যাপ ইন্টারঅ্যাকটিভ থাকে এবং ব্যাকগ্রাউন্ডে বাস্তব কাজ করা যায়।

Web Worker কী?

একটি Web Worker হলো জাভাস্ক্রিপ্ট চালানোর একটি উপায় মেইন থ্রেডের বাইরে। মেইন থ্রেডের সাথে প্রতিযোগিতা না করে (রেন্ডারিং, স্ক্রলিং, ক্লিক‑রেসপন্স), ওয়ার্কার নিজস্ব ব্যাকগ্রাউন্ড থ্রেডে চলে যাতে ভারি কাজ শেষ হয়েও পেজ “অটক” না করে।

এটিকে এভাবে ভাবুন: পেজ ইউজার ইন্টারঅ্যাকশনে ফোকাস রাখে, আর ওয়ার্কার হ্যান্ডেল করে CPU‑গুরুত্বপূর্ণ কাজ—বড় ফাইল পার্স করা, সংখ্যার গণনা, চার্টের জন্য ডেটা প্রস্তুত করা।

কোথায় চলে

ওয়েব ওয়ার্কার একটি বিভিন্ন থ্রেডে, নিজস্ব গ্লোবাল স্কোপে চলে। এটি এখনও বেশ কিছু ওয়েব API‑তে অ্যাক্সেস পায় (টাইমার, অনেক ব্রাউজারে fetch, crypto, ইত্যাদি), কিন্তু পেজ থেকে ইচ্ছাকৃতভাবে আলাদা রাখা হয়েছে।

Dedicated Worker বনাম Shared Worker

কিছু সাধারণ ফ্লেভার আছে:

• Dedicated Worker: একটি একক পেজ/ট্যাবের সাথে সংযুক্ত। সেই পেজ গেলে, সাধারণত ওয়ার্কার বন্ধ হয়ে যায়।\n- Shared Worker: একই উৎস (origin) থেকে একাধিক পেজ/ট্যাব দ্বারা শেয়ার করা যায়, যা ট্যাবগুলোর মধ্যে কাজ সমন্বয় (একটি কেবল সংযোগ শেয়ার করা বা স্টেট সিঙ্ক) করার জন্য উপযোগী।

যদি আপনি কখনো ওয়ার্কার ব্যবহার না করে থাকেন, বেশিরভাগ উদাহরণে আপনি Dedicated Worker দেখবেন।

Web Workers কিভাবে যোগাযোগ করে

ওয়ার্কার সরাসরি আপনার পেজের ফাংশন কল করে না। পরিবর্তে, মেসেজ পাঠানোর মাধ্যমে যোগাযোগ হয়:

• পেজ ওয়ার্কারে ডেটা পাঠায় postMessage() দিয়ে।\n- ওয়ার্কারও আবার postMessage() দিয়ে উত্তর দেয়।\n- ডেটা structured clone অ্যালগরিদমের মাধ্যমে পাঠানো হয়, যা অনেক বিল্ট‑ইন টাইপ (অবজেক্ট, অ্যারে, স্ট্রিং, নম্বর, Maps/Sets, ArrayBuffers ইত্যাদি) সাপোর্ট করে।

বড় বাইনারি ডেটার জন্য, আপনি বারবার কপি হওয়া এড়াতে ArrayBuffer‑এর মালিকানা ট্রান্সফার করে পারফরম্যান্স বাড়াতে পারেন।

সাধারণ সীমাবদ্ধতা (ডিজাইনের কারণে)

ওয়ার্কার আলাদা হওয়ার কারণে কয়েকটি মূল সীমা আছে:

• ডাইরেক্ট DOM অ্যাক্সেস নেই: ওয়ার্কার পেজের HTML, CSS, বা লেআউট পড়তে বা পরিবর্তন করতে পারে না।\n- ভিন্ন গ্লোবালস: এখানে window বা document নেই। ওয়ার্কার self‑এর অধীনে চলে, এবং উপলব্ধ API গুলো মেইন পেজের থেকে ভিন্ন হতে পারে।\n- অ্যাসিঙ্ক মানসিকতা: সবকিছুই মেসেজ‑ভিত্তিক হওয়ায়, আপনি আপনার কোডকে ইনপুট পাঠানো এবং রেজাল্ট পাওয়ার চারপাশে গঠন করবেন।

সঠিকভাবে ব্যবহার করলে, Web Worker হল মেইন থ্রেডের কর্মক্ষমতা উন্নত করার সহজ উপায়, আপনার অ্যাপ কি করে তা বদলানো ছাড়া—কেবল কোথায় ভারি কাজ হয় সেটা বদলানো।

কখন Web Worker ব্যবহার করবেন (এবং কখন নয়)

ওয়েব ওয়ার্কারগুলো চমৎকার যখন আপনার পেজ “অটকে” মনে হয় কারণ মেইন থ্রেডে জাভাস্ক্রিপ্ট খুব বেশি কাজ করছে। মেইন থ্রেড ইউজার ইন্টারঅ্যাকশন এবং রেন্ডারিং‑এর জন্য দায়ী, তাই সেখানে ভারি কাজ জঙ্ক, ক্লিক‑ডিলে, এবং স্ক্রল ফ্রিজ সৃষ্টি করতে পারে।

Web Worker‑এর জন্য সেরা কাজগুলো

যখন আপনার কাছে CPU‑গুরুত্বপূর্ণ কাজ থাকে যা সরাসরি DOM‑এর অ্যাক্সেস ছাড়া করা যায়, তখন Web Worker ব্যবহার করুন:

• ভারি ক্যালকুলেশন: সিমুলেশন, ডেটা ক্রাঞ্চিং।\n- পার্সিং ও ট্রান্সফর্মেশন: বড় JSON পার্স করা, CSV পার্সিং, স্কিমা ভ্যালিডেশন।\n- কম্প্রেশন/ডিকম্প্রেশন: zip/gzip‑ধাঁচের ওয়ার্কলোড।\n- ইমেজ প্রসেসিং: রিসাইজিং, ফিল্টার, থাম্বনেইল তৈরি (সমর্থিত ব্রাউজারে বেশিরভাগ সময় OffscreenCanvas‑র সাথে জোড়া লাগায়)।

ব্যবহারিক উদাহরণ: যদি আপনি বড় JSON পে-লোড পান এবং সেটি পার্স করলে UI‑তে জঙ্ক হয়, পার্সিংটিকে ওয়ার্কার‑এ নিয়ে যান এবং ফলাফল ফিরে পাঠান।

ডেটা হ্যান্ডলিং টিপস (গতি বাড়াতে)

ওয়ার্কার‑এ যোগাযোগ postMessage দিয়ে হয়। বড় বাইনারি ডেটার জন্য transferable objects (যেমন ArrayBuffer) পছন্দ করুন যাতে ব্রাউজার মেমরি মালিকানা কপি না করে হস্তান্তর করতে পারে।

// main thread
worker.postMessage(buffer, [buffer]); // transfers the ArrayBuffer

এটি বিশেষ করে অডিও বাফার, ইমেজ বাইটস, বা বড় ডেটার জন্য উপকারী।

কখন Web Worker ব্যবহার করবেন না

ওয়ার্কারদের ওভারহেড আছে: অতিরিক্ত ফাইল, মেসেজ পাসিং, এবং ভিন্ন ডিবাগিং প্রবাহ। এগুলো এড়ান যখন:

• কাজটা ক্ষুদ্র (কয়েক মিলিসেকেন্ড) এবং বিরল।\n- কাজটা ঘন ঘন DOM পড়া/লিখা করে (ওয়ার্কার DOM‑কে ছোয় না)।\n- আপনাকে অত্যন্ত কম‑লেটেন্সি ব্যাক‑এবং‑ফোরথ দরকার; বারবার postMessage পিং‑পং করলে লাভ মিটে যায়।

একটি সহজ নিয়ম

যদি একটি কাজ লক্ষণীয় বিরতি (প্রায় 50ms+) সৃষ্টি করতে পারে এবং তা “ইনপুট → গণনা → আউটপুট” আকারে প্রকাশ করা যায় DOM অ্যাক্সেস ছাড়া, একটি Web Worker সাধারণত মূল্যবান। যদি কাজটি মূলত UI আপডেট, তাহলে মেইন থ্রেডেই রাখুন এবং সেখানেই অপ্টিমাইজ করুন।

Service Worker কী?

একটি Service Worker হলো বিশেষ ধরনের জাভাস্ক্রিপ্ট ফাইল যা ব্রাউজারের ব্যাকগ্রাউন্ডে চলে এবং আপনার সাইটের জন্য একটি প্রোগ্রামেবল নেটওয়ার্ক লেয়ার হিসেবে কাজ করে। এটি পেজের নিজস্ব স্কোপে না থেকে আপনার ওয়েব অ্যাপ এবং নেটওয়ার্কের মাঝখানে বসে, আপনাকে সিদ্ধান্ত নিতে দেয় যখন অ্যাপ রিসোর্স অনুরোধ করে (HTML, CSS, API কল, ইমেজ)।

লাইফসাইকল বেসিক (register → install → activate → control)

একটি Service Worker‑এর লাইফসাইকল কোনো এক পেজের থেকে আলাদা:

• Register: পেজ ব্রাউজারকে বলবে “এই সাইটে সার্ভিস ওয়ার্কার আছে” (সাধারণত আপনার মেইন JS থেকে)।\n- Install: ব্রাউজার এটি ডাউনলোড করে এবং install ধাপ চালায়, প্রায়শই গুরুত্বপূর্ণ ফাইল প্রিক্যাশ করতে এখানে ব্যবহার করা হয়।\n- Activate: নতুন ওয়ার্কার গ্রহণ করে, সাধারণত পুরনো ট্যাব বন্ধ হওয়ার পর বা নিরাপদ সময়ে পুরনো ভার্সনকে প্রতিস্থাপন করে।\n- Control: একবার active হলে এটি তার স্কোপের পেজগুলোকে “কন্ট্রোল” করতে পারে এবং অনুরোধ ইন্টারসেপ্ট করতে পারে।

ব্রাউজার এটি যে কোন সময়ে থামিয়ে দিতে বা শুরু করতে পারে, তাই এটিকে ইভেন্ট‑চালিত স্ক্রিপ্ট ভাবুন: দ্রুত কাজ করুন, স্টেট পERSISTENT স্টোরেজে রাখুন, এবং ধরে নেবেন না এটি সবসময় চালু থাকবে।

স্কোপ ও অরিজিন নিয়ম (হাই‑লেভেল)

Service Workers সেম্‑অরিজিনে সীমাবদ্ধ থাকে (একই ডোমেইন/প্রোটোকল/পোর্ট) এবং সাধারণত তাদের স্কোপ (ওয়ার্কার ফাইল সার্ভ করার ফোল্ডার ও নীচে)‑এর আওতায় থাকা পেজগুলোকে কন্ট্রোল করে। এছাড়া এরা HTTPS আহরণ করে (localhost ছাড়া) কারণ এরা নেটওয়ার্ক অনুরোধকে প্রভাবিত করতে পারে।

সাধারণত ব্যবহৃত API‑গুলো

• Fetch event: অনুরোধ ইন্টারসেপ্ট করে সিদ্ধান্ত নেয় নেটওয়ার্ক ব্যবহার করবে কি, ক্যাশ ব্যবহার করবে কি, বা কাস্টম রেসপন্স দেবে কি।\n- Cache Storage API: অনলাইন/অফলাইন ব্যবহারের জন্য প্রতিক্রিয়া সংরক্ষণ ও পুনরুদ্ধার করে।\n- Clients API: আপনার ওয়ার্কার যে ওপেন ট্যাব/উইন্ডো গুলোকে কন্ট্রোল করে সেগুলোর সাথে যোগাযোগ ও পরিচালনা করে।

Service Worker কী জন্য ব্যবহার করা হয়

Service Worker প্রধানত আপনার ওয়েব অ্যাপ এবং নেটওয়ার্কের মধ্যে বসে অনুরোধগুলোকে নিয়ন্ত্রণ করার জন্য ব্যবহৃত হয়। এটি নির্ধারণ করতে পারে কখন নেটওয়ার্ক ব্যবহার হবে, কখন ক্যাশেড ডেটা ব্যবহার হবে, এবং কখন ব্যাকগ্রাউন্ডে কিছু কাজ করা হবে—সবই পেজ ব্লক করা ছাড়াই।

অফলাইন সাপোর্ট (স্মার্ট ক্যাশিং)

সর্বাধিক সাধারণ কাজ হলো ক্যাশিং ব্যবহার করে অফলাইন বা দুর্বল সংযোগের অভিজ্ঞতা সক্ষম করা।

কিছু বাস্তবিক ক্যাশিং কৌশল:

• Cache-first: স্ট্যাটিক ফাইলের জন্য চমৎকার (CSS, JS, লোগো)। দ্রুত, অফলাইনে কাজ করে।\n- Network-first: বারবার পরিবর্তিত কন্টেন্টের জন্য ভালো (নিউজ, ফিড)। অফলাইনে ব্যর্থ হলে ক্যাশ ব্যবহার করে।\n- Stale-while-revalidate: তাত্ক্ষণিকভাবে ক্যাশড কন্টেন্ট দেখায়, ব্যাকগ্রাউন্ডে রিফ্রেশ করে পরের বার আপডেট সরবরাহ করে।

এটি সাধারণত Cache Storage API এবং fetch ইভেন্ট হ্যান্ডলিং দিয়ে বাস্তবায়িত হয়।

পুনরাবৃতি ভিজিটে দ্রুততা

Service Workers রিটার্ন ভিজিটে অনুভূত গতিশীলতা বাড়ায়:

• Precaching: ইন্সটলেশনের সময় “মাস্ট‑হ্যাভ” অ্যাপ ফাইলগুলো সেভ করে (প্রায়শই এটাকে app shell বলা হয়)।\n- Runtime caching: ব্যবহারকারীর নেভিগেশনের সময় পেজ বা API প্রতিক্রিয়া ক্যাশ করে।

ফলাফল: কম নেটওয়ার্ক অনুরোধ, দ্রুত স্টার্ট‑আপ, এবং খারাপ সংযোগেও সঙ্গতস্মৃত পারফরম্যান্স।

ব্যাকগ্রাউন্ড ফিচার (সমর্থন থাকলে)

Service Workers পুশ নোটিফিকেশন ও ব্যাকগ্রাউন্ড সিনক (ব্রাউজার ও প্ল্যাটফর্ম অনুসারে সমর্থন ভিন্ন) মতো ব্যাকগ্রাউন্ড সক্ষমতা চালাতে পারে। এর মানে আপনি ব্যবহারকারীকে নোটিফাই করতে পারেন বা পরে ব্যর্থ অনুরোধ পুনরায় চেষ্টা করতে পারেন—এমনকি পেজ খোলা না থাকলেও।

PWA নির্মাণের ব্লকস

আপনি যদি প্রগ্রেসিভ ওয়েব অ্যাপ বানান, Service Workers হলো মূল অংশ যা:

• ইনস্টলেবিলিটি (ওয়েব অ্যাপ ম্যানিফেস্টের সঙ্গে জোড়া করে)\n- নির্ভরযোগ্য অফলাইন পেজ (ফ্রেন্ডলি ফোলব্যাক)\n- app shell মডেল দ্রুত নেভিগেশনের জন্য

প্রধান পার্থক্য: Web Worker বনাম Service Worker

একটি জিনিস মনে রাখুন: Web Workers আপনার পেজকে ভারি কাজ করে ফ্রিজ হতে বাধা দেয়, আর Service Workers আপনার অ্যাপকে নেটওয়ার্ক অনুরোধ নিয়ন্ত্রণ করতে এবং ইনস্টলেবল অ্যাপ (PWA) মত আচরণ করতে সাহায্য করে।

কোথায় চলে (কোন কাজের জন্য)

Web Worker হলো CPU‑গুরুত্বপূর্ণ কাজের জন্য—বড় ডেটা পার্স করা, থাম্বনেইল জেনারেট করা, সংখ্যা ক্রাঞ্চিং—যাতে মেইন থ্রেড রেসপন্সিভ থাকে।

Service Worker হলো অনুরোধ হ্যান্ডলিং ও অ্যাপ লাইফসাইকেল কাজের জন্য—অফলাইন সাপোর্ট, ক্যাশিং কৌশল, ব্যাকগ্রাউন্ড সিনক, পুশ নোটিফিকেশন। এটি আপনার অ্যাপ এবং নেটওয়ার্কের মাঝখানে বসে।

লাইফটাইম ও “কে মালিক”

Web Worker সাধারণত একটি পেজ/ট্যাবের সাথে টাইটলি টাইল করা থাকে। পেজ গেলে সাধারণত ওয়ার্কারও চলে যায় (বিশেষ ক্ষেত্রে SharedWorker আলাদা)।

Service Worker হলো ইভেন্ট‑চালিত। ব্রাউজার ইভেন্ট (যেমন fetch বা push) ঘিরে এটাকে জাগাবে এবং ইভেন্ট শেষে বন্ধ করে দেবে। এর মানে এটি এমনকি কোন ট্যাব খোলা না থাকলেও ইভেন্টে কাজ করতে পারে।

নেটওয়ার্ক অ্যাক্সেস ও কন্ট্রোল

Web Worker পেজ দ্বারা তৈরি নেটওয়ার্ক অনুরোধ ইন্টারসেপ্ট করতে পারে না। এটি fetch() করতে পারে, কিন্তু এটি সার্ভ করে না বা অন্যান্য পেজ অংশের জন্য রিক্যরাইট/ক্যাশ সার্ভ করতে পারে না।

Service Worker অনুরোধ ইন্টারসেপ্ট করতে পারে (fetch ইভেন্ট) এবং সিদ্ধান্ত নিতে পারে নেটওয়ার্কে যাবে কি, ক্যাশ থেকে সার্ভ করবে কি, বা ফোলব্যাক দেবে কি।

স্টোরেজ ও ক্যাশিং

Web Worker HTTP ক্যাশ ম্যানেজ করে না।

Service Worker সাধারণত Cache Storage API ব্যবহার করে অনুরোধ/প্রতিক্রিয়া জোড়া সংরক্ষণ ও পরিবেশন করে—এটাই অফলাইন ক্যাশিং ও দ্রুত পুনরায় লোডের ভিত্তি।

কীভাবে সেটআপ করবেন (হাই‑লেভেল ধাপ)

ওয়ার্কার চালু করা মূলত নির্ভর করে কোথায় এটি চলবে এবং কিভাবে লোড হবে। Web Workers পেইজ স্ক্রিপ্ট দ্বারা সরাসরি তৈরি হয়। Service Workers পেজ থেকে রেজিস্টার করা হয় এবং ব্রাউজার ইনস্টল/অ্যাক্টিভেশন পরিচালনা করে।

Web Worker: পেজ থেকে তৈরি করুন

একটি Web Worker তখন শুরু হয় যখন আপনার পেজ এটি তৈরি করে। আপনি একটি আলাদা জাভাস্ক্রিপ্ট ফাইল নির্দেশ করবেন, তারপর postMessage দিয়ে যোগাযোগ করবেন।

// main.js (পেজে চলছে)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });

worker.postMessage({ action: 'start', payload: { /* ... */ } });

worker.onmessage = (event) => {
  console.log('From worker:', event.data);
};

মনে রাখবেন: ওয়ার্কার ফাইলটি ঠিক যেমন একটি স্ক্রিপ্ট URL—কিন্তু তা মেইন থ্রেডের বাইরে চলে।

Service Worker: একবার রেজিস্টার করুন এবং ব্রাউজারকে ইনস্টল করতে দিন

Service Workers অবশ্যই এমন একটি পেজ থেকে রেজিস্টার করতে হয় যেটা ব্যবহারকারী ভিজিট করে:

// main.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

রেজিস্ট্রেশন পরে ব্রাউজার ইনস্টল/অ্যাক্টিভেশন লাইফসাইকেল পরিচালনা করবে। আপনার sw.js install, activate, এবং fetch ইভেন্ট শুনতে পারে।

কেন Service Workers‑এ HTTPS লাগে

Service Workers নেটওয়ার্ক অনুরোধ ইন্টারসেপ্ট ও প্রতিক্রিয়া ক্যাশ করতে পারে। যদি রেজিস্ট্রেশন HTTP‑এর উপর অনুমোদিত হতো, একজন নেটওয়ার্ক আক্রমণকারী খারাপ sw.js রিপ্লেস করে ভবিষ্যত ভিজিটগুলোর নিয়ন্ত্রণ নিতেও পারে। HTTPS (বা dev‑এর জন্য http://localhost) স্ক্রিপ্ট এবং ট্র্যাফিককে রক্ষা করে।

ভার্সনিং মনোভাব: worker ফাইলকে ডিপ্লয়যোগ্য “রিলিজ” হিসেবে বিবেচনা করুন

ব্রাউজার ওয়ার্কারগুলো সাধারণ পেজ স্ক্রিপ্টের চেয়ে বিভিন্নভাবে ক্যাশ ও আপডেট করে। আপডেট পরিকল্পনা রাখুন:

• আচরণ পরিবর্তন হলে ফাইল পরিবর্তন করুন (সাধারণত নতুন sw.js/ওয়ার্কার বন্ডল ডিপ্লয় করে)।\n- Service Workers‑এ একটি “আপডেট” ফ্লো আশা করুন: নতুন ওয়ার্কার ইনস্টল হয়, তারপর নিরাপদ সময়ে অ্যাক্টিভেট করে পুরনো ভার্সন প্রতিস্থাপন করে।\n- ক্যাশিং নিয়ম বদলে গেলে অ্যাক্টিভেশনের সময় পুরনো ক্যাশ ক্লিন‑আপ করার লজিক যোগ করুন যাতে পুরনো ক্যাশগুলো ঘুরে বেড়ায় না।

পরিবর্তন রোলআউটের স্মুথ কৌশলের জন্য, পরবর্তী ধাপগুলোতে দেখুন /blog/debugging-workers যে পরীক্ষার অভ্যাসগুলি আপডেট এজগুলি আগেভাগে ধরতে সাহায্য করে।

ব্রাউজারে ওয়ার্কার ডিবাগিং ও টেস্টিং

ওয়ার্কারগুলো ভিন্নভাবে ব্যর্থ হয়—তারা আলাদা কনটেক্সটে চলে, তাদের নিজস্ব কনসোল আছে, এবং ব্রাউজার এগুলো পুনরায় শুরু করতে পারে। একটি মজবুত ডিবাগিং রুটিন অনেক সময় বাঁচায়।

Web Worker ডিবাগিং (DevTools)

DevTools খুলে worker‑নির্দিষ্ট টার্গেট দেখুন। Chrome/Edge‑এ আপনি প্রায়ই Workers‑কে Sources এর অধীনে (বা “Dedicated worker” entry) এবং Console কনটেক্সট সিলেক্টরে দেখবেন।

মেইন থ্রেডে যেই টুল আপনি ব্যবহার করবেন সেগুলোই ওয়ার্কারের জন্যও প্রযোজ্য:

• Console logging: Web Worker থেকে লগগুলি DevTools‑এ দেখা যায়, কিন্তু সঠিক কনটেক্সট দেখছেন কি না নিশ্চিত করুন।\n- Breakpoints: ওয়ার্কার স্ক্রিপ্টে ব্রেকপয়েন্ট সেট করুন; onmessage হ্যান্ডলার এবং দীর্ঘ চলা ফাংশনগুলো ধাপে ধাপে দেখুন।\n- Performance profiling: একটি পারফরম্যান্স ট্রেস রেকর্ড করুন এবং যাচাই করুন মেইন থ্রেড রেসপন্সিভ থাকছে কিনা যখন ওয়ার্কার ভারি কাজ করছে।

যদি মেসেজ “হোয়াহ” মনে হয়, উভয় পাশে পরীক্ষা করুন: worker.postMessage(...) কল হচ্ছে কি না, ওয়ার্কারে self.onmessage = ... আছে কি না, এবং মেসেজের কাঠামো মিলছে কি না।

Service Worker ডিবাগিং (Application প্যানেল)

Service Workers‑কে Application প্যানেলে ডিবাগ করা শ্রেয়:

• registration status, scope, এবং active/waiting/installed ভার্সনগুলো পরীক্ষা করুন।\n- লাইফসাইকেল কন্ট্রোলগুলোর মতো Skip waiting এবং Unregister ব্যবহার করে খারাপ স্টেট রিসেট করুন।\n- কোড ইটারেট করার সময় “Update on reload” চালু করে স্টেলে কোড খোঁজ করা বন্ধ করুন।

ইনস্টল/অ্যাক্টিভেট/ফেচ ত্রুটির জন্য কনসোলও দেখুন—এসব প্রায়ই ব্যাখ্যা দেয় কেন ক্যাশিং বা অফলাইন আচরণ কাজ করছে না।

সাধারণ ফাঁদ এবং টেস্টিং টিপস

ক্যাশিং ইস্যু হলো #1 সময়‑খরচকারী: ভুল ফাইল বা অত্যন্ত আগ্রেসিভ ক্যাশিং পুরনো HTML/JS ধরে রাখতে পারে। টেস্টে হার্ড রিলোড আচরণ চেষ্টা করুন এবং যাচাই করুন আসলে কি সার্ভ হচ্ছে।

বাস্তবসম্মত টেস্টিংয়ের জন্য DevTools ব্যবহার করুন:

• Offline মোড সিমুলেট করুন এবং ফোলব্যাক পেজ যাচাই করুন\n- Network throttling প্রয়োগ করুন\n- সার্ভিস ওয়ার্কার আপডেট এবং মেসেজ হ্যান্ডলিং যাচাই করতে একাধিক বার রিলোড করুন

আপনি দ্রুত PWA‑তে ইটারেট করলে, একটি পরিষ্কার বেসলাইন অ্যাপ তৈরি করা (প্রেডিক্টেবল Service Worker এবং বিল্ড আউটপুট সহ) সাহায্য করে এবং তারপর ক্যাশিং কৌশলগুলো ধাপে ধাপে উৎকৃষ্ট করা যায়। প্ল্যাটফর্মগুলো যেমন Koder.ai এই ধরনের ניס্কাশনের জন্য সহায়ক হতে পারে: আপনি চ্যাট প্রম্পট থেকে একটি React‑ভিত্তিক ওয়েব অ্যাপ প্রোটোটাইপ করতে পারেন, সোর্স এক্সপোর্ট করে পরে আপনার ওয়ার্কার সেটআপ ও ক্যাশিং নিয়মে টুইক করতে পারবেন।

নিরাপত্তা, গোপনীয়তা, এবং কর্মক্ষমতার বিবেচনা

ওয়ার্কাররা অ্যাপকে মসৃণ ও আরও সক্ষম করে কিন্তু তারা কোড কোথায় চলে ও কি অ্যাক্সেস পায় তা বদলে দেয়। নিরাপত্তা, গোপনীয়তা, এবং কর্মক্ষমতার দ্রুত চেক আপনাকে অপ্রত্যাশিত বাগ ও অপ্রীতিকর ব্যবহারকারীর অভিজ্ঞতা থেকে রক্ষা করবে।

নিরাপত্তা সীমাবদ্ধতা (কেন same-origin গুরুত্বপূর্ণ)

উভয় Web Worker এবং Service Worker same-origin policy দ্বারা সীমাবদ্ধ: তারা শুধু একই scheme/host/port থেকে সরাসরি রিসোর্সের সাথে ইন্টারঅ্যাক্ট করতে পারে (যদি সার্ভার CORS দিয়ে স্পষ্টভাবে অনুমতি না দেয়)। এটি একটি ওয়ার্কারকে অন্য সাইট থেকে ডেটা চেপে এনে আপনার অ্যাপের সঙ্গে মিশিয়ে দেয়া থেকে রোধ করে।

Service Worker‑গুলোর জন্য অতিরিক্ত গার্ডরেইল আছে: সাধারণত তারা HTTPS চায় (বা ডেভ‑এ localhost) কারণ তারা নেটওয়ার্ক অনুরোধ ইন্টারসেপ্ট করতে পারে। তাদের প্রিভিলেজড কোড হিসেবে বিবেচনা করুন: ডিপেন্ডেন্সি কম রাখুন, ডায়নামিক কোড লোডিং এড়ান, এবং ক্যাশিং লজিক লাইভ‑ভারে সাবধানতার সাথে ভার্সন করুন যাতে পুরনো ক্যাশি আপডেট না হোক।

গোপনীয়তা ও ব্যবহারকারীর প্রত্যাশা

ব্যাকগ্রাউন্ড ফিচারগুলো পূর্বানুমানযোগ্য হওয়া উচিত। পুশ নোটিফিকেশন শক্তিশালী, কিন্তু পারমিশন প্রম্পট সহজে অপব্যবহার করা যায়।

অনুমতি কেবলই তখন চাওয়া উচিত যখন একটি স্পষ্ট সুবিধা রয়েছে (উদাহরণ: ব্যবহারকারী সেটিংসে অ্যালার্ট চালু করার পরে), এবং ব্যাখ্যা করুন তারা কি পাবে। যদি আপনি ব্যাকগ্রাউন্ডে ডেটা সিনক বা প্রিফেচ করেন, তা পরিষ্কার ভাষায় বলুন—ব্যবহারকারীরা অপ্রত্যাশিত নেটওয়ার্ক ক্রিয়াকলাপ বা নোটিফিকেশন লক্ষ্য করে।

নজর দেওয়ার জন্য কর্মক্ষমতা ঝুঁকি

ওয়ার্কার ফ্রি পারফরম্যান্স নয়। অতিরিক্ত ব্যবহার ব্যর্থ করতে পারে:

• মেসেজ ওভারহেড: ঘন ঘন postMessage কল (বড় অবজেক্ট সহ) বটলনেক হতে পারে। উপযুক্ত হলে ব্যাচিং এবং transferable ব্যবহার করুন।\n- মেমরি খরচ: প্রতিটি ওয়ার্কারের নিজস্ব মেমরি ও স্টার্টআপ ওভারহেড আছে; খাদ্যসংখ্যায় ওয়ার্কার রাখা RAM ও ব্যাটারি বাড়াতে পারে।\n- ক্যাশ বৃদ্ধি: অত্যন্ত আগ্রেসিভ ক্যাশিং স্টোরেজ বর্ধিত করতে পারে। আপডেটের সময় ক্যাশ সীমা ও ক্লিন‑আপ যোগ করুন।

গ্রেসফুলো ফলব্যাক

প্রতিটি ব্রাউজার সব ক্ষমতা সমর্থন করে না (অথবা ব্যবহারকারীরা পারমিশন বেঁধে দিতে পারে)। ফিচার‑ডিটেক্ট করুন এবং সুন্দরভাবে degrade করুন:

if ('serviceWorker' in navigator) {
  // register service worker
} else {
  // continue without offline features
}

লক্ষ্য: মূল কার্যকারিতা যেন এখনও কাজ করে, আর “ভাল‑থেকে‑থাক” (offline, push, heavy computations) যখন উপলব্ধ তখন লেয়ার করা হয়।

সাধারণ প্যাটার্ন যেখানে উভয়ই একসঙ্গে ব্যবহার হয়

Web Workers এবং Service Workers ভিন্ন সমস্যার সমাধান করে, তাই যখন একটি অ্যাপে ভারি গণনা এবং দ্রুত/বিশ্বস্ত লোডিং উভয় দরকার তখন তারা ভাল জুটে যায়। একটি ভালো মানসিক মডেল: Web Worker = compute, Service Worker = network + caching, main thread = UI।

প্যাটার্ন 1: ইমেজ প্রসেসিং + অফলাইন গ্যালারি

ধরা যাক আপনার অ্যাপ ব্যবহারকারীকে ছবি এডিট করার সুযোগ দেয় (রিসাইজ, ফিল্টার, ব্যাকগ্রাউন্ড রিমুভ) এবং পরে কানেকশন ছাড়া গ্যালারি দেখা যায়।

• Web Worker CPU‑গুরুত্বপূর্ণ কাজ করে (ডিকোড, ট্রান্সফর্ম, থাম্বনেইল জেনারেট) যাতে স্ক্রলিং ও ট্যাপ মসৃণ থাকে।\n- Service Worker থাম্বনেইল ও অরিজিনালগুলো Cache Storage‑এ ক্যাশ করে (অথবা মেটাডেটা IndexedDB‑এ) এবং পুনরাবৃত্তিতে বা অফলাইনে তৎক্ষণিকভাবে সার্ভ করে।

এই “compute then cache” পদ্ধতি দায়িত্ব পরিষ্কার রাখে: ওয়ার্কার আউটপুট তৈরি করে, সার্ভিস ওয়ার্কার ঠিক করে কীভাবে তা সংরক্ষণ ও পরিবেশন করা হবে।

প্যাটার্ন 2: ডেটা সিঙ্ক + ব্যাকগ্রাউন্ড ক্যাশিং

ফিড, ফর্ম, বা ফিল্ড ডেটা সহ অ্যাপগুলির জন্য:

• Web Worker বড় JSON পে-লোড নরমালাইজ করতে, ডিফিং চালাতে, বা ডেটা ভ্যালিডেট করতে পারে UI ব্লক না করে।\n- Service Worker স্টার্ট‑আপে API প্রতিক্রিয়া ক্যাশ করে দ্রুত লোড নিশ্চিত করে এবং অফলাইন রিডের জন্য কাজ করে। সংযোগ ফিরে এলে এটি ক্যাশ রিফ্রেশ এবং (যেখানে সমর্থিত) ব্যাকগ্রাউন্ড সিনক সমন্বয় করতে পারে।

পূর্ণ ব্যাকগ্রাউন্ড সিনক না থাকলেও, সার্ভিস ওয়ার্কার ক্যাশড প্রতিক্রিয়া পরিবেশন করে অনুভবে দ্রুততা বাড়ায় এবং ব্যাকগ্রাউন্ডে আপডেট করে।

দায়িত্ব আলাদা রাখা

রোল মিশ্রিত করা এড়ান:

• UI থ্রেড: রেন্ডারিং, ইউজার ইনপুট, অ্যাক্সেসিবিলিটি, হালকা স্টেট ওয়্যার।\n- Web Worker: খাঁটি ক্যালকুলেশন ও ডেটা প্রস্তুতি (প্রায়ই postMessage‑এর মাধ্যমে)।\n- Service Worker: অনুরোধ রাউটিং, ক্যাশিং কৌশল, অফলাইন ফোলব্যাক।

দ্রুত চেকলিস্ট: কোনটা দরকার?

• কাজ কি CPU‑গুরুত্বপূর্ণ (পার্সিং, এনকোড/ডিকোড, ক্রিপ্টো, ইমেজ/অডিও প্রসেসিং)? -> Web Worker।\n- কাজ কি ফেচ ইন্টারসেপ্ট, অফলাইন আচরণ, বা ক্যাশিং সম্পর্কিত? -> Service Worker।\n- উভয়ই দ্রুত UI এবং দ্রুত লোড/অফলাইন দরকার? -> দুটোই ব্যবহার করুন, কিন্তু সীমা পরিষ্কার রাখুন: গণনা ওয়েব ওয়ার্কারে, সংরক্ষণ/পরিবেশন সার্ভিস ওয়ার্কারে।

FAQ: ব্যবহারিক প্রশ্নগুলো

Service Worker কি DOM‑এ অ্যাক্সেস করতে পারে?

না। Service Worker ব্যাকগ্রাউন্ডে চলে, কোনো পেজ ট্যাব থেকে আলাদা, এবং সরাসরি DOM (পেজের HTML উপাদান) অ্যাক্সেস করে না।

এই বিচ্ছিন্নতার কারণে Service Worker এমনভাবে ডিজাইন করা হয়েছে যাতে এটি পেজ খোলা না থাকলেও কাজ করতে পারে (উদাহরণ: পুশ ইভেন্টে প্রতিক্রিয়া বা ক্যাশড ফাইল পরিবেশন)। যদি Service Worker‑কে ব্যবহারকারীর দেখায় কিছু প্রভাব ফেলতে হয়, এটি পেজগুলোর সাথে মেসেজিং (যেমন postMessage) করে এবং পেজ UI আপডেট করবে।

কি ওয়েব ওয়ার্কারের জন্য সার্ভিস ওয়ার্কার দরকার?

না। Web Workers এবং Service Workers স্বাধীন ফিচার।

• Web Worker: ভারি জাভাস্ক্রিপ্ট কাজ মেইন থ্রেড থেকে সরানোর জন্য।\n- Service Worker: নেটওয়ার্ক‑স্তরের ফিচার (অফলাইন, ক্যাশিং, পুশ/ব্যাকগ্রাউন্ড সিনক) এর জন্য।

আপনি এককভাবে বা উভয়ই একসাথে ব্যবহার করতে পারেন।

ওয়ার্কারগুলো কি সর্বত্র সমর্থিত?

আধুনিক ব্রাউজারে Web Workers ব্যাপকভাবে সমর্থিত এবং সাধারণত নিরাপদ বেসলাইন।

Service Workers সমর্থনও বড় অংশে রয়েছে, তবে তাদের উপরে আরও শর্ত ও এজ কেস আছে:

• এগুলো HTTPS চায় (localhost ডেভ‑এর জন্য ছাড়)।\n- কিছু ফিচার (যেমন পুশ নোটিফিকেশন) ব্রাউজার ও প্ল্যাটফর্ম অনুযায়ী ভিন্নতা দেখায়।

যদি বিস্তৃত সামঞ্জস্য জরুরি হয়, Service Worker‑এর ফিচারগুলোকে প্রগ্রেসিভ এনহান্সমেন্ট হিসেবে ভাবুন: প্রথমে ভালো কোর অভিজ্ঞতা বানান, তারপর অফলাইন/পুশ সেখানে যোগ করুন যেখানে উপলব্ধ।

এটা কি স্বয়ংক্রিয়ভাবে আমার সাইটকে দ্রুত করবে?

স্বয়ংক্রিয়ভাবে নয়।

• একটি Web Worker সাহায্য করে যখন আপনার সাইট ধীর হচ্ছে কারণ মেইন থ্রেডে CPU‑ভিত্তিক জব চলছে। কাজ স্থানান্তর করলে জঙ্ক কমে কিন্তু মেসেজ পাসিং ও স্টার্টআপ ওভারহেড থাকে।\n- একটি Service Worker সাহায্য করে যখন আপনার সাইট নেটওয়ার্ক অনুরোধে ধীর। স্মার্ট ক্যাশিং ও fetch‑হ্যান্ডলিং পুনরায় ভিজিটকে তাত্ক্ষণিক করে তুলতে পারে—কিন্তু ভুল ক্যাশিং স্টালের কন্টেন্ট রাখতে পারে।

বাস্তব লাভ আসে উপযুক্ত ওয়ার্কার নির্বাচন করে, এবং পরিমাপ করে আগে ও পরে পারফরম্যান্স যাচাই করে।