পিছনে এবং এগিয়ে ক্যাশে

Philip Walton

Barry Pollard

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

এই পৃষ্ঠাটি সমস্ত ব্রাউজার জুড়ে bfcache এর জন্য আপনার পৃষ্ঠাগুলিকে কীভাবে অপ্টিমাইজ করতে হয় তার রূপরেখা দেয়৷

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

bfcache অনেক বছর ধরে, ডেস্কটপ এবং মোবাইল জুড়ে Firefox এবং Safari উভয় ক্ষেত্রেই সমর্থিত।

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

bfcache বেসিক

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

নিচের ভিডিওটি দেখায় ঠিক কতটা bfcache নেভিগেশনের গতি বাড়াতে পারে:

ক্রোম ব্যবহারের ডেটা দেখায় যে ডেস্কটপে 10 টির মধ্যে 1টি নেভিগেশন এবং মোবাইলে 5 টির মধ্যে 1টি হয় পিছনে বা সামনে৷ এই কারণে, bfcache প্রচুর সময় এবং ডেটা ব্যবহার বাঁচানোর সম্ভাবনা রয়েছে।

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

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

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

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

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

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

bfcache এবং iframes

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

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

bfcache এবং একক পৃষ্ঠা অ্যাপস (SPA)

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

APIs bfcache পর্যবেক্ষণ করতে

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

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

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

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

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

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

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

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

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

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.');
  }
});

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

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

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

unload পরিবর্তে pagehide ব্যবহার করুন

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

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

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

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

আপনার পৃষ্ঠার কোনো জাভাস্ক্রিপ্ট unload ব্যবহার করে কিনা তা নির্ধারণ করতে, আমরা লাইটহাউসে no-unload-listeners অডিট ব্যবহার করার পরামর্শ দিই।

unload অবমূল্যায়ন করার জন্য Chrome-এর পরিকল্পনা সম্পর্কে তথ্যের জন্য, আনলোড ইভেন্টকে অবমূল্যায়ন করা পড়ুন।

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

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

Permission-Policy: unload()

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

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

beforeunload জন্য একটি উদাহরণ ব্যবহার কেস একজন ব্যবহারকারীকে সতর্ক করে যে তাদের অসংরক্ষিত পরিবর্তনগুলি আছে যদি তারা পৃষ্ঠাটি ছেড়ে যায় তবে তারা হারাবে৷ এই ক্ষেত্রে, আমরা সুপারিশ করি আনলোড করার beforeunload শ্রোতাদের যোগ করার জন্য শুধুমাত্র যখন একজন ব্যবহারকারীর অসংরক্ষিত পরিবর্তনগুলি থাকে এবং তারপরে অসংরক্ষিত পরিবর্তনগুলি সংরক্ষিত হওয়ার সাথে সাথেই সেগুলিকে সরিয়ে দেওয়া হয়, যেমনটি নিম্নলিখিত কোডে রয়েছে:

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 ক্যাশে নয়, ব্রাউজারগুলি ঐতিহাসিকভাবে bfcache থেকে পৃষ্ঠাগুলিকে বাদ দেয় যখন Cache-Control: no-store পৃষ্ঠার রিসোর্সে সেট করা থাকে (কিন্তু কোনো সাবরিসোর্সে নয়)। ক্রোম ব্যবহারকারীর গোপনীয়তা বজায় রেখে এই আচরণ পরিবর্তন করার জন্য কাজ করছে, কিন্তু ডিফল্টরূপে, Cache-Control: no-store ব্যবহার করা পৃষ্ঠাগুলি bfcache-এর জন্য যোগ্য নয়৷

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

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

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

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

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

নিরাপত্তা ঝুঁকি ছাড়াও, একটি নন-নাল 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 থেকে পৃষ্ঠাটি পুনরুদ্ধার করা যাবে কিনা তা নির্ধারণ করতে দূরে এবং পিছনে নেভিগেট করার চেষ্টা করে।

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

যদি কারণটি এমন কিছু হয় যা আপনি একজন বিকাশকারী হিসাবে সম্বোধন করতে পারেন, প্যানেল এটিকে অ্যাকশনেবল হিসাবে চিহ্নিত করে৷

এই ছবিতে, একটি unload ইভেন্ট শ্রোতার ব্যবহার পৃষ্ঠাটিকে bfcache এর জন্য অযোগ্য করে তোলে৷ আপনি pagehide ব্যবহার করে unload থেকে স্যুইচ করে এটি ঠিক করতে পারেন:

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

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

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

কিভাবে 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 ব্যবহার করে না সেগুলি সনাক্ত করতে, পৃষ্ঠা লোডের জন্য নেভিগেশন প্রকারটি নিম্নরূপ পরিমাপ করুন:

// 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 নেভিগেশনের জন্য 100% bfcache হিট অনুপাত আশা করতে পারে না। যাইহোক, তাদের অনুপাত পরিমাপ করা পৃষ্ঠাগুলি সনাক্ত করতে সাহায্য করতে পারে যা bfcache ব্যবহার প্রতিরোধ করে।

পৃষ্ঠাগুলি কেন bfcache ব্যবহার করে না তার কারণগুলি প্রকাশ করতে সাহায্য করার জন্য Chrome টিম NotRestoredReasons API যুক্ত করেছে, যাতে বিকাশকারীরা তাদের bfcache হিট রেট উন্নত করতে পারে৷

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

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

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

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

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

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

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

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

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

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

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

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