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

Philip Walton

Barry Pollard

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

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

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

সকল প্রধান ব্রাউজারে একটি bfcache থাকে, যার মধ্যে রয়েছে ৯৬ সংস্করণের পর থেকে Chrome, Firefox এবং Safari ।

bfcache এর বেসিকস

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

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

নেভিগেশনের গতি বাড়াতে bfcache-এর এই ভিডিওটি দেখুন:

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

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

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

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

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

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

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

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

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

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

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

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

যদি কোনও এমবেডেড আইফ্রেম এমন API ব্যবহার করে যা এটিকে ব্লক করে, তাহলে মূল ফ্রেমটিকে bfcache ব্যবহার থেকেও ব্লক করা যেতে পারে। এটি এড়াতে মূল ফ্রেমে সেট করা অনুমতি নীতি বা sandbox বৈশিষ্ট্যের ব্যবহার ব্যবহার করা যেতে পারে।

bfcache এবং সিঙ্গেল পেজ অ্যাপস (SPA)

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

bfcache পর্যবেক্ষণ করার জন্য API গুলি

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

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

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

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

load ইভেন্টের ঠিক পরেই pageshow ইভেন্টটি চালু হয় যখন পৃষ্ঠাটি প্রাথমিকভাবে লোড হচ্ছে এবং যেকোনো সময় পৃষ্ঠাটি bfcache থেকে পুনরুদ্ধার করা হয়। pageshow ইভেন্টের একটি persisted প্রপার্টি থাকে, যা bfcache থেকে পৃষ্ঠাটি পুনরুদ্ধার করা হলে true এবং অন্যথায় false হয়। আপনি নিয়মিত পৃষ্ঠা লোড এবং bfcache পুনরুদ্ধারের মধ্যে পার্থক্য করতে 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.');
  }
});

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

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

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

pagehide ইভেন্টটি তখনই চালু হয় যখন কোনও পেজ আনলোড হয় অথবা ব্রাউজার যখন এটিকে bfcache-এ রাখার চেষ্টা করে।

pagehide ইভেন্টের একটি persisted propertyও আছে। যদি এটি 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.');
  }
});

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

bfcache এর জন্য আপনার পৃষ্ঠাগুলি অপ্টিমাইজ করুন

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

ব্রাউজার আপনার পৃষ্ঠাগুলি যতটা সম্ভব ক্যাশে করতে পারে তার সর্বোত্তম অনুশীলনগুলি নিম্নলিখিত বিভাগগুলিতে রূপরেখা দেওয়া হয়েছে।

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

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

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

তাই ব্রাউজারগুলি একটি দ্বিধাগ্রস্ততার সম্মুখীন হয়, তাদের এমন কিছুর মধ্যে একটি বেছে নিতে হয় যা ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে পারে - তবে পৃষ্ঠাটি ভেঙে যাওয়ার ঝুঁকিও নিতে পারে।

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

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

unload ইভেন্ট ব্যবহার করার পরিবর্তে, pagehide ইভেন্ট ব্যবহার করুন। unload ইভেন্ট যেখানেই শুরু হয়, সেইসব ক্ষেত্রেই pagehide ইভেন্টটি সক্রিয় থাকে এবং যখন কোনও পৃষ্ঠা bfcache-এ রাখা হয় তখনও এটি সক্রিয় হয়।

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

অবিশ্বস্ততার কারণে এবং bfcache-এর কর্মক্ষমতা প্রভাবিত হওয়ার কারণে, Chrome unload ইভেন্টটিকে অবমূল্যায়ন করার চেষ্টা করছে।

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

যেসব সাইট unload ইভেন্ট হ্যান্ডলার ব্যবহার করে না, তারা একটি Permissions Policy ব্যবহার করে নিশ্চিত করতে পারে যে এগুলি যোগ করা হচ্ছে না।

Permissions-Policy: unload=()

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

শুধুমাত্র beforeunload যোগ করুনশর্তসাপেক্ষে শ্রোতাদের আনলোড করুন

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

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

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 পুনরুদ্ধার তাৎক্ষণিকভাবে সম্পন্ন হয় এবং যেহেতু পৃষ্ঠাগুলি খুব বেশিক্ষণ bfcache-এ থাকে না, তাই কন্টেন্টটি পুরনো হওয়ার সম্ভাবনা কম। তবে, যদি আপনার কন্টেন্ট মিনিটে মিনিটে পরিবর্তিত হয়, তাহলে আপনি পরবর্তী বিভাগে বর্ণিত pageshow ইভেন্ট ব্যবহার করে যেকোনো আপডেট আনতে পারেন।

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();
  }
});

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

বিজ্ঞাপন এবং bfcache পুনরুদ্ধার

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

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

window.opener রেফারেন্স এড়িয়ে চলুন

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

নিরাপত্তা ঝুঁকি ছাড়াও, নন-নাল window.opener রেফারেন্স সহ একটি পৃষ্ঠা নিরাপদে bfcache-এ রাখা যাবে না, কারণ এটি অ্যাক্সেস করার চেষ্টা করা যেকোনো পৃষ্ঠাকে ভেঙে ফেলতে পারে।

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

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

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

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

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

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

• খোলা IndexedDB সংযোগ সহ পৃষ্ঠাগুলি
• যেসব পৃষ্ঠার ফেচ() বা 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());

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

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

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

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

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

যদি এটি ব্যর্থ হয়, তাহলে প্যানেলটি কারণটি নির্দেশ করে। যদি কারণটি এমন কিছু হয় যা আপনি একজন ডেভেলপার হিসেবে উল্লেখ করতে পারেন, তাহলে প্যানেলটি এটিকে Actionable হিসাবে চিহ্নিত করে।

এই উদাহরণে, একটি unload ইভেন্ট লিসেনার ব্যবহার করলে পৃষ্ঠাটি bfcache-এর জন্য অযোগ্য হয়ে যায়। আপনি unload থেকে pagehide ব্যবহার করে এটি ঠিক করতে পারেন:

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

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

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

bfcache কীভাবে বিশ্লেষণ এবং কর্মক্ষমতা পরিমাপকে প্রভাবিত করে

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

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

আপনার পেজভিউ কাউন্টে bfcache রিস্টোর অন্তর্ভুক্ত করতে, pageshow ইভেন্টের জন্য লিসেনারের সেট করুন এবং persisted সম্পত্তি পরীক্ষা করুন।

নিম্নলিখিত উদাহরণটি Google Analytics দিয়ে এটি কীভাবে করবেন তা দেখায়। অন্যান্য বিশ্লেষণ সরঞ্জামগুলি সম্ভবত একই রকম যুক্তি ব্যবহার করে:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

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.
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 হিট অনুপাত আশা করা উচিত নয়। তবে, তাদের অনুপাত পরিমাপ করা এমন পৃষ্ঠাগুলি সনাক্ত করতে কার্যকর হতে পারে যেখানে পৃষ্ঠাটি নিজেই bfcache ব্যবহারকে ব্যাক এবং ফরোয়ার্ড নেভিগেশনের উচ্চ অনুপাতের জন্য বাধা দিচ্ছে।

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

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

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

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

এর ফলে আপনার ডেটাসেটে দ্রুত পৃষ্ঠা লোড কম হবে, যা সম্ভবত বিতরণকে ধীর করে দেবে—যদিও ব্যবহারকারীর কর্মক্ষমতা সম্ভবত উন্নত হয়েছে!

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

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

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

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

যেসব টুল কোর ওয়েব ভাইটালস মেট্রিক্স সংগ্রহ করে এবং রিপোর্ট করে, যেমন Chrome ব্যবহারকারী অভিজ্ঞতা প্রতিবেদন , তারা তাদের ডেটাসেটে bfcache পুনরুদ্ধারকে পৃথক পৃষ্ঠা পরিদর্শন হিসাবে বিবেচনা করে। এবং bfcache পুনরুদ্ধারের পরে এই মেট্রিক্স পরিমাপ করার জন্য কোনও ডেডিকেটেড ওয়েব পারফরম্যান্স API না থাকলেও, আপনি বিদ্যমান ওয়েব API ব্যবহার করে তাদের মানগুলি আনুমানিক করতে পারেন:

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

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

ওয়েব-ভাইটালস জাভাস্ক্রিপ্ট লাইব্রেরি এটির রিপোর্ট করা মেট্রিক্সে bfcache পুনরুদ্ধার সমর্থন করে ।

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

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