टैग और टैग मैनेजर के लिए सबसे सही तरीके

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के लिए, टैग और टैग मैनेजर को ऑप्टिमाइज़ करें.

Katie Hempenius

Barry Pollard

टैग तीसरे पक्ष के कोड के स्निपेट होते हैं जो किसी साइट में आम तौर पर टैग मैनेजर के ज़रिए डाले जाते हैं. मार्केटिंग और आंकड़ों के लिए, आम तौर पर टैग का इस्तेमाल सबसे ज़्यादा किया जाता है.

ध्यान दें: हालांकि, टैग और तीसरे पक्ष की स्क्रिप्ट आम तौर पर एक जैसे ही होते हैं, लेकिन अलग-अलग शब्दावली में इन स्क्रिप्ट के इस्तेमाल के अलग-अलग तरीके दिखते हैं: "टैग" का मालिकाना हक आम तौर पर मार्केटिंग डिपार्टमेंट के पास होता है और इन्हें टैग मैनेजर के ज़रिए जोड़ा जाता है. वहीं, "तीसरे पक्ष की स्क्रिप्ट" में आम तौर पर इंजीनियरिंग डिपार्टमेंट के कोड में बदलाव करके जोड़े गए संसाधनों का ज़िक्र होता है.

टैग और टैग मैनेजर की परफ़ॉर्मेंस पर, अलग-अलग साइटों के हिसाब से बहुत ज़्यादा असर देखने को मिलता है. टैग मैनेजर की तुलना किसी लिफ़ाफ़े से की जा सकती है: टैग मैनेजर एक लिफ़ाफ़ा उपलब्ध कराता है—लेकिन आप उसमें क्या डालते हैं और उसका इस्तेमाल कैसे करते हैं, यह आप पर निर्भर करता है.

इस लेख में, टैग और टैग मैनेजर को ऑप्टिमाइज़ करने की उन तकनीकों के बारे में बताया गया है जिनकी मदद से परफ़ॉर्मेंस और वेबसाइट की परफ़ॉर्मेंस की जानकारी मिलती है. हालांकि, इस लेख में Google Tag Manager के बारे में बताया गया है, लेकिन यहां बताए गए कई आइडिया दूसरे टैग मैनेजर पर भी लागू होते हैं.

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर असर

Tag Manager, अक्सर आपकी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर असर डाल सकता है. यह अप्रत्यक्ष रूप से, आपके पेज को जल्दी लोड करने और उसे रिस्पॉन्सिव बनाए रखने के लिए ज़रूरी संसाधनों का इस्तेमाल करता है. बैंडविथ का इस्तेमाल, आपकी साइटों के लिए टैग मैनेजर JavaScript या इससे किए जाने वाले बाद के कॉल को डाउनलोड करने में किया जा सकता है. मुख्य थ्रेड पर सीपीयू के समय का इस्तेमाल, टैग मैनेजर और टैग में मौजूद JavaScript का आकलन करने और उसे लागू करने में किया जा सकता है.

सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय (एलसीपी) के लोड होने में लगने वाले समय के दौरान, बैंडविथ पर होने वाले विवाद का जोखिम बढ़ सकता है. इसके अलावा, मुख्य थ्रेड को ब्लॉक करने से एलसीपी को रेंडर होने में ज़्यादा समय लग सकता है.

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

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

टैग के टाइप

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

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

टैग के बारे में बात करते समय, बड़े पैमाने पर ध्यान दें: किसी भी एक टैग का परफ़ॉर्मेंस पर असर न के बराबर हो सकता है—लेकिन जब एक ही पेज पर दस या सैकड़ों टैग इस्तेमाल किए जाते हैं, तो यह काफ़ी अहम हो सकता है.

टैग मैनेजर का इस्तेमाल करके सभी स्क्रिप्ट लोड नहीं की जानी चाहिए

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

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

कस्टम एचटीएमएल टैग के इस्तेमाल में सावधानी बरतें

कस्टम एचटीएमएल टैग कई सालों से मौजूद हैं और ज़्यादातर साइटों पर इनका बहुत ज़्यादा इस्तेमाल किया जाता है. कस्टम एचटीएमएल टैग से, आपको कुछ पाबंदियों के साथ अपना कोड डालने की सुविधा मिलती है. साथ ही, नाम के बावजूद, इस टैग का मुख्य इस्तेमाल पेज में कस्टम <script> एलिमेंट को जोड़ना होता है.

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

कस्टम एचटीएमएल टैग आस-पास के पेज में कोई एलिमेंट डाल सकते हैं. पेज में एलिमेंट डालने की वजह से परफ़ॉर्मेंस से जुड़ी समस्याएं हो सकती हैं. कुछ मामलों में, इसकी वजह से लेआउट शिफ़्ट भी हो सकते हैं.

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

ध्यान दें: अगर किसी पेज पर दिखने वाला कॉन्टेंट जोड़ा या बदला जा रहा है, तो यह ध्यान रखें कि सर्च इंजन के लिए यह ज़रूरी है कि वह इस्तेमाल किए गए JavaScript को फ़ेच और प्रोसेस कर पाए. Google की ओर से, Search के लिए किसी पेज को रेंडर किए जाने की पुष्टि की जा सकती है. दूसरे सर्च इंजन में भी इससे मिलते-जुलते टेस्टिंग टूल उपलब्ध हो सकते हैं.

कस्टम टेंप्लेट इस्तेमाल करें

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

कस्टम टेंप्लेट पर लगाई गई पाबंदियों की वजह से, इन टैग में परफ़ॉर्मेंस या सुरक्षा से जुड़ी समस्याएं होने की संभावना बहुत कम होती है. हालांकि, इन्हीं वजहों से, कस्टम टेंप्लेट सभी तरह के इस्तेमाल के उदाहरणों में काम नहीं करेंगे.

स्क्रिप्ट को सही तरीके से इंजेक्ट करें

स्क्रिप्ट इंजेक्ट करने के लिए टैग मैनेजर का इस्तेमाल करना, इस्तेमाल का एक बहुत ही सामान्य उदाहरण है. हमारा सुझाव है कि आप कस्टम टेंप्लेट और injectScript एपीआई का इस्तेमाल करें.

किसी मौजूदा कस्टम एचटीएमएल टैग को बदलने के लिए, injectScript API का इस्तेमाल करने के बारे में जानकारी के लिए, मौजूदा टैग को बदलें देखें.

अगर आपको कस्टम एचटीएमएल टैग का इस्तेमाल करना ज़रूरी है, तो इन बातों का ध्यान रखें:

• लाइब्रेरी और तीसरे पक्ष की बड़ी स्क्रिप्ट को ऐसे स्क्रिप्ट टैग से लोड किया जाना चाहिए जो स्क्रिप्ट के कॉन्टेंट को सीधे टैग में कॉपी करने के बजाय, बाहरी फ़ाइल (उदाहरण के लिए, <script src="external-scripts.js">) को डाउनलोड करता हो. हालांकि, <script> टैग का बार-बार इस्तेमाल करने से, स्क्रिप्ट का कॉन्टेंट डाउनलोड करने के लिए अलग से राउंड ट्रिप हट जाती है. हालांकि, ऐसा करने से कंटेनर का साइज़ बढ़ जाता है और ब्राउज़र में स्क्रिप्ट को अलग से कैश मेमोरी में सेव नहीं किया जा सकता.
• कई वेंडर, अपने <script> टैग को <head> के सबसे ऊपर रखने का सुझाव देते हैं. हालांकि, टैग मैनेजर से लोड की गई स्क्रिप्ट के लिए, आम तौर पर यह सुझाव ज़रूरी नहीं होता है: ज़्यादातर स्थितियों में, टैग मैनेजर के चालू होने से पहले ही ब्राउज़र <head> को पार्स कर चुका होता है.

पिक्सल का इस्तेमाल करें

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

पिक्सल की सुविधा देने वाली तीसरे पक्ष की सुविधा के बारे में ज़्यादा जानने के लिए, उससे संपर्क करें. इसके अलावा, आपके पास <noscript> टैग के लिए उनके कोड की जांच करने का विकल्प है. अगर कोई वेंडर पिक्सल की सुविधा देता है, तो वह अक्सर उन्हें <noscript> टैग में शामिल करेगा.

पिक्सल के विकल्प

Pixel बड़े पैमाने पर लोकप्रिय हो गए थे, क्योंकि एक समय में वे ऐसी स्थितियों में HTTP अनुरोध करने के सबसे सस्ते और भरोसेमंद तरीकों में से एक थे जहां सर्वर का जवाब काम का नहीं होता था ( उदाहरण के लिए, आंकड़ों की सेवा देने वाली कंपनियों को डेटा भेजते समय). navigator.sendBeacon() और fetch() keepalive एपीआई को इस तरह के इस्तेमाल के लिए डिज़ाइन किया गया है. हालांकि, वे पिक्सल से ज़्यादा भरोसेमंद हैं.

ध्यान दें: sendBeacon() और fetch() keepalive एपीआई अब भी उस स्थिति में काम करेंगे जब ब्राउज़र, पेज को अनलोड कर रहा हो: उदाहरण के लिए, इन दोनों एपीआई का इस्तेमाल आउटबाउंड लिंक क्लिक को ट्रैक करने के लिए किया जा सकता है. इसके उलट, पिक्सल और XMLHttpRequest जैसी तकनीकें इन मामलों में काम नहीं करेंगी.

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

sendBeacon()

navigator.sendBeacon() एपीआई को वेब सर्वर पर कम डेटा भेजने के लिए डिज़ाइन किया गया है. इसे उन स्थितियों में भी डिज़ाइन किया गया है जहां सर्वर के रिस्पॉन्स से कोई फ़र्क़ नहीं पड़ता.

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() का एक सीमित एपीआई है: यह सिर्फ़ पोस्ट अनुरोध करने की सुविधा देता है और कस्टम हेडर सेट करने की सुविधा नहीं देता. यह सभी आधुनिक ब्राउज़र पर काम करता है.

fetch() keepalive

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

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

अगर fetch() keepalive और sendBeacon() काफ़ी मिलते-जुलते हैं, तो ऐसा इसलिए है, क्योंकि वे दोनों एक जैसे हैं. Chromium ब्राउज़र में, sendBeacon() अब fetch() keepalive पर बनाया गया है.

fetch() keepalive और sendBeacon() के बीच चुनते समय, अपनी ज़रूरत की सुविधाओं और ब्राउज़र सहायता पर ध्यान देना ज़रूरी है. फ़ेच() एपीआई काफ़ी ज़्यादा सुविधाजनक है. हालांकि, sendBeacon() के मुकाबले keepalive में कम ब्राउज़र काम करता है.

जानकारी पाएं

टैग अक्सर तीसरे पक्ष के वेंडर के दिशा-निर्देशों की मदद से बनाए जाते हैं. अगर यह अब तक साफ़ तौर पर नहीं पता है कि वेंडर के कोड का क्या होता है—तो किसी ऐसे व्यक्ति से पूछें जिसे इस बारे में जानकारी हो. दूसरे व्यक्ति की राय से यह पता लगाने में मदद मिल सकती है कि टैग में परफ़ॉर्मेंस या सुरक्षा से जुड़ी समस्याएं हो सकती हैं या नहीं.

Tag Manager में, टैग को मालिक के साथ लेबल करने का भी सुझाव दिया जाता है. यह भूल पाना बहुत आसान है कि टैग का मालिक कौन है. साथ ही, हो सकता है कि आप टैग को हटा दें!

ट्रिगर

बड़े लेवल पर, टैग ट्रिगर को ऑप्टिमाइज़ करते समय, आम तौर पर यह पक्का किया जाता है कि ज़रूरत से ज़्यादा टैग ट्रिगर न किए जाएं. साथ ही, ऐसे ट्रिगर को चुना जाता है जो कारोबार की ज़रूरतों को परफ़ॉर्मेंस की लागत के साथ संतुलित करता हो.

ट्रिगर खुद JavaScript कोड होते हैं, जो टैग मैनेजर का आकार—और निष्पादन लागत—बढ़ा देंगे. हालांकि, ज़्यादातर ट्रिगर छोटे होते हैं, लेकिन कुल मिलाकर असर बढ़ सकता है. उदाहरण के लिए कई क्लिक इवेंट या टाइमर ट्रिगर होने से, टैग मैनेजर पर बहुत ज़्यादा काम का दबाव बढ़ सकता है.

सही ट्रिगर इवेंट चुनें

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

हालांकि, सभी टैग के लिए सही ट्रिगर चुनना ज़रूरी है, लेकिन यह खास तौर पर उन टैग के लिए ज़रूरी है जो बड़े संसाधन लोड करते हैं या लंबी स्क्रिप्ट चलाते हैं.

टैग, पेज व्यू या किसी कस्टम इवेंट के आधार पर ट्रिगर हो सकते हैं. आम तौर पर, ये टैग Page load, DOM Ready, Window Loaded पर ट्रिगर होते हैं. पेज लोड पर असर न पड़े, इसके लिए यह सुझाव दिया जाता है कि आप ग़ैर-ज़रूरी टैग को Window Loaded के बाद चालू करें.

कस्टम इवेंट का इस्तेमाल करना

कस्टम इवेंट की मदद से, उन पेज इवेंट के लिए ट्रिगर ट्रिगर किए जा सकते हैं जो Google Tag Manager के बिल्ट-इन ट्रिगर में शामिल नहीं हैं. उदाहरण के लिए, कई टैग पेज व्यू ट्रिगर का इस्तेमाल करते हैं. हालांकि, कई पेजों पर DOM Ready और Window Loaded के बीच की समयावधि ज़्यादा लंबी हो सकती है. इस वजह से, टैग ट्रिगर होने पर उसे बेहतर बनाना मुश्किल हो सकता है. कस्टम इवेंट इस समस्या का समाधान करते हैं.

कस्टम इवेंट का इस्तेमाल करने के लिए, सबसे पहले एक कस्टम इवेंट ट्रिगर बनाएं और इस ट्रिगर का इस्तेमाल करने के लिए अपने टैग अपडेट करें.

ट्रिगर को सक्रिय करने के लिए, उससे जुड़े इवेंट को डेटा लेयर में पुश करें.

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

ट्रिगर की खास शर्तों का इस्तेमाल करना

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

टैग ट्रिगर होने की स्थिति को सीमित करने के लिए, बिल्ट-इन वैरिएबल को भी ट्रिगर की शर्तों में शामिल किया जा सकता है.

हालांकि, ध्यान रखें कि ट्रिगर की जटिल शर्तों या अपवादों के होने पर, प्रोसेस में समय और बंद होने लगता है. इसलिए, उन्हें बहुत जटिल न बनाएं.

अपने टैग मैनेजर को सही समय पर लोड करें

टैग मैनेजर के अपने-आप लोड होने के समय में बदलाव करने से, परफ़ॉर्मेंस पर काफ़ी असर पड़ सकता है. ट्रिगर, भले ही उन्हें किसी भी तरह कॉन्फ़िगर किया गया हो, टैग मैनेजर के लोड होने तक ट्रिगर नहीं हो सकते. हालांकि, अलग-अलग टैग के लिए अच्छे ट्रिगर चुनना ज़रूरी है (जैसा कि ऊपर बताया गया है), लेकिन अपना टैग मैनेजर लोड करते समय प्रयोग करने से, अक्सर अच्छा या ज़्यादा असर पड़ सकता है, क्योंकि यह एक ही फ़ैसला पेज के सभी टैग पर असर डालेगा.

टैग मैनेजर को बाद में लोड करने से कंट्रोल भी मिलता है. इससे आने वाले समय में परफ़ॉर्मेंस से जुड़ी समस्याओं से बचा जा सकता है. इसकी वजह यह है कि टैग मैनेजर का उपयोगकर्ता अनजाने में टैग को बहुत जल्दी लोड कर देगा और उन्हें इस काम के असर का पता भी नहीं चलेगा.

वैरिएबल

वैरिएबल की मदद से, पेज से डेटा पढ़ा जा सकता है. वे ट्रिगर और खुद टैग में काम आते हैं.

ट्रिगर की तरह ही, वैरिएबल की वजह से टैग मैनेजर में JavaScript कोड जुड़ता है. इससे परफ़ॉर्मेंस से जुड़ी समस्याएं हो सकती हैं. वैरिएबल काफ़ी हद तक आसान बिल्ट-इन टाइप हो सकते हैं. उदाहरण के लिए, ये यूआरएल के हिस्सों, कुकी, डेटा लेयर या DOM को पढ़ सकते हैं. या वे कस्टम JavaScript हो सकते हैं, जो उसकी क्षमताओं के हिसाब से अनलिमिटेड है.

वैरिएबल को सरल और कम से कम रखें, क्योंकि उनका आकलन टैग मैनेजर को लगातार करना होगा. Tag Manager स्क्रिप्ट का साइज़ और प्रोसेस होने में लगने वाले समय, दोनों को कम करने के लिए, इस्तेमाल नहीं होने वाले पुराने वैरिएबल हटाएं.

टैग मैनेजमेंट

टैग का बेहतर तरीके से इस्तेमाल करने से, परफ़ॉर्मेंस की समस्याओं का खतरा कम हो जाएगा.

डेटा लेयर का इस्तेमाल करना

डेटा लेयर "में वह सारी जानकारी शामिल होती है जिसे आपको Google Tag Manager को भेजना है". कुल मिलाकर, यह ऑब्जेक्ट की एक JavaScript कलेक्शन है, जिसमें पेज के बारे में जानकारी होती है. इसका इस्तेमाल टैग को ट्रिगर करने के लिए भी किया जा सकता है.

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

हालांकि, Google Tag Manager का इस्तेमाल डेटा लेयर के बिना किया जा सकता है, लेकिन हम इसके इस्तेमाल की सलाह देते हैं. डेटा लेयर की मदद से, तीसरे पक्ष की स्क्रिप्ट से ऐक्सेस किए जा रहे डेटा को एक ही जगह पर इकट्ठा किया जा सकता है. इससे, इसके इस्तेमाल के बारे में बेहतर जानकारी मिलती है. इसके अलावा, इससे अतिरिक्त वैरिएबल कैलकुलेशन और स्क्रिप्ट के एक्ज़ीक्यूशन को कम किया जा सकता है. डेटा लेयर का इस्तेमाल करने से, पूरा JavaScript वैरिएबल या डीओएम ऐक्सेस देने के बजाय, टैग से ऐक्सेस किए जा रहे डेटा को भी कंट्रोल किया जा सकता है.

ध्यान दें: इस वजह से डेटा लेयर की परफ़ॉर्मेंस को समझना मुश्किल लग सकता है. इसकी वजह यह है कि डेटा लेयर को अपडेट करने से Google Tag Manager, सभी कंटेनर वैरिएबल का फिर से आकलन करता है और टैग को ट्रिगर करता है. साथ ही, इन सभी का इस्तेमाल करने के लिए JavaScript का एक्ज़ीक्यूशन करना ज़रूरी है. आम तौर पर, डेटा लेयर के गलत इस्तेमाल की संभावना होती है. आम तौर पर, अगर डेटा लेयर के साथ काम करने की वजह से परफ़ॉर्मेंस से जुड़ी समस्याएं होती हैं, तो हो सकता है कि इससे यह पता चलता हो कि कंटेनर में परफ़ॉर्मेंस से जुड़ी समस्याएं हैं. डेटा लेयर की वजह से, इन समस्याओं को साफ़ तौर पर ज़ाहिर किया जा सकता है.

डुप्लीकेट और इस्तेमाल न होने वाले टैग हटाएं

जब किसी टैग को Tag Manager की मदद से इंजेक्ट किए जाने के अलावा, पेज के एचटीएमएल मार्कअप में शामिल किया जाता है, तब डुप्लीकेट टैग भी शामिल हो सकते हैं.

इस्तेमाल नहीं किए गए टैग को ट्रिगर अपवाद का इस्तेमाल करके ब्लॉक करने के बजाय, रोक देना चाहिए या हटा देना चाहिए. किसी टैग को रोकने या हटाने से कंटेनर से कोड हट जाता है, जबकि ब्लॉक करने से ऐसा नहीं होता.

इस्तेमाल नहीं किए गए टैग हटाए जाने पर, ट्रिगर और वैरिएबल की भी समीक्षा की जानी चाहिए. यह जानने के लिए कि क्या उनमें से किसी का इस्तेमाल सिर्फ़ उन टैग में किया गया है, तो उन्हें हटाया जा सकता है.

अनुमति दें और अस्वीकार करें वाली सूचियों का इस्तेमाल करना

अनुमतियों और अस्वीकार की सूचियों की मदद से, किसी पेज पर लागू टैग, ट्रिगर, और वैरिएबल पर ज़्यादा बारीकी से पाबंदी लगाई जा सकती है. इसका इस्तेमाल, परफ़ॉर्मेंस के सबसे सही तरीकों और दूसरी नीतियों को लागू करने में किया जा सकता है.

अनुमति दें और अस्वीकार करें वाली सूचियों को, डेटा लेयर के ज़रिए कॉन्फ़िगर किया जाता है.

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

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

सर्वर साइड टैगिंग का इस्तेमाल करें

सर्वर साइड टैगिंग पर स्विच करना कोई आसान काम नहीं है, लेकिन इस पर स्विच करना फ़ायदेमंद नहीं है - खास तौर पर ऐसी बड़ी साइटों के लिए जो अपने डेटा पर ज़्यादा कंट्रोल चाहती हैं. सर्वर साइड टैगिंग से वेंडर कोड को क्लाइंट से हटा दिया जाता है. साथ ही, इससे क्लाइंट से सर्वर पर प्रोसेसिंग ऑफ़लोड हो जाती है.

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

ध्यान रखें कि सर्वर साइड टैगिंग सिर्फ़ कुछ टैग के साथ काम करती है. टैग के साथ काम करने की सुविधा, वेंडर के हिसाब से अलग-अलग होती है.

ज़्यादा जानकारी के लिए, सर्वर साइड टैगिंग के बारे में जानकारी देखें.

कंटेनर

आम तौर पर, टैग मैनेजर अपने सेट अप में कई इंस्टेंस या "कंटेनर" को अनुमति देते हैं. इसकी मदद से, एक टैग मैनेजर खाते में कई कंटेनर को कंट्रोल किया जा सकता है.

हर पेज पर सिर्फ़ एक कंटेनर इस्तेमाल करें

एक ही पेज पर कई containers का इस्तेमाल करने से परफ़ॉर्मेंस से जुड़ी बड़ी समस्याएं हो सकती हैं, क्योंकि इससे अतिरिक्त ओवरहेड और स्क्रिप्ट एक्ज़ीक्यूशन हो सकता है. यह मूल टैग कोड का ही डुप्लीकेट बनाता है, क्योंकि उसे कंटेनर की JavaScript के हिस्से के तौर पर डिलीवर किया जाता है. इसलिए, कंटेनर के बीच इसका फिर से इस्तेमाल नहीं किया जा सकता.

ऐसा बहुत कम होता है कि एक से ज़्यादा कंटेनर का असरदार तरीके से इस्तेमाल किया जाए. हालांकि, अगर इसे अच्छी तरह से कंट्रोल किया जा सकता है, तो ऐसे कई उदाहरण हो सकते हैं. जैसे:

• एक बड़े कंटेनर के बजाय, हल्का और "बाद में लोड होने वाला" कंटेनर होना चाहिए.
• कम तकनीकी उपयोगकर्ताओं के ज़रिए प्रतिबंधित कंटेनर का इस्तेमाल करना, जिसमें टैग के लिए कम सीमित लेकिन ज़्यादा सख्ती से नियंत्रित किया गया कंटेनर हो, जिसे प्रतिबंधित कंटेनर में इस्तेमाल नहीं किया जा सकता.

अगर आपको हर पेज के लिए एक से ज़्यादा कंटेनर का इस्तेमाल करना है, तो एक से ज़्यादा कंटेनर सेट अप करने के लिए, Google Tag Manager के निर्देशों का पालन करें.

अगर ज़रूरी हो, तो अलग-अलग कंटेनर का इस्तेमाल करें

अगर आपने एक से ज़्यादा प्रॉपर्टी (उदाहरण के लिए, वेब ऐप्लिकेशन और मोबाइल ऐप्लिकेशन) के लिए टैग मैनेजर का इस्तेमाल किया है, तो आपके इस्तेमाल किए जाने वाले कंटेनर की संख्या से आपके वर्कफ़्लो की प्रोडक्टिविटी कम हो सकती है. इससे परफ़ॉर्मेंस पर भी असर पड़ सकता है.

आम तौर पर, अगर साइटों का इस्तेमाल और स्ट्रक्चर एक जैसा है, तो एक कंटेनर का असरदार तरीके से कई साइटों में इस्तेमाल किया जा सकता है. उदाहरण के लिए, हालांकि किसी ब्रैंड का मोबाइल और वेब ऐप्लिकेशन एक जैसे काम कर सकता है, लेकिन ऐसा हो सकता है कि ऐप्लिकेशन की बनावट अलग-अलग हो और इसलिए अलग-अलग कंटेनर की मदद से उसे ज़्यादा असरदार तरीके से मैनेज किया जाए.

किसी एक कंटेनर को बहुत बड़े पैमाने पर फिर से इस्तेमाल करने की कोशिश से, आम तौर पर कंटेनर की जटिलता और उसका साइज़ बढ़ जाता है. ऐसा करने से, टैग और ट्रिगर को मैनेज करने के लिए मुश्किल लॉजिक का इस्तेमाल करना पड़ता है.

कंटेनर के साइज़ पर नज़र रखें

कंटेनर का साइज़ उसके टैग, ट्रिगर, और वैरिएबल से तय होता है. हालांकि, छोटा कंटेनर अब भी पेज की परफ़ॉर्मेंस पर बुरा असर डाल सकता है, लेकिन एक बड़ा कंटेनर काफ़ी हद तक दिखेगा.

टैग के इस्तेमाल को ऑप्टिमाइज़ करते समय, कंटेनर का साइज़, नॉर्थ-स्टार मेट्रिक नहीं होना चाहिए. हालांकि, कंटेनर का साइज़ बड़ा होना अक्सर चेतावनी का संकेत होता है. यह चेतावनी का मतलब है कि कंटेनर का रखरखाव सही तरीके से नहीं किया गया है और इसका गलत इस्तेमाल हो सकता है.

Google Tag Manager, कंटेनर का साइज़ 200 केबी तक सीमित कर देता है. साथ ही, 140 केबी से शुरू होने वाले कंटेनर के साइज़ के बारे में चेतावनी देगा. हालांकि, ज़्यादातर साइटों को अपने कंटेनर को इससे बहुत छोटा रखना चाहिए. सही मायनों में, साइट कंटेनर का मीडियन 50 केबी का होता है.

अपने कंटेनर का साइज़ जानने के लिए, https://www.googletagmanager.com/gtag/js?id=YOUR_ID से मिले रिस्पॉन्स का साइज़ देखें. इस रिस्पॉन्स में, Google Tag Manager की लाइब्रेरी के साथ-साथ कंटेनर का कॉन्टेंट भी शामिल है. Google Tag Manager लाइब्रेरी का साइज़ 33 केबी तक होता है.

अपने कंटेनर वर्शन को नाम दें

कंटेनर वर्शन, किसी खास समय पर कंटेनर के कॉन्टेंट का स्नैपशॉट होता है. सही नाम का इस्तेमाल करने के साथ-साथ, काम के बदलावों के बारे में कम शब्दों में जानकारी देने से, आने वाले समय में परफ़ॉर्मेंस से जुड़ी समस्याओं को डीबग करने में मदद मिल सकती है.

वर्कफ़्लो को टैग करना

अपने टैग में बदलावों को मैनेज करना ज़रूरी है, ताकि यह पक्का किया जा सके कि उनका पेज की परफ़ॉर्मेंस पर कोई बुरा असर न पड़े.

लागू करने से पहले टैग की जांच करें

डिप्लॉयमेंट से पहले अपने टैग की जांच करने से, उन्हें शिप करने से पहले समस्याओं (परफ़ॉर्मेंस और अन्य तरीकों से) को समझने में मदद मिल सकती है.

टैग को टेस्ट करते समय इन बातों का ध्यान रखें:

• क्या टैग ठीक से काम कर रहा है?
• क्या टैग की वजह से कोई लेआउट शिफ़्ट हुआ है?
• क्या टैग, किसी संसाधन को लोड करता है? ये संसाधन कितने बड़े हैं?
• क्या टैग, लंबे समय तक चलने वाली स्क्रिप्ट को ट्रिगर करता है?

'झलक देखें' मोड

झलक मोड की मदद से, अपनी असल साइट पर टैग में हुए बदलावों की जांच की जा सकती है. ऐसा करने के लिए, आपको उन्हें सार्वजनिक तौर पर डिप्लॉय नहीं करना पड़ता. 'झलक देखें' मोड में एक डीबगिंग कंसोल होता है, जो टैग के बारे में जानकारी देता है.

'झलक देखें' मोड में चलाने पर 'Google टैग मैनेजर' को चलाने का समय अलग (थोड़ा धीमा) होगा, क्योंकि डीबगिंग कंसोल में जानकारी को दिखाने के लिए अतिरिक्त ओवरहेड की ज़रूरत होती है. इसलिए, झलक मोड में इकट्ठा किए गए वेब वाइटल मेज़रमेंट की तुलना, प्रोडक्शन में इकट्ठा किए गए डेटा से करने का सुझाव नहीं दिया जाता. हालांकि, इस अंतर का असर टैग के काम करने के तरीके पर नहीं पड़ेगा.

स्टैंडअलोन टेस्टिंग

टैग की जांच करने का एक वैकल्पिक तरीका यह है कि आप एक टैग वाले कंटेनर वाला खाली पेज सेट अप करें—जिस टैग की आप जांच कर रहे हैं. टेस्ट करने का यह सेटअप असली नहीं है और इसमें कुछ समस्याओं का पता नहीं चलता (उदाहरण के लिए, क्या टैग की वजह से लेआउट शिफ़्ट होता है)—हालांकि, इससे स्क्रिप्ट चलाने जैसी चीज़ों पर टैग के असर को अलग करना और मेज़र करना आसान हो सकता है. जानें कि Telegraph, तीसरे पक्ष के कोड की परफ़ॉर्मेंस को बेहतर बनाने के लिए किस तरह आइसोलेशन के इस तरीके का इस्तेमाल करता है.

टैग की परफ़ॉर्मेंस पर नज़र रखें

Google Tag Manager के Monitoring API का इस्तेमाल, किसी खास टैग के कार्रवाई के समय के बारे में जानकारी इकट्ठा करने के लिए किया जा सकता है. यह जानकारी आपके चुने गए एंडपॉइंट को रिपोर्ट की जाती है.

ज़्यादा जानकारी के लिए, Google Tag Manager मॉनिटर बनाने का तरीका लेख पढ़ें.

कंटेनर में बदलाव करने के लिए अनुमति ज़रूरी है

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

समय-समय पर टैग के इस्तेमाल का ऑडिट करना

टैग के साथ काम करने की एक चुनौती यह है कि वे समय के साथ इकट्ठा होते रहते हैं: टैग जुड़ जाते हैं, लेकिन उन्हें कभी-कभी हटा दिया जाता है. समय-समय पर ऑडिट टैग की जांच करना, इस रुझान को उलटने का एक तरीका है. ऐसा करने की सबसे सही फ़्रीक्वेंसी इस बात पर निर्भर करेगी कि आपकी साइट के टैग कितनी बार अपडेट किए जाते हैं.

हर टैग को इस तरह से लेबल करें कि उसके मालिक को साफ़ तौर पर पता चल सके कि उस टैग का जवाब देने वाला कौन है. साथ ही, वह बता सकता है कि टैग की अब भी ज़रूरत है या नहीं.

टैग को ऑडिट करते समय, ट्रिगर और वैरिएबल को हटाना भी न भूलें. वे आसानी से परफ़ॉर्मेंस की समस्याओं की वजह भी हो सकती हैं.

ज़्यादा जानकारी के लिए, तीसरे पक्ष की स्क्रिप्ट को कंट्रोल में रखना लेख पढ़ें.