JavaScript और CSS cache busting: नए संस्करण की सुरक्षित रिलीज
Cache busting बदली हुई JavaScript या CSS को नया URL देता है, अक्सर filename में content hash जोड़कर। ऐसे स्थिर versioned files को लंबी caching दें; HTML को कम lifetime या revalidation से नए संस्करण खोजने दें।
इस मार्गदर्शिका में
नई रिलीज निजी window में सही और लौटने वाले visitor के browser में पुरानी दिखे तो पहले asset URLs मिलाएं। server पर file बदल सकती है, जबकि browser उसी पुराने URL का अभी ताजा cached response उपयोग कर रहा हो।
भरोसेमंद रिलीज में HTML और उसके assets का संबंध स्पष्ट रहता है। इस उदाहरण में दोनों संस्करण उपलब्ध रहते हैं ताकि deployment से पहले खुला page भी बाद में अपनी matching files ले सके। केवल नए page का चलना पूरी जांच नहीं है।
HTML document और versioned assets अलग रखें
HTML को किसी रिलीज का छोटा manifest मानें। A में app.4c21.js और site.19ab.css हैं। B बदले application के लिए app.9d80.js लेता है; stylesheet की bytes समान हों तो site.19ab.css रख सकता है। ये hashes उदाहरण के नाम हैं, वास्तविक files से निकले परिणाम नहीं।
इससे अपरिवर्तित assets फिर इस्तेमाल होते हैं और बदले assets को नई cache identity मिलती है। HTML को साल भर cache करना नई रिलीज की खोज रोक सकता है: पुराना document पाने वाला visitor पुराने asset URLs ही मांगेगा। इसलिए resource के हिसाब से freshness चुनें।
| संसाधन | रिलीज A | रिलीज B | अपेक्षित व्यवहार |
|---|---|---|---|
| HTML | app.4c21.js की ओर संकेत | app.9d80.js की ओर संकेत | पुनः सत्यापन या जानबूझकर छोटा lifetime |
| एप्लिकेशन JavaScript | app.4c21.js | app.9d80.js | bytes बदलें तो नया URL |
| अपरिवर्तित CSS | site.19ab.css | site.19ab.css | उसी content URL का फिर उपयोग |
| पुराने assets | उपलब्ध | पुराने pages के लिए भी उपलब्ध | जरूरी compatibility अवधि तक रखें |
इसी अनुबंध के अनुसार caching directives चुनें
जो सार्वजनिक content-versioned file उस URL पर कभी नहीं बदलेगी, उसके लिए लंबा max-age और immutable उचित हो सकता है। HTML पर no-cache storage की अनुमति देता है, लेकिन reuse से पहले validation मांगता है। no-store अलग है: वह response न रखने को कहता है। पूरे site पर एक header न चिपकाएं।
नीचे headers एक रणनीति दिखाते हैं, सार्वभौमिक configuration नहीं। hosting वास्तव में क्या भेजता है और edge cache कैसे सेट है, यह जांचें। स्थानीय file में header लिखना इस बात का प्रमाण नहीं कि browser और CDN को वही नीति मिली। published response देखें।
Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable
HTML document: /index.html
Cache-Control: no-cache
The URL /assets/app.9d80.js must continue to serve the same bytes.Query version तभी उपयोगी है जब cache key उसे माने
यदि cache key में query शामिल है तो /app.js?v=release-b और /app.js?v=release-a अलग identities हो सकते हैं। संबंधित हर cache को जांचें। query strings अनदेखी करने वाला CDN नियम दोनों URLs को एक cached object पर ला सकता है और versioning निष्फल हो जाएगी।
हर page load में random value न लगाएं; हर visitor का नया URL उपयोगी reuse समाप्त करता है। stable content hash या release version resource बदलने पर ही बदलता है। /app.js#release-b जैसा fragment HTTP request में नहीं जाता, इसलिए cache busting के लिए उपयुक्त नहीं है।
पुरानी bytes देने वाली परत खोजें
प्रभावित visitor के HTML response, referenced URL और asset bytes मिलाएं। document में पुराना hash हो तो HTML freshness देखें। नया hash पुरानी bytes दे तो deployment, cache key और origin जांचें। network सही लेकिन व्यवहार पुराना हो तो running page या service worker अलग से देखें।
CDN purge हर browser में पहले से मौजूद fresh response नहीं मिटाता। browser hard reload केवल स्थानीय जांच है, सभी visitors का इलाज नहीं। हर परीक्षण में कौन सी cache bypass हुई, लिखें ताकि सफलता दोहराई जा सके; अलग रास्ते की सफलता को स्थायी सुधार न मानें।
- अंतिम HTML URL तथा referenced script या stylesheet URL दर्ज करें।
- status, Content-Type, Cache-Control, ETag और cache-status headers जांचें।
- नए version पर उसकी असली bytes आएं, HTML fallback नहीं।
- यदि service worker है तो उसकी cache policy अलग जांचें।
- साफ visit और deployment के दौरान खुला छोड़ा page दोनों आजमाएं।
Deployment और rollback में पुराने pages चलने दें
नए assets पहले upload करें, फिर उनकी ओर इशारा करने वाला HTML दें; या पूरी रिलीज साथ बदलने वाला deployment अपनाएं। cached HTML और open tabs के लिए पुराने assets पर्याप्त समय रखें। पुराना page पहली visit के घंटों बाद अतिरिक्त module मांग सकता है।
उदाहरण में B के साथ A और B assets उपलब्ध रखें, B जांचें और HTML को A पर लौटाने का रास्ता बचाएं। app.4c21.js तुरंत हटाने से A वाला document टूट सकता है। उसी नाम पर नई bytes रखना भी content-addressed अनुबंध तोड़ता और rollback अनिश्चित बनाता है।
पहले शुद्धता, फिर reuse का मापन
पहली visit में download, दूसरी में योग्य resources का reuse और नई रिलीज में केवल बदले versions का transfer जांचें। वास्तविक network transfer और revalidation requests देखें। हर cached response की लागत समान नहीं होती; केवल cache का नाम देखकर बचत घोषित न करें।
Cache-savings calculator आपके बताए hit-rate से origin requests की कमी का अनुमान देता है। transfer calculator stated request count और response size से bytes निकालता है। दोनों deployed headers और वास्तविक hit rate की जगह नहीं लेते; सही रिलीज के बाद स्पष्ट धारणाओं की तुलना में उनका उपयोग करें।
आम सवाल
पुरानी CSS के लिए सारी caching बंद कर दूं?
पहले stale document या asset पहचानें और स्थिर versioning बनाएं। सब जगह reuse रोकने से transfer और latency बढ़ सकती है, जबकि रिलीज प्रक्रिया अस्पष्ट रहती है।
क्या ETag बदलते ही fresh cached file हट जाती है?
browser fresh response को server से पूछे बिना reuse कर सकता है। बदले content का नया URL भविष्य के validation का इंतजार नहीं करता।
पुराने hashed files कब हटाऊं?
जब cached HTML, खुले pages और rollback के लिए आवश्यक compatibility अवधि समाप्त हो। कोई supported document उन्हें reference कर सकता हो तो बनाए रखें।
स्रोत और परिभाषाएँ
विधि की जाँच की गई: