Chrome DevTools स्टोरेज: प्रत्येक यंत्रणा सोप्या भाषेत (वापराच्या उदाहरणांसह)

DevTools उघडा, Application वर क्लिक करा, आणि डाव्या बाजूच्या साइडबारकडे पाहा. Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage, Shared Storage, Background Services… खूप काही आहे. मी अनुभवी डेव्हलपर्सनासुद्धा प्रत्येक गोष्टीसाठी localStorage वापरताना पाहिलं आहे — मग ते ऑथ टोकन्स असोत, शॉपिंग कार्ट असो, किंवा मेगाबाइट्समधले API रिस्पॉन्स — फक्त त्यांना तेच एक माहीत आहे म्हणून. हे नेहमीच चुकीचं नसतं, पण क्वचितच ते सर्वोत्तम निवड असते. चला, या प्रत्येक यंत्रणेचं काम काय आहे, DevTools मध्ये ती कुठे सापडते, आणि — सर्वात महत्त्वाचं म्हणजे — शेजारी असलेल्या इतर सहा पर्यायांऐवजी ती तुम्ही केव्हा वापरावी, हे प्रत्यक्षात जाऊन पाहूया.

Application पॅनेल इतकं महत्त्वाचं का आहे

ब्राउझर्समध्ये एकत्रित स्टोरेज इन्स्पेक्टर येण्यापूर्वी, “माझा डेटा का टिकत नाहीये” हे शोधण्यासाठी सहसा अंदाजावर आधारित console.log टाकत बसावं लागायचं. Chrome DevTools मधल्या Application पॅनेलने हे बदलून टाकलं — कुकीज, लोकल स्टोरेज, सेशन स्टोरेज, IndexedDB डेटाबेस, कॅश स्टोरेज एंट्रीज, सर्व्हिस वर्कर्स, आणि अगदी Shared Storage व Interest Groups सारख्या नवीन Privacy Sandbox फीचर्ससुद्धा पाहण्यासाठी, संपादित करण्यासाठी आणि हाताने हटवण्यासाठी एकच जागा देतो [1].

हे महत्त्वाचं का आहे, कारण या प्रत्येक स्टोरेज प्रकाराचं वर्तन वेगवेगळं आहे — आकाराच्या मर्यादा वेगळ्या, टिकण्याचा कालावधी वेगळा, सिंक/असिंक वर्तन वेगळं, सर्व्हरला दिसण्याचं प्रमाण वेगळं. चुकीचा प्रकार निवडणं हा फक्त शैलीचा प्रश्न नाही; त्यामुळे तुमच्या अॅपची कामगिरी बिघडू शकते, टॅब्समध्ये डेटा गळू शकतो, किंवा तुम्हाला कारण कळण्याआधीच ब्राउझर तो शांतपणे पुसून टाकू शकतो. चला, सविस्तर पाहूया.

संपूर्ण चित्र — झटपट तुलना

प्रत्येक प्रकारात खोलवर जाण्याआधी, ही एक चीट-शीट आहे जी मला वर्षांपूर्वी कुणीतरी द्यायला हवी होती असं वाटतं:

ही क्षमता आणि वर्तन Chrome आणि MDN प्रकाशित करत असलेल्या तुलनात्मक डेटावरून घेतलेली आहेत आणि DevTools मध्ये स्वतः पाहिलेल्या गोष्टींशी ती साधारणपणे जुळतात — Session/Local Storage साधारण ५MB प्रति ओरिजिन इतकी असते, कुकीज सुमारे ४KB पर्यंत मर्यादित असतात, आणि डिस्कवर किती जागा उपलब्ध आहे यावर अवलंबून IndexedDB शेकडो मेगाबाइट्स किंवा त्याहूनही जास्त वाढू शकते [2].

आता प्रत्येक प्रकार खरोखरच पाहूया — तो कशासाठी आहे, आणि मी तो कधी निवडेन याचं एक खरंखुरं उदाहरण.

Cookies — फक्त हीच एक गोष्ट जी तुमचा सर्व्हर खरोखर वाचू शकतो

जवळपास सर्वांना माहीत असूनही चुकत राहणारी गोष्ट इथे आहे: कुकीज ही एकमेव क्लायंट स्टोरेज यंत्रणा आहे जी प्रत्येक जुळणाऱ्या HTTP रिक्वेस्टसोबत आपोआप सर्व्हरला पाठवली जाते [2]. जेव्हा तुम्हाला सर्व्हर-साइड सेशन व्हॅलिडेशनची गरज असते, तेव्हा हे फायद्याचं असतं, आणि जेव्हा तुम्ही त्यात मेगाबाइट्सभर कचरा कोंबता, तेव्हा हे कामगिरीवर कर बनतं.

DevTools मध्ये, या Application → Storage → Cookies → (एखादी ओरिजिन निवडा) इथे सापडतात. तुम्ही व्हॅल्यूज तिथल्या तिथे संपादित करू शकता, नवीन जोडू शकता, नावाने फिल्टर करू शकता, आणि HttpOnly, Secure, व SameSite यांसारखे फ्लॅग्ज टेबलमध्येच पाहू शकता [1].

प्रत्यक्ष वापराचं उदाहरण: ऑथेंटिकेशन सेशन्स. जेव्हा वापरकर्ता लॉगिन करतो, तेव्हा सर्व्हर सेशन ID असलेली HttpOnly कुकी सेट करतो. ती HttpOnly असल्याने JavaScript ती वाचू शकत नाही (त्यामुळे एखाद्या XSS बगमुळे ती थेट चोरली जाऊ शकत नाही), आणि ती कुकी असल्याने प्रत्येक रिक्वेस्टसोबत आपोआप जाते, त्यामुळे वापरकर्त्याला “लक्षात ठेवण्यासाठी” क्लायंट-साइड कोडची एकही ओळ न लिहिता सर्व्हर सेशन व्हॅलिडेट करू शकतो.

दुसरं, अगदी सद्यकालीन उदाहरण: रेंडरच्या वेळी सर्व्हरला आवश्यक असणारे संमती आणि वैयक्तिकीकरणाचे फ्लॅग्ज — जसं की वापरकर्ता कुठल्या A/B टेस्ट गटात आहे, किंवा त्याने कुकी बॅनर स्वीकारलं आहे का — कारण HTML तयार करण्याआधीच सर्व्हरला हे माहीत असणं गरजेचं आहे.

हेसुद्धा लक्षात घेण्यासारखं आहे की थर्ड-पार्टी कुकीजची गोष्ट एखाद्या रोलरकोस्टरसारखी राहिली आहे. Google ने सुरुवातीला थर्ड-पार्टी कुकीज पूर्णपणे बंद करण्याची घोषणा केली होती, पण नंतर 2024 च्या मध्यात ती मागे घेतली — आता Chrome वापरकर्त्यांना त्या थेट ब्लॉक करण्याऐवजी “निवड” विचारणारा प्रॉम्प्ट दाखवतो [3][4]. Safari आणि Firefox आधीपासूनच थर्ड-पार्टी कुकीज डीफॉल्टने ब्लॉक करतात, त्यामुळे जर तुमचं अ‍ॅप ट्रॅकिंग किंवा embeds साठी क्रॉस-साइट कुकीजवर अवलंबून असेल, तर Chrome ते सक्तीने लागू करो वा न करो — तुम्ही आधीच अंशतः कुकी-विरहित जगात राहत आहात [4]. आणि फर्स्ट-पार्टी असो वा थर्ड-पार्टी, क्रॉस-साइट कुकीजमध्ये SameSite=None; Secure असणं गरजेचं आहे — Chrome 80 पासून ही सक्त गरज आहे [4].

localStorage — सगळ्यांनी जास्तच कोंबलेला सोपा खण

localStorage ही ओरिजिन-आधारित, सिंक्रोनस की-व्हॅल्यू स्टोअर आहे, जी ब्राउझर पुन्हा सुरू केल्यावरही टिकते. ती Application → Storage → Local Storage → (ओरिजिन) इथे सापडते, जिथे DevTools तुम्हाला थेट टेबलमध्ये एंट्रीज जोडण्याची, संपादित करण्याची आणि हटवण्याची सुविधा देतो [1].

ती खरोखर कशासाठी चांगली आहे:

• वापरकर्त्याची प्राधान्ये — थीम (डार्क/लाइट), भाषा, लेआउट डेन्सिटी
• छोटे फीचर फ्लॅग्ज किंवा “हे टूलटिप पुन्हा दाखवू नका” अशा खुणा
• क्वचितच बदलणाऱ्या लहान API रिस्पॉन्सेसचं हलकं कॅशिंग (उदाहरणार्थ: देशांच्या कोडची यादी, संपूर्ण ऑर्डर हिस्टरी नाही)

मी कुठे चुकीचं होताना पाहिलं आहे: लोक “सोयीसाठी” localStorage मध्ये JWT साठवतात, हे लक्षात न घेता की पेजवर चालणारी कुठलीही स्क्रिप्ट — अगदी एखाद्या तडजोड झालेल्या npm पॅकेजमधून आलेली थर्ड-पार्टी स्क्रिप्ट किंवा XSS भेग असलेली स्क्रिप्टसुद्धा — ती वाचू शकते. HttpOnly असलेल्या कुकीज तरी तुमच्या टोकन आणि कुठल्याही JavaScript मध्ये एक भिंत उभी करतात. जर तुम्हाला टोकन क्लायंट-साइड साठवावंच लागत असेल आणि कुकीज वापरता येत नसतील, तर निदान हे समजून घ्या की तुम्ही सोयीसाठी XSS-प्रतिकारशक्ती गमावत आहात.

दुसरी अडचण: localStorage सिंक्रोनस आहे आणि मेन थ्रेड ब्लॉक करते. एखाद्या टेक्स्ट एडिटरमध्ये प्रत्येक कीस्ट्रोकवर काही शेकडो KB चा JSON त्यात लिहा, आणि तुम्हाला तुमचं UI अडखळताना जाणवेल. मी प्रत्यक्षात पाहिलं आहे की एका “साध्या” ऑटोसेव्ह फीचरने इनपुट रिस्पॉन्सिव्हनेस बिघडवली, कारण कोणीतरी प्रत्येक oninput इव्हेंटवर localStorage.setItem(JSON.stringify(hugeObject)) करत होतं. Application पॅनेल नेमकं अशा “माझ्या मशीनवर तर चालतंय” प्रकारच्या बगांना पकडण्यासाठी मदत करतो — Storage टॅब उघडा, आकार रिअल टाइममध्ये वाढताना पाहा, आणि वापरकर्त्यांपर्यंत पोहोचण्याआधीच समस्या तुमच्या लक्षात येईल.

sessionStorage — एक टॅब आपल्या शेजाऱ्याशी जे शेअर करत नाही

sessionStorage DevTools मध्ये अगदी localStorage सारखीच दिसते (तेच टेबल, संपादन/हटवण्याची तीच UI, फक्त साइडबारमध्ये वेगळी एंट्री [1]), पण तिच्यात एक महत्त्वाचा फरक आहे: ती फक्त एका टॅबपुरती मर्यादित असते, आणि तो टॅब बंद झाला की ती नाहीशी होते. एकाच ओरिजिनला उघडलेले दोन टॅब्ससुद्धा sessionStorage डेटा एकमेकांत शेअर करत नाहीत — हे पहिल्यांदा अनुभवताना अनेकांना आश्चर्य वाटतं.

प्रत्यक्ष वापराची उदाहरणं:

• मल्टी-स्टेप फॉर्म्स / चेकआउट विझार्ड्स — “स्टेप 2 पैकी 4” चा डेटा साठवा जेणेकरून रिफ्रेश केल्यावर वापरकर्त्याची प्रगती मिटून जाणार नाही, पण तो डेटा कायमचा राहूही नये
• फॉर्मचं डुप्लिकेट सबमिशन रोखणं — फॉर्म सबमिट झाल्यावर एक फ्लॅग सेट करा, पुन्हा सबमिट होण्याआधी तो तपासा
• एकदाच चालणारे ऑनबोर्डिंग फ्लो जे वापरकर्त्याने नवीन टॅबमध्ये अ‍ॅप उघडल्यास रीसेट व्हायला हवेत

खरं सांगायचं तर, हे दोघांपैकी सर्वात कमी वापरलं जाणारं आहे. लोक सवयीने localStorage निवडतात, अगदी तेव्हाही जेव्हा त्या डेटाला सध्याच्या टॅब सेशननंतर टिकून राहण्याची काहीच गरज नसते — आणि मग तो डेटा नंतर स्वतःहून साफ करायचं लक्षात ठेवावं लागतं. ते काम ब्राउझरला आपोआप करू द्या.

IndexedDB — जेव्हा खरंच ब्राउझरमध्ये डेटाबेसची गरज असते

इथून गोष्टी अधिक रंजक होतात — आणि खरं सांगायचं तर, इथूनच त्या अधिक कठीणही होतात. IndexedDB ही ब्राउझरमध्ये अंगभूत असलेली पूर्ण ट्रांझॅक्शनल, असिंक्रोनस, NoSQL-सदृश डेटाबेस आहे, जी स्ट्रक्चर्ड डेटा, ब्लॉब्स आणि फाइल्स साठवू शकते, आणि इंडेक्सेस व रेंज क्वेरीजना सपोर्ट करते [2][5]. DevTools मध्ये ती Application → Storage → IndexedDB इथे सापडते, जिथे तुम्ही वैयक्तिक डेटाबेसेस, ऑब्जेक्ट स्टोअर्स, आणि अगदी वैयक्तिक रेकॉर्ड्सपर्यंत खोलवर जाऊ शकता [1].

मी प्रत्यक्षात ज्यासाठी हे निवडेन अशी उदाहरणं:

• ऑफलाइन-फर्स्ट अ‍ॅप्स — नोट-टेकिंग अ‍ॅप्स, टू-डू अ‍ॅप्स, कमजोर कनेक्शनवरही चालायला हवेत असे ईमेल क्लायंट्स
• मोठ्या API रिस्पॉन्स सेट्सचं कॅशिंग — उदाहरणार्थ, हजारो टास्क्स कॅश करणारं प्रोजेक्ट मॅनेजमेंट टूल जेणेकरून UI झटपट वाटेल
• फाइल्स/ब्लॉब्स क्लायंट-साइड साठवणं — इमेज एडिटर्स, PDF व्ह्यूअर्स, बायनरी डेटा हाताळणारं काहीही जे localStorage च्या स्ट्रिंग-मात्र, सुमारे ५MB मर्यादेत बसत नाही

याची किंमत अशी आहे की IndexedDB चं API कुप्रसिद्धपणे अवघड आहे — कच्च्या IndexedDB कोडमध्ये एकमेकांत गुंतलेले callbacks आणि onsuccess/onerror हँडलर्स भरलेले असतात, जे जणू 2010 सालचे वाटतात (कारण, खरंच ते तसेच आहेत). बहुतेक टीम्स Dexie.js किंवा idb सारख्या लायब्ररीने त्याभोवती आवरण घालतात जेणेकरून ते सुसह्य होईल. जर तुम्ही ते डीबग करत असाल, तर Application पॅनेलचा IndexedDB व्ह्यूअर हा DevTools मधल्या खरोखर आल्हाददायक भागांपैकी एक आहे — तुम्ही ऑब्जेक्ट स्टोअर्स विस्तारित करू शकता, रेकॉर्ड्स तपासू शकता, आणि एका ओळीचाही कोड न लिहिता संपूर्ण डेटाबेस हटवू शकता.

इतिहासातला एक रंजक भाग जो IndexedDB का जिंकलं हे स्पष्ट करतो: Chrome पूर्वी Web SQL Database लासुद्धा सपोर्ट करत असे, जे SQLite वर आधारित रिलेशनल API होतं. ते कधीच प्रमाणित (standardized) झालं नाही — फक्त Chromium ने त्याचं स्पेसिफिकेशन पूर्णपणे लागू केलं होतं — म्हणून ते Chromium 119 पासून पूर्णपणे काढून टाकण्यात आलं [6]. आता अधिकृत मार्गदर्शन असं आहे की बहुतेक प्रकरणांत Web Storage APIs किंवा IndexedDB वापरावं, आणि गंभीर रिलेशनल/परफॉर्मन्स गरजा असलेल्या अ‍ॅप्ससाठी, Origin Private File System वर चालणारं WebAssembly मध्ये कंपाइल केलेलं SQLite वापरावं [6] — आणि नेमकं हेच आपल्याला पुढच्या विभागाकडे घेऊन जातं.

Cache Storage आणि Service Workers — ऑफलाइन काम करणाऱ्या गोष्टी बनवणं

ही जोडी म्हणजे Progressive Web Apps चालवणारी ताकद आहे. service worker ही तुमच्या पेज आणि नेटवर्कमध्ये बसून रिक्वेस्ट्स अडवणारी स्क्रिप्ट आहे, आणि Cache API / Cache Storage हे ती जिथे प्रत्यक्ष रिस्पॉन्स ऑब्जेक्ट्स साठवते ती जागा आहे [7][8]. DevTools मध्ये:

• Application → Application → Service Workers इथे रजिस्ट्रेशन स्थिती, स्कोप दिसतो, आणि तुम्ही अपडेट्स ट्रिगर करू शकता, सक्तीने अ‍ॅक्टिव्हेट करू शकता, किंवा ऑफलाइन असल्याचं सिम्युलेट करू शकता [9]
• Application → Storage → Cache Storage इथे Cache API द्वारे कॅश केलेल्या प्रत्येक गोष्टीची फक्त-वाचनीय, ब्राउझ करता येणारी यादी असते — तुम्ही URL नुसार फिल्टर करून तपासू शकता आणि वैयक्तिक एंट्रीज हटवू शकता [1][7]

प्रत्यक्ष वापराचं उदाहरण: एक न्यूज साइट जिला असं हवं आहे की लेख मेट्रोमध्ये सिग्नल नसतानाही वाचता यावेत. service worker नेव्हिगेशन रिक्वेस्ट्स अडवतो, आधी Cache Storage तपासतो, आणि गरज असेल तेव्हाच नेटवर्ककडे वळतो. किंवा Twitter/X चा “तुम्ही ऑफलाइन आहात” स्क्रीन विचारात घ्या जो तरीही तुमची शेवटची लोड झालेली टाइमलाइन दाखवतो — हे काम Cache Storage करत असतं.

समजून घेण्यासारखी मुख्य संकल्पना — आणि हे मला कठीण मार्गाने डीबग करेपर्यंत स्पष्टपणे समजलं नव्हतं — ती म्हणजे Cache API ही नेहमीच्या HTTP कॅशेपेक्षा पूर्णपणे वेगळी यंत्रणा आहे. HTTP कॅश रिस्पॉन्स हेडर्स आणि ब्राउझरच्या अंदाजांवर चालते; Cache Storage API पूर्णपणे कोड-नियंत्रित आहे — काय कॅश करायचं, कधी, आणि किती काळ हे तुम्ही ठरवता [8][7]. हे शक्तिशाली आहे, पण याचा अर्थ असाही आहे की जुन्या एंट्रीज अवैध ठरवण्याची जबाबदारी तुमची आहे; HTTP कॅशेसाठी Cache-Control हेडर्सच्या आधारे जसं ब्राउझर आपोआप करतं, तसं इथे होणार नाही.

एका डीबगिंग टिपने मला एक त्रासदायक दुपार वाचवली: service worker अनरजिस्टर केल्याने त्याची कॅशेस साफ होत नाहीत. त्या स्वतंत्र असतात. जर service worker बंद केल्यानंतरही तुमचं “फिक्स” दिसत नसेल, तर Cache Storage वेगळं तपासा — किंवा फक्त Application → Storage खालचं मोठं लाल Clear storage बटण दाबा, जे एका क्लिकमध्ये service workers अनरजिस्टर करतं आणि संबंधित सर्व स्टोरेज पुसून टाकतं [9][10]. त्या एका बटणाने मला “माझा जुना कोड अजूनही का चालतोय” अशा कितीतरी डोकेदुखीतून वाचवलं आहे.

नवीन (आणि जरा विचित्र) प्रकार: OPFS, Shared Storage, आणि Storage Buckets

Application पॅनेल वाढतच चाललं आहे, कारण वेब प्लॅटफॉर्मच वाढत आहे. माहिती असायलाच हवी अशा काही नवीन एंट्रीज:

• Origin Private File System (OPFS) — एक सँडबॉक्स्ड, ओरिजिन-आधारित फाइल सिस्टम जी बाइट-स्तरावरील, उच्च-कार्यक्षमतेची फाइल अ‍ॅक्सेस देते, ज्यात Web Workers मधून सिंक्रोनस वाचन/लेखनही समाविष्ट आहे [11]. ती ब्राउझर-आतल्या SQLite (WASM द्वारे) चं आवडतं घर बनली आहे आणि RxDB व ElectricSQL सारख्या local-first प्रोजेक्ट्समध्ये वापरली जाते [11]. अडचण अशी की DevTools मध्ये अजून OPFS साठी मूळ सपोर्ट नाही — DevTools च्या आत त्याची फाइल ट्री ब्राउझ करण्यासाठी OPFS Explorer सारख्या थर्ड-पार्टी एक्स्टेंशनची गरज आहे [12].
• Shared Storage — Privacy Sandbox उपक्रमाचा भाग, जो साइट्सना क्रॉस-साइट डेटा साठवू देतो, पण तो थेट JavaScript ला उघड न करता — तुम्ही फक्त गोपनीयता-संरक्षित “worklets” मधून एकत्रित अंतर्दृष्टी काढू शकता. खऱ्याखुऱ्या वापराच्या उदाहरणांत जाहिरात मोहिमेच्या अद्वितीय पोहोचीचं मोजमाप करणं किंवा थर्ड-पार्टी कुकीजवर अवलंबून न राहता क्रिएटिव्हज फिरवणं यांचा समावेश आहे [13]. कच्च्या की-व्हॅल्यू जोड्या तुम्ही Application → Storage → Shared Storage इथे पाहू शकता [1][13].
• Storage Buckets — एक उदयोन्मुख API जे तुम्हाला एका ओरिजिनच्या स्टोरेजचे स्वतंत्र कोटा आणि टिकून राहण्याचं वर्तन असलेल्या वेगळ्या “buckets” मध्ये विभाजन करू देतं, त्यामुळे तुम्ही, उदाहरणार्थ, महत्त्वाच्या ऑफलाइन डेटाचा एक bucket persistent म्हणून चिन्हांकित करू शकता, तर वापरून-फेकून देण्याजोग्या कॅश डेटाचा bucket दबावाखाली आधी काढून टाकला जाऊ शकतो [14].

ad-tech किंवा जड ऑफलाइन-फर्स्ट अ‍ॅप्स बनवत नसाल, तर यापैकी बहुतेक गोष्टींना तुम्ही रोजच्या रोज हात लावणार नाही — पण साइडबारमध्ये एखादी अनोळखी एंट्री दिसून ती काय करते असा प्रश्न पडल्यास, या गोष्टी अस्तित्वात आहेत हे माहीत असणं उपयोगी ठरतं.

Extension Storage — DevTools मधून chrome.storage डीबग करणं

जर तुम्ही Chrome एक्स्टेंशन बनवत किंवा डीबग करत असाल, तर ही एक लपलेली सुविधा आहे. Application → Storage → Extension Storage अंतर्गत, DevTools प्रत्येक इन्स्टॉल केलेल्या एक्स्टेंशनला त्याच्या chrome.storage.local आणि chrome.storage.sync डेटासह तपासण्यायोग्य, संपादन करता येण्याजोग्या की-व्हॅल्यू जोड्या म्हणून सूचीबद्ध करतो [17].

दोन स्टोरेज क्षेत्रे खूप वेगळ्या प्रकारे वागतात. chrome.storage.local सध्याच्या मशीनवर डेटा साठवतो. chrome.storage.sync असा डेटा लिहितो जो Chrome वापरकर्ता साइन इन असलेल्या प्रत्येक डिव्हाइसवर आपोआप सिंक करतो [18]. DevTools पॅनेलचा खरा फायदा: कोणत्याही की वर क्लिक करून व्हॅल्यू थेट संपादित करा आणि तुमचं एक्स्टेंशन वेगळ्या साठवलेल्या स्थितींना कसा प्रतिसाद देतो हे लगेच तपासा.

Storage Buckets — ब्राउझरला आधी काय फेकायचं ते सांगणं

Storage Buckets API हे Chromium चं एका वास्तविक प्रोडक्शन समस्येवरील उत्तर आहे: स्टोरेज प्रेशरमुळे होणारी हकालपट्टी ओरिजिनसाठी all-or-nothing असते. Storage Buckets हे वेगळ्या कोटा मर्यादा, हकालपट्टीची प्राथमिकता आणि टिकण्याचे फ्लॅग असलेल्या नामांकित buckets मध्ये स्टोरेजचं विभाजन करून हे ठीक करतात [14].

const criticalBucket = await navigator.storageBuckets.open("user-docs", {
  durability: "strict",
  persisted: true,
});
const cacheBucket = await navigator.storageBuckets.open("temp-cache", {
  durability: "relaxed",
  persisted: false,
});

user-docs bucket strict + persisted: true म्हणून चिन्हांकित आहे — ब्राउझर दबावाखाली त्याला हात लावणार नाही. temp-cache relaxed + persisted: false आहे — हकालपट्टीसाठी उचित. Application → Storage → Storage Buckets मध्ये तुम्ही प्रत्येक नामांकित bucket तपासू शकता आणि तुमच्या टिकण्याच्या सेटिंग्ज अपेक्षेप्रमाणे आहेत का ते पाहू शकता [14].

Private State Tokens — पाळत न ठेवता फसवणूकविरोधी

Private State Tokens (पूर्वी Trust Tokens) एक Privacy Sandbox API आहे जे एखाद्या जारीकर्त्याला — उदाहरणार्थ, एखादी साइट जी आधीच जाणते की तुम्ही खरी व्यक्ती आहात — तुमच्या ओळखी जोडल्याशिवाय किंवा क्रॉस-साइट ट्रॅकिंग न करता दुसऱ्या साइटवर तुमची हमी देऊ देते [19].

Application → Storage → Private State Tokens मध्ये, DevTools दाखवतो की कोणत्या जारीकर्त्यांनी सध्याच्या ब्राउझर प्रोफाइलमध्ये टोकन साठवले आहेत आणि प्रत्येक जारीकर्त्याकडे किती टोकन शिल्लक आहेत. Network पॅनेल वैयक्तिक जारी करणे आणि रिडेम्पशन विनंत्याही नोंद करतो [19]. थर्ड-पार्टी कुकीजपासून दूर गेलेली एखादी फसवणूकविरोधी किंवा बॉट-डिटेक्शन सेवा एकत्रित करताना तुम्हाला या गोष्टी भेटतील.

Interest Groups — ब्राउझर स्वतःची जाहिरात लिलाव कशी चालवतो

Interest Groups हे Protected Audience API (पूर्वी FLEDGE) चा भाग आहेत. थर्ड-पार्टी कुकीजऐवजी, ब्राउझर स्वतः तुम्हाला स्थानिक पातळीवर interest groups मध्ये सामील करतो आणि डिव्हाइसवर बोली लावण्याची लिलाव चालवतो [20]. तुमचा ब्राउझिंग इतिहास कधीच तुमच्या मशीनबाहेर जात नाही.

Application → Storage → Interest Groups मध्ये DevTools सध्याच्या पेजने तुमच्या ब्राउझरला सामील होण्यास सांगितलेल्या प्रत्येक interest group दाखवतो, ज्यात मालक, बिडिंग लॉजिक URL आणि त्या गटाशी संबंधित जाहिरातींची यादी समाविष्ट आहे [20]. इव्हेंट टाइमलाइन joined, bid, win, आणि leave इव्हेंट नोंद करते. एक व्यावहारिक टीप: पेज लोड झाल्यानंतर Application पॅनेल उघडल्यास join इव्हेंट दिसणार नाहीत — DevTools आधीच उघडे ठेवून पेज रिफ्रेश करा [20].

कोटा, हकालपट्टी, आणि तुमचा डेटा कधीकधी का… नाहीसा होतो

कधी एखाद्या वापरकर्त्याने “माझा डेटा गायब झाला” अशी तक्रार केली आणि तुम्हाला कारण कळलं नाही? सहसा याचं उत्तर हे आहे: स्टोरेज अमर्याद नसते, आणि ब्राउझरला जो डेटा आवश्यक नाही असं वाटतं, तो तो काढून टाकतो.

Chromium-आधारित ब्राउझर्स साधारणपणे एका ओरिजिनच्या स्टोरेजला एकूण डिस्क जागेच्या ठराविक टक्केवारीपर्यंत मर्यादित ठेवतात — आणि नेमकी ही मर्यादा त्या ओरिजिनला “persistent” स्टोरेज दिलं गेलं आहे की ते “best-effort” मोडमध्ये कार्यरत आहे, यावर अवलंबून असते [15]. best-effort मोडमध्ये, जेव्हा ब्राउझरवर स्टोरेजचा दबाव येतो, तेव्हा तो सर्वात आधी सर्वात कमी वापरलेले ओरिजिन्स काढून टाकायला सुरुवात करतो — आणि ज्या ओरिजिनने navigator.storage.persist() कॉल केलं आहे आणि ज्याला persistence मंजूर झालं आहे, त्याला तो वगळतो [15].

navigator.storage.estimate() या API द्वारे तुम्ही तुमचं अ‍ॅप नेमकं कुठे उभं आहे हे तपासू शकता, जे तुमचा सध्याचा usage आणि quota दोन्ही परत देतं — आणि उपकरणावर प्रत्यक्षात किती मोकळी डिस्क जागा आहे यानुसार ही दोन्ही बदलत राहतात [16]. आणि DevTools मध्ये, Application → Storage चं विहंगावलोकन तुमच्या ओरिजिनचा कोटा cookies, IndexedDB, cache storage वगैरेमध्ये कसा विभागला आहे, याचा एक pie chart अक्षरशः काढून दाखवतं [1] — शिवाय एक स्लायडर देखील आहे ज्याद्वारे तुम्ही लहान कोटा सिम्युलेट करू शकता, जे प्रत्यक्ष वापरकर्त्याला त्या भिंतीवर आदळण्याआधीच, स्टोरेज कमी पडल्यावर तुमचं अ‍ॅप कसं वागतं हे तपासण्यासाठी अप्रतिम आहे.

स्टोरेज विचित्रपणे वागत असेल तेव्हा मी पाळत असलेली प्रत्यक्ष डीबगिंग यादी:

1. Application → Storage उघडा आणि वापराचा pie chart पाहा — एखादा स्टोरेज प्रकार अनपेक्षितरित्या मोठा झालाय का?
2. ओरिजिनला persistence मंजूर झालं आहे का ते तपासा (navigator.storage.persisted()) — नसेल, तर दबावाखाली हकालपट्टी होणं स्वाभाविक आहे
3. कमी-स्टोरेज परिस्थिती सिम्युलेट करण्यासाठी कोटा override स्लायडर वापरा आणि काय बिघडतं ते पाहा
4. स्वच्छ सुरुवातीसाठी Clear storage दाबा, आणि सुरुवातीपासून समस्या पुन्हा घडवून आणा
5. service-worker च्या समस्यांसाठी विशेषतः, Cache Storage आणि Service Workers दोन्ही वेगळी तपासा — एक साफ केल्याने दुसरी साफ होत नाही [9]

मग नेमकं काय निवडावं?

क्लायंटवर काही लक्षात ठेवावं लागणारं नवीन फीचर सुरू करताना मी प्रत्यक्षात वापरतो ती निर्णय-चौकट इथे आहे:

• प्रत्येक रिक्वेस्टवर सर्व्हरला हे वाचण्याची गरज आहे का? → कुकी. इतर कशालाच आपोआप पाठवलं जात नाही [2].
• ते लहान आहे (काही KB), साधं की-व्हॅल्यू आहे, आणि टॅबपेक्षा जास्त काळ टिकायला हवं? → localStorage.
• ते लहान, साधं आहे, आणि टॅब बंद झाल्यावर नष्ट व्हायला हवं? → sessionStorage.
• ते स्ट्रक्चर्ड, मोठं, बायनरी आहे, किंवा त्याला क्वेरींग/इंडेक्सिंगची गरज आहे? → IndexedDB (शक्यतो Dexie किंवा idb मध्ये गुंडाळलेलं).
• तुम्ही ऑफलाइन वापरासाठी नेटवर्क रिस्पॉन्सेस कॅश करत आहात का? → service worker द्वारे चालवली जाणारी Cache Storage.
• तुम्हाला खरीखुरी फाइल सिस्टम किंवा ब्राउझर-आतला SQL डेटाबेस हवा आहे का? → OPFS, बहुधा SQLite-WASM सोबत [6][11].
• वापरकर्त्याच्या गोपनीयतेला धक्का न लावता क्रॉस-साइट मोजमाप करायचं आहे का? → Shared Storage [13].
• स्टोरेज हकालपट्टीतून वाचायला हवा असा महत्त्वाचा डेटा आहे का? → persisted: true सह Storage Buckets [14].
• Chrome एक्स्टेंशन बनवत किंवा डीबग करत आहात का? → Extension Storage (chrome.storage.local / chrome.storage.sync) [17][18].
• Privacy Sandbox सोबत ad-tech काम करत आहात का? → Private State Tokens (फसवणूकविरोधी सिग्नल) आणि Interest Groups (ऑन-डिव्हाइस जाहिरात लिलाव) [19][20].

बाय द वे, हे एकमेकांना वगळणारे पर्याय नाहीत — बहुतेक गंभीर वेब अ‍ॅप्स यापैकी अनेक एकाच वेळी वापरतात. एखादं PWA ऑथसाठी कुकीज, थीम प्राधान्यांसाठी localStorage, ऑफलाइन कंटेंटसाठी IndexedDB, आणि अ‍ॅप शेलसाठी Cache Storage — हे सगळं एकाच वेळी वापरू शकतं. Application पॅनेल हेच ते टूल आहे जे तुम्हाला हे सगळं एकाच जागी, एकत्र, एकही डीबग console.log न लिहिता काम करताना (किंवा न करताना) पाहू देतं.

पुढच्या वेळी एखादी गोष्ट “नुसती सेव्हच होत नाहीये” असं वाटलं, तर अंदाज बांधत बसू नका — DevTools उघडा, Application वर क्लिक करा, आणि प्रत्यक्ष पाहा. दहांपैकी नऊ वेळा, उत्तर तिथेच, उघड्या डोळ्यांसमोर असतं.

Sources

1. Application panel overview | Chrome DevTools | Chrome for Developers
2. Browser Storage Explained: LocalStorage vs SessionStorage vs IndexedDB vs Cookies - DEV Community
3. Third-Party Cookie Deprecation Testing and Debugging - Chromium
4. Third-Party Cookie Deprecation: The 2026 Guide | Ethyca
5. 9 differences between IndexedDB and LocalStorage - DEV Community
6. Deprecating and removing Web SQL | Blog | Chrome for Developers
7. CacheStorage - Web APIs | MDN
8. Service workers and the Cache Storage API | Articles | web.dev
9. Debug Progressive Web Apps | Chrome DevTools | Chrome for Developers
10. Tips and Tricks for Debugging Service Workers
11. The origin private file system | Articles | web.dev
12. OPFS Explorer - Chrome DevTools extension - GitHub
13. Shared Storage overview | Privacy Sandbox | Chrome for Developers
14. Not all storage is created equal: introducing Storage Buckets | Blog | Chrome for Developers
15. Storage quotas and eviction criteria - Web APIs | MDN
16. Estimating Available Storage Space | Blog | Chrome for Developers
17. View and edit extension storage | Chrome DevTools | Chrome for Developers
18. chrome.storage API Reference | Chrome for Developers
19. Private State Tokens | Privacy Sandbox | Chrome for Developers
20. Protected Audience API overview | Privacy Sandbox | Chrome for Developers