পরিষেবা কর্মীদের একটি বৈশিষ্ট্য হল পরিষেবা কর্মী ইনস্টল করার সময় ফাইলগুলি ক্যাশে সংরক্ষণ করার ক্ষমতা। এটি "প্রেক্যাচিং" হিসাবে উল্লেখ করা হয়। প্রিক্যাচিং নেটওয়ার্কে না গিয়ে ব্রাউজারে ক্যাশে করা ফাইলগুলিকে পরিবেশন করা সম্ভব করে তোলে। অফলাইনে থাকাকালীনও আপনার সাইটের প্রয়োজন এমন গুরুত্বপূর্ণ সম্পদগুলির জন্য প্রিক্যাচিং ব্যবহার করুন: প্রধান পৃষ্ঠা, শৈলী, ফলব্যাক চিত্র এবং প্রয়োজনীয় স্ক্রিপ্ট।
কেন আপনি ওয়ার্কবক্স ব্যবহার করা উচিত?
প্রিক্যাচিংয়ের জন্য ওয়ার্কবক্স ব্যবহার করা ঐচ্ছিক। যখন পরিষেবা কর্মী ইনস্টল করছেন তখন আপনি ক্রিটিক্যাল অ্যাসেট প্রিক্যাচ করতে আপনার নিজের কোড লিখতে পারেন৷ ওয়ার্কবক্স ব্যবহার করার প্রাথমিক সুবিধা হল এর বাইরের-দ্যা-বক্স সংস্করণ নিয়ন্ত্রণ। ওয়ার্কবক্স ব্যবহার করে প্রিক্যাচেড সম্পদ আপডেট করতে আপনাকে অনেক কম সমস্যায় পড়তে হবে যদি আপনি নিজেই এই ফাইলগুলির সংস্করণ এবং আপডেট পরিচালনা করতে পারেন।
Precache উদ্ভাসিত
প্রিক্যাচিং প্রতিটি URL-এর জন্য URL-এর তালিকা এবং সংশ্লিষ্ট সংস্করণ তথ্য দ্বারা চালিত হয়। একসাথে নেওয়া, এই তথ্যটি একটি precache ম্যানিফেস্ট হিসাবে পরিচিত। ম্যানিফেস্ট হল "সত্যের উৎস" যা একটি ওয়েব অ্যাপের প্রদত্ত সংস্করণের জন্য প্রিক্যাশে থাকা সমস্ত কিছুর অবস্থার জন্য। একটি precache ম্যানিফেস্ট, ওয়ার্কবক্স দ্বারা ব্যবহৃত বিন্যাসে, এমন কিছু দেখায়:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
যখন পরিষেবা কর্মী ইনস্টল করা হয়, তিনটি তালিকাভুক্ত URL-এর প্রতিটির জন্য ক্যাশে সঞ্চয়স্থানে তিনটি ক্যাশে এন্ট্রি তৈরি করা হয়। প্রথম সম্পদের সংস্করণ সংক্রান্ত তথ্য ইতিমধ্যেই এর URL-এ অন্তর্ভুক্ত রয়েছে ( app প্রকৃত ফাইলের নাম, এবং .abcd1234 সংস্করণের তথ্য রয়েছে, ফাইল এক্সটেনশন .js এর ঠিক আগে)। ওয়ার্কবক্সের বিল্ড টুল এটি সনাক্ত করতে পারে এবং একটি সংশোধন ক্ষেত্র বাদ দিতে পারে। অন্য দুটি সম্পদ তাদের URL-এ কোনো সংস্করণের তথ্য অন্তর্ভুক্ত করে না, তাই ওয়ার্কবক্সের বিল্ড টুল স্থানীয় ফাইলের বিষয়বস্তুগুলির একটি হ্যাশ সহ একটি পৃথক revision ক্ষেত্র তৈরি করে।
precached সম্পদ পরিবেশন
ক্যাশে সম্পদ যোগ করা প্রিক্যাচিং গল্পের মাত্র একটি অংশ—একবার সম্পদগুলি ক্যাশে করা হলে, তাদের বহির্গামী অনুরোধে সাড়া দিতে হবে। এর জন্য আপনার পরিষেবা কর্মীর মধ্যে একটি fetch শ্রোতার প্রয়োজন যেটি পরীক্ষা করতে পারে কোন ইউআরএলগুলি প্রিক্যাচ করা হয়েছে এবং সেই ক্যাশে করা প্রতিক্রিয়াগুলিকে নির্ভরযোগ্যভাবে ফেরত দিতে পারে, প্রক্রিয়ায় নেটওয়ার্ককে বাইপাস করে৷ যেহেতু পরিষেবা কর্মী প্রতিক্রিয়াগুলির জন্য ক্যাশে পরীক্ষা করে (এবং নেটওয়ার্কের আগে সেগুলি ব্যবহার করে), এটিকে ক্যাশে-প্রথম কৌশল বলা হয়।
দক্ষ আপডেট
একটি precache ম্যানিফেস্ট প্রত্যাশিত ক্যাশে অবস্থার একটি সঠিক উপস্থাপনা প্রদান করে; যদি ম্যানিফেস্টে একটি URL/রিভিশন সংমিশ্রণ পরিবর্তিত হয়, একজন পরিষেবা কর্মী জানেন যে আগের ক্যাশে করা এন্ট্রিটি আর বৈধ নয়, এবং আপডেট করা প্রয়োজন৷ এটি শুধুমাত্র একটি একক নেটওয়ার্ক অনুরোধ নেয়, যা ব্রাউজার দ্বারা স্বয়ংক্রিয়ভাবে পরিষেবা কর্মী আপডেট চেকের অংশ হিসাবে তৈরি করা হয়, কোন প্রিক্যাচ করা URLগুলিকে রিফ্রেশ করতে হবে তা নির্ধারণ করতে৷
প্রিক্যাচেড রিসোর্স আপডেট
আপনি সময়ের সাথে সাথে আপনার ওয়েব অ্যাপের নতুন সংস্করণ প্রকাশ করার সাথে সাথে আপনাকে পূর্বে প্রিক্যাচ করা URLগুলিকে আপ টু ডেট রাখতে হবে, নতুন সম্পদগুলিকে প্রিক্যাচ করতে হবে এবং পুরানো এন্ট্রিগুলি মুছতে হবে৷ যতক্ষণ না আপনি প্রতিবার আপনার সাইট পুনর্নির্মাণ করার সময় একটি সম্পূর্ণ প্রিক্যাশে ম্যানিফেস্ট তৈরি করা চালিয়ে যান, সেই ম্যানিফেস্টটি যেকোনো সময়ে আপনার প্রিক্যাশ অবস্থার জন্য "সত্যের উত্স" হিসাবে কাজ করে।
যদি একটি নতুন পুনর্বিবেচনা ক্ষেত্র সহ একটি বিদ্যমান URL থাকে, অথবা যদি ম্যানিফেস্ট থেকে কোনো URL যোগ করা হয় বা বাদ দেওয়া হয়, তবে এটি আপনার পরিষেবা কর্মীদের জন্য একটি চিহ্ন যে ইভেন্ট হ্যান্ডলারগুলিকে install এবং activate অংশ হিসাবে আপডেটগুলি সম্পাদন করতে হবে৷ উদাহরণস্বরূপ, আপনি যদি আপনার সাইটে কিছু পরিবর্তন করে থাকেন এবং পুনঃনির্মাণ করেন, আপনার সাম্প্রতিক প্রিক্যাশে ম্যানিফেস্টে নিম্নলিখিত পরিবর্তনগুলি হতে পারে:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
এই পরিবর্তনগুলির প্রতিটি আপনার পরিষেবা কর্মীকে বলে যে পূর্বে ক্যাশ করা এন্ট্রিগুলি ( 'offline.svg' এবং 'index.html' ) আপডেট করার জন্য এবং নতুন URL ( 'app.ffaa4455.js' ), পাশাপাশি ক্যাশে করার জন্য নতুন অনুরোধ করা দরকার ইউআরএলগুলি পরিষ্কার করার জন্য মুছে ফেলা যা আর ব্যবহার করা হয় না ( 'app.abcd1234.js' )।
সত্যিকারের "অ্যাপ স্টোর" ইনস্টল করার অভিজ্ঞতা
প্রিক্যাচিংয়ের আরেকটি সুবিধা হল আপনি আপনার ব্যবহারকারীদের এমন একটি অভিজ্ঞতা দিতে পারেন যা অন্যথায় "অ্যাপ স্টোর" ইনস্টলেশনের বাইরে অর্জন করা কঠিন হবে। একবার একজন ব্যবহারকারী আপনার ওয়েব অ্যাপের যেকোন পৃষ্ঠায় প্রথমবার ভিজিট করলে, আপনি সম্ভাব্যভাবে আপনার ওয়েব অ্যাপ্লিকেশানের যেকোন ভিউ প্রদর্শনের জন্য প্রয়োজনীয় সমস্ত ইউআরএল প্রিক্যাশ করতে পারেন, যতক্ষণ না তারা প্রতিটি পৃথক ভিউ পরিদর্শন করে ততক্ষণ অপেক্ষা না করে।
যখন একজন ব্যবহারকারী একটি অ্যাপ ইনস্টল করেন, তখন তারা আশা করেন যে প্রতিটি অংশ দ্রুত প্রদর্শিত হবে, শুধুমাত্র অতীতে যে ভিউ দেখেছেন তা নয়। প্রিক্যাচিং ওয়েব অ্যাপে একই অভিজ্ঞতা নিয়ে আসে।
আপনার কোন সম্পদ precached করা উচিত?
কোন ইউআরএলগুলিকে প্রিক্যাচ করা সবচেয়ে বেশি বোধগম্য হয় তার একটি ভাল ছবি পেতে আইডেন্টিফাই কি লোড হচ্ছে নির্দেশিকাতে ফিরে যান৷ সাধারণ নিয়ম হল যেকোন HTML, JavaScript, বা CSS কে প্রিক্যাচ করা যা প্রথম দিকে লোড হয় এবং একটি প্রদত্ত পৃষ্ঠার মৌলিক কাঠামো প্রদর্শনের জন্য অত্যন্ত গুরুত্বপূর্ণ।
প্রিক্যাচিং মিডিয়া বা অন্যান্য সম্পদ যা পরে লোড করা হয় এড়িয়ে চলাই ভালো (যদি না আপনার ওয়েব অ্যাপের কার্যকারিতার জন্য গুরুত্বপূর্ণ হয়)। পরিবর্তে, একটি রানটাইম ক্যাশিং কৌশল ব্যবহার করে নিশ্চিত করুন যে এই সম্পদগুলি আপনি-যাতে-যাতে ক্যাশে করা হয়েছে।
সর্বদা মনে রাখবেন যে প্রিক্যাচিং একটি ব্যবহারকারীর ডিভাইসে নেটওয়ার্ক ব্যান্ডউইথ এবং স্টোরেজ ব্যবহার করে (যেমন একটি অ্যাপ স্টোর থেকে একটি অ্যাপ ইনস্টল করা হয়)। এটি আপনার উপর নির্ভর করে যে ডেভেলপার হিসাবে বিচক্ষণতার সাথে precache করা, এবং একটি ফুলে যাওয়া precache ম্যানিফেস্ট এড়ানো।
ওয়ার্কবক্সের বিল্ড টুল আপনাকে precache ম্যানিফেস্টে আইটেমের সংখ্যা এবং সেইসাথে precache পেলোডের মোট আকার বলে সাহায্য করে।
প্রিক্যাচিংয়ের অগ্রিম খরচ থেকে দীর্ঘমেয়াদে আপনার ওয়েব অ্যাপের সুবিধার জন্য দর্শকদের পুনরাবৃত্তি করুন, যেহেতু এটি নেটওয়ার্ক এড়াতে যে ক্ষমতা দেয় তা সময়ের সাথে সাথে সংরক্ষিত ব্যান্ডউইথের মধ্যে নিজের জন্য অর্থ প্রদান করে।