इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

Jeremy Wagner

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

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

सिर्फ़ कॉन्टेंट के लिए कीमत तय करने की ज़रूरत है

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

कॉन्टेंट के लिए मोल-भाव करने का एक उदाहरण यह है 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 फ़ंक्शन का इस्तेमाल किया जा सकता है. आप ये ऑप्ट-इन हेडर http-equiv के साथ भी सेट कर सकते हैं एट्रिब्यूट <meta> टैग इस्तेमाल करने के लिए:

<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 हो (जैसे, रेटिना स्क्रीन), 2x इमेज का अनुरोध किया गया है. इसका डेंसिटी-करेक्ट किया गया इंट्रिंसिक साइज़ 2x इमेज का साइज़ 320x240 है, क्योंकि 640x480 को 2 से भाग देने पर नतीजा 320x240 है.

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

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

चलिए, अब कुछ खास शब्दावली में उपलब्ध डिवाइस के बारे में बात करते हैं. क्लाइंट के लिए सलाह उपलब्ध होंगी.

व्यूपोर्ट की चौड़ाई

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

Viewport-Width: 320

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

DPR

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

DPR: 2

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

चौड़ाई

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

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

Width: 544

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

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

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

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

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

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

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

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

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

Device-Memory: 2

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

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

नेटवर्क से जुड़े सुझाव

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 के लिए, Accept-CH के साथ ऑप्ट इन नहीं किया जा सकता. Android डिवाइसों पर, Chrome की डेटा बचाने की सेटिंग की सुविधा को टॉगल करके, सिर्फ़ उपयोगकर्ता यह कंट्रोल कर सकता है कि यह संकेत भेजा जाए या नहीं.

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

Save-Data: on

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

सब कुछ एक साथ जोड़ना

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

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

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

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

स्कोनी का WebPagetest झरना
धीमे नेटवर्क कनेक्शन पर सभी संसाधन लोड करने में टिंबर साइट. — **तीसरी इमेज**. ऐसे संसाधन जो इमेज को बहुत ज़्यादा लोड करते हैं, स्क्रिप्ट और फ़ॉन्ट के साथ काम करता है.

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

स्कोनी का 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

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

फ़ाइल टाइप के लिए Imagemin प्लगिन.
क्लाइंट संकेत	JS के बराबर
`ईसीटी`	`navigator.connection.effectiveType`
`आरटीटी`	`navigator.connection.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 पर काम करते हैं ब्राउज़र— उनका उपयोग इस तरह से किया जा सकता है कि वे बड़ी न हों जो ब्राउज़र पर काम नहीं करते. सही ऑडियंस बनाने के लिए, क्लाइंट हिंट का इस्तेमाल करें बिना किसी भेदभाव के हर उपयोगकर्ता के डिवाइस के हिसाब से, बिना किसी भेदभाव के सभी को एक जैसा अनुभव देना और किन नेटवर्क से कनेक्ट किया जाता है. उम्मीद है कि अन्य ब्राउज़र वेंडर, आपको उनकी वैल्यू दिखेगी और उन्हें लागू करने का इरादा दिखेगा.

संसाधन

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