अलग-अलग तरह के उपयोगकर्ताओं और डिवाइसों के लिए कॉन्टेंट बनाते समय, लेआउट और ग्राफ़िक डिज़ाइन के साथ-साथ कॉन्टेंट पर भी ध्यान दें.
लोग वेब पर कैसे पढ़ते हैं
रिसर्च से पता चलता है कि लोग वेब पेज नहीं पढ़ते, बल्कि उन्हें स्कैन करते हैं. औसतन, लोग वेब पेज के कॉन्टेंट का सिर्फ़ 20–28% हिस्सा ही पढ़ते हैं. स्क्रीन पर पढ़ने में, कागज़ पर पढ़ने के मुकाबले ज़्यादा समय लगता है. अगर जानकारी आसानी से ऐक्सेस नहीं की जा सकती और उसे समझा नहीं जा सकता, तो लोग आपकी साइट छोड़कर चले जाएंगे.
मोबाइल के लिए कॉन्टेंट कैसे लिखें
जिस विषय के बारे में लिखा जा रहा है उस पर फ़ोकस करें और कहानी की शुरुआत में ही ज़रूरी जानकारी दें. यह पक्का करें कि कॉन्टेंट अलग-अलग डिवाइसों और व्यूपोर्ट पर सही तरीके से दिखे. इसके लिए, मुख्य बातें शुरुआत में ही बताएं. आम तौर पर, पहले चार पैराग्राफ़ में, करीब 70 शब्दों में मुख्य बातें बताई जानी चाहिए.
खुद से पूछें कि लोग आपकी साइट से क्या उम्मीद रखते हैं. क्या वे कुछ ढूंढने की कोशिश कर रहे हैं? अगर लोग जानकारी पाने के लिए आपकी साइट पर आते हैं, तो पक्का करें कि आपका सारा टेक्स्ट, उनके लक्ष्य को हासिल करने में मदद करे. ऐक्टिव वॉइस में लिखें. साथ ही, लोगों को कार्रवाई करने और समस्याओं के समाधान के बारे में जानकारी दें.
सिर्फ़ वही कॉन्टेंट पब्लिश करें जो आपके दर्शकों को चाहिए. इससे ज़्यादा कॉन्टेंट पब्लिश न करें.
ब्रिटेन की सरकार की रिसर्च से यह भी पता चलता है कि:
दूसरे शब्दों में कहें, तो आसान भाषा, छोटे शब्दों, और वाक्य की आसान संरचनाओं का इस्तेमाल करें. भले ही, आपकी ऑडियंस पढ़ी-लिखी हो या तकनीकी जानकारी रखने वाली हो. अगर कोई ठोस वजह न हो, तो बातचीत वाली टोन का इस्तेमाल करें. पत्रकारिता का एक पुराना नियम है कि इस तरह से लिखें जैसे आप 11 साल के किसी समझदार बच्चे से बात कर रहे हों.
अगले एक अरब उपयोगकर्ता
कम शब्दों में जानकारी देने वाला तरीका, खास तौर पर मोबाइल डिवाइसों पर पढ़ने वाले लोगों के लिए ज़रूरी है. साथ ही, यह तरीका उन कम कीमत वाले फ़ोन के लिए कॉन्टेंट बनाते समय भी ज़रूरी है जिनमें छोटे व्यूपोर्ट होते हैं. ऐसे फ़ोन में ज़्यादा स्क्रोलिंग की ज़रूरत होती है. साथ ही, इनकी डिसप्ले क्वालिटी कम हो सकती है और स्क्रीन कम रिस्पॉन्सिव हो सकती हैं.
अगले एक अरब उपयोगकर्ताओं में से ज़्यादातर के पास कम कीमत वाले डिवाइस होंगे. वे लंबे-चौड़े कॉन्टेंट को नेविगेट करने में अपना डेटा खर्च नहीं करना चाहेंगे. साथ ही, हो सकता है कि वे अपनी पहली भाषा में न पढ़ रहे हों. अपने टेक्स्ट को छोटा करें. इसके लिए, छोटे वाक्यों, कम विराम चिह्नों, पांच या उससे कम लाइनों वाले पैराग्राफ़, और एक लाइन वाली हेडिंग का इस्तेमाल करें. रिस्पॉन्सिव टेक्स्ट का इस्तेमाल करने के बारे में सोचें. उदाहरण के लिए, छोटे व्यूपोर्ट के लिए छोटी हेडलाइन का इस्तेमाल करें. हालांकि, इसके नुकसान के बारे में भी जान लें.
टेक्स्ट के लिए कम शब्दों में जानकारी देने वाला तरीका अपनाने से, आपके कॉन्टेंट को स्थानीय भाषा में उपलब्ध कराना और अंतरराष्ट्रीय स्तर पर उपलब्ध कराना आसान हो जाएगा. साथ ही, इस बात की संभावना बढ़ जाएगी कि आपके कॉन्टेंट को सोशल मीडिया पर कोट किया जाए.
खास बातें:
- इसे आसान रखें
- गै़र-ज़रूरी जानकारी को कॉन्टेंट में शामिल न करें
- सटीक जानकारी देता है
गै़र-ज़रूरी कॉन्टेंट को कॉन्टेंट में शामिल न करें
बाइट साइज़ के हिसाब से, वेब पेज बड़े होते हैं और ये और भी बड़े होते जा रहे हैं.
रिस्पॉन्सिव डिज़ाइन की तकनीकों की मदद से, छोटे व्यूपोर्ट के लिए अलग-अलग कॉन्टेंट दिखाया जा सकता है. हालांकि, टेक्स्ट, इमेज, और अन्य कॉन्टेंट को स्ट्रीमलाइन करके शुरुआत करना हमेशा सही होता है.
वेब पर आने वाले लोग अक्सर किसी काम को पूरा करने के मकसद से आते हैं. वे अपने मौजूदा सवाल के जवाब ढूंढने के लिए, "आगे की ओर झुकते हैं". इसका मतलब है कि वे जवाब ढूंढने के लिए ज़्यादा ध्यान देते हैं. वहीं, अच्छी किताब पढ़ने के लिए वे "पीछे की ओर झुकते हैं". इसका मतलब है कि वे किताब पढ़ने के लिए आराम से बैठते हैं और ज़्यादा ध्यान नहीं देते.
Jackob Nielsen
खुद से पूछें कि लोग मेरी साइट पर आकर क्या हासिल करना चाहते हैं?
क्या हर पेज कॉम्पोनेंट, लोगों को अपना लक्ष्य हासिल करने में मदद करता है?
पेज के गै़र-ज़रूरी एलिमेंट हटाएं
एचटीटीपी आर्काइव के मुताबिक, औसतन वेब पेज के लिए, एचटीएमएल फ़ाइलें करीब 70 हज़ार होती हैं. साथ ही, नौ से ज़्यादा अनुरोध किए जाते हैं.
कई लोकप्रिय साइटों पर, हर पेज के लिए कई हज़ार एचटीएमएल एलिमेंट और कई हज़ार लाइनों का कोड इस्तेमाल किया जाता है. ऐसा मोबाइल पर भी होता है. एचटीएमएल फ़ाइल का साइज़ ज़्यादा होने से, हो सकता है कि पेज धीरे-धीरे लोड न हों. हालांकि, ज़्यादा एचटीएमएल पेलोड, कॉन्टेंट के साइज़ के बढ़ने का संकेत हो सकता है. इसका मतलब है कि .html फ़ाइलें बड़ी होने पर, ज़्यादा एलिमेंट, ज़्यादा टेक्स्ट कॉन्टेंट या दोनों हो सकते हैं.
एचटीएमएल की जटिलता कम करने से, पेज का वेट भी कम हो जाएगा. साथ ही, स्थानीय भाषा में उपलब्ध कराने और अंतरराष्ट्रीय स्तर पर उपलब्ध कराने में मदद मिलेगी. इसके अलावा, रिस्पॉन्सिव डिज़ाइन को प्लान करना और डीबग करना आसान हो जाएगा. ज़्यादा असरदार एचटीएमएल लिखने के बारे में जानने के लिए, हाई परफ़ॉर्मेंस एचटीएमएल देखें.
अगर उपयोगकर्ता को आपके ऐप्लिकेशन से वैल्यू पाने से पहले, कोई भी काम करना पड़ता है, तो आपको 20% उपयोगकर्ता खोने पड़ सकते हैं
Gabor Cselle, Twitter
कॉन्टेंट के मामले में भी यही बात लागू होती है. लोगों को अपनी ज़रूरत की जानकारी जल्द से जल्द पाने में मदद करें.
सिर्फ़ मोबाइल उपयोगकर्ताओं के लिए कॉन्टेंट न छिपाएं. कॉन्टेंट पैरिटी का लक्ष्य रखें, क्योंकि यह अनुमान लगाना कि आपके मोबाइल उपयोगकर्ता किन सुविधाओं को मिस नहीं करेंगे, किसी के लिए भी सही साबित नहीं हो सकता. अगर आपके पास संसाधन हैं, तो अलग-अलग व्यूपोर्ट साइज़ के लिए, एक ही कॉन्टेंट के अलग-अलग वर्शन बनाएं. भले ही, यह सिर्फ़ ज़्यादा प्राथमिकता वाले पेज एलिमेंट के लिए हो.
कॉन्टेंट मैनेजमेंट और वर्कफ़्लो के बारे में सोचें. क्या पुराने सिस्टम की वजह से पुराना कॉन्टेंट दिख रहा है?
टेक्स्ट को आसान बनाएं
वेब का इस्तेमाल मोबाइल पर ज़्यादा होने की वजह से, आपको लिखने का तरीका बदलना होगा. इसे आसान रखें, गै़र-ज़रूरी जानकारी को कॉन्टेंट में शामिल न करें, और सटीक जानकारी दें.
गै़र-ज़रूरी इमेज हटाएं
इमेज सुंदर, मज़ेदार, और जानकारी देने वाली हो सकती हैं. हालांकि, ये पेज की जगह का इस्तेमाल करती हैं, पेज का वेट बढ़ाती हैं, और फ़ाइल के अनुरोधों की संख्या बढ़ाती हैं. कनेक्टिविटी खराब होने पर, इंतज़ार का समय बढ़ जाता है. इसका मतलब है कि वेब का इस्तेमाल मोबाइल पर ज़्यादा होने की वजह से, इमेज फ़ाइल के अनुरोधों की संख्या बढ़ना एक बढ़ती हुई समस्या है.
इमेज, बैटरी भी खर्च करती हैं. स्क्रीन के बाद, रेडियो आपकी बैटरी को सबसे ज़्यादा खर्च करता है. इमेज के ज़्यादा अनुरोध, रेडियो का ज़्यादा इस्तेमाल, बैटरी का ज़्यादा खर्च. सिर्फ़ इमेज रेंडर करने में भी बैटरी खर्च होती है. यह इमेज के साइज़ और संख्या के हिसाब से तय होता है. स्टैनफ़र्ड की रिपोर्ट देखें: Who Killed My Battery?
अगर हो सके, तो इमेज का इस्तेमाल न करें!
यहां कुछ सुझाव दिए जा रहे हैं:
- ऐसी डिज़ाइन के बारे में सोचें जिनमें इमेज का इस्तेमाल न किया जाए या कम इमेज का इस्तेमाल किया जाए. सिर्फ़ टेक्स्ट वाला कॉन्टेंट भी सुंदर हो सकता है! खुद से पूछें, "मेरी साइट पर आने वाले लोग क्या हासिल करना चाहते हैं? क्या इमेज, उस प्रोसेस में मदद करती हैं?"
- पुराने समय में, हेडिंग और अन्य टेक्स्ट को ग्राफ़िक के तौर पर सेव करना आम बात थी. इस तरीके से, व्यूपोर्ट साइज़ में बदलाव होने पर, कॉन्टेंट सही तरीके से नहीं दिखता. साथ ही, इससे पेज वेट और इंतज़ार का समय बढ़ जाता है. टेक्स्ट को ग्राफ़िक के तौर पर इस्तेमाल करने का मतलब है कि टेक्स्ट को सर्च इंजन नहीं ढूंढ सकते. साथ ही, स्क्रीनरीडर और अन्य सहायक टेक्नोलॉजी से इसे ऐक्सेस नहीं किया जा सकता. जहां तक हो सके, "असली" टेक्स्ट का इस्तेमाल करें. वेब फ़ॉन्ट और सीएसएस की मदद से, सुंदर टाइपोग्राफ़ी बनाई जा सकती है.
- ग्रेडिएंट, शैडो, राउंड कॉर्नर, और बैकग्राउंड टेक्सचर के लिए, इमेज के बजाय सीएसएस का इस्तेमाल करें. ये सुविधाएं सभी मॉडर्न ब्राउज़र पर काम करती हैं. हालांकि, ध्यान रखें कि सीएसएस, इमेज से बेहतर हो सकता है. इसके बाद भी, प्रोसेसिंग और रेंडरिंग में समय लग सकता है. खास तौर पर, मोबाइल पर यह समय ज़्यादा लग सकता है.
- बैकग्राउंड इमेज, मोबाइल पर शायद ही कभी सही तरीके से दिखती हैं. छोटे व्यूपोर्ट पर बैकग्राउंड इमेज से बचने के लिए, मीडिया क्वेरी का इस्तेमाल किया जा सकता है.
- स्प्लैश स्क्रीन इमेज का इस्तेमाल न करें.
- यूज़र इंटरफ़ेस के ऐनिमेशन के लिए, सीएसएस का इस्तेमाल करें.
- अपने ग्लिफ़ के बारे में जानें. इमेज के बजाय, यूनिकोड सिंबल और आइकॉन का इस्तेमाल करें. अगर ज़रूरी हो, तो वेब फ़ॉन्ट का इस्तेमाल करें.
- आइकॉन फ़ॉन्ट का इस्तेमाल करने के बारे में सोचें. ये वेक्टर ग्राफ़िक होते हैं जिन्हें ज़रूरत के हिसाब से स्केल किया जा सकता है. साथ ही, इमेज का पूरा सेट एक फ़ॉन्ट में डाउनलोड किया जा सकता है. (हालांकि, इन समस्याओं के बारे में जान लें.)
- लाइनों, कर्व, टेक्स्ट, और अन्य इमेज से JavaScript में इमेज बनाने के लिए,
<canvas>एलिमेंट का इस्तेमाल किया जा सकता है. - इनलाइन एसवीजी या डेटा यूआरआई इमेज से पेज वेट कम नहीं होगा. हालांकि, रिसॉर्स के अनुरोधों की संख्या कम करके, इंतज़ार का समय कम किया जा सकता है. मोबाइल और डेस्कटॉप ब्राउज़र पर, इनलाइन एसवीजी अच्छी तरह से काम करता है. साथ ही, ऑप्टिमाइज़ेशन टूल की मदद से, एसवीजी का साइज़ काफ़ी कम किया जा सकता है. इसी तरह, डेटा यूआरआई भी अच्छी तरह से काम करते हैं. दोनों को सीएसएस में इनलाइन किया जा सकता है.
- ऐनिमेटेड GIF के बजाय,
<video>का इस्तेमाल करने के बारे में सोचें. वीडियो एलिमेंट, मोबाइल पर सभी ब्राउज़र (Opera Mini को छोड़कर) पर काम करता है.
ज़्यादा जानकारी के लिए, इमेज ऑप्टिमाइज़ेशन और इमेज हटाना और बदलना देखें.
अलग-अलग व्यूपोर्ट साइज़ के लिए, कॉन्टेंट को इस तरह डिज़ाइन करें कि वह सही तरीके से दिखे
"कोई प्रॉडक्ट बनाएं. छोटी स्क्रीन के लिए, किसी प्रॉडक्ट को फिर से डिज़ाइन न करें. मोबाइल के लिए शानदार प्रॉडक्ट बनाए जाते हैं, न कि पोर्ट किए जाते हैं."
Mobile Design and Development, Brian Fling
शानदार डिज़ाइनर, "मोबाइल के लिए ऑप्टिमाइज़" नहीं करते. वे रिस्पॉन्सिव तरीके से सोचते हैं, ताकि ऐसी साइटें बनाई जा सकें जो अलग-अलग डिवाइसों पर काम करें. अलग-अलग डिवाइसों पर साइट को सही तरीके से दिखाने के लिए, टेक्स्ट और पेज के अन्य कॉन्टेंट की संरचना ज़रूरी है.
अगले एक अरब उपयोगकर्ताओं में से कई लोग, कम कीमत वाले डिवाइसों का इस्तेमाल करेंगे. इन डिवाइसों में छोटे व्यूपोर्ट होते हैं. कम रिज़ॉल्यूशन वाली 3.5" या 4" स्क्रीन पर पढ़ना मुश्किल हो सकता है.
यहां दोनों डिवाइसों की एक साथ फ़ोटो दी गई है:
बड़ी स्क्रीन पर, टेक्स्ट छोटा है, लेकिन उसे पढ़ा जा सकता है.
छोटी स्क्रीन पर, ब्राउज़र लेआउट को सही तरीके से रेंडर करता है. हालांकि, ज़ूम इन करने पर भी टेक्स्ट को पढ़ा नहीं जा सकता. डिसप्ले धुंधली है और इसमें 'कलर कास्ट' है. इसका मतलब है कि सफ़ेद रंग, सफ़ेद नहीं दिखता. इससे कॉन्टेंट को पढ़ना मुश्किल हो जाता है.
मोबाइल के लिए कॉन्टेंट डिज़ाइन करना
अलग-अलग व्यूपोर्ट के लिए कॉन्टेंट बनाते समय, लेआउट और ग्राफ़िक डिज़ाइन के साथ-साथ कॉन्टेंट पर भी ध्यान दें. प्लेसहोल्डर कॉन्टेंट के बजाय, असली टेक्स्ट और इमेज का इस्तेमाल करें.
"डिज़ाइन से पहले कॉन्टेंट आता है. कॉन्टेंट के बिना डिज़ाइन, डिज़ाइन नहीं होता, बल्कि सजावट होती है."
Jeffrey Zeldman
- सबसे ज़रूरी कॉन्टेंट को सबसे ऊपर रखें, क्योंकि लोग वेब पेजों को F-शेप पैटर्न में पढ़ते हैं.
- लोग किसी लक्ष्य को हासिल करने के लिए आपकी साइट पर आते हैं. खुद से पूछें कि उन्हें अपना लक्ष्य हासिल करने के लिए क्या चाहिए और बाकी सब कुछ हटा दें. विज़ुअल और टेक्स्ट में सजावट, पुराने कॉन्टेंट, ज़्यादा लिंक, और अन्य गै़र-ज़रूरी जानकारी को कॉन्टेंट में शामिल न करें.
- सोशल शेयरिंग आइकॉन का इस्तेमाल करते समय सावधानी बरतें. इनसे लेआउट में गड़बड़ी हो सकती है. साथ ही, इनके कोड की वजह से पेज लोड होने में ज़्यादा समय लग सकता है.
- कॉन्टेंट के लिए रिस्पॉन्सिव लेआउट डिज़ाइन करें. डिवाइस के तय साइज़ के लिए नहीं.
कॉन्टेंट की जांच करना
- Chrome DevTools और अन्य एम्युलेशन टूल का इस्तेमाल करके, छोटे व्यूपोर्ट पर पढ़ने की सुविधा की जांच करें.
- कम बैंडविथ और ज़्यादा इंतज़ार के समय की स्थितियों में, अपने कॉन्टेंट की जांच करें. अलग-अलग कनेक्टिविटी स्थितियों में कॉन्टेंट आज़माएं.
- कम कीमत वाले फ़ोन पर, अपने कॉन्टेंट को पढ़ने और उससे इंटरैक्ट करने की कोशिश करें.
- अपने दोस्तों और सहकर्मियों से, आपके ऐप्लिकेशन या साइट को आज़माने के लिए कहें.
- डिवाइस टेस्ट लैब बनाएं. Google की मिनी मोबाइल डिवाइस लैब के GitHub रेपो में, अपनी लैब बनाने के निर्देश दिए गए हैं. OpenSTF, कई Android डिवाइसों पर वेबसाइटों की जांच करने के लिए एक आसान वेब ऐप्लिकेशन है.
यहां OpenSTF इस्तेमाल करने का तरीका बताया गया है:
मोबाइल डिवाइसों का इस्तेमाल, सिर्फ़ कम्यूनिकेशन, गेम, और मीडिया के लिए नहीं किया जाता. इनका इस्तेमाल, कॉन्टेंट देखने और जानकारी पाने के लिए भी किया जाता है.
इसलिए, अलग-अलग व्यूपोर्ट पर सही तरीके से दिखने के लिए, कॉन्टेंट की प्लानिंग करना ज़रूरी है. साथ ही, अलग-अलग डिवाइसों के लिए लेआउट, इंटरफ़ेस, और इंटरैक्शन डिज़ाइन करते समय, कॉन्टेंट को प्राथमिकता देना ज़रूरी है.
डेटा खर्च को समझना
वेब पेज बड़े होते जा रहे हैं.
एचटीटीपी आर्काइव के मुताबिक, सबसे लोकप्रिय 10 लाख साइटों के लिए, औसतन पेज वेट अब 2 एमबी से ज़्यादा है.
लोग उन साइटों या ऐप्लिकेशन का इस्तेमाल नहीं करते जो धीरे-धीरे लोड होते हैं या जिनमें ज़्यादा डेटा खर्च होता है. इसलिए, पेज और ऐप्लिकेशन के कॉम्पोनेंट लोड करने में लगने वाले खर्च को समझना ज़रूरी है.
पेज वेट कम करने से फ़ायदा भी हो सकता है. YouTube के Chris Zacharias ने पाया कि जब उन्होंने वॉच-पेज का साइज़ 1.2 एमबी से घटाकर 250 केबी कर दिया, तो:
दूसरे शब्दों में कहें, तो पेज वेट कम करने से नए मार्केट में एंट्री मिल सकती है.
पेज वेट का हिसाब लगाना
पेज वेट का हिसाब लगाने के लिए कई टूल उपलब्ध हैं. Chrome DevTools का नेटवर्क पैनल, सभी रिसॉर्स के लिए कुल बाइट साइज़ दिखाता है. इसका इस्तेमाल, अलग-अलग ऐसेट टाइप के लिए वेट का पता लगाने के लिए किया जा सकता है. आपके पास यह भी देखने का विकल्प है कि ब्राउज़र कैश से कौनसे आइटम वापस पाए गए हैं.
Firefox और अन्य ब्राउज़र भी इसी तरह के टूल उपलब्ध कराते हैं.
WebPagetest, पेज के पहले और बाद के लोड को टेस्ट करने की सुविधा देता है. स्क्रिप्ट की मदद से (उदाहरण के लिए, किसी साइट पर लॉग इन करने के लिए) या उनके RESTful एपीआई का इस्तेमाल करके, टेस्ट को ऑटोमेट किया जा सकता है. यहां दिए गए उदाहरण (developers.google.com/web लोड करना) से पता चलता है कि कैशिंग सही तरीके से हुई है और पेज के बाद के लोड के लिए, किसी अन्य रिसॉर्स की ज़रूरत नहीं पड़ी.
WebPagetest, MIME टाइप के हिसाब से साइज़ और अनुरोधों की जानकारी भी देता है.
पेज के खर्च का हिसाब लगाना
कई लोगों के लिए, डेटा का खर्च सिर्फ़ बाइट और परफ़ॉर्मेंस के हिसाब से नहीं होता, बल्कि पैसे के हिसाब से भी होता है.
What Does My Site Cost? साइट की मदद से, अपनी साइट को लोड करने में लगने वाले असल खर्च का अनुमान लगाया जा सकता है. यहां दिए गए हिस्टोग्राम से पता चलता है कि प्रीपेड डेटा प्लान का इस्तेमाल करके, amazon.com को लोड करने में कितना खर्च आता है.
ध्यान रखें कि इसमें आय के हिसाब से, खर्च करने की क्षमता को ध्यान में नहीं रखा जाता. blog.jana.com के डेटा से, डेटा के खर्च के बारे में पता चलता है.
| 500 एमबी डेटा प्लान कीमत (USD) |
घंटे के हिसाब से कम से कम मज़दूरी (USD) |
500 एमबी डेटा प्लान के लिए काम करने के घंटे |
|
| भारत | $3.38 | $0.20 | 17 घंटे |
| इंडोनेशिया | $2.39 | INR31.39 | 6 घंटे |
| ब्राज़ील | $13.77 | $1.04 | 13 घंटे |
पेज वेट की समस्या सिर्फ़ उभरते हुए मार्केट के लिए नहीं है. कई देशों में, लोग सीमित डेटा वाले मोबाइल प्लान का इस्तेमाल करते हैं. अगर उन्हें लगता है कि आपकी साइट या ऐप्लिकेशन में ज़्यादा डेटा खर्च होता है, तो वे इसका इस्तेमाल नहीं करेंगे. आम तौर पर, "अनलिमिटेड" सेल और वाई-फ़ाई डेटा प्लान में भी डेटा की सीमा होती है. इस सीमा के बाद, डेटा ब्लॉक हो जाता है या उसकी स्पीड कम हो जाती है. इन वजहों से, यह बताना ज़रूरी है कि आपके पेज पर कितना डेटा खर्च होता है. यहां दिए गए ब्लॉग पोस्ट में, सबसे सही तरीके बताए गए हैं: Nurture trust through cost transparency
खास बात: पेज वेट से परफ़ॉर्मेंस पर असर पड़ता है और डेटा खर्च होता है. कॉन्टेंट की परफ़ॉर्मेंस को ऑप्टिमाइज़ करना लेख में, डेटा खर्च को कम करने का तरीका बताया गया है.