उपयोगकर्ताओं के हिसाब से क्लाइंट संकेतों के हिसाब से बदलाव करना

Jeremy Wagner

ऐसी साइटें बनाना मुश्किल हो सकता है जो हर जगह तेज़ी से लोड हों. डिवाइस की कई क्षमताओं और उनके कनेक्ट होने वाले नेटवर्क की क्वालिटी की वजह से, यह काम बहुत मुश्किल लग सकता है. लोडिंग की परफ़ॉर्मेंस को बेहतर बनाने के लिए, हम ब्राउज़र की सुविधाओं का फ़ायदा ले सकते हैं. हालांकि, हमें यह कैसे पता चलेगा कि उपयोगकर्ता का डिवाइस कैसा है या उसके नेटवर्क कनेक्शन की क्वालिटी कैसी है? इसका समाधान क्लाइंट हिंट है!

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

यह सब कॉन्टेंट नेगोशिएशन के बारे में है

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

कॉन्टेंट नेगोशिएशन का एक उदाहरण, Accept अनुरोध हेडर से जुड़ा है. इससे पता चलता है कि ब्राउज़र किस तरह के कॉन्टेंट को समझता है. सर्वर इसका इस्तेमाल करके, जवाब के लिए बातचीत कर सकता है. इमेज के अनुरोधों के लिए, Chrome के Accept हेडर का कॉन्टेंट यह है:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

सभी ब्राउज़र पर JPEG, PNG, और GIF जैसे इमेज फ़ॉर्मैट काम करते हैं. हालांकि, इस मामले में Accept से पता चलता है कि ब्राउज़र WebP और APNG को भी सपोर्ट करता है. इस जानकारी का इस्तेमाल करके, हम हर ब्राउज़र के लिए सबसे अच्छी इमेज टाइप तय कर सकते हैं:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

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

ऑप्ट इन करना

Accept हेडर के उलट, क्लाइंट हिंट अपने-आप नहीं दिखते. हालांकि, Save-Data के मामले में ऐसा होता है. इसके बारे में हम बाद में बात करेंगे. अनुरोध हेडर को कम से कम रखने के लिए, आपको यह चुनना होगा कि आपको कौनसी क्लाइंट हिंट चाहिए. इसके लिए, जब कोई उपयोगकर्ता किसी संसाधन का अनुरोध करता है, तब आपको Accept-CH हेडर भेजना होगा:

Accept-CH: Viewport-Width, Downlink

Accept-CH की वैल्यू, कॉमा से अलग किए गए उन अनुरोधित हिंट की सूची होती है जिनका इस्तेमाल साइट, संसाधन के बाद के अनुरोधों के नतीजे तय करने के लिए करेगी. जब क्लाइंट इस हेडर को पढ़ता है, तो उसे बताया जाता है कि “इस साइट को Viewport-Width और Downlink क्लाइंट हिंट चाहिए.” खास हिंट के बारे में चिंता न करें. हम थोड़ी देर में उन पर चर्चा करेंगे.

इन ऑप्ट-इन हेडर को बैक-एंड की किसी भी भाषा में सेट किया जा सकता है. उदाहरण के लिए, PHP के header फ़ंक्शन का इस्तेमाल किया जा सकता है. <meta> टैग पर http-equiv एट्रिब्यूट का इस्तेमाल करके, ऑप्ट-इन हेडर भी सेट किए जा सकते हैं:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

सभी क्लाइंट हिंट!

क्लाइंट हिंट से दो तरह की जानकारी मिलती है: पहली, आपके उपयोगकर्ताओं के इस्तेमाल किए जाने वाले डिवाइस की जानकारी और दूसरी, आपकी साइट को ऐक्सेस करने के लिए इस्तेमाल किए जा रहे नेटवर्क की जानकारी. आइए, उपलब्ध सभी संकेतों के बारे में संक्षेप में जानें.

डिवाइस के लिए हिंट

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

इस सूची के बारे में जानने से पहले, स्क्रीन और मीडिया रिज़ॉल्यूशन के बारे में बताने के लिए इस्तेमाल किए गए कुछ मुख्य शब्दों के बारे में जान लें:

इंट्रिंसिक साइज़: किसी मीडिया रिसोर्स के असल डाइमेंशन. उदाहरण के लिए, अगर आपने Photoshop में कोई इमेज खोली है, तो इमेज के साइज़ वाले डायलॉग बॉक्स में दिखाए गए डाइमेंशन, इमेज के मूल साइज़ के बारे में बताते हैं.

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

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

मान लें कि इस मामले में 1x इमेज का ओरिजनल साइज़ 320x240 है और 2x इमेज का ओरिजनल साइज़ 640x480 है. अगर इस मार्कअप को ऐसे डिवाइस पर इंस्टॉल किए गए क्लाइंट से पार्स किया जाता है जिसकी स्क्रीन का डिवाइस पिक्सल रेशियो 2 है (जैसे, रेटिना स्क्रीन), तो 2x इमेज का अनुरोध किया जाता है. 2x इमेज का डेंसिटी के हिसाब से सही किया गया ओरिजनल साइज़ 320x240 है, क्योंकि 640x480 को 2 से भाग देने पर 320x240 मिलता है.

एक्सट्रिंसिक साइज़: सीएसएस और लेआउट से जुड़े अन्य फ़ैक्टर (जैसे कि width और height एट्रिब्यूट) लागू होने के बाद, मीडिया संसाधन का साइज़. मान लें कि आपके पास एक <img> एलिमेंट है, जो 320x240 के डेनसिटी-करेक्टेड इंट्रिंसिक साइज़ वाली इमेज लोड करता है. हालांकि, इसमें सीएसएस width और height प्रॉपर्टी भी हैं, जिनकी वैल्यू क्रमशः 256px और 192px लागू की गई हैं. इस उदाहरण में, उस <img> एलिमेंट का बाहरी साइज़ 256x192 हो जाता है.

अब हम आपको डिवाइस के हिसाब से उपलब्ध क्लाइंट हिंट की सूची के बारे में बताते हैं.

Viewport-Width

Viewport-Width, उपयोगकर्ता के व्यूपोर्ट की चौड़ाई है, जो सीएसएस पिक्सल में होती है:

Viewport-Width: 320

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

DPR

DPR, डिवाइस पिक्सल के अनुपात का छोटा नाम है. यह उपयोगकर्ता की स्क्रीन के फ़िज़िकल पिक्सल और सीएसएस पिक्सल के अनुपात की जानकारी देता है:

DPR: 2

यह हिंट, इमेज के ऐसे सोर्स चुनने में मददगार होता है जो स्क्रीन की पिक्सल डेंसिटी के मुताबिक हों. जैसे, x डिस्क्रिप्टर, srcset एट्रिब्यूट में ऐसा करते हैं.

चौड़ाई

Width हिंट, इमेज रिसॉर्स के उन अनुरोधों पर दिखता है जिन्हें <img> या <source> टैग ने sizes एट्रिब्यूट का इस्तेमाल करके ट्रिगर किया है. sizes से ब्राउज़र को पता चलता है कि संसाधन का बाहरी साइज़ क्या होगा; Width उस बाहरी साइज़ का इस्तेमाल करके, ऐसी इमेज का अनुरोध करता है जिसका मूल साइज़, मौजूदा लेआउट के लिए सबसे सही हो.

उदाहरण के लिए, मान लीजिए कि कोई उपयोगकर्ता 320 सीएसएस पिक्सल चौड़ी स्क्रीन वाला पेज मांगता है. इस स्क्रीन का डीपीआर 2 है. डिवाइस, <img> एलिमेंट वाला एक दस्तावेज़ लोड करता है.इसमें sizes एट्रिब्यूट की वैल्यू 85vw होती है. इसका मतलब है कि सभी स्क्रीन साइज़ के लिए, व्यूपोर्ट की चौड़ाई का 85% होना चाहिए. अगर Width हिंट के लिए ऑप्ट-इन किया गया है, तो क्लाइंट इस Width हिंट को सर्वर को भेजेगा. साथ ही, <img> के src के लिए अनुरोध करेगा:

Width: 544

इस मामले में, क्लाइंट सर्वर को यह जानकारी दे रहा है कि अनुरोध की गई इमेज की इंट्रिंसिक चौड़ाई, व्यूपोर्ट की चौड़ाई (272 पिक्सल) के 85% को स्क्रीन के डीपीआर (2) से गुणा करने पर मिलने वाली वैल्यू के बराबर होगी. यह वैल्यू 544 पिक्सल है.

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

Content-DPR

आपको पहले से पता है कि स्क्रीन का डिवाइस पिक्सल अनुपात होता है. हालांकि, संसाधनों के भी अपने पिक्सल अनुपात होते हैं. संसाधन चुनने के सबसे आसान इस्तेमाल के उदाहरणों में, डिवाइसों और संसाधनों के बीच पिक्सल अनुपात एक जैसा हो सकता है. लेकिन! अगर DPR और Width हेडर, दोनों इस्तेमाल किए जा रहे हैं, तो संसाधन के बाहरी साइज़ की वजह से, दोनों में अंतर हो सकता है. ऐसे में, Content-DPR हिंट की सुविधा काम आती है.

अन्य क्लाइंट हिंट के उलट, Content-DPR सर्वर के लिए इस्तेमाल किया जाने वाला अनुरोध हेडर नहीं है. इसके बजाय, यह एक जवाब हेडर है, जिसे सर्वर को भेजना होता है. ऐसा तब करना होता है, जब किसी रिसॉर्स को चुनने के लिए DPR और Width हिंट का इस्तेमाल किया जाता है. Content-DPR की वैल्यू, इस समीकरण का नतीजा होनी चाहिए:

Content-DPR = [चुने गए इमेज रिसॉर्स का साइज़] / ([Width] / [DPR])

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

Device-Memory

तकनीकी तौर पर, Device-Memory, Device Memory API का हिस्सा है. यह मौजूदा डिवाइस में मौजूद मेमोरी की अनुमानित मात्रा को GiB में दिखाता है:

Device-Memory: 2

इस हिंट का इस्तेमाल, कम मेमोरी वाले डिवाइसों पर ब्राउज़र को भेजी जाने वाली JavaScript की मात्रा को कम करने के लिए किया जा सकता है. ऐसा इसलिए, क्योंकि JavaScript सबसे ज़्यादा संसाधन इस्तेमाल करने वाला कॉन्टेंट टाइप है, जिसे ब्राउज़र आम तौर पर लोड करते हैं. इसके अलावा, कम डीपीआर वाली इमेज भेजी जा सकती हैं. ऐसा इसलिए, क्योंकि इन्हें डिकोड करने के लिए कम मेमोरी की ज़रूरत होती है.

नेटवर्क के सुझाव

Network Information API, क्लाइंट हिंट की एक और कैटगरी उपलब्ध कराता है. इससे उपयोगकर्ता के नेटवर्क कनेक्शन की परफ़ॉर्मेंस के बारे में पता चलता है. मेरे हिसाब से, ये सबसे ज़्यादा काम के हिंट हैं. इनकी मदद से, हम उपयोगकर्ताओं के अनुभव को उनकी ज़रूरतों के मुताबिक बना सकते हैं. इसके लिए, हमें यह बदलना होगा कि हम धीमे कनेक्शन पर क्लाइंट को संसाधन कैसे उपलब्ध कराते हैं.

आरटीटी

RTT हिंट से, ऐप्लिकेशन लेयर पर राउंड ट्रिप टाइम का अनुमानित समय मिलता है. यह समय मिलीसेकंड में होता है. ट्रांसपोर्ट लेयर आरटीटी के उलट, RTT हिंट में सर्वर प्रोसेसिंग का समय शामिल होता है.

RTT: 125

यह सुझाव इसलिए काम का है, क्योंकि लोडिंग परफ़ॉर्मेंस में भूमिका की अहमियत होती है. RTT हिंट का इस्तेमाल करके, हम नेटवर्क की परफ़ॉर्मेंस के आधार पर फ़ैसले ले सकते हैं.इससे, पूरे अनुभव को तेज़ी से डिलीवर करने में मदद मिल सकती है. उदाहरण के लिए, कुछ अनुरोधों को छोड़कर.

डाउनलिंक

पेज लोड होने में लगने वाले समय के लिए, लेटेन्सी अहम होती है. हालांकि, बैंडविड्थ भी अहम होती है. मेगाबिट प्रति सेकंड (एमबीपीएस) में दिखाई गई Downlink हिंट से, उपयोगकर्ता के कनेक्शन की अनुमानित डाउनस्ट्रीम स्पीड का पता चलता है:

Downlink: 2.5

RTT के साथ-साथ, Downlink का इस्तेमाल करके यह तय किया जा सकता है कि नेटवर्क कनेक्शन की क्वालिटी के आधार पर, उपयोगकर्ताओं को कॉन्टेंट कैसे डिलीवर किया जाए.

ECT

ECT का मतलब इफ़ेक्टिव कनेक्शन टाइप है. इसकी वैल्यू, कनेक्शन टाइप की एक सूची होती है. इसमें हर टाइप, RTT और Downlink वैल्यू की तय की गई रेंज के बीच के कनेक्शन के बारे में बताता है.

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

ECT: 2g

ECT एट्रिब्यूट के लिए मान्य वैल्यू 4g, 3g, 2g, और slow-2g हैं. इस हिंट का इस्तेमाल, कनेक्शन की क्वालिटी का आकलन करने के लिए किया जा सकता है. इसके बाद, RTT और Downlink हिंट का इस्तेमाल करके, इसे बेहतर बनाया जा सकता है.

Save-Data

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

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

Save-Data: on

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

सभी को एक साथ जोड़ना

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

रिस्पॉन्सिव इमेज

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

<picture> और srcset, बेशक बेहतरीन टूल हैं. हालांकि, इस्तेमाल के जटिल उदाहरणों के लिए इन्हें डेवलप करने और बनाए रखने में समय लग सकता है. हम मार्कअप जनरेट करने की प्रोसेस को अपने-आप होने वाली प्रोसेस में बदल सकते हैं. हालांकि, ऐसा करना मुश्किल है. इसकी वजह यह है कि <picture> और srcset की सुविधाएं इतनी जटिल हैं कि उन्हें अपने-आप होने वाली प्रोसेस में बदलने के लिए, इस तरह से काम करना होगा कि उनकी फ़्लेक्सिबिलिटी बनी रहे.

क्लाइंट हिंट की मदद से, इसे आसान बनाया जा सकता है. क्लाइंट हिंट के साथ इमेज के जवाबों पर बातचीत करने का तरीका कुछ ऐसा हो सकता है:

1. अगर यह आपके वर्कफ़्लो पर लागू होता है, तो सबसे पहले Viewport-Width हिंट पर सही का निशान लगाकर, इमेज ट्रीटमेंट (यानी कि आर्ट-डायरेक्टेड इमेज) चुनें.
2. Width और DPR हिंट देखकर, इमेज का रिज़ॉल्यूशन चुनें. साथ ही, ऐसा सोर्स चुनें जो इमेज के लेआउट साइज़ और स्क्रीन डेंसिटी के हिसाब से सही हो. यह ठीक उसी तरह काम करता है जिस तरह srcset में x और w डिस्क्रिप्टर काम करते हैं.
3. ब्राउज़र के साथ काम करने वाला सबसे सही फ़ाइल फ़ॉर्मैट चुनें. Accept ज़्यादातर ब्राउज़र में ऐसा करने में हमारी मदद करता है.

मैंने अपनी काल्पनिक टिंबर कंपनी के क्लाइंट के लिए, PHP में एक इमेज चुनने की सामान्य रूटीन तैयार की है. इसमें क्लाइंट हिंट का इस्तेमाल किया जाता है. इसका मतलब है कि सभी उपयोगकर्ताओं को यह मार्कअप भेजने के बजाय:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

हमने ब्राउज़र के हिसाब से, इस सुविधा के काम करने की जानकारी को यहां दिया है:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

इस उदाहरण में, /image यूआरएल एक PHP स्क्रिप्ट है. इसके बाद, mod_rewrite से फिर से लिखे गए पैरामीटर दिए गए हैं. यह इमेज के फ़ाइल नाम और अन्य पैरामीटर लेता है, ताकि बैक-एंड स्क्रिप्ट दी गई शर्तों के हिसाब से सबसे अच्छी इमेज चुन सके.

हमें लगता है कि आपका पहला सवाल यह है कि “क्या यह सिर्फ़ बैक-एंड पर <picture> और srcset को फिर से लागू नहीं कर रहा है?”.

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

क्लाइंट हिंट की मदद से, बिना किसी नुकसान के ज़्यादा रिज़ॉल्यूशन वाली इमेज से शुरुआत की जा सकती है. इसके बाद, स्क्रीन और लेआउट के किसी भी कॉम्बिनेशन के लिए, इमेज का साइज़ डाइनैमिक तरीके से बदला जा सकता है. srcset के लिए, आपको इमेज के संभावित विकल्पों की एक तय सूची देनी होती है, ताकि ब्राउज़र उनमें से किसी एक को चुन सके. हालांकि, इस तरीके में ज़्यादा विकल्प दिए जा सकते हैं. srcset की मदद से, ब्राउज़र को वैरिएंट का एक सामान्य सेट उपलब्ध कराया जाता है. जैसे, 256w, 512w, 768w, और 1024w. वहीं, क्लाइंट-हिंट की मदद से काम करने वाला समाधान, मार्कअप के बड़े ढेर के बिना सभी चौड़ाई दिखा सकता है.

हालांकि, आपको इमेज चुनने का लॉजिक खुद लिखने की ज़रूरत नहीं है. Cloudinary, w_auto पैरामीटर का इस्तेमाल करने पर, इमेज के जवाब तैयार करने के लिए क्लाइंट हिंट का इस्तेमाल करता है. साथ ही, उसने देखा कि क्लाइंट हिंट की सुविधा वाले ब्राउज़र का इस्तेमाल करने पर, मीडियन उपयोगकर्ताओं ने 42% कम बाइट डाउनलोड किए.

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

धीमे नेटवर्क पर उपयोगकर्ताओं की मदद करना

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

Sconnie Timber की साइट के लिए, हम नेटवर्क की स्पीड कम होने पर लोड कम करने के लिए कदम उठाते हैं. इसके लिए, हम बैक-एंड कोड में Save-Data, ECT, RTT, और Downlink हेडर की जांच करते हैं. ऐसा होने पर, हम नेटवर्क क्वालिटी का स्कोर जनरेट करते हैं. इसका इस्तेमाल यह तय करने के लिए किया जा सकता है कि हमें उपयोगकर्ता के बेहतर अनुभव के लिए हस्तक्षेप करना चाहिए या नहीं. नेटवर्क का यह स्कोर 0 और 1 के बीच है. इसमें 0 सबसे खराब और 1 सबसे अच्छी नेटवर्क क्वालिटी है.

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

हालांकि, अगर Save-Data मौजूद नहीं है, तो हम आगे बढ़ते हैं और ECT, RTT, और Downlink के सुझावों की वैल्यू का आकलन करते हैं. इससे हमें एक ऐसा स्कोर मिलता है जिससे नेटवर्क कनेक्शन की क्वालिटी के बारे में पता चलता है. नेटवर्क स्कोर जनरेट करने का सोर्स कोड Github पर उपलब्ध है. इसका मतलब यह है कि अगर हम नेटवर्क से जुड़े संकेतों का इस्तेमाल कुछ इस तरह से करते हैं, तो हम उन लोगों के लिए अनुभव को बेहतर बना सकते हैं जो धीमे नेटवर्क का इस्तेमाल कर रहे हैं.

जब साइटें, क्लाइंट हिंट से मिली जानकारी के हिसाब से काम करती हैं, तो हमें “सभी या कोई नहीं” वाला तरीका अपनाने की ज़रूरत नहीं होती. हम यह तय कर सकते हैं कि कौनसे संसाधन भेजने हैं. हम रिस्पॉन्सिव इमेज चुनने के लॉजिक में बदलाव कर सकते हैं, ताकि नेटवर्क की क्वालिटी खराब होने पर, डिसप्ले के लिए हल्की क्वालिटी वाली इमेज भेजी जा सकें. इससे इमेज को तेज़ी से लोड करने में मदद मिलती है.

इस उदाहरण में, हम देख सकते हैं कि धीमे नेटवर्क पर साइटों की परफ़ॉर्मेंस को बेहतर बनाने के लिए, क्लाइंट हिंट का क्या असर पड़ता है. यहां एक ऐसी साइट का WebPagetest वॉटरफ़ॉल दिया गया है जो क्लाइंट हिंट के हिसाब से नहीं बदलती. यह साइट, धीमे नेटवर्क पर काम करती है:

अब उसी साइट के लिए, उसी धीमे कनेक्शन पर वॉटरफ़ॉल देखें. हालांकि, इस बार साइट, पेज के गैर-ज़रूरी संसाधनों को हटाने के लिए क्लाइंट हिंट का इस्तेमाल करती है:

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

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

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

यहां "4g", ECT हेडर में बताए गए सबसे बेहतर क्वालिटी वाले नेटवर्क कनेक्शन को दिखाता है. अगर हम $ect को "4g" पर सेट करते हैं, तो क्लाइंट हिंट की सुविधा के साथ काम न करने वाले ब्राउज़र पर इसका कोई असर नहीं पड़ेगा. ऑप्ट-इन एफ़टीडब्ल्यू!

उन कैश मेमोरी का ध्यान रखें!

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

Vary: DPR, Width

हालांकि, इसमें एक बड़ी चेतावनी है: आपको कभी भी बार-बार बदलने वाले हेडर (जैसे कि Cookie) पर Vary कैश मेमोरी में सेव किए जा सकने वाले जवाब नहीं चाहिए, क्योंकि वे संसाधन कैश मेमोरी में सेव नहीं किए जा सकते. इस जानकारी के आधार पर, हो सकता है कि आप RTT या Downlink जैसे क्लाइंट हिंट हेडर पर Vary न करना चाहें, क्योंकि ये कनेक्शन फ़ैक्टर हैं और इनमें अक्सर बदलाव हो सकता है. अगर आपको उन हेडर के रिस्पॉन्स में बदलाव करना है, तो सिर्फ़ ECT हेडर को कुंजी के तौर पर इस्तेमाल करें. इससे कैश मेमोरी में मौजूद डेटा के न मिलने की समस्या कम हो जाएगी.

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

सर्विस वर्कर में क्लाइंट के संकेत

कॉन्टेंट नेगोशिएशन की सुविधा अब सिर्फ़ सर्वर के लिए नहीं है! सर्विस वर्कर, क्लाइंट और सर्वर के बीच प्रॉक्सी के तौर पर काम करते हैं. इसलिए, आपके पास यह कंट्रोल होता है कि JavaScript के ज़रिए संसाधनों को कैसे डिलीवर किया जाए. इसमें क्लाइंट हिंट शामिल हैं. सर्विस वर्कर के fetch इवेंट में, event ऑब्जेक्ट के request.headers.get तरीके का इस्तेमाल करके, किसी संसाधन के अनुरोध हेडर को इस तरह पढ़ा जा सकता है:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

आपने जिस भी क्लाइंट हिंट हेडर के लिए ऑप्ट इन किया है उसे इस तरह से पढ़ा जा सकता है. हालांकि, इस जानकारी को पाने का यह इकलौता तरीका नहीं है. नेटवर्क के हिसाब से दिए गए सुझावों को, navigator ऑब्जेक्ट में मौजूद इन JavaScript प्रॉपर्टी में पढ़ा जा सकता है:

ये एपीआई हर जगह उपलब्ध नहीं हैं. इसलिए, आपको in ऑपरेटर से यह पता करना होगा कि ये एपीआई कहां-कहां उपलब्ध हैं:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

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

रैप अप

क्लाइंट हिंट की मदद से, हम उपयोगकर्ताओं के लिए अनुभव को पूरी तरह से प्रोग्रेसिव तरीके से बेहतर बना सकते हैं. हम उपयोगकर्ता के डिवाइस की क्षमताओं के आधार पर मीडिया दिखा सकते हैं. इससे रिस्पॉन्सिव इमेज दिखाना, <picture> और srcset पर भरोसा करने के मुकाबले ज़्यादा आसान हो जाता है. खास तौर पर, इस्तेमाल के मुश्किल मामलों के लिए. इससे हमें डेवलपमेंट में लगने वाले समय और मेहनत को कम करने में मदद मिलती है. साथ ही, हम संसाधनों, खास तौर पर इमेज को इस तरह से ऑप्टिमाइज़ कर पाते हैं कि वे उपयोगकर्ता की स्क्रीन को और srcset से ज़्यादा बेहतर तरीके से टारगेट कर सकें.

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

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

संसाधन

• क्लाइंट हिंट की मदद से, अपने-आप रिस्पॉन्सिव इमेज जनरेट करने की सुविधा
• क्लाइंट हिंट और रिस्पॉन्सिव इमेज—Chrome 67 में क्या बदलाव हुए
• क्लाइंट हिंट का इस्तेमाल करें! (Slides)
• Save-Data की मदद से, तेज़ और हल्के ऐप्लिकेशन डिलीवर करना

इस लेख पर अहम सुझाव देने और इसमें बदलाव करने के लिए, इलिया ग्रिगोरिक, एरिक पोर्टिस, जेफ़ पॉज़निक, योआव वेइस, और एस्तेल वेइल का धन्यवाद.