तीसरे पक्ष की JavaScript लोड करना

Addy Osmani

Arthur Evans

अगर आपने अपने कोड को ऑप्टिमाइज़ कर लिया है, लेकिन आपकी साइट अब भी बहुत धीमी लोड हो रही है, तो हो सकता है कि तीसरे पक्ष की स्क्रिप्ट में कोई गड़बड़ी हो.

तीसरे पक्ष की स्क्रिप्ट, कई तरह की काम की सुविधाएं उपलब्ध कराती हैं. इनसे वेब को ज़्यादा डाइनैमिक, इंटरैक्टिव, और इंटरकनेक्टेड बनाया जा सकता है. इनमें से कुछ आपकी वेबसाइट के काम करने के तरीके या रेवेन्यू स्ट्रीम के लिए ज़रूरी हो सकते हैं. हालांकि, इनका इस्तेमाल करना जोखिम भरा है:

• इनसे आपकी साइट की परफ़ॉर्मेंस धीमी हो सकती है.
• इनसे निजता या सुरक्षा से जुड़ी समस्याएं हो सकती हैं.
• इनके बारे में पहले से कुछ नहीं कहा जा सकता और इनके व्यवहार के अनचाहे नतीजे हो सकते हैं.

आम तौर पर, आपको यह पक्का करना चाहिए कि तीसरे पक्ष की स्क्रिप्ट, आपकी साइट के क्रिटिकल रेंडरिंग पाथ पर असर न डालें. इस गाइड में, हम तीसरे पक्ष की JavaScript को लोड करने से जुड़ी समस्याओं को ढूंढने और उन्हें ठीक करने का तरीका बताएंगे. साथ ही, उपयोगकर्ताओं के लिए जोखिमों को कम करने का तरीका भी बताएंगे.

तीसरे पक्ष की स्क्रिप्ट क्या होती हैं?

तीसरे पक्ष की JavaScript का मतलब अक्सर ऐसी स्क्रिप्ट से होता है जिन्हें तीसरे पक्ष के वेंडर से सीधे तौर पर किसी भी साइट में एम्बेड किया जा सकता है. उदाहरण के लिए:

• सोशल मीडिया पर शेयर करने की सुविधा वाले बटन (Facebook, X, LinkedIn, Mastodon)

• एम्बेड किए गए वीडियो प्लेयर (YouTube, Vimeo)

• विज्ञापन वाले iframe

• Analytics और मेट्रिक स्क्रिप्ट

• एक्सपेरिमेंट के लिए, A/B टेस्टिंग स्क्रिप्ट

• हेल्पर लाइब्रेरी, जैसे कि तारीख को फ़ॉर्मैट करने वाली लाइब्रेरी, ऐनिमेशन लाइब्रेरी या फ़ंक्शनल लाइब्रेरी

यहां एम्बेड किए गए YouTube वीडियो का उदाहरण दिया गया है. इसे इस कोड का इस्तेमाल करके, किसी पेज में जोड़ा जा सकता है.

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

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

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

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

• बड़ी, ऑप्टिमाइज़ नहीं की गई इमेज फ़ाइलें या वीडियो भेजने से, डेटा खर्च हो सकता है और उपयोगकर्ताओं को पैसे चुकाने पड़ सकते हैं.

• सुरक्षा से जुड़ी ऐसी समस्याएं जो खराब होने पर पूरे सिस्टम को बंद करने वाले पॉइंट (एसपीओएफ़) के तौर पर काम कर सकती हैं. ऐसा तब होता है, जब आपका पेज बिना किसी सावधानी के स्क्रिप्ट लोड करता है.

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

• सर्वर कंप्रेस करने की सुविधा न होने की वजह से, रिसॉर्स धीरे-धीरे लोड होते हैं.

• प्रोसेस पूरी होने तक, कॉन्टेंट को दिखने से रोकना. यह बात, एसिंक्रोनस A/B टेस्टिंग स्क्रिप्ट के लिए भी सही हो सकती है.

• ऐसे लेगसी एपीआई का इस्तेमाल करना जिनसे उपयोगकर्ता अनुभव खराब होता है. जैसे, document.write().

• बहुत ज़्यादा डीओएम एलिमेंट या ज़्यादा समय लेने वाले सीएसएस सिलेक्टर.

• तीसरे पक्ष के कई एम्बेड शामिल करने से, कई फ़्रेमवर्क और लाइब्रेरी को कई बार लोड किया जा सकता है. इससे रिसॉर्स बर्बाद होते हैं और परफ़ॉर्मेंस की मौजूदा समस्याएं और खराब हो जाती हैं.

• तीसरे पक्ष की स्क्रिप्ट अक्सर एम्बेड करने की ऐसी तकनीकों का इस्तेमाल करती हैं जो window.onload को ब्लॉक कर सकती हैं. ऐसा तब होता है, जब उनके सर्वर धीरे-धीरे जवाब देते हैं. भले ही, एम्बेड करने के लिए एसिंक या डिफ़र का इस्तेमाल किया जा रहा हो.

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

किसी पेज पर तीसरे पक्ष की स्क्रिप्ट की पहचान कैसे की जाती है?

अपनी साइट पर तीसरे पक्ष की स्क्रिप्ट की पहचान करना और उनकी परफ़ॉर्मेंस पर पड़ने वाले असर का पता लगाना, उन्हें ऑप्टिमाइज़ करने की दिशा में पहला कदम है. हमारा सुझाव है कि आप Chrome DevTools, PageSpeed Insights, और WebPageTest जैसे मुफ़्त वेब स्पीड टेस्ट टूल का इस्तेमाल करें. इससे आपको ज़्यादा सीपीयू इस्तेमाल करने वाली स्क्रिप्ट की पहचान करने में मदद मिलेगी. इन टूल से, डाइग्नोस्टिक्स की ज़्यादा जानकारी मिलती है. इससे आपको पता चल सकता है कि आपकी साइट पर तीसरे पक्ष की कितनी स्क्रिप्ट इस्तेमाल की जाती हैं और किन स्क्रिप्ट को लागू होने में सबसे ज़्यादा समय लगता है.

WebPageTest का वॉटरफ़ॉल व्यू, तीसरे पक्ष की भारी-भरकम स्क्रिप्ट के इस्तेमाल से पड़ने वाले असर को हाइलाइट कर सकता है. Tags Gone Wild की इस इमेज में, किसी साइट के मुख्य कॉन्टेंट को लोड करने के लिए ज़रूरी नेटवर्क अनुरोधों का डायग्राम दिखाया गया है. इसमें ट्रैकिंग और मार्केटिंग स्क्रिप्ट के लिए ज़रूरी नेटवर्क अनुरोधों का डायग्राम नहीं दिखाया गया है.

इस पेज पर मौजूद स्क्रिप्ट को लोड होने में, पेज के लोड होने से ज़्यादा समय लगता है.

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

डोमेन ब्रेकडाउन चार्ट से पता चलता है कि पेज का कितना कॉन्टेंट, तीसरे पक्ष से लिया गया है.

मैं अपने पेज पर तीसरे पक्ष की स्क्रिप्ट के असर को कैसे मेज़र करूं?

अगर आपको कोई ऐसी स्क्रिप्ट दिखती है जिसकी वजह से समस्याएं आ रही हैं, तो पता लगाएं कि वह स्क्रिप्ट क्या करती है. साथ ही, यह तय करें कि आपकी साइट को काम करने के लिए उसकी ज़रूरत है या नहीं. अगर ज़रूरी हो, तो A/B टेस्ट चलाएं. इससे आपको यह समझने में मदद मिलेगी कि उपयोगकर्ताओं को आपके ऐप्लिकेशन की वैल्यू कितनी लगती है. साथ ही, यह भी पता चलेगा कि उपयोगकर्ता के जुड़ाव या परफ़ॉर्मेंस मेट्रिक पर इसका क्या असर पड़ता है.

Lighthouse बूट-अप टाइम ऑडिट

Lighthouse का JavaScript बूट-अप टाइम ऑडिट, उन स्क्रिप्ट को हाइलाइट करता है जिन्हें पार्स करने, कंपाइल करने या आकलन करने में ज़्यादा समय लगता है. इससे आपको तीसरे पक्ष की ऐसी स्क्रिप्ट की पहचान करने में मदद मिल सकती है जो सीपीयू का ज़्यादा इस्तेमाल करती हैं.

बूट-अप टाइम ऑडिट से पता चलता है कि किन स्क्रिप्ट को लोड होने में सबसे ज़्यादा समय लगता है.

Lighthouse नेटवर्क पेलोड ऑडिट

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

नेटवर्क पेलोड ऑडिट से पता चलता है कि नेटवर्क के किन अनुरोधों में सबसे ज़्यादा समय लगता है और किन अनुरोधों से सबसे ज़्यादा डेटा फ़ेच होता है.

Chrome DevTools में नेटवर्क के अनुरोध को ब्लॉक करने वाला टूल

Chrome DevTools की मदद से यह देखा जा सकता है कि जब कोई स्क्रिप्ट, स्टाइल शीट या अन्य संसाधन उपलब्ध न हो, तो आपका पेज कैसा दिखता है. ऐसा नेटवर्क अनुरोध को ब्लॉक करने की सुविधा की मदद से किया जाता है. यह सुविधा, आपके पेज से तीसरे पक्ष के अलग-अलग संसाधनों को हटाने के असर को मेज़र करने में मदद कर सकती है.

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

नेटवर्क के अलग-अलग अनुरोधों को ब्लॉक करें, ताकि यह देखा जा सके कि उनके बिना आपका पेज कैसा परफ़ॉर्म करता है.

Chrome DevTools का परफ़ॉर्मेंस पैनल

Chrome DevTools में मौजूद परफ़ॉर्मेंस पैनल की मदद से, आपके पेज की वेब परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाया जा सकता है.

1. रिकॉर्ड करें पर क्लिक करें.
2. अपना पेज लोड करें. DevTools, वॉटरफ़ॉल डायग्राम दिखाता है. इससे पता चलता है कि आपकी साइट लोड होने में कितना समय लेती है.
3. परफ़ॉर्मेंस पैनल में सबसे नीचे मौजूद, बॉटम-अप पर जाएं.
4. प्रॉडक्ट के हिसाब से ग्रुप बनाएं पर क्लिक करें. इसके बाद, अपने पेज की तीसरे पक्ष की स्क्रिप्ट को लोड होने में लगने वाले समय के हिसाब से क्रम में लगाएं.

तीसरे पक्ष की स्क्रिप्ट को प्रॉडक्ट के हिसाब से क्रम में लगाया गया है. इसमें सबसे ज़्यादा लोड होने वाले प्रॉडक्ट को सबसे पहले रखा गया है.

पेज लोड होने की परफ़ॉर्मेंस का विश्लेषण करने के लिए, Chrome DevTools का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, रनटाइम परफ़ॉर्मेंस का विश्लेषण करना शुरू करें लेख पढ़ें.

तीसरे पक्ष की स्क्रिप्ट के असर को मेज़र करने के लिए, हमारा सुझाया गया वर्कफ़्लो यहां दिया गया है:

1. नेटवर्क पैनल का इस्तेमाल करके, यह मेज़र करें कि आपके पेज को लोड होने में कितना समय लगता है.
   • असल दुनिया की स्थितियों को समझने के लिए, हमारा सुझाव है कि आप नेटवर्क थ्रॉटलिंग और सीपीयू थ्रॉटलिंग चालू करें. ऐसा हो सकता है कि आपके उपयोगकर्ताओं के पास तेज़ इंटरनेट कनेक्शन और डेस्कटॉप हार्डवेयर न हों. ये दोनों चीज़ें, लैब की स्थितियों में महंगी स्क्रिप्ट के असर को कम करती हैं.
2. तीसरे पक्ष की स्क्रिप्ट के लिए ज़िम्मेदार उन यूआरएल या डोमेन को ब्लॉक करें जो आपको लगता है कि समस्या पैदा कर रहे हैं. ज़्यादा समय लेने वाली स्क्रिप्ट की पहचान करने के बारे में जानने के लिए, Chrome DevTools का परफ़ॉर्मेंस पैनल देखें.
3. पेज को फिर से लोड करें और लोड होने में लगने वाले समय को फिर से मेज़र करें.
   • ज़्यादा सटीक डेटा पाने के लिए, आपको पेज लोड होने में लगने वाले समय को कम से कम तीन बार मेज़र करना चाहिए. इसकी वजह यह है कि तीसरे पक्ष की कुछ स्क्रिप्ट, हर पेज लोड होने पर अलग-अलग रिसॉर्स फ़ेच करती हैं. इस काम में मदद करने के लिए, DevTools के परफ़ॉर्मेंस पैनल में कई रिकॉर्डिंग सेव की जा सकती हैं.

WebPageTest की मदद से, तीसरे पक्ष की स्क्रिप्ट के असर को मेज़र करना

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

इस पैनल में उन डोमेन की सूची बनाएं जिन्हें आपको ब्लॉक करना है.

इस सुविधा का इस्तेमाल करने के लिए, हम इस वर्कफ़्लो का सुझाव देते हैं:

1. तीसरे पक्ष को ब्लॉक किए बिना किसी पेज की जांच करना.
2. तीसरे पक्ष की कुछ कुकी को ब्लॉक करके, टेस्ट को दोहराएं.
3. जांच के इतिहास से दो नतीजे चुनें.
4. तुलना करें पर क्लिक करें.

तुलना करने के लिए, लोड टेस्ट के नतीजे चुनें.

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

तीसरे पक्ष के संसाधनों को ब्लॉक करने का असर, तीसरे पक्ष के टैग के असर को मापने के लिए WebPageTest का इस्तेमाल करना एंडी डेविस के मुताबिक.

WebPageTest, डोमेन को ब्लॉक करने के लिए डीएनएस लेवल पर काम करने वाले दो कमांड भी इस्तेमाल करता है:

• blockDomains ब्लॉक किए जाने वाले डोमेन की सूची लेता है.
• blockDomainsExcept डोमेन की सूची लेता है और सूची में शामिल नहीं की गई हर चीज़ को ब्लॉक करता है.

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

एसपीओएफ़ टेस्टिंग की सुविधा का इस्तेमाल करके, यह सिम्युलेट करें कि तय किए गए डोमेन के फ़ेल होने पर क्या होगा.

ज़्यादा समय लेने वाले टास्क का इस्तेमाल करके, ज़्यादा रिसॉर्स इस्तेमाल करने वाले iframe का पता लगाना

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

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

यहां दिया गया कोड, कंसोल में 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 को चलाने से पार्सर ब्लॉक हो रहा है. जब ब्राउज़र को कोई स्क्रिप्ट मिलती है, तो उसे DOM बनाने की प्रोसेस को रोकना पड़ता है. इसके बाद, स्क्रिप्ट को JavaScript इंजन को पास करना पड़ता है. साथ ही, DOM बनाने की प्रोसेस को जारी रखने से पहले, स्क्रिप्ट को एक्ज़ीक्यूट करने की अनुमति देनी पड़ती है.

async और defer एट्रिब्यूट, इस तरीके को इस तरह बदलते हैं:

• async की वजह से, ब्राउज़र स्क्रिप्ट को एसिंक्रोनस तरीके से डाउनलोड करता है. साथ ही, एचटीएमएल दस्तावेज़ को पार्स करना जारी रखता है. स्क्रिप्ट डाउनलोड होने के बाद, स्क्रिप्ट के चलने के दौरान पार्सिंग ब्लॉक हो जाती है.

• defer की वजह से, ब्राउज़र स्क्रिप्ट को एसिंक्रोनस तरीके से डाउनलोड करता है. इस दौरान, वह एचटीएमएल दस्तावेज़ को पार्स करना जारी रखता है. इसके बाद, दस्तावेज़ को पार्स करने की प्रोसेस पूरी होने तक, स्क्रिप्ट को चलाने के लिए इंतज़ार करता है.

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

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

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

कुछ स्क्रिप्ट को async या defer के बिना लोड करना ज़रूरी होता है. खास तौर पर, वे स्क्रिप्ट जो आपकी साइट के लिए ज़रूरी हैं. इनमें यूज़र इंटरफ़ेस (यूआई) लाइब्रेरी या कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) फ़्रेमवर्क शामिल हैं. इनके बिना आपकी साइट काम नहीं कर सकती.

कुछ स्क्रिप्ट, एसिंक्रोनस रूप से लोड होने पर काम नहीं करतीं. इस्तेमाल की जा रही किसी भी स्क्रिप्ट के दस्तावेज़ देखें. साथ ही, ऐसी किसी भी स्क्रिप्ट को बदलें जिसे एसिंक्रोनस तरीके से लोड नहीं किया जा सकता. ध्यान रखें कि कुछ तीसरे पक्ष, अपनी स्क्रिप्ट को सिंक्रोनस तरीके से चलाने का सुझाव देते हैं. भले ही, वे एसिंक्रोनस तरीके से भी उतनी ही अच्छी तरह से काम करें.

याद रखें कि async से हर समस्या ठीक नहीं होती. अगर आपके पेज पर विज्ञापन के मकसद से ट्रैकिंग स्क्रिप्ट जैसी कई स्क्रिप्ट शामिल हैं, तो उन्हें एसिंक्रोनस तरीके से लोड करने से, पेज लोड होने की स्पीड कम होने से नहीं रोकी जा सकेगी.

कनेक्शन सेटअप करने में लगने वाले समय को कम करने के लिए, रिसॉर्स हिंट का इस्तेमाल करना

तीसरे पक्ष के ऑरिजिन से कनेक्शन बनाने में ज़्यादा समय लग सकता है. खास तौर पर, धीमे नेटवर्क पर. ऐसा इसलिए, क्योंकि नेटवर्क के अनुरोधों में कई जटिल कॉम्पोनेंट होते हैं. इनमें डीएनएस लुकअप और रीडायरेक्ट शामिल हैं. पेज लोड होने की प्रोसेस के दौरान, तीसरे पक्ष की स्क्रिप्ट को होस्ट करने वाले डोमेन के लिए डीएनएस लुकअप करने के लिए, Resource Hints का इस्तेमाल किया जा सकता है. जैसे, . इससे, नेटवर्क के बाकी अनुरोधों को बाद में तेज़ी से प्रोसेस किया जा सकता है:

<link rel="dns-prefetch" href="http://example.com" />

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

<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 कोड शामिल होता है. इस कोड पर, खराब इंटरनेट कनेक्शन का असर पड़ सकता है.

ध्यान दें: LazySizes, इमेज और iframe की लेज़ी लोडिंग के लिए एक लोकप्रिय JavaScript लाइब्रेरी है. इसमें YouTube वीडियो और विजेट एम्बेड किए जा सकते हैं.

DoubleClick के आधिकारिक दस्तावेज़ में, विज्ञापनों को लेज़ी लोड करने के बारे में जानकारी दी गई है.

Intersection Observer की मदद से, लेज़ी लोडिंग को बेहतर बनाना

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

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

लेज़ी लोड से जुड़े आंकड़े

अगर आपने Analytics स्क्रिप्ट को लोड होने में बहुत ज़्यादा समय लगाया, तो हो सकता है कि आपको Analytics का अहम डेटा न मिले. खुशकिस्मती से, पेज लोड होने के शुरुआती डेटा को बनाए रखते हुए, ऐनलिटिक्स को लेज़ी लोड करने की रणनीतियां उपलब्ध हैं.

फ़िल वॉल्टन की ब्लॉग पोस्ट The Google Analytics Setup I Use on Every Site I Build में, Google Analytics के लिए ऐसी ही एक रणनीति के बारे में बताया गया है.

तीसरे पक्ष की स्क्रिप्ट को सुरक्षित तरीके से लोड करना

इस सेक्शन में, तीसरे पक्ष की स्क्रिप्ट को सुरक्षित तरीके से लोड करने के बारे में बताया गया है.

document.write() से बचें

तीसरे पक्ष की स्क्रिप्ट, खास तौर पर पुरानी सेवाओं के लिए, कभी-कभी स्क्रिप्ट को इंजेक्ट और लोड करने के लिए, document.write() का इस्तेमाल करती हैं. यह एक समस्या है, क्योंकि document.write() का व्यवहार एक जैसा नहीं होता. साथ ही, इसकी गड़बड़ियों को डीबग करना मुश्किल होता है.

document.write() से जुड़ी समस्याओं को ठीक करने का तरीका यह है कि इसका इस्तेमाल न किया जाए. Chrome 53 और इसके बाद के वर्शन में, Chrome DevTools, document.write() के गलत इस्तेमाल के लिए कंसोल में चेतावनियां लॉग करता है:

Chrome DevTools के फ़्लैग document.write() का इस्तेमाल.

अगर आपको यह गड़बड़ी मिलती है, तो अपनी साइट पर document.write() के इस्तेमाल की जांच की जा सकती है. इसके लिए, अपने ब्राउज़र पर भेजे गए एचटीटीपी हेडर देखें. Lighthouse, तीसरे पक्ष की उन स्क्रिप्ट को भी हाइलाइट कर सकता है जो अब भी document.write() का इस्तेमाल कर रही हैं.

Lighthouse की रिपोर्ट, जिसमें यह दिखाया गया है कि कौनसी स्क्रिप्ट document.write() का इस्तेमाल करती हैं.

टैग मैनेजर का इस्तेमाल ध्यान से करें

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

पेज लोड को तेज़ी से रखने के लिए, हमारा सुझाव है कि आप Google Tag Manager (GTM) जैसे Tag Manager का इस्तेमाल करें. GTM की मदद से, टैग को एसिंक्रोनस तरीके से डिप्लॉय किया जा सकता है. इससे टैग एक-दूसरे को लोड होने से नहीं रोकते. साथ ही, ब्राउज़र को टैग लागू करने के लिए कम नेटवर्क कॉल करने पड़ते हैं. इसके अलावा, GTM अपने डेटा लेयर यूज़र इंटरफ़ेस (यूआई) में टैग डेटा इकट्ठा करता है.

टैग मैनेजर इस्तेमाल करने के जोखिम

टैग मैनेजर को पेज लोड होने की प्रोसेस को आसान बनाने के लिए डिज़ाइन किया गया है. हालांकि, इनका इस्तेमाल लापरवाही से करने पर, पेज लोड होने की प्रोसेस धीमी हो सकती है. ऐसा इन तरीकों से हो सकता है:

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

ऐसी स्क्रिप्ट का इस्तेमाल करने से बचें जो ग्लोबल स्कोप को खराब करती हैं

तीसरे पक्ष की स्क्रिप्ट कई तरह से काम कर सकती हैं. इससे आपके पेज पर अचानक गड़बड़ी हो सकती है:

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

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

जोखिम कम करने की रणनीतियां

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

• HTTPS: एचटीटीपीएस का इस्तेमाल करने वाली साइटों को एचटीटीपी का इस्तेमाल करने वाले तीसरे पक्षों पर निर्भर नहीं होना चाहिए. ज़्यादा जानकारी के लिए, मिक्स्ड कॉन्टेंट लेख पढ़ें.

• सैंडबॉक्सिंग: तीसरे पक्ष की स्क्रिप्ट को sandbox एट्रिब्यूट वाले iframe में चलाएं. इससे स्क्रिप्ट के लिए उपलब्ध कार्रवाइयों को सीमित किया जा सकता है.

• कॉन्टेंट की सुरक्षा के लिए नीति (सीएसपी): अपने सर्वर के रिस्पॉन्स में एचटीटीपी हेडर का इस्तेमाल करके, अपनी साइट के लिए भरोसेमंद स्क्रिप्ट के व्यवहार तय किए जा सकते हैं. साथ ही, क्रॉस साइट स्क्रिप्टिंग (XSS) जैसे कुछ हमलों का पता लगाया जा सकता है और उनके असर को कम किया जा सकता है.

यहां एक उदाहरण दिया गया है, जिसमें सीएसपी के script-src डायरेक्टिव का इस्तेमाल करके, किसी पेज के लिए अनुमति वाले JavaScript सोर्स के बारे में बताया गया है:

// 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 की मदद से इंटरैक्टिविटी जोड़ना
• तीसरे पक्ष की स्क्रिप्ट से होने वाले संभावित खतरे
• तीसरे पक्ष की स्क्रिप्ट, वेब पर बेहतर परफ़ॉर्मेंस कैसे दे सकती हैं
• Why Fast Matters - CSS Wizardry
• The JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party Libraries
• तीसरे पक्ष की सीएसएस सुरक्षित नहीं है

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