ক্যাশে আচরণ পরিচালনা করুন

আপনার সাইটকে যথাসম্ভব দ্রুত করার জন্য Firebase Hosting একটি শক্তিশালী গ্লোবাল সিডিএন ব্যবহার করে।

অনুরোধ করা যেকোনো স্ট্যাটিক কন্টেন্ট স্বয়ংক্রিয়ভাবে CDN-এ ক্যাশ করা হয় । আপনি যদি আপনার সাইটের কন্টেন্ট পুনরায় স্থাপন করেন, তাহলে Firebase Hosting পরবর্তী অনুরোধ পর্যন্ত CDN জুড়ে আপনার সমস্ত ক্যাশ করা কন্টেন্ট স্বয়ংক্রিয়ভাবে মুছে ফেলে।

তবে, যেহেতু Cloud Functions এবং Cloud Run পরিষেবাগুলো ডাইনামিকভাবে কন্টেন্ট তৈরি করে, তাই ব্যবহারকারীর ইনপুট বা তার পরিচয়ের মতো বিষয়ের ওপর ভিত্তি করে একটি নির্দিষ্ট URL-এর কন্টেন্ট পরিবর্তিত হতে পারে। এই বিষয়টি বিবেচনায় রেখে, ব্যাকএন্ড কোড দ্বারা পরিচালিত রিকোয়েস্টগুলো ডিফল্টভাবে CDN-এ ক্যাশ করা হয় না ।

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

একইভাবে, আপনি ক্যাশিং আচরণ কনফিগার করে ফাংশন এক্সিকিউশনের খরচ কমাতে পারেন, কারণ কন্টেন্টটি কোনো ট্রিগারড ফাংশনের পরিবর্তে সিডিএন (CDN) থেকে পরিবেশন করা হয়। ফাংশন এক্সিকিউশন এবং সার্ভিস অপ্টিমাইজ করার বিষয়ে আরও জানতে Cloud Functions এবং Cloud Run ডকুমেন্টেশন পড়ুন।

এর ব্যতিক্রম হলো সেইসব অনুরোধ যেগুলো 404 ত্রুটি ফেরত দেয়। CDN আপনার পরিষেবার একটি অস্তিত্বহীন URL-এর জন্য আসা 404 প্রতিক্রিয়া ১০ মিনিটের জন্য ক্যাশ করে রাখে, যাতে সেই URL-এর জন্য পরবর্তী অনুরোধগুলো CDN থেকেই পরিবেশিত হয়। আপনি যদি আপনার পরিষেবা এমনভাবে পরিবর্তন করেন যাতে এই URL-এ এখন কন্টেন্ট বিদ্যমান থাকে, তাহলে CDN ক্যাশ করা যেকোনো 404 প্রতিক্রিয়া সর্বোচ্চ ১০ মিনিট পর্যন্ত পরিবেশন করতে থাকে এবং তারপর সেই URL থেকে স্বাভাবিকভাবে কন্টেন্ট পরিবেশন করে।

যদি কোনো 404 রেসপন্সে আপনার Cloud Functions বা Cloud Run সার্ভিস দ্বারা সেট করা ক্যাশিং হেডার আগে থেকেই থাকে, তাহলে সেগুলি ডিফল্ট ১০ মিনিটের সময়কে ওভাররাইড করে এবং CDN-এর ক্যাশিং আচরণ সম্পূর্ণরূপে নির্ধারণ করে।

গুগলের ওয়েব ডেভেলপার ডকুমেন্টেশনে ক্যাশিং আচরণ সম্পর্কে আরও জানুন।

ক্যাশে-নিয়ন্ত্রণ সেট করুন

ডাইনামিক কন্টেন্টের ক্যাশে ম্যানেজ করার জন্য ব্যবহৃত প্রধান টুলটি হলো Cache-Control হেডার। এই হেডারটি কনফিগার করার মাধ্যমে, আপনি ব্রাউজার এবং CDN উভয়কেই জানাতে পারেন যে আপনার কন্টেন্ট কতক্ষণ ক্যাশে রাখা যাবে। আপনার ফাংশনে, আপনি Cache-Control এইভাবে সেট করবেন:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

এই উদাহরণ হেডারে, ডিরেক্টিভগুলো তিনটি কাজ করে:

• public — প্রতিক্রিয়াটিকে public হিসেবে চিহ্নিত করে। এর মানে হলো, ব্রাউজার এবং মধ্যবর্তী ক্যাশে ( Firebase Hosting এর সিডিএন সহ) উভয়ই কন্টেন্টটি ক্যাশে করতে পারে।

• max-age — এটি নির্ধারণ করে যে, একটি রেসপন্স কত সেকেন্ড পুরোনো হওয়ার পর সেটিকে অরিজিন সার্ভারের সাথে পুনরায় যাচাই করা হবে। এটি ব্রাউজারের ক্ষেত্রে প্রযোজ্য; যদি কোনো s-maxage হেডার না থাকে, তবে এটি অন্যান্য সমস্ত ক্যাশের (CDN সহ) ক্ষেত্রেও প্রযোজ্য হয়।

• s-maxage — শেয়ার্ড ক্যাশের (যেমন সিডিএন) জন্য max-age ডিরেক্টিভকে ওভাররাইড করে। যখন সিডিএন s-maxage সেকেন্ডের চেয়ে পুরোনো কোনো রেসপন্স খুঁজে পায়, তখন সিডিএন অরিজিন সার্ভারের সাথে সেটিকে পুনরায় যাচাই করে। উদাহরণ হেডারে, ব্রাউজারগুলো রেসপন্সটি ৫ মিনিটের জন্য ক্যাশ করে রাখতে পারে, কিন্তু সিডিএন এবং অন্য যেকোনো মধ্যবর্তী ক্যাশ এটিকে ১০ মিনিটের জন্য ক্যাশ করে রাখতে পারে।

max-age এবং s-maxage ক্ষেত্রে, এগুলোর মান এমন দীর্ঘতম সময়ে সেট করুন, যে সময় পর্যন্ত ব্যবহারকারীরা পুরোনো কন্টেন্ট পেলে আপনার কোনো অসুবিধা হবে না। যদি কোনো পেজ প্রতি কয়েক সেকেন্ডে পরিবর্তিত হয়, তবে একটি ছোট সময়সীমা ব্যবহার করুন। তবে, অন্যান্য ধরনের কন্টেন্ট কয়েক ঘন্টা, দিন বা এমনকি মাস ধরেও নিরাপদে ক্যাশ করে রাখা যেতে পারে।

আপনি যদি ক্যাশিং সম্পূর্ণরূপে বন্ধ করতে চান (উদাহরণস্বরূপ, স্ট্যাটিক কন্টেন্টের সর্বদা সর্বশেষ সংস্করণ পরিবেশন করতে), তাহলে আপনি firebase.json headers সেটিং ব্যবহার করে এটি কনফিগার করতে পারেন:

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

আপনি মোজিলা ডেভেলপার নেটওয়ার্ক এবং গুগলের ওয়েব ডেভেলপার ডকুমেন্টেশন থেকে Cache-Control হেডার সম্পর্কে আরও জানতে পারবেন।

ক্যাশ করা কন্টেন্ট কখন পরিবেশন করা হয়?

ব্রাউজার এবং সিডিএন নিম্নলিখিত বিষয়ের উপর ভিত্তি করে আপনার কন্টেন্ট ক্যাশ করে:

• হোস্টনেম
• পথ
• কোয়েরি স্ট্রিং
• Vary হেডারে নির্দিষ্ট করা রিকোয়েস্ট হেডারগুলোর বিষয়বস্তু

শিরোনাম পরিবর্তন করুন

Vary হেডারটি নির্ধারণ করে যে একটি উপযুক্ত প্রতিক্রিয়া প্রদানের জন্য কোন অনুরোধ হেডারগুলি ব্যবহার করা উচিত (ক্যাশে করা বিষয়বস্তু বৈধ কিনা, অথবা বিষয়বস্তুটি মূল সার্ভারের সাথে পুনরায় যাচাই করা উচিত কিনা)।

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

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

এক্ষেত্রে, Vary হেডারের মান হলো:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

এই সেটিংসের মাধ্যমে, ভিন্ন X-My-Custom-Header হেডারযুক্ত দুটি অভিন্ন অনুরোধ আলাদাভাবে ক্যাশ করা হয়। উল্লেখ্য যে, ডাইনামিক কন্টেন্টের জন্য অনুরোধ করা হলে Hosting ডিফল্টরূপে Vary হেডারে Cookie এবং Authorization যোগ করে। এটি নিশ্চিত করে যে আপনার ব্যবহৃত যেকোনো সেশন বা কুকি অথরাইজেশন হেডার ক্যাশ কী-এর অংশ হয়ে যায়, যা কন্টেন্টের আকস্মিক ফাঁস হওয়া প্রতিরোধ করে।

আরও লক্ষ্য করুন:

• শুধুমাত্র GET এবং HEAD রিকোয়েস্টই ক্যাশ করা যায়। অন্যান্য মেথড ব্যবহার করে করা HTTPS রিকোয়েস্ট কখনোই ক্যাশ করা হয় না।

• Vary হেডারে সেটিংস যোগ করার সময় সতর্ক থাকুন। আপনি যত বেশি সেটিংস যোগ করবেন, CDN-এর পক্ষে ক্যাশ করা কন্টেন্ট পরিবেশন করার সম্ভাবনা তত কমে যাবে। এও মনে রাখবেন যে, Vary রিকোয়েস্ট হেডারের উপর ভিত্তি করে কাজ করে, রেসপন্স হেডারের উপর নয়।

কুকি ব্যবহার করে

Cloud Functions বা Cloud Run এর সাথে Firebase Hosting ব্যবহার করার সময়, আগত অনুরোধগুলি থেকে সাধারণত কুকিগুলি মুছে ফেলা হয়। সিডিএন ক্যাশের কার্যকর আচরণের জন্য এটি প্রয়োজনীয়। শুধুমাত্র বিশেষ নামের __session কুকিটি আপনার অ্যাপের নির্বাহের জন্য পাস করার অনুমতি পায়।

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