मुफ़्त Cache-Control हेडर विश्लेषक

Cache-Control Header Analyzer एक मुफ़्त ऑनलाइन टूल है जो cache-control हेडर को पार्स करके समझाता है, और एक विज़ुअल बिल्डर तथा सर्वोत्तम-अभ्यास सुझाव देता है। यह पूरी तरह आपके ब्राउज़र में चलता है, किसी इंस्टॉलेशन या साइन-अप की ज़रूरत नहीं।

सभी Cache-Control डायरेक्टिव, जिनमें max-age, no-cache, no-store, public, private, must-revalidate और अन्य शामिल हैं।

हाँ — हेडर स्ट्रिंग बनाने के लिए बिल्डर मोड में डायरेक्टिव को टॉगल करें।

हाँ, पूरी तरह मुफ़्त।

बिल्कुल। Cache-Control Header Analyzer सब कुछ आपके ब्राउज़र में क्लाइंट-साइड पर ही प्रोसेस करता है। कोई भी डेटा किसी सर्वर पर अपलोड या संग्रहीत नहीं किया जाता। आपकी सामग्री हर समय आपके डिवाइस पर निजी रहती है।

हाँ, Cache-Control Header Analyzer पूरी तरह रिस्पॉन्सिव है और स्मार्टफ़ोन व टैबलेट पर काम करता है। आप इसे आधुनिक वेब ब्राउज़र वाले किसी भी डिवाइस पर इस्तेमाल कर सकते हैं, किसी ऐप डाउनलोड की ज़रूरत नहीं।

किसी खाते या पंजीकरण की ज़रूरत नहीं है। बस अपने ब्राउज़र में Cache-Control Header Analyzer खोलें और तुरंत इस्तेमाल शुरू करें। कोई साइन-अप बाधा या उपयोग प्रतिबंध नहीं है।

बस दिए गए फ़ील्ड में अपना इनपुट दर्ज करें, अपनी पसंद के अनुसार कोई भी सेटिंग समायोजित करें, और टूल उसे तुरंत प्रोसेस कर देगा। फिर आप परिणाम को क्लिपबोर्ड पर कॉपी कर सकते हैं या डाउनलोड कर सकते हैं।

Cache-Control Header Analyzer सभी आधुनिक ब्राउज़र में काम करता है, जिनमें Chrome, Firefox, Safari, Edge और Opera शामिल हैं। बेहतरीन अनुभव के लिए अपने पसंदीदा ब्राउज़र का नवीनतम संस्करण उपयोग करें।

दोनों सेकंड में एक freshness lifetime सेट करते हैं, लेकिन ये अलग-अलग caches को टारगेट करते हैं। max-age हर cache को — विज़िटर के ब्राउज़र सहित — बताता है कि दोबारा fetch या revalidate किए जाने से पहले रिस्पॉन्स कितनी देर तक फ्रेश रहता है। s-maxage सिर्फ CDNs और proxies जैसे shared caches पर लागू होता है, और मौजूद होने पर यह उन caches के लिए max-age को ओवरराइड कर देता है जबकि ब्राउज़र के max-age को नहीं छूता। इससे आप CDN edge पर रिस्पॉन्स को आक्रामक तरीके से कैश कर सकते हैं जबकि ब्राउज़र में एक छोटा या अलग lifetime रख सकते हैं, उदाहरण के लिए public, max-age=3600, s-maxage=86400 — एक घंटे का ब्राउज़र कैश और एक दिन का edge कैश। यह एनालाइज़र ब्राउज़र कैश और CDN कैश को दो अलग-अलग बैज के रूप में दिखाता है, तो अपना header ऊपर पेस्ट करके देखें कि हर लेयर रिस्पॉन्स को कितनी देर तक होल्ड करेगी।

मिलते-जुलते नाम होने के बावजूद, ये directives बिल्कुल विपरीत काम करते हैं। no-store कैशिंग को पूरी तरह रोकता है: न ब्राउज़र और न ही कोई CDN कॉपी रख सकता है, इसलिए हर रिक्वेस्ट वापस origin तक जाती है। बैंकिंग पेज या पर्सनल अकाउंट डेटा जैसे संवेदनशील रिस्पॉन्स के लिए यही सही विकल्प है। no-cache रिस्पॉन्स को स्टोर करने की इजाज़त तो देता है, लेकिन इसे दोबारा सर्व करने से पहले cache को origin सर्वर से revalidate करना ज़रूरी होता है, इसलिए जब कुछ भी नहीं बदला हो तो यूज़र को हमेशा पूरी री-डाउनलोड के बिना वेरिफाइड-फ्रेश कंटेंट मिलता है। एक आम पैटर्न यह है कि HTML के लिए no-cache इस्तेमाल किया जाए ताकि डिप्लॉय के तुरंत बाद नए asset संदर्भ दिखें, और no-store सिर्फ वहीं इस्तेमाल हो जहां प्राइवेसी की ज़रूरत हो। ऊपर कोई header पेस्ट करें और एनालाइज़र हर directive को कैटेगरी के हिसाब से लेबल कर देगा — freshness, revalidation, या audience — ताकि व्यवहार एक नज़र में साफ हो जाए।

max-age हमेशा सेकंड में व्यक्त किया जाता है, और 31,536,000 सेकंड ठीक एक साल के बराबर होता है (60 x 60 x 24 x 365)। यह पारंपरिक अधिकतम मान इसलिए है क्योंकि ज्यादातर कैशिंग गाइडलाइंस एक साल को व्यावहारिक रूप से स्थायी मानती हैं। यह अक्सर fingerprinted स्टैटिक assets पर immutable के साथ मिलता है — ऐसी फाइलें जिनके नाम में एक content hash शामिल होता है, जैसे app.4f2a9c.js — क्योंकि हर नए बिल्ड से एक नया फाइलनेम बनता है, इसलिए पुरानी फाइल को कभी बदलने की ज़रूरत नहीं पड़ती और उसे जितना हो सके उतनी देर तक कैश किया जा सकता है। immutable directive यह भी बताता है कि उस समय-सीमा के दौरान रीलोड पर ब्राउज़र revalidation रिक्वेस्ट न भेजें। हाथ से duration निकालना गलतियों से भरा होता है, इसलिए यह टूल किसी भी max-age या s-maxage वैल्यू को वापस घंटों और दिनों जैसी पढ़ने लायक इकाइयों में बदल देता है, जिससे आप किसी header को शिप करने से पहले उसकी जांच कर सकें। इसे तुरंत डिकोड करने के लिए ऊपर एक पेस्ट करें।

डिप्लॉय के बाद पुराना कंटेंट दिखने का कारण लगभग हमेशा HTML दस्तावेज़ पर बहुत ज्यादा आक्रामक Cache-Control header होता है। अगर पेज एक लंबे max-age और बिना किसी revalidation directive के भेजा गया था, तो ब्राउज़र और CDN उस lifetime के खत्म होने तक कैश की गई कॉपी — उसके पुराने CSS और JavaScript संदर्भों सहित — सर्व करते रहते हैं, जिससे यूज़र्स को कभी फिक्स नहीं मिलता। सुरक्षित उपाय यह है कि HTML को no-cache के साथ (या बहुत छोटे max-age के साथ must-revalidate जोड़कर) सर्व करें ताकि यह हर विज़िट पर revalidate हो और नए asset संदर्भों को तुरंत दर्शाए, जबकि लंबी, immutable कैशिंग सिर्फ hashed स्टैटिक फाइलों पर ही रखें। याद रखें कि CDN edge caches s-maxage का पालन स्वतंत्र रूप से करते हैं, इसलिए एक पुराना edge एक फ्रेश ब्राउज़र से भी ज्यादा देर तक टिक सकता है। पेज का Cache-Control header ऊपर पेस्ट करें यह देखने के लिए कि वह कहीं ज़्यादा देर के लिए तो कैश नहीं हो रहा।

stale-while-revalidate किसी cache को थोड़ी पुरानी रिस्पॉन्स तुरंत सर्व करने देता है, जबकि वह बैकग्राउंड में origin से एक फ्रेश कॉपी fetch करता रहता है, इसलिए अगले विज़िटर को धीमे राउंड-ट्रिप का इंतज़ार किए बिना ही अपडेट मिल जाता है। आप सेकंड में एक विंडो सेट करते हैं — उदाहरण के लिए public, max-age=300, stale-while-revalidate=60 का मतलब है कि रिस्पॉन्स पांच मिनट तक फ्रेश रहता है, फिर एक और मिनट तक stale सर्व हो सकता है जबकि यह बैकग्राउंड में रिफ्रेश होता है। यह उस कंटेंट के लिए आदर्श है जो थोड़ी staleness झेल सकता है, जैसे CDN-कैश्ड पेज और API रिस्पॉन्स, जहां पूर्ण freshness से ज्यादा माना गया स्पीड मायने रखती है। एक संबंधित directive, stale-if-error, तब stale कॉपी सर्व करता है जब origin एरर लौटाता है, जिससे resilience बढ़ता है। इनमें से कोई भी directive शामिल करने वाला header ऊपर पेस्ट करें और एनालाइज़र सटीक व्यवहार और समय-सीमा समझा देगा।