अगर आपने अपना कोड ऑप्टिमाइज़ किया है, लेकिन आपकी साइट अब भी बहुत धीरे लोड होती है, तो शायद तीसरे पक्ष की स्क्रिप्ट की गलती है.
तीसरे पक्ष की स्क्रिप्ट कई तरह की उपयोगी सुविधाएं देती हैं, जो वेब को ज़्यादा डाइनैमिक, इंटरैक्टिव, और आपस में कनेक्ट होने की सुविधा देती हैं. इनमें से कुछ बातें आपकी वेबसाइट के फ़ंक्शन या रेवेन्यू स्ट्रीम के लिए भी अहम हो सकती हैं. हालांकि, इनका इस्तेमाल करना जोखिम भरा है:
- इनकी वजह से, आपकी साइट की परफ़ॉर्मेंस कम हो सकती है.
- इनसे निजता या सुरक्षा से जुड़ी समस्याएं हो सकती हैं.
- इन चीज़ों के बारे में अनुमान नहीं लगाया जा सकता. साथ ही, इनके व्यवहार के बारे में अनचाहे नतीजे हो सकते हैं.
आम तौर पर, आपको यह पक्का करना चाहिए कि तीसरे पक्ष की स्क्रिप्ट का असर, आपकी साइट के ज़रूरी रेंडरिंग पाथ पर न पड़े. इस गाइड में, हम आपको तीसरे पक्ष की JavaScript लोड करने से जुड़ी समस्याओं का पता लगाने और उन्हें ठीक करने का तरीका बताएंगे. साथ ही, हम आपके उपयोगकर्ताओं को होने वाले खतरों को कम करने का तरीका बताएंगे.
तीसरे पक्ष की स्क्रिप्ट क्या होती हैं?
तीसरे पक्ष का JavaScript आम तौर पर उन स्क्रिप्ट का मतलब होता है जिन्हें किसी तीसरे पक्ष के वेंडर से, सीधे किसी भी साइट में एम्बेड किया जा सकता है. उदाहरण के लिए:
सोशल मीडिया पर शेयर करने की सुविधा के बटन (Facebook, X, LinkedIn, Mastodon)
वीडियो प्लेयर एम्बेड (YouTube, Vimeo)
विज्ञापन iframe
Analytics और मेट्रिक स्क्रिप्ट
प्रयोग के लिए, A/B टेस्टिंग स्क्रिप्ट
हेल्पर लाइब्रेरी, जैसे कि तारीख को फ़ॉर्मैट करना, ऐनिमेशन या फ़ंक्शनल लाइब्रेरी
<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/mo8thg5XGV0"
frameborder="0"
allow="autoplay; encrypted-media"
allowfullscreen
>
</iframe>
माफ़ करें, तीसरे पक्ष की स्क्रिप्ट को एम्बेड करने का मतलब है कि हम अक्सर उन स्क्रिप्ट पर भरोसा करते हैं जो तेज़ी से काम करती हैं और पेजों के लोड होने की स्पीड कम नहीं करती हैं. आम तौर पर, तीसरे पक्ष की स्क्रिप्ट की वजह से साइट के मालिक के कंट्रोल से बाहर रहने वाले संसाधनों की वजह से परफ़ॉर्मेंस धीमी हो जाती है. इनमें ये समस्याएं भी शामिल हैं:
एक से ज़्यादा सर्वर पर बहुत ज़्यादा नेटवर्क अनुरोध चलाना. किसी साइट को जितने ज़्यादा अनुरोध करने होंगे, उसे लोड होने में उतना ही ज़्यादा समय लगेगा.
बहुत ज़्यादा JavaScript भेजना, जो मुख्य थ्रेड को व्यस्त बनाए रखता है. बहुत ज़्यादा JavaScript से डीओएम बनाने में रुकावट आ सकती है इससे पेज रेंडरिंग में देरी होती है. CPU-इंटेसिव स्क्रिप्ट पार्स करने और चलाने से उपयोगकर्ता इंटरैक्शन में देरी हो सकती है और बैटरी तेज़ी से खर्च हो सकती है.
बड़ी, ऑप्टिमाइज़ नहीं की गई इमेज फ़ाइलें या वीडियो भेजने से डेटा खर्च हो सकता है और उपयोगकर्ताओं के पैसे खर्च हो सकते हैं.
अगर आपका पेज सावधानी से कोई स्क्रिप्ट लोड करता है, तो सुरक्षा से जुड़ी ऐसी समस्याएं हो सकती हैं जो एक बार में ही पूरी कार्रवाई (SPOF) के तौर पर की जा सकती हैं.
एचटीटीपी कैश मेमोरी कम होने की वजह से, ब्राउज़र को रिसॉर्स फ़ेच करने के लिए ज़्यादा नेटवर्क अनुरोध भेजने पड़ते हैं.
ज़रूरत के मुताबिक सर्वर कंप्रेशन न होने की वजह से, रिसॉर्स धीरे लोड होते हैं.
प्रोसेस पूरी होने तक, कॉन्टेंट दिखने पर रोक लगी रहेगी. यह स्थिति, एक साथ काम नहीं करने वाली A/B टेस्टिंग स्क्रिप्ट पर भी लागू हो सकती है.
ऐसे लेगसी एपीआई का इस्तेमाल करना जो उपयोगकर्ता के अनुभव को नुकसान पहुंचाने के बारे में जानते हैं. जैसे, document.write().
बहुत ज़्यादा डीओएम एलिमेंट या महंगे सीएसएस सिलेक्टर.
तीसरे पक्ष के एक से ज़्यादा एम्बेड शामिल करने से कई फ़्रेमवर्क और लाइब्रेरी को कई बार खींचा जा सकता है, जिससे संसाधनों की बर्बादी होती है और परफ़ॉर्मेंस की मौजूदा समस्याओं की समस्या बढ़ सकती है.
तीसरे पक्ष की स्क्रिप्ट अक्सर एम्बेड करने की तकनीकों का इस्तेमाल करती हैं, जो window.onload को ब्लॉक कर सकती हैं. ऐसा तब होता है, जब उनके सर्वर धीरे जवाब देते हैं. भले ही एम्बेड, async या डेफ़र का इस्तेमाल कर रहा हो.
तीसरे पक्ष की स्क्रिप्ट से जुड़ी समस्याओं को ठीक करने की आपकी क्षमता, आपकी साइट और तीसरे पक्ष के कोड को लोड करने के तरीके को कॉन्फ़िगर करने की आपकी क्षमता पर निर्भर करती है. अच्छी बात यह है कि तीसरे पक्ष के संसाधनों से जुड़ी समस्याओं को ढूंढने और उन्हें ठीक करने के लिए, कई समाधान और टूल मौजूद हैं.
किसी पेज पर तीसरे पक्ष की स्क्रिप्ट की पहचान कैसे की जाती है?
अपनी साइट पर तीसरे पक्ष की स्क्रिप्ट की पहचान करना और उनकी परफ़ॉर्मेंस पर पड़ने वाले असर का पता लगाना, उन्हें ऑप्टिमाइज़ करने का पहला कदम है. हमारा सुझाव है कि महंगी स्क्रिप्ट की पहचान करने के लिए, आप वेब स्पीड टेस्ट के मुफ़्त टूल इस्तेमाल करें. इनमें Chrome DevTools, PageSpeed Insights, और WebPageTest शामिल हैं. ये टूल, डाइग्नोस्टिक से जुड़ी बेहतर जानकारी दिखाते हैं. इससे आपको यह पता चल सकता है कि आपकी साइट, तीसरे पक्ष की कितनी स्क्रिप्ट इस्तेमाल करती है और किन स्क्रिप्ट को लागू करने में ज़्यादा समय लगता है.
WebPageTest का वॉटरफ़ॉल व्यू तीसरे पक्ष के स्क्रिप्ट के बहुत ज़्यादा इस्तेमाल के असर को हाइलाइट कर सकता है. टैग गॉन वाइल्ड की नीचे दी गई इमेज में, ट्रैकिंग और मार्केटिंग स्क्रिप्ट के उलट, किसी साइट का मुख्य कॉन्टेंट लोड करने के लिए ज़रूरी नेटवर्क अनुरोधों का एक उदाहरण दिया गया है.
WebPageTest के डोमेन ब्रेकडाउन की मदद से, यह देखा जा सकता है कि तीसरे पक्ष के ऑरिजिन से कितना कॉन्टेंट आता है. इसे इसमें कुल बाइट और अनुरोधों की संख्या, दोनों के हिसाब से बांटा जाता है:
मैं अपने पेज पर तीसरे पक्ष की स्क्रिप्ट के असर को कैसे मेज़र करूं?
जब आपको समस्या पैदा करने वाली स्क्रिप्ट दिखे, तो स्क्रिप्ट के काम करने का तरीका जानें और तय करें कि आपकी साइट को काम करने की ज़रूरत है या नहीं. अगर ज़रूरी हो, तो A/B टेस्ट करें, ताकि उपयोगकर्ता के जुड़ाव या परफ़ॉर्मेंस मेट्रिक पर पड़ने वाले असर की तुलना में, उसकी अनुमानित वैल्यू को संतुलित किया जा सके.
लाइटहाउस चालू करने के समय का ऑडिट
लाइटहाउस JavaScript बूट-अप टाइम ऑडिट उन स्क्रिप्ट को हाइलाइट करता है जिनमें महंगा स्क्रिप्ट पार्स, कंपाइल या आकलन में लगने वाला समय होता है. इससे, आपको तीसरे पक्ष की उन स्क्रिप्ट की पहचान करने में मदद मिल सकती है जो सीपीयू पर बहुत ज़्यादा काम करती हैं.
लाइटहाउस नेटवर्क पेलोड ऑडिट
Lighthouse नेटवर्क पेलोड ऑडिट नेटवर्क अनुरोधों की पहचान करता है. इनमें तीसरे पक्ष के नेटवर्क अनुरोध शामिल हैं, जो पेज लोड होने में लगने वाले समय को कम करते हैं. साथ ही, उपयोगकर्ताओं के लिए मोबाइल डेटा पर उम्मीद से ज़्यादा खर्च करना पड़ता है.
Chrome DevTools नेटवर्क के लिए अनुरोध को ब्लॉक करना
Chrome DevTools की मदद से यह देखा जा सकता है कि कोई स्क्रिप्ट, स्टाइल शीट या अन्य संसाधन उपलब्ध न होने पर, आपका पेज कैसे काम करता है. इसके लिए, नेटवर्क अनुरोध को ब्लॉक किया जाता है. इस सुविधा से, तीसरे पक्ष के अलग-अलग संसाधनों को आपके पेज से हटाने पर होने वाले असर का आकलन किया जा सकता है.
अनुरोध को ब्लॉक करने की सुविधा चालू करने के लिए, नेटवर्क पैनल में किसी भी अनुरोध पर राइट क्लिक करें और अनुरोध यूआरएल को ब्लॉक करें को चुनें. इसके बाद, एक 'ब्लॉक करने का अनुरोध' टैब DevTools में दिखेगा. इससे आपको यह मैनेज करने की सुविधा मिलती है कि कौनसे अनुरोध ब्लॉक किए गए हैं.
Chrome DevTools का परफ़ॉर्मेंस पैनल
Chrome DevTools में परफ़ॉर्मेंस पैनल की मदद से, आपके पेज की वेब परफ़ॉर्मेंस से जुड़ी समस्याओं की पहचान की जा सकती है.
- रिकॉर्ड करें पर क्लिक करें.
- अपना पेज लोड करें. DevTools एक वॉटरफ़ॉल डायग्राम दिखाता है. इससे पता चलता है कि आपकी साइट, लोड होने में लगने वाले समय को कैसे खर्च करती है.
- परफ़ॉर्मेंस पैनल में सबसे नीचे, बॉटम-अप पर जाएं.
- प्रॉडक्ट के हिसाब से ग्रुप बनाएं पर क्लिक करें और अपने पेज की तीसरे पक्ष की स्क्रिप्ट को लोड होने के समय के मुताबिक, क्रम से लगाएं.
पेज लोड की परफ़ॉर्मेंस का विश्लेषण करने के लिए, Chrome DevTools का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, रनटाइम की परफ़ॉर्मेंस का विश्लेषण करना लेख पढ़ें.
तीसरे पक्ष की स्क्रिप्ट के असर का आकलन करने के लिए, हम यहां सुझाया गया तरीका अपनाते हैं:
- नेटवर्क पैनल का इस्तेमाल करके मेज़र करें कि आपके पेज को लोड होने में कितना समय लगता है.
- असल हालातों का पालन करने के लिए, हमारा सुझाव है कि नेटवर्क थ्रॉटलिंग और सीपीयू थ्रॉटलिंग चालू करें. ऐसा हो सकता है कि आपके उपयोगकर्ताओं के पास तेज़ इंटरनेट और डेस्कटॉप हार्डवेयर न हों, जो लैब स्थितियों में महंगी स्क्रिप्ट के असर को कम करते हैं.
- आपको लगता है कि तीसरे पक्ष की स्क्रिप्ट से जुड़े उन यूआरएल या डोमेन को ब्लॉक किया जा सकता है जो आपके हिसाब से समस्या हैं. महंगी स्क्रिप्ट की पहचान करने के बारे में दिशा-निर्देशों के लिए, Chrome DevTools का परफ़ॉर्मेंस पैनल देखें.
- पेज को फिर से लोड करें और लोड होने में लगने वाले समय को फिर से मेज़र करें.
- ज़्यादा सटीक डेटा के लिए, हो सकता है कि आप लोड होने में लगने वाले समय को कम से कम तीन बार मेज़र करना चाहें. ऐसा इसलिए होता है, क्योंकि तीसरे पक्ष की कुछ स्क्रिप्ट, हर पेज लोड पर अलग-अलग संसाधन लाती हैं. इस काम में मदद करने के लिए, DevTools परफ़ॉर्मेंस पैनल में कई रिकॉर्डिंग काम करती हैं.
WebPageTest की मदद से, तीसरे पक्ष की स्क्रिप्ट के असर का आकलन करना
WebPageTest किसी अनुरोध को लोड होने से रोकने के लिए काम करता है, ताकि उसके असर को बेहतर सेटिंग > ब्लॉक करें में जाकर मापा जा सके. इस सुविधा का इस्तेमाल करके, ब्लॉक किए जाने वाले डोमेन की सूची तय करें, जैसे कि विज्ञापन डोमेन.
इस सुविधा का इस्तेमाल करने के लिए, हम आपको यह तरीका इस्तेमाल करने का सुझाव देते हैं:
- तीसरे पक्षों को ब्लॉक किए बिना पेज की जांच करें.
- अगर तीसरे पक्ष की कुछ कंपनियां ब्लॉक कर दी गई हैं, तो दोबारा जांच करें.
- अपनी जांच के इतिहास से मिले दो नतीजे चुनें.
- तुलना करें पर क्लिक करें.
नीचे दी गई इमेज में WebPageTest की फ़िल्मस्ट्रिप सुविधा दिखाई गई है. इसमें तीसरे पक्ष के चालू संसाधनों के साथ और उनके बिना पेजों के लोड क्रम की तुलना की गई है. हमारा सुझाव है कि आप तीसरे पक्ष के अलग-अलग ऑरिजिन के टेस्ट से पहले इसकी जांच करें. इससे आपको यह पता चलेगा कि आपके पेज की परफ़ॉर्मेंस पर किन डोमेन का सबसे ज़्यादा असर होता है.
WebPageCheck पर भी डोमेन को ब्लॉक करने के लिए, डीएनएस लेवल पर काम करने वाले दो निर्देशों का इस्तेमाल किया जा सकता है:
blockDomainsब्लॉक करने के लिए डोमेन की सूची लेता है.- blockDomainsExcept डोमेन की सूची लेता है और सूची में मौजूद नहीं चीज़ को ब्लॉक करता है.
WebPageTest में एक फ़ेलियर पॉइंट (SPOF) टैब भी है, जिसकी मदद से आप टाइम आउट को सिम्युलेट कर सकते हैं या संसाधन लोड करने में पूरी तरह विफल हो सकते हैं. डोमेन ब्लॉक करने के समय, SPOF धीरे-धीरे काम करता है. इसकी मदद से यह जांच की जा सकती है कि तीसरे पक्ष की सेवाओं पर बहुत ज़्यादा लोड होने या कुछ समय के लिए उपलब्ध न होने पर, आपके पेज कैसा परफ़ॉर्म करेंगे.
लंबे टास्क का इस्तेमाल करके, महंगे iframe का पता लगाएं
जब तीसरे पक्ष के iframe में मौजूद स्क्रिप्ट को चलने में ज़्यादा समय लगता है, तो वे मुख्य थ्रेड को ब्लॉक कर सकती हैं और दूसरे टास्क में देरी कर सकती हैं. लंबे समय तक चलने वाले इन टास्क की वजह से, इवेंट हैंडलर धीरे काम कर सकते हैं या फ़्रेम कम हो सकते हैं, जिससे उपयोगकर्ता अनुभव खराब हो सकता है.
रीयल यूज़र मॉनिटरिंग (आरयूएम) के लंबे टास्क का पता लगाने के लिए, JavaScript PerformanceObserver एपीआई का इस्तेमाल करें. इससे लॉन्गटास्क एंट्री को देखा जा सकता है. इन एंट्री में एक एट्रिब्यूशन प्रॉपर्टी होती है, जिसका इस्तेमाल यह तय करने के लिए किया जा सकता है कि यह टास्क किस फ़्रेम के कॉन्टेक्स्ट की वजह से हुआ है.
यह कोड, कंसोल में longtask की एंट्री लॉग करता है. इसमें "महंगे" iframe के लिए एक एंट्री भी शामिल है:
<script>
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Attribution entry including "containerSrc":"https://example.com"
console.log(JSON.stringify(entry.attribution));
}
});
observer.observe({entryTypes: ['longtask']});
</script>
<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>
लंबे टास्क पर नज़र रखने के बारे में ज़्यादा जानने के लिए, उपयोगकर्ता के बारे में बनाई गई परफ़ॉर्मेंस मेट्रिक देखें.
तीसरे पक्ष की स्क्रिप्ट, बेहतर तरीके से कैसे लोड की जाती है?
अगर तीसरे पक्ष की स्क्रिप्ट आपके पेज लोड को धीमा कर रही है, तो आपके पास परफ़ॉर्मेंस को बेहतर बनाने के कई विकल्प हैं:
- दस्तावेज़ पार्स करने की सुविधा को ब्लॉक करने से बचने के लिए,
asyncयाdeferएट्रिब्यूट का इस्तेमाल करके स्क्रिप्ट लोड करें. - अगर तीसरे पक्ष का सर्वर धीमा है, तो स्क्रिप्ट को खुद होस्ट करें.
- अगर स्क्रिप्ट आपकी साइट से साफ़ तौर पर कोई वैल्यू नहीं जोड़ती, तो उसे हटा दें.
- तीसरे पक्ष की स्क्रिप्ट होस्ट करने वाले डोमेन के लिए डीएनएस लुकअप करने के लिए,
<link rel=preconnect>या<link rel=dns-prefetch>जैसे संसाधन संकेत का इस्तेमाल करें.
async या defer का इस्तेमाल करें
JavaScript निष्पादन पार्सर-ब्लॉकिंग है. ब्राउज़र को कोई स्क्रिप्ट मिलने पर, उसे डीओएम कंस्ट्रक्शन को रोकना, स्क्रिप्ट को JavaScript इंजन में पास करना, और डीओएम कंस्ट्रक्शन जारी रखने से पहले स्क्रिप्ट को एक्ज़ीक्यूट करने की अनुमति देनी होगी.
async और defer एट्रिब्यूट की मदद से, इस तरीके में इस तरह बदलाव होता है:
asyncकी वजह से ब्राउज़र, स्क्रिप्ट को एसिंक्रोनस तरीके से डाउनलोड करता है, जबकि यह एचटीएमएल दस्तावेज़ को पार्स करना जारी रखता है. जब स्क्रिप्ट डाउनलोड हो जाती है, तो स्क्रिप्ट के चलने के दौरान पार्सिंग ब्लॉक हो जाती है.deferकी वजह से, ब्राउज़र उस समय एसिंक्रोनस तरीके से स्क्रिप्ट डाउनलोड करता है, जब यह एचटीएमएल दस्तावेज़ को पार्स करना जारी रखता है. इसके बाद, वह दस्तावेज़ के पार्स होने की प्रोसेस पूरी होने तक स्क्रिप्ट चलाने का इंतज़ार करता है.
तीसरे पक्ष की स्क्रिप्ट के लिए हमेशा async या defer का इस्तेमाल करें. ऐसा तब तक करें, जब तक अहम रेंडरिंग पाथ के लिए स्क्रिप्ट ज़रूरी न हो. अगर स्क्रिप्ट को लोड होने की प्रक्रिया में पहले चलाना ज़रूरी है, जैसे कि कुछ Analytics स्क्रिप्ट के लिए, तो async का इस्तेमाल करें. कम ज़रूरी संसाधनों के लिए defer का इस्तेमाल करें. जैसे, वे वीडियो जो उपयोगकर्ता को शुरुआत में पेज पर नीचे की तरफ़ दिखते हैं.
अगर पेज की परफ़ॉर्मेंस सबसे अहम है, तो हमारा सुझाव है कि आप पेज का ज़रूरी कॉन्टेंट लोड होने तक, एसिंक्रोनस स्क्रिप्ट जोड़ें. हम jQuery जैसी ज़रूरी लाइब्रेरी के लिए,
async का इस्तेमाल करने का सुझाव नहीं देते.
कुछ स्क्रिप्ट को async या defer के बिना लोड किया जाना चाहिए. खास तौर पर, वे स्क्रिप्ट जो आपकी साइट के अहम हिस्से हैं. इनमें यूज़र इंटरफ़ेस (यूआई) लाइब्रेरी या कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) फ़्रेमवर्क शामिल हैं. इनके बिना आपकी साइट काम नहीं कर सकती.
अगर दूसरी स्क्रिप्ट को एसिंक्रोनस रूप से लोड किया जाता है, तो वे काम नहीं करती हैं. इस्तेमाल की जा रही किसी भी स्क्रिप्ट के लिए दस्तावेज़ देखें. साथ ही, जिन स्क्रिप्ट को एसिंक्रोनस रूप से लोड नहीं किया जा सकता उन्हें बदलें. ध्यान रखें कि कुछ तीसरे पक्ष अपनी स्क्रिप्ट को सिंक करने का सुझाव देते हैं, भले ही वे एसिंक्रोनस तरीके से समान रूप से काम करें.
याद रखें कि async से सबकुछ ठीक नहीं किया जा सकता. अगर आपके पेज पर बहुत ज़्यादा स्क्रिप्ट मौजूद हैं, जैसे कि
विज्ञापन के मकसद से स्क्रिप्ट ट्रैक करना, तो उन्हें एसिंक्रोनस तरीके से लोड करना, पेज लोड होने की प्रोसेस को धीमा नहीं करेगा.
कनेक्शन को सेटअप करने में लगने वाला समय कम करने के लिए, संसाधन हिंट का इस्तेमाल करें
तीसरे पक्ष के ऑरिजिन से कनेक्शन बनाने में ज़्यादा समय लग सकता है, खास तौर पर धीमे नेटवर्क पर. ऐसा इसलिए होता है, क्योंकि नेटवर्क के अनुरोधों में कई जटिल कॉम्पोनेंट होते हैं, जिनमें डीएनएस लुकअप और रीडायरेक्ट शामिल हैं. तीसरे पक्ष की स्क्रिप्ट को होस्ट करने वाले डोमेन के लिए, पेज लोड होने की प्रोसेस की शुरुआत में ही संसाधन हिंट, का इस्तेमाल किया जा सकता है. इससे उन डोमेन के लिए, डीएनएस लुकअप का इस्तेमाल किया जा सकता है जो बाद में तेज़ी से प्रोसेस किए जा सकते हैं:
<link rel="dns-prefetch" href="http://example.com" />
जिस तीसरे पक्ष के डोमेन को एचटीटीपीएस से कनेक्ट किया जा रहा है, अगर वह एचटीटीपीएस का इस्तेमाल करता है, तो का भी इस्तेमाल किया जा सकता है. यह दोनों ही डीएनएस लुकअप करता है और टीसीपी की राउंड-ट्रिप को रिज़ॉल्व करता है और TLS नेगोशिएशन को हैंडल करता है. ये अन्य चरण बहुत धीमे हो सकते हैं, क्योंकि इनमें एसएसएल सर्टिफ़िकेट की पुष्टि करना शामिल है. इसलिए, पहले से कनेक्ट करने से लोड होने में लगने वाला समय काफ़ी कम हो सकता है.
<link rel="preconnect" href="https://cdn.example.com" />
iframe के साथ "सैंडबॉक्स" स्क्रिप्ट
अगर किसी तीसरे पक्ष की स्क्रिप्ट को सीधे iframe में लोड किया जाता है, तो मुख्य पेज का
कार्रवाई ब्लॉक नहीं होता. एएमपी, JavaScript को ज़रूरी पाथ से बाहर रखने के लिए, इस तरीके का इस्तेमाल करता है. ध्यान दें कि इस तरीके से अब भी onload इवेंट ब्लॉक होता है. इसलिए, onload में अहम सुविधाएं अटैच न करें.
Chrome में अनुमतियों से जुड़ी नीति (पहले इसे सुविधा के लिए नीति के नाम से जाना जाता था) का भी इस्तेमाल किया जा सकता है. यह नीतियों का एक ऐसा सेट है जो डेवलपर को ब्राउज़र की कुछ सुविधाओं के ऐक्सेस को चुनिंदा तरीके से बंद करने की अनुमति देता है. इसका इस्तेमाल करके, तीसरे पक्ष के कॉन्टेंट को किसी साइट पर गलत व्यवहार दिखाने से रोका जा सकता है.
तीसरे पक्ष की स्क्रिप्ट को खुद होस्ट करें
अगर आपको इस बात पर ज़्यादा कंट्रोल चाहिए कि कोई ज़रूरी स्क्रिप्ट कैसे लोड होती है, जैसे कि डीएनएस का समय कम करना या एचटीटीपी कैश में सेव होने वाले हेडर को बेहतर बनाना, तो इसे खुद होस्ट किया जा सकता है.
हालांकि, सेल्फ़-होस्टिंग में कुछ समस्याएं आती हैं. खास तौर पर, जब स्क्रिप्ट अपडेट करने की बात आती है. खुद होस्ट की जाने वाली स्क्रिप्ट को एपीआई में होने वाले बदलावों या सुरक्षा से जुड़े सुधारों के लिए, अपने-आप अपडेट नहीं मिलेंगे. इन अपडेट की वजह से रेवेन्यू में कमी या सुरक्षा से जुड़ी समस्याएं हो सकती हैं. ऐसा तब तक होगा, जब तक स्क्रिप्ट को मैन्युअल तरीके से अपडेट न किया जाए.
विकल्प के तौर पर, आपके पास सर्विस वर्कर का इस्तेमाल करके तीसरे पक्ष की स्क्रिप्ट को कैश मेमोरी में सेव करने का विकल्प होता है. इससे यह कंट्रोल किया जा सकता है कि नेटवर्क से स्क्रिप्ट कितनी बार फ़ेच की जाएं. लोड करने की रणनीतियां बनाने के लिए, सर्विस वर्कर का भी इस्तेमाल किया जा सकता है. ये रणनीतियां, तीसरे पक्ष के ग़ैर-ज़रूरी अनुरोधों को तब तक थ्रॉटल करती हैं, जब तक कि आपका पेज किसी अहम उपयोगकर्ता पॉइंट पर नहीं पहुंच जाता.
A/B उपयोगकर्ताओं के छोटे सैंपल टेस्ट करें
A/B टेस्टिंग (या स्प्लिट-टेस्टिंग) किसी पेज के दो वर्शन के साथ प्रयोग करने की एक तकनीक है. इससे उपयोगकर्ता अनुभव और व्यवहार का विश्लेषण किया जा सकता है. इससे आपकी वेबसाइट के ट्रैफ़िक के अलग-अलग सैंपल के लिए पेज का वर्शन उपलब्ध हो जाता है. साथ ही, आंकड़ों से पता चलता है कि कौनसा वर्शन बेहतर कन्वर्ज़न रेट देता है.
हालांकि, डिज़ाइन के हिसाब से A/B टेस्टिंग की रेंडरिंग में देरी होती है. इसकी मदद से, यह तय किया जाता है कि किस प्रयोग के चालू होने की ज़रूरत है. JavaScript का इस्तेमाल अक्सर यह पता लगाने के लिए किया जाता है कि आपका कोई उपयोगकर्ता, A/B टेस्ट एक्सपेरिमेंट से जुड़ा है या नहीं. इसके बाद, सही वैरिएंट को चालू किया जाता है. इस प्रोसेस से उन लोगों का भी अनुभव खराब हो सकता है जो प्रयोग का हिस्सा नहीं हैं.
पेज रेंडरिंग की रफ़्तार बढ़ाने के लिए, हमारा सुझाव है कि आप A/B टेस्टिंग स्क्रिप्ट को अपने उपयोगकर्ता आधार के छोटे सैंपल पर भेजें. साथ ही, वह कोड चलाएं जो यह तय करता हो कि पेज का कौनसा वर्शन सर्वरसाइड दिखाना है.
लेज़ी लोड तीसरे पक्ष के संसाधन
एम्बेड किए गए तीसरे पक्ष के संसाधन, जैसे कि विज्ञापन और वीडियो, खराब तरीके से बनाए जाने पर पेज की स्पीड धीमी करने में काफ़ी अहम भूमिका निभा सकते हैं. लेज़ी लोडिंग का इस्तेमाल, एम्बेड किए गए रिसॉर्स को ज़रूरत पड़ने पर ही लोड करने के लिए किया जा सकता है. उदाहरण के लिए, पेज के फ़ुटर में विज्ञापनों को तब तक दिखाने के लिए इंतज़ार करना, जब तक कि उपयोगकर्ता उन्हें देखने के लिए काफ़ी स्क्रोल न करे. मुख्य पेज का कॉन्टेंट लोड होने के बाद भी तीसरे पक्ष के कॉन्टेंट को लेज़ी लोड किया जा सकता है, लेकिन इससे पहले कि उपयोगकर्ता पेज से इंटरैक्ट करे.
लेज़ी लोडिंग रिसॉर्स के समय सावधानी बरतें. ऐसा इसलिए, क्योंकि इसमें अक्सर ऐसा JavaScript कोड शामिल होता है जिस पर नेटवर्क कनेक्शन के अस्थिर होने की वजह से असर पड़ सकता है.
DoubleClick ने अपने आधिकारिक दस्तावेज़ों में विज्ञापनों को लेज़ी लोड करने के तरीके के बारे में दिशा-निर्देश दिए हैं.
इंटरसेक्शन ऑब्ज़र्वर की मदद से, लेज़ी लोडिंग की बेहतर सुविधा
अब तक, लेज़ी लोडिंग के लिए व्यूपोर्ट में कोई एलिमेंट दिख रहा है या नहीं, इसका पता लगाने के तरीकों में गड़बड़ी की संभावना होती है. इससे ब्राउज़र अक्सर धीमा हो जाता है. काम न करने वाले ये तरीके अक्सर scroll या resize इवेंट का इस्तेमाल करते हैं. इसके बाद, getBoundingClientRect() जैसे DOM एपीआई का इस्तेमाल करके, यह कैलकुलेट किया जाता है कि एलिमेंट, व्यूपोर्ट से कहां जुड़े हैं.
IntersectionObserver एक ब्राउज़र एपीआई है. इसकी मदद से, पेज के मालिक यह पता कर पाते हैं कि कोई एलिमेंट कब ब्राउज़र के व्यूपोर्ट में आता है या वहां से बाहर निकलता है. LazySizes में इंटरसेक्शन ऑब्ज़र्वर के लिए ज़रूरी नहीं है.
लेज़ी लोड के आंकड़े
अगर Analytics स्क्रिप्ट को बहुत देर तक लोड होने से रोका जाता है, तो हो सकता है कि आपको आंकड़ों का अहम डेटा न दिखे. अच्छी बात यह है कि शुरुआत में पेज-लोड डेटा को बनाए रखते हुए, एआई को देरी से शुरू करने के लिए रणनीतियां उपलब्ध हैं.
फ़िल वॉल्टन की ब्लॉग पोस्ट में, मेरी हर साइट पर इस्तेमाल किया जाने वाला Google Analytics सेटअप में, Google Analytics के लिए ऐसी ही एक रणनीति के बारे में बताया गया है.
तीसरे पक्ष की स्क्रिप्ट को सुरक्षित तरीके से लोड करें
इस सेक्शन में, तीसरे पक्ष की स्क्रिप्ट को ज़्यादा से ज़्यादा सुरक्षित तरीके से लोड करने के बारे में दिशा-निर्देश दिए गए हैं.
document.write() से बचें
तीसरे पक्ष की स्क्रिप्ट, खास तौर पर पुरानी सेवाओं के लिए, कभी-कभी स्क्रिप्ट को इंजेक्ट और लोड करने के लिए document.write() का इस्तेमाल करती हैं. यह समस्या इसलिए है, क्योंकि document.write() ठीक से काम नहीं करता है. साथ ही, इसके काम न करने पर, इसे डीबग करना मुश्किल होता है.
इसका इस्तेमाल न करने से, document.write() से जुड़ी समस्याओं को हल करने में मदद मिलती है. Chrome 53 और उसके बाद के वर्शन में,
Chrome DevTools, कंसोल पर चेतावनियां लॉग करता है. इससे, document.write() के इस्तेमाल में गड़बड़ी होती है:
document.write() के इस्तेमाल को फ़्लैग करता है.अगर आपको यह गड़बड़ी मिलती है, तो अपने ब्राउज़र पर भेजे गए एचटीटीपी हेडर देखकर, अपनी साइट के document.write() के इस्तेमाल की जांच की जा सकती है.
Lighthouse
अब भी document.write() का इस्तेमाल करके
किसी तीसरे पक्ष की स्क्रिप्ट को हाइलाइट किया जा सकता है.
document.write() का इस्तेमाल करती हैं.Tag Manager का इस्तेमाल ध्यान से करना
टैग एक कोड स्निपेट होता है, जिसकी मदद से डिजिटल मार्केटिंग टीमें डेटा इकट्ठा कर सकती हैं, कुकी सेट कर सकती हैं या सोशल मीडिया विजेट जैसे तीसरे पक्ष के कॉन्टेंट को किसी साइट में इंटिग्रेट कर सकती हैं. ये टैग आपके पेज में नेटवर्क अनुरोध, JavaScript की डिपेंडेंसी, और दूसरे संसाधन जोड़ते हैं. इनसे पेज की परफ़ॉर्मेंस पर असर पड़ सकता है. ज़्यादा टैग जोड़ने की वजह से, आपके उपयोगकर्ताओं पर पड़ने वाले असर को कम करना और भी मुश्किल हो जाता है.
पेज को तेज़ी से लोड करने के लिए, हम Google Tag Manager (GTM) जैसे किसी टैग मैनेजर का इस्तेमाल करने का सुझाव देते हैं. GTM की मदद से, टैग को एसिंक्रोनस तरीके से डिप्लॉय किया जा सकता है, ताकि वे एक-दूसरे को लोड होने से न रोकें. इसके अलावा, ब्राउज़र को टैग चलाने के लिए, नेटवर्क कॉल की संख्या कम हो जाती है और डेटा लेयर यूज़र इंटरफ़ेस (यूआई) में टैग का डेटा इकट्ठा होता है.
टैग मैनेजर का इस्तेमाल करने के जोखिम
हालांकि, टैग मैनेजर को पेज लोड होने की प्रक्रिया को आसान बनाने के लिए डिज़ाइन किया गया है, फिर भी उनका ध्यान से इस्तेमाल करने से यह प्रोसेस धीमी हो सकती है. इसके लिए नीचे दिए गए तरीके अपनाए जा सकते हैं:
- आपके टैग मैनेजर में बहुत ज़्यादा टैग और ऑटो-इवेंट लिसनर की वजह से, ब्राउज़र को सामान्य से ज़्यादा नेटवर्क अनुरोध करने पड़ते हैं. इससे आपके कोड की इवेंट का तुरंत जवाब देने की क्षमता कम हो जाती है.
- जिन लोगों के पास क्रेडेंशियल और ऐक्सेस है वे आपके टैग मैनेजर में JavaScript जोड़ सकते हैं. इससे न सिर्फ़ आपके पेज को लोड करने के लिए ज़रूरी महंगे नेटवर्क अनुरोधों की संख्या बढ़ सकती है, बल्कि गैर-ज़रूरी स्क्रिप्ट से सुरक्षा से जुड़े जोखिम और परफ़ॉर्मेंस की अन्य समस्याएं भी पैदा हो सकती हैं. इन जोखिमों को कम करने के लिए, हमारा सुझाव है कि अपने टैग मैनेजर का ऐक्सेस सीमित रखें.
ग्लोबल स्कोप को नुकसान पहुंचाने वाली स्क्रिप्ट से बचें
तीसरे पक्ष की स्क्रिप्ट हर तरह के तरीकों से काम कर सकती हैं, जिनकी वजह से आपके पेज पर अचानक कोई गड़बड़ी हो जाती है:
- JavaScript डिपेंडेंसी लोड करने वाली स्क्रिप्ट, आपके कोड के साथ गलत तरीके से इंटरैक्ट करने वाले कोड की मदद से ग्लोबल स्कोप को प्रदूषण फैलाने में मदद कर सकती हैं.
- अनचाहे अपडेट की वजह से, नुकसान पहुंचा सकने वाले बदलाव हो सकते हैं.
- तृतीय-पक्ष कोड को आपके पेज के परीक्षण और परिनियोजन के बीच अलग-अलग तरीके से व्यवहार करने के लिए ट्रांज़िट के दौरान संशोधित किया जा सकता है.
हमारा सुझाव है कि आप तीसरे पक्ष की जो स्क्रिप्ट लोड करते हैं उनका नियमित रूप से ऑडिट करें, ताकि बुरे मकसद से काम करने वाले लोगों या ग्रुप का पता लगाया जा सके. अपने पेज को सुरक्षित रखने के लिए, खुद से जांच करने, सबसोर्स इंटिग्रिटी, और तीसरे पक्ष के कोड को सुरक्षित तरीके से भेजने की सुविधा भी लागू की जा सकती है.
जोखिम कम करने की रणनीतियां
आपकी साइट की परफ़ॉर्मेंस और सुरक्षा पर तीसरे पक्ष की स्क्रिप्ट के असर को कम करने के लिए, यहां बड़े पैमाने पर इस्तेमाल की जाने वाली कुछ रणनीतियां दी गई हैं:
एचटीटीपीएस: एचटीटीपीएस का इस्तेमाल करने वाली साइटें, एचटीटीपी का इस्तेमाल करने वाले तीसरे पक्षों पर निर्भर नहीं होनी चाहिए. ज़्यादा जानकारी के लिए, मिक्स्ड कॉन्टेंट देखें.
सैंडबॉक्सिंग: स्क्रिप्ट में उपलब्ध कार्रवाइयों को सीमित करने के लिए, iframe में
sandboxएट्रिब्यूट के साथ तीसरे पक्ष की स्क्रिप्ट चलाएं.कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी): सर्वर से रिस्पॉन्स में एचटीटीपी हेडर का इस्तेमाल करके, अपनी साइट के लिए भरोसेमंद स्क्रिप्ट के व्यवहार तय किए जा सकते हैं. साथ ही, क्रॉस साइट स्क्रिप्टिंग (एक्सएसएस) जैसे कुछ हमलों के असर का पता लगाकर, उन्हें कम किया जा सकता है.
इस उदाहरण में बताया गया है कि किसी पेज के लिए स्वीकार किए गए JavaScript सोर्स की जानकारी देने के लिए, सीएसपी के script-src डायरेक्टिव का इस्तेमाल कैसे करें:
// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed
<script src="https://not-example.com/js/library.js"></script>
इसके बारे में और पढ़ें
तीसरे पक्ष की JavaScript को ऑप्टिमाइज़ करने के बारे में ज़्यादा जानने के लिए, हमारा सुझाव है कि आप ये लेख पढ़ें:
- परफ़ॉर्मेंस और लचीलापन: तनाव को दूर करने वाले तीसरे पक्ष
- JavaScript की मदद से इंटरैक्टिविटी जोड़ना
- तीसरे पक्ष की स्क्रिप्ट से होने वाले संभावित खतरे
- तीसरे पक्ष की स्क्रिप्ट, वेब पर किस तरह बेहतर परफ़ॉर्म कर सकती हैं
- यह ज़रूरी क्यों है - CSS विज़ार्ड
- JavaScript सप्लाई चेन में विरोधाभास: SRI, सीएसपी, और तीसरे पक्ष की लाइब्रेरी में भरोसा
- तीसरे पक्ष की सीएसएस सुरक्षित नहीं है
इन समीक्षाओं के लिए, केंजी बहेक्स, जेरेमी वैगनर, पैट मीनन, फ़िलिप वॉल्टन, जेफ़ पॉसनिक, और चेनी साई को धन्यवाद.