डेटा सेव करने की सुविधा का इस्तेमाल करके, तेज़ और कम डेटा वाले ऐप्लिकेशन डिलीवर करना

Chrome, Opera, और Yandex ब्राउज़र में उपलब्ध Save-Data क्लाइंट संकेत अनुरोध हेडर की मदद से डेवलपर, ऐसे उपयोगकर्ताओं को कम और तेज़ ऐप्लिकेशन डिलीवर कर सकते हैं जो अपने ब्राउज़र में डेटा बचाने वाले मोड में ऑप्ट-इन करते हैं.

लाइटवेट पेजों की ज़रूरत

Weblight के आंकड़े

हर कोई इस बात से सहमत है कि तेज़ी से और आसानी से लोड होने वाले वेब पेज, उपयोगकर्ताओं को बेहतर अनुभव देते हैं साथ ही, कॉन्टेंट को समझने और उसे बनाए रखने के साथ-साथ कन्वर्ज़न और रेवेन्यू में बढ़ोतरी करते हैं. Google रिसर्च से पता चला है कि "...ऑप्टिमाइज़ किए गए पेज, मूल पेज की तुलना में चार गुना तेज़ी से लोड होते हैं और 80% कम बाइट इस्तेमाल करते हैं. ये पेज बहुत तेज़ी से लोड होते हैं, इसलिए हमने इन पेजों के ट्रैफ़िक में भी 50% की बढ़ोतरी देखी."

हालांकि, 2G कनेक्शन की संख्या आखिर में अस्वीकार की जाती है, लेकिन 2015 में 2G अब भी मुख्य नेटवर्क टेक्नोलॉजी का हिस्सा था. 3G और 4G नेटवर्क की पहुंच और उनकी उपलब्धता तेज़ी से बढ़ रही है, लेकिन मालिकाना हक से जुड़ी लागत और नेटवर्क की सीमाएं अब भी करोड़ों उपयोगकर्ताओं के लिए अहम फ़ैक्टर हैं.

ये पेज ऑप्टिमाइज़ेशन के लिए अहम तर्क हैं.

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

Save-Data अनुरोध का हेडर

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

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

ब्राउज़र समर्थन

Save-Data सेटिंग का पता लगाया जा रहा है

यह तय करने के लिए कि आपके उपयोगकर्ताओं को "लाइट" अनुभव कब देना है, आपका ऐप्लिकेशन Save-Data क्लाइंट संकेत अनुरोध हेडर की जांच कर सकता है. इस अनुरोध के हेडर से पता चलता है कि ट्रांसफ़र की ज़्यादा कीमत, इंटरनेट की धीमी स्पीड या अन्य वजहों से, उपयोगकर्ता कम डेटा खर्च करना चाहता है.

जब लोग अपने ब्राउज़र में डेटा सेविंग मोड को चालू करते हैं, तब ब्राउज़र Save-Data अनुरोध के हेडर को सभी आउटगोइंग अनुरोधों (एचटीटीपी और एचटीटीपीएस, दोनों) में जोड़ देता है. इस लेख के दौरान, ब्राउज़र हेडर में सिर्फ़ एक *on- टोकन (Save-Data: on) दिखाता है. हालांकि, उपयोगकर्ता की अन्य प्राथमिकताओं के बारे में बताने के लिए, आने वाले समय में इस टोकन को बढ़ाया भी जा सकता है.

इसके अलावा, यह पता लगाया जा सकता है कि JavaScript में Save-Data चालू है या नहीं:

if ('connection' in navigator) {
  if (navigator.connection.saveData === true) {
    // Implement data saving operations here.
  }
}

navigator ऑब्जेक्ट में connection ऑब्जेक्ट की मौजूदगी का पता लगाना ज़रूरी है, क्योंकि यह Network Information API को दिखाता है, जिसे सिर्फ़ Chrome, Android के लिए Chrome, और Samsung के इंटरनेट ब्राउज़र में लागू किया जाता है. यहां से, आपको सिर्फ़ यह जांच करनी होगी कि navigator.connection.saveData, true के बराबर है या नहीं. साथ ही, इस स्थिति में डेटा सेव करने से जुड़ी कोई भी कार्रवाई लागू की जा सकती है.

Chrome के डेवलपर टूल में दिखाया गया
डेटा सेव करने वाला हेडर, डेटा बचाने की सेटिंग के एक्सटेंशन के साथ दिखाया गया है.
डेस्कटॉप पर, Chrome में डेटा बचाने की सेटिंग का एक्सटेंशन चालू करना.

अगर आपका ऐप्लिकेशन सेवा कर्मचारी का इस्तेमाल करता है, तो वह अनुरोध हेडर की जांच कर सकता है और अनुभव को ऑप्टिमाइज़ करने के लिए ज़रूरी लॉजिक लागू कर सकता है. इसके अलावा, सर्वर Save-Data अनुरोध के हेडर में विज्ञापन की प्राथमिकताओं को देख सकता है और एक वैकल्पिक रिस्पॉन्स दे सकता है. जैसे, अलग-अलग मार्कअप, छोटी इमेज, वीडियो वगैरह.

लागू करने के लिए सलाह और सबसे सही तरीके

  1. Save-Data का इस्तेमाल करते समय, ऐसे यूज़र इंटरफ़ेस (यूआई) डिवाइस उपलब्ध कराएं जिन पर यह काम करता हो. साथ ही, उपयोगकर्ताओं को एक से दूसरे अनुभव पर आसानी से जाने की सुविधा भी दें. उदाहरण के लिए:
    • उपयोगकर्ताओं को बताएं कि Save-Data काम करता है और उन्हें इसका इस्तेमाल करने के लिए बढ़ावा दें.
    • उपयोगकर्ताओं को सही प्रॉम्प्ट और चालू/बंद बटन या चेकबॉक्स की मदद से, मोड की पहचान करने और उसे चुनने की अनुमति दें.
    • डेटा बचाने वाला मोड चुनने पर, एलान करें और इसे बंद करने का आसान और आसान तरीका बताएं. अगर आप चाहें, तो सभी सुविधाएं वापस चालू कर दें.
  2. याद रखें कि लाइटवेट ऐप्लिकेशन कम काम के नहीं हैं. इससे ज़रूरी सुविधाओं या डेटा को नहीं छोड़ा जाता है. इससे, बढ़ी हुई कीमतों और उपयोगकर्ता अनुभव के बारे में उन्हें बेहतर जानकारी मिलती है. उदाहरण के लिए:
    • फ़ोटो गैलरी वाला कोई ऐप्लिकेशन, कम रिज़ॉल्यूशन वाली झलक दिखा सकता है या कम कोड वाले कैरसेल सिस्टम का इस्तेमाल कर सकता है.
    • सर्च ऐप्लिकेशन एक बार में कम नतीजे दिखा सकता है, बहुत ज़्यादा मीडिया वाले नतीजे सीमित कर सकता है या पेज को रेंडर करने के लिए ज़रूरी निर्भरता को कम कर सकता है.
    • ऐसा हो सकता है कि खबरों वाली साइट कम खबरें दिखाए, कम लोकप्रिय कैटगरी को छोड़ दें या मीडिया की छोटे झलक उपलब्ध कराएं.
  3. Save-Data अनुरोध के हेडर की जांच करने के लिए, सर्वर लॉजिक दें.इसके चालू होने पर, पेज का कोई दूसरा और हल्का रिस्पॉन्स दें. उदाहरण के लिए, ज़रूरी रिसॉर्स और डिपेंडेंसी की संख्या कम करना, रिसॉर्स को ज़्यादा सटीक और कम समय में कंप्रेस करना वगैरह.
    • अगर Save-Data हेडर के आधार पर कोई दूसरा रिस्पॉन्स दिया जा रहा है, तो इसे 'वैरी लिस्ट Vary: Save-Data' में जोड़ना न भूलें. इससे अपस्ट्रीम कैश मेमोरी को यह बताया जा सकेगा कि Save-Data अनुरोध हेडर मौजूद होने पर ही, इस वर्शन को कैश मेमोरी में सेव करना चाहिए और दिखाना चाहिए. ज़्यादा जानकारी के लिए, कैश मेमोरी से इंटरैक्ट करने के सबसे सही तरीके देखें.
  4. अगर किसी सर्विस वर्कर का इस्तेमाल किया जाता है, तो आपका ऐप्लिकेशन यह पता लगा सकता है कि डेटा सेव करने का विकल्प कब चालू है. इसके लिए, आपका ऐप्लिकेशन Save-Data अनुरोध हेडर की मौजूदगी की जांच करके या navigator.connection.saveData प्रॉपर्टी की वैल्यू की जांच कर सकता है. यह सुविधा चालू होने पर, यह देखें कि क्या कम बाइट फ़ेच करने के लिए फिर से अनुरोध लिखा जा सकता है या पहले से फ़ेच किए गए रिस्पॉन्स का इस्तेमाल किया जा सकता है या नहीं.
  5. Save-Data को अन्य सिग्नल की मदद से बेहतर बनाएं, जैसे कि उपयोगकर्ता के कनेक्शन टाइप और टेक्नोलॉजी के बारे में जानकारी (NetInfo API देखें). उदाहरण के लिए, हो सकता है कि आप 2G कनेक्शन का इस्तेमाल करने वाले किसी भी उपयोगकर्ता को लाइटवेट अनुभव देना चाहें, भले ही Save-Data चालू न हो. इसके उलट, अगर उपयोगकर्ता "तेज़" 4G कनेक्शन पर है, तो इसका मतलब यह नहीं है कि उसे डेटा सेव करने में दिलचस्पी नहीं है. जैसे, रोमिंग में. इसके अलावा, कम मेमोरी वाले डिवाइसों पर उपयोगकर्ताओं की ज़रूरतों के हिसाब से बदलाव करने के लिए, Device-Memory क्लाइंट हिंट की मदद से Save-Data की मौजूदगी को बेहतर बनाया जा सकता है. उपयोगकर्ता के डिवाइस की मेमोरी का विज्ञापन भी navigator.deviceMemory क्लाइंट हिंट में दिखाया जाता है.

रेसिपी

Save-Data से हासिल की जा सकने वाली चीज़ें सिर्फ़ इस तक सीमित हैं कि क्या किया जा सकता है. यह कैसे दिखाया जा सकता है, इस बारे में आपको बताने के लिए, आइए इस्तेमाल के कुछ केस पर बात करते हैं. इसे पढ़ने के बाद, हो सकता है कि आपको खुद ही कोई और उदाहरण दिख जाए. इसलिए, बेझिझक प्रयोग करें और देखें कि क्या संभव है!

सर्वर साइड कोड में Save-Data की जांच की जा रही है

हालांकि, आप navigator.connection.saveData प्रॉपर्टी की मदद से JavaScript में Save-Data की स्थिति का पता लगा सकते हैं. हालांकि, कभी-कभी इसे सर्वर साइड पर भी पता लगाना बेहतर माना जाता है. कुछ मामलों में JavaScript लागू हो सकता है. साथ ही, क्लाइंट को भेजे जाने से पहले, मार्कअप में बदलाव करने के लिए सर्वर साइड की पहचान करना ही एक तरीका है. ऐसा Save-Data के कुछ सबसे फ़ायदेमंद इस्तेमाल के मामलों में किया जाता है.

सर्वर साइड कोड में Save-Data हेडर का पता लगाने का सिंटैक्स, इस्तेमाल की जाने वाली भाषा पर निर्भर करता है. हालांकि, किसी भी ऐप्लिकेशन के बैक एंड के लिए बुनियादी आइडिया एक जैसा होना चाहिए. उदाहरण के लिए, PHP में अनुरोध हेडर HTTP_ से शुरू होने वाले इंडेक्स पर $_SERVER सुपरग्लोबल ऐरे में सेव किए जाते हैं. इसका मतलब है कि $_SERVER["HTTP_SAVE_DATA"] वैरिएबल की मौजूदगी और वैल्यू की जांच करके, Save-Data हेडर का पता लगाया जा सकता है. जैसे:

// false by default.
$saveData = false;

// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
  // `Save-Data` detected!
  $saveData = true;
}

क्लाइंट को कोई भी मार्कअप भेजने से पहले यह जांच करने पर, $saveData वैरिएबल में Save-Data स्थिति होगी. साथ ही, यह पेज पर इस्तेमाल करने के लिए कहीं भी उपलब्ध होगा. इस तरीके को समझाने के लिए, आइए कुछ उदाहरणों पर नज़र डालते हैं कि हम उपयोगकर्ता को भेजे जाने वाले डेटा को सीमित करने के लिए इसका इस्तेमाल कैसे कर सकते हैं.

हाई रिज़ॉल्यूशन वाली स्क्रीन के लिए, कम रिज़ॉल्यूशन वाली इमेज इस्तेमाल करें

वेब पर इमेज के लिए सामान्य इस्तेमाल के उदाहरण में, दो के सेट में इमेज दिखाई जाती हैं: एक इमेज "स्टैंडर्ड" स्क्रीन (1x) के लिए और दूसरी जो हाई रिज़ॉल्यूशन वाली स्क्रीन के लिए दोगुनी बड़ी होती है (2x) (उदाहरण के लिए, Retina Display). ज़रूरी नहीं है कि हाई रिज़ॉल्यूशन वाली इस तरह की स्क्रीन ज़्यादा एंड स्क्रीन वाले डिवाइसों तक ही सीमित हों. इनका इस्तेमाल तेज़ी से बढ़ता जा रहा है. ऐसे मामलों में, जहां ऐप्लिकेशन के कम इस्तेमाल करने को प्राथमिकता दी जाती है, इन स्क्रीन पर कम रिज़ॉल्यूशन (1x) वाली इमेज भेजना सही रहेगा, न कि बड़े (2x) वैरिएंट. Save-Data हेडर के मौजूद होने पर ऐसा करने के लिए, हम क्लाइंट को भेजे जाने वाले मार्कअप में बदलाव करते हैं:

if ($saveData === true) {
  // Send a low-resolution version of the image for clients specifying `Save-Data`.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
  // Send the usual assets for everyone else.
  ?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}

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

<html> एलिमेंट में क्लास जोड़कर भी इस कॉन्सेप्ट को सीएसएस background-image प्रॉपर्टी में भी शामिल किया जा सकता है:

<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">

यहां से, अपनी सीएसएस के <html> एलिमेंट पर save-data क्लास को टारगेट करके, इमेज डिलीवर करने का तरीका बदला जा सकता है. ऊपर दिए गए एचटीएमएल के उदाहरण में दिखाए गए तरीके से, हाई रिज़ॉल्यूशन वाली स्क्रीन पर लो रिज़ॉल्यूशन वाली बैकग्राउंड इमेज भेजी जा सकती हैं. इसके अलावा, कुछ संसाधनों को हटाया भी जा सकता है.

गै़र-ज़रूरी तस्वीरों का संग्रह छोड़ें

वेब पर मौजूद इमेज का कुछ कॉन्टेंट गैर-ज़रूरी होता है. इस तरह की तस्वीरों के साथ-साथ कॉन्टेंट को भी ध्यान में रखा जा सकता है. हालांकि, सीमित डेटा प्लान से बाहर निकलने के लिए सभी चीज़ों को फ़िल्टर करने की कोशिश करने वालों को यह मक़सद नहीं होता. Save-Data का सबसे आसान इस्तेमाल का मामला होने पर, हम पहले से PHP पहचान कोड का इस्तेमाल कर सकते हैं और ग़ैर-ज़रूरी इमेज मार्कअप को हटा सकते हैं:

<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
  // Only send this image if `Save-Data` hasn't been detected.
  ?><img src="meme.jpg" alt="One does not simply consume data."><?php
}

इस तकनीक का खास असर होता है, जैसा कि यहां दी गई इमेज में देखा जा सकता है:

&#39;सेव-डेटा&#39; मौजूद न होने पर लोड होने वाली गैर-ज़रूरी तस्वीरों और &#39;डेटा सेव करें&#39; के मौजूद न होने पर उसी तस्वीरों की तुलना
सेव-डेटा मौजूद न होने पर, लोड की जा रही गैर-ज़रूरी तस्वीरों की तुलना और 'सेव करें' के मौजूद होने पर वही तस्वीरें लोड होने से रोकने के लिए तुलना.

बेशक, इमेज को छोड़ने की ही संभावना नहीं है. कुछ टाइपफ़ेस जैसे गैर-ज़रूरी संसाधनों को भेजने से पहले भी Save-Data पर कार्रवाई की जा सकती है.

गै़र-ज़रूरी वेब फ़ॉन्ट हटाएं

आम तौर पर, वेब फ़ॉन्ट किसी पेज के कुल पेलोड का उतना नहीं होता जितना कि इमेज अक्सर होते हैं. फिर भी वे लोकप्रिय हैं. वे बहुत कम डेटा का इस्तेमाल भी नहीं करते हैं. इसके अलावा, ब्राउज़र में फ़ॉन्ट को फ़ेच और रेंडर करने का तरीका भी थोड़ा मुश्किल होता है. इसमें FOIT, FOUT, और ब्राउज़र के अनुभव से जुड़े कॉन्सेप्ट हैं, जिनकी वजह से आपको बहुत बारीकी से काम करने की ज़रूरत पड़ती है.

अगर आपको लगता है कि लोग ग़ैर-ज़रूरी वेब फ़ॉन्ट का इस्तेमाल नहीं करना चाहते हैं, तो हो सकता है कि आप उपयोगकर्ताओं को बेहतर अनुभव देना चाहें. Save-Data के ज़रिए ऐसा किया जा सकता है.

उदाहरण के लिए, मान लें कि आपने अपनी साइट पर Google Fonts से Fira Sans को शामिल किया है. Fira Sans एक बेहतरीन बॉडी कॉपी फ़ॉन्ट है, लेकिन हो सकता है कि डेटा बचाने की कोशिश करने वाले उपयोगकर्ताओं के लिए यह इतना ज़रूरी न हो. Save-Data हेडर के मौजूद होने पर, <html> एलिमेंट में save-data की क्लास जोड़कर, हम ऐसी स्टाइल लिख सकते हैं जो शुरुआत में गैर-ज़रूरी टाइपफ़ेस को शुरू करती हैं. हालांकि, Save-Data हेडर मौजूद होने पर, हम इससे ऑप्ट-आउट कर देते हैं:

/* Opt into web fonts by default. */
p,
li {
  font-family: 'Fira Sans', 'Arial', sans-serif;
}

/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
  font-family: 'Arial', sans-serif;
}

इस तरीके का इस्तेमाल करके, Google Fonts से <link> स्निपेट को उसकी जगह पर छोड़ा जा सकता है. इसकी वजह यह है कि ब्राउज़र, सबसे पहले डीओएम पर स्टाइल लागू करके सीएसएस रिसॉर्स (जिसमें वेब फ़ॉन्ट भी शामिल है) को लोड करता है. इसके बाद, यह देखता है कि एचटीएमएल एलिमेंट, स्टाइल शीट में किसी रिसॉर्स को शुरू करता है या नहीं. अगर कोई व्यक्ति Save-Data को चालू करता है, तो Fira Sans कभी भी लोड नहीं होगा, क्योंकि स्टाइल वाले DOM इसे कभी शुरू नहीं करते. इसके बजाय, एरियल नई जगह लेगा. यह Fira Sans जितना अच्छा नहीं है, लेकिन यह उन उपयोगकर्ताओं के लिए बेहतर हो सकता है जो अपने डेटा प्लान को बेहतर बनाने की कोशिश कर रहे हैं.

खास जानकारी

Save-Data हेडर में ज़्यादा बारीकियां नहीं होती हैं; यह चालू या बंद होता है. साथ ही, ऐप्लिकेशन में अपनी सेटिंग के आधार पर, सही अनुभव देने का दबाव पड़ता है. भले ही, कोई भी वजह हो.

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

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

Save-Data के बारे में ज़्यादा जानकारी और काम के बेहतरीन उदाहरणों के लिए, अपने उपयोगकर्ताओं की मदद करें Save Data देखें.