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

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

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

यह कॉन्टेंट पर बातचीत के बारे में है

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

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

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

सभी ब्राउज़र पर JPEG, PNG, और GIF जैसे इमेज फ़ॉर्मैट काम करते हैं. इस मामले में, 'स्वीकार करें' बताता है कि ब्राउज़र 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: 320

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

डीपीआर

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

DPR: 2

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

चौड़ाई

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

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

Width: 544

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

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

कॉन्टेंट-डीपीआर

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

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

Content-DPR = [इमेज के संसाधन का चुना गया साइज़] / ([Width] / [DPR])

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

डिवाइस की मेमोरी

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

Device-Memory: 2

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

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

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: on

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

सभी को एक साथ जोड़ा जा रहा है

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

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

रिस्पॉन्सिव इमेज के सबसे आसान इस्तेमाल को छोड़कर, बाकी सभी जटिल काम हो सकते हैं. अगर आपके पास अलग-अलग स्क्रीन साइज़ और अलग-अलग फ़ॉर्मैट के लिए, एक ही इमेज के अलग-अलग और वैरिएंट हैं, तो क्या होगा? वह मार्कअप बहुत बहुत आसान हो जाता है. इसे गलत माना जा सकता है. साथ ही, ज़रूरी सिद्धांतों (जैसे कि 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" से शुरू करते हैं, तो जिन ब्राउज़र में क्लाइंट हिंट काम नहीं करते उन पर कोई असर नहीं पड़ेगा. FTW के लिए ऑप्ट-इन करें!

कैश मेमोरी में सेव डेटा का ध्यान रखें!

एचटीटीपी हेडर के आधार पर रिस्पॉन्स में बदलाव करने पर, आपको इस बात की जानकारी होनी चाहिए कि कैश मेमोरी उस संसाधन के लिए आने वाले समय में फ़ेच को कैसे मैनेज करेगी. यहां 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 प्रॉपर्टी में पढ़ा जा सकता है:

फ़ाइल टाइप के लिए Imagemin प्लगिन.

क्लाइंट का संकेत	JS मिलता है
`ईसीटी`	`navigator.connection.effectiveType`
`आरटीटी`	`navigator.कनेक्शन.rtt`
`डेटा सेव करें`	`navigator.connection.saveData`
`डाउनलिंक`	`navigator.connection.downlink`
`डिवाइस की मेमोरी`	`navigator.deviceMemory`

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

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

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

रैप कर रहा है

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

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

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

रिसॉर्स

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

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