রিসোর্স অনুযায়ী নীতি ম্যাপ করুন, সার্ভারের উপর নয়
হেডার পরিবর্তন করার আগে প্রতিনিধিত্বমূলক ইউআরএলগুলোর ইনভেন্টরি নিন: হোম পেজ, কনটেন্ট পেজ, অ্যাপ্লিকেশন শেল, CSS, JavaScript, ছবি, ফন্ট, API, লগইন, অ্যাকাউন্ট, চেকআউট এবং ডাউনলোড। প্রতিটির জন্য নথিভুক্ত করুন রেসপন্সটি পাবলিক নাকি ব্যক্তিগতকৃত, তার URL কি বদলে যায় যখন বিটগুলো বদলে যায়, এবং সঠিকতা দর্শক পর্যন্ত কত দ্রুত পৌঁছাতে হবে।
ওই ইনভেন্টরি থেকে একটি নীতি ম্যাট্রিক্স তৈরি করুন। কনটেন্ট-অ্যাড্রেসড পাবলিক অ্যাসেটের জন্য স্থির ঠিকানার HTML-এর চাইতে ভিন্ন নিয়ম প্রয়োজন। Cache-Control ছাড়া রেসপন্সগুলোও হিউরিস্টিকভাবে ক্যাশ হতে পারে, তাই স্পষ্ট নিয়মগুলো টেস্ট করা সহজ।
সংগ্রহীত রেসপন্স কতক্ষণ পুনঃব্যবহারযোগ্য থাকবে; max-age সেকেন্ডে এটি দেয়।
Cache-Control টার্মগুলো সঠিকভাবে ব্যবহার করুন
Cache-Control ব্রাউজার এবং শেয়ার্ড ক্যাশকে বলে কিভাবে একটি রেসপন্স সংরক্ষণ এবং পুনঃব্যবহার করতে হবে। max-age=N রেসপন্সকে ফ্রেশ থাকা অবস্থায় পুনরায় ব্যবহার করার অনুমতি দেয়। s-maxage=N শেয়ার্ড-ক্যাশের freshness সেট করে এবং সেখানে max-age কে ওভাররাইড করে, কিন্তু ব্রাউজার s-maxage উপেক্ষা করে। public যে কোনও ক্যাশকে অনুমতি দেয়; private ব্রাউজার ক্যাশিং অনুমোদন করে কিন্তু শেয়ার্ড-ক্যাশে সংরক্ষণ রোধ করে।
no-cache স্টোরেজকে অনুমতি দেয় কিন্তু পুনঃব্যবহারের আগে origin ভ্যালিডেশন চায়। no-store মানে ক্যাশগুলো রেসপন্সটি সংরক্ষণ করবে না, কিন্তু এটি সম্পূর্ণ প্রাইভেসি নিয়ন্ত্রণ নয়। যখন মেয়াদ উত্তীর্ণের পরে স্টেইল কনটেন্ট সার্ভ করা গ্রহণযোগ্য নয়, তখন must-revalidate ব্যবহার করুন; তখন অনুপলব্ধ origin একটি stale fallback দেওয়ার বদলে 504 দিতে পারে।
এটি স্টোরেজ সরিয়ে দেয় শুধুমাত্র চেক করাকে বাধ্য করা ছাড়াও; শুধুমাত্র এমন রেসপন্সে ব্যবহারের জন্য সংরক্ষণ করুন যেগুলো সত্যিই সংরক্ষণ করা যাবেনা।
অপরিবর্তনীয় (immutable) অ্যাসেটগুলিকে লম্বা লাইফটাইম দেওয়ার আগে ভার্সন দিন
একটি ভার্সন্ড অ্যাসেট URL-এ কনটেন্ট ফিঙ্গারপ্রিন্ট বা রিলিজ ভার্সন থাকে, যেমন app.4f2c.js। যখন অ্যাসেট বাইটস বদলে যায়, ভিন্ন URL প্রকাশ করে HTML রেফারেন্স আপডেট করুন। ক্যাশ নতুন রিসোর্স হিসেবে দেখে, তাই ভিজিটররা ইনভ্যালিডেশন ছাড়াই নতুন অ্যাসেট ফetch করবে।
যদি একটি রিপ্রেজেন্টেশন তার freshness lifetime-এর মধ্যে বদলে না হয়, তাহলে Cache-Control: max-age=31536000, immutable একটি ব্যবহারিক প্যাটার্ন। immutable সমর্থনকারী ক্লায়েন্টকে ফ্রেশ থাকা অবস্থায় কন্ডিশনালি রিভ্যালিডেশনে না যেতে বলে। mutable same-URL ফাইলের জন্য এক বছর বা immutable ব্যবহার করবেন না। cached HTML এখনও যে ফিঙ্গারপ্রিন্টকৃত অ্যাসেটগুলোকে রেফার করে, সেগুলোকে ধরে রাখুন।
HTML অ্যাসেট URL নির্বাচন করে, তাই রিলিজ সিকোয়েন্সিংয়ে রেফারেন্স করা জেনারেশন রাখতে হবে।
HTML আপ-টু-ডেট রাখতে ভ্যালিডেশন ব্যবহার করুন, দীর্ঘকালের ক্যাশিং নয়
HTML সাধারণত স্থিতিশীল, মানব-সম্মুখী URL থাকে এবং কনটেন্ট, অ্যাসেট রেফারেন্স, ফিচার ফ্ল্যাগ বা সিকিউরিটি নোটিস অনুযায়ী বদলে যায়। একটি সংরক্ষণশীল পাবলিক HTML প্যাটার্ন হচ্ছে Cache-Control: no-cache সঙ্গে ETag এবং Last-Modified—যখন আপনার প্ল্যাটফর্ম সেগুলো সঠিকভাবে তৈরি করতে পারে। ব্রাউজার বডিটি সংরক্ষণ করে কিন্তু পুনঃব্যবহারের আগে শর্তসাপেক্ষ অনুরোধ করে; অপরিবর্তিত থাকলে সার্ভার 304 Not Modified দেবে বডি ছাড়াই।
ETag একটি রিসোর্স ভার্সন শনাক্ত করে। একটি স্টেইল রেসপন্সে, ব্রাউজার এটি If-None-Match-এ পাঠাতে পারে; যদি মিল থাকে সার্ভার 304 রিটার্ন করে, নচেৎ নতুন রিপ্রেজেন্টেশন পাঠায়। RFC নির্দেশনা সম্ভব হলে 200 রেসপন্সে ETag এবং Last-Modified উভয়ই রাখার পরামর্শ দেয়। no-cache Back বা Forward নেভিগেশনে ভ্যালিডেশনের গ্যারান্টি দেয় না কারণ ব্রাউজার সেশন-হিস্টোরি স্ন্যাপশট পুনঃস্থাপন করতে পারে।
ETag অবশ্যই রিপ্রেজেন্টেশন বদলে গেলে পরিবর্তিত হতে হবে; এটা অরিজিন এবং ডেপ্লয়মেন্ট জুড়ে টেস্ট করুন।
পাবলিক ডেলিভারিকে ব্যক্তিগত ও সংবেদনশীল রেসপন্স থেকে আলাদা করুন
একটি শেয়ার্ড-ক্যাশ, যেমন CDN, একাধিক ব্যবহারকারীর জন্য একই রেসপন্স পুনরায় ব্যবহার করতে পারে। অ্যাকাউন্ট-নির্দিষ্ট HTML বা API ডেটা ব্যবহারকারীর মধ্যে পুনরায় ব্যবহার করা যাবে না। ব্রাউজারে থাকতে পারে এমন ব্যক্তিগতকৃত কনটেন্টের জন্য private, no-cache একটি যৌক্তিক সূচনাপথ: এটি শেয়ার্ড স্টোরেজ বন্ধ করে এবং ভ্যালিডেশন চাই। Set-Cookie হেডার একা ক্যাশিং বন্ধ করে না।
সংরক্ষণ করা উচিত নয় এমন রেসপন্সের জন্য no-store ব্যবহার করুন এবং অ্যাপ কোড, CDN নিয়ম, সার্ভিস ওয়ার্কার, ব্রাউজার স্টোরেজ, লগ এবং এরর পেজগুলো পর্যালোচনা করুন। শুধুমাত্র হেডার দিয়ে প্রাইভেসি, কমপ্লায়েন্স বা পেমেন্ট-সিকিউরিটি নিশ্চিত করা যায় না। সংবেদনশীল ফ্লো এবং প্রযোজ্য চাহিদার জন্য যোগ্য সিকিউরিটি, প্রাইভেসি এবং পেমেন্ট রিভিউয়ারদের মূল্যায়ন করান।
ওয়ার্ম ব্রাউজার এবং CDN ক্যাশ নিয়ে সাইন-ইন, সাইন-আউট, অ্যাকাউন্ট সুইচিং এবং পারমিশন পরিবর্তনগুলো টেস্ট করুন।
ক্যাশ পরিবর্তনগুলো রিভার্সযোগ্য রিলিজ হিসেবে রোল আউট করুন
অপেক্ষাহীন এবং রিপিট রিকোয়েস্টের জন্য বেসলাইন হেডার এবং বডি আচরণ ক্যাপচার করুন। স্টেজিং-এ প্রথমে ভার্সন্ড অ্যাসেট ডেপ্লয় করুন, তারপর যে HTML সেগুলো রেফারেন্স করে তা ডেপ্লয় করে পুরনো ক্যাশড HTML কে নতুন অরিজিনের বিরুদ্ধে টেস্ট করুন। যদি ডাইরেক্ট-অরিজিন এবং CDN পাথ দুটোই থাকে সেগুলো চেক করুন। DevTools Network হেডারগুলো পরিকল্পিত নীতি এবং রিপিট আচরণ দেখাবে কিনা যাচাই করুন।
একটি রিলিজ ম্যানিফেস্ট রাখুন যাতে অ্যাসেট URL, হেডার নিয়ম এবং কনফিগারেশন ভার্সন থাকে। যদি একটি রিলিজ অসমঞ্জস ক্লায়েন্ট ফাইল একসাথে প্রকাশ করে, তবে কম্প্যাটিবল HTML এবং অ্যাপ্লিকেশন আচরণ পুনঃস্থাপন করুন, কিন্তু একটি প্রকাশিত ফিঙ্গারপ্রিন্টকৃত ফাইল ওভাররাইট করবেন না। HTML-কে নেক-গুড জেনারেশনে পয়েন্ট করুন এবং cached HTML এখনও যেগুলো অনুরোধ করতে পারে সেগুলো ধরে রাখুন। একটি শেয়ার্ড-ক্যাশ purge প্রতিটি ব্রাউজারকে একটি ফ্রেশ রেসপন্স discard করাতে পারে না।
হেডার-টেস্ট ব্যর্থতা, অ্যাসেট 404 এবং ভার্সন মিসম্যাচগুলোকে পরবর্তী রিলিজ চেকলিস্টের পরিবর্তে রূপান্তর করুন।