प्रत्येक तृतीय-पक्ष टैग का स्कोर करें, फिर उसे सर्वर-साइड पर निष्क्रिय करें, स्थगित करें या स्थानांतरित करें।

HTTP आर्काइव के अनुसार, 90% से अधिक पेज कम से कम एक तृतीय-पक्ष सेवा को लोड करते हैं, और शीर्ष 1,000 साइटों पर मोबाइल पर औसतन 106 तृतीय-पक्ष अनुरोध आते हैं - जो पिछले वर्ष की तुलना में 15 अधिक हैं। 2025 वेब पंचांगइन अनुरोधों में स्क्रिप्ट का हिस्सा सबसे बड़ा है, जो 24.8% है।

इसमें से लगभग कुछ भी निर्णय द्वारा नहीं आया। यह एक-एक टैग करके आया, और कुल लागत का कोई मालिक नहीं है। लागत मापने योग्य है: Google की केस स्टडी लाइब्रेरी में वोडाफोन इटली द्वारा एलसीपी में 31% सुधार और उसे अपनाने का रिकॉर्ड है। 8% अधिक बिक्री.

यह गाइड उन लोगों के लिए है जिन्हें Core Web Vitals को ठीक करने का काम सौंपा गया है और जो मार्केटिंग टैग को अपने आप डिलीट नहीं कर सकते। इस गाइड के अंत तक, आपके पास अपनी साइट पर मौजूद हर थर्ड पार्टी के लिए पाँच मानदंडों वाला स्कोर होगा, एक रूटिंग नियम होगा जो हर स्कोर को एक विशिष्ट कार्रवाई में बदल देगा, और एक ऐसा समय होगा जो 380ms में उस मीटिंग के लिए मान्य होगा जिसमें कोई व्यक्ति टैग का बचाव करता है।

कुछ भी हासिल करने से पहले अपना सामान तैयार कर लें।

आपको दो सूचियों की आवश्यकता है; इनमें से कोई भी सूची अपने आप में पूर्ण नहीं है।

कंटेनर सूची। अपने Google Tag Manager कंटेनर को निर्यात करें: टैग, ट्रिगर और वैरिएबल, उनके मालिकों और फायरिंग शर्तों के साथ। यही उद्देश्य है।

नेटवर्क सूची। कैशिंग बंद करके पेज को क्रोम डेवलपर टूल्स में लोड करें, फिर लाइटहाउस चलाएं और "थर्ड-पार्टी कोड के प्रभाव को कम करें" ऑडिट पढ़ें। यही वह कोड है जो वास्तव में निष्पादित होता है, जिसमें अन्य टैग द्वारा इंजेक्ट किए गए टैग भी शामिल हैं, जो कंटेनर एक्सपोर्ट में कभी दिखाई नहीं देते।

दोनों सूचियों में शामिल प्रत्येक तृतीय पक्ष के लिए, सात फ़ील्ड रिकॉर्ड करें:

• विक्रेता और उसके दावे
• व्यवसाय के मालिक का नाम (एक व्यक्ति, विभाग नहीं)
• स्क्रिप्ट स्थानांतरण आकार
• इसके कारण मुख्य थ्रेड अवरुद्ध होने का समय
• क्या यह एलसीपी तत्व के महत्वपूर्ण पथ पर स्थित है?
• यह किन पेज टेम्प्लेट पर सक्रिय होता है
• पिछली बार किसी ने इसके डेटा का उपयोग करके कोई निर्णय लिया था

वह आखिरी फ़ील्ड ही है जिसे लोग अक्सर छोड़ देते हैं, और वही है जो सबसे ज़्यादा बहसें खत्म करती है। फ़ील्ड डेटा के आधार पर स्कोर: कोर वेब वाइटल्स का मूल्यांकन निम्न स्तर पर किया जाता है। वास्तविक पेज लोड का 75वां पर्सेंटाइलऔर तेज़ कनेक्शन पर किया गया लैब रन आपके स्टैक को बेहतर बनाता है।

पांच स्कोरिंग मानदंड

प्रत्येक तृतीय पक्ष को पाँचों पैमानों पर 0-3 अंक दें। उच्च अंक निष्कासन के लिए अधिक ठोस आधार दर्शाते हैं।

कुल योग के ऊपर दो ओवरराइड हैं:

1. कुल संख्या की परवाह किए बिना मारने के लिए प्रदर्शित उपयोग मार्गों पर 3 अंक। ऐसे टैग के लिए कोई भी कीमत चुकाना उचित नहीं है जिसका कोई उपयोग ही न करता हो।
2. क्रिटिकल-पाथ पोजीशन पर 3 का मतलब है कम से कम बैंड 3 तक पहुंचने का मार्ग। हेडर में मौजूद रेंडर-ब्लॉकिंग स्क्रिप्ट संरचनात्मक होती है, चाहे विक्रेता कितना भी मूल्यवान क्यों न हो।

मर्गदर्शक सारणी

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

साइन-ऑफ कॉलम महत्वपूर्ण है क्योंकि प्रत्येक बैंड एक व्यक्ति का नाम बताता है। "टैग्स की वजह से साइट धीमी चल रही है" एक शिकायत है। "इस टैग को 11 अंक मिले, यह व्यक्ति इसे साइन ऑफ करता है" एक टिकट है।

एक हल किया हुआ उदाहरण

एक मिश्रित मिड-मार्केट ई-कॉमर्स चेकआउट प्रक्रिया। यह ग्राहक डेटा नहीं है; संख्याएँ केवल उदाहरण के तौर पर दी गई हैं।

चैट विजेट निर्देशात्मक पंक्ति है। इसका वास्तव में उपयोग होता है और इसे बदला नहीं जा सकता, और यह अभी भी एक मुखौटे की ओर निर्देशित करता है, क्योंकि श्रेणी "क्या हमें इसकी आवश्यकता है" और "क्या हमें पहले 2.5 सेकंड में इसकी आवश्यकता है" के बीच अंतर करती है।

[INTERNAL DATA NEEDED: replace this composite table with a real anonymised inventory from a Switas engagement — vendor category, measured blocking time, post-change field metric.]

तीनों समाधानों को इस आधार पर क्रमबद्ध किया गया है कि वे वास्तव में कितनी बार काम करते हैं।

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

स्थगित करना। कुछ सावधानियों के साथ उपयोगी। क्रोम नेटवर्क प्राथमिकता को कम करता है of async और defer संसाधनों को लोड करने में आपकी अपेक्षा से अधिक समय लगता है - पिक्सेल के लिए तो ठीक है, लेकिन रेंडर होने वाली किसी भी चीज़ के लिए नहीं। web.dev यह भी नोट करता है कि एम्बेड "ब्लॉक कर सकते हैं"। window.onload यदि उनके सर्वर धीमी प्रतिक्रिया देते हैं, तब भी जब एम्बेड एसिंक्रोनस या डेफर का उपयोग कर रहा हो।" डेफर करने से लागत स्थानांतरित हो जाती है; यह हमेशा उसे समाप्त नहीं करती है।

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

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

जहां सहमति की परत गणित को बदल देती है

आपका सहमति प्रबंधन प्लेटफ़ॉर्म आमतौर पर इन्वेंट्री में सबसे अधिक स्कोर करने वाला आइटम होता है: यह हेड में स्थित होता है, यह डिज़ाइन के अनुसार रेंडर-ब्लॉकिंग होता है, और हर दूसरा टैग इस पर निर्भर करता है। इसे अन्य किसी भी चीज़ की तरह ही स्कोर करें।

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

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

तुर्की या बहु-बाजार खुदरा विक्रेता के लिए व्यावहारिक परिणाम यह है: तुर्की ट्रैफ़िक पर बेसिक सहमति मोड और EEA ट्रैफ़िक पर एडवांस्ड सहमति मोड चलाएँ, और आपको किसी भी बाजार में मिलने वाले किसी भी अधिकार का नुकसान नहीं होगा। अधिकांश CMP इसे डिफ़ॉल्ट रूप से नहीं करते हैं। यह एक भौगोलिक क्षेत्र-आधारित कॉन्फ़िगरेशन निर्णय है, प्लगइन नहीं।

इस श्रेणी में निम्नलिखित बातें शामिल नहीं हैं

• यह टैग्स को स्कोर करता है, पेजों को नहीं। होमपेज पर हानिरहित टैग लिस्टिंग पेज पर चालीस टैग लोड होने पर विनाशकारी साबित हो सकता है।
• मुख्य थ्रेड की लागत योगात्मक नहीं है। पांच 100ms टैग हटाने से शायद ही कभी 500ms का परिणाम मिलता है। प्रत्येक परिवर्तन के बाद मापें।
• यह आपके अपने कोड को अनदेखा करता है। फ्रेमवर्क हाइड्रेशन से जुड़े लंबे कार्य अक्सर खराब आईएनपी का एक बड़ा हिस्सा होते हैं, और कोई भी तृतीय-पक्ष ऑडिट उन्हें नहीं खोज पाएगा।
• यह आपको केवल लागत पक्ष की जानकारी देता है। 380ms का टैग, जिससे वास्तविक रूप से अनुमानित राजस्व प्राप्त हो रहा है, उसे रखना फायदेमंद हो सकता है।
• सुरक्षा या डेटा निवास के संबंध में इसकी कोई राय नहीं है।कभी-कभी, यही वह वास्तविक कारण होता है जिसके चलते किसी विक्रेता को जाना चाहिए।
• पिगीबैक्ड टैग कंटेनर निर्यात से छिपे रहते हैं। जहां दोनों सूचियां एक-दूसरे से मेल नहीं खातीं, वहां नेटवर्क की सूची पर भरोसा करें।

सामान्य प्रश्न

मैं किसी विशिष्ट तृतीय पक्ष के लिए मुख्य-थ्रेड लागत को कैसे मापूं? लंबे कार्यों के लिए स्क्रिप्ट स्रोत निर्धारित करने हेतु क्रोम डेवलपर टूल्स के परफॉर्मेंस पैनल का उपयोग करें और लाइटहाउस के "थर्ड-पार्टी कोड के प्रभाव को कम करें" ऑडिट से इसकी पुष्टि करें। फील्ड डेटा से मिलान करें, क्योंकि प्रयोगशाला परीक्षण वास्तविक लागत को कम करके आंकता है।

क्या सर्वर-साइड टैगिंग से कोर वेब वाइटल्स में सुधार होता है? यह अपने आप नहीं होता। सर्वर-साइड टैगिंग के लिए Google के दस्तावेज़ में डेटा नियंत्रण और रूटिंग का वर्णन है, न कि पेज की गति का, और ब्राउज़र अभी भी मापन कोड लोड करता है और इवेंट्स प्रसारित करता है। कोई भी सुधार उन वेंडर स्क्रिप्ट्स से आता है जिन्हें आप माइग्रेशन के हिस्से के रूप में पेज से हटा देते हैं।

तृतीय पक्ष सबसे अधिक कोर वेब वाइटल को नुकसान पहुंचाते हैं? आमतौर पर INP का उपयोग होता है, क्योंकि स्क्रिप्ट मुख्य थ्रेड को व्यस्त कर देती हैं और इनपुट विलंब और प्रोसेसिंग अवधि को बढ़ा देती हैं। हेड में रेंडर-ब्लॉकिंग टैग LCP को प्रभावित करते हैं, और देर से इंजेक्ट किए गए बैनर या विजेट CLS को प्रभावित करते हैं।

क्या मुझे थर्ड-पार्टी स्क्रिप्ट को स्वयं होस्ट करना चाहिए? कभी-कभी, लेकिन यह एक समझौता है। सेल्फ-होस्टेड कॉपी को वेंडर API में हुए बदलाव और सुरक्षा संबंधी सुधार तब तक नहीं मिलते जब तक आप उन्हें मैन्युअल रूप से अपडेट नहीं करते, जिसे web.dev राजस्व और सुरक्षा जोखिम के रूप में चिह्नित करता है।

मुझे किस लक्ष्य की ओर अग्रसर होना चाहिए? वास्तविक पेज लोड के 75वें प्रतिशतक पर: एलसीपी 2.5 सेकंड या उससे कम, आईएनपी 200 मिलीसेकंड या उससे कम, सीएलएस 0.1 या उससे कम।

अगर मेरे ट्रैफिक में ज्यादातर तुर्की भाषा के लोग हैं तो क्या मुझे Google की सहमति मोड की आवश्यकता होगी? Google की EEA सहमति-संकेत आवश्यकता तुर्की ट्रैफ़िक पर लागू नहीं होती है, लेकिन KVKK के कुकी नियम लागू होते हैं, इसलिए आपको अभी भी एक कार्यशील सहमति तंत्र की आवश्यकता है। इसमें बदलाव यह है कि आप उस सेगमेंट के लिए तेज़ बुनियादी कार्यान्वयन चुनने के लिए अधिक स्वतंत्र हैं।

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

अगर टैग का मालिक मना कर दे तो मुझे क्या करना चाहिए? स्कोर और बैंड भेजें, बहस नहीं। मानदंड इसलिए बनाए गए हैं ताकि बातचीत किसी संख्या और नाम वाली कार्रवाई पर केंद्रित रहे, न कि इस बात पर कि किसकी प्राथमिकता जीतती है।

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

सूत्रों का कहना है

• तृतीय पक्ष — 2025 वेब पंचांग, ​​HTTP आर्काइव
• वेब वाइटल्स — web.dev
• नेक्स्ट पेंट (INP) के साथ इंटरैक्शन — web.dev
• तृतीय-पक्ष जावास्क्रिप्ट लोड हो रहा है — web.dev
• कोर वेब वाइटल्स का व्यावसायिक प्रभाव — वेब.डेव केस स्टडी
• सर्वर-साइड टैगिंग का परिचय — गूगल टैग प्लेटफ़ॉर्म
• सर्वर कंटेनर को डेटा भेजें — गूगल टैग प्लेटफ़ॉर्म
• सहमति मोड की अवधारणाएँ — गूगल टैग प्लेटफ़ॉर्म
• EEA ट्रैफ़िक के लिए सहमति मोड में अपडेट — Google Ads सहायता
• केवीकेके चेरेज़ रेहबेरी अनुपालन रोडमैप — मोंडाक (प्राधिकरण की 61-पृष्ठीय मार्गदर्शिका का विश्लेषण; लेखन के समय kvkk.gov.tr ​​तक पहुंच संभव नहीं थी)