स्मार्ट टीवी और सेट-टॉप बॉक्स डिवाइसों पर इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) को बेहतर बनाना, डेस्कटॉप ब्राउज़र के मुकाबले काफ़ी ज़्यादा चुनौतियां है. ऐसा सीमित एपीआई सपोर्ट और सिस्टम की सीमित खासियतों की वजह से होता है. इस केस स्टडी में आपको पता चलेगा कि Disney+ Hotstar ने इन मुश्किलों को कैसे हल किया. इससे कारोबार को कई फ़ायदे मिले.
लिविंग रूम के डिवाइस का इस्तेमाल बढ़ने के साथ, Disney+ Hotstar ने यह माना कि स्मार्ट टीवी और सेट-टॉप बॉक्स के लिए अपने ऐप्लिकेशन में ब्राउज़िंग का बेहतर अनुभव देना, कारोबार के लिए बहुत ज़रूरी है. ऐसे डिवाइसों के लिए आईएनपी की गड़बड़ी को ठीक करना मुश्किल हो जाता है. हालांकि, किसी टीवी मॉडल में ब्राउज़र के काफ़ी पुराने वर्शन इस्तेमाल किए जा सकते हैं. उदाहरण के लिए, 2020 के LG TV में Chrome 68 का इस्तेमाल किया जाता है, जिसे 2018 में रिलीज़ किया गया था. इनमें से कुछ डिवाइसों को लो-एंड-एंड डिवाइस की कैटगरी में भी रखा जा सकता है. इसका मतलब है कि वे इंटरैक्शन के लिए उतनी तेज़ी से कार्रवाई नहीं कर सकते जितनी तेज़ी से फ़्लैगशिप टैबलेट और लैपटॉप डिवाइस करते हैं.
नीचे दिए गए डायग्राम में यह तुलना की गई है कि एक लैपटॉप के साथ Chrome DevTools और स्मार्ट टीवी पर छह गुना तक कम सीपीयू का इस्तेमाल करने पर, एक पेज को लोड होने में कितना समय लगता है. जैसा कि हमने देखा, लैपटॉप हाल ही में बनाए गए स्मार्ट टीवी के मुकाबले अब भी काफ़ी तेज़ है.
![Chrome DevTools में परफ़ॉर्मेंस प्रोफ़ाइलर का स्क्रीनशॉट, जो लैपटॉप पर Disney+ HotStar ऐप्लिकेशन की लोडिंग परफ़ॉर्मेंस की प्रोफ़ाइल बना रहा है. PAGE_RENDER_TIME नाम का कस्टम मेट्रिक 1.39 सेकंड में आता है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-1.png?authuser=3&hl=hi)
![Chrome DevTools में परफ़ॉर्मेंस प्रोफ़ाइलर का स्क्रीनशॉट, जो स्मार्ट टीवी पर Disney+ HotStar ऐप्लिकेशन की लोडिंग परफ़ॉर्मेंस की प्रोफ़ाइल बना रहा है. PAGE_RENDER_TIME नाम की कस्टम मेट्रिक 6.47 सेकंड में आती है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-2.png?authuser=3&hl=hi)
इन टेस्ट से लैब का डेटा मिलता है, लेकिन Disney+ Hotstar ने वेब अहम जानकारी वाली लाइब्रेरी का इस्तेमाल करके, अपने ऐप्लिकेशन के असली उपयोगकर्ताओं से इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) के लिए फ़ील्ड डेटा इकट्ठा करना शुरू किया. इसके अलावा, ऐप्लिकेशन के 75% उपयोगकर्ताओं ने फ़ील्ड में 675 मिलीसेकंड का आईएनपी अनुभव किया, जिसे आईएनपी थ्रेशोल्ड के हिसाब से "खराब" उपयोगकर्ता अनुभव माना जाता है.
इस केस स्टडी में बताया गया है कि Disney+ Hotstar ने खास तौर पर कम कीमत वाले डिवाइसों पर अपने स्ट्रीमिंग ऐप्लिकेशन में, रिस्पॉन्स देने की क्षमता को कैसे बेहतर बनाया है. उन्होंने आईएनपी वैल्यू को घटाकर 272 मिलीसेकंड करके 61% की बढ़ोतरी की. यह सुधार अब भी 200 मिलीसेकंड के सुझाए गए "अच्छे" थ्रेशोल्ड से ज़्यादा है. हालांकि, इस दिशा में काफ़ी सुधार हुआ है.
नतीजे
Disney+ Hotstar ने ऐप्लिकेशन को वेब-वाइटल लाइब्रेरी के एट्रिब्यूशन बिल्ड में से, onINP
तरीके का इस्तेमाल करके तैयार किया है. शुरुआती चरण में, खास तौर पर टारगेट एलिमेंट की सटीक पहचान करने में कई चुनौतियों का सामना करना पड़ा. यह समस्या इसलिए हुई, क्योंकि सभी रेफ़रंस तीसरे पक्ष की स्पेशल नेविगेशन लाइब्रेरी की वजह से टारगेट किए गए थे, जिसका इस्तेमाल Disney+ Hotstar ऐप्लिकेशन में कुछ कस्टमाइज़ेशन के साथ किया गया था. यह लाइब्रेरी सिर्फ़ दस्तावेज़ के मुख्य हिस्से से जुड़े इवेंट को सुनती है और फिर रिमोट की दबाए गए बटन के आधार पर अगले फ़ोकस का अनुमान लगाती है.
Disney+ Hotstar ने सबसे पहले एट्रिब्यूशन से जुड़ी समस्या को हल करने की शुरुआत की, ताकि हाई आईएनपी वैल्यू के लिए ज़िम्मेदार इंटरैक्शन को सही तरीके से पहचाना जा सके. इसके लिए, Disney+ Hotstar ने focusKey
एट्रिब्यूट को लॉग किया है, जो मौजूदा फ़ोकस वाले एलिमेंट के लिए स्पेशल नेविगेशन लाइब्रेरी में पहले से मौजूद है. साथ ही, पेज पर फ़ोकस करने लायक सभी एलिमेंट के मैप में भी मौजूद है. यह एट्रिब्यूट, वेब अहम जानकारी एट्रिब्यूशन बिल्ड में उपलब्ध इंटरैक्शन टारगेट के जैसा है.
![फ़ोकस-की एट्रिब्यूट के हिसाब से, एलिमेंट की सूची का स्क्रीनशॉट. साथ ही, हर एलिमेंट के इंटरैक्शन का इंतज़ार का समय भी दिखाया गया है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-3.png?authuser=3&hl=hi)
focusKey
को कैप्चर किया जा रहा है. साथ ही, इसे ट्रिगर करने वाले एलिमेंट का पाथ भी लिया जा रहा है.
अब सही मेज़रमेंट और एट्रिब्यूशन के साथ, फ़ील्ड डेटा से मिले नतीजों ने आईएनपी के लिए इन इंटरैक्शन को सबसे समस्या के तौर पर रिपोर्ट किया.
- हॉरिज़ॉन्टल कैरसेल ट्रे नेविगेशन.
- वर्टिकल कैरसेल ट्रे नेविगेशन.
- पेज लोड होने के दौरान होने वाले इंटरैक्शन.
![ट्रे कैरसेल नेविगेशन के लिए ज़िम्मेदार एलिमेंट का स्क्रीनशॉट. इसकी फ़ोकस कुंजी से ली गई जानकारी.](https://web.dev/static/case-studies/hotstar-inp/image/fig-4.png?authuser=3&hl=hi)
Chrome Dev टूल में परफ़ॉर्मेंस पैनल के साथ इन इंटरैक्शन की प्रोफ़ाइल बनाने पर, यह पता चला कि स्पेशल नेविगेशन लाइब्रेरी ने फ़ोकस करने लायक सभी एलिमेंट की पोज़िशन पढ़ ली है और एक नया ट्री बनाया है. यह एक महंगा ऑपरेशन है, जो हर इंटरैक्शन पर लेआउट थ्रेशिंग को ट्रिगर करता है, जैसे कि एक एलिमेंट से दूसरे एलिमेंट पर जाना.
होम पेज के लिए, स्पेशल नेविगेशन लाइब्रेरी से एक ट्री इस तरह बनाया गया:
![स्पेशल नेविगेशन लाइब्रेरी से जनरेट किए गए ट्री का उदाहरण. रूट के नीचे नेविगेशनबार और ट्रे कंटेनर नोड हैं. खास तौर पर, ट्रे कंटेनर नोड में तीन कार्ड नोड होते हैं. हर कार्ड में ऐसे कई सबनोड होते हैं जो बड़े DOM साइज़ में योगदान देते हैं.](https://web.dev/static/case-studies/hotstar-inp/image/fig-5.png?authuser=3&hl=hi)
इसका मतलब यह था कि अगर ऐप्लिकेशन 10 ट्रे दिखाता है और हर ट्रे में 7 कार्ड थे, तो नेविगेशन आइटम सहित ट्रे कंटेनर के लिए 70 फ़ोकस करने लायक एलिमेंट होंगे. इसमें इंटरैक्टिव एलिमेंट की संख्या बहुत ज़्यादा होती है. तीसरे पक्ष की कैरसेल लाइब्रेरी का भी इस्तेमाल किया गया. इससे कंटेनर का अनुवाद करने के लिए, हॉरिज़ॉन्टल नेविगेशन के दौरान हर कार्ड के डाइमेंशन को पढ़ा जाता है. इससे, इंटरैक्शन में लगने वाला समय बढ़ जाता है.
समस्याओं को ठीक करना
ऐप्लिकेशन की रिस्पॉन्सिवनेस से जुड़ी समस्याओं को हल करने के लिए, कई समस्याओं को अलग-अलग हल करना पड़ता था.
हॉरिज़ॉन्टल ट्रे नेविगेशन में सुधार
Disney+ Hotstar ने अपनी खुद की इन-हाउस कैरसेल लाइब्रेरी बनाई है. इसमें, लेआउट थ्रैशिंग को ट्रिगर करने के लिए, कंपोज़िट किए गए ऐनिमेशन का इस्तेमाल नहीं किया जाता. साथ ही, एक ट्रे में डाइमेंशन को एक बार पढ़ने के बजाय, एक कार्ड में एक बार ही इसका इस्तेमाल किया जाता है.
स्पेशल नेविगेशन की सुविधा सिर्फ़ कैरसेल के रूट पर फ़ोकस करती है और आगे हॉरिज़ॉन्टल नेविगेशन के लिए, हमारा कस्टम कैरसेल दिखता है. इस तरीके को अपनाकर, Disney+ Hotstar ने स्पेशल नेविगेशन की डिपेंडेंसी को हटा दिया. साथ ही, पुरानी कैरसेल लाइब्रेरी को भी हटा दिया, जो हर नेविगेशन पर डाइमेंशन को पढ़ रही थी.
इन ऑप्टिमाइज़ेशन के बाद, स्पेशल नेविगेशन ट्री कुछ इस तरह दिखता था.
![स्पेशल नेविगेशन लाइब्रेरी से जनरेट किया गया, ऑप्टिमाइज़ किया गया एक ट्री उदाहरण. इसे पिछले वर्शन के मुकाबले ज़्यादा ऑप्टिमाइज़ किया गया है और इसमें बहुत कम नोड हैं.](https://web.dev/static/case-studies/hotstar-inp/image/fig-6.png?authuser=3&hl=hi)
नीचे दी गई इमेज, कैरसेल को लागू करने से पहले और बाद में, Chrome DevTools के परफ़ॉर्मेंस पैनल में मेज़र की गई परफ़ॉर्मेंस की तुलना करती हैं.
![Chrome DevTools में परफ़ॉर्मेंस पैनल का एक स्क्रीनशॉट, जो तीसरे पक्ष के कैरसेल के शुरू होने वाले टास्क के लिए है. ऐसे कई लंबे टास्क हैं जिनकी वजह से, इंटरैक्टिविटी में देरी होती है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-7.png?authuser=3&hl=hi)
![Chrome DevTools में इन-हाउस कैरसेल से शुरू होने वाले टास्क के लिए, परफ़ॉर्मेंस पैनल का एक स्क्रीनशॉट. तीसरे पक्ष के कैरसेल की तुलना में, इसमें ज़्यादा लंबे टास्क होते हैं. इसलिए, इंटरैक्शन ज़्यादा तेज़ी से होते हैं.](https://web.dev/static/case-studies/hotstar-inp/image/fig-8.png?authuser=3&hl=hi)
इस काम की वजह से, Disney+ Hotstar ने फ़ील्ड में अपने ऐप्लिकेशन की आईएनपी में काफ़ी गिरावट देखी. साथ ही, तीसरे पक्ष की लाइब्रेरी को हटाकर, करीब 35 केबी (कंप्रेस्ड) की बचत हुई. बोनस के तौर पर, इन सुधारों की वजह से Disney+ Hotstar अपनी कस्टम मेट्रिक की अवधि को कम कर सके, जिसका इस्तेमाल वे होम पेज के लिए कुल रेंडरिंग समय को मापने के लिए करते हैं. ऐसा इसलिए होता है, क्योंकि स्पेशल नेविगेशन नोड कम होने की वजह से लेआउट कम बार ट्रिगर होते हैं.
![tizentv और webos, दोनों के लिए पेज के रेंडर होने में लगने वाले समय की कस्टम मेट्रिक की टाइम सीरीज़, जिसमें 13 मार्च से 19 मार्च तक की समयसीमा में क्रमश: 31% और 25.2%, दोनों की कमी आई.](https://web.dev/static/case-studies/hotstar-inp/image/fig-9.png?authuser=3&hl=hi)
वर्टिकल ट्रे नेविगेशन में सुधार
Disney+ Hotstar ने वर्टिकल ट्रे नेविगेशन परफ़ॉर्मेंस को भी बेहतर बनाया है. ऐसा इसलिए किया गया है, क्योंकि ये ट्रे ऊपर की ओर लोड होने के बजाय लेज़ी लोड होती हैं. इसलिए, पेज लोड होने पर, ट्रे के 10 इंस्टेंस लोड करने के बजाय, जिसमें हर बार एक कैरसेल कॉम्पोनेंट और कई इमेज होती हैं. ऐप्लिकेशन, व्यूपोर्ट में दिखने वाली दो ट्रे को ही लोड करता है. साथ ही, ऐप्लिकेशन के ऊपर और नीचे एक और ट्रे भी लोड होती है. setTimeout()
यील्डिंग रणनीति का इस्तेमाल करके, रेंडरिंग को कई टास्क में बांटा गया, ताकि मुख्य थ्रेड के पास उपयोगकर्ता के इंटरैक्शन को मैनेज करने के ज़्यादा मौके हों.
![रनिंग इवेंट हैंडलर और रेंडरिंग अपडेट के लिए, टास्क का बेहतर बनाया गया विज़ुअलाइज़ेशन. एक लंबे टास्क के बाद, रेंडरिंग अपडेट की तारीख आगे बढ़ा दी जाती है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-10.png?authuser=3&hl=hi)
![उसी गतिविधि का एक और विज़ुअलाइज़ेशन जो पिछले आंकड़े की तरह ही है, लेकिन काम न करने की वजह से टास्क पूरे हो जाते हैं, जिसकी वजह से रेंडरिंग जल्द हो सकती है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-11.png?authuser=3&hl=hi)
शुरुआत में पेज लोड होने के दौरान होने वाले इंटरैक्शन
आईएनपी मेट्रिक, उन ऐप्लिकेशन के लिए ज़्यादा होगी जो ऐप्लिकेशन लॉन्च करने के दौरान बड़ी संख्या में स्क्रिप्ट प्रोसेस करते हैं. ऐसा इसलिए होता है, क्योंकि ब्राउज़र को उन स्क्रिप्ट को डाउनलोड, पार्स, और उनका आकलन करना होता है. ऐसा होने पर, मुख्य थ्रेड लंबे समय तक बनी रहेगी. इससे वह उपयोगकर्ता के इंटरैक्शन का तुरंत जवाब नहीं दे पाएगी.
Disney+ Hotstar को एहसास हुआ कि वे ऐप्लिकेशन शुरू होने (स्प्लैश स्क्रीन टाइम) के दौरान, ज़रूरत से ज़्यादा स्क्रिप्ट प्रोसेस कर रहे थे, ताकि आने वाले समय में पेज तेज़ी से लोड हो सकें. इसकी वजह से, स्क्रिप्ट का आकलन करने वाले कुछ और टास्क सामने आए. इनसे आईएनपी पर बुरा असर पड़ने की संभावना भी है.
इस समस्या को ठीक करने के लिए, Disney+ Hotstar ने ज़्यादातर ऐसेट को डाइनैमिक तरीके से लोड करने पर विचार किया, ताकि ऐप्लिकेशन शुरू होने के दौरान वे समय की बचत कर सकें. हालांकि, ऐसा करने से आने वाले समय में पेजों के नेविगेशन के लिए लोड होने का समय बढ़ जाएगा, क्योंकि इस बदलाव के बाद JavaScript को पहले से लोड नहीं किया जाएगा. इस समस्या से निपटने के लिए, Disney+ Hotstar ने इन-हाउस ऐसेट प्रीलोडर लाइब्रेरी डेवलप की है. इससे यह तय होता है कि उपयोगकर्ता के अनुभव में अगला पेज कौनसा हो सकता है. इसके बाद, वह उस पेज के लिए ऐसेट पहले से लोड कर देगा. उदाहरण के लिए:
- जब कोई उपयोगकर्ता लॉगिन पेज पर होता है, तो एसेट प्रीलोडर लाइब्रेरी, प्रोफ़ाइल चुनने वाले पेज के लिए ऐसेट को पहले से लोड कर देगी.
- प्रोफ़ाइल चुनने वाले पेज पर, होम पेज की ऐसेट लोड हो जाती हैं.
- होम पेज पर, ज़्यादा जानकारी वाले पेज की ऐसेट लोड हो जाती हैं.
- आखिर में, वॉच पेज की ऐसेट, ज़्यादा जानकारी वाले पेज पर लोड हो जाती हैं.
एसेट लोड होने की सुविधा को ऑप्टिमाइज़ करने से Disney+ Hotstar को दो चीज़ों में मदद मिली: ऐप्लिकेशन का आईएनपी कम करना (क्योंकि मुख्य थ्रेड अब उपयोगकर्ताओं के इंटरैक्शन के लिए पहले से ज़्यादा आसान था) और कम लेवल वाले डिवाइसों पर मेमोरी के इस्तेमाल को भी कम करना.
इन बदलावों की वजह से, फ़ील्ड से रिपोर्ट की गई आईएनपी संख्या में 32% की कमी आई. इसका उदाहरण नीचे दिया गया है.
![13 अगस्त से 11 सितंबर से शुरू होने वाली आईएनपी वैल्यू की टाइम सीरीज़. इस दौरान, आईएनपी में 32% की कमी दिखाई गई है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-12.png?authuser=3&hl=hi)
अन्य सुधार
Disney+ Hotstar ने यह भी पता लगाया कि कुछ उपयोगकर्ता इवेंट में लंबे टास्क थे जिन्हें मुख्य थ्रेड में बार-बार जोड़कर बांटा जा सकता है. इसने एक कदम आगे जाकर, टास्क जनरेट करने वाली एक सुविधा बनाई. इसकी मदद से उपयोगकर्ता, टास्क के बीच में ही उस टास्क को रद्द कर सकते हैं.
उदाहरण के लिए, जब उपयोगकर्ता ट्रे पर एक से ज़्यादा कार्ड से नेविगेट करता है, तो ऐसा होता है:
- अगले कार्ड पर फ़ोकस है.
- ज़रूरत पड़ने पर, कार्ड का अनुवाद किया जाता है.
- स्पॉटलाइट अपडेट कर दिया गया है.
- अगर ट्रेलर मौजूद है, तो उसे फ़ेच किया जाता है और वीडियो चलाना शुरू कर दिया जाता है.
- Analytics इवेंट, कार्रवाई के लिए चालू होते हैं.
अगर इस प्रोसेस के दौरान, उपयोगकर्ता अगले कार्ड पर फ़ोकस करता है, तो बाकी के चरणों को पूरा करने की ज़रूरत नहीं पड़ेगी. उदाहरण के लिए, अगर उपयोगकर्ता अगले कार्ड पर चला गया है, तो अब किसी खास टाइटल के लिए ट्रेलर फ़ेच करने और प्लेयर को शुरू करने की ज़रूरत नहीं होगी. इसलिए, मुख्य थ्रेड को खाली करने के लिए, उन टास्क को रद्द किया जा सकता है.
Disney+ Hotstar की टास्क जनरेटर यूटिलिटी एक फ़ंक्शन को स्वीकार करती है, जो एक टास्क है और जब बीच में कोई दूसरा टास्क आ जाता है, तो पिछला टास्क रद्द हो जाता है. इस वजह से, वह टास्क पूरा नहीं कर पाता और उस पर तुरंत काम कर पाता है.
नतीजे
कुल मिलाकर देखें, तो Disney+ Hotstar के आवेदन के लिए आईएनपी मेट्रिक, 675 मिलीसेकंड से घटकर 272 मिलीसेकंड हो गई है. इससे करीब 60% की बढ़ोतरी हुई! इसके अलावा, खास तौर पर ट्रे इंटरैक्शन के इंतज़ार का समय करीब 400 मिलीसेकंड से घटकर 100 मिलीसेकंड हो गया है.
![टाइम सीरीज़ INP वैल्यू, 23 अगस्त से 21 सितंबर तक. इस समयसीमा में, आईएनपी में 61% की कमी आई.](https://web.dev/static/case-studies/hotstar-inp/image/fig-13.png?authuser=3&hl=hi)
कारोबार पर असर: हर हफ़्ते कार्ड व्यू की संख्या 111 से बढ़कर 226 हो गई! इससे 100% ज़्यादा बढ़ोतरी हुई है. इससे पता चलता है कि तेज़ और ज़्यादा रिस्पॉन्सिव इंटरफ़ेस, उपयोगकर्ताओं को लंबे समय तक जोड़े रख सकता है.
![इस टाइम सीरीज़ का स्क्रीनशॉट, जिसमें Disney+ HotStar ऐप्लिकेशन पर हर हफ़्ते मिलने वाले कार्ड व्यू में 100% की बढ़ोतरी दिख रही है. यह बढ़ोतरी, Tizentv और webos, दोनों के लिए है. इसमें 4 अप्रैल, 2004 के बाद तेज़ी से बढ़ोतरी हुई है.](https://web.dev/static/case-studies/hotstar-inp/image/fig-14.png?authuser=3&hl=hi)
यह तो बस शुरुआत है. Disney+ Hotstar ने रेंडरिंग और इंटरैक्शन परफ़ॉर्मेंस को बेहतर बनाने के लिए, आईएनपी मेट्रिक को बेहतर बनाने की शुरुआत की है. साथ ही, उनकी टीम आने वाले समय में अपने ग्राहकों के लिए Disney+ Hotstar को बेहतरीन अनुभव देने वाली बनाने के लिए उत्साहित है.
सभी को धन्यवाद देने के लिए, Disney+ Hotstar के आयुष, अजय, किरण, मिलन, और रिचा का धन्यवाद.
इस केस स्टडी की समीक्षा करने और इसे पब्लिश करने में Google की टीम के जेरेमी वैगनर, गिल्बर्टो, बैरी पोलार्ड, और ब्रेंडन केनी को धन्यवाद. एंकीत मेनी, इंजीनियरिंग हेड Disney+ Hotstar के इंजीनियरिंग हेड, और राहुल कृष्णन पी, कस्टमर एक्सपीरियंस Disney+ Hotstar के हेड हैं.