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

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

Pete LePage

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

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

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

• आपके ऐप्लिकेशन और फ़ाइल-आधारित कॉन्टेंट को लोड करने के लिए ज़रूरी नेटवर्क संसाधनों के लिए, cache Storage API का इस्तेमाल करें (इसका हिस्सा सर्विस वर्कर).
• दूसरे डेटा के लिए, IndexedDB का इस्तेमाल करें (एक प्रॉमिस रैपर).

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

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

ब्राउज़र में स्टोरेज बढ़ाने के कई और तरीके भी उपलब्ध हैं, लेकिन कम इस्तेमाल होता है और इसकी वजह से परफ़ॉर्मेंस से जुड़ी गंभीर समस्याएं हो सकती हैं.

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

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

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

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

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

WebSQL का इस्तेमाल नहीं किया जाना चाहिए. साथ ही, मौजूदा इस्तेमाल को इस पर माइग्रेट किया जाना चाहिए IndexedDB. करीब सभी प्रमुख देशों/इलाकों से सहायता टीम को हटा दिया गया है ब्राउज़र खोलें. साल 2010 में, W3C ने Web SQL की खास बातों का रखरखाव करना बंद कर दिया, आने वाले समय में अपडेट करने की कोई योजना नहीं है.

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

कितना स्टोरेज सेव किया जा सकता है?

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

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

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

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

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

कई ब्राउज़र में, स्टोरेज की मात्रा तय करने के लिए, StorageManager API ऑरिजिन के लिए उपलब्ध है और कितना स्टोरेज इस्तेमाल कर रहा है. यह कुल IndexedDB और कैश 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.`);
}

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

ध्यान दें: उपलब्ध कोटा रिपोर्ट करते समय, Chromium का इस्तेमाल करने वाले अन्य ब्राउज़र, खाली जगह की समयावधि पर असर डाल सकते हैं. Chrome ऐसा नहीं करता और हमेशा डिस्क के असली साइज़ का 60% हिस्सा रिपोर्ट करता है. इससे, सेव किए गए क्रॉस ऑरिजिन रिसॉर्स का साइज़ तय करने की सुविधा को कम करने में मदद मिलती है.

जांच करें

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

Chrome 88 में एक नई सुविधा जोड़ी गई है. इसका इस्तेमाल करके, साइट का स्टोरेज बदला जा सकता है स्टोरेज पेन में कोटा. इस सुविधा की मदद से, आपको अपने मौजूदा साथ ही, इस बात की भी जांच करें कि डिस्क में कम स्टोरेज इस्तेमाल होने पर आपके ऐप्लिकेशन कैसे काम करते हैं . ऐप्लिकेशन पर जाएं, फिर स्टोरेज पर जाएं. इसके बाद, कस्टम स्टोरेज कोटा को सिम्युलेट करें चेकबॉक्स को चुनकर, कोई भी मान्य संख्या डालें को सिम्युलेट करने के लिए किया जा सकता है.

इस लेख पर काम करते समय, मैंने इसके लिए एक आसान टूल लिखा जितना हो सके उतना स्टोरेज तेज़ी से इस्तेमाल करने की कोशिश करें. यह एक तेज़ और आसान तरीका है जिससे अलग-अलग स्टोरेज तरीकों से एक्सपेरिमेंट किया जा सके. साथ ही, यह देखा जा सके कि क्या होता है आप अपना पूरा कोटा इस्तेमाल करते हैं.

कोटा से ज़्यादा स्टोरेज को मैनेज करने का तरीका क्या है?

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

IndexedDB और कैश एपीआई, दोनों ही नाम का 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
  }
};

कैश एपीआई

अगर ऑरिजिन की तय सीमा पार हो गई है, तो यह कैश एपीआई पर लिखने की कोशिश करता है 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
  }
}

प्रॉपर्टी को हटाने की सुविधा कैसे काम करती है?

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

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

निकालने की सबसे अच्छी कोशिश के लिए यह नीति है:

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

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

ध्यान दें: उपयोगकर्ता या ऐप्लिकेशन के ज़रूरी डेटा को सुरक्षित रखने के लिए, अपनी साइट के लिए हमेशा स्टोरेज का अनुरोध किया जा सकता है.

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

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

नतीजा

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

अन्य संसाधन

• IndexedDB सबसे सही तरीके
• Chrome वेब स्टोरेज और कोटा के कॉन्सेप्ट

धन्यवाद

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

हीरो इमेज, गिलाउम बोल्डक ने पोस्ट की है अनस्प्लैश.