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

डेव गैश
डेव गैश
इल्या ग्रिगोरिक
इलिया ग्रिगोरिक
जेरेमी वैगनर
जेरेमी वैगनर

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

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

Weblight के आंकड़े

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

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

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

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

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

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

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

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

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

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

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

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

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

navigator ऑब्जेक्ट में connection ऑब्जेक्ट की मौजूदगी की जांच करना ज़रूरी है, क्योंकि यह नेटवर्क जानकारी एपीआई को दिखाता है, जिसे सिर्फ़ 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 देखें). उदाहरण के लिए, हो सकता है कि आप Save-Data चालू न होने पर भी किसी 2G कनेक्शन का इस्तेमाल करने वाले किसी भी उपयोगकर्ता को लाइटवेट अनुभव देना चाहें. वहीं, अगर उपयोगकर्ता "तेज़" 4G कनेक्शन का इस्तेमाल करता है, तो इसका मतलब यह नहीं है कि उसे डेटा बचाने में दिलचस्पी नहीं है. उदाहरण के लिए, रोमिंग के दौरान. इसके अलावा, Device-Memory क्लाइंट हिंट की मदद से, Save-Data की मौजूदगी को बेहतर बनाया जा सकता है. इससे, आपको कम मेमोरी वाले डिवाइसों पर उपयोगकर्ताओं के हिसाब से बदलाव करने में मदद मिलेगी. उपयोगकर्ता के डिवाइस की मेमोरी को navigator.deviceMemory क्लाइंट संकेत में भी दिखाया जाता है.

Recipes

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

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

navigator.connection.saveData प्रॉपर्टी की मदद से, 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) है, जैसा कि रेटिना डिसप्ले). यह ज़रूरी नहीं है कि हाई रिज़ॉल्यूशन वाली स्क्रीन की यह कैटगरी, सिर्फ़ हाई एंड डिवाइसों तक सीमित हो रही है. ऐसा लगातार बढ़ता जा रहा है. ऐसे मामलों में जहां ऐप्लिकेशन के अनुभव को बेहतर बनाने का सुझाव दिया जाता है, वहां बड़े (2x) वैरिएंट के बजाय, कम रिज़ॉल्यूशन वाली (1x) इमेज भेजने के बजाय, इन स्क्रीन पर कम रिज़ॉल्यूशन वाली (1x) इमेज भेजना सही हो सकता है. 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 जैसे यूआरएल रीराइट मॉड्यूल का इस्तेमाल करके भी ऐसा किया जा सकता है. बहुत कम कॉन्फ़िगरेशन की मदद से इसे हासिल करने के तरीके यहां दिए गए हैं.

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

<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; डेटा मौजूद न होने पर लोड होने वाली ग़ैर-ज़रूरी तस्वीरों की तुलना
और डेटा सेव होने पर, हटाए जाने वाली तस्वीरों की
तुलना.
सेव का डेटा मौजूद न होने पर लोड होने वाली ग़ैर-ज़रूरी तस्वीरों की तुलना. यह तुलना, डेटा सेव करने की सुविधा मौजूद होने पर हटाई जाने वाली तस्वीरों की तुलना से की जाती है.

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

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

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

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

उदाहरण के लिए, मान लें कि आपने अपनी साइट पर, Google फ़ॉन्ट से 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 देखें.