क्लाइंट के संकेतों की मदद से, संसाधन चुनने के विकल्प को ऑटोमेट करना

Ilya Grigorik

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

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

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

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

परफ़ॉर्मेंस को लेकर जागरूक डेवलपर की कहानी

इमेज ऑप्टिमाइज़ेशन स्पेस के ज़रिए खोज करने के दो अलग-अलग चरण होते हैं: बिल्ड-टाइम और रन-टाइम.

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

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

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

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

1. बेहतरीन कंप्रेशन पाने के लिए, वे हर क्लाइंट के लिए सबसे सही इमेज फ़ॉर्मैट का इस्तेमाल करना चाहती हैं: Chrome के लिए WebP, Edge के लिए JPEG XR, और बाकी के लिए JPEG.
2. सबसे अच्छी विज़ुअल क्वालिटी पाने के लिए, उन्हें अलग-अलग रिज़ॉल्यूशन वाली हर इमेज के अलग-अलग वैरिएंट जनरेट करने होंगे: 1x, 1.5x, 2x, 2.5x, 3x, और शायद कुछ और वैरिएंट.
3. गै़र-ज़रूरी पिक्सल डिलीवर करने से बचने के लिए, उन्हें यह समझना होगा कि "उपयोगकर्ता के व्यूपोर्ट का 50% असल में क्या मतलब है"—व्यूपोर्ट की चौड़ाई अलग-अलग है!
4. आम तौर पर, वे बेहतर अनुभव देना चाहती हैं, ताकि धीमे नेटवर्क का इस्तेमाल करने वाले लोग अपने-आप कम रिज़ॉल्यूशन ले पाएं. आखिरकार, अब बात करने का समय है.
5. यह ऐप्लिकेशन, उपयोगकर्ता के कुछ ऐसे कंट्रोल भी उपलब्ध कराता है जिनसे इस बात पर असर पड़ता है कि किस इमेज रिसॉर्स को फ़ेच किया जाना चाहिए. इसलिए, इसमें ऐसी चीज़ें भी शामिल होती हैं जिन्हें शामिल किया जाना चाहिए.

ओह, और फिर डिज़ाइनर को एहसास होता है कि उन्हें 100% चौड़ाई वाली एक अलग इमेज दिखानी होगी, अगर व्यूपोर्ट का साइज़ छोटा है, ताकि आसानी से पढ़ा जा सके. इसका मतलब है कि अब हमें एक और एसेट के लिए, इसी प्रक्रिया को दोहराना होगा और फिर व्यूपोर्ट के साइज़ पर, 'फ़ेच कंडिशनल' लागू करना होगा. क्या मैंने बताया है कि यह काम मुश्किल है? ठीक है, ठीक है, शुरू करते हैं. picture एलिमेंट हमें बहुत आगे ले जाएगा:

<picture>
    <!-- serve WebP to Chrome and Opera -->
    <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w,
        /image/thing-800.webp 800w, /image/thing-1200.webp 1200w,
        /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w"
    type="image/webp">
    <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w,
        /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w,
        /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w"
    type="image/webp">
    <!-- serve JPEGXR to Edge -->
    <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.jpgxr 200w, /image/thing-400.jpgxr 400w,
        /image/thing-800.jpgxr 800w, /image/thing-1200.jpgxr 1200w,
        /image/thing-1600.jpgxr 1600w, /image/thing-2000.jpgxr 2000w"
    type="image/vnd.ms-photo">
    <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.jpgxr 200w, /image/thing-crop-400.jpgxr 400w,
        /image/thing-crop-800.jpgxr 800w, /image/thing-crop-1200.jpgxr 1200w,
        /image/thing-crop-1600.jpgxr 1600w, /image/thing-crop-2000.jpgxr 2000w"
    type="image/vnd.ms-photo">
    <!-- serve JPEG to others -->
    <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w,
        /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w,
        /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w">
    <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w,
        /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w,
        /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w">
    <!-- fallback for browsers that don't support picture -->
    <img src="/image/thing.jpg" width="50%">
</picture>

हमने आर्ट डायरेक्शन और फ़ॉर्मैट चुनने का काम मैनेज किया है. साथ ही, क्लाइंट के डिवाइस के DPR और व्यूपोर्ट की चौड़ाई को ध्यान में रखते हुए, हर इमेज के छह वैरिएंट दिए हैं. बहुत ही बढ़िया!

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

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

क्लाइंट के संकेतों की मदद से संसाधन चुनने की प्रोसेस को ऑटोमेट करना

एक गहरी सांस लें, अपने अविश्वास को भूल जाएं और अब नीचे दिए गए उदाहरण पर विचार करें:

<meta http-equiv="Accept-CH" content="DPR, Viewport-Width, Width">
...
<picture>
    <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing">
    <img sizes="100vw" src="/image/thing-crop">
</picture>

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

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

Chrome 46, DPR, Width, और Viewport-Width से जुड़े संकेतों के साथ नेटिव सहायता उपलब्ध कराता है. संकेत डिफ़ॉल्ट रूप से बंद होते हैं और ऊपर दिया गया <meta http-equiv="Accept-CH" content="...">, ऑप्ट-इन सिग्नल के तौर पर काम करता है. यह Chrome को, बताए गए हेडर को आउटगोइंग अनुरोधों में जोड़ने के लिए कहता है. इसके बाद, चलिए सैंपल इमेज अनुरोध के लिए अनुरोध और रिस्पॉन्स हेडर की जांच करते हैं:

Chrome, WebP फ़ॉर्मैट के लिए विज्ञापन दिखाने के लिए, अनुरोध स्वीकार करने के हेडर के ज़रिए विज्ञापन दिखाता है. नया Edge ब्राउज़र, स्वीकार हेडर के ज़रिए JPEG XR के साथ काम करता है.

अगले तीन अनुरोध हेडर, क्लाइंट-हिंट हेडर हैं. ये क्लाइंट के डिवाइस के डिवाइस पिक्सल का अनुपात (3x), लेआउट व्यूपोर्ट की चौड़ाई (460 पिक्सल), और रिसॉर्स के डिसप्ले की चौड़ाई (230 पिक्सल) दिखाते हैं. इससे सर्वर को सभी ज़रूरी जानकारी मिलती है, ताकि वह अपनी नीतियों के आधार पर इमेज का सबसे सही वैरिएंट चुन सके. जैसे, पहले से जनरेट किए गए संसाधनों की उपलब्धता, किसी संसाधन को फिर से कोड में बदलने या उसका साइज़ बदलने की कीमत, संसाधन की लोकप्रियता, सर्वर का मौजूदा लोड वगैरह. इस मामले में, सर्वर DPR और Width संकेत का इस्तेमाल करता है और WebP संसाधन दिखाता है, जैसा कि Content-Type, Content-DPR, और Vary हेडर से दिखाया जाता है.

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

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

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

सर्विस वर्कर की मदद से, चुने गए रिसॉर्स को कंट्रोल करना

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

self.onfetch = function(event) {
    var req = event.request.clone();
    console.log("SW received request for: " + req.url)
    for (var entry of req.headers.entries()) {
    console.log("\t" + entry[0] +": " + entry[1])
    }
    ...
}

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

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

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

क्लाइंट की ओर से अक्सर पूछे जाने वाले सवालों के जवाब दिए जाते हैं

1. क्लाइंट हिंट कहां उपलब्ध हैं? Chrome 46 में भेजा गया. Firefox और Edge पर टैप करें.

2. क्लाइंट संकेत ऑप्ट-इन क्यों कर रहे हैं? हम उन साइटों के लिए ओवरहेड कम करना चाहते हैं जो क्लाइंट हिंट का इस्तेमाल नहीं करेंगी. क्लाइंट संकेत की सुविधा चालू करने के लिए, साइट को पेज मार्कअप में Accept-CH हेडर या इसके बराबर का <meta http-equiv> निर्देश देना चाहिए. इनमें से किसी भी उपलब्ध होने पर, उपयोगकर्ता एजेंट सभी सबरिसॉर्स के अनुरोधों के लिए सही संकेत जोड़ेगा. आने वाले समय में, हम किसी खास ऑरिजिन के लिए इस प्राथमिकता को लागू रखने का एक और तरीका उपलब्ध करा सकते हैं. इससे नेविगेशन के अनुरोधों पर भी यही संकेत दिए जा सकेंगे.

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

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

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

6. <insert my private hint> का क्या होगा? ServiceWorker, डेवलपर को सभी आउटगोइंग अनुरोधों को रोकने और उनमें बदलाव करने (उदाहरण के लिए, नए हेडर जोड़ने) की सुविधा देता है. उदाहरण के तौर पर, मौजूदा कनेक्शन टाइप को दिखाने के लिए, NetInfo पर आधारित जानकारी जोड़ना आसान है. "ServiceWorker के साथ क्षमता की रिपोर्टिंग" देखें. Chrome में भेजे गए "नेटिव" संकेत (डीपीआर, चौड़ाई, संसाधन की चौड़ाई) ब्राउज़र में लागू किए जाते हैं, क्योंकि सिर्फ़ एसडब्ल्यू पर आधारित लागू करने से सभी इमेज अनुरोधों में देरी हो सकती है.

7. मुझे इस बारे में ज़्यादा जानकारी कहां मिल सकती है, ज़्यादा डेमो कहां देखे जा सकते हैं, और इनके बारे में क्या जानकारी मिल सकती है? ज़्यादा जानकारी देने वाला दस्तावेज़ देखें. अगर आपका कोई सुझाव या सवाल है, तो GitHub पर समस्या को खोलें.