Chrome 102 में आपको अपने DevTools में परफ़ॉर्मेंस की अहम जानकारी नाम का एक नया प्रयोग वाला पैनल दिखेगा. इस पोस्ट में हम न सिर्फ़ इस बात पर चर्चा करेंगे कि हम एक नए पैनल पर काम क्यों कर रहे हैं, बल्कि उन तकनीकी चुनौतियों पर भी चर्चा करेंगे जो हमारे सामने आई थीं और इस दौरान हमने जो फ़ैसले लिए थे.
दूसरा पैनल क्यों बनाएं?
अगर आपने अब तक परफ़ॉर्मेंस की अहम जानकारी वाला पैनल नहीं देखा है, तो हमने एक वीडियो पोस्ट किया है. इसमें बताया गया है कि आपको परफ़ॉर्मेंस की अहम जानकारी वाला पैनल क्यों बनाना चाहिए और इसकी मदद से अपनी वेबसाइट की परफ़ॉर्मेंस के बारे में अहम जानकारी कैसे मिल सकती है.
अगर आपको अपनी वेबसाइट का पूरा डेटा एक ही जगह पर देखना है, तो मौजूदा परफ़ॉर्मेंस पैनल एक बेहतरीन संसाधन है, लेकिन हमें लगता है कि इससे आपको थोड़ी परेशानी हो सकती है. अगर आप परफ़ॉर्मेंस के विशेषज्ञ नहीं हैं, तो यह जानना बहुत मुश्किल है कि असल में क्या देखना है और रिकॉर्डिंग के कौनसे हिस्से काम के हैं.
इनसाइट पैनल में जाएं. यहां आपको अब भी अपने ट्रेस की टाइमलाइन दिखेगी और डेटा की जांच होगी. साथ ही, आपको उन चीज़ों की एक सूची भी मिलेगी जिन्हें DevTools के ज़रिए मुख्य “इनसाइट” के तौर पर देखा जा सकता है. इनसाइट में, रेंडर करने के अनुरोध, लेआउट शिफ़्ट, और लंबे टास्क जैसी समस्याओं की पहचान की जाएगी. इनसे आपकी वेबसाइट के पेज लोड होने की परफ़ॉर्मेंस और खास तौर पर, आपकी साइट के वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी (सीडब्ल्यूवी) के स्कोर पर बुरा असर पड़ सकता है. समस्याओं को फ़्लैग करने के साथ ही, परफ़ॉर्मेंस की अहम जानकारी से आपको ऐसे सुझाव मिलेंगे जिनका इस्तेमाल करके, CWV स्कोर को बेहतर बनाया जा सकता है. साथ ही, अन्य संसाधनों और दस्तावेज़ के लिंक भी मिलेंगे.
इस पैनल पर प्रयोग जारी है और हम इसके बारे में आपके सुझाव चाहते हैं! अगर आपको कोई गड़बड़ी मिलती है या आपको किसी सुविधा का अनुरोध मिलता है, तो कृपया हमें बताएं. इन अनुरोधों से साइट की परफ़ॉर्मेंस को बेहतर बनाने में मदद मिलेगी.
हमने परफ़ॉर्मेंस के बारे में अहम जानकारी कैसे बनाई
अन्य DevTools की तरह ही, हमने TypeScript में परफ़ॉर्मेंस इनसाइट बनाई. साथ ही, यूज़र इंटरफ़ेस बनाने के लिए, lit-html का इस्तेमाल करके वेब कॉम्पोनेंट का इस्तेमाल किया. जहां परफ़ॉर्मेंस के बारे में अहम जानकारी में अंतर होता है, वह यह है कि प्राइमरी यूज़र इंटरफ़ेस (यूआई) इंटरफ़ेस, एचटीएमएल canvas एलिमेंट होता है और टाइमलाइन इस कैनवस पर खींची जाती है. इस कैनवस को मैनेज करने में कई समस्याएं आती हैं: न सिर्फ़ सही जगह पर सही जानकारी बनाना, बल्कि माउस इवेंट को मैनेज करना (उदाहरण के लिए: उपयोगकर्ता ने कैनवस पर कहां क्लिक किया? क्या उन्होंने हमारे बनाए हुए इवेंट पर क्लिक किया?) इससे यह पक्का होता है कि हमने कैनवस को सही तरीके से फिर से रेंडर किया है.
एक कैनवस पर कई ट्रैक
किसी वेबसाइट के लिए, हम कई “ट्रैक” बनाना चाहते हैं. हर ट्रैक, डेटा की अलग कैटगरी को दिखाता है. उदाहरण के लिए, इनसाइट पैनल में डिफ़ॉल्ट रूप से तीन ट्रैक दिखेंगे:
जैसे-जैसे हम पैनल में नई-नई सुविधाएं जोड़ रहे हैं, हमें उम्मीद है कि इसमें और ट्रैक जोड़े जाएंगे.
हमारा शुरुआती ख्याल था, इनमें से हर ट्रैक को अपने हिसाब से <canvas> रेंडर करना था, ताकि मुख्य व्यू, वर्टिकल तौर पर स्टैक किए गए कई कैनवस एलिमेंट में बदल जाए. इससे ट्रैक लेवल पर रेंडरिंग आसान हो जाएगी, क्योंकि हर ट्रैक अलग-अलग रेंडर हो सकता है और ट्रैक की सीमा से बाहर रेंडर होने का कोई खतरा नहीं होता. हालांकि, इस तरीके में दो बड़ी समस्याएं हैं:
canvas एलिमेंट को रेंडर करना (फिर से) महंगा होता है. एक से ज़्यादा कैनवस होने पर, एक कैनवस के मुकाबले ज़्यादा खर्च होता है, भले ही वह कैनवस बड़ा हो.
कई ट्रैक पर जाने वाले ओवरले (उदाहरण के लिए, एफ़सीपी टाइम जैसे इवेंट मार्क करने के लिए वर्टिकल लाइनें) को रेंडर करना मुश्किल हो जाता है: हमें कई कैनवस पर रेंडर करना होता है. साथ ही, यह पक्का करना होता है कि वे सभी एक साथ रेंडर हों और सही तरीके से अलाइन हों.
पूरे यूज़र इंटरफ़ेस (यूआई) के लिए एक canvas का इस्तेमाल करने का मतलब था कि हमें यह पता लगाना था कि यह कैसे पक्का किया जाए कि हर ट्रैक सही निर्देशांक पर रेंडर हो और दूसरे ट्रैक में ओवरफ़्लो न हो. उदाहरण के लिए, अगर किसी ट्रैक की ऊंचाई 100 पिक्सल है, तो हम 120 पिक्सल ऊंची किसी चीज़ को रेंडर करने की अनुमति नहीं दे सकते. साथ ही, हम उसे 120 पिक्सल ऊंची किसी चीज़ को रेंडर करने की अनुमति भी नहीं दे सकते. ऐसा इसलिए है, क्योंकि हम उसे 100 पिक्सल ऊंचे ट्रैक से नीचे वाले ट्रैक में ले जाते हैं. इस समस्या को हल करने के लिए, हम clip का इस्तेमाल कर सकते हैं. हर ट्रैक को रेंडर करने से पहले, हम दिखने वाली ट्रैक विंडो को दिखाने वाला एक रेक्टैंगल बनाते हैं. इससे यह पक्का होता है कि इन सीमाओं के बाहर बनाए गए किसी भी पाथ को कैनवस की मदद से क्लिप किया जाएगा.
canvasContext.beginPath();
canvasContext.rect(
trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();
हम यह भी नहीं चाहते थे कि हर ट्रैक को उसकी जगह की जानकारी वर्टिकल तौर पर मिले: हर ट्रैक को उसी तरह रेंडर होना चाहिए जैसे वह (0, 0) पर रेंडर हो रहा हो. साथ ही, हमारे पास ट्रैक की पूरी पोज़िशन को मैनेज करने के लिए, एक बड़े लेवल का कॉम्पोनेंट (जिसे हम TrackManager कहते हैं) भी मौजूद होना चाहिए. ऐसा translate की मदद से किया जा सकता है, जो दी गई (x, y) स्थिति के हिसाब से कैनवस का अनुवाद करता है. उदाहरण के लिए:
canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide
rect कोड सेटिंग 0, 0 को जगह के तौर पर सेट करने के बावजूद, पूरे अनुवाद को लागू करने पर, आयत की इमेज 0, 10 पर रेंडर होगी. इससे हम ट्रैक के आधार पर काम कर पाते हैं, जैसे कि हम (0, 0) पर रेंडर कर रहे हों. साथ ही, हमारे ट्रैक मैनेजर को अनुवाद करने की सुविधा मिलती है, क्योंकि यह हर ट्रैक को रेंडर करता है. इससे यह पक्का होता है कि हर ट्रैक को पिछले ट्रैक के नीचे सही तरीके से रेंडर किया गया है.
ट्रैक और हाइलाइट के लिए ऑफ़-स्क्रीन कैनवस
कैनवस रेंडरिंग में आम तौर पर लगने वाला खर्च ज़्यादा होता है. इसलिए, हम यह पक्का करना चाहते हैं कि इनसाइट पैनल बिना किसी रुकावट के काम करे और आप इसके साथ काम करें. कभी-कभी पूरे कैनवस को फिर से रेंडर करने की ज़रूरत नहीं पड़ती. उदाहरण के लिए, अगर ज़ूम लेवल बदला जाता है, तो हमें फिर से शुरू करना होगा और सारा कॉन्टेंट फिर से रेंडर करना होगा. कैनवस री-रेंडरिंग खास तौर पर महंगा होता है, क्योंकि इसमें सिर्फ़ उसका एक छोटा सा हिस्सा ही रेंडर नहीं होता. आपको पूरे कैनवस को वाइप करके फिर से रेंडर करना होगा. यह DOM री-रेंडरिंग से अलग होता है, जहां टूल ज़रूरत के हिसाब से कम से कम काम का हिसाब लगा सकते हैं. साथ ही, सब कुछ हटाकर फिर से शुरू कर सकते हैं.
हमें विज़ुअल से जुड़ी समस्याओं का एक हिस्सा हाइलाइट करना था. पैनल में मेट्रिक पर कर्सर घुमाने पर, हम उन्हें टाइमलाइन पर हाइलाइट करते हैं. इसी तरह, किसी इवेंट की अहम जानकारी पर कर्सर घुमाने पर, हम उस इवेंट के चारों ओर नीले रंग का बॉर्डर बनाते हैं.
इस सुविधा को लागू करने के लिए, सबसे पहले हाइलाइट को ट्रिगर करने वाले किसी एलिमेंट पर माउस की गतिविधि का पता लगाया गया था. इसके बाद, हाइलाइट किए गए एलिमेंट को सीधे मुख्य कैनवस पर बनाया गया था. हमारी समस्या तब आती है, जब हमें हाइलाइट हटानी पड़ती है: हर चीज़ को फिर से ड्राफ़्ट करना ही एक विकल्प होता है! इमारत के उस हिस्से को फिर से तैयार करना नामुमकिन है जहां हाइलाइट में बहुत बड़े बदलाव किए बिना नहीं, बल्कि पूरे कैनवस को सिर्फ़ इसलिए बनाया जा रहा है, क्योंकि हमें किसी चीज़ के चारों ओर से एक नीले बॉर्डर को हटाने के लिए, उसे ज़रूरत से ज़्यादा खर्च करना पड़ता है. अगर अलग-अलग आइटम पर तेज़ी से कर्सर घुमाया जाता है, तो एक के बाद एक कई आइटम हाइलाइट हो जाते हैं. इससे, स्क्रीन पर दिखने में भी समय लगता है.
इसे ठीक करने के लिए, हमने अपने यूज़र इंटरफ़ेस (यूआई) को दो ऑफ़-स्क्रीन कैनवस में बांट दिया: “मुख्य” कैनवस, जहां ट्रैक रेंडर होते हैं और “हाइलाइट” कैनवस, जहां हाइलाइट ड्रॉ की जाती हैं. इसके बाद हम उन कैनवस को स्क्रीन पर दिखने वाले कैनवस पर कॉपी करके, इमेज बनाते हैं. हम drawImage तरीके का इस्तेमाल कैनवस कॉन्टेक्स्ट पर कर सकते हैं. यह किसी दूसरे कैनवस को भी अपने सोर्स के तौर पर इस्तेमाल कर सकता है.
ऐसा करने का मतलब है कि हाइलाइट हटाने से मुख्य कैनवस फिर से नहीं बनता: इसके बजाय, हम स्क्रीन पर दिख रहे कैनवस को साफ़ कर सकते हैं. इसके बाद, मुख्य कैनवस को कॉपी करके, दिखने वाले कैनवस पर रखते हैं. कैनवस कॉपी करने का काम सस्ता होता है, ड्रॉइंग बहुत महंगी होती है, इसलिए किसी अलग कैनवस पर हाइलाइट को ले जाने से, हम हाइलाइट को चालू और बंद करने में उस खर्च से बचते हैं.
बेहतर तरीके से टेस्ट किया गया ट्रेस पार्स करना
शुरुआत से एक नई सुविधा बनाने का एक फ़ायदा यह भी है कि आप पहले चुने गए तकनीकी विकल्पों को ध्यान में रखकर उन्हें बेहतर बना सकते हैं. हमें अपने कोड को दो हिस्सों में बांटने की ज़रूरत थी, जिनमें से एक को हम बेहतर बनाना चाहते थे:
ट्रेस फ़ाइल को पार्स करें और ज़रूरी डेटा बाहर निकालें. ट्रैक का एक सेट रेंडर करें.
पार्स करने (भाग 1) को यूज़र इंटरफ़ेस (यूआई) के काम से अलग रखने से (भाग 2) हमें एक ठोस पार्स करने वाला सिस्टम बनाने में मदद मिली; हर ट्रेस हैंडलर की एक सीरीज़ के ज़रिए चलता है, जो अलग-अलग समस्याओं के लिए ज़िम्मेदार है: LayoutShiftHandler, लेआउट शिफ़्ट के लिए ज़रूरी सभी जानकारी की गणना करता है और NetworkRequestsHandler खास तौर से नेटवर्क अनुरोधों को हल करने के काम करता है. पार्स करने के इस साफ़ तौर पर चरण को पूरा करना, हमारे पास ट्रेस के अलग-अलग हिस्सों के लिए अलग-अलग हैंडलर हैं. यह भी फ़ायदेमंद है: ट्रेस पार्स करने की प्रक्रिया बहुत मुश्किल हो सकती है. साथ ही, इससे एक समय में एक ही चिंता पर फ़ोकस करने में मदद मिलती है.
हम DevTools में रिकॉर्डिंग लेकर, सेव किए गए और फिर अपने टेस्ट सुइट के हिस्से के तौर पर लोड करके, ट्रेस पार्स करने की हमारी सुविधा को बेहतर तरीके से टेस्ट कर पाए हैं. यह बहुत अच्छी बात है, क्योंकि हम असली ट्रेस की मदद से जांच कर सकते हैं, न कि बहुत ज़्यादा नकली ट्रेस डेटा, जो पुराना हो सकता है.
कैनवस यूज़र इंटरफ़ेस (यूआई) के लिए स्क्रीनशॉट टेस्टिंग
टेस्टिंग के विषय पर बात करते हुए, हम आम तौर पर अपने फ़्रंटएंड कॉम्पोनेंट को ब्राउज़र में रेंडर करके और यह पक्का करके उनकी जांच करते हैं कि वे उम्मीद के मुताबिक काम कर रहे हैं. हम अपडेट ट्रिगर करने के लिए क्लिक इवेंट भेज सकते हैं और यह पुष्टि करते हैं कि कॉम्पोनेंट से जनरेट किया गया DOM सही है. यह तरीका हमारे लिए सबसे अच्छा काम करता है, लेकिन कैनवस पर रेंडर करते समय कम हो जाता है. किसी कैनवस की जांच करने और उस पर बने कॉन्टेंट को तय करने का कोई तरीका नहीं है! इसलिए, रेंडरिंग और फिर क्वेरी करने का हमारा सामान्य तरीका सही नहीं है.
कुछ टेस्ट कवरेज देने के लिए, हमने स्क्रीनशॉट टेस्टिंग का विकल्प चुना. हर टेस्ट एक कैनवस को ट्रिगर करता है, उस ट्रैक को रेंडर करता है जिसकी हमें जांच करनी है. इसके बाद, वह कैनवस एलिमेंट का स्क्रीनशॉट लेता है. इसके बाद, यह स्क्रीनशॉट हमारे कोड बेस में सेव हो जाता है. आगे के टेस्ट में, सेव किए गए स्क्रीनशॉट की तुलना, उससे जनरेट किए गए स्क्रीनशॉट से की जाएगी. अगर दोनों स्क्रीनशॉट अलग-अलग हैं, तो जांच नहीं हो पाएगी. हम जांच करने के लिए फ़्लैग भी उपलब्ध कराते हैं. साथ ही, जब हम जान-बूझकर रेंडरिंग में बदलाव कर देते हैं और टेस्ट को अपडेट करने की ज़रूरत होती है, तब हम स्क्रीनशॉट अपडेट करने के लिए भी तैयार होते हैं.
स्क्रीनशॉट टेस्ट सटीक नहीं होते और थोड़े मुश्किल होते हैं; ज़्यादा खास दावों के बजाय, सिर्फ़ यह जांच कर सकते हैं कि पूरा कॉम्पोनेंट, उम्मीद के मुताबिक रेंडर कर रहा है या नहीं. शुरुआत में, इन सभी कॉम्पोनेंट का ज़रूरत से ज़्यादा इस्तेमाल करना हमारी ज़िम्मेदारी थी, ताकि हर कॉम्पोनेंट (एचटीएमएल या कैनवस) को सही तरीके से रेंडर किया जा सके. इससे हमारा टेस्ट सुइट काफ़ी धीमा हो गया और यूज़र इंटरफ़ेस (यूआई) में छोटे-मोटे और ग़ैर-ज़रूरी ट्वीक (जैसे, रंग में छोटे-मोटे बदलाव करना या आइटम के बीच कुछ मार्जिन जोड़ना) की वजह से कई स्क्रीनशॉट काम नहीं कर पाए और उन्हें अपडेट करना पड़ा. हमने अब स्क्रीनशॉट का इस्तेमाल कम कर दिया है और उनका इस्तेमाल सिर्फ़ कैनवस आधारित कॉम्पोनेंट के लिए किया जाता है. इससे हमें यह संतुलन बनाने में मदद मिली.
नतीजा
परफ़ॉर्मेंस की अहम जानकारी वाला नया पैनल बनाना, टीम के लिए बेहद मज़ेदार और जानकारी देने वाला अनुभव रहा है. हमने ट्रेस फ़ाइलों, कैनवस के साथ काम करने वगैरह के बारे में बहुत कुछ सीखा है. हमें उम्मीद है कि आपको नए पैनल का इस्तेमाल करना पसंद आएगा. हमें इस बारे में आपकी राय जानने का इंतज़ार रहेगा.
परफ़ॉर्मेंस की अहम जानकारी वाले पैनल के बारे में ज़्यादा जानने के लिए, परफ़ॉर्मेंस की अहम जानकारी: अपनी वेबसाइट की परफ़ॉर्मेंस के बारे में अहम जानकारी पाना लेख पढ़ें.
झलक दिखाने वाले चैनलों को डाउनलोड करें
अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर, Chrome के कैनरी, डेव या बीटा वर्शन का इस्तेमाल करें. झलक दिखाने वाले इन चैनलों से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, सबसे नए वेब प्लैटफ़ॉर्म एपीआई टेस्ट करने और उपयोगकर्ताओं के ऐसा करने से पहले ही, अपनी साइट पर समस्याओं का पता लगाने में मदद मिलती है!
Chrome DevTools टीम से संपर्क करना
पोस्ट में मौजूद नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी अन्य चीज़ के बारे में बताने के लिए, नीचे दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com के ज़रिए हमें कोई सुझाव या सुझाव सबमिट करें.
- DevTools में ज़्यादा विकल्प
> सहायता > DevTools से जुड़ी समस्याओं की शिकायत करें पर जाकर, DevTools से जुड़ी समस्या की शिकायत करें. - @ChromeDevTool पर ट्वीट करें.
- DevTools YouTube वीडियो या DevTools सलाह वाले YouTube वीडियो में नया क्या है, इस बारे में टिप्पणियां करें.