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

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 कैनरी, डेवलपर या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन झलक वाले चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, इनसे आपको वेब प्लैटफ़ॉर्म के सबसे नए एपीआई की जांच करने में मदद मिलती है. इसके अलावा, इनकी मदद से उपयोगकर्ताओं से पहले अपनी साइट की समस्याओं का पता लगाया जा सकता है!

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

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