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

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) पर रेंडर कर रहे हैं. साथ ही, हमारे ट्रैक मैनेजर को हर ट्रैक को रेंडर करते समय ट्रांसलेट करना होता है, ताकि यह पक्का किया जा सके कि हर ट्रैक को पिछले ट्रैक के नीचे सही तरीके से रेंडर किया गया है.

ट्रैक और हाइलाइट के लिए, स्क्रीन से बाहर कैनवस

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

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

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

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

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

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