ब्राउज़र कैश
Browser cache उन copies का set है जो browser पहले से download की गई files की रखता है: HTML pages, scripts, stylesheets, images, fonts और कुछ API responses। जब किसी file की फिर ज़रूरत होती है और stored copy अब भी इस्तेमाल की जा सकती है, तो browser file दोबारा download करने की बजाय copy ले लेता है। इससे दोबारा आने पर site तेज़ खुलती है, और लौटकर आने वाला user पहली बार आने वाले visitor से कुछ अलग देख सकता है।
उदाहरण: एक shop 10:00 बजे हरा "Pay now" button release करती है। कल आया एक customer 11:00 बजे checkout खोलता है और उसे अब भी पुराना नीला button दिखता है, क्योंकि browser ने server से पूछे बिना कल की stylesheet दोबारा इस्तेमाल कर ली। Release ठीक काम करता है; बस वह उस customer तक पहुँचा नहीं।
यह क्यों ज़रूरी है
Release के बाद "मेरे यहाँ तो चल रहा है" की एक आम वजह stale content है: tester ने साफ़ browser से जाँचा, जबकि customers के पास पुरानी files रह गईं। असर पुराने logo से लेकर गंभीर failures तक होता है: नया HTML पुराने JavaScript के साथ चलता है जो ऐसी requests भेजता है जिन्हें server अब स्वीकार नहीं करता, या logout के बाद भी account page दिखता रहता है।
Caching को team set up करती है। Response headers, build settings और service worker का code तय करते हैं कि क्या और कितनी देर store होगा; जिस response में caching headers नहीं होते, उसकी lifetime का browser खुद अंदाज़ा भी लगा सकता है। गलत या missing setting किसी भी दूसरे defect जैसा ही defect है। अगर आप हमेशा खाली cache से टेस्ट करते हैं, तो आप कभी वह नहीं देखते जो आपके ज़्यादातर users देखते हैं।
Memory cache, disk cache और service workers
"ब्राउज़र कैसे काम करता है" वाले lesson में आपने देखा कि Chrome Network panel की कुछ rows पर (memory cache) या (disk cache) लिखता है। Memory cache उन files को रखता है जिन्हें खुला page पहले इस्तेमाल कर चुका है; यह तेज़ और कम समय का है, और tab बंद होने के बाद नहीं बचता। Disk cache browser का HTTP cache है, RFC 9111 की भाषा में एक private cache: यह restart के बाद भी बचा रहता है, और response headers तय करते हैं कि यह क्या और कितनी देर store कर सकता है।
Fresh copy, जैसे वह जो अभी अपनी Cache-Control: max-age lifetime के अंदर है, server से संपर्क किए बिना इस्तेमाल होती है। Stale copy आम तौर पर revalidate होती है: browser copy का version tag (ETag) If-None-Match में, या उसकी date (Last-Modified) If-Modified-Since में भेजता है, और server 304 Not Modified (copy रखें) या नए version के साथ 200 लौटाता है। no-cache का मतलब है "store करो, पर हर इस्तेमाल से पहले revalidate करो"; no-store का मतलब है "store मत करो"। HTTP caching वाला lesson इन headers को विस्तार से समझाता है।
Service worker एक script है जिसे site browser में register करती है। यह page और network के बीच बैठता है और अपने store, Cache Storage, से requests का जवाब दे सकता है, भले ही HTTP cache खाली हो। Default रूप से इसका नया version background में install होता है और तब तक इंतज़ार करता है जब तक पुराना version इस्तेमाल करने वाला हर tab बंद न हो जाए, इसलिए normal reload से version नहीं बदलता।
उत्तर: हाँ
परिणाम: Service worker जवाब देता हैउसका code Cache Storage या network चुनता है, इसलिए वह पुराना version दे सकता है(ServiceWorker)उत्तर: नहीं
प्रश्न 2: क्या browser के पास stored copy है?Memory cache या disk cache मेंउत्तर: नहीं
परिणाम: Miss: server से downloadफिर store होता है, अगर response headers अनुमति दें200उत्तर: हाँ
प्रश्न 3: क्या copy अब भी fresh है?अपनेmax-ageके अंदर औरno-cacheके बिनाउत्तर: हाँ
परिणाम: Hit: server से पूछे बिना इस्तेमाल(memory cache)या(disk cache)दिखता है; उसी URL पर नया deploy इस तक नहीं पहुँचताउत्तर: नहीं
परिणाम: Server के साथ revalidate304: copy रखी जाती है;200: नया version उसकी जगह लेता हैIf-None-Match
Conceptual model: browsers details में अलग हो सकते हैं; जैसे Chrome अपना कम समय वाला memory cache service worker से भी पहले देखता है। Hard reload एक load के लिए stored copies और service worker को छोड़ देता है और कुछ delete नहीं करता।
- Hard reload (Ctrl+Shift+R, या Mac पर Cmd+Shift+R): page और उसकी files फिर से माँगता है और service worker को छोड़ देता है, सिर्फ़ इसी एक load के लिए। यह कुछ delete नहीं करता, और normal reload fresh copies फिर भी इस्तेमाल कर सकता है।
- Empty Cache and Hard Reload (Chrome में, DevTools खुला रखकर reload button पर right-click): पहले cache खाली करता है, फिर hard reload करता है।
- Disable cache (Network panel): DevTools खुला रहने तक HTTP cache बंद, लेकिन service worker फिर भी जवाब दे सकता है।
- Application panel: Service workers section active और कोई waiting version दिखाता है, Bypass for network और Unregister के साथ; Clear site data worker और उसका Cache Storage भी हटा देता है।
- Private window: खाली caches और कोई service worker नहीं, यानी पहली बार आने वाले visitor का view। पहले बाकी private windows बंद करें: वे एक ही session और उसका cache share करती हैं।
Cache busting: release browser तक कैसे पहुँचता है
Teams दो चीज़ें एक साथ चाहती हैं: files जो एक बार download होकर लंबे समय तक दोबारा इस्तेमाल हों, और releases जो हर user को तुरंत मिलें। Cache busting दोनों देता है: file बदलती है तो उसका URL बदल जाता है। Build tools file name में एक fingerprint, यानी file के content से निकाला गया एक छोटा code (hash), डालते हैं, जिससे app.3f9c1e.js बदलकर app.9b41d2.js हो जाता है; कुछ teams इसकी जगह query string में version जोड़ती हैं (app.js?v=2.15.0)। Browser ने नया URL कभी store नहीं किया, इसलिए उसे download करना ही पड़ता है।
यह तभी काम करता है जब files के नाम बताने वाला HTML खुद fresh हो। नीचे का set-up ऐसे पढ़ें:
- HTML को
no-cacheमिलता है: हर visit पर वह revalidate होता है और नए file names मिलते हैं। - Fingerprint वाली files एक साल तक cache की जा सकती हैं, क्योंकि कोई भी बदलाव उन्हें नया नाम देता है।
- बिना fingerprint वाली file, जैसे
logo.svg, deploy के बाद अपनेmax-ageतक पुरानी रह सकती है। - Deploy से पहले खुला tab अब भी पुराना code चलाता है। अगर वह बाद में ऐसी file माँगे जिसे deploy ने हटा दिया, जैसे किसी दूसरी screen की script, तो request
404के साथ fail होती है; इसलिए teams पिछले release की files कुछ समय तक online रखती हैं।
Request Cache-Control After a deploy
GET /checkout no-cache revalidated: new HTML
GET /assets/app.9b41d2.js max-age=31536000, immutable new name: downloaded
GET /assets/app.51c7aa.css max-age=31536000, immutable new name: downloaded
GET /images/logo.svg max-age=86400 old for up to 1 day
GET /api/cart no-store never storedStale-content defects और उन्हें कैसे पहचानें
Stale-content failure किसी page, file या data का ऐसा version दिखाता है जो server पर अभी मौजूद version से पुराना है। इसके पीछे का defect आम तौर पर caching set-up में होता है, test हो रहे feature में नहीं: missing fingerprint, ज़रूरत से लंबा max-age, ऐसे HTML या API responses जिन्हें cache नहीं होना चाहिए था, या ऐसा service worker जो कभी update नहीं होता। "Stale" के दो मतलबों का ध्यान रखें: ऐसे failure के पीछे की copy आम तौर पर अपने headers के हिसाब से अब भी fresh होती है, इसलिए browser server से नहीं पूछता। RFC 9111 में "stale" का मतलब सिर्फ़ इतना है कि copy की lifetime ख़त्म हो गई, और stale copy server से check की जाती है।
यह साबित करने के लिए कि वजह cache है, तुलना करें: वही steps private window में दोहराएँ, Size column पढ़ें जहाँ byte count की जगह (memory cache), (disk cache) या (ServiceWorker) लिखा होता है, और file names व build number की तुलना deploy हुए version से करें। आम symptoms:
- Release का कुछ हिस्सा कुछ users के लिए गायब: नया HTML पुरानी styles के साथ, या ऐसा feature जो hard reload के बाद दिखता है पर colleague को नहीं दिखता।
- पुराना data: admin में price बदला गया, पर shop पुराना price दिखाती है क्योंकि API response browser या CDN (content delivery network, users और site के बीच shared caches का set) में cache हो गया।
- Mixed versions: पुराना JavaScript बदली हुई API को call करता है, और save
400या console error के साथ fail होता है। - Site पुराने version पर अटकी रहती है, या online होते हुए भी अपना offline page दिखाती है: service worker अपनी stored copies दे रहा है।
- Logout के बाद personal data: Back दबाने पर account page फिर दिखता है।
Worked example: returning user की तरह release टेस्ट करना
एक shop का release 2.15.0 checkout button और उसकी styles बदलता है। Tester एक browser profile रखती है जो returning customer का काम करता है। Deploy से पहले वह उसमें checkout खोलकर load हुई files के नामों की list save करती है; deploy के बाद वह इस warm (भरे हुए) cache की तुलना cold (खाली) cache से करती है:
- उस profile में checkout normal navigation से खोलें, Disable cache बंद रखें; जो दिखे वह और build number note करें।
- Network rows की तुलना saved list से करें: क्या हर बदली हुई file नए नाम के साथ server से आती है, या पुराने content के साथ
(disk cache)से? - Deploy से पहले से खुले tab में कोई ऐसी screen खोलें जो अभी तक नहीं खोली, और एक form submit करें।
- अगर site पर service worker है, तो Application > Service workers में waiting version देखें; site के सारे tabs बंद करें, उसे फिर खोलें और confirm करें कि नया version active है।
- Private window खोलें: पहली बार आने वाले visitor को भी नया release मिलना चाहिए।
Release 2.15.0 on staging, returning-customer profile, normal navigation
Name Status Size Note
checkout 200 5.2 kB new HTML, footer shows build 2.15.0
app.9b41d2.js 200 212 kB new fingerprint
styles.css 200 (disk cache) no fingerprint, max-age=604800
logo.svg 200 (disk cache) not changed in 2.15.0: fine
Result: "Pay now" यहाँ नीला है (पुरानी styles) और private window में हरा।
Bug: styles.css पर fingerprint नहीं है और यह 7 दिन cache होती है, इसलिए
expire होने तक returning customers को 2.15.0 checkout 2.14 styles
के साथ दिखता है।आम गलतियाँ
- Release को सिर्फ़ खाली cache के साथ टेस्ट करना (private window, hard reload, या हमेशा on रहने वाला Disable cache), जिससे आप कभी नहीं देखते कि returning users क्या देखते हैं।
- Stale-content report का जवाब "अपना cache clear कर लें" देना। Users cache clear नहीं करते; caching defect report करें।
- Service worker भूल जाना: hard reload के बाद page सही दिखता है, और अगला normal load फिर पुराना worker serve करता है।
- यह मान लेना कि page नया build दिखा रहा है। कुछ और टेस्ट करने से पहले build number या file fingerprints जाँचें।
- Bug report में cache की स्थिति न लिखना: Size column की value, file names और उनके headers, build, और क्या आपने hard reload किया था।
QA का नज़रिया
जब भी कोई story front end को छूती है, refinement के दौरान caching के सवाल उठाएँ: किन files पर fingerprint है, HTML, files और API responses को कौन-सा Cache-Control मिलता है, पुरानी files कितनी देर online रहती हैं, और service worker कैसे update होता है और users से reload करने को कैसे कहता है।
हर deploy के बाद पहले returning-user profile से टेस्ट करें, फिर हर cache को bypass करने वाली एक check जोड़ें और दोनों की तुलना करें। Stale-content report में expected build और दिखा हुआ build, प्रभावित URL उसके Cache-Control और Size column value के साथ, browser और profile, और क्या private window नया version दिखाती है, यह सब record करें। तब developers अंदाज़ा लगाने की बजाय गलत configured file ढूँढ लेते हैं।
अभ्यास
Release के बाद returning customer क्या देखेगा, पहले से बताएँ
Release 3.4.0 invoice page पर VAT line जोड़ता है, brand colour बदलता है और logo बदलता है। यह मंगलवार 10:00 बजे live हुआ। एक customer ने पहले सिर्फ़ एक बार, सोमवार 18:00 बजे, invoice खोला था, तभी browser ने उसकी सारी files store कीं, और वह मंगलवार 11:00 बजे normal navigation से लौटता है। Site पर कोई service worker नहीं है।
नीचे दिए headers से हर request के लिए तय करें कि browser अपनी stored copy इस्तेमाल करता है या server, बताएँ कि customer क्या देखता है, और defects व उन्हें confirm करने का तरीका लिखें।
Release 3.4.0, live Tuesday 10:00. No service worker.
Request Cache-Control Note
GET /invoice/1001 no-cache ETag changed in 3.4.0
GET /static/invoice.81f2a0.js max-age=31536000, immutable new name in 3.4.0
GET /static/styles.css max-age=604800 changed in 3.4.0
GET /static/logo.png max-age=86400 changed in 3.4.0
GET /api/invoices/1001 no-store VAT line data- हिसाब लगाएँ कि हर stored copy कब तक fresh रहती है।
- हर request के लिए तय करें: download, revalidation, stored copy या कभी store नहीं।
- Customer को दिखने वाले page का वर्णन करें।
- Defects और उन्हें confirm करने वाली एक check लिखें।
मॉडल उत्तर दिखाएँ
नए हिस्से पहुँचते हैं: no-cache की वजह से /invoice/1001 revalidate होता है, और बदला हुआ ETag VAT line वाला नया HTML लाता है; invoice.81f2a0.js ऐसा URL है जिसे browser ने कभी store नहीं किया, इसलिए वह download होता है; no-store वाला API response हमेशा server से आता है।
पुराने हिस्से रह जाते हैं: styles.css सोमवार 18:00 बजे max-age=604800 (7 दिन) के साथ store हुई थी, इसलिए वह अगले सोमवार 18:00 बजे तक fresh है और server से पूछे बिना इस्तेमाल होती है। logo.png का max-age=86400 (1 दिन) है, इसलिए वह मंगलवार 18:00 बजे तक fresh रहता है।
Customer VAT line वाला नया invoice देखता है, पर पुराने colour और पुराने logo के साथ, और VAT line अपनी नई styles के बिना दिख सकती है। Defect: styles.css और logo.png पर fingerprint नहीं है, इसलिए returning users को 7 दिन तक नया page पिछले release की styles के साथ, और 1 दिन तक पुराने logo के साथ मिलता है। Fix चुनना, जैसे दोनों files पर fingerprint लगाना, developers का काम है।
Confirmation: release से पहले invoice load कर चुके profile में उसे normally खोलें और Size column पढ़ें, जिसमें दोनों files के लिए (disk cache) दिखता है; फिर page private window में खोलें, जहाँ नया colour और logo दिखते हैं। यह अंतर दिखाता है कि वजह cache है, release नहीं।
अक्सर पूछे जाने वाले सवाल
Hard reload और cache clear करने में क्या फ़र्क है?
Hard reload एक load के लिए stored copies को अनदेखा करता है: browser page और उसकी files फिर से माँगता है और service worker को छोड़ देता है, पर cache रहने देता है। Cached files clear करने से copies delete हो जाती हैं। इनमें से कोई भी service worker को नहीं हटाता; उसे Application panel का Clear site data या Unregister हटाता है।
अगर cache clear करने से समस्या ठीक हो जाए, तो क्या यह फिर भी defect है?
हाँ। Customers अपना cache clear नहीं करते, इसलिए उन्हें failure दिखता रहता है। Defect caching set-up में है, जैसे missing fingerprint या ज़रूरत से लंबा max-age। इसकी severity इस पर निर्भर करती है कि पुराना content क्या तोड़ता है: पुराना logo Minor है, पुराना price या fail होता payment नहीं।
क्या DevTools का Disable cache service worker को भी बंद करता है?
नहीं। यह DevTools खुला रहने तक HTTP cache बंद करता है, लेकिन service worker अपने Cache Storage से फिर भी जवाब दे सकता है। Chrome में Application > Service workers का Bypass for network इस्तेमाल करें, या private window में टेस्ट करें।
संदर्भ
- RFC 9111: HTTP CachingCache-Control, Expires, ETag और वैलिडेटर कैसे तय करते हैं कि रिस्पॉन्स स्टोर और पुन: उपयोग हो सकता है या नहीं।
- HTTP caching — MDNप्राइवेट बनाम शेयर्ड कैश, फ़्रेशनेस, ETag / Last-Modified से वैलिडेशन और आम Cache-Control पैटर्न।
- Service Worker API — MDNService workers: वे स्क्रिप्ट जो वेब ऐप और नेटवर्क के बीच बैठकर requests को intercept करती हैं, cache संभालती हैं और ऐप को offline चलाए रखती हैं।
Mutqan tools से अभ्यास करें
Cache-Control, Expires, ETag, Last-Modified, Vary और Age हेडर जाँचें और समझें कि ब्राउज़र तथा CDN रिस्पॉन्स को कैसे कैश करेंगे।
कच्चे HTTP रिक्वेस्ट/रिस्पॉन्स हेडर को व्याख्या सहित एक संरचित तालिका में बदलें।
caching, CORS, security और content negotiation के प्रीसेट से HTTP हेडर तैयार करें।
दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।