00:00:00GitHub ने अभी Storybook के लिए एक बहुत ही शक्तिशाली एड-ऑन जारी किया है जो पूरी तरह से
00:00:05कंपोनेंट परफॉरमेंस को टेस्ट करने के हमारे तरीके को बदल देता है।
00:00:07इसमें एक बहुत ही विस्तृत परफॉरमेंस पैनल शामिल है जो मूल्यवान जानकारी से भरा है जैसे कि
00:00:12फ्रेम टाइमिंग, इनपुट रिस्पॉन्सिवनेस, लेआउट स्टेबिलिटी, रिएक्ट प्रोफाइलिंग, मेमोरी प्रेशर
00:00:18को मापना और भी बहुत कुछ।
00:00:19इस वीडियो में, हम करीब से देखेंगे कि इस एड-ऑन में क्या-क्या खूबियाँ हैं।
00:00:23यह बहुत मजेदार होने वाला है, तो चलिए शुरू करते हैं।
00:00:31शुरू करने से पहले एक छोटा सा सवाल।
00:00:32क्या आप जानते हैं कि “शिफ्ट-लेफ्ट” परफॉरमेंस टेस्टिंग क्या है?
00:00:35यह एक डेवलपमेंट मॉडल है जो कहता है कि आपके ऐप कंपोनेंट्स की परफॉरमेंस को
00:00:40डेवलपमेंट प्रोसेस के शुरुआती दौर में ही टेस्ट किया जाना चाहिए, न कि बाद में।
00:00:45और यह टूल विशेष रूप से डेवलपर्स को जल्दी निर्णय लेने में मदद करने के लिए बनाया गया है,
00:00:50जो आपको प्रोडक्शन में जाने से पहले ही आपके कंपोनेंट्स के व्यवहार की रीयल-टाइम झलक देता है।
00:00:55तो Storybook परफॉरमेंस पैनल इस बात की बारीकी से जानकारी देता है कि आपके कंपोनेंट्स
00:01:00ब्राउज़र के रेंडरिंग इंजन के साथ कैसे इंटरैक्ट करते हैं।
00:01:02उदाहरण के लिए, यह जिटर (jitter) की पहचान करने के लिए फ्रेम टाइमिंग को ट्रैक करता है, यानी वह
00:01:07फ्रेमों के बीच छोटे अनियमित अंतराल जो एनिमेशन को अटके हुए जैसा महसूस कराते हैं।
00:01:10यह 'DOM churn' और 'thrashing' के लिए मेन थ्रेड की भी निगरानी करता है।
00:01:15DOM churn तब होता है जब आपका कोड अनावश्यक रूप से एक लूप में एलिमेंट्स बनाता, हटाता या अपडेट करता है,
00:01:20जबकि thrashing तब होती है जब ब्राउज़र को एक ही फ्रेम में कई बार
00:01:25लेआउट की गणना करने के लिए मजबूर किया जाता है क्योंकि आप लगातार स्टाइल पढ़ और लिख रहे होते हैं।
00:01:30और यह एड-ऑन आप जिस भी फ्रेमवर्क का उपयोग कर रहे हैं, उसके अनुसार ढल जाता है।
00:01:33यदि आप React का उपयोग कर रहे हैं, तो यह रेंडर कैस्केड जैसे मेट्रिक्स को हाइलाइट कर सकता है,
00:01:38जो वे छोटे स्टेट बदलाव हैं जो गलती से आपके पूरे ऐप में री-रेंडर्स की एक बड़ी लहर पैदा कर देते हैं।
00:01:44यह P95 ड्यूरेशन को भी ट्रैक करता है, जो केवल औसत के बजाय आपके सबसे धीमे उपयोगकर्ताओं
00:01:50के लिए सबसे खराब स्थिति दिखाता है।
00:01:52और यदि आप React का उपयोग नहीं कर रहे हैं, तो इसका यूनिवर्सल मोड Vue, Svelte या वेब
00:01:58कंपोनेंट्स के लिए पूरी तरह से काम करता है।
00:01:59सर्वोत्तम परिणामों के लिए, इस एड-ऑन को Chrome या Edge पर चलाने की सलाह दी जाती है।
00:02:04और उनके पास एक लाइव प्लेबुक भी है जहाँ हम इन मेट्रिक्स को एक्शन में देख सकते हैं।
00:02:08उदाहरण के लिए, एनिमेटेड बॉक्स उदाहरण में, हम ट्रैक कर सकते हैं कि एनिमेशन के दौरान
00:02:13बिल्कुल कितने इनलाइन स्टाइल म्यूटेशन हो रहे हैं।
00:02:16इस मामले में, सब कुछ सही लग रहा है।
00:02:18फ्रेम रेट और फ्रेम टाइम पूरी तरह स्थिर रहता है, जिसका अर्थ है कि ब्राउज़र
00:02:23बिना किसी परेशानी के उन स्टाइल अपडेट्स को संभाल रहा है।
00:02:25हालाँकि, भारी लिस्ट वाला उदाहरण एक अलग कहानी बताता है।
00:02:29जब हम इस बड़ी लिस्ट को फ़िल्टर करते हैं, तो हमें कुछ चेतावनी के संकेत मिलते हैं।
00:02:32सबसे पहले, क्यूम्युलेटिव लेआउट शिफ्ट बहुत अधिक हो जाता है, जो दर्शाता है कि लोड होते समय
00:02:38एलिमेंट्स काफी हिल रहे हैं, जिससे उपयोगकर्ता के लिए अनुभव खराब हो रहा है।
00:02:43हम DOM churn में भी उछाल देखते हैं, जिसका अर्थ है कि ब्राउज़र एक साथ
00:02:49बड़ी संख्या में नोड्स को हटाने और फिर से बनाने के लिए बहुत मेहनत कर रहा है।
00:02:52इसके परिणामस्वरूप फ्रेम भी ड्रॉप होते हैं, जो इंटरफ़ेस की
00:02:57गति और सुगमता के अहसास को खत्म कर देता है।
00:02:58एलिमेंट टाइमिंग उदाहरण में, एलिमेंट टाइमिंग एट्रिब्यूट वाले किसी भी DOM एलिमेंट को
00:03:04उसके सटीक रेंडर टाइम के लिए मापा जाता है।
00:03:06यह अविश्वसनीय रूप से उपयोगी है क्योंकि यह आपको उस सटीक क्षण की पहचान करने में मदद करता है जब आपका
00:03:11मुख्य कंटेंट या कॉल टू एक्शन दिखाई देता है, जिससे आपको सामान्य पेज लोड मेट्रिक्स के बजाय
00:03:17परफॉरमेंस की अधिक सटीक तस्वीर मिलती है।
00:03:21और जब हम एक्सपेंसिव रेंडर उदाहरण को देखते हैं, तो यदि हम री-रेंडर बटन पर क्लिक करते हैं,
00:03:26तो यह P95 ड्यूरेशन को बढ़ा देता है।
00:03:29ऐसा इसलिए होता है क्योंकि भारी जावास्क्रिप्ट निष्पादन के कारण मेन थ्रेड रुका हुआ है,
00:03:34जिससे UI बहुत धीमा महसूस होता है।
00:03:36हम यहाँ फ्रेम जिटर चेतावनियाँ भी देखते हैं, जो अस्थिर रेंडरिंग को दर्शाती हैं जहाँ
00:03:41फ्रेमों के बीच का समय बहुत तेज़ी से बदल रहा है।
00:03:44और यहाँ एक उच्च टोटल ब्लॉकिंग टाइम या TBT भी है।
00:03:47और TBT एक बड़ा चेतावनी संकेत है क्योंकि यह दर्शाता है कि मेन थ्रेड
00:03:52इतनी देर तक ब्लॉक था कि उपयोगकर्ता पेज के साथ इंटरैक्ट नहीं कर पाया,
00:03:57जैसे कि बटन क्लिक करना या स्क्रॉल करना।
00:03:58और हम मेमोइज़ेशन वेस्ट (memoization waste) उदाहरण में भी इसी तरह का विवरण देखते हैं।
00:04:03यहाँ डेमो दिखाता है कि हर एक एलिमेंट को अनावश्यक रूप से फिर से रेंडर करने से
00:04:08भारी लैग होता है।
00:04:09इसके विपरीत, सही ढंग से मेमोइज़ किया गया उदाहरण दिखाता है कि यदि हम अपने
00:04:15कंपोनेंट्स को मेमोइज़ करते हैं तो कितना काम बच जाता है।
00:04:16उन अनावश्यक रेंडर्स को छोड़ कर, हम मेन थ्रेड को खाली रखते हैं और फ्रेम रेट को
00:04:21बनाए रखते हैं ताकि हमें एकदम स्मूथ 60 फ्रेम प्रति सेकंड मिल सके।
00:04:25रेंडर कैस्केड उदाहरण में, हम देखते हैं कि क्या होता है जब आप
00:04:30useLayoutEffect के अंदर setState का उपयोग करते हैं।
00:04:31हर एक इंक्रीमेंट एक कैस्केड शुरू करता है क्योंकि useLayoutEffect सभी DOM म्यूटेशन के बाद
00:04:37सिंक्रोनस रूप से चलता है, लेकिन ब्राउज़र के पेंट करने का मौका मिलने से पहले।
00:04:42इसलिए यहाँ स्टेट अपडेट को ट्रिगर करके, आप React को कंपोनेंट ट्री को दोबारा प्रोसेस करने
00:04:47और ब्राउज़र को लेआउट की गणना दूसरी बार करने के लिए मजबूर कर रहे हैं, इससे पहले कि उपयोगकर्ता को
00:04:52पहला परिणाम भी दिखे।
00:04:53और यह बुरा है क्योंकि प्रभावी रूप से यह हर एक फ्रेम के लिए काम को दोगुना कर देता है,
00:04:58जिससे रेंडर लैग होता है जो सरल इंटरैक्शन को भी भारी बना सकता है।
00:05:02और फिर स्टाइल चर्न (style churn) का उदाहरण भी एक महत्वपूर्ण अवलोकन दिखाता है।
00:05:07क्या होता है जब हम एक साथ 600 अलग-अलग नोड्स के इनलाइन स्टाइल बदलते हैं?
00:05:13हमें तुरंत थ्रैशिंग सेक्शन में स्टॉल वार्निंग्स (stall warnings) दिखाई देती हैं, जो बताती हैं कि
00:05:18ब्राउज़र एक रिफ्लो लूप में फंस गया है।
00:05:21यह एक साथ 600 एलिमेंट्स की पोजीशन की गणना करने की कोशिश कर रहा है जबकि जावास्क्रिप्ट अभी भी
00:05:26बदलाव कर रहा है।
00:05:27इससे हमारे फ्रेम मेट्रिक्स के लिए बहुत खराब स्थिति पैदा होती है क्योंकि मेन थ्रेड
00:05:33पूरी तरह से भर चुका है।
00:05:34तो मुझे उम्मीद है कि ये सभी उदाहरण आपको दिखाते हैं कि आप अधिक सटीक वातावरण में बाधाओं की
00:05:38पहचान करने के लिए इस Storybook एड-ऑन का उपयोग कैसे कर सकते हैं।
00:05:41निश्चित रूप से, आप Lighthouse जैसे टूल का उपयोग कर सकते हैं, लेकिन Lighthouse एक व्यापक टूल है।
00:05:46यह आपको वह सूक्ष्म सटीकता नहीं देता जिससे आप देख सकें कि एक व्यक्तिगत कंपोनेंट
00:05:51आपके ऐप की परफॉरमेंस को कैसे प्रभावित करता है।
00:05:53मैं आपको वास्तव में इस एड-ऑन को डाउनलोड करने, इसे अपने Storybook सुइट में जोड़ने और
00:05:58इसके साथ प्रयोग करने के लिए प्रोत्साहित करता हूँ।
00:05:59एक बार जब आप पूरी तस्वीर देख लेते हैं कि आपके कंपोनेंट्स पर्दे के पीछे वास्तव में कैसे काम करते हैं,
00:06:03तो आपको बहुत सी मूल्यवान जानकारी मिल सकती है।
00:06:06तो दोस्तों, यह था नया GitHub Storybook परफॉरमेंस पैनल एड-ऑन
00:06:10संक्षेप में।
00:06:11आप इसके बारे में क्या सोचते हैं?
00:06:13और आप अपने एप्लिकेशन पर परफॉरमेंस को कैसे मापते हैं?
00:06:16हमें नीचे कमेंट्स में बताएं।
00:06:18और दोस्तों, अगर आपको इस तरह के तकनीकी ब्रेकडाउन पसंद हैं, तो कृपया
00:06:22वीडियो के नीचे लाइक बटन पर क्लिक करके और हमारे चैनल को सब्सक्राइब करके मुझे बताएं।
00:06:28मैं Better Stack से Andres हूँ और मैं आपसे अगले वीडियो में मिलूँगा।