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