ব্যাক/ফরওয়ার্ড ক্যাশে

Philip Walton

Barry Pollard

প্রকাশিত: ২৫ মে, ২০২৩, সর্বশেষ হালনাগাদ: ২৫ মার্চ, ২০২৫

ব্যাক/ফরোয়ার্ড ক্যাশে (বা বিএফক্যাশ) হলো একটি ব্রাউজার অপটিমাইজেশন যা তাৎক্ষণিক সামনে ও পেছনে যাওয়ার সুবিধা দেয়। এটি ব্রাউজিং অভিজ্ঞতাকে উল্লেখযোগ্যভাবে উন্নত করে, বিশেষ করে ধীরগতির নেটওয়ার্ক বা ডিভাইস ব্যবহারকারীদের জন্য।

ওয়েব ডেভেলপার হিসেবে, bfcache-এর জন্য আপনার পেজগুলোকে কীভাবে অপ্টিমাইজ করতে হয় তা বোঝা অত্যন্ত জরুরি, যাতে আপনার ব্যবহারকারীরা এর সুবিধাগুলো ভোগ করতে পারেন।

ব্রাউজার সামঞ্জস্যতা

ক্রোম ৯৬ সংস্করণ থেকে, ফায়ারফক্স এবং সাফারি সহ সকল প্রধান ব্রাউজারে একটি bfcache অন্তর্ভুক্ত থাকে।

বিএফক্যাশের মৌলিক বিষয়াবলী

ব্যাক/ফরোয়ার্ড ক্যাশে (bfcache) ব্যবহার করলে, ব্যবহারকারী অন্য পেজে চলে গেলে পেজটি মুছে ফেলার পরিবর্তে, আমরা সেই মুছে ফেলার প্রক্রিয়াটি স্থগিত রাখি এবং জাভাস্ক্রিপ্ট (JS) চালানো থামিয়ে দিই। যদি ব্যবহারকারী শীঘ্রই ফিরে আসেন, আমরা পেজটিকে আবার দৃশ্যমান করে তুলি এবং জাভাস্ক্রিপ্ট চালানো পুনরায় চালু করি। এর ফলে ব্যবহারকারী প্রায় সঙ্গে সঙ্গেই পেজে ফিরে যেতে পারেন।

কতবার এমন হয়েছে যে আপনি কোনো ওয়েবসাইটে গিয়ে অন্য পেজে যাওয়ার জন্য লিঙ্কে ক্লিক করেছেন, কিন্তু পরে বুঝতে পেরেছেন যে এটি আপনার কাঙ্ক্ষিত পেজ নয় এবং ব্যাক বাটনে ক্লিক করেছেন? সেই মুহূর্তে, আগের পেজটি কত দ্রুত লোড হবে, তাতে bfcache একটি বড় পার্থক্য গড়ে দিতে পারে।

নেভিগেশনে bfcache কতটা গতি বাড়াতে পারে তা বুঝতে এর কার্যকারিতার এই ভিডিওটি দেখুন:

ভিডিওটিতে, bfcache সহ উদাহরণটি এটি ছাড়া উদাহরণটির চেয়ে বেশ খানিকটা দ্রুততর।

bfcache শুধু নেভিগেশনের গতিই বাড়ায় না, এটি ডেটা ব্যবহারও কমায়, কারণ রিসোর্সগুলো পুনরায় ডাউনলোড করার প্রয়োজন হয় না।

ক্রোম ব্যবহারের ডেটা থেকে দেখা যায় যে, ডেস্কটপে প্রতি ১০টি নেভিগেশনের মধ্যে ১টি এবং মোবাইলে প্রতি ৫টি নেভিগেশনের মধ্যে ১টি হয় পেছনে যাওয়া অথবা সামনে যাওয়া। bfcache সক্রিয় থাকলে, ব্রাউজারগুলো প্রতিদিন শত শত কোটি ওয়েব পেজের জন্য প্রয়োজনীয় ডেটা ট্রান্সফার এবং লোড হওয়ার সময়কে সম্পূর্ণরূপে দূর করতে পারে!

"ক্যাশ" কীভাবে কাজ করে

bfcache যে "ক্যাশ" ব্যবহার করে তা HTTP ক্যাশ থেকে ভিন্ন, যা বারবার নেভিগেশনের গতি বাড়াতে নিজস্ব ভূমিকা পালন করে। bfcache হলো জাভাস্ক্রিপ্ট হিপ সহ মেমরিতে থাকা সম্পূর্ণ পেজটির একটি স্ন্যাপশট, যেখানে HTTP ক্যাশে শুধুমাত্র পূর্বে করা অনুরোধগুলোর প্রতিক্রিয়া থাকে। যেহেতু একটি পেজ লোড করার জন্য প্রয়োজনীয় সমস্ত অনুরোধ HTTP ক্যাশ থেকে পূরণ হওয়া খুবই বিরল, তাই bfcache রিস্টোর ব্যবহার করে বারবার ভিজিট করা এমনকি সবচেয়ে ভালোভাবে অপ্টিমাইজ করা নন-bfcache নেভিগেশনের চেয়েও সর্বদা দ্রুততর হয়।

পরবর্তীতে আবার চালু করার উদ্দেশ্যে কোনো পেজকে ফ্রিজ করার ক্ষেত্রে, চলমান কোড কীভাবে সবচেয়ে ভালোভাবে সংরক্ষণ করা যায়, সেই বিষয়ে কিছু জটিলতা রয়েছে। উদাহরণস্বরূপ, পেজটি bfcache-এ থাকা অবস্থায় টাইমআউট শেষ হয়ে গেলে setTimeout() কলগুলো আপনি কীভাবে সামলাবেন?

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

কিছু ক্ষেত্রে, যেমন টাইমআউট এবং প্রমিজের জন্য, এটি বেশ কম ঝুঁকিপূর্ণ, কিন্তু অন্যান্য ক্ষেত্রে এটি বিভ্রান্তিকর বা অপ্রত্যাশিত আচরণের কারণ হতে পারে। উদাহরণস্বরূপ, যদি ব্রাউজার এমন কোনো কাজ থামিয়ে দেয় যা একটি IndexedDB ট্রানজ্যাকশনের অংশ হিসেবে প্রয়োজন, তবে এটি একই অরিজিনে খোলা অন্যান্য ট্যাবকে প্রভাবিত করতে পারে, কারণ একই IndexedDB ডেটাবেস একাধিক ট্যাব দ্বারা একই সাথে অ্যাক্সেস করা যায়। ফলস্বরূপ, ব্রাউজারগুলো সাধারণত কোনো IndexedDB ট্রানজ্যাকশনের মাঝখানে বা এমন কোনো API ব্যবহার করার সময় পেজ ক্যাশ করার চেষ্টা করে না যা অন্য পেজকে প্রভাবিত করতে পারে।

বিভিন্ন API-এর ব্যবহার কীভাবে একটি পেজের bfcache যোগ্যতার উপর প্রভাব ফেলে, সে সম্পর্কে আরও বিস্তারিত জানতে, 'Optimize your pages for bfcache ' দেখুন।

বিএফক্যাশ এবং আইফ্রেম

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

তবে, যখন বিএফক্যাশ থেকে মূল ফ্রেমটি পুনরুদ্ধার করা হবে, তখন এমবেডেড আইফ্রেমগুলিও সেই অবস্থাতেই পুনরুদ্ধার হবে, যে অবস্থায় পৃষ্ঠাটি বিএফক্যাশে প্রবেশ করেছিল।

যদি কোনো এমবেডেড আইফ্রেম এমন এপিআই ব্যবহার করে যা বিএফক্যাশ (bfcache) ব্যবহারে বাধা দেয়, তাহলে মেইনফ্রেমের বিএফক্যাশ ব্যবহারও ব্লক হয়ে যেতে পারে। এটি এড়ানোর জন্য মেইনফ্রেমে পারমিশন পলিসি (Permissions Policy) সেট করা অথবা sandbox attributes) ব্যবহার করা যেতে পারে।

বিএফক্যাশ এবং সিঙ্গেল পেজ অ্যাপস (এসপিএ)

যেহেতু bfcache ব্রাউজার-পরিচালিত নেভিগেশনের সাথে কাজ করে, তাই এটি একটি সিঙ্গেল-পেজ অ্যাপ (SPA)-এর ভেতরের 'সফট নেভিগেশন'-এর জন্য কাজ করে না। তবে, অ্যাপটিকে আবার শুরু থেকে সম্পূর্ণভাবে পুনরায় চালু না করে, কোনো SPA-তে ফিরে যাওয়ার ক্ষেত্রেও bfcache সাহায্য করতে পারে।

bfcache পর্যবেক্ষণ করার জন্য API

যদিও বিএফক্যাশ (bfcache) একটি অপটিমাইজেশন যা ব্রাউজারগুলো স্বয়ংক্রিয়ভাবে করে থাকে, তবুও ডেভেলপারদের জন্য এটি কখন ঘটছে তা জানা গুরুত্বপূর্ণ, যাতে তারা এর জন্য তাদের পেজগুলো অপটিমাইজ করতে পারে এবং সেই অনুযায়ী যেকোনো মেট্রিক বা পারফরম্যান্স পরিমাপ সমন্বয় করতে পারে ।

bfcache পর্যবেক্ষণ করার জন্য ব্যবহৃত প্রধান ইভেন্টগুলো হলো pageshow এবং pagehide পেজ ট্রানজিশন ইভেন্ট , যেগুলো বেশিরভাগ ব্রাউজার দ্বারা সমর্থিত।

নতুন পেজ লাইফসাইকেল ইভেন্ট— freeze এবং resume —পেজ যখন bfcache-এ প্রবেশ করে বা তা থেকে বেরিয়ে যায়, তখন এবং আরও কিছু পরিস্থিতিতে, যেমন সিপিইউ ব্যবহার কমানোর জন্য যখন কোনো ব্যাকগ্রাউন্ড ট্যাব ফ্রিজ হয়ে যায়, তখনও ডিসপ্যাচ করা হয়। এই ইভেন্টগুলো শুধুমাত্র ক্রোমিয়াম-ভিত্তিক ব্রাউজারগুলিতে সমর্থিত।

bfcache থেকে কখন একটি পৃষ্ঠা পুনরুদ্ধার করা হয় তা পর্যবেক্ষণ করুন।

পেজটি প্রাথমিকভাবে লোড হওয়ার সময় এবং যখনই পেজটি বিএফক্যাশ (bfcache) থেকে রিস্টোর করা হয়, তখন load ইভেন্টের ঠিক পরেই pageshow ইভেন্টটি ফায়ার হয়। pageshow ইভেন্টের একটি persisted ) প্রপার্টি আছে, যা পেজটি বিএফক্যাশ থেকে রিস্টোর করা হলে ট্রু ( true এবং অন্যথায় false হয়। সাধারণ পেজ লোড এবং বিএফক্যাশ রিস্টোরের মধ্যে পার্থক্য করার জন্য আপনি persisted প্রপার্টিটি ব্যবহার করতে পারেন। উদাহরণস্বরূপ:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

যেসব ব্রাউজার পেজ লাইফসাইকেল এপিআই (Page Lifecycle API) সমর্থন করে, সেগুলোতে বিএফক্যাশ (bfcache) থেকে পেজ পুনরুদ্ধার করার সময় ( pageshow ইভেন্টের ঠিক আগে) এবং যখন কোনো ব্যবহারকারী একটি ফ্রোজেন (frozen) ব্যাকগ্রাউন্ড ট্যাবে পুনরায় প্রবেশ করে, তখন রেজিউম resume ) ইভেন্টটি ফায়ার হয়। যদি আপনি কোনো পেজ ফ্রোজেন হওয়ার পরে তার স্টেট আপডেট করতে চান (যার মধ্যে বিএফক্যাশে থাকা পেজগুলোও অন্তর্ভুক্ত), তাহলে আপনি resume ইভেন্টটি ব্যবহার করতে পারেন, কিন্তু যদি আপনি আপনার সাইটের বিএফক্যাশ হিট রেট (bfcache hit rate) পরিমাপ করতে চান, তাহলে আপনাকে pageshow ইভেন্টটি ব্যবহার করতে হবে। কিছু ক্ষেত্রে, আপনার উভয়ই ব্যবহার করার প্রয়োজন হতে পারে।

bfcache পরিমাপের সর্বোত্তম অনুশীলন সম্পর্কে বিস্তারিত জানতে, "bfcache কীভাবে অ্যানালিটিক্স এবং পারফরম্যান্স পরিমাপকে প্রভাবিত করে" দেখুন।

কখন একটি পৃষ্ঠা bfcache-এ প্রবেশ করছে তা পর্যবেক্ষণ করুন।

কোনো পৃষ্ঠা আনলোড হলে অথবা ব্রাউজার যখন সেটিকে বিএফক্যাশে (bfcache) রাখার চেষ্টা করে, তখন pagehide ইভেন্টটি ফায়ার হয়।

pagehide ইভেন্টের একটি persisted প্রপার্টিও আছে। যদি এর false , তবে আপনি নিশ্চিত থাকতে পারেন যে পেজটি bfcache-এ প্রবেশ করবে না। তবে, persisted এর মান true হলেই যে পেজটি ক্যাশ হবে, তার কোনো নিশ্চয়তা নেই। এর মানে হলো, ব্রাউজার পেজটি ক্যাশ করতে চায় , কিন্তু এমন অন্যান্য কারণও থাকতে পারে যার জন্য এটি ক্যাশ করা অসম্ভব হয়ে পড়ে।

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

একইভাবে, যদি persisted true হয়, তাহলে pagehide ইভেন্টের ঠিক পরেই freeze ইভেন্টটি ফায়ার হয়, কিন্তু এর মানে শুধু এই যে ব্রাউজার পেজটি ক্যাশ করে রাখতে চায় । পরে ব্যাখ্যা করা বিভিন্ন কারণে ব্রাউজারকে পেজটি বাতিলও করে দিতে হতে পারে।

bfcache-এর জন্য আপনার পেজগুলো অপ্টিমাইজ করুন।

সব পেজ bfcache-এ সংরক্ষিত হয় না, এবং কোনো পেজ সেখানে সংরক্ষিত হলেও তা অনির্দিষ্টকালের জন্য সেখানে থাকে না। ডেভেলপারদের জন্য এটা বোঝা অত্যন্ত জরুরি যে কোন পেজগুলো bfcache-এর জন্য যোগ্য (এবং অযোগ্য) হয়, যাতে তারা তাদের ক্যাশ-হিট রেট সর্বোচ্চ করতে পারেন।

নিম্নলিখিত বিভাগগুলিতে এমন সেরা অনুশীলনগুলি তুলে ধরা হয়েছে, যার মাধ্যমে ব্রাউজার আপনার পৃষ্ঠাগুলি ক্যাশ করার সম্ভাবনা যথাসম্ভব বাড়িয়ে তুলতে পারে।

unload ইভেন্টটি কখনই ব্যবহার করবেন না

সব ব্রাউজারে bfcache অপ্টিমাইজ করার সবচেয়ে গুরুত্বপূর্ণ উপায় হলো, কখনোই unload ইভেন্ট ব্যবহার না করা। কখনোই না!

ব্রাউজারগুলোর জন্য unload ইভেন্টটি একটি সমস্যা, কারণ এটি বিএফক্যাশের (bfcache) আগের এবং ইন্টারনেটের অনেক পেজ এই (যৌক্তিক) ধারণার ওপর ভিত্তি করে চলে যে, unload ইভেন্টটি ফায়ার হওয়ার পর পেজটির অস্তিত্ব আর থাকবে না। এটি একটি প্রতিবন্ধকতা তৈরি করে, কারণ এই পেজগুলোর অনেকগুলোই এই ধারণার ওপর ভিত্তি করে তৈরি করা হয়েছিল যে, ব্যবহারকারী যখনই অন্য কোনো পেজে চলে যাবে, তখনই unload ইভেন্টটি ফায়ার হবে, যা এখন আর সত্য নয় (এবং অনেক দিন ধরেই সত্য নয় )।

ফলে ব্রাউজারগুলো একটি উভয়সঙ্কটের সম্মুখীন হয়; তাদের এমন কিছুর মধ্যে একটি বেছে নিতে হয় যা ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে পারে—কিন্তু একই সাথে পেজটি ভেঙে যাওয়ার ঝুঁকিও তৈরি করতে পারে।

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

মোবাইলে, Chrome এবং Safari সেইসব পেজ ক্যাশ করার চেষ্টা করে যেগুলিতে একটি unload ইভেন্ট লিসেনার থাকে, কারণ এতে পেজ ভেঙে যাওয়ার ঝুঁকি কম থাকে। এর কারণ হলো, মোবাইলে unload ইভেন্টটি বরাবরই অত্যন্ত অনির্ভরযোগ্য। Firefox, unload ব্যবহারকারী পেজগুলিকে bfcache-এর জন্য অযোগ্য বলে মনে করে, তবে iOS এর ক্ষেত্রে তা হয় না। iOS-এ সব ব্রাউজারকে WebKit রেন্ডারিং ইঞ্জিন ব্যবহার করতে হয়, এবং তাই এটি Safari-এর মতোই আচরণ করে।

unload ইভেন্টের পরিবর্তে pagehide ইভেন্ট ব্যবহার করুন। unload ইভেন্ট যেখানেই ফায়ার হয়, pagehide ইভেন্টও সেখানেই ফায়ার হয় এবং কোনো পেজ বিএফক্যাশে (bfcache) রাখা হলেও এটি ফায়ার হয়।

প্রকৃতপক্ষে, লাইটহাউসের একটি no-unload-listeners অডিট রয়েছে, যা ডেভেলপারদের সতর্ক করে দেবে যদি তাদের পেজের কোনো জাভাস্ক্রিপ্ট (তৃতীয় পক্ষের লাইব্রেরির কোড সহ) একটি unload ইভেন্ট লিসেনার যোগ করে।

এর অবিশ্বস্ততা এবং bfcache-এর পারফরম্যান্সের উপর প্রভাবের কারণে, Chrome unload ইভেন্টটি বাতিল করার কথা ভাবছে।

একটি পৃষ্ঠায় আনলোড হ্যান্ডলার ব্যবহার প্রতিরোধ করতে অনুমতি নীতি ব্যবহার করুন।

যেসব সাইট unload ইভেন্ট হ্যান্ডলার ব্যবহার করে না, তারা একটি পারমিশন পলিসি ব্যবহারের মাধ্যমে নিশ্চিত করতে পারে যে এগুলি যুক্ত না হয়।

Permissions-Policy: unload=()

এটি তৃতীয় পক্ষ বা এক্সটেনশনগুলিকে আনলোড হ্যান্ডলার যোগ করে সাইটের গতি কমিয়ে দেওয়া থেকেও বিরত রাখে এবং সাইটটিকে বিএফক্যাশের (bfcache) জন্য অযোগ্য করে তোলে।

শুধুমাত্র শর্তসাপেক্ষে beforeunload লিসেনার যোগ করুন।

beforeunload ইভেন্টটি আধুনিক ব্রাউজারগুলোর bfcache-এ আপনার পেজগুলোকে অযোগ্য করে তুলবে না, কিন্তু আগে এটি করত এবং এটি এখনও নির্ভরযোগ্য নয়, তাই একান্ত প্রয়োজন না হলে এটি ব্যবহার করা থেকে বিরত থাকুন।

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

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Cache-Control: no-store এর ব্যবহার কমান।

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

যদিও bfcache কোনো HTTP ক্যাশ নয়, ঐতিহাসিকভাবে, যখন কোনো সাবরিসোর্সের পরিবর্তে সরাসরি পেজ রিসোর্সে Cache-Control: no-store সেট করা হয়, তখন ব্রাউজারগুলো পেজটিকে bfcache-এ সংরক্ষণ করে না। ফলে Cache-Control: no-store ব্যবহারকারী পেজগুলো bfcache-এর জন্য যোগ্য নাও হতে পারে। গোপনীয়তা রক্ষার কথা মাথায় রেখে Chrome-এর জন্য এই আচরণটি পরিবর্তন করার কাজ চলছে ।

যেহেতু Cache-Control: no-store একটি পেজের bfcache-এর জন্য যোগ্যতাকে সীমাবদ্ধ করে, তাই এটি শুধুমাত্র সেইসব পেজে সেট করা উচিত যেগুলিতে সংবেদনশীল তথ্য থাকে এবং যেখানে কোনো ধরনের ক্যাশিং কখনোই উপযুক্ত নয়।

যেসব পেজের জন্য সবসময় হালনাগাদ কন্টেন্ট পরিবেশন করা প্রয়োজন—এবং সেই কন্টেন্টে কোনো সংবেদনশীল তথ্য থাকে না— Cache-Control: no-cache অথবা Cache-Control: max-age=0 ব্যবহার করুন। এই নির্দেশিকাগুলো ব্রাউজারকে কন্টেন্ট পরিবেশন করার আগে তা পুনরায় যাচাই করতে নির্দেশ দেয় এবং এগুলো কোনো পেজের bfcache যোগ্যতাকে প্রভাবিত করে না।

উল্লেখ্য যে, যখন কোনো পৃষ্ঠা bfcache থেকে পুনরুদ্ধার করা হয়, তখন তা HTTP ক্যাশ থেকে নয়, বরং মেমরি থেকে পুনরুদ্ধার করা হয়। ফলে, Cache-Control: no-cache বা Cache-Control: max-age=0 এর মতো নির্দেশাবলী বিবেচনায় নেওয়া হয় না এবং ব্যবহারকারীর কাছে বিষয়বস্তু প্রদর্শিত হওয়ার আগে কোনো পুনঃযাচাইকরণ ঘটে না।

তবে, এটি সম্ভবত ব্যবহারকারীর জন্য আরও ভালো অভিজ্ঞতা দেবে, কারণ বিএফক্যাশ (bfcache) রিস্টোর তাৎক্ষণিক হয় এবং—যেহেতু পেজগুলো বিএফক্যাশে বেশিক্ষণ থাকে না—তাই কন্টেন্ট পুরোনো হয়ে যাওয়ার সম্ভাবনা কম। কিন্তু, যদি আপনার কন্টেন্ট প্রতি মিনিটে পরিবর্তিত হয়, তাহলে আপনি পরবর্তী বিভাগে বর্ণিত পদ্ধতি অনুযায়ী pageshow ইভেন্ট ব্যবহার করে যেকোনো আপডেট ফেচ (fetch) করতে পারেন।

bfcache রিস্টোর করার পর অপ্রচলিত বা সংবেদনশীল ডেটা আপডেট করুন।

যদি আপনার সাইট ব্যবহারকারীর অবস্থা—বিশেষ করে কোনো সংবেদনশীল তথ্য—সংরক্ষণ করে, তাহলে bfcache থেকে কোনো পৃষ্ঠা পুনরুদ্ধার করার পর সেই ডেটা আপডেট বা মুছে ফেলা প্রয়োজন।

উদাহরণস্বরূপ, যদি কোনো ব্যবহারকারী একটি চেকআউট পৃষ্ঠায় যান এবং তারপরে তার শপিং কার্ট আপডেট করেন, তাহলে bfcache থেকে একটি পুরোনো পৃষ্ঠা পুনরুদ্ধার করা হলে ব্যাক নেভিগেশনের ফলে সম্ভাব্যভাবে পুরোনো তথ্য প্রকাশ হয়ে যেতে পারে।

আরেকটি, আরও গুরুতর উদাহরণ হলো, যদি কোনো ব্যবহারকারী একটি পাবলিক কম্পিউটার থেকে কোনো সাইট থেকে সাইন আউট করেন এবং পরবর্তী ব্যবহারকারী ব্যাক বাটনে ক্লিক করেন। এর ফলে এমন ব্যক্তিগত তথ্য ফাঁস হয়ে যেতে পারে, যা ব্যবহারকারী লগ আউট করার সময় মুছে গেছে বলে ধরে নিয়েছিলেন।

এই ধরনের পরিস্থিতি এড়ানোর জন্য, যদি event.persisted true হয়, তাহলে pageshow ইভেন্টের পরে পেজটি সবসময় আপডেট করা ভালো।

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

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

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

রিলোড করার সুবিধা হলো এটি হিস্ট্রি সংরক্ষণ করে রাখে (যাতে সামনে নেভিগেট করা যায়), কিন্তু কিছু ক্ষেত্রে রিডাইরেক্ট করা বেশি উপযুক্ত হতে পারে।

Ads এবং bfcache পুনরুদ্ধার

প্রতিবার সামনে বা পেছনে যাওয়ার সময় নতুন করে বিজ্ঞাপন দেখানোর জন্য বিএফক্যাশ (bfcache) ব্যবহার এড়িয়ে চলার একটি প্রবণতা থাকতে পারে। তবে, এটি যেমন পারফরম্যান্সের ওপর প্রভাব ফেলে, তেমনই এই ধরনের আচরণ বিজ্ঞাপনের প্রতি ব্যবহারকারীর সম্পৃক্ততা বাড়ায় কিনা, তা নিয়েও প্রশ্ন রয়েছে। ব্যবহারকারীরা হয়তো এমন কোনো বিজ্ঞাপন দেখেছেন যেটিতে ফিরে এসে ক্লিক করতে চেয়েছিলেন, কিন্তু বিএফক্যাশ থেকে পুনরুদ্ধার না করে শুধু রিলোড করার ফলে তারা তা করতে পারেননি। কোনো কিছু অনুমান করার আগে এই পরিস্থিতিটি পরীক্ষা করা—বিশেষত একটি এ/বি টেস্টের মাধ্যমে—গুরুত্বপূর্ণ।

যেসব সাইট bfcache রিস্টোরের সময় বিজ্ঞাপন রিফ্রেশ করতে চায়, তাদের জন্য event.persisted true থাকা অবস্থায় pageshow ইভেন্টে শুধু বিজ্ঞাপনগুলো রিফ্রেশ করলে পেজের পারফরম্যান্সে কোনো প্রভাব না ফেলেই এটি করা সম্ভব হয়। আপনার বিজ্ঞাপন প্রদানকারীর সাথে বিষয়টি যাচাই করে নিন, তবে গুগল পাবলিশিং ট্যাগ ব্যবহার করে এটি কীভাবে করতে হয় তার একটি উদাহরণ এখানে দেওয়া হলো ।

window.opener উল্লেখ এড়িয়ে চলুন।

পুরানো ব্রাউজারগুলিতে, যদি rel="noopener" উল্লেখ না করে target=_blank সহ কোনো লিঙ্ক থেকে window.open() ব্যবহার করে একটি পৃষ্ঠা খোলা হতো, তাহলে যে পৃষ্ঠাটি খুলত তাতে খোলা পৃষ্ঠাটির window অবজেক্টের একটি রেফারেন্স থাকত।

নিরাপত্তাজনিত ঝুঁকি হওয়ার পাশাপাশি, যে পেজে window.opener রেফারেন্সটি নাল (null) নয়, সেটিকে নিরাপদে bfcache-এ রাখা যায় না, কারণ এর ফলে সেটিকে অ্যাক্সেস করতে চাওয়া যেকোনো পেজ অকার্যকর হয়ে যেতে পারে।

ফলস্বরূপ, window.opener রেফারেন্স তৈরি করা এড়িয়ে চলাই ভালো। যখনই সম্ভব rel="noopener" ব্যবহার করে আপনি এটি করতে পারেন (উল্লেখ্য, এটি এখন সমস্ত আধুনিক ব্রাউজারে ডিফল্ট)। যদি আপনার সাইটে একটি উইন্ডো খোলার এবং window.postMessage() এর মাধ্যমে এটিকে নিয়ন্ত্রণ করার অথবা সরাসরি window অবজেক্টকে রেফারেন্স করার প্রয়োজন হয়, তাহলে খোলা উইন্ডো বা ওপেনার কোনোটিই bfcache-এর জন্য উপযুক্ত হবে না।

ব্যবহারকারী অন্যত্র চলে যাওয়ার আগে খোলা সংযোগগুলি বন্ধ করুন।

পূর্বে যেমন উল্লেখ করা হয়েছে, যখন কোনো পেজ bfcache-এ রাখা হয়, তখন এটি সমস্ত নির্ধারিত জাভাস্ক্রিপ্ট টাস্ক থামিয়ে দেয় এবং পেজটি ক্যাশ থেকে বের করে নিলে সেগুলোকে পুনরায় চালু করে।

যদি এই নির্ধারিত জাভাস্ক্রিপ্ট টাস্কগুলো শুধুমাত্র DOM API—অথবা শুধু বর্তমান পৃষ্ঠার জন্য সীমাবদ্ধ অন্যান্য API—অ্যাক্সেস করে, তাহলে ব্যবহারকারীর কাছে পৃষ্ঠাটি অদৃশ্য থাকাকালীন এই টাস্কগুলো পজ করে রাখলে কোনো সমস্যা হবে না।

তবে, যদি এই টাস্কগুলো এমন API-এর সাথে সংযুক্ত থাকে যা একই অরিজিনের অন্যান্য পেজ থেকেও অ্যাক্সেসযোগ্য (যেমন: IndexedDB, Web Locks, WebSockets), তাহলে এটি সমস্যাজনক হতে পারে, কারণ এই টাস্কগুলো পজ করলে অন্যান্য ট্যাবের কোড চালানো বন্ধ হয়ে যেতে পারে।

ফলস্বরূপ, কিছু ব্রাউজার নিম্নলিখিত পরিস্থিতিগুলিতে কোনো পৃষ্ঠাকে bfcache-এ রাখার চেষ্টা করবে না:

• খোলা IndexedDB সংযোগ সহ পৃষ্ঠাগুলি
• যেসব পেজে `fetch()` বা `XMLHttpRequest` চলমান আছে
• খোলা WebSocket বা WebRTC সংযোগ সহ পৃষ্ঠাগুলি

আপনার পেজ যদি এই API-গুলোর কোনোটি ব্যবহার করে থাকে, তাহলে আমরা pagehide বা freeze ইভেন্টের সময় কানেকশন বন্ধ করতে এবং অবজারভারদের রিমুভ বা ডিসকানেক্ট করার জন্য দৃঢ়ভাবে সুপারিশ করছি। এর ফলে ব্রাউজার অন্য খোলা ট্যাবগুলোকে প্রভাবিত করার ঝুঁকি ছাড়াই নিরাপদে পেজটি ক্যাশ করতে পারে।

তারপর, যদি পৃষ্ঠাটি bfcache থেকে পুনরুদ্ধার করা হয়, তাহলে আপনি pageshow বা resume ইভেন্টের সময় সেই API-গুলি পুনরায় খুলতে বা সেগুলিতে পুনরায় সংযোগ করতে পারবেন।

নিম্নলিখিত উদাহরণটি দেখায় যে কীভাবে pagehide ইভেন্ট লিসেনারে একটি খোলা সংযোগ বন্ধ করার মাধ্যমে IndexedDB ব্যবহারকারী পেজগুলি bfcache-এর জন্য যোগ্য কিনা তা নিশ্চিত করা যায়:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

আপনার পেজগুলো ক্যাশেযোগ্য কিনা তা পরীক্ষা করুন।

আপনার পেজগুলো bfcache-এর জন্য অপ্টিমাইজ করা আছে কিনা তা পরীক্ষা করতে এবং সেগুলোর যোগ্যতা অর্জনে বাধা সৃষ্টিকারী যেকোনো সমস্যা শনাক্ত করতে Chrome DevTools আপনাকে সাহায্য করতে পারে।

একটি পৃষ্ঠা পরীক্ষা করতে:

1. ক্রোমে পৃষ্ঠাটিতে যান।
2. DevTools-এ, Application -> Back-forward Cache- এ যান।
3. রান টেস্ট বাটনটিতে ক্লিক করুন। এরপর ডেভটুলস পেজটি বিএফক্যাশ (bfcache) থেকে পুনরুদ্ধার করা যাবে কিনা তা নির্ধারণ করার জন্য অন্য পেজে গিয়ে আবার ফিরে আসার চেষ্টা করে।

পরীক্ষাটি সফল হলে, প্যানেলটি "ব্যাক-ফরোয়ার্ড ক্যাশে থেকে পুনরুদ্ধার করা হয়েছে" বার্তাটি প্রদর্শন করে।

যদি এটি অসফল হয়, প্যানেলটি তার কারণ নির্দেশ করে। যদি কারণটি এমন হয় যা আপনি একজন ডেভেলপার হিসেবে সমাধান করতে পারেন, তবে প্যানেলটি সেটিকে ‘কার্যকরী’ (Actionable) হিসেবে চিহ্নিত করে।

এই উদাহরণে, unload ইভেন্ট লিসেনার ব্যবহারের ফলে পেজটি বিএফক্যাশের জন্য অযোগ্য হয়ে পড়ে। আপনি unload পরিবর্তে pagehide ব্যবহার করে এটি ঠিক করতে পারেন।

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

Lighthouse 10.0-এ একটি bfcache অডিটও যোগ করা হয়েছে , যা একই ধরনের পরীক্ষা করে। আরও তথ্যের জন্য, bfcache অডিটের ডক্স দেখুন।

bfcache কীভাবে অ্যানালিটিক্স এবং পারফরম্যান্স পরিমাপকে প্রভাবিত করে

আপনি যদি আপনার সাইটের ভিজিট পরিমাপ করতে কোনো অ্যানালিটিক্স টুল ব্যবহার করেন, তাহলে আপনি হয়তো লক্ষ্য করবেন যে, ক্রোম আরও বেশি ব্যবহারকারীর জন্য বিএফক্যাশ (bfcache) চালু করার ফলে রিপোর্ট করা মোট পেজভিউয়ের সংখ্যা কমে গেছে।

প্রকৃতপক্ষে, আপনি সম্ভবত ইতিমধ্যেই bfcache ব্যবহারকারী অন্যান্য ব্রাউজারগুলো থেকে পেজভিউ কম দেখাচ্ছেন, কারণ অনেক জনপ্রিয় অ্যানালিটিক্স লাইব্রেরি bfcache রিস্টোরকে নতুন পেজভিউ হিসেবে গণনা করে না।

আপনার পেজভিউ গণনায় বিএফক্যাশ রিস্টোর অন্তর্ভুক্ত করতে, pageshow ইভেন্টের জন্য লিসেনার সেট করুন এবং persisted প্রপার্টিটি চেক করুন।

নিম্নলিখিত উদাহরণটি দেখায় কিভাবে গুগল অ্যানালিটিক্স দিয়ে এটি করতে হয়। অন্যান্য অ্যানালিটিক্স টুলগুলোও সম্ভবত একই ধরনের যুক্তি ব্যবহার করে:

// Send a pageview when the page is first loaded.
// This happens by default just by loading gtag
gtag('config', 'TAG_ID');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

আপনার bfcache হিট অনুপাত পরিমাপ করুন

আপনি bfcache ব্যবহৃত হয়েছে কিনা তাও পরিমাপ করতে চাইতে পারেন, যা bfcache ব্যবহার করছে না এমন পৃষ্ঠাগুলি শনাক্ত করতে সাহায্য করবে। পৃষ্ঠা লোডের জন্য নেভিগেশন টাইপ পরিমাপ করার মাধ্যমে এটি করা যেতে পারে:

// Send a navigation_type when the page is first loaded.
// To do this disable the default pageview so you can manually send it
// supplemented with the additional detail.
gtag('config', 'TAG_ID', { send_page_view: false });
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

back_forward নেভিগেশন এবং back_forward_cache নেভিগেশনের সংখ্যা ব্যবহার করে আপনার bfcache হিট রেশিও গণনা করুন।

এটা উপলব্ধি করা গুরুত্বপূর্ণ যে, সাইট মালিকের নিয়ন্ত্রণের বাইরে এমন বেশ কিছু পরিস্থিতি রয়েছে, যখন ব্যাক/ফরোয়ার্ড নেভিগেশন bfcache ব্যবহার করে না, যার মধ্যে রয়েছে:

• যখন ব্যবহারকারী ব্রাউজারটি বন্ধ করে আবার চালু করে
• যখন ব্যবহারকারী একটি ট্যাব নকল করে
• যখন ব্যবহারকারী একটি ট্যাব বন্ধ করে আবার খোলে

এইসব ক্ষেত্রের কয়েকটিতে কিছু ব্রাউজার মূল নেভিগেশন টাইপটি সংরক্ষণ করতে পারে এবং তাই এগুলি ব্যাক/ফরোয়ার্ড নেভিগেশন না হওয়া সত্ত্বেও back_forward টাইপের নেভিগেশন দেখাতে পারে।

ওই বর্জনগুলো ছাড়াও মেমরি সংরক্ষণের জন্য একটি নির্দিষ্ট সময় পর বিএফক্যাশ (bfcache) বাতিল করে দেওয়া হবে।

সুতরাং, ওয়েবসাইট মালিকদের সমস্ত back_forward নেভিগেশনের জন্য ১০০% বিএফক্যাশ হিট রেশিও আশা করা উচিত নয়। তবে, এই রেশিও পরিমাপ করা এমন পেজ শনাক্ত করতে সহায়ক হতে পারে, যেখানে পেজটি নিজেই ব্যাক ও ফরওয়ার্ড নেভিগেশনের একটি বড় অংশের জন্য বিএফক্যাশ ব্যবহারে বাধা দিচ্ছে।

পেজগুলো কেন bfcache ব্যবহার করে না, তার কারণগুলো জানতে Chrome টিম NotRestoredReasons API যুক্ত করেছে, যাতে ডেভেলপাররা তাদের bfcache হিট রেট উন্নত করতে পারেন। Chrome টিম CrUX-এ নেভিগেশন টাইপও যুক্ত করেছে, যার ফলে নিজে পরিমাপ না করেও bfcache নেভিগেশনের সংখ্যা দেখা সম্ভব হয়েছে।

কর্মক্ষমতা পরিমাপ

bfcache ফিল্ড থেকে সংগৃহীত পারফরম্যান্স মেট্রিকগুলোকেও নেতিবাচকভাবে প্রভাবিত করতে পারে, বিশেষ করে সেইসব মেট্রিক যা পেজ লোড হওয়ার সময় পরিমাপ করে।

যেহেতু bfcache নেভিগেশন একটি নতুন পেজ লোড শুরু করার পরিবর্তে একটি বিদ্যমান পেজ পুনরুদ্ধার করে, তাই bfcache সক্রিয় থাকলে সংগৃহীত মোট পেজ লোডের সংখ্যা কমে যাবে। তবে, গুরুত্বপূর্ণ বিষয় হলো, bfcache পুনরুদ্ধারের মাধ্যমে প্রতিস্থাপিত পেজ লোডগুলো সম্ভবত আপনার ডেটাসেটের সবচেয়ে দ্রুততম পেজ লোডগুলোর মধ্যে কয়েকটি ছিল। এর কারণ হলো, ব্যাক এবং ফরোয়ার্ড নেভিগেশনগুলো সংজ্ঞানুসারে পুনরাবৃত্তিমূলক ভিজিট, এবং পুনরাবৃত্তিমূলক পেজ লোডগুলো সাধারণত প্রথমবারের ভিজিটরদের পেজ লোডের চেয়ে দ্রুততর হয় (যেমনটি আগে উল্লেখ করা হয়েছে, HTTP ক্যাশিংয়ের কারণে)।

এর ফলে আপনার ডেটাসেটে দ্রুত পেজ লোডের সংখ্যা কমে যায়, যা সম্ভবত ডেটার বিন্যাসকে আরও ধীর করে দেবে—যদিও ব্যবহারকারীর অভিজ্ঞতায় পারফরম্যান্স সম্ভবত উন্নত হয়েছে!

এই সমস্যাটি মোকাবেলা করার কয়েকটি উপায় আছে। একটি হলো সমস্ত পেজ লোড মেট্রিককে তাদের নিজ নিজ ন্যাভিগেশন টাইপ —যেমন: navigate , reload , back_forward , বা prerender দিয়ে টীকাযুক্ত করা। এর ফলে, সামগ্রিক বিন্যাস নেতিবাচক দিকে ঝুঁকে থাকলেও, আপনি এই ন্যাভিগেশন টাইপগুলোর মধ্যে আপনার পারফরম্যান্স নিরীক্ষণ চালিয়ে যেতে পারবেন। আমরা Time to First Byte (TTFB)- এর মতো ব্যবহারকারী-কেন্দ্রিক নয় এমন পেজ লোড মেট্রিকগুলোর জন্য এই পদ্ধতিটি সুপারিশ করি।

কোর ওয়েব ভাইটালস- এর মতো ব্যবহারকারী-কেন্দ্রিক মেট্রিকগুলোর ক্ষেত্রে, এমন একটি মান রিপোর্ট করা আরও ভালো বিকল্প যা ব্যবহারকারীর অভিজ্ঞতাকে আরও নির্ভুলভাবে উপস্থাপন করে।

কোর ওয়েব ভাইটালসের উপর প্রভাব

কোর ওয়েব ভাইটালস একটি ওয়েব পেজের ব্যবহারকারীর অভিজ্ঞতাকে বিভিন্ন দিক (যেমন লোডিং স্পিড, ইন্টারঅ্যাকটিভিটি, ভিজ্যুয়াল স্ট্যাবিলিটি) জুড়ে পরিমাপ করে। যেহেতু ব্যবহারকারীরা সম্পূর্ণ পেজ লোড হওয়ার চেয়ে বিএফক্যাশ রিস্টোরকে দ্রুততর নেভিগেশন হিসেবে অনুভব করেন, তাই কোর ওয়েব ভাইটালস মেট্রিক্সে এর প্রতিফলন থাকাটা জরুরি। সর্বোপরি, বিএফক্যাশ চালু ছিল কি না, তা নিয়ে একজন ব্যবহারকারীর কোনো মাথাব্যথা নেই; তাদের কাছে শুধু এটাই গুরুত্বপূর্ণ যে নেভিগেশনটি দ্রুত ছিল!

যেসব টুল কোর ওয়েব ভাইটালস মেট্রিকস সংগ্রহ ও রিপোর্ট করে, যেমন ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্ট , সেগুলো তাদের ডেটাসেটে বিএফক্যাশ রিস্টোরকে আলাদা পেজ ভিজিট হিসেবে গণ্য করে। এবং যদিও বিএফক্যাশ রিস্টোরের পরে এই মেট্রিকসগুলো পরিমাপ করার জন্য কোনো ডেডিকেটেড ওয়েব পারফরম্যান্স এপিআই নেই, আপনি বিদ্যমান ওয়েব এপিআই ব্যবহার করে এগুলোর আনুমানিক মান বের করতে পারেন:

• লার্জেস্ট কন্টেন্টফুল পেইন্ট (LCP)- এর জন্য, pageshow ইভেন্টের টাইমস্ট্যাম্প এবং পরবর্তী পেইন্ট করা ফ্রেমের টাইমস্ট্যাম্পের মধ্যকার ডেল্টা ব্যবহার করুন, কারণ ফ্রেমের সমস্ত এলিমেন্ট একই সময়ে পেইন্ট করা হবে। বিএফক্যাশ রিস্টোরের ক্ষেত্রে, LCP এবং FCP একই হয়।
• পরবর্তী পেইন্টে ইন্টারঅ্যাকশনের (INP) জন্য, আপনার বিদ্যমান পারফরম্যান্স অবজারভারটি ব্যবহার করতে থাকুন, কিন্তু বর্তমান INP মানটি 0-তে রিসেট করুন।
• কিউমুলেটিভ লেআউট শিফট (CLS)- এর জন্য, আপনার বিদ্যমান পারফরম্যান্স অবজারভার ব্যবহার করতে থাকুন, কিন্তু বর্তমান CLS মানটি 0-তে রিসেট করুন।

bfcache প্রতিটি মেট্রিককে কীভাবে প্রভাবিত করে সে সম্পর্কে আরও বিশদ জানতে, স্বতন্ত্র Core Web Vitals মেট্রিক গাইড পৃষ্ঠাগুলি দেখুন। এই মেট্রিকগুলির bfcache সংস্করণগুলি কীভাবে প্রয়োগ করতে হয় তার একটি নির্দিষ্ট উদাহরণের জন্য, web-vitals JS লাইব্রেরিতে সেগুলি যুক্ত করা PR-টি দেখুন।

web-vitals জাভাস্ক্রিপ্ট লাইব্রেরি তার রিপোর্ট করা মেট্রিক্সে bfcache রিস্টোর সমর্থন করে ।

অতিরিক্ত সম্পদ

• ফায়ারফক্স ক্যাশিং (ফায়ারফক্সে bfcache)
• পেজ ক্যাশে (সাফারিতে bfcache)
• ব্যাক/ফরোয়ার্ড ক্যাশে: ওয়েবে প্রকাশিত আচরণ (বিভিন্ন ব্রাউজারে bfcache-এর পার্থক্য)
• বিএফক্যাশ টেস্টার (ব্রাউজারে বিভিন্ন এপিআই এবং ইভেন্ট কীভাবে বিএফক্যাশকে প্রভাবিত করে তা পরীক্ষা করুন)
• পারফরম্যান্স গেম চেঞ্জার: ব্রাউজার ব্যাক/ফরোয়ার্ড ক্যাশে (স্ম্যাশিং ম্যাগাজিনের একটি কেস স্টাডি, যা bfcache সক্রিয় করার মাধ্যমে কোর ওয়েব ভাইটালস-এর নাটকীয় উন্নতি প্রদর্শন করে)