आज-कल वेब पर, तीसरे पक्ष के रिसॉर्स (जैसे कि एम्बेड और स्क्रिप्ट) का बहुत ज़्यादा इस्तेमाल होता है. इस टूल की मदद से, सोशल मीडिया, वीडियो, आंकड़े, लाइव चैट, विज्ञापन, A/B टेस्टिंग, ऐप्लिकेशन को उपयोगकर्ता के मनमुताबिक बनाने की प्रोसेस वगैरह को एम्बेड करने के लिए बेहतरीन टूल उपलब्ध कराए जाते हैं. तीसरे पक्ष के एम्बेड, आधुनिक वेबसाइटों का एक ज़रूरी हिस्सा हैं. इनकी मदद से, साइट के मालिक अपनी मुख्य क्षमताओं पर ध्यान दे पाते हैं. साथ ही, बाहरी कंपनियों के लिए स्टैंडर्ड और ज़रूरी कामों का लोड भी रोक देते हैं.
जब किसी वेब पेज पर पहले पक्ष और तीसरे पक्ष, दोनों साथ मिलकर काम करते हैं, तो हो सकता है कि कोई पेज बेहतरीन उपयोगकर्ता अनुभव दे. हालांकि, इसके लिए इंजीनियरिंग और कारोबार, दोनों ही टीमों को काफ़ी मेहनत करनी पड़ती है. ऐसा होने पर, अक्सर इन्हें अनदेखा कर दिया जाता है. इस वजह से, वेब पेजों की परफ़ॉर्मेंस कम हो जाती है. साथ ही, वेबसाइट की परफ़ॉर्मेंस की जानकारी जैसी उपयोगकर्ता को ध्यान में रखकर काम करने वाली मेट्रिक पर भी गलत असर पड़ता है. यह दोनों पक्षों के लिए नुकसानदेह होता है और इससे कारोबारों में छूटे हुए मौके सामने आते हैं. क्या हम यहां बेहतर कर सकते हैं?
हम आने वाले समय में वेब को बेहतर बनाने की कोशिश कर रहे हैं. इसमें तीसरे पक्ष की स्क्रिप्ट और संसाधन, ब्राउज़र में इस्तेमाल की जाने वाली वेबसाइटों की परफ़ॉर्मेंस या उपयोगकर्ता अनुभव पर कम से कम असर डालते हुए, आपके कारोबार के लिए सही जानकारी उपलब्ध कराएंगे. इससे उपयोगकर्ताओं को तेज़ी से पेज लोड होने का अनुभव मिलेगा.
पिछले साल, हमने ऐसी कई संभावनाओं पर विचार किया, उन पर चर्चा की, और उनसे जुड़े प्रयोग किए हैं. इनकी मदद से, साइट के मालिकों के लिए तीसरे पक्ष की स्क्रिप्ट के कारोबार की वैल्यू कम किए बिना, उपयोगकर्ता अनुभव को संभावित रूप से सुरक्षित रखा जा सकता है.
इस पोस्ट के ज़रिए, हम अपने कुछ एक्सपेरिमेंट के बारे में जानकारी देना चाहते हैं. हमें उम्मीद है कि यह ऐसी प्रक्रिया की शुरुआत है जिससे उपयोगकर्ता एजेंट, कारोबारों, और तीसरे पक्ष की सेवा देने वाली कंपनियों के बीच पारदर्शिता और पारदर्शिता को बढ़ावा मिलेगा. साथ ही, इंटरनेट को तेज़ी से लोड करने में मदद मिलेगी.
तीसरे पक्षों के बारे में ज़्यादा जानकारी
तीसरा पक्ष, ऐसा संसाधन है जो साइट से बाहर की कंपनी देती है. वे सीधे साइट के मालिकों के कंट्रोल में नहीं होते, बल्कि उनकी मंज़ूरी के साथ मौजूद होते हैं. तीसरे पक्ष के संसाधन नीचे दिए गए हैं:
- प्राइमरी साइट के ऑरिजिन से अलग, शेयर किए गए और सार्वजनिक ऑरिजिन पर होस्ट किया गया.
- किसी साइट के मालिक ने न तो उसे लिखा है और न ही उससे प्रभावित है.
- कई तरह की साइटों में इसका इस्तेमाल बड़े पैमाने पर किया जाता है.
तीसरे पक्ष, रेवेन्यू जनरेट करने (विज्ञापनों के ज़रिए) से लेकर मार्केटिंग के बेहतर अवसर देने (सोशल मीडिया एम्बेड) तक, कई तरह के कारोबारी मकसद पूरे करते हैं. तीसरे पक्षों की सामान्य कैटगरी में ये शामिल हैं:
सोर्स: कैटगरी के मुताबिक तीसरे पक्ष.
| कैटगरी | परिभाषा |
|---|---|
| विज्ञापन | विज्ञापन दिखाने या विज्ञापन की परफ़ॉर्मेंस देखने के लिए इस्तेमाल की जाने वाली स्क्रिप्ट. |
| वीडियो | वीडियो प्लेयर और स्ट्रीमिंग की सुविधा को चालू करने वाली स्क्रिप्ट. |
| होस्ट की गई लाइब्रेरी | सार्वजनिक रूप से होस्ट की गई ओपन सोर्स लाइब्रेरी का मिक्स. |
| कॉन्टेंट | कॉन्टेंट देने वाले या पब्लिश करने से जुड़े खास अफ़िलिएट ट्रैकिंग की स्क्रिप्ट. |
| कस्टमर सक्सेस | चैट और संपर्क समाधान ऑफ़र करने वाली ग्राहक सहायता/मार्केटिंग कंपनियों की स्क्रिप्ट. |
| Hosting | वेब होस्टिंग प्लैटफ़ॉर्म से स्क्रिप्ट. |
| मार्केटिंग | पॉप-अप, न्यूज़लेटर वगैरह जोड़ने वाले मार्केटिंग टूल की स्क्रिप्ट. |
| सोशल | ऐसी स्क्रिप्ट जो सामाजिक सुविधाओं को चालू करती हैं. |
| Tag Manager | ऐसी स्क्रिप्ट जो कई अन्य स्क्रिप्ट लोड करती हैं और कई काम शुरू करती हैं. |
| Analytics | ऐसी स्क्रिप्ट जो उपयोगकर्ताओं और उनकी कार्रवाइयों को मेज़र या ट्रैक करती हैं. |
| कुकी के लिए सहमति देने वाला प्लैटफ़ॉर्म | ऐसी स्क्रिप्ट जो साइटों को, सही और पारदर्शी तरीके से उपयोगकर्ता की सहमति (जीडीपीआर, ईपीआर, सीसीपीए) पाने की अनुमति देती हैं. |
| उपयोगिता | ऐसी स्क्रिप्ट जो डेवलपर के लिए काम की हैं (एपीआई क्लाइंट, साइट को मॉनिटर करना, धोखाधड़ी की पहचान करना वगैरह). |
| अन्य | शेयर किए गए ऑरिजिन से डिलीवर की गई अलग-अलग स्क्रिप्ट, जिसमें कोई सटीक कैटगरी या एट्रिब्यूशन शामिल नहीं है. |
तीसरे पक्ष की इन स्क्रिप्ट और लाइब्रेरी की मदद से वेब डेवलपर, मशीन में नई चीज़ें शामिल करने के बजाय, स्टैंडर्ड सुविधाओं को लागू करने के लिए आज़माए हुए और आज़माए हुए तरीकों का इस्तेमाल कर पाते हैं. इसलिए, तीसरे पक्ष से कारोबार को डेवलप करने में लगने वाला समय कम हो जाता है और कारोबारों को तेज़ी से प्रॉडक्ट लॉन्च या अपग्रेड करने में मदद मिलती है. इसमें कोई हैरानी की बात नहीं है कि डेस्कटॉप और मोबाइल पर मौजूद 94% से ज़्यादा वेबसाइटों पर तीसरे पक्ष का इस्तेमाल किया जाता है.
तीसरे पक्ष, परफ़ॉर्मेंस पर कैसे असर डालते हैं?
आम तौर पर, तीसरे पक्षों के डेवलपर, अपने ऐप्लिकेशन की खास सुविधाओं के लिए विषय की जानकारी रखने वाले विशेषज्ञ होते हैं. ज़्यादातर लोकप्रिय तीसरे-पक्षों में कई बार बदलाव हो चुके हैं. इसलिए, कोई भी व्यक्ति अपने कारोबार के लक्ष्यों के लिए, उसके कोड को ऑप्टिमाइज़ कर सकता है. हो सकता है कि उसके कोड में उनका इस्तेमाल करने वाले पेजों की परफ़ॉर्मेंस भी शामिल हो या नहीं. हालांकि, हम यह जानते हैं कि सबसे ज़्यादा ऑप्टिमाइज़ किए गए तीसरे पक्ष भी परफ़ॉर्मेंस पर असर डालते हैं. इसकी मुख्य वजहें ये हैं:
साइज़ और स्क्रिप्ट एक्ज़ीक्यूशन की लागत: तीसरे पक्षों का मकसद अक्सर "बस" आपके पेज में
<script>या<iframe>एलिमेंट शामिल करके, ज़रूरी फ़ंक्शन उपलब्ध कराना होता है. इसके बाद, ये एलिमेंट ऐसी स्क्रिप्ट और रिसॉर्स इकट्ठा करते हैं जिनका साइज़ बहुत ज़्यादा होता है. इन एलिमेंट को डाउनलोड और एक्ज़ीक्यूट करने में ज़्यादा समय लगता है. बहुत ज़्यादा JavaScript, मुख्य थ्रेड को ज़्यादा देर तक व्यस्त रखता है, रेंडरिंग को ब्लॉक करता है, और उपयोगकर्ता के इंटरैक्शन को देरी से पूरा करता है. ऐसा माना गया है कि कुछ मुख्य तीसरे पक्षों ने 50% से ज़्यादा साइटों के विश्लेषण के लिए, मुख्य थ्रेड को 42 मि॰से॰ से 1.6 एस तक ब्लॉक कर दिया है. मुख्य थ्रेड को ब्लॉक करने से, टोटल ब्लॉकिंग टाइम (टीबीटी) बढ़ जाता है. यह उन मेट्रिक में से एक है जो साइट के परफ़ॉर्मेंस स्कोर पर असर डालती है. इसके अलावा, यह उपयोगकर्ता के इंटरैक्शन पर भी जवाब देने में देरी करता है. साथ ही, यह वेबसाइटों के रिस्पॉन्स को मापने के लिए इस्तेमाल की जाने वाली इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) मेट्रिक को कम करता है. इसलिए, स्क्रिप्ट चलाने की लागत का, परफ़ॉर्मेंस पर काफ़ी असर पड़ता है.संख्या: औसतन, वेबसाइटें मोबाइल और वेब पर 21 अलग-अलग तीसरे पक्षों का इस्तेमाल करती हैं. तीसरे पक्ष के टैग अक्सर टैग मैनेजमेंट टूल की मदद से जोड़े जाते हैं. तकनीकी/डेवलपमेंट टीम, इन टूल को सीधे तौर पर कंट्रोल नहीं करती हैं. जिन टैग की ज़रूरत नहीं है उन्हें अन्य टीमें बिना समीक्षा की प्रोसेस के जोड़ सकती हैं और उन्हें कभी हटाया नहीं जा सकता. इनसे उपयोगकर्ता अनुभव, पेज के वज़न या सीपीयू के इस्तेमाल पर काफ़ी असर पड़ सकता है. नियंत्रण करने की प्रोसेस लागू करने से, ऐसी समस्याओं का समाधान हो सकता है. साथ ही, डेवलपर को सेवा देने वाली हर कंपनी के असर का ऑडिट करने में मदद मिल सकती है. इससे हमें मदद मिलेगी कि डेवलपर के पास सभी तीसरे पक्षों के लिए ऐसा डेटा उपलब्ध हो जो उनकी परफ़ॉर्मेंस के असर, फ़ायदों, और तुलना के लिए किसी खास फ़ंक्शन की सुविधा देता हो. टीमों के सामने एक और चुनौती यह है कि उनके तीसरे पक्ष के टैग सिर्फ़ प्रोडक्शन में काम करते हैं, न कि डेवलपमेंट एनवायरमेंट में. ऐसी कई साइटों के मामले में, डेवलपर के लिए इनकी जांच करना और भी मुश्किल हो जाता है.
नेटवर्क: तीसरे पक्षों को अलग-अलग ऑरिजिन से होस्ट किया जाता है. इसलिए, उनसे कॉन्टेंट डाउनलोड करने के लिए, ब्राउज़र को बड़ी संख्या में कनेक्शन बनाने पड़ते हैं. अलग-अलग कनेक्शन, प्राथमिकता के आधार पर डाउनलोड को सिंक नहीं कर सकते. इस वजह से, नेटवर्क में समस्या आ रही है. अगर सही ऑप्टिमाइज़ेशन पर ध्यान नहीं दिया जाता है, तो पेज लोड होने में और देरी हो सकती है.
क्रम से लगाना: तीसरे पक्ष, मुख्य थ्रेड को ब्लॉक कर सकते हैं और ज़्यादा ज़रूरी संसाधनों के लिए बैंडविथ पर सवाल पूछ सकते हैं. हालांकि, कुछ मामलों में तीसरे पक्ष, पेज को रेंडर करने के लिए ज़रूरी संसाधन होते हैं. जब वेबसाइटें एक से ज़्यादा तीसरे पक्ष का इस्तेमाल करती हैं, तो पहले और तीसरे पक्ष के संसाधनों को इष्टतम क्रम में रखना ज़रूरी हो जाता है. वेब डेवलपर को क्रम को ऑप्टिमाइज़ करने के लिए मौजूद अलग-अलग विकल्प के बारे में पता होना चाहिए.
ऊपर बताई गई बातों की वजह से, तीसरे पक्ष का असर, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के किसी भी या सभी कॉम्पोनेंट पर पड़ सकता है. तीसरे पक्ष की ज़्यादातर कंपनियां, सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) और फ़र्स्ट इनपुट डिले (एफ़आईडी) पर बुरा असर डालती हैं. YouTube ने एम्बेड की गई मुख्य थ्रेड को ब्लॉक कर दिया है. ऐसा, मोबाइल की 10% वेबसाइटों के लिए 4.5 सेकंड और स्टडी की गई 50% वेबसाइटों के लिए, कम से कम 1.6 सेकंड के लिए किया जाता है. मान लें कि धीमे इंटरनेट कनेक्शन पर ऐसी 20 स्क्रिप्ट वाले पेज को देखने पर उपयोगकर्ता को कितना तकलीफ़ होगी. thirdpartyweb.today का यह विज़ुअलाइज़ेशन, तीसरे पक्ष के ऐसे लोगों को दिखाता है जिनकी परफ़ॉर्मेंस पर मौजूदा समय में सबसे ज़्यादा असर हुआ है.
"कुल ~40 लाख साइटों में से, ~2700 ऑरिजिन पर स्क्रिप्ट लागू होने में लगने वाले कुल समय में से 57% हिस्सा, टॉप 50 इकाइयों से आता है. ये इकाइयां पहले से ही ~47% हैं". - तीसरे पक्ष का वेब
ऐसे पेज जो जल्दी रेंडर होते हैं और सही समयसीमा में इंटरैक्टिव हो जाते हैं वे लोगों को अच्छा अनुभव देने के लिए ज़रूरी होते हैं. इस जानकारी को वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक से मापा जाता है. अच्छे UX का मतलब अक्सर वेबसाइट के लिए अच्छा कारोबार होता है. इसका मतलब है कि इसका मतलब है कि तीसरे पक्षों का इस्तेमाल करना उनके लिए भी अच्छा है. तीसरे पक्षों के असर को कम करने के लिए मिलकर काम करना, चेन में शामिल सभी लोगों के लिए फ़ायदेमंद हो सकता है.
हम स्वीकार करते हैं कि Google, आम तौर पर इस्तेमाल होने वाली तीसरे पक्ष की बहुत सी स्क्रिप्ट देता है. इनमें Google Tag Manager, YouTube से एम्बेड की गई स्क्रिप्ट, और ReCaptcha शामिल हैं. हम स्वीकार करते हैं कि हमारी कई स्क्रिप्ट की परफ़ॉर्मेंस की वजह से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर बुरा असर पड़ सकता है. साथ ही, हम जहां संभव हो वहां इस असर को कम करने के तरीके एक्सप्लोर करने की पूरी कोशिश कर रहे हैं.
Chrome आपकी मदद कैसे कर सकता है?
तीसरे पक्ष के संसाधनों का परफ़ॉर्मेंस खराब होना, डेवलपर के लिए आम तौर पर एक चुनौती होती है. इसकी वजह से, उन्हें नेटवर्क में चल रहे बदलावों में बड़े पैमाने पर बदलाव करना पड़ता है. Chrome इन नतीजों के लिए इस प्लैटफ़ॉर्म को एक्सप्लोर करना चाहता है:
उपयोगकर्ता अनुभव या कारोबार के नतीजों को फिर से हासिल किए बिना, वेब पर तीसरे पक्ष के संसाधनों को लोड करने के बेहतर तरीके ढूंढें.
हम जानते हैं कि अगर हम पार्टनर, कारोबारों, तीसरे पक्षों, और डेवलपर के साथ मिलकर काम नहीं करते हैं, तो इस मामले को और बेहतर नहीं बनाया जा सकता. हमें सार्वजनिक तौर पर जानकारी देने वाले वीडियो या पोस्ट की मदद से, अलग-अलग तरह की संभावनाओं के बारे में बात करने और आइडिया शेयर करने के लिए, एक ओपन फ़ील्ड बनाना है. डेवलपर के पास सुझाव देने और इनमें से कई प्रस्तावों के असर की जांच करने के लिए समय होगा.
तीसरे पक्ष की स्क्रिप्ट के उपयोगकर्ताओं को टूल और फ़ील्ड में अपनी लागत के लिए बेहतर एट्रिब्यूशन पाने में मदद करें. साथ ही, उन्हें इस्तेमाल करने के लिए सही और सही पाथ और ऑथरिंग टाइम के दौरान बेहतर इंसेंटिव पाने के लिए भी बढ़ावा दें, ताकि यह पक्का किया जा सके कि वे डिफ़ॉल्ट रूप से बेहतर हों.
हम सभी लेयर को बेहतर बनाना चाहते हैं, जैसे कि उपयोगकर्ता एजेंट, फ़्रेमवर्क, और तीसरे पक्ष की स्क्रिप्ट, ताकि तीसरे पक्ष की परफ़ॉर्मेंस के असर को कम किया जा सके. हम ज़रूरत के हिसाब से अहम जानकारी भी उपलब्ध कराना चाहते हैं, ताकि साइट के मालिक, एम्बेड की गई हर स्क्रिप्ट के लिए सबसे सही तरीके लागू कर सकें. साथ ही, ज़रूरत पड़ने पर वे तेज़ी से विकल्प भी दे सकते हैं.
प्रस्तावित तरीका
इन नतीजों को पाने के लिए, हम तीन चरणों में काम करने का सुझाव देते हैं...
**डेवलपर को आरयूएम और Chrome के डेवलपर टूलिंग के ज़रिए, तीसरे पक्ष से होने वाले हर असर के बारे में ज़्यादा जानकारी दें.**
आरयूएम का मतलब है, उपयोगकर्ता की असल मेट्रिक के डेटा को वेब परफ़ॉर्मेंस मॉनिटर करने वाले एपीआई के ज़रिए उपलब्ध कराना. इसे फ़ील्ड डेटा भी कहा जाता है. Chrome डेवलपर टूलिंग में Lighthouse, Chrome DevTools, और Chrome उपयोगकर्ता अनुभव रिपोर्ट शामिल हैं. हम उपलब्ध एपीआई और टूल को बेहतर बनाने का सुझाव देते हैं, ताकि साइट डेवलपर हर पेज पर इस्तेमाल किए गए हर तीसरे पक्ष के असर को समझ सकें. इन टूल में, उन्हें यह जानकारी भी दी जाती है कि उनके असर को कम करने के लिए, कौनसे कदम उठाए जा सकते हैं. जैसे, उन्हें रोकना या फ़ैकैड का इस्तेमाल करना. साथ ही, उन्हें यह भी पता चलेगा कि वे क्या कर सकते हैं. जैसे, तीसरे पक्ष या खुद करके देखें और ट्रेड-ऑफ़ करें. वेब की परफ़ॉर्मेंस को मॉनिटर करने वाले एपीआई के लिए, हम ऐसे तरीके एक्सप्लोर कर रहे हैं जिनसे अपने उपयोगकर्ताओं की निजता और सुरक्षा से समझौता किए बिना, क्रॉस-ऑरिजिन संसाधनों के कवरेज को बढ़ाया जा सके.
**तीसरे पक्ष के संसाधनों को बेहतर तरीके से लोड करने के लिए, कारोबारों को एक बेहतर पाथ दें.**
हम ऐसे नए स्टैंडर्ड का सुझाव देना चाहते हैं जो ब्राउज़र को बेहतर तरीके से लोड करने के लिए बढ़ावा देते हैं. इससे, उपयोगकर्ताओं को लोड होने के बेहतर अनुभव के लिए, पहले-पक्ष और तीसरे-पक्ष के संसाधनों के लोड होने में मदद मिलती है. बाद में, हम इनमें से कुछ प्रस्तावों को हाइलाइट करेंगे. जैसे कि डिफ़ॉल्ट रूप से, धीमे लोड होने वाले तीसरे पक्ष के एम्बेड या तीसरे पक्ष के संसाधनों को अलग-अलग संसाधनों की प्राथमिकता लागू करना. ऐसा हो सकता है कि यह शुरुआती कॉन्टेंट के लिए उपयोगकर्ताओं के लिए ज़्यादा अहम न हो. ये उन आइडिया की एक छोटी संख्या है जिनकी हम इस जगह पर आकलन कर रहे हैं. इस काम को पूरा करने के लिए, हम वेब परफ़ॉर्मेंस विशेषज्ञों और पूरी कम्यूनिटी के साथ मिलकर काम करना चाहते हैं.
हम ज़रूरत के हिसाब से, JavaScript फ़्रेमवर्क और कॉन्टेंट मैनेजमेंट सिस्टम (सीएमएस) में इस तरह की समस्याओं को हल करना चाहते हैं. Aurora और WordPress Performance Team जैसे प्रोजेक्ट ने हमें बेक-इन डिफ़ॉल्ट की अहमियत समझाई, जिनसे लोड होने से जुड़ी सामान्य समस्याएं हल हो जाती हैं. डिफ़ॉल्ट तौर पर, फ़्रेमवर्क और सीएमएस, कारोबार को बेहतर तरीके से मैनेज करने में मदद करते हैं. ये उपयोगकर्ता एजेंट (उदाहरण के लिए, Chrome) के लिए भी मददगार हो सकते हैं. ये संकेत, पेज लोड और CWV को ऑप्टिमाइज़ करने के लिए अनुभव को लागू करने में मदद करते हैं. इन संकेतों से उपयोगकर्ता एजेंट को यह तय करने में मदद मिल सकती है कि पेज की लाइफ़ साइकल में तीसरे पक्षों को कब और कैसे लोड करना चाहिए. (उदाहरण के लिए, पेज के इंटरैक्टिव होने के बाद, तीसरे पक्ष की स्क्रिप्ट लोड करने के लिए, Next.js स्क्रिप्ट कॉम्पोनेंट में डिफ़ॉल्ट रूप से बेक किया गया विकल्प मौजूद होता है.
**पारदर्शिता की बेहतर कोशिशों के ज़रिए, तीसरे पक्ष को इंसेंटिव दें, ताकि उनकी परफ़ॉर्मेंस पर पड़ने वाले असर को कम किया जा सके.**
फ़िलहाल, तीसरे पक्ष के डेवलपर के पास यह समझने के लिए ज़रूरी जानकारी नहीं है कि उनकी स्क्रिप्ट का, साइटों पर क्या असर हो रहा है. हम इस समस्या को हल करने की योजना बना रहे हैं. साथ ही, इन कंपनियों को ऐसे टूल उपलब्ध करा रहे हैं जिनसे इनके असर का विश्लेषण किया जा सकता है. साथ ही, इनका इस्तेमाल करके हम मार्केट में मौजूद ऐसे ही दूसरे प्रॉडक्ट से इसकी तुलना कर सकते हैं. हम डेटा का इस्तेमाल करने में उनकी मदद करना चाहते हैं, ताकि वे इसकी वजह का पता लगा सकें. इससे अपस्ट्रीम की वजह से इस समस्या को कम किया जा सकेगा. हमें सफलता पाने के लिए सभी तीसरे पक्षों को शामिल करना होगा. इनमें वे पक्ष भी शामिल हैं जिन्हें Google ने बनाया है.
चैलेंज वाले वीडियो
इतने बड़े पैमाने पर काम करने की कोशिश चुनौतियों के बिना नहीं की जा सकती. हमें कुछ मुख्य चुनौतियों पर ध्यान देना होगा.
- थर्ड पार्टी एक गंभीर समस्या है. इसमें विज्ञापन, विश्लेषण, टैग मैनेजमेंट, सुविधाएं, और दूसरी बहुत सारी समस्याएं शामिल होती हैं. हर क्षेत्र के लिए, ज़रूरी शर्तों के खास सेट और ट्रेड-ऑफ़ को ध्यान में रखना ज़रूरी है. उदाहरण के लिए:
- विज्ञापनों की लोडिंग को ऑप्टिमाइज़ करने का फ़ैसला, आय और उपयोगकर्ता अनुभव के बीच के समझौते पर निर्भर करता है. बहुत जल्दी, वे ज़रूरी कॉन्टेंट को ब्लॉक कर देते हैं, इसलिए, उपयोगकर्ता उन्हें नहीं देख पाएंगे.
- Analytics स्क्रिप्ट की वजह से पेज का महत्व बढ़ जाता है, लेकिन इससे कारोबार से जुड़े उपयोगकर्ता की कार्रवाइयों के बारे में अहम डेटा मिलता है.
हम उम्मीद करते हैं कि हम अलग-अलग तरह के तीसरे पक्षों के साथ साझेदारी करेंगे, उनकी बारीकियों को समझें, समझौते को सुलझाने, और ऐसे इंसेंटिव तैयार करेंगे जो सभी के लिए कारगर साबित हों. हम समझते हैं कि अपनी रणनीति को असरदार बनाने के लिए, हमें हर क्षेत्र में इकाइयों के साथ अलग-अलग काम करना होगा. इसमें Google Tag Manager, Google Ads, और YouTube जैसे हमारे इंटरनल पार्टनर शामिल हैं.
हम साइट डेवलपर और तीसरे पक्ष के डेवलपर, दोनों को ज़्यादा एट्रिब्यूशन देना चाहते हैं. इसके लिए हमें बहुत सोच-समझकर यह काम करना पड़ता है कि असर का आकलन करने के लिए कौनसा डेटा सबसे ज़्यादा काम का है. साथ ही, सटीक जानकारी देने के साथ-साथ, इसे बेहतर तरीके से पेश करने के लिए भी हमें सही दिशा में काम करना होगा. कुल मिलाकर, किसी तीसरे पक्ष की तुलना में उसकी परफ़ॉर्मेंस की तुलना सभी के लिए साफ़ होनी चाहिए.
हम Chrome को बेहतर बनाने का सुझाव देते हैं, ताकि वह ऐसे ऑप्टिमाइज़ेशन लागू कर सके जो पहले बनाम तीसरे पक्ष के संसाधनों को लोड करने को प्राथमिकता देते समय सही संतुलन बनाने में मदद करते हैं. अहम बदलाव सभी ब्राउज़र पर एक स्टैंडर्ड के रूप में उपलब्ध हो जाता है, लेकिन इसमें समय लगता है. उदाहरण के लिए,
<img>और<iframe>एलिमेंट के लिएloadingएट्रिब्यूट, 2019 से Chrome/Edge में उपलब्ध है. हालांकि, यह 2022 में ही Safari में उपलब्ध हुआ था. जब तक किसी सुविधा का स्टैंडर्ड तय नहीं हो जाता, तब तक तीसरे पक्ष के संसाधनों के उपयोगकर्ताओं को यह पक्का करना होगा कि उन्होंने अन्य ब्राउज़र के लिए भी ऑप्टिमाइज़ किया है. जहां ज़रूरी हो वहां हम अपने दिशा-निर्देशों में इसे हाइलाइट करके आपकी मदद करेंगे.इस प्रोजेक्ट पर काम करने के लिए, हमें पार्टनर और डेवलपर के साथ मिलकर काम करना होगा. इससे हमें न सिर्फ़ खास ज़रूरतों को समझने में मदद मिलेगी, बल्कि बड़े पैमाने पर एक्सपेरिमेंटल समाधानों को टेस्ट करने में भी मदद मिलेगी. साथ ही, ज़रूरत पड़ने पर हमें सुझाव/शिकायत/राय देनी होगी, उसे दोहराना, और सुधार करना होगा. बदलावों की योजना बनानी होगी, ताकि जांच और आकलन करने के लिए सही समय अवधि मिल सके.
शुरुआती मानक के प्रस्ताव
हमने कुछ शुरुआती प्रयोग करके ऐसी सुविधाएं डेवलप की हैं जिन्हें चालू करके, तीसरे पक्ष की लोड होने की प्रोसेस को ऑप्टिमाइज़ किया जा सकता है. हम नतीजों से खुश हैं और फ़िलहाल इनमें से दो सुविधाओं के बारे में चर्चा कर सकते हैं.
LazyEmbeds
Chrome पहले हमारे लाइट मोड के उपयोगकर्ताओं के लिए, ऑफ़स्क्रीन <img> और <iframe> एलिमेंट को पहले लेज़ी-लोड करता था. इस सुविधा को सभी उपयोगकर्ताओं के लिए इस्तेमाल किया जा सकता है, ताकि तीसरे पक्ष के एम्बेड किए गए <iframe> एलिमेंट के लोड होने की प्रक्रिया को रोका जा सके. ऐसा तब तक हो सकता है, जब तक उपयोगकर्ता पेज के आस-पास स्क्रोल न करे. इससे पेज के अन्य हिस्सों को लोड होने की रफ़्तार बढ़ सकती है, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी बेहतर हो सकती है, मेमोरी का इस्तेमाल कम हो सकता है, और डेटा की बचत हो सकती है.
यहां एक डेमो दिया गया है. इसमें, किसी पेज पर YouTube वीडियो को लेज़ी लोड करने के लिए LazyEmbeds का इस्तेमाल किया गया है. एक YouTube वीडियो एम्बेड करने पर, आम तौर पर पेज पर 500 से 600 केबी का JavaScript जुड़ जाता है. हमने LazyEmbeds का इस्तेमाल करके एक ब्लॉग पोस्ट को ऑप्टिमाइज़ करने की कोशिश की. इसमें ऐसे 14 वीडियो एम्बेड किए गए. नतीजे, पेज लोड होने में लगने वाले समय और डेटा की बचत के हिसाब से उम्मीद के मुताबिक रहे.
| पहले | बाद में | |
|---|---|---|
| डेटा | 15.4 एमबी | 6.1 एमबी |
| टोटल ब्लॉकिंग टाइम | 3.2 सेकंड | 1.6 सेकंड |
इस काम के बारे में ज़्यादा जानने के लिए, हमारे एक्सप्लेनर और ब्लिंक-डेव intent-to-एक्सपेरिमेंट के थ्रेड और एक्सपेरिमेंट एक्सटेंशन पर जाएं.
टारगेट की गई तीसरे पक्ष की थ्रॉटलिंग
तीसरे पक्ष की स्क्रिप्ट को अलग-अलग टीमें अक्सर जोड़ती हैं. इसमें पूरी निगरानी की प्रोसेस शामिल नहीं होती. The Telegraph की इंजीनियरिंग टीम ने साफ़ तौर पर कहा कि "हर कोई एक पेज पर 'वह टैग' चाहता है जिससे संगठन को पैसा मिले". इससे परफ़ॉर्मेंस के असर को मैनेज करने का बोझ लगातार बढ़ सकता है.
टारगेट किए गए तीसरे पक्ष की स्क्रिप्ट को थ्रॉटलिंग करना, खास तरह के तीसरे पक्षों को थ्रॉटल करने का सुझाव देता है, ताकि उनके असर को कम किया जा सके. इससे ब्राउज़र, मुख्य कॉन्टेंट और तीसरे पक्ष के अहम कॉन्टेंट को पहले ही लोड कर पाएंगे. साथ ही, बाद में लोड होने वाले सुरक्षित कॉन्टेंट को थ्रॉटल कर दिया जाएगा.
RUM एपीआई को बेहतर बनाया जा रहा है
हम RUM एपीआई को बेहतर बनाने पर भी विचार कर रहे हैं, ताकि तीसरे पक्ष की परफ़ॉर्मेंस के आकलन के लिए काम की जानकारी शामिल की जा सके. बेहतर बनाने के लिए ये तरीके उपलब्ध हैं:
<iframe>रिपोर्टिंग: हम क्रॉस-फ़्रेम रिपोर्टिंग के लिए, परफ़ॉर्मेंस टाइमलाइन एपीआई का इस्तेमाल करने वाले समाधानों पर काम कर रहे हैं. इसकी मदद से, टॉप-लेवल के पेज के लेखक उस पेज पर एम्बेड किए गए, तीसरे पक्ष के साथ मिलकर काम कर रहे iframe के परफ़ॉर्मेंस डेटा की जांच कर सकते हैं.लॉन्ग टास्क एट्रिब्यूशन: आरयूएम में मौजूद Long Tasks API, साइट के मालिकों को उन लंबे टास्क की पहचान करने में मदद करेगा जो मुख्य थ्रेड से लंबे समय तक जुड़े होते हैं और इंटरैक्शन में देरी होती है.
ज़्यादा अपडेट
हम अब भी ऐसे कई आइडिया पर प्रयोग कर रहे हैं. हमें उम्मीद है कि हम आगे की कार्रवाई के लिए, GitHub पर जानकारी देने वाले वीडियो और खास बातों के ड्राफ़्ट पब्लिश करते रहेंगे. ऐसे तीसरे पक्ष और साइट के मालिक जो हमारे साथ साझेदारी करना चाहते हैं या जो सुझाव देना चाहते हैं वे बातचीत में हिस्सा ले सकते हैं. तीसरे पक्ष भी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी और आईएनपी मेट्रिक को ऑप्टिमाइज़ करने पर ध्यान दे सकते हैं. इससे यह पक्का किया जाता है कि वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी/आईएनपी से जुड़े खराब डेटा को क्रेडिट न किया जाए. फ़िलहाल, जिन्हें अपडेट चाहिए वे blink-dev ग्रुप पर की गई पोस्ट देख सकते हैं.
हम उम्मीद करते हैं कि आने वाले समय में हम इस समस्या को हल करने की दिशा में आगे भी काम करेंगे और हमारी कम्यूनिटी के साथ जुड़कर काम करेंगे.
लीना सोहोनी-कैस्टर, जेरेमी वैगनर, गिल्बर्टो कोची, केंजी बाहेक्स, कोउही उएनो, केंटारो हारा, और एलेक्स एन॰ जोस, मेलिसा मिचेल, यौव वाइस, शुन्या शिशिदो, और मिनोरू चिकाम्यून ने अपने सुझाव, शिकायत या राय और योगदान के लिए अपना योगदान दिया.