ফ্রেশার সার্ভিস কর্মীরা, ডিফল্টরূপে

Jeff Posnick

tl; ড

Chrome 68 থেকে শুরু করে, HTTP অনুরোধগুলি যেগুলি পরিষেবা কর্মী স্ক্রিপ্টের আপডেটগুলি পরীক্ষা করে তা ডিফল্টরূপে HTTP ক্যাশে দ্বারা আর পূরণ করা হবে না৷ এটি একটি সাধারণ বিকাশকারীর ব্যথা বিন্দুর চারপাশে কাজ করে, যেখানে আপনার পরিষেবা কর্মী স্ক্রিপ্টে একটি অসাবধানতাবশত Cache-Control হেডার সেট করা আপডেটগুলি বিলম্বিত হতে পারে৷

আপনি যদি ইতিমধ্যেই আপনার /service-worker.js স্ক্রিপ্টের Cache-Control: max-age=0 এর সাথে পরিবেশন করে HTTP ক্যাশিং থেকে অপ্ট-আউট করে থাকেন, তাহলে নতুন ডিফল্ট আচরণের কারণে আপনি কোনো পরিবর্তন দেখতে পাবেন না।

অতিরিক্তভাবে, Chrome 78 থেকে শুরু করে, importScripts() এর মাধ্যমে পরিষেবা কর্মীতে লোড করা স্ক্রিপ্টগুলিতে বাইট-ফর-বাইটের তুলনা প্রয়োগ করা হবে। একটি আমদানি করা স্ক্রিপ্টে করা যেকোনো পরিবর্তন পরিষেবা কর্মী আপডেট প্রবাহকে ট্রিগার করবে, ঠিক যেমন শীর্ষ-স্তরের পরিষেবা কর্মীর পরিবর্তন হবে।

পটভূমি

প্রতিবার যখন আপনি একটি পরিষেবা কর্মীদের সুযোগের অধীনে একটি নতুন পৃষ্ঠায় নেভিগেট করবেন, স্পষ্টভাবে JavaScript থেকে registration.update() কল করুন, বা যখন কোনও পরিষেবা কর্মী একটি push বা sync ইভেন্টের মাধ্যমে "জাগিয়ে" থাকবে, ব্রাউজার সমান্তরালভাবে অনুরোধ করবে জাভাস্ক্রিপ্ট রিসোর্স যা মূলত navigator.serviceWorker.register() কলে পাঠানো হয়েছিল, সার্ভিস ওয়ার্কার স্ক্রিপ্টের আপডেট খোঁজার জন্য।

এই নিবন্ধটির উদ্দেশ্যে, আসুন ধরে নেওয়া যাক এর URL হল /service-worker.js এবং এতে importScripts() এর জন্য একটি একক কল রয়েছে, যা পরিষেবা কর্মীর ভিতরে চালানো অতিরিক্ত কোড লোড করে:

// Inside our /service-worker.js file:
importScripts('path/to/import.js');

// Other top-level code goes here.

কি পরিবর্তন হচ্ছে?

Chrome 68-এর আগে, /service-worker.js এর জন্য আপডেট অনুরোধ HTTP ক্যাশের মাধ্যমে করা হবে (যেমন বেশির ভাগ আনা হয়)। এর অর্থ হল যদি স্ক্রিপ্টটি মূলত Cache-Control: max-age=600 , পরবর্তী 600 সেকেন্ডের (10 মিনিট) মধ্যে আপডেটগুলি নেটওয়ার্কে যাবে না, তাই ব্যবহারকারী সবচেয়ে আপ-টু-ডেট সংস্করণ নাও পেতে পারেন সেবা কর্মীর। যাইহোক, যদি max-age 86400 (24 ঘন্টা) এর বেশি হয়, তবে এটিকে 86400 হিসাবে বিবেচনা করা হবে, যাতে ব্যবহারকারীরা চিরতরে একটি নির্দিষ্ট সংস্করণে আটকে না যায়।

68 থেকে শুরু করে, পরিষেবা কর্মী স্ক্রিপ্টে আপডেটের অনুরোধ করার সময় HTTP ক্যাশে উপেক্ষা করা হবে, তাই বিদ্যমান ওয়েব অ্যাপ্লিকেশনগুলি তাদের পরিষেবা কর্মী স্ক্রিপ্টের জন্য অনুরোধের ফ্রিকোয়েন্সি বৃদ্ধি দেখতে পারে৷ importScripts জন্য অনুরোধগুলি এখনও HTTP ক্যাশের মাধ্যমে যাবে৷ কিন্তু এটি শুধুমাত্র ডিফল্ট—একটি নতুন নিবন্ধন বিকল্প, updateViaCache উপলব্ধ যা এই আচরণের উপর নিয়ন্ত্রণ প্রদান করে।

updateViaCache

navigator.serviceWorker.register() : updateViaCache প্যারামিটারে কল করার সময় বিকাশকারীরা এখন একটি নতুন বিকল্পে পাস করতে পারে। এটি তিনটি মানগুলির মধ্যে একটি লাগে: 'imports' , 'all' , বা 'none' ।

আপডেট করা পরিষেবা কর্মী সংস্থানগুলি পরীক্ষা করার জন্য HTTP অনুরোধ করার সময় ব্রাউজারের মানক HTTP ক্যাশে কার্যকর হয় কিনা এবং কিভাবে মানগুলি নির্ধারণ করে৷

• 'imports' এ সেট করা হলে, /service-worker.js স্ক্রিপ্টের আপডেট চেক করার সময় HTTP ক্যাশে কখনই পরামর্শ করা হবে না, কিন্তু কোনো আমদানি করা স্ক্রিপ্ট ( path/to/import.js , আমাদের উদাহরণে) আনার সময় পরামর্শ করা হবে। . এটি ডিফল্ট, এবং এটি Chrome 68 থেকে শুরু হওয়া আচরণের সাথে মেলে।

• 'all' -এ সেট করা হলে, শীর্ষ-স্তরের /service-worker.js স্ক্রিপ্ট, সেইসাথে path/to/import.js মতো পরিষেবা কর্মীর ভিতরে আমদানি করা যেকোনো স্ক্রিপ্টের জন্য অনুরোধ করার সময় HTTP ক্যাশের সাথে পরামর্শ করা হবে। . এই বিকল্পটি Chrome 68-এর পূর্বে ক্রোমের পূর্ববর্তী আচরণের সাথে মিলে যায়।

• যখন 'none' তে সেট করা হয়, তখন হয় শীর্ষ-স্তরের /service-worker.js বা অনুমানমূলক path/to/import.js মতো কোনো আমদানি করা স্ক্রিপ্টের জন্য অনুরোধ করার সময় HTTP ক্যাশের সাথে পরামর্শ করা হবে না।

উদাহরণস্বরূপ, নিম্নলিখিত কোডটি একজন পরিষেবা কর্মীকে নিবন্ধন করবে এবং নিশ্চিত করবে যে /service-worker.js স্ক্রিপ্ট, অথবা /service-worker.js এর ভিতরে importScripts() এর মাধ্যমে উল্লেখ করা যেকোনো স্ক্রিপ্টের আপডেট চেক করার সময় HTTP ক্যাশে কখনই পরামর্শ করা হবে না। /service-worker.js :

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js', {
    updateViaCache: 'none',
    // Optionally, set 'scope' here, if needed.
  });
}

আমদানি করা স্ক্রিপ্টগুলির আপডেটের জন্য পরীক্ষা করে

Chrome 78-এর আগে, importScripts() মাধ্যমে লোড করা যেকোন পরিষেবা কর্মী স্ক্রিপ্ট শুধুমাত্র একবারই পুনরুদ্ধার করা হবে (HTTP ক্যাশে বা নেটওয়ার্কের মাধ্যমে, updateViaCache কনফিগারেশনের উপর নির্ভর করে প্রথমে চেক করা)। সেই প্রাথমিক পুনরুদ্ধারের পরে, এটি ব্রাউজার দ্বারা অভ্যন্তরীণভাবে সংরক্ষণ করা হবে এবং পুনরায় আনা হবে না।

একটি আমদানি করা স্ক্রিপ্টে পরিবর্তনগুলি বেছে নেওয়ার জন্য একটি ইতিমধ্যে ইনস্টল করা পরিষেবা কর্মীকে বাধ্য করার একমাত্র উপায় হল স্ক্রিপ্টের URL পরিবর্তন করা, সাধারণত সেমভার মান যোগ করে (যেমন importScripts('https://example.com/v1.1.0/index.js') ) বা বিষয়বস্তুর একটি হ্যাশ অন্তর্ভুক্ত করে (যেমন importScripts('https://example.com/index.abcd1234.js') )। আমদানি করা URL পরিবর্তন করার একটি পার্শ্ব-প্রতিক্রিয়া হল শীর্ষ-স্তরের পরিষেবা কর্মী স্ক্রিপ্টের বিষয়বস্তু পরিবর্তিত হয়, যা পরিবর্তিতভাবে পরিষেবা কর্মী আপডেট প্রবাহকে ট্রিগার করে।

Chrome 78 দিয়ে শুরু করে, প্রতিবার একটি শীর্ষ-স্তরের পরিষেবা কর্মী ফাইলের জন্য আপডেট চেক করা হয়, কোনো আমদানি করা স্ক্রিপ্টের বিষয়বস্তু পরিবর্তিত হয়েছে কিনা তা নির্ধারণ করতে একই সময়ে চেক করা হবে। ব্যবহৃত Cache-Control হেডারের উপর নির্ভর করে, এই আমদানি করা স্ক্রিপ্ট চেকগুলি HTTP ক্যাশে দ্বারা পূরণ করা হতে পারে যদি updateViaCache 'all' বা 'imports' (যা ডিফল্ট মান) সেট করা থাকে, অথবা চেকগুলি সরাসরি নেটওয়ার্কের বিরুদ্ধে যেতে পারে যদি updateViaCache 'none' এ সেট করা হয়েছে।

যদি কোনও আমদানি করা স্ক্রিপ্টের জন্য আপডেট চেক করার ফলে পরিষেবা কর্মী দ্বারা পূর্বে যা সংরক্ষণ করা হয়েছিল তার তুলনায় একটি বাইট-ফর-বাইটের পার্থক্য দেখা যায়, তাহলে এটি সম্পূর্ণ পরিষেবা কর্মী আপডেট প্রবাহকে ট্রিগার করবে, এমনকি শীর্ষ-স্তরের পরিষেবা কর্মী ফাইলটি থেকে গেলেও একই

ক্রোম 78 এর আচরণ বেশ কয়েক বছর আগে ফায়ারফক্স 56-এ যা প্রয়োগ করেছিল তার সাথে মিলে যায়। Safari ইতিমধ্যে এই আচরণটিও প্রয়োগ করে।

ডেভেলপারদের কি করতে হবে?

আপনি যদি আপনার /service-worker.js স্ক্রিপ্টের জন্য Cache-Control: max-age=0 (বা অনুরূপ মান) দিয়ে পরিবেশন করার মাধ্যমে কার্যকরভাবে HTTP ক্যাশিং থেকে অপ্ট-আউট করে থাকেন, তাহলে আপনি এর কারণে কোনো পরিবর্তন দেখতে পাবেন না নতুন ডিফল্ট আচরণ।

আপনি যদি আপনার /service-worker.js স্ক্রিপ্টটি HTTP ক্যাশিং সক্ষম করে পরিবেশন করেন, হয় ইচ্ছাকৃতভাবে বা এটি শুধুমাত্র আপনার হোস্টিং পরিবেশের জন্য ডিফল্ট , আপনি আপনার বিরুদ্ধে করা /service-worker.js এর জন্য অতিরিক্ত HTTP অনুরোধগুলির একটি আপটিক দেখতে শুরু করতে পারেন সার্ভার—এগুলি এমন অনুরোধ যা HTTP ক্যাশে দ্বারা পূরণ করা হত। আপনি যদি আপনার /service-worker.js এর সতেজতাকে প্রভাবিত করতে Cache-Control হেডার মানকে অনুমতি দেওয়া চালিয়ে যেতে চান, তাহলে আপনার পরিষেবা কর্মীকে নিবন্ধন করার সময় আপনাকে স্পষ্টভাবে updateViaCache: 'all' সেট করা শুরু করতে হবে।

পুরানো ব্রাউজার সংস্করণগুলিতে ব্যবহারকারীদের দীর্ঘ-টেইল থাকতে পারে তা প্রদত্ত, পরিষেবা কর্মী স্ক্রিপ্টগুলিতে Cache-Control: max-age=0 HTTP হেডার সেট করা চালিয়ে যাওয়া এখনও একটি ভাল ধারণা, যদিও নতুন ব্রাউজারগুলি তাদের উপেক্ষা করতে পারে।

বিকাশকারীরা এই সুযোগটি ব্যবহার করে সিদ্ধান্ত নিতে পারে যে তারা তাদের আমদানি করা স্ক্রিপ্টগুলি এখনই HTTP ক্যাশিং থেকে স্পষ্টভাবে বেছে নিতে চায় এবং উপযুক্ত হলে তাদের পরিষেবা কর্মী নিবন্ধনে updateViaCache: 'none' যোগ করতে চায়।

আমদানিকৃত স্ক্রিপ্ট পরিবেশন করা হচ্ছে

Chrome 78 দিয়ে শুরু করে, বিকাশকারীরা importScripts() মাধ্যমে লোড করা সংস্থানগুলির জন্য আরও ইনকামিং HTTP অনুরোধগুলি দেখতে পারে, যেহেতু সেগুলি এখন আপডেটের জন্য পরীক্ষা করা হবে৷

আপনি যদি এই অতিরিক্ত HTTP ট্র্যাফিক এড়াতে চান, তাহলে দীর্ঘস্থায়ী Cache-Control শিরোনামগুলি সেট করুন যখন স্ক্রিপ্টগুলি তাদের URL-এ সেমভার বা হ্যাশগুলি অন্তর্ভুক্ত করে এবং 'imports' এর ডিফল্ট updateViaCache আচরণের উপর নির্ভর করুন।

বিকল্পভাবে, যদি আপনি চান যে আপনার আমদানি করা স্ক্রিপ্টগুলি ঘন ঘন আপডেটের জন্য পরীক্ষা করা হোক, তাহলে নিশ্চিত করুন যে আপনি সেগুলিকে Cache-Control: max-age=0 দিয়ে পরিবেশন করছেন বা আপনি updateViaCache: 'none' ব্যবহার করছেন।

আরও পড়া

জ্যাক আর্চিবাল্ডের " দ্য সার্ভিস ওয়ার্কার লাইফসাইকেল " এবং " ক্যাচিং বেস্ট প্র্যাকটিস এবং ম্যাক্স-এজ গোটচাস " উভয়ই ওয়েবে যেকোন কিছু স্থাপনকারী ডেভেলপারদের জন্য পড়ার সুপারিশ করা হয়।