वेब के लिए स्टोरेज

ब्राउज़र में डेटा सेव करने के लिए कई अलग-अलग विकल्प मौजूद हैं. आपकी ज़रूरतों के हिसाब से कौनसा प्लान सबसे सही है?

Pete LePage

सफ़र के दौरान इंटरनेट कनेक्शन खराब हो सकता है या पूरी तरह से बंद हो सकता है. इसलिए, ऑफ़लाइन मोड में काम करना और भरोसेमंद परफ़ॉर्मेंस, प्रोग्रेसिव वेब ऐप्लिकेशन की सामान्य सुविधाएं हैं. बेहतरीन वायरलेस नेटवर्क वाले माहौल में भी, कैश मेमोरी और अन्य स्टोरेज तकनीकों का सही इस्तेमाल करके, उपयोगकर्ता अनुभव को काफ़ी बेहतर बनाया जा सकता है. अपने स्टैटिक ऐप्लिकेशन के रिसॉर्स (एचटीएमएल, JavaScript, सीएसएस, इमेज वगैरह) और डेटा (उपयोगकर्ता का डेटा, समाचार रिपोर्ट वगैरह) को कैश मेमोरी में सेव करने के कई तरीके हैं. हालांकि, इनमें से सबसे सही तरीका कौनसा है? कितना डेटा सेव किया जा सकता है? इसे निकाले जाने से कैसे रोका जा सकता है?

मुझे किसका इस्तेमाल करना चाहिए?

संसाधनों को सेव करने के लिए, यहां एक सामान्य सुझाव दिया गया है:

IndexedDB, OPFS, और Cache Storage API, हर मॉडर्न ब्राउज़र पर काम करते हैं. ये एसिंक्रोनस होते हैं और मुख्य थ्रेड को ब्लॉक नहीं करते. हालांकि, OPFS का एक सिंक्रोनस वैरिएंट भी होता है, जो सिर्फ़ वेब वर्कर में उपलब्ध होता है. इन्हें window ऑब्जेक्ट, वेब वर्कर, और सर्विस वर्कर से ऐक्सेस किया जा सकता है. इससे इन्हें आपके कोड में कहीं भी इस्तेमाल किया जा सकता है.

स्टोरेज के अन्य तरीकों के बारे में क्या?

ब्राउज़र में स्टोरेज के कई अन्य तरीके उपलब्ध हैं. हालांकि, उनका इस्तेमाल सीमित है और उनसे परफ़ॉर्मेंस की समस्या हो सकती हैं.

SessionStorage, टैब के हिसाब से होता है और यह टैब के बंद होने तक ही काम करता है. यह सेशन से जुड़ी कम जानकारी को सेव करने के लिए मददगार हो सकता है. उदाहरण के लिए, IndexedDB कुंजी. इसका इस्तेमाल सावधानी से किया जाना चाहिए, क्योंकि यह सिंक्रोनस है और मुख्य थ्रेड को ब्लॉक कर देगा. यह करीब 5 एमबी तक सीमित है और इसमें सिर्फ़ स्ट्रिंग हो सकती हैं. यह टैब के हिसाब से होता है, इसलिए इसे वेब वर्कर या सर्विस वर्कर से ऐक्सेस नहीं किया जा सकता.

LocalStorage का इस्तेमाल करने से बचना चाहिए, क्योंकि यह सिंक्रोनस है और मुख्य थ्रेड को ब्लॉक कर देगा. यह करीब 5 एमबी तक सीमित है और इसमें सिर्फ़ स्ट्रिंग हो सकती हैं. LocalStorage को वेब वर्कर या सर्विस वर्कर से ऐक्सेस नहीं किया जा सकता.

कुकी के अपने इस्तेमाल होते हैं, लेकिन इनका इस्तेमाल स्टोरेज के लिए नहीं किया जाना चाहिए. कुकी, हर एचटीटीपी अनुरोध के साथ भेजी जाती हैं. इसलिए, डेटा की थोड़ी सी मात्रा से ज़्यादा कुछ भी सेव करने से, हर वेब अनुरोध का साइज़ काफ़ी बढ़ जाएगा. ये सिंक्रोनस होते हैं और इन्हें वेब वर्कर से ऐक्सेस नहीं किया जा सकता. LocalStorage और SessionStorage की तरह, कुकी भी सिर्फ़ स्ट्रिंग तक सीमित होती हैं.

File System Access API को इसलिए डिज़ाइन किया गया था, ताकि उपयोगकर्ता अपने लोकल फ़ाइल सिस्टम में मौजूद फ़ाइलों को पढ़ सकें और उनमें बदलाव कर सकें. किसी पेज को किसी लोकल फ़ाइल को पढ़ने या उसमें बदलाव करने से पहले, उपयोगकर्ता से अनुमति लेनी होगी. साथ ही, सेशन के दौरान दी गई अनुमतियां सेव नहीं रहतीं. हालांकि, अगर IndexedDB में फ़ाइल हैंडल को कैश मेमोरी में सेव किया गया है, तो अनुमतियां सेव रहती हैं. File System Access API का इस्तेमाल, एडिटर जैसे मामलों के लिए सबसे सही है. इसमें आपको कोई फ़ाइल खोलनी होती है, उसमें बदलाव करना होता है, और फिर बदलावों को फ़ाइल में सेव करना होता है.

File System API और FileWriter API, सैंडबॉक्स किए गए फ़ाइल सिस्टम में फ़ाइलों को पढ़ने और लिखने के तरीके उपलब्ध कराते हैं. हालांकि, यह एसिंक्रोनस है, लेकिन इसका इस्तेमाल करने का सुझाव नहीं दिया जाता. इसकी वजह यह है कि यह सिर्फ़ Chromium कोड वाले ब्राउज़र में उपलब्ध है.

कितना डेटा सेव किया जा सकता है?

कम शब्दों में कहें, तो बहुत ज़्यादा. कम से कम कुछ सौ मेगाबाइट और शायद सैकड़ों गीगाबाइट या इससे ज़्यादा. ब्राउज़र के हिसाब से, स्टोरेज की क्षमता अलग-अलग होती है. हालांकि, आम तौर पर स्टोरेज की क्षमता, डिवाइस पर उपलब्ध स्टोरेज के हिसाब से तय होती है.

  • Chrome, ब्राउज़र को डिस्क में बचे कुल स्टोरेज का 80% तक इस्तेमाल करने की अनुमति देता है. कोई ऑरिजिन, डिस्क में बचे कुल स्टोरेज का 60% तक इस्तेमाल कर सकता है. StorageManager API का इस्तेमाल करके, यह पता लगाया जा सकता है कि आपके पास ज़्यादा से ज़्यादा कितना कोटा उपलब्ध है. Chromium पर आधारित अन्य ब्राउज़र अलग हो सकते हैं.
    • गुप्त मोड में, Chrome किसी ऑरिजिन के लिए स्टोरेज की सीमा को कम कर देता है. यह सीमा, डिस्क में बचे कुल स्टोरेज के करीब 5% तक होती है.
    • अगर उपयोगकर्ता ने Chrome में "सभी विंडो बंद करने पर, कुकी और साइट डेटा मिटाएं" सेटिंग चालू की है, तो स्टोरेज कोटा काफ़ी कम हो जाता है. यह ज़्यादा से ज़्यादा 300 एमबी तक हो सकता है.
  • Firefox, ब्राउज़र को डिस्क में बचा स्टोरेज का 50% तक इस्तेमाल करने की अनुमति देता है. eTLD+1 ग्रुप (जैसे, example.com, www.example.com, और foo.bar.example.com) ज़्यादा से ज़्यादा 2 जीबी स्टोरेज का इस्तेमाल कर सकता है. StorageManager API का इस्तेमाल करके, यह पता लगाया जा सकता है कि अब भी कितनी जगह उपलब्ध है.
  • Safari (डेस्कटॉप और मोबाइल, दोनों) में करीब 1 जीबी तक डेटा सेव किया जा सकता है. सीमा पूरी होने पर, Safari उपयोगकर्ता को सूचना देगा और सीमा को 200 एमबी तक बढ़ा देगा. मुझे इस बारे में कोई आधिकारिक दस्तावेज़ नहीं मिला.
    • अगर मोबाइल Safari पर होम स्क्रीन में कोई PWA जोड़ा जाता है, तो वह एक नया स्टोरेज कंटेनर बनाता है. साथ ही, PWA और मोबाइल Safari के बीच कुछ भी शेयर नहीं किया जाता. इंस्टॉल किए गए किसी पीडब्ल्यूए के लिए कोटा पूरा होने के बाद, ज़्यादा स्टोरेज का अनुरोध करने का कोई तरीका नहीं दिखता.

पहले, अगर कोई साइट डेटा सेव करने की तय सीमा को पार कर जाती थी, तो ब्राउज़र उपयोगकर्ता को ज़्यादा डेटा इस्तेमाल करने की अनुमति देने के लिए कहता था. उदाहरण के लिए, अगर ऑरिजिन ने 50 एमबी से ज़्यादा स्टोरेज का इस्तेमाल किया है, तो ब्राउज़र उपयोगकर्ता से 100 एमबी तक का डेटा सेव करने की अनुमति मांगेगा. इसके बाद, 50 एमबी की बढ़ोतरी होने पर फिर से अनुमति मांगेगा.

आज के समय में, ज़्यादातर मॉडर्न ब्राउज़र उपयोगकर्ता को सूचना नहीं देते हैं. साथ ही, वे किसी साइट को उसके लिए तय किए गए कोटे तक का इस्तेमाल करने की अनुमति देते हैं. Safari इसका अपवाद है. यह स्टोरेज कोटा खत्म होने पर सूचना देता है और तय किए गए कोटे को बढ़ाने की अनुमति मांगता है. अगर कोई ऑरिजिन, अपने लिए तय किए गए कोटे से ज़्यादा स्टोरेज का इस्तेमाल करने की कोशिश करता है, तो डेटा सेव करने की आगे की कोशिशें नाकाम हो जाएंगी.

मैं यह कैसे देखूं कि मेरे खाते में कितना स्टोरेज उपलब्ध है?

कई ब्राउज़र में, StorageManager API का इस्तेमाल करके यह पता लगाया जा सकता है कि ऑरिजिन के लिए कितना स्टोरेज उपलब्ध है और वह कितने स्टोरेज का इस्तेमाल कर रहा है. यह IndexedDB और Cache API के इस्तेमाल किए गए कुल बाइट की जानकारी देता है. साथ ही, इससे बचे हुए स्टोरेज का अनुमान लगाया जा सकता है.

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

आपको कोटा से ज़्यादा इस्तेमाल करने की वजह से होने वाली गड़बड़ियों को पकड़ना होगा (नीचे देखें). कुछ मामलों में, ऐसा हो सकता है कि उपलब्ध कोटा, असल में उपलब्ध स्टोरेज से ज़्यादा हो.

जांच करें

डेवलपमेंट के दौरान, अपने ब्राउज़र के DevTools का इस्तेमाल करके, अलग-अलग तरह के स्टोरेज की जांच की जा सकती है. साथ ही, सेव किए गए सभी डेटा को मिटाया जा सकता है.

Chrome 88 में एक नई सुविधा जोड़ी गई है. इसकी मदद से, स्टोरेज पैनल में साइट के स्टोरेज कोटे को बदला जा सकता है. इस सुविधा की मदद से, अलग-अलग डिवाइसों को सिम्युलेट किया जा सकता है. साथ ही, डिस्क में कम स्टोरेज होने पर, अपने ऐप्लिकेशन के काम करने के तरीके की जांच की जा सकती है. Application और फिर Storage पर जाएं. इसके बाद, Simulate custom storage quota चेकबॉक्स को चालू करें और स्टोरेज कोटा को सिम्युलेट करने के लिए कोई मान्य नंबर डालें.

कोटा खत्म होने पर क्या करें?

तय सीमा से ज़्यादा स्टोरेज इस्तेमाल करने पर आपको क्या करना चाहिए? सबसे ज़रूरी बात यह है कि आपको डेटा लिखने से जुड़ी गड़बड़ियों को हमेशा पकड़ना और ठीक करना चाहिए. भले ही, वह QuotaExceededError हो या कुछ और. इसके बाद, अपने ऐप्लिकेशन के डिज़ाइन के हिसाब से तय करें कि इसे कैसे मैनेज करना है. उदाहरण के लिए, ऐसा कॉन्टेंट मिटाएं जिसे लंबे समय से ऐक्सेस नहीं किया गया है, साइज़ के हिसाब से डेटा हटाएं या उपयोगकर्ताओं को यह चुनने का विकल्प दें कि उन्हें क्या मिटाना है.

कोटा खत्म होने पर, IndexedDB और Cache API, दोनों DOMError नाम का QuotaExceededError दिखाते हैं.

IndexedDB

अगर ऑरिजिन ने अपना कोटा पार कर लिया है, तो IndexedDB में डेटा सेव करने की कोशिशें नाकाम हो जाएंगी. लेन-देन के onabort() हैंडलर को कॉल किया जाएगा और एक इवेंट पास किया जाएगा. इवेंट में, गड़बड़ी की प्रॉपर्टी में DOMException शामिल होगा. गड़बड़ी name की जांच करने पर, QuotaExceededError दिखेगा.

const transaction = idb.transaction(['entries'], 'readwrite');
transaction.onabort = function(event) {
  const error = event.target.error; // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
};

Cache API

अगर ऑरिजिन ने अपना कोटा पार कर लिया है, तो Cache API में डेटा सेव करने की कोशिशों को QuotaExceededError DOMException के साथ अस्वीकार कर दिया जाएगा.

try {
  const cache = await caches.open('my-cache');
  await cache.add(new Request('/sample1.jpg'));
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}

किरायेदार को निकालने की प्रक्रिया कैसे काम करती है?

वेब स्टोरेज को दो कैटगरी में बांटा गया है, "बेस्ट एफ़र्ट" और "पर्सिस्टेंट". 'बेस्ट एफ़र्ट' का मतलब है कि ब्राउज़र, उपयोगकर्ता को बिना बताए स्टोरेज को खाली कर सकता है. हालांकि, यह लंबे समय तक या ज़रूरी डेटा को सेव रखने के लिए कम भरोसेमंद है. स्टोरेज कम होने पर, परसिस्टेंट स्टोरेज अपने-आप खाली नहीं होता. उपयोगकर्ता को ब्राउज़र सेटिंग में जाकर, इस स्टोरेज को मैन्युअल तरीके से खाली करना होगा.

डिफ़ॉल्ट रूप से, किसी साइट का डेटा (IndexedDB, Cache API वगैरह) 'बेस्ट एफ़र्ट' कैटगरी में आता है. इसका मतलब है कि जब तक कोई साइट परसिस्टेंट स्टोरेज का अनुरोध नहीं करती, तब तक ब्राउज़र अपने हिसाब से साइट का डेटा हटा सकता है. उदाहरण के लिए, डिवाइस का स्टोरेज कम होने पर.

बेस्ट एफ़र्ट के लिए, हटाने की नीति यह है:

  • Chromium पर आधारित ब्राउज़र, स्टोरेज भर जाने पर डेटा को हटाना शुरू कर देंगे. इसके लिए, वे सबसे पहले उस ऑरिजिन से साइट का सारा डेटा मिटाएंगे जिसका इस्तेमाल हाल ही में सबसे कम किया गया है. इसके बाद, वे अगले ऑरिजिन से डेटा मिटाएंगे. ऐसा तब तक किया जाएगा, जब तक ब्राउज़र में स्टोरेज की तय सीमा से ज़्यादा डेटा मौजूद रहेगा.
  • डिस्क में बचा स्टोरेज भर जाने पर, Firefox डेटा को हटाना शुरू कर देगा. यह सबसे पहले उस ऑरिजिन का सारा साइट डेटा मिटाएगा जिसका इस्तेमाल हाल ही में सबसे कम किया गया है. इसके बाद, यह अगले ऑरिजिन का डेटा मिटाएगा. यह प्रोसेस तब तक चलती रहेगी, जब तक ब्राउज़र में तय सीमा से ज़्यादा डेटा मौजूद रहेगा.
  • पहले, Safari डेटा को नहीं हटाता था. हालांकि, हाल ही में उसने डेटा सेव करने की सुविधा देने वाले सभी स्टोरेज के लिए, सात दिन की नई सीमा लागू की है (नीचे देखें).

iOS और iPadOS 13.4 और macOS पर Safari 13.1 से, स्क्रिप्ट से लिखे जा सकने वाले सभी स्टोरेज पर सात दिन की सीमा लागू होती है. इसमें IndexedDB, सर्विस वर्कर रजिस्ट्रेशन, और Cache API शामिल हैं. इसका मतलब है कि अगर उपयोगकर्ता साइट से इंटरैक्ट नहीं करता है, तो Safari का इस्तेमाल करने के सात दिनों बाद, Safari कैश मेमोरी से सारा कॉन्टेंट हटा देगा. यह नीति, इंस्टॉल किए गए उन पीडब्ल्यूए पर लागू नहीं होती जिन्हें होम स्क्रीन पर जोड़ा गया है. पूरी जानकारी के लिए, WebKit ब्लॉग पर तीसरे पक्ष की कुकी को पूरी तरह से ब्लॉक करना और अन्य जानकारी देखें.

स्टोरेज बकेट

Storage Buckets API का मुख्य मकसद, साइटों को कई स्टोरेज बकेट बनाने की सुविधा देना है. इससे ब्राउज़र, हर बकेट को अन्य बकेट से अलग मिटा सकता है. इससे डेवलपर, डेटा को हटाने की प्राथमिकता तय कर सकते हैं, ताकि सबसे अहम डेटा न मिटे.

बोनस: IndexedDB के लिए रैपर का इस्तेमाल क्यों करें

IndexedDB एक लो लेवल एपीआई है. इसका इस्तेमाल करने से पहले, इसे सेटअप करना ज़रूरी है. कम जटिलता वाले डेटा को सेव करने के लिए, यह काफ़ी मुश्किल हो सकता है. प्रॉमिस पर आधारित ज़्यादातर आधुनिक एपीआई के उलट, यह इवेंट पर आधारित होता है. IndexedDB के लिए idb जैसे प्रॉमिस रैपर, कुछ बेहतरीन सुविधाओं को छिपा देते हैं. हालांकि, इससे भी ज़्यादा ज़रूरी बात यह है कि वे IndexedDB लाइब्रेरी के साथ आने वाली जटिल मशीनरी (जैसे, लेन-देन, स्कीमा वर्शनिंग) को छिपा देते हैं.

बोनस: SQLite Wasm

वेब एसक्यूएल की सुविधा बंद होने और Chrome से हटाए जाने के बाद, Google ने SQLite डेटाबेस के मेंटेनर के साथ मिलकर काम किया, ताकि SQLite पर आधारित वेब एसक्यूएल का विकल्प उपलब्ध कराया जा सके. इसे इस्तेमाल करने के तरीके के बारे में जानने के लिए, ओरिजिन प्राइवेट फ़ाइल सिस्टम की मदद से ब्राउज़र में SQLite Wasm लेख पढ़ें.

नतीजा

अब सीमित स्टोरेज और उपयोगकर्ता को ज़्यादा से ज़्यादा डेटा सेव करने के लिए कहने के दिन चले गए हैं. साइटें, काम करने के लिए ज़रूरी सभी संसाधनों और डेटा को सेव कर सकती हैं. StorageManager API का इस्तेमाल करके, यह पता लगाया जा सकता है कि आपके पास कितना स्टोरेज उपलब्ध है और आपने कितना स्टोरेज इस्तेमाल किया है. परसिस्टेंट स्टोरेज की मदद से, डेटा को हटाया नहीं जा सकता. हालांकि, उपयोगकर्ता उसे हटा सकता है.

अन्य संसाधन

धन्यवाद

इस गाइड की समीक्षा करने के लिए, जैरिड गुडमैन, फ़िल वॉल्टन, ईजी कितामुरा, डैनियल मर्फ़ी, डार्विन हुआंग, जोश बेल, मैरिन क्रुइसलब्रिंक, और विक्टर कोस्टान को खास तौर पर धन्यवाद. एजी कितामुरा, एडी ओस्मानी, और मार्क कोहेन को धन्यवाद, जिन्होंने ओरिजनल लेख लिखे. यह लेख उन्हीं पर आधारित है. ईजी ने ब्राउज़र स्टोरेज अब्यूज़र नाम का एक मददगार टूल बनाया. यह टूल, मौजूदा व्यवहार की पुष्टि करने में काम आया. इसकी मदद से, ज़्यादा से ज़्यादा डेटा सेव किया जा सकता है. साथ ही, अपने ब्राउज़र पर स्टोरेज की सीमाएं देखी जा सकती हैं. फ़्रांसवा बोफ़ोर को धन्यवाद, जिन्होंने Safari की स्टोरेज सीमाओं का पता लगाया. साथ ही, थॉमस स्टाइनर को धन्यवाद, जिन्होंने ओरिजन प्राइवेट फ़ाइल सिस्टम, स्टोरेज बकेट, SQLite Wasm के बारे में जानकारी जोड़ी और 2024 में कॉन्टेंट को अपडेट किया.