नीति को सर्वर के बजाय संसाधन से मैप करें
हेडर बदलने से पहले प्रतिनिधि URL का इन्वेंटरी बनाइए: होम पेज, कंटेंट पेज, एप्लिकेशन शेल, CSS, JavaScript, इमेज, फ़ॉन्ट, APIs, लॉगिन, अकाउंट, चेकआउट, और डाउनलोड। प्रत्येक के लिए रिकॉर्ड करें कि प्रतिक्रिया सार्वजनिक है या व्यक्तिगत, क्या उसका URL बाइट्स बदलने पर बदलता है, और सुधार कितनी जल्दी विज़िटर्स तक पहुँचाना आवश्यक है।
उस इन्वेंटरी से एक नीति मैट्रिक्स बनाइए। एक सार्वजनिक कंटेंट‑एड्रेस्ड (content-addressed) एसेट को एक स्थिर पते पर HTML से अलग नियम की आवश्यकता होती है। Cache-Control न होने पर भी प्रतिक्रियाएँ heuristically कैश हो सकती हैं, इसलिए स्पष्ट नियम टेस्ट करना आसान होते हैं।
स्टोर की गई प्रतिक्रिया कितने समय तक पुन: उपयोग की जा सकती है; max-age सेकंड में इसे देता है।
Cache-Control शब्दों का सटीक प्रयोग करें
Cache-Control ब्राउज़र और शेयर किए गए कैशेस को बताता है कि कैसे किसी प्रतिक्रिया को स्टोर और पुन: उपयोग करना है। max-age=N फ्रेश रहते हुए पुन: उपयोग की अनुमति देता है। s-maxage=N शेयर किए गए कैश के फ्रेशनेस को सेट करता है और वहाँ max-age को ओवरराइड करता है, पर ब्राउज़र s-maxage को अनदेखा करते हैं। public किसी भी कैश को अनुमति देता है; private ब्राउज़र कैशिंग की अनुमति देता है पर शेयर किए गए कैश में स्टोरिंग रोकता है।
no-cache स्टोरेज की अनुमति देता है पर पुन: उपयोग से पहले ओरिजिन वैलिडेशन अनिवार्य करता है। no-store का अर्थ है कि कैशेस को प्रतिक्रिया स्टोर नहीं करनी चाहिए, पर यह एक पूर्ण गोपनीयता नियंत्रण नहीं है। जब एक्सपायरी के बाद स्टेल सामग्री सेवा अस्वीकार्य हो तो must-revalidate का उपयोग करें; तब अनुपलब्ध ओरिजिन 504 दे सकता है बजाय स्टेल फॉलबैक के।
यह स्टोरेज को हटा देता है बजाय केवल चेक की आवश्यकता बताने के; इसे उन प्रतिक्रियाओं के लिए आरक्षित रखें जिन्हें वाकई में स्टोर नहीं किया जाना चाहिए।
स्थिर (immutable) एसेटों को लंबी लाइफटाइम देने से पहले वर्जनिंग करें
एक वर्जन्ड एसेट URL में कंटेंट‑फिंगरप्रिंट या रिलीज़ वर्ज़न शामिल होता है, जैसे app.4f2c.js। जब एसेट बाइट्स बदलें, तो एक अलग URL प्रकाशित करें और HTML संदर्भ अपडेट करें। कैश नया संसाधन देखता है, इसलिए विज़िटर्स नया एसेट बिना हर ब्राउज़र तक इनवैलिडेशन पहुँचाए फ़ेच कर लेते हैं।
यदि किसी प्रतिनिधित्व के फ्रेशनेस लाइफटाइम के दौरान वह नहीं बदलेगा, तो Cache-Control: max-age=31536000, immutable एक व्यावहारिक पैटर्न है। immutable समर्थित क्लाइंट्स को फ्रेश रहते हुए conditional revalidate न करने के लिए बताता है। इसे या एक साल‑लंबी max-age को उसी‑URL पर म्यूटेबल फ़ाइल पर न लगाएँ। उन पूर्व फिंगरप्रिंटेड एसेट्स को बनाए रखें जबकि कैश्ड HTML अभी भी उनका संदर्भ दे सकता है।
HTML एसेट URL चुनता है, इसलिए रिलीज़ अनुक्रमण (sequencing) को संदर्भित जनरेशन को बनाए रखना होगा।
HTML को लंबी कैशिंग के बजाय वैलिडेशन के माध्यम से अद्यतित रखें
HTML आमतौर पर स्थिर, मानव‑मुखी URL रखता है और सामग्री, एसेट संदर्भ, फीचर फ्लैग, या सुरक्षा सूचनाओं के साथ बदलता है। एक conservative सार्वजनिक HTML पैटर्न है Cache-Control: no-cache के साथ ETag और Last-Modified जब आपकी प्लेटफ़ॉर्म इन्हें सही तरह से उत्पन्न कर सकता है। ब्राउज़र बॉडी को स्टोर करता है पर पुन: उपयोग से पहले conditional request करता है; यदि अपरिवर्तित है तो 304 Not Modified बिना बॉडी के लौट सकता है।
ETag किसी संसाधन वर्ज़न की पहचान करता है। एक स्टेल प्रतिक्रिया पर ब्राउज़र इसे If-None-Match में भेज सकता है; यदि यह मेल खाता है, तो सर्वर 304 लौटाता है, अन्यथा नया प्रतिनिधित्व भेजता है। RFC मार्गदर्शन संभव होने पर 200 प्रतिक्रिया पर ETag और Last-Modified दोनों होने को प्राथमिकता देता है। no-cache बैक या फॉरवर्ड नेविगेशन पर वैलिडेशन की गारंटी नहीं देता क्योंकि ब्राउज़र सेशन‑हिस्ट्री स्नैपशॉट बहाल कर सकता है।
ETag को तब बदलना चाहिए जब प्रतिनिधित्व बदलता है; विभिन्न ओरिजिन और डिप्लॉयमेंट्स पर इसका परीक्षण करें।
सार्वजनिक डिलीवरी को व्यक्तिगत और संवेदनशील प्रतिक्रियाओं से अलग रखें
एक साझी कैश, जैसे CDN, एक ही प्रतिक्रिया को कई उपयोगकर्ताओं के लिए पुन: उपयोग कर सकता है। उसे अकाउंट‑विशेष HTML या API डेटा को उपयोगकर्ताओं में साझा करने न दें। व्यक्तिगत सामग्री के लिए जो ब्राउज़र में रह सकती है, private, no-cache एक समझदारी भरा प्रारंभिक बिंदु है: यह शेयर स्टोरेज रोकता है और वैलिडेशन आवश्यक बनाता है। केवल Set-Cookie हेडर कैशिंग को नहीं रोकता।
उन प्रतिक्रियाओं के लिए जिन्हें स्टोर नहीं किया जाना चाहिए, no-store का उपयोग करें और एप्लिकेशन कोड, CDN नियम, सर्विस वर्कर, ब्राउज़र स्टोरेज, लॉग, और त्रुटि पृष्ठों की समीक्षा करें। केवल हेडर पर्याप्त नहीं हैं—यह कोई गोपनीयता, अनुपालन, या भुगतान‑सुरक्षा कार्यक्रम नहीं हैं। संवेदनशील फ्लोज़ और लागू नियमों की समीक्षा के लिए योग्य सुरक्षा, गोपनीयता, और भुगतान परीक्षकों को शामिल करें।
वार्म ब्राउज़र और CDN कैश के साथ साइन‑इन, साइन‑आउट, अकाउंट स्विचिंग, और अनुमति परिवर्तन परीक्षण करें।
कैश परिवर्तनों को एक बहु‑रिवर्सिबल रिलीज़ की तरह रोल आउट करें
अनकैश्ड और रिपीट अनुरोधों के लिए बेसलाइन हेडर्स और बॉडी व्यवहार कैप्चर करें। स्टेजिंग में, पहले वर्जन्ड एसेट्स डिप्लॉय करें, फिर उन्हीं का संदर्भ देने वाला HTML, और पुराने कैश्ड HTML को नए ओरिजिन के खिलाफ टेस्ट करें। यदि दोनों मौजूद हों तो डायरेक्ट‑ओरिजिन और CDN पाथ की जाँच करें। DevTools Network हेडर दिखाने चाहिए कि नीति और रिपीट व्यवहार इच्छित के अनुरूप हैं।
एसेट URL, हेडर नियम, और कॉन्फ़िगरेशन वर्ज़न की एक रिलीज़ मैनिफेस्ट रखें। यदि कोई रिलीज़ असंगत क्लाइंट फ़ाइलें मिलाती है, तो संगत HTML और एप्लिकेशन व्यवहार बहाल करें, पर प्रकाशित फिंगरप्रिंटेड फ़ाइल को ओवरराइट न करें। HTML को जानी‑पहचानी‑सही जनरेशन की ओर पॉइंट करें और दोनों जनरेशनों को रखें जब तक की कैश्ड HTML उन्हें अनुरोध कर सकता है। एक शेयर‑कैश purge ब्राउज़र को ताज़ा प्रतिक्रिया discard करने के लिए मजबूर नहीं कर सकता।
हेडर‑टेस्ट विफलताएँ, एसेट 404s, और वर्ज़न मिसमैच को अगले रिलीज़ चेकलिस्ट में बदलाव बनाइए।