প্রকাশিত: ২১ অক্টোবর, ২০২৪, সর্বশেষ আপডেট: ৯ সেপ্টেম্বর, ২০২৫
Chrome একটি পরিবর্তন আনছে যাতে Cache-Control: no-store ব্যবহার করে এমন পৃষ্ঠাগুলির জন্য ব্যাক/ফরোয়ার্ড ক্যাশে (bfcache) ব্যবহারের অনুমতি দেওয়া যায় যখন এটি করা নিরাপদ। ডেভেলপারদের জন্য এর অর্থ কী তা জেনে নিন।
পটভূমি
Cache-Control: no-store HTTP হেডার হিসেবে সেট করা একটি সংকেত যে পৃষ্ঠাটি HTTP ক্যাশে সংরক্ষণ করা উচিত নয়। এটি সংবেদনশীল ডেটা ধারণকারী পৃষ্ঠাগুলির জন্য ব্যবহার করা উচিত - উদাহরণস্বরূপ, যখন কোনও ব্যবহারকারী লগ ইন করেন তখন পৃষ্ঠাগুলির জন্য - তবে no-store নির্দেশিকা প্রায়শই সংবেদনশীল ডেটা ছাড়াই পৃষ্ঠাগুলিতে ব্যবহৃত হয়।
bfcache ব্যবহার করে, ব্যবহারকারী যখন অন্যত্র চলে যায় তখন কোনও পৃষ্ঠা ধ্বংস করার পরিবর্তে, আমরা ধ্বংস স্থগিত করি এবং JS এক্সিকিউশন স্থগিত করি। ব্যবহারকারী যদি শীঘ্রই ফিরে আসে, তাহলে আমরা পৃষ্ঠাটি আবার দৃশ্যমান করি এবং JS এক্সিকিউশন স্থগিত করি। এর ফলে ব্যবহারকারীর জন্য প্রায় তাৎক্ষণিকভাবে পৃষ্ঠা নেভিগেশন শুরু হয়।
যদিও HTML স্পেসিফিকেশনের জন্য এটি প্রয়োজনীয় নয়, ব্রাউজারগুলি সাধারণত পৃষ্ঠাটি bfcache-এ রাখা এড়াতে Cache-Control: no-store একটি সংকেত হিসেবে গ্রহণ করে। এটিই bfcache ব্যবহার না করার সবচেয়ে বড় কারণ , মোবাইলে প্রায় 17% ইতিহাস নেভিগেশন এবং ডেস্কটপে 7% ইতিহাস নেভিগেশনের জন্য। এর অর্থ হল এই পৃষ্ঠাগুলি দ্রুত পুনরুদ্ধার থেকে উপকৃত হয় না এবং যেকোনো নেটওয়ার্ক কল, জাভাস্ক্রিপ্ট এক্সিকিউশন এবং রেন্ডারিং সহ পৃষ্ঠাটি সম্পূর্ণরূপে পুনরায় লোড করতে হয়।
প্রায়শই Cache-Control: no-store সেট করা থাকে যাতে সাইট পরিবর্তনের সময় ক্যাশিং সমস্যা এড়ানো যায়, কিন্তু bfcache ব্যবহার করার সময় এই কারণটি কম প্রাসঙ্গিক হয়, কারণ পুরো পৃষ্ঠাটি প্রায় এমনভাবে পুনরুদ্ধার করা হয় যেন এটি সর্বদা খোলা রেখে দেওয়া হয়েছিল।
Chrome কীভাবে এই আচরণ পরিবর্তন করছে
ক্রোম এই আচরণ পরিবর্তন করার ইচ্ছা প্রকাশ করেছে কিন্তু এই পরিবর্তনের জন্য সতর্ক দৃষ্টিভঙ্গি নিচ্ছে। আমরা ক্রোম ১১৬ থেকে ধীরে ধীরে পৃষ্ঠা লোডের শতাংশ বৃদ্ধির জন্য পরীক্ষা-নিরীক্ষা চালিয়ে আসছি এবং ২০২৫ সালের মার্চ এবং এপ্রিল মাসে এটি ১০০% এ পৌঁছাবে বলে আশা করা হচ্ছে।
সংবেদনশীল তথ্য
যদিও আমাদের বিশ্লেষণে দেখা গেছে যে বেশিরভাগ ব্যাক বা ফরোয়ার্ড নেভিগেশনে সংবেদনশীল ডেটা থাকে না এবং তাই bfcache-এর জন্য যোগ্য হওয়া উচিত, এমন কিছু ক্ষেত্রে আছে যেখানে পৃষ্ঠাগুলি bfcache-তে রাখা উচিত নয়। উদাহরণস্বরূপ, লগ আউট করার সময়, সামনে বা পিছনে নেভিগেট করে লগ ইন করা পৃষ্ঠাটি পুনরুদ্ধার করা সম্ভব হবে না।
এটি এড়াতে, কুকিজ বা অন্যান্য অনুমোদন পদ্ধতিতে পরিবর্তনের ক্ষেত্রে Chrome bfcache থেকে একটি পৃষ্ঠা সরিয়ে দেবে।
এছাড়াও, Cache-Control: no-store ব্যবহার করে পৃষ্ঠাগুলির জন্য নিম্নলিখিত API গুলি ব্যবহার করলে সেই পৃষ্ঠাগুলি bfcache-এর জন্য অযোগ্য হয়ে উঠবে:
এছাড়াও, যদি একটি Cache-control: no-store পৃষ্ঠা একটি fetch বা XHR অনুরোধ করে এবং এটি তার প্রতিক্রিয়ায় Cache-control: no-store ফেরত দেয়, তাহলে এটি পৃষ্ঠাটিকেও সরিয়ে দেবে কারণ এতে সংবেদনশীল ডেটা থাকতে পারে।
মনে রাখবেন যে এটি bfcache ব্যবহার প্রতিরোধকারী API গুলির একটি বিস্তৃত তালিকা নয় বরং Cache-Control: no-store পৃষ্ঠাগুলিতে bfcache ব্লক করে এমন API গুলি, এমনকি যদি পৃষ্ঠাটি ছাড়ার সময় সেগুলি ব্যবহার নাও করা হয়।
ঝুঁকি আরও কমাতে Cache-Control: no-store পৃষ্ঠাগুলির জন্য bfcache টাইমআউট 3 মিনিটে কমিয়ে আনা হয়েছে (যে পৃষ্ঠাগুলি Cache-Control: no-store ব্যবহার করে না তাদের জন্য ব্যবহৃত 10 মিনিট থেকে)।
এন্টারপ্রাইজ আউট অপটস
এন্টারপ্রাইজগুলিতে প্রায়শই আপডেট করা কঠিন সফ্টওয়্যার এবং শেয়ার করা ডিভাইস থাকে। Cache-Control: no-store পৃষ্ঠাগুলির জন্য bfcache ব্যবহার প্রতিরোধ করতে AllowBackForwardCacheForCacheControlNoStorePageEnabled নীতিটি অক্ষম করা যেতে পারে।
পরিবর্তন পরীক্ষা করা হচ্ছে
ডেভেলপাররা নিম্নলিখিত পতাকা ব্যবহার করে এই পরিবর্তনটি পরীক্ষা করতে পারেন:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
যদি পূর্ববর্তী কোনও ব্যতিক্রম প্রযোজ্য হয়—যেমন, কুকিজ পরিবর্তন করা—তবে এটি পৃষ্ঠাটিকে bfcache ব্যবহার করতে বাধা দেবে কারণ "যেসব পৃষ্ঠার প্রধান রিসোর্সে Cache-Control: no-store ব্যাক/ফরওয়ার্ড ক্যাশে প্রবেশ করতে পারে না।" Chrome DevTools bfcache tester এ দেখানো হচ্ছে।
এই পতাকাটি সহ এবং ছাড়াই পরীক্ষা করার জন্য আপনি এই bfcache পরীক্ষা পৃষ্ঠাটি ব্যবহার করতে পারেন।
ডেভেলপারদের যা জানা উচিত
যদিও ডেভেলপারদের তাদের ব্যবহারকারীদের এই বৃহত্তর bfcache ব্যবহারের সুবিধা পেতে কোনও পরিবর্তন করতে হবে না, তবে এর ফলে কিছু বিষয় বিবেচনা করতে হতে পারে। ২০২১ সালের ডিসেম্বরে bfcache-এর প্রাথমিক লঞ্চের সময় অন্যান্য সাইটগুলিও একই রকম বিবেচনার সম্মুখীন হতে পারে।
ডেভেলপারদের কি এখনও Cache-Control: no-store ব্যবহার কমানোর লক্ষ্য রাখা উচিত?
পূর্বে উল্লিখিত সীমিত পরিস্থিতিতে এবং শুধুমাত্র Chrome এর জন্য bfcache সক্রিয় করা হয়েছে। Cache Cache-Control: no-store Cache-Control: no-store ব্যবহার করা হলে অন্যান্য ব্রাউজারগুলি এখনও bfcache ব্যবহার ব্লক করতে পারে।
এই হিউরিস্টিকসের উপর নির্ভর না করে Cache-Control: no-store ব্যবহার কমানোই সর্বোত্তম অনুশীলন।
কর্মক্ষমতার উপর প্রভাব
আমরা এই পরিবর্তনটি করার কারণ হল ওয়েব ব্যবহারকারীদের জন্য পৃষ্ঠার অভিজ্ঞতা উন্নত করা। আমরা যখন প্রথম bfcache চালু করেছিলাম তখন Core Web Vitals-এ লক্ষণীয় উন্নতি দেখেছি, এবং এখন আমরা আরও সাইটে একই উন্নতি আনতে চাই।
এটি চালু হওয়ার সাথে সাথে সাইট মালিকরা তাদের কোর ওয়েব ভাইটালগুলিতে উন্নতি দেখতে পাবেন এবং CrUX-এ, CrUX Vis সহ, bfcache ব্যবহার পরিমাপ করতে পারবেন।
প্রভাব বিশ্লেষণ
bfcache থেকে পুনরুদ্ধার করা পৃষ্ঠাগুলি পৃষ্ঠাটি পুনরায় লোড করার পরিবর্তে পুরানো পৃষ্ঠাটি (জাভাস্ক্রিপ্ট হিপ সহ) "পুনরুদ্ধার" করে। অনেক জনপ্রিয় বিশ্লেষণ সরবরাহকারী bfcache পুনরুদ্ধারগুলিকে নতুন পৃষ্ঠা ভিউ হিসাবে পরিমাপ করে না কারণ তারা প্রাথমিকভাবে লোড হওয়ার সময় কেবল পৃষ্ঠা ভিউ ট্রিগার করে।
তাই, সাইটগুলি যখন প্রথমবারের মতো bfcache ব্যবহার শুরু করবে তখন তাদের বিশ্লেষণে পৃষ্ঠা লোড হ্রাস পেতে পারে। আমরা pageshow ইভেন্টের জন্য শ্রোতা সেট করে এবং persisted সম্পত্তি পরীক্ষা করে এগুলিকে পৃষ্ঠাভিউ হিসাবে বিবেচনা করার পরামর্শ দিচ্ছি:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
পৃষ্ঠা পুনরুদ্ধারের সময় আপডেটগুলি পরিচালনা করুন
যেহেতু সাইটগুলি এখন bfcache ব্যবহার দেখতে পাবে, যদিও তারা আগে এটি দেখেনি এবং যখন পৃষ্ঠাটি সম্পূর্ণরূপে তাজা ডেটা দিয়ে পুনরায় লোড হবে, তখন ডেভেলপাররা bfcache পুনরুদ্ধারে ডেটা রিফ্রেশ করার কথা বিবেচনা করতে পারেন।
pageshow ইভেন্ট ব্যবহার করে বিশ্লেষণের জন্য অতিরিক্ত পৃষ্ঠা ভিউ লগ করা এবং persisted সম্পত্তি পরীক্ষা করার মতোই আপডেটগুলি ট্রিগার করা যেতে পারে।
মনে রাখবেন যে সমস্ত কন্টেন্ট আপডেট করার প্রয়োজন নেই এবং ব্যবহারকারীরা হয়তো আগে যে কন্টেন্ট দেখেছিলেন তাতে "ফিরে" যেতে পছন্দ করতে পারেন। উদাহরণস্বরূপ, নিবন্ধের তালিকা রিফ্রেশ করার অর্থ হতে পারে যে ব্যবহারকারী আর সেই নিবন্ধটি দেখতে পাবেন না যা তারা আগে দেখতে যাচ্ছিলেন।
বিজ্ঞাপনের উপর প্রভাব
বিশ্লেষণের প্রভাবের মতো, যদি বিজ্ঞাপনগুলি কেবল পৃষ্ঠা লোডের সময় লোড হয় তবে সাইটগুলিতে বিজ্ঞাপনের ইম্প্রেশন হ্রাস পেতে পারে। সম্পূর্ণ পৃষ্ঠা লোডের সাথে সমতা নিশ্চিত করতে bfcache পুনরুদ্ধারে বিজ্ঞাপনগুলি প্রোগ্রাম্যাটিকভাবে রিফ্রেশ করা যেতে পারে, আবার pageshow ইভেন্ট ব্যবহার করে এবং persisted সম্পত্তি পরীক্ষা করে তবে এটি সর্বদা সঠিক কাজ নাও হতে পারে। বিজ্ঞাপন পুনরায় লোড কীভাবে ট্রিগার করবেন সে সম্পর্কে আপনার বিজ্ঞাপন সরবরাহকারীর ডকুমেন্টেশন দেখুন।
bfcache সম্পর্কে আরও তথ্য
bfcache সম্পর্কে আরও তথ্যের জন্য, আমাদের বিস্তৃত bfcache প্রযুক্তিগত নির্দেশিকা দেখুন।
প্রতিক্রিয়া
আমরা এই পরিবর্তন সম্পর্কে প্রতিক্রিয়া জানতে আগ্রহী, যা bfcache কম্পোনেন্ট ব্যবহার করে Chrome এর ইস্যু ট্র্যাকারে প্রদান করা যেতে পারে।
উপসংহার
ব্যবহারকারীদের পৃষ্ঠার অভিজ্ঞতা উন্নত করার জন্য আমরা আরও অনেক পৃষ্ঠায় bfcache-এর সুবিধা আনতে পেরে আনন্দিত। আমরা এই পরিবর্তনটি সাবধানতার সাথে বিবেচনা করেছি এবং আমাদের পদ্ধতিটি যতটা সম্ভব নিরাপদ উপায়ে এটি চালু করার চেষ্টা করে। আমরা আশা করি এখানে প্রদত্ত তথ্য ডেভেলপারদের এই পরিবর্তনটি বুঝতে এবং এটি ঘটলে সমস্যা এড়াতে প্রয়োজনীয় পরিবর্তন করতে সহায়তা করবে।