Skip to content

Latest commit

 

History

History

10. browser-storage-and-caching

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 

Browser Storage

ওয়েব অ্যাপস/সাইটগুলিতে অফলাইন/Cache মেকানিজম প্রদান করার জন্য Browser Storage ব্যবহার করে:

  • local storage: localStorage অনেক ডেভেলপারদের মধ্যে ব্রাউজারে সবচেয়ে জনপ্রিয় স্টোরেজ বিকল্পগুলির মধ্যে একটি। localStorage-এ, ডেটা সেশন জুড়ে সংরক্ষণ করা হয়, সার্ভারের সাথে share করা হয় না এবং একই প্রোটোকল এবং ডোমেনের অধীনে সমস্ত web-page এর জন্য ব্যবহারযোগ্য। localStorage সীমা সর্বাধিক ~5MB। localStorage-এ সংরক্ষণ করার আগে আমাদের অবশ্যই ডেটাটিকে স্ট্রিংয়ে রূপান্তর করতে হবে। localStorage এর প্রধান তিনটি function হলো:
    1. localStorage.setItem('key', 'value')
    2. localStorage.getItem('key')
    3. localStorage.removeItem('key')
  • session storage : sessionStorage অবজেক্ট শুধুমাত্র একটি সেশনের জন্য ডেটা সঞ্চয় করে। ব্রাউজার ট্যাব বন্ধ হয়ে গেলে ডেটা মুছে ফেলা হয়। sessionStorage এর প্রধান তিনটি fucntion হলো:
    1. sessionStorage.setItem('key', 'value')
    2. sessionStorage.getItem('key')
    3. sessionStorage.removeItem('key')
  • IndexedDB: একটি ক্লায়েন্ট-সাইড, NoSQL ডাটাবেস যা ডেটা, ফাইল এবং ব্লব সংরক্ষণ করতে পারে। ব্রাউজারগুলির উপর নির্ভর করে প্রতি ডোমেইনে কমপক্ষে 1GB পাওয়া উচিত, এবং এটি অবশিষ্ট disc-space এর 60% পর্যন্ত পৌঁছাতে পারে। IndexedDB ব্যবহার করে synchronous অপারেশনগুলি asynchronous করা হয়, যাতে অ্যাপ্লিকেশনগুলি ব্লক না হয়।
  • Cookies: Cookies হলো একমাত্র স্টোরেজ যা সার্ভারের সাথে শেয়ার করা হয়। Cookies প্রতিটি HTTP request অংশ হিসাবে পাঠানো হয়. এটি আমাদের ক্লায়েন্ট এবং সার্ভারের মধ্যে একটি shared state তৈরি করতে দেয়, এবং বিভিন্ন সাব-ডোমেইনে একাধিক অ্যাপ্লিকেশনের মধ্যে shared state তৈরি করে। একটি সতর্কতা: প্রতিটি api request -এর সাথে Cookies পাঠানো হয়, অর্থাৎ একটি request -এর আকার ছোট রাখার জন্য আমাদের কুকিগুলি ছোট রাখতে হবে।
  • URL storage: URL একটি storage নয়, কিন্তু এটি shared state তৈরি করার একটি ভাল উপায়। এর অর্থ current URL এ query parameters যোগ করা যাতে current state পুনরায় তৈরি করতে ব্যবহার করা যেতে পারে।
  • Cache API: Cache API হলো service worker স্পেসিফিকেশনের একটি অংশ, এবং resource cache করার একটি দুর্দান্ত উপায়। এটি আপনাকে URL রিসোর্স (assets, webpages, HTTP API responses) cache করার অনুমতি দেয়। Cache API তৈরি করা হয়েছিল Service Worker নেটওয়ার্ক request cache করতে সক্ষম করার জন্য যাতে তারা দ্রুত response প্রদান করতে পারে, নেটওয়ার্কের speed বা availability নির্বিশেষে। যাইহোক, Cache API একটি সাধারণ স্টোরেজ mechanism হিসাবেও ব্যবহার করা যেতে পারে।

Browser Caching

Caching হলো ওয়েব ব্রাউজিংয়ের একটি বৈশিষ্ট্য যা সাম্প্রতিক ওয়েব page গুলিকে ওয়েব ব্রাউজারে অস্থায়ীভাবে সংরক্ষণ করার অনুমতি দেয়। এই বৈশিষ্ট্যটি গুরুত্বপূর্ণ, কারণ এটি পৃষ্ঠা লোডের সময়কে উন্নত করে এবং ব্রাউজিং খরচ কমায়৷ এটি একটি resourceful কৌশল যা ডেভেলপাররা ওয়েব ব্রাউজিং অভিজ্ঞতা উন্নত করতে ব্যবহার করতে পারেন। ওয়েবসাইটগুলিকে আরও দ্রুত লোড করার জন্য ওয়েব ব্রাউজারগুলি HTML ফাইল, Javascript এবং Image গুলি cache করে। ওয়েব সার্ভার ওয়েবসাইট থেকে তথ্য সংগ্রহ করে এবং ওয়েব ব্রাউজারে পাঠায়। ব্যবহারকারী প্রথমবার ভিজিটর কিনা বা সাইটটি আগে ব্যবহার করেছেন তার উপর নির্ভর করে Caching করা হয়। Caching কীভাবে কাজ করে তা বোঝার জন্য আসুন এই দুটি ক্ষেত্রে দেখি:

Case 1: A first-time user

আপনি যখন প্রথমবার কোনো ওয়েবসাইট ভিজিট করেন, তখন ওয়েব ব্রাউজার ওয়েব সার্ভার থেকে ডেটা (HTML, CSS, JS) সংগ্রহ করবে। এর কারণ হলো ওয়েব রিসোর্সগুলি এখনও Cache সংরক্ষণ করা হয়নি। ওয়েব ব্রাউজার তারপর ওয়েবসাইটটিতে পরবর্তী পরিদর্শনে user experience উন্নত করতে একটি Cache এ ওয়েব resource গুলি সংরক্ষণ করবে।

Case 2: The user used the website before

যদি কোনো ব্যবহারকারী একই কম্পিউটার ডিভাইস ব্যবহার করে দ্বিতীয়বার কোনো ওয়েবসাইট পরিদর্শন করেন, ওয়েবসাইটটি প্রথম দর্শনের চেয়ে দ্রুত লোড হবে। কারণ ওয়েব ব্রাউজার Cache থেকে images, CSS এবং Javascript এর মতো স্ট্যাটিক ওয়েব রিসোর্স পুনরুদ্ধার করবে।

HTTP response headers সাধারণত Caching এর জন্য ব্যবহৃত হয়. একটি ওয়েবসাইটের মালিকের cache policy এর উপর নিয়ন্ত্রণ থাকে। এই নিয়ন্ত্রণ HTTP Cache হেডার ব্যবহার করে ব্যবহার করা হয়। এই headers মেয়াদ শেষ হওয়ার আগে ওয়েব resource কে Cache করা যেতে পারে এমন সর্বাধিক সময় নির্ধারণ করতে ব্যবহৃত হয়। নিম্নলিখিত HTTP response headers সাধারণত Cache করার জন্য ব্যবহৃত হয়:

ETag:

এটি 'Entity tag' শব্দটির সংক্ষিপ্ত রূপ। এটি একটি Cache validation টোকেন হিসাবে কাজ করে। ক্যাশ করা ফাইলের মেয়াদ শেষ হলে এটি ব্যবহার করা হয়। ওয়েব ব্রাউজারটি তার request এ ETag ব্যবহার করে Cache এ বিদ্যমান একটি পুরানো কপি আছে কিনা তা নিশ্চিত করতে ব্যবহৃত হয়।

Cache-Control:

এই header এ বিভিন্ন parameters রয়েছে যা validation, cache behavior এবং expiration নিয়ন্ত্রণ করে. এই header এর কিছু directives অন্তর্ভুক্ত:

  • no-cache: এই directive টি ওয়েব সার্ভারের content এর সাথে সামঞ্জস্যপূর্ণ কিনা তা পরীক্ষা করতে ব্রাউজারকে Cache এ থাকা content যাচাই করার নির্দেশ দেয়। যদি content টি fresh হয়, তাহলে ব্রাউজার Cache থেকে এটি আনতে পারে।
  • public: এর মানে হলো যে ব্রাউজার বা কোনো মধ্যস্থতাকারী পক্ষ (যেমন CDN বা proxies) ওয়েব রিসোর্স Cache করতে পারে।
  • private: এর মানে হলো যে শুধুমাত্র ব্রাউজারই ওয়েব রিসোর্স Cache করতে পারে।
  • no-store: এই নির্দেশিকা ব্রাউজারকে Cache না করার নির্দেশ দেয়।
  • Expires: এই header টি কখন Cache এ সংরক্ষিত সম্পদের মেয়াদ শেষ হবে তা define করে। মেয়াদ শেষ হওয়ার সময় পৌঁছে গেলে, ব্রাউজার কন্টেন্টটিকে পুরানো বিবেচনা করবে। যেমন, Expires: Mon, 14 June 2021 10:30:00 GMT.
  • Last modified: এই header টি কখন web content পরিবর্তন করা হয়েছিল সেই সংক্রান্ত তথ্য প্রদান করে। এই paremeter টি মূল content পরিবর্তনের তারিখ এবং সময় অন্তর্ভুক্ত করে। যেমন, Last Modified: Tue, 11 February 2021 10:30:00 GMT.