Frontend interview: Client Hints के साथ प्राइवेसी-सुरक्षित रिस्पॉन्सिव इमेज पाइपलाइन आप कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

एक कंटेंट साइट फ़ोन, टैबलेट और डेस्कटॉप पर विभिन्न चौड़ाई और DPR मानों पर इमेज सर्व करती है। प्रोडक्ट टीम पहले व्यू में डेटा ट्रांसफर कम करना चाहती है, जबकि CDN को चिंता है कि प्रत्येक Width और DPR के लिए एक कैश एंट्री बनने से कैश विखंडित (fragment) हो जाएगा। लीगल टीम केवल आवश्यक डिवाइस जानकारी की मांग करती है। पाइपलाइन डिज़ाइन करें, Client Hints के बिना व्यवहार समझाएं, CLS और डुप्लिकेट डाउनलोड को रोकें, और परिभाषित करें कि आप परिणाम को कैसे मापेंगे।

यह ब्राउज़र रिसोर्स चयन, HTTP कैशिंग, परफ़ॉर्मेंस, एक्सेसिबिलिटी और प्रोग्रेसिव एन्हांसमेंट का परीक्षण करता है। चौड़ाई, DPR और ट्रैफ़िक मापने योग्य वेरिएबल हैं; बिना डेटा के किसी निश्चित प्रतिशत लाभ का वादा न करें।

इंटरव्यूअर क्या जांच रहा है

• क्या आप srcset और sizes के साथ वास्तविक रेंडर किए गए स्लॉट का वर्णन कर सकते हैं ताकि ब्राउज़र एक सही विकल्प चुन सके।
• क्या आप Accept-CH, बाद के रिक्वेस्ट्स, Vary और CDN कैश की (key) को एक डेटा फ्लो में जोड़ सकते हैं।
• क्या आप हाई-कार्डिनैलिटी हिंट्स से होने वाले प्राइवेसी, फ़िंगरप्रिंटिंग और कैश-विस्फोट के जोखिमों को पहचानते हैं।
• क्या आप जावास्क्रिप्ट-स्वतंत्र फ़ॉलबैक, आयाम (dimension) रिज़र्वेशन, alt और एक मेज़रमेंट लूप प्रदान करते हैं।

पहले स्पष्ट करने योग्य प्रश्न

1. क्या इमेज कंटेंट है, सजावट (decoration) है, या आर्ट-डायरेक्टेड हीरो इमेज है? यह alt और picture-एलिमेंट हैंडलिंग को बदल देता है।
2. प्रत्येक ब्रेकपॉइंट पर CSS स्लॉट की चौड़ाई और आस्पेक्ट रेशियो क्या हैं? sizes को स्लॉट का वर्णन करना चाहिए, आँख मूंदकर व्यूपोर्ट का नहीं।
3. क्या CDN नॉर्मलाइज़्ड चौड़ाई, फ़ॉर्मेट और क्वालिटी मानों पर की (key) बना सकता है? चौड़ाई के कितने विकल्पों की अनुमति है?
4. Client Hints, आधुनिक फ़ॉर्मेट और रिस्पॉन्सिव प्रीलोडिंग के लिए लक्षित ब्राउज़र सपोर्ट क्या है?
5. फर्स्ट-व्यू मेट्रिक्स, कैश हिट रेट, इमेज बाइट्स और एरर्स के लिए बेसलाइन क्या हैं?

30-सेकंड उत्तर ढाँचा

पहले नेटिव रिस्पॉन्सिव इमेजेस का उपयोग करें, फिर सर्वर/CDN प्रोग्रेसिव एन्हांसमेंट के रूप में Client Hints जोड़ें। ब्राउज़र उम्मीदवार चुनने के लिए srcset और sizes का उपयोग करता है; यदि सर्वर हिंट्स का उपयोग करके रिस्पॉन्स बदलता है, तो यह Accept-CH का विज्ञापन करता है और कैश पॉलिसी में उन फ़ील्ड्स को दर्शाता है जो वास्तव में रिस्पॉन्स को प्रभावित करते हैं। सुरक्षित डिफ़ॉल्ट और नो-हिंट्स पाथ के साथ केवल बकेटेड चौड़ाई और नॉर्मलाइज़्ड DPR की अनुमति दें। LCP, CLS, इमेज बाइट्स, हिट रेट और एरर्स के साथ मान्य करें, और जांचें कि क्या हाई-एन्ट्रॉपी हिंट्स वास्तव में आवश्यक हैं।

चरण-दर-चरण उत्तर

1. एक सीमित कैंडिडेट सेट और स्लॉट परिभाषित करें

स्रोत आस्पेक्ट रेशियो को बनाए रखते हुए प्रति इमेज एक सीमित चौड़ाई सेट उत्पन्न करें, जैसे कि 320, 640, 960 और 1280 (उदाहरण मान, कोई सार्वभौमिक मानक नहीं)। sizes में प्रत्येक लेआउट ब्रेकपॉइंट पर अपेक्षित डिस्प्ले चौड़ाई व्यक्त करें; ब्राउज़र DPR, नेटवर्क और अपनी नीति पर भी विचार करता है। src को एक आवश्यक फ़ॉलबैक के रूप में रखें।

<img
  src="/img/card-640.jpg"
  srcset="/img/card-320.jpg 320w, /img/card-640.jpg 640w, /img/card-960.jpg 960w, /img/card-1280.jpg 1280w"
  sizes="(min-width: 66rem) 33vw, (min-width: 44rem) 50vw, 100vw"
  width="640"
  height="400"
  alt="Article cover"
  loading="lazy"
  decoding="async"
>

2. फ़ॉर्मेट और आर्ट डायरेक्शन के लिए picture का उपयोग करें

जब फ़ॉर्मेट चयन या एक अलग मोबाइल क्रॉप की आवश्यकता हो तो picture एलिमेंट का उपयोग करें, और src वाले img-एलिमेंट फ़ॉलबैक के साथ समाप्त करें। फ़ॉर्मेट और चौड़ाई चयन को अलग रखें; एक निश्चित प्रीलोड को गलत रिसोर्स को बाध्य नहीं करना चाहिए।

3. Client Hints लूप को न्यूनतम रखें

रिस्पॉन्स उन हिंट्स का अनुरोध करने के लिए Accept-CH का उपयोग कर सकता है जिनका सर्वर वास्तव में उपयोग करता है, जैसे कि DPR या Width। कोई ब्राउज़र उन्हें भेजता है या कब भेजता है, यह ब्राउज़र पॉलिसी, अनुमतियों और समर्थन पर निर्भर करता है। अज्ञात हिंट्स को अनदेखा करें और केवल उन्हीं फ़ील्ड्स को घोषित करें जो वास्तव में कैश करने योग्य रिस्पॉन्स को बदलते हैं।

Accept-CH: DPR, Width
Vary: Accept, DPR, Width

Vary एक सिमेंटिक घोषणा है, असीमित वैरिएंट्स बनाने की अनुमति नहीं। Width को सीमित बकेट्स में मैप करें, DPR को नॉर्मलाइज़ करें, या नॉर्मलाइज़्ड परिणाम को CDN की में रखें; अपस्ट्रीम URL में कभी भी मनमाने रॉ (raw) पैरामीटर्स को न जोड़ें।

4. प्राइवेसी, अनुमतियाँ और इनपुट सुरक्षा संभालें

Client Hints रिक्वेस्ट मेटाडेटा हैं, क्रेडेंशियल नहीं। किसी बताई गई समस्या को हल करने वाले लो-एन्ट्रॉपी हिंट्स को प्राथमिकता दें, और प्रोफ़ाइलिंग के लिए डिवाइस मॉडल डेटा का अनुरोध करने से बचें। चौड़ाई, क्वालिटी और फ़ॉर्मेट पैरामीटर्स को सीमित और अनुमत सूची (allowlist) में रखें; एक इमेज ट्रांसफार्मर को SSRF, ओपन रीडायरेक्ट और अत्यधिक बड़े कार्यों से भी बचाव करना चाहिए।

5. प्रोग्रेसिव एन्हांसमेंट और एक्सेसिबिलिटी को सुरक्षित रखें

जब हिंट्स अनुपस्थित हों, अस्वीकार कर दिए गए हों, या CDN को मिस करते हों, तब भी srcset/sizes और एक सर्वर डिफ़ॉल्ट इमेज लोड करते हैं। CLS को कम करने के लिए width और height, या एक समकक्ष आस्पेक्ट-रेशियो बॉक्स सेट करें। अबव-द-फ़ोल्ड LCP इमेज के लिए loading="eager" या fetchpriority="high" का संयम से उपयोग करें; बिलो-द-फ़ोल्ड इमेजेस को लेज़ी-लोड करें; कंटेंट इमेजेस के लिए सार्थक alt टेक्स्ट प्रदान करें।

6. एक प्रतिवर्ती (reversible) मेज़रमेंट प्लान बनाएं

तुलनीय ट्रैफ़िक और कंटेंट को कंट्रोल और ट्रीटमेंट में विभाजित करें। LCP, INP, CLS, इमेज ट्रांसफर बाइट्स, डिकोड टाइम, हिट रेट, एरर रेट, वास्तविक डिस्प्ले चौड़ाई और डिवाइस क्लास रिकॉर्ड करें। यदि हिट रेट गिरता है या डुप्लिकेट डाउनलोड बढ़ते हैं, तो अधिक वैरिएंट्स जोड़ने से पहले हिंट डायमेंशन कम करें, बकेट्स चौड़े करें, या Client Hints को रोलबैक करें।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं ब्राउज़र-नेटिव चयन को पहले रखूँगा: एक सीमित srcset, एक सटीक sizes, आंतरिक आयाम (intrinsic dimensions), और सुलभ alt टेक्स्ट प्रदान करें। picture एलिमेंट का उपयोग केवल तभी करें जब फ़ॉर्मेट या आर्ट डायरेक्शन की आवश्यकता हो, जिसमें एक विश्वसनीय img-एलिमेंट फ़ॉलबैक हो। सर्वर उन हिंट्स के लिए Accept-CH का विज्ञापन कर सकता है जिनका वह वास्तव में उपयोग करता है, लेकिन जब हिंट्स असमर्थित, अस्वीकृत या अभी तक उपलब्ध न हों, तब भी पहली रिक्वेस्ट को काम करना चाहिए।

यदि कोई रिस्पॉन्स हिंट द्वारा बदलता है, तो मैं CDN की (key) को नॉर्मलाइज़्ड चौड़ाई बकेट्स, DPR बकेट्स, फ़ॉर्मेट और अनुमत क्वालिटी तक सीमित रखूँगा। Vary केवल उन फ़ील्ड्स को सूचीबद्ध करेगा जो प्रतिनिधित्व को प्रभावित करते हैं। रॉ चौड़ाई और नेटवर्क मानों में उच्च कार्डिनैलिटी हो सकती है, इसलिए उन्हें प्रत्येक के लिए एक कैश ऑब्जेक्ट नहीं बनाना चाहिए। मैं ठोस आवश्यकता के बिना डिवाइस मॉडल डेटा का अनुरोध नहीं करूँगा और कभी भी हिंट को प्रमाणीकरण (authentication) के रूप में नहीं मानूँगा। अंत में, रोलआउट का विस्तार करने से पहले मैं LCP/CLS, बाइट्स, हिट रेट और एरर्स पर समान-सामग्री वाला A/B टेस्ट चलाऊंगा।

सामान्य विफलता मोड

• हमेशा sizes="100vw" लिखना और मल्टी-कॉलम लेआउट की अनदेखी करना, जिससे आवश्यकता से बड़े विकल्प उत्पन्न होते हैं।
• बाद की रिक्वेस्ट, अनुमति, Accept-CH, Vary और कैश-की संदर्भ के बिना समझाना।
• प्रत्येक रॉ चौड़ाई, DPR, या नेटवर्क मान के लिए एक CDN वैरिएंट बनाना।
• पहले मापने के लिए क्लाइंट जावास्क्रिप्ट की आवश्यकता होना, जिससे फ़र्स्ट पेंट और फ़ॉलबैक व्यवहार को नुकसान पहुँचता है।
• एक निश्चित प्रीलोड लिंक का उपयोग करना जो रिस्पॉन्सिव चयन के साथ संघर्ष करता है और दो बार डाउनलोड करता है।
• alt, आयाम रिज़र्वेशन, पैरामीटर अनुमत सूचियों, या हाई-एन्ट्रॉपी प्राइवेसी जोखिम की अनदेखी करना।

फॉलो-अप प्रश्न और संदर्भ उत्तर

क्या अधिक Vary होना हमेशा अधिक सही होता है?

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

जब srcset पहले से मौजूद है तो Client Hints क्यों जोड़ें?

srcset और sizes ब्राउज़र को उसके स्लॉट ज्ञान का उपयोग करके चुनने की अनुमति देते हैं और आमतौर पर पहली पसंद होते हैं। Client Hints एक वैकल्पिक पूरक हैं जब सर्वर या CDN को डिवाइस या नेटवर्क मेटाडेटा का उपयोग करके रिस्पॉन्स को ट्रांसफॉर्म करना होता है; वे फ़ॉलबैक की जगह नहीं लेते हैं।

क्या पहली HTML रिक्वेस्ट में Width शामिल होगी?

ऐसा मानकर न चलें। Accept-CH बातचीत बाद की रिक्वेस्ट्स को प्रभावित करती है, और भेजना ब्राउज़र समर्थन और अनुमतियों के अधीन है। इसलिए पहली रिक्वेस्ट को स्टैंडअलोन काम करना चाहिए।

आपको कैसे पता चलेगा कि कैश बकेट बहुत अधिक बारीक (fine-grained) है?

प्रति बकेट हिट रेट, वैरिएंट काउंट, एज स्टोरेज और रिक्वेस्ट वॉल्यूम ट्रैक करें। पड़ोसी चौड़ाइयों को मर्ज करें और बाइट्स तथा LCP की तुलना करें; जब परफ़ॉर्मेंस लाभ कैश लागत से कम हो जाए तो उन्हें समेकित (converge) करें।

हाई-एन्ट्रॉपी हिंट्स से कब बचना चाहिए?

जब प्रोडक्ट को केवल सामान्य चौड़ाई, फ़ॉर्मेट या डेटा-बचत व्यवहार की आवश्यकता हो। डिवाइस मॉडल हिंट्स फ़िंगरप्रिंटिंग की संभावना और कैश डायमेंशन को बढ़ाते हैं और इन्हें केवल इसलिए सक्षम नहीं किया जाना चाहिए क्योंकि वे मदद कर सकते हैं।

आप कैसे सत्यापित करते हैं कि रिस्पॉन्सिव प्रीलोड डाउनलोड को डुप्लिकेट नहीं करता है?

रिस्पॉन्सिव-प्रीलोड सपोर्ट वाले और बिना सपोर्ट वाले ब्राउज़रों में नेटवर्क ट्रेस कैप्चर करें। पुष्टि करें कि प्रीलोड और अंतिम img-एलिमेंट चयन एक ही URL पर रिज़ॉल्व होते हैं; अन्यथा HTML srcset को एकमात्र विश्वसनीय पाथ बने रहने दें।