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

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

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

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

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

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

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

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

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

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

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

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

এই উদাহরণ হেডারে, নির্দেশাবলী তিনটি কাজ করে:

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

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

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

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"
    } ]
  } ]
}

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

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

ব্রাউজার এবং CDN আপনার কন্টেন্ট ক্যাশে করে রাখে এর উপর ভিত্তি করে:

• হোস্টনাম
• পথ
• কোয়েরি স্ট্রিং
• 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 ব্যবহার করার সময়, সাধারণত আগত অনুরোধগুলি থেকে কুকিজ বাদ দেওয়া হয়। দক্ষ CDN ক্যাশে আচরণের জন্য এটি প্রয়োজনীয়। শুধুমাত্র বিশেষভাবে নামকরণ করা __session কুকি আপনার অ্যাপের এক্সিকিউশনে যাওয়ার অনুমতি রয়েছে।

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