Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

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" />

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

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

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

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

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

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

मूल साइज़: मीडिया रिसॉर्स के असल डाइमेंशन. उदाहरण के लिए, अगर आप 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 के स्क्रीन डिवाइस पिक्सल रेशियो वाले डिवाइस पर इंस्टॉल है (जैसे, Retina स्क्रीन), तो 2x इमेज का अनुरोध किया जाता है. 2x इमेज का डेंसिटी के हिसाब से सही किया गया इंट्रिन्सिक साइज़ 320x240 है, क्योंकि 640x480 को 2 से भाग देने पर 320x240 आता है.

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

इमेज के मूल साइज़ और बाहरी साइज़ के बीच के अंतर को दिखाने वाला इलस्ट्रेशन. इसमें 320x240 पिक्सल साइज़ का एक बॉक्स दिखाया गया है, जिस पर INTRINSIC SIZE का लेबल लगा है. इसके अंदर 256x192 पिक्सल का एक छोटा बॉक्स है, जो सीएसएस के साथ एचटीएमएल img एलिमेंट को दिखाता है. इस बॉक्स पर EXTRINSIC SIZE लेबल लगा है. दाईं ओर एक बॉक्स है, जिसमें एलिमेंट पर लागू सीएसएस है. यह img एलिमेंट के लेआउट में बदलाव करती है, ताकि इसका बाहरी साइज़ इसके मूल साइज़ से अलग हो. — **पहली इमेज**. इमेज के मूल साइज़ और बाहरी साइज़ का इलस्ट्रेशन. लेआउट फ़ैक्टर लागू होने के बाद, इमेज को उसका बाहरी साइज़ मिलता है. इस मामले में, `width: 256px;` और `height: 192px;` के सीएसएस नियम लागू करने से, 320x240 साइज़ की इमेज, 256x192 साइज़ में बदल जाती है.

कुछ शब्दावली के बारे में जानने के बाद, आइए डिवाइस के हिसाब से उपलब्ध क्लाइंट हिंट की सूची के बारे में जानें.

Viewport-Width

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

Viewport-Width: 320

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

DPR

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

DPR: 2

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

चौड़ाई

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

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

Width: 544

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

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

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

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

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

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

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

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

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

Device-Memory: 2

ध्यान दें: इस जानकारी का इस्तेमाल उपयोगकर्ताओं के फ़िंगरप्रिंट के लिए किया जा सकता है. इसलिए, Device-Memory की वैल्यू को जान-बूझकर कम सटीक रखा गया है. मान्य वैल्यू 0.25, 0.5, 1, 2, 4, और 8 हैं.

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

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

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

आरटीटी

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

RTT: 125

ध्यान दें: फ़िंगरप्रिंटिंग से बचने के लिए, RTT की वैल्यू को सबसे नज़दीकी 25 मिलीसेकंड में राउंड किया जाता है.

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

डाउनलिंक

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

Downlink: 2.5

ध्यान दें: Downlink की वैल्यू को 25 किलोबिट प्रति सेकंड के सबसे नज़दीकी गुणज में बदल दिया जाता है. क्योंकि फ़िंगरप्रिंटिंग की वजह से, ऐसा करना ज़रूरी है.

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

ECT

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

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

ECT: 2g

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

Save-Data

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

ध्यान दें: सभी क्लाइंट हिंट में से, Save-Data ही एक ऐसा क्लाइंट हिंट है जिसके लिए Accept-CH का इस्तेमाल करके ऑप्ट इन नहीं किया जा सकता. सिर्फ़ उपयोगकर्ता यह कंट्रोल कर सकता है कि यह हिंट भेजा जाए या नहीं. इसके लिए, उसे Android डिवाइसों पर Chrome की डेटा बचाने की सुविधा को टॉगल करना होगा.

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

Save-Data: on

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

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

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

रिस्पॉन्सिव (डिवाइस के हिसाब से आकार बदलने वाली) इमेज

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

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

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

अगर आपके वर्कफ़्लो पर लागू होता है, तो पहले इमेज ट्रीटमेंट (यानी कि आर्ट-डायरेक्टेड इमेजरी) चुनें. इसके लिए, Viewport-Width हिंट देखें.
इमेज का रिज़ॉल्यूशन चुनने के लिए, Width हिंट और DPR हिंट देखें. इसके बाद, ऐसा सोर्स चुनें जो इमेज के लेआउट साइज़ और स्क्रीन डेंसिटी के हिसाब से सही हो. यह ठीक उसी तरह काम करता है जिस तरह srcset में x और w डिस्क्रिप्टर काम करते हैं.
ब्राउज़र के साथ काम करने वाला सबसे सही फ़ाइल फ़ॉर्मैट चुनें. 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 पर उपलब्ध है. इससे हमें यह पता चलता है कि अगर हम नेटवर्क से जुड़े हिंट का इस्तेमाल किसी तरह से करें, तो हम धीमे नेटवर्क का इस्तेमाल करने वाले लोगों के लिए अनुभव को बेहतर बना सकते हैं.

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

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

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

Sconnie Timber की साइट का WebPagetest वॉटरफ़ॉल, जो धीमे इंटरनेट कनेक्शन पर सभी रिसॉर्स लोड कर रहा है. — **तीसरी इमेज**. धीमे कनेक्शन पर इमेज, स्क्रिप्ट, और फ़ॉन्ट लोड करने वाली साइट.

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

Sconnie Timber साइट का WebPagetest वॉटरफ़ॉल, क्लाइंट हिंट का इस्तेमाल करके यह तय करता है कि धीमे इंटरनेट कनेक्शन पर गै़र-ज़रूरी रिसॉर्स लोड न किए जाएं. — **चौथी इमेज**. एक ही कनेक्शन पर एक ही साइट, सिर्फ़ “अच्छे” रिसॉर्स को छोड़कर, तेज़ी से लोड होने वाले रिसॉर्स को शामिल किया जाता है.

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

इसके अलावा, क्लाइंट हिंट का इस्तेमाल उन ब्राउज़र के लिए भी किया जा सकता है जो इन्हें सपोर्ट नहीं करते. इससे ब्राउज़र के अनुभव पर कोई असर नहीं पड़ता. उदाहरण के लिए, अगर हमें 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!
    })(),
  );
});

चेतावनी: सभी ब्राउज़र, क्लाइंट हिंट के साथ काम नहीं करते. इसलिए, आपको यह देखना होगा कि event.request.headers.get कौनसी वैल्यू दिखाता है. इसके अलावा, window.devicePixelRatio या window.innerWidth जैसे JS के बराबर के एलिमेंट को IndexedDB में रिकॉर्ड किया जा सकता है. इसे सर्विस वर्कर के स्कोप में ऐक्सेस किया जा सकता है.

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

फ़ाइल टाइप के लिए Imgmin प्लगिन.
क्लाइंट हिंट	JS के बराबर
`ECT`	`navigator.connection.effectiveType`
आरटीटी	navigator.connection.rtt
`Save-Data`	`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 पर आधारित ब्राउज़र में उपलब्ध हैं. हालांकि, इन्हें इस तरह से इस्तेमाल किया जा सकता है कि ये उन ब्राउज़र पर असर न डालें जिनमें ये काम नहीं करते. क्लाइंट हिंट का इस्तेमाल करके, सभी के लिए उपलब्ध और ज़रूरत के हिसाब से काम करने वाले अनुभव बनाएं. ये अनुभव, हर उपयोगकर्ता के डिवाइस की क्षमताओं और उनके कनेक्ट किए गए नेटवर्क के बारे में जानकारी देते हैं. उम्मीद है कि ब्राउज़र बनाने वाली अन्य कंपनियां भी इनकी अहमियत समझेंगी और इन्हें लागू करने की कोशिश करेंगी.

संसाधन

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