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

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>

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

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

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

क्लाइंट हिंट की मदद से, रिसॉर्स को अपने-आप चुनना

गहरी सांस लें और नीचे दिए गए उदाहरण पर ध्यान दें:

<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, Accept अनुरोध हेडर की मदद से, WebP फ़ॉर्मैट के साथ काम करने की जानकारी देता है. इसी तरह, Edge का नया ब्राउज़र, Accept हेडर की मदद से JPEG XR के साथ काम करने की जानकारी देता है.

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

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

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

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