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

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

इलिया ग्रिगोरिक

Twitter होम पेज

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

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

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

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

बेहतर परफ़ॉर्म करने वाले डेवलपर की कहानी

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

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

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

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

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

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

ओह, और फिर डिज़ाइनर को पता चलता है कि अगर व्यूपोर्ट का साइज़ छोटा है, ताकि टेक्स्ट पढ़ने में आसानी हो, तो उसे 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 से पहले से लोड किए जाने वाले स्कैनर को ऑप्टिमाइज़ नहीं किया जा सकेगा. ठीक है.

उन सीमाओं को छोड़ दें, तो यह कारगर है. खैर, कम से कम इस खास ऐसेट के लिए. यहां असली और लंबे समय तक चलने वाली चुनौती यह है कि हम हर एसेट के लिए डिज़ाइनर या डेवलपर से इस तरह का कोड बनाने की उम्मीद नहीं कर सकते. पहली कोशिश में यह दिमागी पहेली काफ़ी मज़ेदार होती है, लेकिन इसके तुरंत बाद यह अपनी पसंद खो देती है. हमें ऑटोमेशन की ज़रूरत है. शायद 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">

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

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

क्लाइंट संकेत कहां उपलब्ध होते हैं? Chrome 46 में भेजा जाता है. Firefox औरEdge में सुझाव के तहत.
क्लाइंट संकेतों के लिए ऑप्ट-इन क्यों करते हैं? हम उन साइटों के लिए ओवरहेड कम करना चाहते हैं जो क्लाइंट संकेतों का इस्तेमाल नहीं करेंगी. क्लाइंट संकेतों को चालू करने के लिए, साइट को पेज मार्कअप में Accept-CH हेडर या इसके बराबर <meta http-equiv> डायरेक्टिव देना चाहिए. अगर दोनों में से कोई भी मौजूद हो, तो उपयोगकर्ता एजेंट सभी सबरिसॉर्स अनुरोधों में सही संकेत जोड़ देगा. आने वाले समय में, हम किसी खास ऑरिजिन के लिए इस प्राथमिकता को बनाए रखने के लिए एक और तरीका उपलब्ध करा सकते हैं. इससे नेविगेशन के अनुरोधों पर यही संकेत मिलेंगे.
अगर हमारे पास ServiceWorker हैं, तो हमें क्लाइंट के सुझावों की ज़रूरत क्यों होती है? ServiceWorker के पास लेआउट, संसाधन और व्यूपोर्ट की चौड़ाई की जानकारी का ऐक्सेस नहीं है. महंगे राउंडट्रिप लागू किए बिना और इमेज के अनुरोध में बहुत ज़्यादा देरी किए बिना ऐसा नहीं किया जा सकता - उदाहरण के लिए, जब प्रीलोड पार्सर से कोई इमेज का अनुरोध शुरू होता है. क्लाइंट हिंट, ब्राउज़र के साथ इंटिग्रेट हो जाते हैं, ताकि इस डेटा को अनुरोध के तौर पर उपलब्ध कराया जा सके.
क्या क्लाइंट संकेत सिर्फ़ इमेज से जुड़े संसाधनों के लिए हैं? DPR, व्यूपोर्ट-विड्थ, और विड्थ हिंट के पीछे मुख्य इस्तेमाल का उदाहरण, इमेज एसेट के लिए संसाधन चुनने को चालू करना है. हालांकि, सभी सबरिसॉर्स के लिए एक जैसे संकेत दिए जाते हैं, चाहे उनका टाइप किसी भी तरह का हो -- जैसे कि सीएसएस और JavaScript के अनुरोधों को भी एक ही जानकारी मिलती है. साथ ही, इसका इस्तेमाल उन रिसॉर्स को ऑप्टिमाइज़ करने के लिए किया जा सकता है.
इमेज के कुछ अनुरोध, चौड़ाई की जानकारी नहीं देते. ऐसा क्यों? ऐसा हो सकता है कि ब्राउज़र को डिसप्ले की सही चौड़ाई का पता न हो, क्योंकि साइट, इमेज के स्वाभाविक साइज़ पर निर्भर होती है. इसलिए, ऐसे अनुरोधों के लिए और उन अनुरोधों के लिए चौड़ाई संकेत हटा दिया जाता है जिनमें "डिसप्ले विड्थ" नहीं होती है - जैसे कि एक JavaScript संसाधन. चौड़ाई के लिए सुझाव पाने के लिए, पक्का करें कि आपने अपनी इमेज पर साइज़ की वैल्यू दी हो.
<insert myपसंदीदा hint> का क्या होगा? ServiceWorker की मदद से, डेवलपर को भेजे जाने वाले सभी अनुरोधों को रोकने और उनमें बदलाव करने (जैसे, नए हेडर जोड़ना) किया जा सकता है. उदाहरण के लिए, मौजूदा कनेक्शन टाइप को दिखाने के लिए, NetInfo पर आधारित जानकारी को जोड़ना आसान है -- "ServiceWorker के साथ क्षमता रिपोर्टिंग" देखें. Chrome में शिप किए जाने वाले "नेटिव" संकेतों (DPR, विड्थ, रिसॉर्स-विड्थ) को ब्राउज़र में लागू किया जाता है, क्योंकि एसडब्ल्यू-आधारित प्रोसेस पर पूरी तरह से लागू करने से सभी इमेज अनुरोधों में देरी होती है.
मुझे कहां से ज़्यादा जानकारी मिल सकती है, ज़्यादा डेमो देखें, और इनके बारे में क्या जानकारी पाएं? जानकारी देने वाला दस्तावेज़ देखें. अगर आपका कोई सुझाव, शिकायत या राय है या कुछ और पूछना है, तो GitHub पर समस्या के बारे में बताएं.