stale-while-revalidate-এর মাধ্যমে কন্টেন্ট ফ্রেশ রাখা

আপনার ওয়েব অ্যাপ পরিবেশন করার সময় অবিলম্বে ও ফ্রেশ কন্টেন্ট দেখানোর মধ্যে ভারসাম্য বজায় রাখতে সাহায্য করার জন্য একটি অতিরিক্ত টুল।

Jeff Posnick

কী শিপ করা হয়েছে?

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

আপনার Cache-Control রেসপন্স হেডারে max-age-এর পাশাপাশি stale-while-revalidate সেট করার সুবিধা Chrome 75 এবং Firefox 68-এ উপলভ্য।

যেসব ব্রাউজারে stale-while-revalidate কাজ করে না, সেগুলি কনফিগারেশন ভ্যালু উপেক্ষা করে max-age ব্যবহার করবে, আমি শীঘ্রই এই বিষয়ে ব্যাখ্যা করব…

এর মানে কী?

আসুন stale-while-revalidate-কে দুটি ভাগে ভাগ করি: ক্যাশে করা উত্তর বাসি হতে পারে এবং রিভ্যালিডেশনের প্রসেস।

প্রথমত, ব্রাউজার কীভাবে জানবে যে ক্যাশে করা উত্তর "পুরনো"? stale-while-revalidate সহ Cache-Control রেসপন্স হেডারে max-age-ও থাকতে হবে এবং max-age-এর মাধ্যমে নির্দিষ্ট করা সেকেন্ডের সংখ্যা স্টেলনেস নির্ধারণ করে। max-age-এর থেকে নতুন যেকোনও ক্যাশে করা উত্তরকে ফ্রেশ হিসেবে বিবেচনা করা হয় এবং পুরনো ক্যাশে করা উত্তরকে বাসি হিসেবে বিবেচনা করা হয়।

স্থানীয়ভাবে ক্যাশে করা উত্তর এখনও ফ্রেশ থাকলে, ব্রাউজারের অনুরোধ পূরণ করতে এটি যেমন আছে তেমন ব্যবহার করা যেতে পারে। stale-while-revalidate-এর দৃষ্টিভঙ্গি থেকে, এই পরিস্থিতিতে কিছু করার নেই।

কিন্তু ক্যাশে করা উত্তরটি পুরনো হলে, বয়স-ভিত্তিক আরেকটি চেক করা হয়: ক্যাশে করা উত্তরের বয়স কি stale-while-revalidate সেটিংয়ের মাধ্যমে প্রদান করা অতিরিক্ত সময়সীমার মধ্যে পড়ে?

কোনও পুরনো উত্তরের বয়স এই উইন্ডোর মধ্যে পড়লে, ব্রাউজারের অনুরোধ পূরণ করতে এটি ব্যবহার করা হবে। একই সময়ে, নেটওয়ার্কের কাছে "আবার যাচাই করার" অনুরোধ করা হবে যাতে ক্যাশে করা উত্তর ব্যবহার করতে দেরি না হয়। ফেরত পাঠানো উত্তরে আগে থেকে ক্যাশে করা উত্তরের মতো একই তথ্য থাকতে পারে অথবা এটি আলাদা হতে পারে। যাই হোক না কেন, নেটওয়ার্ক রেসপন্স স্থানীয়ভাবে স্টোর করা হয়, আগে থেকে যা কিছু ক্যাশে ছিল তা সরিয়ে দেয় এবং ভবিষ্যতে যেকোনও max-age তুলনার সময় ব্যবহার করা "ফ্রেশনেস" টাইমার রিসেট করে।

তবে, ক্যাশে করা পুরনো উত্তর যদি এতটাই পুরনো হয় যে তা stale-while-revalidate সময়সীমার বাইরে চলে যায়, তাহলে সেটি ব্রাউজারের অনুরোধ পূরণ করবে না। পরিবর্তে, ব্রাউজার নেটওয়ার্ক থেকে একটি উত্তর পাবে এবং প্রাথমিক অনুরোধ পূরণ করা এবং নতুন উত্তর সহ স্থানীয় ক্যাশে পপুলেট করা, উভয় ক্ষেত্রেই এটি ব্যবহার করবে।

লাইভ উদাহরণ

বর্তমান সময় দেখানোর জন্য HTTP API-এর একটি সহজ উদাহরণ নিচে দেওয়া হল—আরও নির্দিষ্টভাবে বলতে গেলে, বর্তমান ঘণ্টায় কত মিনিট হয়েছে তা দেখানো।

এই পরিস্থিতিতে, ওয়েব সার্ভার তার HTTP রেসপন্সে এই Cache-Control হেডার ব্যবহার করে:

Cache-Control: max-age=1, stale-while-revalidate=59

এই সেটিংয়ের অর্থ হল, পরবর্তী ১ সেকেন্ডের মধ্যে সময়ের জন্য অনুরোধের পুনরাবৃত্তি হলে, আগে ক্যাশে করা ভ্যালু তখনও ফ্রেশ থাকবে এবং কোনও রিভ্যালিডেশন ছাড়াই যেমন আছে তেমন ব্যবহার করা হবে।

১ থেকে ৬০ সেকেন্ডের মধ্যে কোনও অনুরোধের পুনরাবৃত্তি হলে, ক্যাশে করা ভ্যালু পুরনো হয়ে যাবে, তবে API অনুরোধ পূরণ করতে ব্যবহার করা হবে। একই সময়ে, "ব্যাকগ্রাউন্ডে," ক্যাশে পপুলেট করার জন্য একটি রিভ্যালিডেশন অনুরোধ করা হবে যাতে ভবিষ্যতে ব্যবহারের জন্য নতুন ভ্যালু পাওয়া যায়।

৬০ সেকেন্ডের বেশি সময় পরে কোনও অনুরোধের পুনরাবৃত্তি হলে, পুরনো রেসপন্স একেবারেই ব্যবহার করা হয় না এবং ব্রাউজারের অনুরোধ পূরণ করা ও ক্যাশে পুনরায় যাচাই করা, নেটওয়ার্ক থেকে রেসপন্স পাওয়ার উপর নির্ভর করবে।

এখানে সেই তিনটি স্বতন্ত্র অবস্থার একটি ব্রেকডাউন রয়েছে, সাথে সময়ের উইন্ডো যার মধ্যে প্রতিটি আমাদের উদাহরণের জন্য প্রযোজ্য:

পূর্ববর্তী বিভাগ থেকে তথ্য ব্যাখ্যা করে এমন একটি ডায়াগ্রাম।

সাধারণত কোন কোন ক্ষেত্রে এটি ব্যবহার করা হয়?

"ঘণ্টার পরে মিনিট" API পরিষেবার জন্য উপরে দেওয়া উদাহরণটি কাল্পনিক হলেও, এটি প্রত্যাশিত ব্যবহারের উদাহরণ তুলে ধরে—এমন পরিষেবা যা তথ্য প্রদান করে যা রিফ্রেশ করা প্রয়োজন, তবে যেখানে কিছুটা পুরনো তথ্য গ্রহণযোগ্য।

কম কৃত্রিম উদাহরণের মধ্যে বর্তমান আবহাওয়ার পরিস্থিতি সংক্রান্ত API বা গত এক ঘণ্টায় লেখা সেরা খবরের হেডলাইন অন্তর্ভুক্ত হতে পারে।

সাধারণত, পরিচিত ইন্টারভালে আপডেট হয়, একাধিকবার অনুরোধ করা হতে পারে এবং সেই ইন্টারভালে স্ট্যাটিক থাকে এমন যেকোনও উত্তর max-age-এর মাধ্যমে স্বল্প-মেয়াদী ক্যাশিংয়ের জন্য উপযুক্ত। max-age-এর সাথে stale-while-revalidate ব্যবহার করলে, নেটওয়ার্ক রেসপন্সে ব্লক না করে, আরও ফ্রেশ কন্টেন্ট সহ ক্যাশে থেকে ভবিষ্যতের অনুরোধ পূরণ করার সম্ভাবনা বৃদ্ধি পায়।

এটি কীভাবে সার্ভিস ওয়ার্কারের সাথে ইন্টার‍্যাক্ট করে?

আপনি যদি stale-while-revalidate-এর ব্যাপারে শুনে থাকেন, তাহলে সম্ভবত সেটি সার্ভিস ওয়ার্কার-এর মধ্যে ব্যবহৃত রেসিপি-এর প্রসঙ্গে শুনেছেন।

Cache-Control হেডারের মাধ্যমে stale-while-revalidate ব্যবহার করার সাথে সার্ভিস ওয়ার্কারে এর ব্যবহারের কিছু মিল আছে এবং ফ্রেশনেস ট্রেড-অফ ও সর্বাধিক লাইফটাইমের ক্ষেত্রে একই ধরনের অনেক বিষয় প্রযোজ্য হয়। তবে, সার্ভিস ওয়ার্কার-ভিত্তিক পদ্ধতি প্রয়োগ করবেন নাকি শুধু Cache-Control হেডার কনফিগারেশনের উপর নির্ভর করবেন, সেই সিদ্ধান্ত নেওয়ার সময় আপনাকে কয়েকটি বিষয় বিবেচনা করতে হবে।

সার্ভিস ওয়ার্কার অ্যাপ্রোচ ব্যবহার করুন যদি…

  • আপনি আগে থেকেই আপনার ওয়েব অ্যাপে সার্ভিস ওয়ার্কার ব্যবহার করছেন।
  • আপনার ক্যাশের কন্টেন্টের উপর আপনার সূক্ষ্ম-দানাদার নিয়ন্ত্রণ প্রয়োজন এবং সবচেয়ে কম-সম্প্রতি ব্যবহৃত মেয়াদ শেষ হওয়ার নীতির মতো কিছু বাস্তবায়ন করতে চান। Workbox-এর ক্যাশে এক্সপায়ার হওয়া মডিউল এই বিষয়ে সাহায্য করতে পারে।
  • আপনি চান যে ব্যাকগ্রাউন্ডে কোনও পুরনো উত্তর পরিবর্তন হলে আপনাকে বিজ্ঞপ্তি পাঠানো হোক। এটি রিভ্যালিডেশন ধাপের সময় ঘটে। Workbox-এর ব্রডকাস্ট ক্যাশে আপডেট মডিউল এই ব্যাপারে সাহায্য করতে পারে।
  • সব আধুনিক ব্রাউজারে আপনার এই stale-while-revalidate আচরণ প্রয়োজন।

Cache-Control পদ্ধতি ব্যবহার করুন যদি…

  • আপনি বরং আপনার ওয়েব অ্যাপের জন্য কোনও সার্ভিস ওয়ার্কার ডিপ্লয় এবং রক্ষণাবেক্ষণের ওভারহেড নিয়ে ডিল করতে চান না।
  • ব্রাউজারের অটোমেটিক ক্যাশে ম্যানেজমেন্ট আপনার লোকাল ক্যাশে খুব বেশি বড় হতে বাধা দিলে আপনার কোনও সমস্যা নেই।
  • আপনি এমন একটি পদ্ধতি ব্যবহার করতে চান যা বর্তমানে সব আধুনিক ব্রাউজারে কাজ করে না (জুলাই ২০১৯ পর্যন্ত; ভবিষ্যতে আরও ব্রাউজারে কাজ করতে পারে)।

আপনি যদি কোনও সার্ভিস ওয়ার্কার ব্যবহার করেন এবং Cache-Control হেডারের মাধ্যমে কিছু উত্তরের জন্য stale-while-revalidate চালু করে থাকেন, তাহলে সাধারণত সার্ভিস ওয়ার্কার অনুরোধের উত্তর দেওয়ার জন্য "প্রথম সুযোগ" পাবে। সার্ভিস ওয়ার্কার উত্তর না দেওয়ার সিদ্ধান্ত নিলে অথবা উত্তর জেনারেট করার প্রসেসে fetch() ব্যবহার করে নেটওয়ার্ক অনুরোধ করলে, Cache-Control হেডারের মাধ্যমে কনফিগার করা আচরণ কার্যকর হবে।

আরও জানুন