Cache-Control: no-store ব্যবহার করে পৃষ্ঠাগুলির জন্য ব্যাক/ফরোয়ার্ড ক্যাশে (bfcache) ব্যবহারের অনুমতি দেওয়ার জন্য Chrome একটি পরিবর্তন করছে যখন এটি করা নিরাপদ। বিকাশকারীদের জন্য এর অর্থ কী তা সন্ধান করুন।
পটভূমি
Cache-Control: no-store একটি সংকেত যে পৃষ্ঠাটি HTTP ক্যাশে সংরক্ষণ করা উচিত নয়। এটি সংবেদনশীল ডেটা রয়েছে এমন পৃষ্ঠাগুলির জন্য ব্যবহার করা উচিত—উদাহরণস্বরূপ, যখন কোনও ব্যবহারকারী লগ ইন করেন তখন পৃষ্ঠাগুলির জন্য—কিন্তু no-store নির্দেশিকাটি প্রায়ই সংবেদনশীল ডেটা ছাড়া পৃষ্ঠাগুলিতে ব্যবহার করা হয়৷
bfcache এর সাথে, ব্যবহারকারী যখন নেভিগেট করে তখন একটি পৃষ্ঠা ধ্বংস করার পরিবর্তে, আমরা ধ্বংস স্থগিত করি এবং JS নির্বাহকে বিরতি দেই। ব্যবহারকারী শীঘ্রই আবার নেভিগেট করলে, আমরা পৃষ্ঠাটিকে আবার দৃশ্যমান করি এবং JS এক্সিকিউশন আনপজ করি। এটি ব্যবহারকারীর জন্য একটি কাছাকাছি তাত্ক্ষণিক পৃষ্ঠা নেভিগেশন ফলাফল.
যদিও এইচটিএমএল স্পেকের দ্বারা এটির প্রয়োজন হয় না, ব্রাউজারগুলি সাধারণত Cache-Control: no-store একটি সংকেত হিসাবে গ্রহণ করে যাতে পৃষ্ঠাটিকে bfcache এ না রাখা যায়। মোবাইলে হিস্ট্রি নেভিগেশনের প্রায় 17% এবং ডেস্কটপে হিস্ট্রি নেভিগেশনের 7% জন্য bfcache ব্যবহার না হওয়ার এটাই সবচেয়ে বড় কারণ । এর মানে এই পৃষ্ঠাগুলি দ্রুত পুনরুদ্ধার থেকে উপকৃত হয় না এবং যেকোন নেটওয়ার্ক কল, জাভাস্ক্রিপ্ট এক্সিকিউশন এবং রেন্ডারিং সহ পৃষ্ঠাটিকে সম্পূর্ণরূপে পুনরায় লোড করতে হবে।
প্রায়শই Cache-Control: no-store সেট করা হয়, কিন্তু যখন bfcache ব্যবহার করা হয় তখন এই কারণটি কম প্রাসঙ্গিক হয়, কারণ পুরো পৃষ্ঠাটি প্রায় এমনভাবে পুনরুদ্ধার করা হয় যেন এটি খোলা রেখে দেওয়া হয়।
কিভাবে Chrome এই আচরণ পরিবর্তন করছে
Chrome এই আচরণ পরিবর্তন করার একটি অভিপ্রায় ঘোষণা করেছে কিন্তু এই পরিবর্তনের জন্য একটি সতর্ক দৃষ্টিভঙ্গি গ্রহণ করছে৷ আমরা Chrome 116 থেকে পরীক্ষা-নিরীক্ষা চালাচ্ছি এবং সম্প্রতি পর্যন্ত এগুলি 5% পৃষ্ঠা লোডের উপর চলছিল।
আমরা ২রা অক্টোবর এটিকে পৃষ্ঠা লোডের 10% এ বাড়িয়েছি এবং নভেম্বরে এটিকে আরও বাড়িয়ে 20% পৃষ্ঠা লোড করতে চাইছি, পরের বছরের শুরুর দিকে 50%, এটির শীঘ্রই এটি সম্পূর্ণরূপে চালু করা হবে, পরবর্তী আলোচনা করা কিছু অপ্ট আউট সহ।
সংবেদনশীল তথ্য
যদিও আমাদের বিশ্লেষণ দেখায় যে বেশিরভাগ পিছনে বা ফরোয়ার্ড নেভিগেশন সংবেদনশীল ডেটা অন্তর্ভুক্ত করে না এবং তাই bfcache এর জন্য যোগ্য হওয়া উচিত, এমন কিছু ক্ষেত্রে রয়েছে যেখানে পৃষ্ঠাগুলি bfcache-এ স্থাপন করা উচিত নয়। উদাহরণস্বরূপ, লগ আউট করার সময়, সামনে বা পিছনে নেভিগেট করে লগ ইন করা পৃষ্ঠা পুনরুদ্ধার করা সম্ভব হবে না।
এটি এড়াতে, Chrome কুকিতে পরিবর্তন বা অন্যান্য অনুমোদন পদ্ধতিতে bfcache থেকে একটি পৃষ্ঠা উচ্ছেদ করবে।
উপরন্তু, Cache-Control: no-store সেই পৃষ্ঠাগুলিকে bfcache-এর জন্য অযোগ্য করে তুলবে:
মনে রাখবেন যে এটি এপিআইগুলির একটি বিস্তৃত তালিকা নয় যা bfcache ব্যবহারকে বাধা দেয় তবে APIগুলি যেগুলি Cache-Control: no-store পৃষ্ঠাগুলি এমনকি যদি সেগুলি পৃষ্ঠা ছেড়ে যাওয়ার সময় ব্যবহার না করা হয়।
Cache-Control: no-store পৃষ্ঠাগুলির জন্য bfcache টাইমআউট আরও ঝুঁকি কমাতে 3 মিনিট (যে পৃষ্ঠাগুলি Cache-Control: no-store ব্যবহার করে না তাদের জন্য 10 মিনিট ব্যবহার করা হয়) কমিয়ে দেওয়া হয়েছে।
এন্টারপ্রাইজ অপ্ট আউট
এন্টারপ্রাইজগুলিতে প্রায়ই আপডেট করা কঠিন সফ্টওয়্যার এবং ভাগ করা ডিভাইস থাকে। AllowBackForwardCacheForCacheControlNoStorePageEnabled নীতিটি Cache-Control: no-store পৃষ্ঠাগুলির জন্য bfcache ব্যবহার প্রতিরোধ চালিয়ে যেতে অক্ষম করা যেতে পারে৷
বিকাশকারীদের কি জানা উচিত
যদিও ডেভেলপারদের তাদের ব্যবহারকারীদের এই বৃহত্তর bfcache ব্যবহার থেকে উপকৃত হওয়ার জন্য কোনও পরিবর্তন করতে হবে না, তবে কিছু জিনিস রয়েছে যা তাদের এটির ফলে বিবেচনা করতে হবে। এগুলি একইরকম বিবেচনা ছিল যা অন্যান্য সাইটগুলি ডিসেম্বর 2021-এ bfcache-এর প্রাথমিক লঞ্চের সময় অনুভব করতে পারে।
কর্মক্ষমতা উপর প্রভাব
আমরা এই পরিবর্তন করার কারণ হল ওয়েবে ব্যবহারকারীদের জন্য পৃষ্ঠার অভিজ্ঞতা উন্নত করা। যখন আমরা প্রথম bfcache চালু করি তখন আমরা Core Web Vitals-এ লক্ষণীয় উন্নতি দেখেছি এবং এখন আমরা সেই একই উন্নতিগুলি আরও সাইটে আনতে চাই৷
সাইটের মালিকরা তাদের মূল ওয়েব ভাইটালগুলিতে উন্নতি দেখতে পাবেন এবং এটি CrUX-এ, CrUX ড্যাশবোর্ড সহ 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 এর সুবিধা নিয়ে আসতে পেরে উত্তেজিত। আমরা এই পরিবর্তনটি যত্ন সহকারে বিবেচনা করেছি এবং আমাদের দৃষ্টিভঙ্গি যতটা সম্ভব নিরাপদ উপায়ে এটি চালু করার চেষ্টা করে। আমরা আশা করি এখানে প্রদত্ত তথ্য ডেভেলপারদের এই পরিবর্তনটি বুঝতে সাহায্য করবে এবং যখন এটি ঘটবে তখন সমস্যা এড়াতে প্রয়োজনীয় পরিবর্তন করতে পারবে৷