फ़्रंटएंड इंटरव्यू: ब्राउज़र HTTP कैशिंग कैसे काम करती है?

समस्या और यह कब लागू होती है

एक वेब एप्लिकेशन में चार प्रकार के GET रिस्पॉन्स होते हैं:

• /index.html का एक स्थिर URL होता है, यह प्रत्येक डिप्लॉयमेंट के साथ बदलता है, और वर्तमान स्टैटिक एसेट्स को संदर्भित करता है।
• /assets/app.8f3c.js के फ़ाइल नाम में एक कंटेंट हैश होता है, इसलिए कंटेंट बदलने पर URL भी बदल जाता है।
• /api/catalog एक सार्वजनिक उत्पाद कैटलॉग है। सर्वर Accept-Language से एक रिप्रजेंटेशन चुनता है, और उत्पाद लगभग 60 सेकंड के पुरानेपन (staleness) की अनुमति देता है।
• /api/cart प्रमाणित उपयोगकर्ता के लिए वैयक्तिकृत (personalized) है और इसे CDN या किसी अन्य उपयोगकर्ता द्वारा पुन: उपयोग नहीं किया जाना चाहिए।

एक रिलीज़ के बाद, कुछ उपयोगकर्ताओं के पास पुराना HTML बना रहता है और वे एक पुरानी JavaScript फ़ाइल का अनुरोध करते हैं जिसे डिप्लॉयमेंट पहले ही हटा चुका है। कैटलॉग कभी-कभी गलत भाषा में दिखाई देता है। टीम no-cache को "स्टोर न करें" भी मानती है, इसलिए उसके प्रस्तावित समाधान अभीष्ट व्यवहार का वर्णन नहीं करते हैं। बताएं कि एक प्राइवेट ब्राउज़र कैश, एक शेयर्ड CDN कैश, फ़्रेशनेस, पुनर्वैधीकरण और कैश कीज़ कैसे इंटरैक्ट करते हैं। फिर चारों रिस्पॉन्स के लिए रिस्पॉन्स हेडर, डिप्लॉयमेंट क्रम और सत्यापन विधि डिज़ाइन करें।

60-सेकंड का मान इंटरव्यू का एक अनुमान है, किसी स्रोत से लिया गया प्रोडक्शन माप नहीं। बेस स्कोप HTTP कैश को कवर करता है। सर्विस वर्कर कैश, एप्लिकेशन मेमोरी कैश और फ़्रेमवर्क डेटा कैश फ़ॉलो-अप में आते हैं। यह एक फ़्रंटएंड, फ़ुल-स्टैक, या वेब-परफ़ॉर्मेंस का प्रश्न है जिसका मुख्य कौशल ब्राउज़र और HTTP प्लेटफ़ॉर्म व्यवहार के बारे में तर्क करना है, इसलिए इसकी श्रेणी frontend है।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

पहला संकेत यह है कि क्या उम्मीदवार चार प्रश्नों से नीति प्राप्त करता है: क्या रिस्पॉन्स को स्टोर किया जा सकता है, कौन इसका पुन: उपयोग कर सकता है, यह कब तक ताज़ा है, और इसके बासी (stale) होने के बाद क्या होता है? Cache-Control निर्देशों को रटने से अक्सर स्टोरेज और सीधे पुन: उपयोग में भ्रम हो जाता है। एक मजबूत उत्तर हेडर लिखने से पहले डेटा सीमा को परिभाषित करता है।

दूसरा संकेत no-cache और no-store के बीच का सटीक अंतर है। no-cache स्टोरेज की अनुमति देता है लेकिन प्रत्येक पुन: उपयोग से पहले ओरिजिन के साथ सत्यापन की आवश्यकता होती है। no-store कैश को रिस्पॉन्स स्टोर न करने के लिए कहता है। हर डायनेमिक रिस्पॉन्स पर no-store लागू करने से सशर्त-अनुरोध (conditional-request) के लाभ और कुछ ब्राउज़र क्षमताएं समाप्त हो जाती हैं; यह वहीं लागू होना चाहिए जहां आवश्यकता वास्तव में HTTP-कैश स्टोरेज को प्रतिबंधित करती है।

तीसरा संकेत एक सही फ़्रेशनेस और वैलिडेशन मॉडल है। एक ताज़ा रिस्पॉन्स को आमतौर पर अपस्ट्रीम सर्वर से संपर्क किए बिना पुन: उपयोग किया जा सकता है। जब यह बासी हो जाता है या सत्यापन की आवश्यकता होती है, तो क्लाइंट If-None-Match या If-Modified-Since भेज सकता है। यदि रिप्रजेंटेशन नहीं बदला है, तो सर्वर 304 Not Modified लौटाता है; कैश मेटाडेटा को अपडेट करता है और अपनी संग्रहीत बॉडी का पुन: उपयोग करता है।

अंत में, इंटरव्यूअर डिप्लॉयमेंट और कैश-की से जुड़े तर्कों की तलाश करता है। सही स्टैटिक-एसेट हेडर उस रिलीज़ प्रक्रिया को ठीक नहीं कर सकते जिसमें पुराना HTML हटाई गई फ़ाइलों को इंगित करता है। Vary: Accept-Language को छोड़ने से एक शेयर्ड कैश एक ही URL के लिए अंग्रेज़ी अनुरोध पर चीनी भाषा का रिप्रजेंटेशन भी उपयोग कर सकता है। एक मजबूत उत्तर हेडर, एसेट लाइफ़टाइम, रिप्रजेंटेशन वेरिएंट और पुनरुत्पादनीय परीक्षणों को कवर करता है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्या सभी चार रिस्पॉन्स CDN से होकर गुजरते हैं? s-maxage शेयर्ड कैश को नियंत्रित करता है और प्राइवेट-ब्राउज़र फ़्रेशनेस सेट नहीं करता है। CDN के बिना, पब्लिक API नीति सरल हो सकती है।
• क्या कैटलॉग की भाषा URL से आती है या रिक्वेस्ट हेडर से? /api/catalog?locale=zh-CN पहले से ही कैश की के हिस्से के रूप में एक अलग URI का उपयोग करता है। एक एकल URL जिसका रिप्रजेंटेशन Accept-Language पर निर्भर करता है, उसे उपयुक्त Vary फ़ील्ड की आवश्यकता होती है।
• क्या ब्राउज़र कार्ट रिस्पॉन्स को स्टोर कर सकता है और बाद में इसे वैलिडेट कर सकता है? यदि किसी एकल उपयोगकर्ता का प्राइवेट कैश इसे स्टोर कर सकता है, तो private, no-cache का उपयोग करें। यदि सुरक्षा या उत्पाद नीति किसी भी HTTP-कैश स्टोरेज को प्रतिबंधित करती है, तो no-store का उपयोग करें।
• पुराने हैश किए गए एसेट्स कब तक उपलब्ध रह सकते हैं? तत्काल विलोपन पुराने टैब, इतिहास नेविगेशन, कंपित (staggered) डिप्लॉयमेंट और रोलबैक संस्करणों को तोड़ देता है। प्रतिधारण (retention) को उस अवधि को कवर करना चाहिए जिसमें एक पुराना एंट्री पॉइंट रोलबैक विंडो के साथ-साथ सुलभ रहता है।
• कैटलॉग डेटा कितना बासी हो सकता है? "अधिकतम 60 सेकंड" को पुनर्वैधीकरण या त्रुटियों के दौरान अतिरिक्त बासी उपयोग से सामान्य फ़्रेशनेस में अंतर करना चाहिए। यदि पुराना कंटेंट कभी भी स्वीकार्य नहीं है, तो stale-while-revalidate और stale-if-error पुन: उपयोग को बढ़ा नहीं सकते हैं।
• क्या सर्विस वर्कर इंस्टॉल है? एक सर्विस वर्कर अनुरोध को इंटरसेप्ट कर सकता है और सामान्य HTTP कैश के भाग लेने से पहले एक कैश स्टोरेज प्रविष्टि लौटा सकता है। इसे एक अलग परत के रूप में जाँचना आवश्यक है।

30-सेकंड उत्तर फ़्रेमवर्क

"प्रत्येक रिस्पॉन्स के लिए मैं पहले यह तय करता हूँ कि क्या इसे स्टोर किया जा सकता है, कौन इसका पुन: उपयोग कर सकता है, यह कब तक ताज़ा है, और उसके बाद इसे कैसे वैलिडेट किया जाता है। एक कंटेंट-हैश की गई JavaScript एसेट को एक साल का max-age और immutable मिलता है, इस गारंटी के साथ कि एक ही URL पर बाइट्स कभी नहीं बदलते हैं। HTML को no-cache और एक ETag मिलता है, ताकि ब्राउज़र इसे स्टोर कर सके लेकिन सामान्य पुन: उपयोग पर इसे वैलिडेट करे। सार्वजनिक कैटलॉग CDN को s-maxage=60 दे सकता है, एक ETag जोड़ सकता है, और जब एक ही URL कई भाषाओं में सेवा प्रदान करता है तो Vary: Accept-Language का उपयोग कर सकता है। कार्ट कम से कम private है; यदि ब्राउज़र स्टोरेज की अनुमति है तो private, no-cache का उपयोग करें, और केवल तभी no-store का उपयोग करें जब स्टोरेज स्वयं प्रतिबंधित हो। HTML से पहले नए एसेट्स डिप्लॉय करें और पुरानी हैश की गई फ़ाइलों को बनाए रखें। फिर एक अनकैश्ड 200, एक फ्रेश हिट, 304 पुनर्वैधीकरण, भाषा वेरिएंट और पुराने HTML के रीप्ले का परीक्षण करें।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: स्टोरेज, पुन: उपयोग, फ़्रेशनेस और पुनर्वैधीकरण को अलग-अलग मॉडल करें

HTTP कैशिंग कोई एकल स्विच नहीं है। एक अनुरोध पथ के लिए कम से कम चार निर्णयों की आवश्यकता होती है:

1. स्टोरेज: no-store स्टोरेज को रोकता है। अन्य रिस्पॉन्स विधि, स्थिति, प्राधिकरण और स्पष्ट कैशिंग नियमों के अधीन हैं।
2. पुन: उपयोग का दायरा: एक ब्राउज़र एक प्राइवेट कैश है जो सामान्यतः एक उपयोगकर्ता की सेवा करता है। CDN और प्रॉक्सी शेयर्ड कैश हैं। private शेयर्ड-कैश पुन: उपयोग को रोकता है, जबकि public स्पष्ट रूप से इसकी अनुमति दे सकता है।
3. फ़्रेशनेस: max-age=N आम तौर पर परिभाषित करता है कि प्राइवेट और शेयर्ड कैश कब तक किसी रिस्पॉन्स का सीधे पुन: उपयोग कर सकते हैं। एक शेयर्ड कैश में, s-maxage=N, max-age को ओवरराइड करता है। वर्तमान रिस्पॉन्स आयु Date और Age जैसे मेटाडेटा को भी दर्शाती है।
4. बासी होने के बाद का व्यवहार: एक कैश एक वैलिडेटर का उपयोग करके सशर्त अनुरोध भेज सकता है। एक अपरिवर्तित रिप्रजेंटेशन 304 उत्पन्न करता है और संग्रहीत बॉडी का पुन: उपयोग करता है; एक परिवर्तित रिप्रजेंटेशन नई सामग्री के साथ 200 उत्पन्न करता है।

इसलिए "कैश हिट" दो अलग-अलग लागतों का वर्णन करता है। एक ताज़ा हिट के लिए किसी अपस्ट्रीम पुष्टि की आवश्यकता नहीं होती है। एक पुनर्वैधीकृत (revalidated) हिट में अभी भी एक नेटवर्क राउंड ट्रिप और सत्यापन कार्य होता है, भले ही यह पूर्ण रिस्पॉन्स बॉडी को स्थानांतरित करने से बचता हो। एक साक्षात्कार उत्तर में यह स्पष्ट होना चाहिए कि इसका क्या अर्थ है।

चरण 2: कंटेंट-हैश किए गए स्टैटिक एसेट्स को एक लंबा फ़्रेशनेस लाइफ़टाइम दें

यदि बिल्ड यह गारंटी देता है कि बदली हुई सामग्री को एक नया URL मिलता है, तो एक स्टैटिक एसेट लौटा सकता है:

Cache-Control: public, max-age=31536000, immutable

31536000 सेकंड एक वर्ष है। immutable कहता है कि संसाधन तब तक नहीं बदलेगा जब तक वह ताज़ा है और कुछ पुनः लोड पथों में व्यर्थ सत्यापन से बच सकता है। महत्वपूर्ण बात कोई विशेष एक वर्ष की संख्या नहीं है। यह अपरिवर्तनीयताओं (invariants) की जोड़ी है:

• किसी दिए गए हैश किए गए URL पर बाइट्स कभी नहीं बदलते हैं।
• एक नया संस्करण नए HTML द्वारा संदर्भित एक नए URL का उपयोग करता है।

उसी लंबे समय तक चलने वाले URL पर किसी फ़ाइल को अधिलेखित (overwrite) करने से क्लाइंट्स के पास पुरानी सामग्री रह जाती है। पुरानी हैश की गई फ़ाइलों को हटाने से पुराने टैब, ब्राउज़र इतिहास, कंपित एज नोड्स और रोलबैक रिलीज़ भी टूट जाते हैं जो अभी भी उनका अनुरोध कर सकते हैं। एक मजबूत रिलीज़ पहले नए एसेट्स अपलोड करती है, सत्यापित करती है कि वे सुलभ हैं, उसके बाद HTML प्रकाशित करती है, और पुराने हैश किए गए एसेट्स को तब तक बनाए रखती है जब तक कि पुराने प्रवेश बिंदु और रोलबैक संस्करण अब सुलभ न हों।

चरण 3: हर सामान्य पुन: उपयोग पर स्थिर HTML URL को पुनर्वैधीकृत करें

एंट्री HTML स्वाभाविक रूप से प्रत्येक रिप्रजेंटेशन के साथ अपना URL नहीं बदल सकता है, इसलिए यह लौटा सकता है:

Cache-Control: no-cache
ETag: "index-v184"

ब्राउज़र दस्तावेज़ को स्टोर कर सकता है, लेकिन सामान्य पुन: उपयोग के लिए सत्यापन की आवश्यकता होती है। बाद के अनुरोध में शामिल है:

If-None-Match: "index-v184"

यदि रिप्रजेंटेशन अपरिवर्तित है तो सर्वर 304 लौटाता है, या रिलीज़ के बाद नए HTML और नए ETag के साथ 200 लौटाता है। एक ETag किसी रिप्रजेंटेशन के संस्करण की पहचान करता है। यह कंटेंट हैश होना ज़रूरी नहीं है, लेकिन रिप्रजेंटेशन बदलने पर इसे बदलना चाहिए। रिस्पॉन्स Last-Modified भी ले जा सकता है। यदि किसी अनुरोध में If-None-Match और If-Modified-Since दोनों शामिल हैं, तो अधिक सटीक ETag स्थिति HTTP सिमेंटिक्स के तहत प्राथमिकता लेती है।

no-cache का अर्थ "सहेजें नहीं" नहीं है। no-store का उपयोग केवल तभी करें जब उत्पाद को 304 पुनर्वैधीकरण के नुकसान को स्वीकार करते हुए, HTML को HTTP कैश में बिल्कुल भी प्रवेश न करने की आवश्यकता हो। ब्राउज़र बैक/फ़ॉरवर्ड कैश भी सामान्य HTTP पुनर्वैधीकरण पथ का अनुसरण किए बिना पेज स्नैपशॉट को पुनर्स्थापित कर सकता है, इसलिए "बैक बटन ने एक पुराना पेज दिखाया" का निदान केवल Cache-Control से नहीं किया जा सकता है।

चरण 4: सार्वजनिक API के लिए ब्राउज़र और CDN व्यवहार को स्वतंत्र रूप से नियंत्रित करें

मान लीजिए कि कैटलॉग आमतौर पर 60 सेकंड की देरी सहन करता है। ब्राउज़र को हर अनुरोध पर पुष्टि करनी चाहिए, जबकि CDN 60 सेकंड तक सीधे रिस्पॉन्स का पुन: उपयोग कर सकता है:

Cache-Control: public, max-age=0, s-maxage=60
ETag: "catalog-v927"
Vary: Accept-Language

प्रत्येक निर्देश का एक अलग कार्य है:

• max-age=0 ब्राउज़र को रिस्पॉन्स स्टोर करने देता है लेकिन इसे तुरंत बासी बना देता है, इसलिए बाद में उपयोग एक सत्यापन पथ में प्रवेश करता है।
• s-maxage=60 एक शेयर्ड कैश को इसे 60 सेकंड के लिए सीधे पुन: उपयोग करने देता है।
• ETag ब्राउज़र या CDN को बासी होने के बाद सशर्त अनुरोध करने देता है।
• Vary: Accept-Language कैश को संग्रहीत रिस्पॉन्स का चयन करते समय भाषा अनुरोध हेडर को शामिल करने के लिए कहता है।

यदि उत्पाद कम सत्यापन विलंबता के बदले 30 सेकंड के अन्य बासी डेटा को स्वीकार करता है, तो जोड़ें stale-while-revalidate=30। यह मानक निर्देश हर उस कैश को प्रभावित करता है जो इसका समर्थन करता है, न केवल CDN को। यदि केवल CDN व्यवहार बदलना चाहिए, तो चयनित प्रदाता से एक स्पष्ट CDN-विशिष्ट सेटिंग का उपयोग करें। जब व्यावसायिक गारंटी कहती है कि सामग्री कभी भी 60 सेकंड से अधिक पुरानी नहीं होनी चाहिए, तो इस बासी विंडो को न जोड़ें। यह कम विलंबता के लिए फ़्रेशनेस का एक स्पष्ट समझौता है, कोई डिफ़ॉल्ट अनुकूलन नहीं।

स्थान (locale) को URL में रखना अक्सर अधिक पूर्वानुमान योग्य होता है, जैसे /api/catalog?locale=zh-CN। लॉगिंग, वार्मिंग, इनवैलिडेशन और कैश कीज़ तब स्पष्ट हो जाते हैं, और रिस्पॉन्स को अब एक URL पर रिप्रजेंटेशन को अलग करने के लिए Accept-Language की आवश्यकता नहीं होती है। लापरवाही से Vary: User-Agent जोड़ने से बचें; इसके संभावित मानों की उच्च संख्या शेयर्ड-कैश के पुन: उपयोग को नष्ट कर सकती है।

चरण 5: वैयक्तिकृत कार्ट को सुरक्षित रखें

कार्ट को कभी भी शेयर्ड कैश से किसी अन्य उपयोगकर्ता को नहीं दिया जाना चाहिए। यदि ब्राउज़र वर्तमान उपयोगकर्ता के रिस्पॉन्स को स्टोर कर सकता है लेकिन पुन: उपयोग से पहले इसकी पुष्टि करनी चाहिए, तो लौटाएं:

Cache-Control: private, no-cache
ETag: "cart-v19"

private स्टोरेज को प्राइवेट कैश तक सीमित करता है। no-cache को पुन: उपयोग से पहले सत्यापन की आवश्यकता होती है। Vary: Cookie के साथ उपयोगकर्ताओं को अलग करने का प्रयास न करें: कुकी मानों में अत्यधिक उच्च कार्डिनैलिटी होती है और यह कैश-की और गोपनीयता जोखिम दोनों पैदा करती है। वैयक्तिकृत रिस्पॉन्स को स्पष्ट रूप से शेयर्ड पुन: उपयोग को रोकना चाहिए।

यदि सुरक्षा आवश्यकता "रिस्पॉन्स को किसी भी HTTP कैश में नहीं लिखा जाना चाहिए" है, तो उपयोग करें:

Cache-Control: no-store

private, no-cache, max-age=0 जोड़ने की कोई आवश्यकता नहीं है। ओवरलैपिंग या अधिक प्रतिबंधात्मक निर्देश नीति को अधिक सुरक्षित नहीं बनाते हैं; वे इसके इरादे का ऑडिट करना कठिन बनाते हैं। साथ ही, भविष्य के रिस्पॉन्स में no-store जोड़ने से पहले संग्रहीत ताज़ा प्रतियां नहीं मिटती हैं। घटना प्रतिक्रिया (incident response) के लिए CDN पर्ज, एक संस्करणित URL, पुरानी प्रविष्टियों की समाप्ति, या एक लक्षित ब्राउज़र-क्लियरिंग तंत्र की आवश्यकता हो सकती है।

चरण 6: कैश नीति को डिप्लॉयमेंट प्रोटोकॉल से बांधें

हटाई गई JavaScript विफलता को केवल हेडर द्वारा ठीक नहीं किया जा सकता है। डिप्लॉयमेंट प्रोटोकॉल को चाहिए:

1. प्रत्येक नया हैश किया गया एसेट अपलोड करें।
2. प्रोडक्शन एज स्थानों से सत्यापित करें कि प्रत्येक एसेट सुलभ है और इसमें सही MIME प्रकार, संपीड़न और हेडर हैं।
3. नए URLs को संदर्भित करने वाले HTML को प्रकाशित करें।
4. पुराने-टैब, कंपित-रिलीज़ और रोलबैक विंडो के माध्यम से पुराने हैश किए गए एसेट्स को बनाए रखें।
5. रोलबैक के दौरान पुराने HTML को तब पुनर्स्थापित करें जब उसके पुराने एसेट अभी भी मौजूद हों।
6. किसी एसेट को तभी हटाएं जब कोई भी सुलभ प्रवेश बिंदु उसे संदर्भित न करे।

यदि एकाधिक नोड HTML उत्पन्न करते हैं, तो उनके ETags को भी रिप्रजेंटेशन के अनुरूप होना चाहिए। समान सामग्री के लिए अलग-अलग ETags अनावश्यक 200 रिस्पॉन्स उत्पन्न करते हैं। भिन्न सामग्री के लिए समान मजबूत ETag का पुन: उपयोग करने से गलत 304 उत्पन्न हो सकता है। संपीड़न, भाषा और अन्य रिप्रजेंटेशन परिवर्तनों के लिए भी सही कैश कीज़ या Vary हैंडलिंग की आवश्यकता होती है।

चरण 7: एक रीलोड के बजाय अनुरोधों के एक क्रम को सत्यापित करें

ब्राउज़र DevTools में या curl के साथ एक अनुरोध मैट्रिक्स बनाएं:

curl -I "$ORIGIN/index.html"
curl -I -H 'If-None-Match: "index-v184"' "$ORIGIN/index.html"
curl -I -H 'Accept-Language: zh-CN' "$ORIGIN/api/catalog"
curl -I -H 'Accept-Language: en-US' "$ORIGIN/api/catalog"

कमांड चलाने से पहले ORIGIN को लक्ष्य साइट के ओरिजिन पर सेट करें। निम्नलिखित सभी को सत्यापित करें:

• एक प्रारंभिक अनुरोध 200, अभीष्ट हेडर और वैलिडेटर लौटाता है।
• एक स्टैटिक एसेट ताज़ा रहने के दौरान अपस्ट्रीम से संपर्क नहीं करता है, और बदला हुआ URL एक नई फ़ाइल प्राप्त करता है।
• एक अपरिवर्तित HTML सशर्त अनुरोध 304 लौटाता है, जबकि एक डिप्लॉयमेंट नए ETag के साथ 200 उत्पन्न करता है।
• कैटलॉग CDN हिट्स पर Age बढ़ता है, और शेयर्ड फ़्रेशनेस समाप्त होने के बाद सत्यापन होता है।
• दो भाषा अनुरोधों को अलग-अलग बॉडी प्राप्त होती हैं और रिस्पॉन्स में Vary शामिल होता है।
• कार्ट में ऐसा कोई कॉन्फ़िगरेशन नहीं है जो शेयर्ड-कैश पुन: उपयोग की अनुमति देता हो।
• पुराने HTML को फिर से चलाने पर भी 200 के साथ इसका संदर्भित हैश किया गया एसेट प्राप्त होता है।
• DevTools "Disable cache" नेटवर्क निदान के लिए उपयोगी है लेकिन वास्तविक कैश पथ के परीक्षण का स्थान नहीं लेता है।

एक सामान्य रीलोड, एक फ़ोर्स रीलोड, एक नया टैब, बैक/फ़ॉरवर्ड नेविगेशन, और सर्विस वर्कर वाले पथ का अलग से परीक्षण करें। एक फ़ोर्स रीलोड अनुरोध कैश निर्देशों को बदल देता है, इसलिए केवल उस पथ का परीक्षण करने से सामान्य उपयोगकर्ता व्यवहार का पुनरुत्पादन नहीं होता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं हेडर सूचीबद्ध करके शुरुआत नहीं करूंगा। प्रत्येक रिस्पॉन्स के लिए मैं चार प्रश्नों का उत्तर दूंगा: क्या इसे स्टोर किया जा सकता है, कौन इसका पुन: उपयोग कर सकता है, यह कब तक ताज़ा है, और उसके बाद इसे कैसे वैलिडेट किया जाता है?

JavaScript फ़ाइल कंटेंट हैश की गई है, इसलिए इसका URL इसके बाइट्स के साथ बदल जाता है। मैं public, max-age=31536000, immutable लौटाऊंगा और 'एक ही URL पर सामग्री को कभी ओवरराइट न करें' को रिलीज़ इनवेरिएंट बनाऊंगा। एंट्री HTML का एक स्थिर URL है, इसलिए मैं ETag के साथ no-cache का उपयोग करूंगा। इसे स्टोर किया जा सकता है, लेकिन एक सामान्य पुन: उपयोग इसे वैलिडेट करता है; अपरिवर्तित सामग्री को 304 मिलता है, जबकि परिवर्तित सामग्री को नया HTML और एक नया ETag मिलता है। no-cache स्टोरेज की अनुमति देता है। no-store वह निर्देश है जो इसे रोकता है।

सार्वजनिक कैटलॉग लगभग 60 सेकंड की देरी की अनुमति देता है। मैं ब्राउज़र के लिए max-age=0 और CDN के लिए s-maxage=60 का उपयोग करूंगा। यदि उत्पाद पुनर्वैधीकरण विलंबता को छिपाने के बदले 30 सेकंड के अन्य बासी डेटा को स्वीकार करता है, तो मैं stale-while-revalidate=30 जोड़ूंगा; अन्यथा मैं इसे छोड़ दूंगा। यदि एक ही /api/catalog URL, Accept-Language द्वारा भिन्न होता है, तो इसे Vary: Accept-Language की आवश्यकता होती है। भाषा (locale) को URL में रखना समझने में और भी आसान है।

कार्ट स्पष्ट रूप से उपयोगकर्ता-निजी है। यदि ब्राउज़र स्टोरेज और सत्यापन स्वीकार्य हैं, तो मैं private, no-cache लौटाऊंगा। यदि नीति स्टोरेज को प्रतिबंधित करती है, तो मैं केवल no-store लौटाऊंगा। मैं शेयर्ड कैश में वैयक्तिकृत रिस्पॉन्स की अनुमति नहीं दूंगा या इसकी शेयर्ड कैश की के रूप में उच्च-कार्डिनैलिटी कुकी का उपयोग नहीं करूंगा।

हटाई गई बंडल का अनुरोध करने वाला पुराना HTML एक डिप्लॉयमेंट-प्रोटोकॉल बग को भी उजागर करता है। मैं पहले नए एसेट्स अपलोड करूंगा, दूसरे नंबर पर HTML प्रकाशित करूंगा, और पुराने-प्रवेश और रोलबैक विंडो के माध्यम से पुराने हैश किए गए एसेट्स को बनाए रखूंगा। मेरा सत्यापन एक प्रारंभिक 200, एक फ्रेश हिट, ETag-आधारित 304, एक पोस्ट-डिप्लॉय 200, दो भाषा रिप्रजेंटेशन, कार्ट की शेयर्ड-कैश सीमा, और पुराने HTML के रीप्ले का अभ्यास करेगा—न कि केवल एक फ़ोर्स रीलोड का।"

सामान्य गलतियाँ

• no-cache को नो-स्टोरेज के रूप में व्याख्या करना → यह स्टोरेज की अनुमति देता है और पुन: उपयोग से पहले सत्यापन की आवश्यकता होती है → स्टोरेज को प्रतिबंधित करने के लिए no-store का उपयोग करें, या 304 से लाभ उठाने के लिए no-cache प्लस एक वैलिडेटर रखें।
• प्रत्येक संसाधन को एक वर्ष का फ़्रेशनेस लाइफ़टाइम देना → स्थिर-URL वाला HTML एक पुरानी रिलीज़ को इंगित करता रह सकता है → कंटेंट-एड्रेस्ड एसेट्स के लिए लंबी फ़्रेशनेस आरक्षित करें और एंट्री दस्तावेज़ को वैलिडेट करें।
• रिलीज़ के तुरंत बाद पुराने हैश किए गए एसेट्स को हटाना → पुराने टैब, इतिहास और रोलबैक रिलीज़ अभी भी उन्हें संदर्भित कर सकते हैं → एंट्री पॉइंट से पहले एसेट्स प्रकाशित करें और उन्हें सुलभ विंडो के माध्यम से बनाए रखें।
• फ़्रेशनेस नीति के बिना एक ETag सेट करना → कैश में स्पष्ट प्रत्यक्ष-पुन: उपयोग लाइफ़टाइम का अभाव होता है और यह अनावश्यक रूप से वैलिडेट हो सकता है → फ़्रेशनेस और वैलिडेशन को एक साथ परिभाषित करें।
• 304 को मुफ़्त कहना → यह रिस्पॉन्स बॉडी को बचाता है लेकिन फिर भी राउंड ट्रिप और सत्यापन कार्य की लागत लेता है → विलंबता और डेटा सहनशीलता उचित होने पर एक ताज़ा लाइफ़टाइम चुनें।
• बिना Vary के एक URL पर एकाधिक भाषाओं की सेवा करना → एक शेयर्ड कैश गलत रिप्रजेंटेशन का पुन: उपयोग कर सकता है → भाषा को URL में रखें या कैश की में Vary: Accept-Language जोड़ें।
• कार्ट को अलग करने के लिए Vary: Cookie का उपयोग करना → उच्च-कार्डिनैलिटी कीज़ हिट्स को कम करती हैं और गोपनीयता जोखिम को बढ़ाती हैं → private या no-store के साथ शेयर्ड पुन: उपयोग को रोकें।
• यह मान लेना कि नया जोड़ा गया no-store निर्देश पुरानी प्रविष्टियों को मिटा देता है → नया हेडर किसी ताज़ा रिस्पॉन्स तक नहीं पहुँच सकता है जिसे अभी भी सीधे पुन: उपयोग किया जा रहा है → इसे पर्ज करें, इसका संस्करण बनाएं, या पुरानी प्रविष्टि के समाप्त होने की प्रतीक्षा करें।
• केवल DevTools फ़ोर्स रीलोड के साथ परीक्षण करना → फ़ोर्स रीलोड अनुरोध कैश निर्देशों को बदल देता है → सामान्य नेविगेशन, फ्रेश हिट्स, पुनर्वैधीकरण, इतिहास पुनर्स्थापना और सर्विस वर्कर पथों का परीक्षण करें।

फ़ॉलो-अप प्रश्न

फ़ॉलो-अप 1: क्या CDN या ओरिजिन विफल होने पर कैटलॉग बासी डेटा परोस सकता है?

व्यावसायिक सहनशीलता को दो विंडो में विभाजित करें: सामान्य संचालन के दौरान अधिकतम 60 सेकंड, और ओरिजिन 5xx रिस्पॉन्स के दौरान एक अलग छूट। यदि किसी त्रुटि के दौरान पुराना डेटा स्वीकार्य है, तो एक सीमित अवधि के साथ stale-if-error का मूल्यांकन करें। यदि कीमतें या इन्वेंट्री पुरानी नहीं हो सकती हैं, तो इसके बजाय त्रुटि प्रदर्शित करें। stale-while-revalidate बैकग्राउंड पुनर्वैधीकरण विलंबता को छुपाता है; stale-if-error विफलता के दौरान बासी पुन: उपयोग की अनुमति देता है। वे विभिन्न समस्याओं का समाधान करते हैं।

फ़ॉलो-अप 2: सर्वर को स्ट्रांग या वीक ETag का उपयोग कब करना चाहिए?

एक स्ट्रांग ETag का अर्थ है कि दो रिप्रजेंटेशन बाइट-दर-बाइट समतुल्य हैं और यह उपयुक्त है जहां सटीक रेंज अनुरोध या बाइट पहचान मायने रखती है। एक वीक ETag W/ से शुरू होता है और संभावित बाइट अंतरों के बावजूद सिमेंटिक तुल्यता का प्रतिनिधित्व करता है, जो सर्वर-रेंडर किए गए आउटपुट में अप्रासंगिक फ़ॉर्मेटिंग परिवर्तनों के अनुकूल हो सकता है। कैश सत्यापन दोनों में से किसी का भी उपयोग कर सकता है, लेकिन If-Match समवर्ती नियंत्रण और रेंज अनुरोधों के लिए मजबूत-तुलना नियमों की एक और जाँच की आवश्यकता होती है।

फ़ॉलो-अप 3: DevTools बिना 304 दिखाए "from memory cache" या "from disk cache" क्यों कहता है?

एक ताज़ा रिस्पॉन्स को बिना किसी सशर्त अनुरोध के पुन: उपयोग किया जा सकता है, इसलिए कोई 304 नहीं होता है। मेमोरी और डिस्क ब्राउज़र द्वारा किए गए स्टोरेज विकल्पों का वर्णन करते हैं, न कि अलग HTTP सिमेंटिक्स का। एक DevTools लेबल से संपूर्ण नीति का अनुमान लगाने के बजाय Cache-Control, Age, अनुरोध भेजा गया था या नहीं, और रिस्पॉन्स की वर्तमान आयु का निरीक्षण करें।

फ़ॉलो-अप 4: सर्विस वर्कर जोड़ने के बाद रिस्पॉन्स हेडर बदलने से कोई मदद क्यों नहीं मिली?

नेटवर्क अनुरोध होने से पहले सर्विस वर्कर एक पुराना कैश स्टोरेज रिस्पॉन्स लौटा सकता है, इसलिए सामान्य HTTP कैश कभी भाग नहीं लेता है। फ़ेच हैंडलर, कैश स्टोरेज संस्करण, सक्रियण-समय सफ़ाई, और क्लाइंट-दावा समय का निरीक्षण करें। कैश नामों या संसाधन मैनिफ़ेस्ट का संस्करण बनाएं, फिर सत्यापित करें कि पुराने सर्विस वर्कर द्वारा नियंत्रित पेज कैसे अपग्रेड होते हैं।

फ़ॉलो-अप 5: हैश किए गए एसेट्स को संदर्भित करने वाले वैयक्तिकृत HTML को कैसे कैश किया जाना चाहिए?

HTML शेयर्ड पुन: उपयोग को रोकने और प्राइवेट-कैश पुन: उपयोग से पहले सत्यापित करने के लिए Cache-Control: private, no-cache का उपयोग कर सकता है। हैश किए गए स्टैटिक एसेट्स जो प्रत्येक उपयोगकर्ता के लिए समान हैं, वे अभी भी सार्वजनिक दीर्घकालिक कैशिंग का उपयोग कर सकते हैं। एक प्रमाणित पेज और उसके स्टैटिक संसाधनों को एक साझा नीति की आवश्यकता नहीं है; सीमा इस बात से तय करें कि क्या प्रत्येक रिप्रजेंटेशन वैयक्तिकृत है।

फ़ॉलो-अप 6: डिप्लॉयमेंट पुराने स्टैटिक एसेट्स को सुरक्षित रूप से कैसे हटा सकता है?

वर्तमान HTML, रोलबैक-सक्षम HTML, रूट मैनिफ़ेस्ट और रिलीज़ रिकॉर्ड से एक संदर्भ सेट बनाएं, फिर अधिकतम पुराने-पेज की पहुंच विंडो जोड़ें। एक हैश की गई एसेट केवल तभी विलंबित विलोपन के लिए पात्र बनती है जब कोई भी प्रकाशित करने योग्य प्रवेश बिंदु इसे संदर्भित नहीं करता है, रोलबैक विंडो समाप्त हो गई है, और एक्सेस लॉग कोई वैध अनुरोध नहीं दिखाते हैं। सफ़ाई कार्य रुकने योग्य होना चाहिए और कई हालिया रिलीज़ों को बनाए रखना चाहिए ताकि एक गलत निर्णय रोलबैक को नष्ट न करे।