ब्राउज़र जो लोड करता है उससे एक इन्वेंटरी बनाएं
प्रतिनिधि पृष्ठों के साथ शुरू करें: होम, लैंडिंग, डिटेल, सर्च, कार्ट, चेकआउट, अकाउंट, और कैंपेन पृष्ठ। Chrome DevTools में ताजा और रिटर्न विज़िट्स रिकॉर्ड करें। ब्राउज़र साक्ष्य की तुलना टैग मैनेजर, CMS प्लग-इंस और कोड डिपेंडेंसियों से करें; एक दृश्य इंजेक्ट किए गए स्क्रिप्ट्स को मिस कर सकता है।
प्रति URL नहीं बल्कि प्रति विक्रेता या इंटीग्रेशन एक पंक्ति का उपयोग करें। उस द्वारा संपर्क किए जाने वाले डोमेन्स और यह कि क्या वह टैग जोड़ सकता है, कैप्चर करें। इसे एक बिजनेस मालिक दें जो उद्देश्य का बचाव कर सके और हटाने को मंजूरी दे सके। कैंपेन, विक्रेता परिवर्तन, टेम्पलेट रिलीज़ और रीडिज़ाइन के बाद पुनः जाँच करें।
पेज, यात्रा, विक्रेता डोमेन्स, अनुरोध, ट्रांसफर साइज, मुख्य-थ्रेड काम, और परीक्षण स्थितियाँ सेव करें। एक लैब ट्रेस डायग्नोस्टिक साक्ष्य है, हर विज़िटर के लिए वादा नहीं।
उद्देश्य, मालिक, सहमति श्रेणी, ट्रिगर, उजागर किया गया डेटा, निर्भरता क्रम, फॉलबैक, और समीक्षा तिथि शामिल करें।
रखें, हटाएँ, और बजट निर्णय दिखाई देने योग्य बनाएं
हर मालिक से पूछें कि इंटीग्रेशन गायब होने पर क्या सबसे खराब होगा। यदि उत्तर अस्पष्ट है, तो उसे डिसेबल या हटाएँ। web.dev बजट, डुप्लिकेट कार्यों से बचने, और अनावश्यक स्क्रिप्ट्स साफ़ करने की सलाह देता है।
बजट एक टीम गार्डरेल है, सार्वभौमिक सीमा नहीं। बाइट्स, अनुरोधों, मुख्य-थ्रेड समय, और लोडिंग के लिए प्रति-विक्रेता और पेज भत्ते सेट करें। बेसलाइन की तुलना परिवर्तन से करें। मालिक को भत्ता के भीतर रहने, किसी अन्य लागत को हटाने, या एक एक्सपायर होने वाले अपवाद प्राप्त करने की आवश्यकता रखें। तुलनात्मक यात्राएँ और उपयोगकर्ता-केंद्रित मीट्रिक्स उपयोग करें।
केवल उन्हीं निर्भरताओं को रखें जिनका वर्तमान उद्देश्य है, जिनका मालिक-स्वीकृत लागत और डेटा उपयोग है, और जिनके पास स्वीकार्य विफलता पथ है।
समाप्त पिक्सल्स, डुप्लीकेट एनालिटिक्स, निष्क्रिय चैट, अप्रयुक्त एक्सपेरिमेंट्स, और परित्यक्त प्लग-इंस को स्टेज्ड रिलीज़ के माध्यम से रिटायर करें।
कारण, लागत, अनुमोदक, समकक्ष कार्रवाई, और समीक्षा तिथि रिकॉर्ड करें।
केवल तब देर से लोड करें जब देर सुरक्षित हो
लोड़िंग व्यवहार जानबूझकर चुनें। कोई क्लासिक बाहरी स्क्रिप्ट बिना async, defer, या module व्यवहार के HTML पार्सिंग जारी रखने से पहले फ़ेच और execute होती है। async के साथ, डाउनलोड समानांतर चलता है लेकिन execution तैयार होने पर शुरू हो जाता है, इसलिए क्रम गारंटीकृत नहीं है। defer के साथ, क्लासिक बाहरी स्क्रिप्ट्स पार्सिंग के बाद और document order में DOMContentLoaded से पहले रन करती हैं। ordered स्क्रिप्ट्स के लिए defer उपयुक्त है; यह सार्वभौमिक नहीं है।
वैकल्पिक चैट, सोशल, मानचित्र, वीडियो, या रिकमेंडेशन इंटरफेस के लिए हल्का प्लेसहोल्डर रेंडर करें और क्लिक या प्रासंगिक होने पर विक्रेता को लोड करें। यह facade पैटर्न पूर्ण एम्बेड के बजाय आपकी नियंत्रण वाली शुरुआत देता है। कीबोर्ड इंटरैक्शन बनाए रखें और स्थान रिज़र्व करें। मूल्य की गणना, साइन-इन, भुगतान प्रक्रिया, आवश्यक एक्सेसिबिलिटी, या पुष्टि किए गए दायित्वों के लिए आवश्यक कोड को बिना समीक्षा किए वैकल्पिक के रूप में न टालें।
सिर्फ़ पहले-काम निर्भरता के लिए तुरंत लोड करें; क्रमबद्ध कोड के लिए पोस्ट-parse का उपयोग करें और वैकल्पिक एम्बेड्स के लिए इंटरैक्शन या विजिबिलिटी ट्रिगर चुनें।
इंटरडिपेंडेंट स्क्रिप्ट्स को async मार्क करके क्रम की उम्मीद न रखें। प्रकाशित चेन को दस्तावेज़ और परीक्षण करें।
निर्णायक UI को window load से बाँधें नहीं; तीसरे-पक्ष एम्बेड्स window load को धीमा कर सकते हैं, भले ही async या defer उपयोग में हों।
सहमति को गेट बनाएं, न कि बाद की सोच
प्रत्येक विक्रेता को गोपनीयता और कानूनी स्टेकहोल्डर्स के साथ वर्गीकृत करें जो विधिक अधिकारक्षेत्र और डेटा फ्लो समझते हों। एक सहमति-गेटेड इंटीग्रेशन के लिए, टैग संबंधित डेटा भेजने से पहले सहमति स्थिति स्थापित करें। Google कहता है कि इसकी डिफ़ॉल्ट consent कमांड को मीज़रमेंट कमांड्स से पहले चलना चाहिए, और बदली गयी पसंद के बाद अपडेट्स का पालन होना चाहिए। यह प्रोडक्ट मार्गदर्शन कानूनी सलाह नहीं है।
पहली विज़िट में बिना विकल्प, स्वीकार, अस्वीकार और वापसी पर परीक्षण करें। इंटरफ़ेस और नेटवर्क दोनों चेक करें: एक छुपा हुआ विजेट यह साबित नहीं करता कि कोई अनुरोध या पहचानकर्ता नहीं भेजा गया। यदि सहमति प्लेटफ़ॉर्म असिंक्रोनस रूप से लोड होता है, तो समयिंग का परीक्षण करें। विकल्पों को उपयुक्त रूप से स्थायी करें और वर्तमान पृष्ठ व बाद की विज़िट्स पर परिवर्तन लागू करें।
विक्रेता लेबल पर भरोसा न करें। यह रिकॉर्ड करें कि टैग किसी क्षेत्र या यात्रा के लिए अनिवार्य, वैकल्पिक, या निषिद्ध क्यों है और अनुमोदन प्राप्त करें।
वापसी के बाद, पुष्टि करें कि कॉन्फ़िगर किए गए गैर-आवश्यक टैग लोड या डेटा नहीं भेजते और परीक्षण साक्ष्य रखें।
आपके नियंत्रण में नहीं होने वाले कोड के ब्लास्ट रेडियस को कम करें
OWASP क्लाइंट-साइड परिवर्तन पर नियंत्रण खोने, ब्राउज़र में arbitrary code execution, और संवेदनशील-डेटा के खुलासे को केंद्रीय जोखिम के रूप में पहचानता है। टैग-पब्लिशिंग एक्सेस सीमित करें, कस्टम HTML या arbitrary-code फीचर्स की समीक्षा करें, और अनुमत डेटा-लेयर फ़ील्ड्स दस्तावेज़ करें। उच्च-जोखिम इंटीग्रेशन के लिए विक्रेता अनुबंध और योग्य सुरक्षा समीक्षा मदद कर सकते हैं; परन्तु ये परीक्षण का स्थान नहीं लेतीं।
Subresource Integrity, या SRI, ब्राउज़र को किसी स्क्रिप्ट की क्रिप्टोग्राफिक हैश के खिलाफ सत्यापित करने देता है। यह केवल तब मदद करता है जब स्रोत पिन किया जा सके और क्रॉस-ओरिजन डिलीवरी CORS का समर्थन करे; W3C कहता है कि CORS के बिना SRI का उपयोग तर्कगत त्रुटि है। यह कई बदलते विक्रेता URLs के लिए खराब फिट है। एक iframe sandbox होस्ट DOM और कुकीज़ तक सीधे पहुँच को कम कर सकता है, पर विशेषज्ञ समीक्षा की आवश्यकता होती है। भुगतान और सुरक्षा-संवेदनशील फ़्लो के लिए योग्य समीक्षा अनिवार्य है।
केवल प्रयोजन के लिए आवश्यक दस्तावेजीकृत फ़ील्ड पास करें। सीक्रेट्स, भुगतान डेटा, या अनावश्यक ग्राहक गुण उजागर न करें।
SRI बाइट्स की सत्यापन करता है, यह नहीं कि डेटा उपयोग या बाद की अनुरोध-श्रृंखला उपयुक्त है; अलगाव एक प्लग-इन समाधान नहीं है।
ग्राहक अनुभव से पहले विक्रेता विफलता का अभ्यास करें
प्रत्येक रखे गए विक्रेता के लिए, उसके डोमेन्स को एक परीक्षण वातावरण या ब्राउज़र अनुरोध ब्लॉककर में ब्लॉक करें, फिर यात्रा का अभ्यास करें। धीमे उत्तरों और टैग-मैनेजर कॉन्फ़िगरेशन बिना इंटीग्रेशन के भी परीक्षण करें। प्राथमिक सामग्री, नेविगेशन, फ़ॉर्म्स, चेकआउट और अकाउंट एक्सेस वांछित व्यवहार करते हैं यह पुष्टि करें। यह रिलीज़ से पहले मान्य धारणाओं को उजागर करता है।
घटना से पहले निवारण परिभाषित करें: कौन टैग डिसेबल कर सकता है, क्या फ्लैग या टैग-मैनेजर पब्लिश आवश्यक है, कैसे रोलबैक करेंगे, और कैसे सत्यापित करेंगे। SIU सक्रिय अपटाइम अनुकूलन और निवारण है: इन्वेंटरी, बजट, प्रीफ़्लाइट, और रोलबैक अभ्यास का उपयोग करके निर्भरता जोखिम कम करें। SIU विक्रेता इंफ्रास्ट्रक्चर को नियंत्रित नहीं कर सकता, उपलब्धता की गारंटी नहीं दे सकता, और समीक्षा की जगह नहीं लेता।
कहें कि विक्रेता के बिना क्या उपयोगी रहता है, क्या घट सकता है, फॉलबैक क्या है, और डिसेबल करने से पहले अधिकतम देरी कितनी है।
परिवर्तन रिकॉर्ड में पहले और बाद का ट्रेस, सहमति परिणाम, ब्लॉक किए गए विक्रेता का परिणाम, और रोलबैक मालिक संलग्न करें।