प्रश्न और संदर्भ
एक ई-कॉमर्स प्रोडक्ट पेज एनालिटिक्स, चैट, विज्ञापन और A/B-टेस्टिंग स्क्रिप्ट लोड करता है। मोबाइल पर वास्तविक उपयोगकर्ताओं का p75 LCP 3.8 सेकंड और INP 280 मिलीसेकंड है; थर्ड-पार्टी JavaScript 14 ओरिजिन से लगभग 1.2 MB डेटा ट्रांसफर करती है, जबकि डेस्कटॉप लैब टेस्ट सही दिखते हैं। आपको नेटवर्क, मेन थ्रेड, प्राइवेसी और पेज की उपलब्धता पर थर्ड-पार्टी के प्रभावों को सीमित करते हुए आवश्यक बिज़नेस क्षमताओं को बनाए रखना होगा।
पहले चार सीमाओं को स्पष्ट करें: कौन सी स्क्रिप्ट्स पहली स्क्रीन से पहले चलनी चाहिए, किनकी आवश्यकता केवल इंटरैक्शन के बाद होती है, क्या स्क्रिप्ट्स एक-दूसरे के क्रम पर निर्भर हैं, क्या सहमति से पहले डेटा भेजा जा सकता है, और क्या किसी थर्ड-पार्टी के डाउन होने से चेकआउट रुक सकता है। थर्ड-पार्टी कोड पेज के एक्ज़ीक्यूशन एनवायरनमेंट का हिस्सा है; इसे एक सामान्य स्टैटिक एसेट की तरह नहीं माना जा सकता जिसका स्वामित्व हमेशा किसी अन्य टीम के पास रहे।
यह प्रश्न फ्रंटएंड, वेब-प्लेटफ़ॉर्म और परफ़ॉर्मेंस-इंजीनियरिंग साक्षात्कारों के लिए उपयुक्त है। सार्वजनिक फ्रंटएंड साक्षात्कार सामग्री async, defer, स्क्रिप्ट के क्रम और परफ़ॉर्मेंस ट्रेड-ऑफ़ को बुनियादी विषयों के रूप में मानती है; web.dev, MDN और W3C सामग्री लोडिंग टाइमिंग, लॉन्ग टास्क, CSP और सोर्स कंट्रोल के लिए तकनीकी आधार प्रदान करती है। इस प्रश्न का मुख्य केंद्र गवर्नेंस और प्रमाण है, न कि किसी फ़्रेमवर्क कॉम्पोनेंट को रटना।
इंटरव्यूअर क्या आकलन कर रहा है
एक कमज़ोर उत्तर कहता है "हर जगह async जोड़ दें" या "स्क्रिप्ट्स को पेज के नीचे रख दें।" एक मज़बूत उत्तर यूज़र वैल्यू और क्रिटिकल-पाथ इम्पैक्ट के आधार पर स्क्रिप्ट्स की इन्वेंट्री तैयार करता है, फिर डिपेंडेंसी और फ़ेलियर सीमाओं के आधार पर async, defer, मॉड्यूल्स, इंटरैक्शन-ट्रिगर्ड लोडिंग, या एक iframe फ़ैसाड (facade) चुनता है।
इंटरव्यूअर पाँच संकेत देखना चाहता है: क्या उम्मीदवार डाउनलोड समय को एक्ज़ीक्यूशन समय से अलग कर सकता है; बिना क्रम वाले async बनाम क्रमबद्ध defer की व्याख्या कर सकता है; परफ़ॉर्मेंस बजट, सहमति, CSP/SRI और सप्लाई-चेन जोखिम को संयोजित कर सकता है; चेकआउट को ब्लॉक किए बिना वेंडर की विफलता को अलग (isolate) कर सकता है; और बदलाव को साबित करने के लिए RUM, लॉन्ग-टास्क डेटा और एक नियंत्रित तुलना का उपयोग कर सकता है।
केवल लाइटहाउस (Lighthouse) स्कोर पर्याप्त नहीं है। लैब की स्थितियाँ कम क्षमता वाले फ़ोन, धीमे नेटवर्क, कंटेंट ब्लॉकर्स या रुकने वाले वेंडर सर्वर का प्रतिनिधित्व नहीं करती हैं; उत्तर में वास्तविक यूज़र परसेंटाइल, स्क्रिप्ट एक्ज़ीक्यूशन समय और बिज़नेस कंप्लीशन रेट शामिल होना चाहिए।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- फ़र्स्ट पेंट या पहले इंटरैक्शन के लिए वास्तव में किन स्क्रिप्ट्स की आवश्यकता है? पेमेंट और आवश्यक फ्रॉड चेक महत्वपूर्ण हो सकते हैं; चैट, सिफ़ारिशें (recommendations) और रीप्ले आमतौर पर इंटरैक्शन या आइडल समय की प्रतीक्षा कर सकते हैं।
- क्या स्क्रिप्ट्स एक-दूसरे पर निर्भर हैं? स्वतंत्र एनालिटिक्स
asyncका उपयोग कर सकते हैं; DOM- या क्रम-निर्भर एप्लिकेशन कोड आमतौर परdeferका उपयोग करता है; अज्ञात डिपेंडेंसी को समानांतर (parallelize) नहीं किया जाना चाहिए। - सहमति (consent) से पहले क्या अनुमत है? स्क्रिप्ट, कुकी, नेटवर्क रिक्वेस्ट या अनाम माप बनाने से पहले उद्देश्य, क्षेत्र और सहमति की स्थिति को परिभाषित करें।
- वेंडर किस पेज डेटा को एक्सेस कर सकता है? सेम-ओरिजिन कोड पेज संदर्भ को पढ़ सकता है; यदि किसी चैट या विज्ञापन को केवल रेंडर करने की आवश्यकता है, तो कम परमिशन सतह वाले iframe या सर्वर-साइड इवेंट को प्राथमिकता दें।
- विफलता की स्थिति में उपयोगकर्ता का अनुभव क्या होगा? खरीदारी, लॉगिन और नेविगेशन के लिए फ़र्स्ट-पार्टी पाथ की आवश्यकता होती है; वेंडर के टाइमआउट के कारण किसी महत्वपूर्ण बटन या मेन थ्रेड को हमेशा के लिए प्रतीक्षा नहीं करनी चाहिए।
- क्या वेंडर को बदला जा सकता है या सेल्फ़-होस्ट किया जा सकता है? सेल्फ़-होस्टिंग से DNS और वेंडर-उपलब्धता का जोखिम समाप्त हो सकता है लेकिन इससे अपडेट, इंटेग्रिटी, लाइसेंस और कैश ओनरशिप जुड़ जाती है; यह अपने आप अधिक सुरक्षित नहीं हो जाता।
30-सेकंड का उत्तर ढाँचा
"मैं बिज़नेस वैल्यू, डिपेंडेंसी, बाइट्स, रिक्वेस्ट्स, मेन-थ्रेड समय, डेटा उद्देश्य और विफलता प्रभाव को रिकॉर्ड करते हुए एक इन्वेंट्री बनाऊँगा, फिर प्रत्येक स्क्रिप्ट को क्रिटिकल, डिफर्ड (deferred) या हटाने योग्य के रूप में वर्गीकृत करूँगा। स्वतंत्र स्क्रिप्ट्स async का उपयोग करती हैं; DOM- या क्रम-निर्भर स्क्रिप्ट्स defer का उपयोग करती हैं; इंटरैक्टिव विजेट फ़ैसाड या iframe का उपयोग करते हैं। मैं सहमति से पहले गैर-आवश्यक ट्रैकर्स नहीं बनाऊँगा। CSP केवल समीक्षित ओरिजिन की अनुमति देगा, और फ़िक्स्ड एसेट्स SRI का उपयोग कर सकते हैं। प्रत्येक वेंडर को बाइट, एक्ज़ीक्यूशन-टाइम और एरर बजट मिलता है। RUM डिवाइस और सहमति स्थिति के आधार पर LCP, INP, लॉन्ग टास्क, कन्वर्ज़न और स्क्रिप्ट त्रुटियों की तुलना करेगा। मैं पहले हटाने या टालने (deferral) का ग्रे आउट (gradual rollout) करूँगा, फिर यह साबित करने के लिए फ़ॉल्ट इंजेक्शन और रोलबैक का उपयोग करूँगा कि पेज अभी भी मुख्य कार्य को पूरा करता है।"
चरण-दर-चरण विस्तृत उत्तर
1. इन्वेंट्री और क्रिटिकल पाथ का निर्माण करें
प्रत्येक स्क्रिप्ट के वेंडर, वर्ज़न, ट्रिगर, डिपेंडेंसी, रिक्वेस्ट ओरिजिन, ट्रांसफ़र बाइट्स, पार्स और एक्ज़ीक्यूशन समय, लॉन्ग टास्क, पढ़े गए डेटा, ओनर और हटाने की शर्त को रिकॉर्ड करें। वैल्यू को "अनुभव में सुधार" के बजाय एक परीक्षण योग्य परिणाम के रूप में बताएं, जैसे कि "चेकआउट विफलताओं का कारण ट्रैक करना"। बिना स्पष्ट उद्देश्य, ओनर या मीट्रिक वाली स्क्रिप्ट को हटाने का उम्मीदवार माना जाता है।
फ़र्स्ट पेंट और पहले इंटरैक्शन के लिए डिपेंडेंसी ग्राफ़ बनाएं। क्रिटिकल पाथ पर केवल शुरुआती स्क्रीन, लॉगिन, कार्ट और पेमेंट के लिए आवश्यक फ़र्स्ट-पार्टी कोड रखें। एनालिटिक्स, चैट, सिफ़ारिशें, रीप्ले और मार्केटिंग टैग अक्सर पेंट या स्पष्ट इंटरैक्शन के बाद तक प्रतीक्षा कर सकते हैं। एसिंक्रोनस डाउनलोड से पार्स, कंपाइल या मेन-थ्रेड एक्ज़ीक्यूशन की लागत समाप्त नहीं होती है।
2. डिपेंडेंसी के आधार पर लोडिंग सिमेंटिक्स चुनें
बिना किसी एट्रिब्यूट वाली क्लासिक स्क्रिप्ट HTML पार्सिंग को ब्लॉक करती है। async समानांतर में डाउनलोड होता है और तैयार होते ही निष्पादित हो जाता है, जिसमें क्रम की कोई गारंटी नहीं होती; यह स्वतंत्र एनालिटिक्स या विज्ञापनों के लिए उपयुक्त है। defer भी समानांतर में डाउनलोड होता है लेकिन पार्सिंग के बाद डॉक्यूमेंट क्रम में चलता है, जो उस कोड के लिए उपयुक्त है जिसे DOM या किसी अन्य स्क्रिप्ट की आवश्यकता होती है। मॉड्यूल स्क्रिप्ट डिफ़ॉल्ट रूप से डिफर्ड होती हैं, लेकिन उनके डिपेंडेंसी ग्राफ़ की समीक्षा की आवश्यकता होती है।
निर्णय तालिका का उपयोग करें:
| विधि | एक्ज़ीक्यूशन टाइमिंग | क्रम | उपयुक्तता | मुख्य जोखिम |
|---|---|---|---|---|
| प्लेन क्लासिक स्क्रिप्ट | डाउनलोड के बाद निष्पादित होती है और पार्सिंग को ब्लॉक करती है | डॉक्यूमेंट क्रम | दुर्लभ सिंक्रोनस बूटस्ट्रैप | पार्सिंग और फ़र्स्ट पेंट में देरी करती है |
async | डाउनलोड पूरा होने पर निष्पादित होती है | कोई गारंटी नहीं | स्वतंत्र एनालिटिक्स, विज्ञापन, सरल विजेट | पार्सिंग को बाधित कर सकती है; डिपेंडेंसी के साथ रेस कंडीशन |
defer | पार्सिंग के बाद क्रम में निष्पादित होती है | संरक्षित | DOM- या स्टार्टअप-निर्भर कोड | फिर भी DOMContentLoaded में देरी करती है |
| इंटरैक्शन-ट्रिगर्ड | उपयोगकर्ता कार्रवाई या आइडल समय पर | लोडर-नियंत्रित | चैट, मैप्स, वीडियो, रीप्ले | पहली बार खोलने पर अतिरिक्त लेटेंसी |
| Iframe फ़ैसाड | पहले स्टैटिक शेल, बाद में आइसोलेटेड एम्बेड | क्रॉस-डॉक्यूमेंट सीमा | वीडियो, पेमेंट UI, जटिल विजेट | कम्युनिकेशन और एक्सेसिबिलिटी लागत |
सभी निर्भर स्क्रिप्ट्स को async के रूप में मार्क न करें। यदि plugin.js को vendor.js की आवश्यकता है, तो डाउनलोड टाइमिंग के सही बैठने की उम्मीद करने के बजाय ऑर्डर्ड defer, मॉड्यूल इम्पोर्ट या एक स्पष्ट लोडर का उपयोग करें।
3. कार्यक्षमता को टालें (defer), छाँटें (trim), या बदलें
गैर-क्रिटिकल कार्य के लिए उपयोगकर्ता इंटरैक्शन, टाइमआउट फ़ॉलबैक के साथ requestIdleCallback, या पोस्ट-पेंट कतार का उपयोग करें। एक चैट बटन फ़र्स्ट-पार्टी स्टैटिक एंट्री हो सकता है जो केवल क्लिक करने पर विजेट बनाता है; एक वीडियो iframe एम्बेड करने से पहले थंबनेल और प्ले कंट्रोल दिखा सकता है। यह पहली स्क्रीन के नेटवर्क और मेन-थ्रेड कार्य को कम करता है और उपयोगकर्ता द्वारा कभी उपयोग न की जाने वाली सुविधाओं के लिए भुगतान करने से बचाता है।
डुप्लिकेट टैग मैनेजर, एनालिटिक्स SDK और अप्रयुक्त प्रयोगों को हटा दें। वेंडर्स से छोटे बिल्ड, पेज-विशिष्ट बंडल, कंप्रेशन और कैशिंग की मांग करें। सेल्फ़-होस्टिंग से थर्ड-पार्टी DNS या उपलब्धता का जोखिम कम हो सकता है, लेकिन इसके लिए वर्ज़न अपडेट, SRI, लाइसेंसिंग, कैश इनवैलिडेशन और रोलबैक की आवश्यकता होती है; यह निष्पादन लागत को समाप्त नहीं करता है।
4. प्राइवेसी, सिक्योरिटी और फ़ेलियर सीमाओं को परिभाषित करें
सहमति मिलने से पहले, गैर-आवश्यक ट्रैकिंग स्क्रिप्ट न बनाएं और न ही उन्हें लोड करके केवल बाद में डेटा भेजना डिसेबल करें। परिभाषित करें कि क्या सहमति वापस लेने से कुकीज़ साफ़ हो जाती हैं, कतारें रुक जाती हैं और बाद के अनुरोध रुक जाते हैं। CSP script-src और प्रासंगिक कनेक्शन निर्देशों के साथ ओरिजिन को सीमित करें; फ़िक्स्ड-वर्ज़न बाहरी संसाधनों के लिए SRI का उपयोग करें। केवल पहले डोमेन पर भरोसा करने के बजाय डायनेमिक लोडिंग, वेंडर द्वारा लोड की गई डिपेंडेंसी और strict-dynamic का अलग से ऑडिट करें।
सेम-ओरिजिन पर चलने वाले थर्ड-पार्टी कोड के पास व्यापक अनुमतियाँ होती हैं। केवल रेंडर करने वाले कॉम्पोनेंट्स को iframe में रखें और postMessage के माध्यम से न्यूनतम फ़ील्ड भेजें। खरीदारी, लॉगिन, नेविगेशन और एरर रिकवरी को फ़र्स्ट-पार्टी रखें; मुख्य प्रवाह को ब्लॉक करने के बजाय वेंडर टाइमआउट को टाइमआउट, सर्किट ब्रेक या प्लेसहोल्डर के साथ समाप्त करें।
5. बजट सेट करें और मॉनिटर करें
प्रत्येक वेंडर और पेज प्रकार को ट्रांसफ़र बाइट्स, रिक्वेस्ट काउंट, मेन-थ्रेड एक्ज़ीक्यूशन, लॉन्ग टास्क, एरर रेट और LCP/INP में योगदान के लिए बजट दें। बजट से अधिक होने पर भविष्य के क्लीनअप टिकट के बजाय समीक्षा या स्वचालित डिग्रेडेशन शुरू होना चाहिए। कम क्षमता वाले डिवाइस, धीमे नेटवर्क और सहमति स्थिति के आधार पर बजट को विभाजित करें क्योंकि औसत डेटा टेल एंड (tail) को छिपा देता है।
लैब में, पार्सिंग, एक्ज़ीक्यूशन, लॉन्ग टास्क और सिंगल-पॉइंट फ़ेलियर को देखने के लिए DevTools परफ़ॉर्मेंस और नेटवर्क पैनल, WebPageTest और फ़ॉल्ट इंजेक्शन का उपयोग करें। प्रोडक्शन में, सोर्स, रिसोर्स टाइमिंग, PerformanceObserver लॉन्ग टास्क, LCP, INP, CLS, कन्वर्ज़न और एरर रिकॉर्ड करने के लिए RUM का उपयोग करें। डिवाइस, ब्राउज़र, क्षेत्र और पेज-टेम्पलेट सेगमेंट की तुलना करें ताकि ट्रैफ़िक मिश्रण में आए बदलावों को ग़लती से ऑप्टिमाइज़ेशन न समझ लिया जाए।
6. वेंडर परिवर्तनों का रोलआउट, रोलबैक और गवर्नेंस करें
पहले एक पेज टेम्पलेट और मोबाइल ट्रैफ़िक के एक छोटे हिस्से पर ग्रे आउट (ग्रे रिलीज़) करें। प्रत्येक स्क्रिप्ट परिवर्तन में एक वर्ज़न, सोर्स, सहमति कॉन्फ़िगरेशन और रोलबैक स्विच होता है; वेंडर अपडेट भी इसी पथ का अनुसरण करते हैं। यदि कोई स्क्रिप्ट टाइमआउट होती है या एरर देती है, तो उसे हमेशा पुन: प्रयास करने के बजाय छोड़ दें या डिफ़ॉल्ट रूप से डिग्रेड करें। रोलबैक वेंडर URL से किसी अज्ञात वर्ज़न को खींचने के बजाय अंतिम समीक्षित मैनिफ़ेस्ट को पुनर्स्थापित करता है।
इनवेरिएंट्स (invariants) को सत्यापित करें: वेंडर के विफल होने पर भी उपयोगकर्ता ब्राउज़ कर सकते हैं, कार्ट में जोड़ सकते हैं और खरीदारी कर सकते हैं; सहमति के बिना प्रतिबंधित डेटा का अनुरोध नहीं किया जाता है; स्क्रिप्ट बजट सीमा के भीतर रहता है; CSP रिपोर्ट कोई नया ओरिजिन नहीं दिखाती है; और महत्वपूर्ण इंटरैक्शन INP में गिरावट नहीं आती है। प्रत्येक वेंडर के लिए स्पष्ट रूप से हटाने या बदलने के ट्रिगर रखें।
7. सत्यापन को निष्पादन योग्य (executable) बनाएं
धीमे DNS, वेंडर 5xx, बीच में रुके डाउनलोड, अपवाद (exception), मेन-थ्रेड लॉन्ग टास्क, सहमति वापसी, अक्षम थर्ड-पार्टी कुकीज़, कंटेंट ब्लॉकर और पुराने ब्राउज़र का परीक्षण करें। विज़ुअल रेंडरिंग से अधिक की पुष्टि करें: खरीदारी की स्थिति, रिकवरी, कीबोर्ड इंटरैक्शन, स्क्रीन-रीडर घोषणाएं और डेटा-अनुरोध सीमाएं।
एक कंट्रोल ग्रुप का उपयोग करें जो कंटेंट और ट्रैफ़िक नियमों को स्थिर रखते हुए केवल एक लोडिंग रणनीति को बदलता है, जैसे कि सिंक्रोनस से डिफर्ड। p75/p95 LCP, INP, लॉन्ग टास्क, रिसोर्स बाइट्स, कन्वर्ज़न और वेंडर एरर सत्यापित करें। यदि चेकआउट में सुधार होता है लेकिन चैट खोलना धीमा हो जाता है, तो केवल एक आकर्षक स्कोर की रिपोर्ट करने के बजाय ट्रेड-ऑफ़ की रिपोर्ट करें और ट्रिगर को ट्यून करें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं सभी 14 स्क्रिप्ट्स में async जोड़कर शुरुआत नहीं करूँगा। मैं प्रत्येक स्क्रिप्ट के उद्देश्य, डिपेंडेंसी, रिक्वेस्ट्स, बाइट्स, मेन-थ्रेड समय, डेटा उपयोग, ओनर और विफलता प्रभाव की इन्वेंट्री बनाऊँगा, फिर इसे क्रिटिकल, डिफर्ड या हटाने योग्य के रूप में वर्गीकृत करूँगा। पेमेंट और लॉगिन फ़र्स्ट-पार्टी क्रिटिकल पाथ पर रहेंगे; स्वतंत्र एनालिटिक्स एसिंक्रोनस हो सकते हैं; DOM- या क्रम-निर्भर कोड defer का उपयोग करता है; चैट, मैप्स और वीडियो इंटरैक्शन पर या iframe फ़ैसाड के पीछे लोड होते हैं।
सहमति से पहले मैं गैर-आवश्यक ट्रैकर्स नहीं बनाऊँगा। CSP समीक्षित स्रोतों की अनुमति देगा और फ़िक्स्ड एसेट्स SRI का उपयोग कर सकते हैं। केवल रेंडर होने वाला विजेट iframe में जाता है, जबकि खरीदारी और नेविगेशन फ़र्स्ट-पार्टी फ़ॉलबैक बनाए रखते हैं। प्रत्येक वेंडर के पास बाइट, एक्ज़ीक्यूशन, लॉन्ग-टास्क और एरर बजट होता है।
मैं एक छोटे मोबाइल समूह पर बदलाव को रोल आउट करूँगा। लैब में मैं नेटवर्क को थ्रॉटल करूँगा, परफ़ॉर्मेंस ट्रेस का निरीक्षण करूँगा और वेंडर फ़ेलियर इंजेक्ट करूँगा। प्रोडक्शन में मैं डिवाइस, क्षेत्र और सहमति स्थिति के अनुसार RUM को विभाजित करूँगा और LCP, INP, CLS, लॉन्ग टास्क, रिसोर्स टाइमिंग, कन्वर्ज़न और एरर की तुलना करूँगा। प्रत्येक परिवर्तन प्रतिवर्ती (reversible) है और वेंडर अपडेट की समीक्षा की जाती है। यदि कोई वेंडर विफल हो जाता है, तो भी मुख्य खरीदारी कार्य करती है; यदि सहमति से पहले डेटा भेजा जाता है या गार्डरेल्स बजट से अधिक हो जाती हैं, तो विस्तार रोक दिया जाता है।"
सामान्य गलतियाँ
- प्रत्येक स्क्रिप्ट में
asyncजोड़ना → निर्भर स्क्रिप्ट्स बिना क्रम के चल सकती हैं और एक्ज़ीक्यूशन अभी भी पार्सिंग को बाधित कर सकता है → डिपेंडेंसी का मैप बनाएं; स्वतंत्र कार्य के लिएasyncऔर क्रमित कार्य के लिएdeferया मॉड्यूल्स का उपयोग करें। - टैग्स को केवल body के अंत में ले जाना → डाउनलोड और एक्ज़ीक्यूशन अभी भी मेन थ्रेड के लिए प्रतिस्पर्धा करते हैं और इंटरैक्शन ख़राब हो सकता है → फ़ंक्शन के आधार पर टालें, छाँटें, विभाजित करें या ट्रिगर करें, फिर एक्ज़ीक्यूशन लागत को मापें।
- केवल Lighthouse का उपयोग करना → लैब स्थितियाँ कम क्षमता वाले डिवाइस, धीमे नेटवर्क और वेंडर के रुकने की उपेक्षा करती हैं → वास्तविक यूज़र परसेंटाइल, लॉन्ग टास्क और बिज़नेस मेट्रिक्स की तुलना करें।
- सहमति अस्वीकार होने के बाद ट्रैकिंग अक्षम करना → स्क्रिप्ट पहले ही चल चुकी है और अनुरोध भेज चुकी हो सकती है → स्क्रिप्ट या नेटवर्क अनुरोध बनाने से पहले सहमति की जाँच करें।
- सेल्फ़-होस्टिंग को संपूर्ण सुरक्षा समाधान मानना → अपडेट, इंटेग्रिटी, लाइसेंसिंग और निष्पादन लागत बनी रहती है → समीक्षित वर्ज़न, SRI, CSP, बजट और रोलबैक को संयोजित करें।
- विफल वेंडर को तब तक पुनः प्रयास करना जब तक वह काम न करे → वेंडर महत्वपूर्ण पेज के लिए सिंगल पॉइंट ऑफ़ फ़ेलियर बन जाता है → टाइमआउट, एक डिग्रैडेड प्लेसहोल्डर और फ़र्स्ट-पार्टी कोर पाथ का उपयोग करें।
फ़ॉलो-अप और उनके उत्तर
फ़ॉलो-अप 1: एनालिटिक्स को पहली स्क्रीन का इवेंट तुरंत भेजना होगा। क्या यह क्रिटिकल हो सकता है?
पहले जांचें कि क्या इसे वास्तव में फ़र्स्ट पेंट से पहले भेजा जाना चाहिए। यदि पेज-व्यू इवेंट को पेंट के बाद बैच किया जा सकता है और थोड़ा डेटा नुकसान स्वीकार्य है, तो इसे टाल दें। यदि एट्रिब्यूशन या कंप्लायंस के लिए पहले डिलीवरी की आवश्यकता है, तो एक स्वतंत्र async स्क्रिप्ट, एक छोटे टाइमआउट और एक छोटी फ़र्स्ट-पार्टी कतार का उपयोग करें; रेंडरिंग को ब्लॉक न करें। LCP और INP की बिज़नेस वैल्यू के साथ इवेंट में देरी की तुलना करके बजट निर्धारित करें।
फ़ॉलो-अप 2: एक वेंडर केवल एक डायनेमिक URL प्रदान करता है। आप SRI का उपयोग कैसे कर सकते हैं?
आप लगातार बदलने वाले कंटेंट के लिए एक विश्वसनीय हैश पिन नहीं कर सकते। वर्ज़न्ड एसेट्स का अनुरोध करें, एक सेल्फ़-होस्टेड हस्ताक्षरित-रिलीज़ प्रक्रिया बनाएं, या iframe या सर्वर-साइड एकीकरण में इस सुविधा को अलग करें। CSP, एक्सेस ऑडिट और परिवर्तन निगरानी से जोखिम कम होता है। नकली हैश का उपयोग न करें और न ही इसे unsafe-inline से बदलें।
फ़ॉलो-अप 3: defer के साथ भी एक थर्ड-पार्टी स्क्रिप्ट लॉन्ग टास्क बना रही है। आगे क्या करें?
defer टाइमिंग को बदलता है, पार्स या एक्ज़ीक्यूशन कार्य को नहीं। स्क्रिप्ट और टास्क की पहचान करने के लिए परफ़ॉर्मेंस ट्रेस का उपयोग करें, फिर वेंडर से इसे विभाजित करने, इंटरैक्शन पर ट्रिगर करने, सुविधाओं को हटाने, या कार्य को iframe या सर्वर-साइड इवेंट में ले जाने के लिए कहें। यदि इसे चलना ही है, तो टाइमआउट के साथ आइडल समय में छोटे हिस्सों को शेड्यूल करें और RUM के साथ टेल एंड को सत्यापित करें।
फ़ॉलो-अप 4: मार्केटिंग टीम एक साथ पाँच टैग जोड़ना चाहती है। आप क्या कहेंगे?
प्रत्येक टैग के लिए उसका उद्देश्य, ओनर, अपेक्षित निर्णय, सहमति श्रेणी, परफ़ॉर्मेंस बजट और हटाने की शर्त बताने की आवश्यकता रखें। डुप्लिकेट संग्रह या किसी मौजूदा इवेंट की जांच करें जो पहले से ही उस प्रश्न का उत्तर देता है। सैंडबॉक्स में मापें और वैल्यू स्पष्ट होने के बाद ही ग्रे आउट (रोल आउट) करें। बिना मापने योग्य वैल्यू या बजट से बाहर की लागत वाला टैग प्रोडक्शन में नहीं जाता है।