हमने परफ़ॉर्मेंस के बारे में अहम जानकारी देने वाली अहम जानकारी को कैसे और क्यों बनाया

Jack Franklin

Chrome 102 में, आपको अपने DevTools में परफ़ॉर्मेंस की अहम जानकारी नाम का एक नया पैनल दिखेगा. यह पैनल, एक्सपेरिमेंट के तौर पर उपलब्ध है. इस पोस्ट में, हम न सिर्फ़ इस बारे में बात करेंगे कि हम नए पैनल पर क्यों काम कर रहे हैं, बल्कि हम उन तकनीकी चुनौतियों के बारे में भी बात करेंगे जिनका सामना हमें करना पड़ा. साथ ही, हम इस बारे में भी बात करेंगे कि हमने इस दौरान कौनसे फ़ैसले लिए.

ALT_TEXT_HERE

दूसरा पैनल क्यों बनाएं?

(अगर आपने यह टूल अब तक नहीं देखा है, तो हमने परफ़ॉर्मेंस की अहम जानकारी वाला पैनल बनाने की वजह बताने वाला वीडियो पोस्ट किया है. साथ ही, यह भी बताया है कि इस पैनल की मदद से आपको अपनी वेबसाइट की परफ़ॉर्मेंस के बारे में अहम जानकारी कैसे मिल सकती है.)

अगर आपको अपनी वेबसाइट का पूरा डेटा एक ही जगह पर देखना है, तो मौजूदा परफ़ॉर्मेंस पैनल एक बेहतरीन संसाधन है. हालांकि, हमें लगा कि यह थोड़ा मुश्किल हो सकता है. अगर आप परफ़ॉर्मेंस के विशेषज्ञ नहीं हैं, तो आपके लिए यह जानना मुश्किल है कि किस तरह की रिकॉर्डिंग की जांच करनी चाहिए और रिकॉर्डिंग के कौनसे हिस्से काम के हैं.

अहम जानकारी वाले पैनल में जाएं. यहां अब भी अपने ट्रेस की टाइमलाइन देखी जा सकती है और डेटा की जांच की जा सकती है. साथ ही, आपको एक आसान सूची भी मिलेगी, जिसमें DevTools के हिसाब से मुख्य “अहम जानकारी” शामिल होती है. अहम जानकारी से, रेंडर ब्लॉकिंग अनुरोध, लेआउट में बदलाव, और लंबे टास्क जैसी समस्याओं की पहचान की जा सकती है. इन सभी समस्याओं से आपकी वेबसाइट के पेज लोड होने की परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. खास तौर पर, आपकी साइट के कोर वेब विटल (CWV) स्कोर पर असर पड़ सकता है. समस्याओं को फ़्लैग करने के साथ-साथ, परफ़ॉर्मेंस की अहम जानकारी से आपको सीडब्ल्यूवी स्कोर को बेहतर बनाने के लिए, काम के सुझाव मिलेंगे. साथ ही, आपको अन्य रिसॉर्स और दस्तावेज़ों के लिंक भी मिलेंगे.

पैनल में सुझाव, शिकायत या राय देने के लिए लिंक

यह पैनल एक्सपेरिमेंट के तौर पर उपलब्ध है और हमें आपके सुझाव, शिकायत या राय चाहिए! अगर आपको कोई गड़बड़ी मिलती है या आपके पास सुविधा के ऐसे अनुरोध हैं जो आपके हिसाब से, साइट की परफ़ॉर्मेंस को बेहतर बनाने में आपकी मदद करेंगे, तो कृपया हमें बताएं.

हमने परफ़ॉर्मेंस के बारे में अहम जानकारी देने वाली सुविधा को कैसे बनाया

बाकी DevTools की तरह, हमने TypeScript में परफ़ॉर्मेंस की अहम जानकारी बनाई है. साथ ही, यूज़र इंटरफ़ेस बनाने के लिए वेब कॉम्पोनेंट का इस्तेमाल किया है. ये कॉम्पोनेंट lit-html पर आधारित हैं. परफ़ॉर्मेंस की अहम जानकारी में, प्राइमरी यूज़र इंटरफ़ेस (यूआई) इंटरफ़ेस एचटीएमएल canvas एलिमेंट होता है. साथ ही, टाइमलाइन इस कैनवस पर बनाई जाती है. इस कैनवस को मैनेज करने में काफ़ी मुश्किल आती है: इसमें सही जगह पर सही जानकारी ड्रॉ करने के साथ-साथ, माउस इवेंट मैनेज करना भी शामिल है. उदाहरण के लिए: उपयोगकर्ता ने कैनवस पर कहां क्लिक किया? क्या उन्होंने हमारे बनाए गए किसी इवेंट पर क्लिक किया है?). साथ ही, यह पक्का करें कि हम कैनवस को असरदार तरीके से फिर से रेंडर करें.

एक ही कैनवस पर कई ट्रैक

किसी वेबसाइट के लिए, ऐसे कई “ट्रैक” हैं जिन्हें हमें रेंडर करना है. हर ट्रैक, डेटा की अलग-अलग कैटगरी को दिखाता है. उदाहरण के लिए, अहम जानकारी वाले पैनल में डिफ़ॉल्ट रूप से तीन ट्रैक दिखेंगे:

हम इस पैनल में और भी सुविधाएं जोड़ते रहेंगे. साथ ही, इसमें और भी ट्रैक जोड़े जाएंगे.

शुरुआती तौर पर हमने सोचा था कि इनमें से हर ट्रैक का अपना <canvas> रेंडर हो, ताकि मुख्य व्यू, वर्टिकल तौर पर स्टैक किए गए एक से ज़्यादा कैनवस एलिमेंट बन जाए. इससे ट्रैक लेवल पर रेंडरिंग आसान हो जाएगी, क्योंकि हर ट्रैक को अलग से रेंडर किया जा सकता है. साथ ही, ट्रैक के अपने दायरे से बाहर रेंडर होने का कोई खतरा नहीं होगा. हालांकि, इस तरीके में दो बड़ी समस्याएं हैं:

canvas एलिमेंट को (फिर से) रेंडर करने में ज़्यादा समय लगता है. एक कैनवस की तुलना में, एक से ज़्यादा कैनवस का इस्तेमाल करना ज़्यादा महंगा होता है. भले ही, वह कैनवस बड़ा हो. एक से ज़्यादा ट्रैक पर दिखने वाले ओवरले (उदाहरण के लिए, एफ़सीपी समय जैसे इवेंट को मार्क करने के लिए वर्टिकल लाइनें) को रेंडर करना मुश्किल हो जाता है: हमें कई कैनवस पर रेंडर करना होता है और यह पक्का करना होता है कि वे सभी एक साथ रेंडर हों और सही तरीके से अलाइन हों.

पूरे यूज़र इंटरफ़ेस (यूआई) के लिए एक canvas का इस्तेमाल करने का मतलब है कि हमें यह पक्का करना था कि हर ट्रैक सही निर्देशांक पर रेंडर हो और किसी दूसरे ट्रैक में ओवरफ़्लो न हो. उदाहरण के लिए, अगर कोई ट्रैक 100 पिक्सल ऊंचा है, तो हम उसे 120 पिक्सल ऊंचाई वाली किसी चीज़ को रेंडर करने और उसे उसके नीचे वाले ट्रैक में भेजने की अनुमति नहीं दे सकते. इस समस्या को हल करने के लिए, हम 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) पर रेंडर कर रहे हों. साथ ही, ट्रैक मैनेजर को हर ट्रैक को रेंडर करते समय अनुवाद करने के लिए कहा जाता है, ताकि यह पक्का किया जा सके कि हर ट्रैक को पिछले ट्रैक के नीचे सही तरीके से रेंडर किया गया हो.

ट्रैक और हाइलाइट के लिए, ऑफ़-स्क्रीन कैनवस

कैनवस रेंडरिंग काफ़ी महंगी होती है. साथ ही, हम यह पक्का करना चाहते हैं कि जब आप इसके साथ काम करें, तो इनसाइट पैनल बिना किसी रुकावट के काम करे. कभी-कभी पूरे कैनवस को फिर से रेंडर करना पड़ता है. उदाहरण के लिए, ज़ूम लेवल बदलने पर, हमें फिर से शुरू करके सब कुछ फिर से रेंडर करना पड़ता है. कैनवस को फिर से रेंडर करने की प्रोसेस काफ़ी महंगी है. ऐसा इसलिए, क्योंकि सिर्फ़ इसके एक छोटे हिस्से को ही फिर से रेंडर नहीं किया जा सकता. आपको पूरे कैनवस को वाइप करके फिर से रेंडर करना होगा. यह डीओएम को फिर से रेंडर करने के तरीके से अलग है. इस तरीके में, टूल कम से कम काम का हिसाब लगा सकते हैं. साथ ही, वे सब कुछ हटाकर फिर से शुरू नहीं करते.

एक तरफ़ जहां हमने विज़ुअल से जुड़ी समस्याएं थीं उसे हाइलाइट किया. पैनल में मेट्रिक पर कर्सर घुमाने पर, हम उन्हें टाइमलाइन पर हाइलाइट करते हैं. इसी तरह, किसी इवेंट की अहम जानकारी पर कर्सर घुमाने पर, हम उस इवेंट के चारों ओर नीले रंग का बॉर्डर बना देते हैं.

इस सुविधा को सबसे पहले, किसी एलिमेंट पर माउस घुमाने से हाइलाइट होने की सुविधा के तौर पर लागू किया गया था. इसके बाद, उस हाइलाइट को सीधे मुख्य कैनवस पर ड्रॉ किया गया था. हाइलाइट हटाने में हमें समस्या आती है: इसके लिए, हमें सब कुछ फिर से ड्रॉ करना पड़ता है! हाइलाइट किए गए हिस्से को फिर से ड्रॉ करना मुश्किल है. इसके लिए, आर्किटेक्चर में बड़े बदलाव करने पड़ते हैं. हालांकि, सिर्फ़ एक आइटम के चारों ओर मौजूद नीले बॉर्डर को हटाने के लिए, पूरे कैनवस को फिर से ड्रॉ करना ज़रूरी नहीं है. अगर आपने एक के बाद एक कई हाइलाइट ट्रिगर करने के लिए, अलग-अलग आइटम पर तेज़ी से कर्सर घुमाया है, तो यह विज़ुअल तौर पर भी देरी से दिख सकता है.

इस समस्या को ठीक करने के लिए, हमने अपने यूज़र इंटरफ़ेस (यूआई) को दो ऑफ़-स्क्रीन कैनवस में बांटा है: “मुख्य” कैनवस, जहां ट्रैक रेंडर होते हैं और “हाइलाइट” कैनवस, जहां हाइलाइट बनाई जाती हैं. इसके बाद, हम उन कैनवस को उस एक कैनवस पर कॉपी करके रेंडर करते हैं जो उपयोगकर्ता को स्क्रीन पर दिखता है. हम कैनवस कॉन्टेक्स्ट पर drawImage तरीके का इस्तेमाल कर सकते हैं. यह तरीका, किसी दूसरे कैनवस को सोर्स के तौर पर इस्तेमाल कर सकता है.

ऐसा करने का मतलब है कि हाइलाइट हटाने पर, मुख्य कैनवस फिर से नहीं बनता: इसके बजाय, हम स्क्रीन पर मौजूद कैनवस को मिटा सकते हैं और फिर मुख्य कैनवस को दिख रहे कैनवस पर कॉपी कर सकते हैं. कैनवस को कॉपी करने का काम सस्ता होता है और इसकी ड्रॉइंग महंगी होती है. इसलिए, हाइलाइट को किसी अलग कैनवस पर ट्रांसफ़र करने से, हम हाइलाइट को चालू या बंद करने के दौरान उस शुल्क से बच जाते हैं.

पूरी तरह से जांची गई ट्रेस पार्सिंग

नई सुविधा को शुरू से बनाने का एक फ़ायदा यह है कि आपके पास पहले से किए गए तकनीकी विकल्पों को देखने और उनमें सुधार करने का विकल्प होता है. हम अपने कोड को दो हिस्सों में बांटना चाहते थे, ताकि उसे बेहतर बनाया जा सके. ये दो हिस्से पूरी तरह से अलग-अलग थे:

ट्रेस फ़ाइल को पार्स करें और ज़रूरी डेटा निकालें. ट्रैक का सेट रेंडर करना.

पार्सिंग (पहला चरण) को यूज़र इंटरफ़ेस (दूसरा चरण) से अलग रखने से, हमें पार्सिंग का एक बेहतर सिस्टम बनाने में मदद मिली. हर ट्रेस को हैंडलर की एक सीरीज़ के ज़रिए चलाया जाता है, जो अलग-अलग समस्याओं के लिए ज़िम्मेदार होते हैं: LayoutShiftHandler, लेआउट शिफ़्ट के लिए ज़रूरी सभी जानकारी का हिसाब लगाता है और NetworkRequestsHandler, नेटवर्क अनुरोधों को खींचने के लिए खास तौर पर काम करता है. पार्स करने के इस चरण में, ट्रेस के अलग-अलग हिस्सों के लिए अलग-अलग हैंडलर होने से भी फ़ायदा हुआ है: ट्रेस पार्स करना बहुत मुश्किल हो सकता है. इससे एक बार में एक समस्या पर फ़ोकस करने में मदद मिलती है.

हमने DevTools में रिकॉर्डिंग करके, उन्हें सेव करके, और फिर अपने टेस्ट सुइट के हिस्से के तौर पर लोड करके, अपने ट्रेस पार्सिंग की पूरी तरह से जांच की है. यह बहुत अच्छा है, क्योंकि हम असल ट्रेस की मदद से जांच कर सकते हैं. साथ ही, नकली ट्रेस का बहुत ज़्यादा डेटा इकट्ठा नहीं करना पड़ता, जो पुराना हो सकता है.

कैनवस यूज़र इंटरफ़ेस (यूआई) के लिए स्क्रीनशॉट की जांच

टेस्टिंग के विषय को ध्यान में रखते हुए, हम आम तौर पर अपने फ़्रंटएंड कॉम्पोनेंट को ब्राउज़र में रेंडर करके और यह पक्का करके उनकी जांच करते हैं कि वे उम्मीद के मुताबिक काम करें. हम अपडेट ट्रिगर करने के लिए, क्लिक इवेंट भेज सकते हैं. साथ ही, यह दावा कर सकते हैं कि कॉम्पोनेंट से जनरेट किया गया डीओएम सही है. यह तरीका हमारे लिए कारगर साबित होता है, लेकिन किसी कैनवस को रेंडर करने के बारे में सोच-विचार करते समय यह कम हो जाता है. कैनवस की जांच करके यह तय करने का कोई तरीका नहीं है कि उसमें क्या बनाया गया है! इसलिए, रेंडर करने और फिर क्वेरी करने का हमारा सामान्य तरीका सही नहीं है.

हमने स्क्रीनशॉट टेस्टिंग का इस्तेमाल करके, कुछ टेस्ट कवरेज हासिल की. हर टेस्ट एक कैनवस शुरू करता है, उस ट्रैक को रेंडर करता है जिसकी हमें जांच करनी है. इसके बाद, वह कैनवस एलिमेंट का स्क्रीनशॉट लेता है. इसके बाद, इस स्क्रीनशॉट को हमारे कोडबेस में सेव कर दिया जाता है. आने वाले समय में होने वाली टेस्ट रन में, सेव किए गए स्क्रीनशॉट की तुलना जनरेट किए गए स्क्रीनशॉट से की जाएगी. अगर स्क्रीनशॉट अलग-अलग हैं, तो जांच पूरी नहीं होगी. हम टेस्ट चलाने के लिए एक फ़्लैग भी देते हैं. साथ ही, जब हम जान-बूझकर रेंडरिंग में बदलाव करते हैं और टेस्ट को अपडेट करना होता है, तब हम स्क्रीनशॉट को अपडेट करने के लिए भी फ़्लैग देते हैं.

स्क्रीनशॉट टेस्ट पूरी तरह से सही नहीं होते और इनमें ज़्यादा जानकारी नहीं मिलती. इनसे सिर्फ़ यह पता चलता है कि पूरा कॉम्पोनेंट उम्मीद के मुताबिक रेंडर हो रहा है या नहीं. शुरुआत में, हमने हर कॉम्पोनेंट (एचटीएमएल या कैनवस) के सही तरीके से रेंडर होने की पुष्टि करने के लिए, इनका ज़्यादा इस्तेमाल किया था. इस वजह से, हमारे टेस्ट सुइट की परफ़ॉर्मेंस काफ़ी खराब हो गई. साथ ही, यूज़र इंटरफ़ेस (यूआई) में छोटे-मोटे बदलाव करने पर, कई स्क्रीनशॉट लेने में समस्याएं आ रही थीं. जैसे, रंग में थोड़ा बदलाव करना या आइटम के बीच कुछ मार्जिन जोड़ना. इन बदलावों की वजह से, स्क्रीनशॉट लेने की प्रोसेस को अपडेट करना पड़ता था. हमने अब स्क्रीनशॉट के इस्तेमाल को कम कर दिया है और उनका इस्तेमाल सिर्फ़ कैनवस पर आधारित कॉम्पोनेंट के लिए किया है. अब तक, यह संतुलन हमारे लिए अच्छा रहा है.

नतीजा

परफ़ॉर्मेंस के बारे में अहम जानकारी देने वाला नया पैनल बनाना, टीम के लिए बहुत ही मज़ेदार और शिक्षाप्रद अनुभव रहा. हमने ट्रेस फ़ाइलों, कैनवस के साथ काम करने वगैरह के बारे में काफ़ी कुछ सीखा है. हमें उम्मीद है कि आपको नए पैनल का इस्तेमाल करने में मज़ा आ रहा होगा. हमें आपके सुझाव, राय या शिकायत का इंतज़ार रहेगा.

परफ़ॉर्मेंस की अहम जानकारी वाले पैनल के बारे में ज़्यादा जानने के लिए, परफ़ॉर्मेंस की अहम जानकारी: अपनी वेबसाइट की परफ़ॉर्मेंस के बारे में अहम जानकारी पाना लेख पढ़ें.

झलक वाले चैनल डाउनलोड करना

Chrome Canary, Dev या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. झलक दिखाने वाले इन चैनलों की मदद से, DevTools की नई सुविधाओं को ऐक्सेस किया जा सकता है. साथ ही, वेब प्लैटफ़ॉर्म के आधुनिक एपीआई को आज़माया जा सकता है. साथ ही, उपयोगकर्ताओं के उपलब्ध होने से पहले, अपनी साइट की समस्याओं का पता लगाया जा सकता है!

Chrome DevTools की टीम से संपर्क करना

DevTools से जुड़ी नई सुविधाओं, अपडेट या किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, यहां दिए गए विकल्पों का इस्तेमाल करें.