পরিষেবা কর্মীরা ওয়েবসাইটগুলিকে অফলাইনে কাজ করার এবং নিজেদের জন্য বিশেষ ক্যাশিং নিয়ম তৈরি করার অনুমতি দেওয়ার জন্য একটি শক্তিশালী হাতিয়ার৷ একজন পরিষেবা কর্মী fetch হ্যান্ডলার এটি নিয়ন্ত্রণ করে এমন একটি পৃষ্ঠার প্রতিটি অনুরোধ দেখেন এবং পরিষেবা কর্মী ক্যাশে থেকে এটির একটি প্রতিক্রিয়া দিতে চান কিনা তা সিদ্ধান্ত নিতে পারেন, অথবা এমনকি সম্পূর্ণরূপে ভিন্ন প্রতিক্রিয়া আনার জন্য URL পুনরায় লিখতে পারেন - উদাহরণস্বরূপ, স্থানীয় ভিত্তিতে ব্যবহারকারীর সুবিধামত.
যাইহোক, পরিষেবা কর্মীদের কর্মক্ষমতা খরচ হতে পারে যখন একটি পৃষ্ঠা কিছু সময়ের মধ্যে প্রথমবার লোড করা হয় এবং নিয়ন্ত্রণকারী পরিষেবা কর্মী বর্তমানে চলছে না। যেহেতু সমস্ত আনয়ন পরিষেবা কর্মীর মাধ্যমে ঘটতে হবে, ব্রাউজারটিকে পরিষেবা কর্মী শুরু হওয়ার জন্য অপেক্ষা করতে হবে এবং কোন সামগ্রী লোড করতে হবে তা জানতে হবে৷ ক্যাশিং কৌশলগুলির মাধ্যমে কর্মক্ষমতা উন্নত করতে পরিষেবা কর্মীদের ব্যবহার করে ডেভেলপারদের জন্য এই স্টার্টআপ খরচ ছোট, কিন্তু তাৎপর্যপূর্ণ হতে পারে।
ন্যাভিগেশন প্রিলোড হল সমস্যা সমাধানের একটি পদ্ধতি—পরিষেবা কর্মী স্টার্টআপের সমান্তরালে নেটওয়ার্কের মাধ্যমে নেভিগেশন অনুরোধগুলি করার অনুমতি দেওয়া—কিন্তু এটি প্রাথমিক নেভিগেশন অনুরোধের মধ্যে সীমাবদ্ধ এবং এখনও গুরুত্বপূর্ণ পথে পরিষেবা কর্মীকে অন্তর্ভুক্ত করে। নেভিগেশন প্রিলোড চালু হওয়ার পর থেকে, পরিষেবা কর্মী স্টার্টআপে কিছু অনুরোধ যাতে একেবারেই ব্লক না করা যায় সেগুলি সহ সমস্যার স্থানের আরও সাধারণ সমাধান তৈরি করার জন্য একাধিক প্রচেষ্টা করা হয়েছে৷
সার্ভিস ওয়ার্কার স্ট্যাটিক রাউটিং API
Chrome 116 থেকে শুরু করে, পরীক্ষামূলক পরিষেবা কর্মী স্ট্যাটিক রাউটিং API এই ধরনের সমাধানের প্রথম ধাপ পরীক্ষা করার জন্য উপলব্ধ। যখন একটি পরিষেবা কর্মী ইনস্টল করা হয়, তখন এটি পরিষেবা কর্মী স্ট্যাটিক রাউটিং API ব্যবহার করে ঘোষণামূলকভাবে বর্ণনা করতে পারে যে কীভাবে নির্দিষ্ট রিসোর্স পাথ আনতে হবে।
API-এর প্রাথমিক সংস্করণে, পাথগুলি সর্বদা নেটওয়ার্ক থেকে পরিবেশন করা হবে বলে ঘোষণা করা যেতে পারে, পরিষেবা কর্মী নয়। যখন একটি নিয়ন্ত্রিত URL পরে লোড করা হয়, তখন পরিষেবা কর্মী শুরু করার আগে ব্রাউজার সেই পথগুলি থেকে সংস্থানগুলি আনা শুরু করতে পারে৷ এটি পরিষেবা কর্মীকে সেই পথগুলি থেকে সরিয়ে দেয় যা আপনি জানেন যে কোনও পরিষেবা কর্মী প্রয়োজন নেই৷
API ব্যবহার করার জন্য, পরিষেবা কর্মী একটি সেট নিয়ম সহ install ইভেন্টে event.registerRouter কল করে:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
প্রতিটি নিয়ম সাধারণত দুটি বৈশিষ্ট্য আছে:
condition: রিসোর্স পাথ মেলে ইউআরএল প্যাটার্ন API ব্যবহার করে নিয়মটি কখন প্রযোজ্য হবে তা নির্দিষ্ট করে। প্রপার্টি একটিURLPatternউদাহরণ নিতে পারে, বা সমতুল্য প্লেইন অবজেক্ট যাURLPatternকনস্ট্রাক্টরে পাস করার সাথে সামঞ্জস্যপূর্ণ (উদাহরণস্বরূপ, হয়new URLPattern({pathname: '*.jpg'})অথবা শুধুমাত্র{pathname: '*.jpg'})।ইউআরএল প্যাটার্নের নমনীয়তার অর্থ হল নিয়মটি একটি পাথের অধীনে যেকোন সম্পদের মতো সহজ কিছুর সাথে খুব নির্দিষ্ট এবং বিশদ শর্তের সাথে মিলতে পারে। নিদর্শনগুলি সাধারণত জনপ্রিয় রাউটিং লাইব্রেরির ব্যবহারকারীদের কাছে পরিচিত হওয়া উচিত।
source: রিসোর্স ম্যাচিংconditionকিভাবে লোড হবে তা উল্লেখ করে। আজ, শুধুমাত্র'network'মান সমর্থিত (পরিষেবা কর্মীকে বাইপাস করে সরাসরি নেটওয়ার্কের উপর রিসোর্স লোড করে), কিন্তু পরিকল্পনাটি ভবিষ্যতে এটিকে অন্যান্য মানগুলিতে প্রসারিত করার।
ব্যবহারের ক্ষেত্রে
যেমন ব্যাখ্যা করা হয়েছে, API-এর প্রাথমিক সংস্করণটি মূলত কিছু পাথের জন্য পরিষেবা কর্মী নিয়ন্ত্রণ থেকে একটি পালানোর হ্যাচ। এটি কোথায় ব্যবহার করা অর্থপূর্ণ হবে তা নির্ভর করবে আপনি কীভাবে আপনার পরিষেবা কর্মীকে ব্যবহার করেন এবং ব্যবহারকারীরা কীভাবে আপনার সাইটটি অতিক্রম করে।
একটি উদাহরণ হতে পারে যদি আপনার সাইটটি একটি ক্যাশে-প্রথম কৌশল ব্যবহার করে (নেটওয়ার্কে ফিরে আসা), কিন্তু এমন কিছু বিষয়বস্তু আছে যা এত কমই পরিদর্শন করা হয় যে ক্যাশে আঘাত করার ক্ষেত্রে এটির কোনো মূল্য নেই (যেমন সংরক্ষণাগারভুক্ত সামগ্রী বা RSS ফিড)। নেটওয়ার্ক থেকে আনার জন্য এই পথগুলিকে সীমাবদ্ধ করা শুধুমাত্র পরিষেবা কর্মীতে সেট আপ করা যেতে পারে , তবে পরিষেবা কর্মীকে এখনও শুরু করতে হবে এবং সেই অনুরোধগুলি কীভাবে পরিচালনা করবেন তা সিদ্ধান্ত নিতে হবে৷
স্ট্যাটিক রাউটিং API, বিপরীতে, কয়েকটি ঘোষণামূলক লাইনের সাথে পরিষেবা কর্মীকে সম্পূর্ণভাবে বাইপাস করে:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
সার্ভিস ওয়ার্কার স্ট্যাটিক রাউটিং এপিআই বিকশিত হওয়ার সাথে সাথে এই কনফিগারেশনটি আরও নমনীয় এবং আরও পরিস্থিতি সমর্থন করার জন্য পরিকল্পনা হল, যেমন ঘোষণামূলকভাবে একটি নেটওয়ার্ক আনয়ন এবং পরিষেবা কর্মী স্টার্টআপ। আরও বিশদ বিবরণের জন্য API-এর সম্ভাব্য "চূড়ান্ত ফর্ম" এর স্পেক ব্যাখ্যাকারীর অনুসন্ধান দেখুন।
সার্ভিস ওয়ার্কার স্ট্যাটিক রাউটিং API ব্যবহার করে দেখুন
সার্ভিস ওয়ার্কার স্ট্যাটিক রাউটিং API Chrome এ উপলব্ধ একটি অরিজিন ট্রায়ালের পিছনে 116 সংস্করণ থেকে শুরু করে, যা বিকাশকারীদের প্রভাব পরিমাপ করতে প্রকৃত ব্যবহারকারীদের সাথে তাদের সাইটে API পরীক্ষা করতে দেয়৷ মূল ট্রায়ালের পটভূমির তথ্যের জন্য "অরিজিন ট্রায়াল দিয়ে শুরু করুন" দেখুন।
স্থানীয় পরীক্ষার জন্য, সার্ভিস ওয়ার্কার স্ট্যাটিক রাউটিং API chrome://flags/#service-worker-static-router এ একটি পতাকা দিয়ে বা --enable-features=ServiceWorkerStaticRouter এর মতো কমান্ড থেকে Chrome চালানোর মাধ্যমে সক্ষম করা যেতে পারে।
প্রতিক্রিয়া এবং ভবিষ্যতের দিকনির্দেশ
সার্ভিস ওয়ার্কার স্ট্যাটিক রাউটিং API সক্রিয়ভাবে বিকশিত হচ্ছে এবং এখনও আকার দেওয়া হচ্ছে। যদি মনে হয় এটি আপনার জন্য উপযোগী হতে পারে, তাহলে অনুগ্রহ করে এটি অরিজিন ট্রায়ালের মাধ্যমে চেষ্টা করে দেখুন এবং API, বাস্তবায়ন এবং উপলব্ধ কার্যকারিতা সম্পর্কে প্রতিক্রিয়া প্রদান করুন ৷