Angular ऐप्लिकेशन की प्रोफ़ाइल बनाने के लिए, Chrome DevTools के परफ़ॉर्मेंस पैनल का इस्तेमाल करना

Andrés Olivares

Pawel Kozlowski

Angular, React, Vue, और Svelte जैसे वेब फ़्रेमवर्क की मदद से, बड़े पैमाने पर मुश्किल वेब ऐप्लिकेशन को लिखना और बनाए रखना आसान हो जाता है.

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

उदाहरण के लिए, DevTools में Performance पैनल की मदद से, Angular ऐप्लिकेशन की प्रोफ़ाइल बनाते समय आपको यह दिखेगा:

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

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

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

इस वजह से, हमने Angular टीम के साथ मिलकर काम किया. इससे, Performance panel Extensibility API का इस्तेमाल करके, Angular के रनटाइम डेटा को सीधे Performance पैनल में लाया जा सका. इस पोस्ट में, हम देखेंगे कि एपीआई क्या-क्या कर सकता है. साथ ही, यह भी देखेंगे कि Angular फ़्रेमवर्क में इसका इस्तेमाल कैसे किया गया. इस सुविधा को लागू करने का तरीका, अन्य फ़्रेमवर्क और ऐब्स्ट्रैक्शन के लिए एक उदाहरण के तौर पर काम कर सकता है. इससे वे अपने टूल को इंस्ट्रुमेंट करके, डेवलपर के अनुभव को बेहतर बना सकते हैं. साथ ही, Chrome DevTools का इस्तेमाल करने वाले डेवलपर की मदद कर सकते हैं.

परफ़ॉर्मेंस पैनल एक्सटेंसिबिलिटी एपीआई क्या है?

इस एपीआई की मदद से, परफ़ॉर्मेंस पैनल के ट्रेस में अपनी टाइमिंग की एंट्री जोड़ी जा सकती हैं. ये एंट्री, ब्राउज़र के बाकी डेटा की टाइमलाइन में ही जोड़ी जाती हैं. ऐसा करने के लिए, दो तरीके उपलब्ध हैं:

• User Timing API
• console.timeStamp API

User Timing API

performance.mark और performance.measure का इस्तेमाल करके, इस तरह से एंट्री जोड़ी जा सकती हैं:

// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();

// ... later in your code

performance.measure("Component rendering", {
  start: renderStart,
  detail: {
    devtools: {
      dataType: "track-entry",
      track: "Components",
      color: "secondary",
      properties: [
        ["Render reason", "Props changed"],
        ["Priority", "low"]
      ],
    }
  }
});

इससे आपकी टाइमलाइन में कॉम्पोनेंट ट्रैक जुड़ जाएगा. इसमें यह मेज़रमेंट दिखेगा:

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

इस एपीआई और devtools ऑब्जेक्ट के बारे में ज़्यादा जानने के लिए, दस्तावेज़ पढ़ें.

console.timeStamp एपीआई

यह एपीआई, User Timing API का एक हल्का विकल्प है. ऊपर दिए गए उदाहरण का इस्तेमाल करके, आपके पास ये विकल्प हो सकते हैं:

// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();

// ... later in your code

console.timeStamp(
"Component rendering",
/* start time */ renderStart,
/* end time (current time) */ undefined,
/* track name */ "Components",
 /* track group name */ undefined,
 /* color */ "secondary"
);

यह एपीआई, ऐप्लिकेशन को इंस्ट्रुमेंट करने का बेहतर तरीका उपलब्ध कराता है. User Timing API के विकल्प के उलट, यह बफ़र किया गया डेटा नहीं बनाता. यह एपीआई, DevTools के **परफ़ॉर्मेंस** पैनल में डेटा जोड़ता है. इसका मतलब है कि जब DevTools, ट्रेस रिकॉर्ड नहीं कर रहा होता है, तब एपीआई को किए गए कॉल कोई कार्रवाई नहीं करते हैं. इससे यह एपीआई, परफ़ॉर्मेंस के लिहाज़ से ज़रूरी हॉट पाथ के लिए ज़्यादा तेज़ और सही हो जाता है. कस्टम बनाने के सभी पैरामीटर वाले ऑब्जेक्ट के बजाय, पोज़ीशनल आर्ग्युमेंट का इस्तेमाल करने का विकल्प इसलिए चुना गया है, ताकि एपीआई को जितना हो सके उतना हल्का रखा जा सके.

परफ़ॉर्मेंस पैनल और दस्तावेज़ में पास किए जा सकने वाले पैरामीटर को बढ़ाने के लिए, console.timeStamp का इस्तेमाल करने के बारे में ज़्यादा जानें.

ऐंगुलर ने DevTools के एक्सटेंसिबिलिटी एपीआई को कैसे इंटिग्रेट किया है

हम देखेंगे कि Angular टीम ने Chrome DevTools के साथ इंटिग्रेट करने के लिए, एक्सटेंसिबिलिटी एपीआई का इस्तेमाल कैसे किया.

console.timestamp का इस्तेमाल करके, ओवरहेड से बचना

Angular के वर्शन 20 से, Performance पैनल के एक्सटेंसिबिलिटी एपीआई के साथ इंस्ट्रुमेंटेशन उपलब्ध है. DevTools में परफ़ॉर्मेंस डेटा के लिए, ज़्यादा जानकारी वाले लेवल की ज़रूरत होती है. इसके लिए, तेज़ एपीआई की ज़रूरत होती है. इसलिए, इंस्ट्रुमेंटेशन जोड़ने वाले पुल अनुरोध (60217) ने console.timeStamp एपीआई का इस्तेमाल करने का विकल्प चुना. इससे ऐप्लिकेशन की रनटाइम परफ़ॉर्मेंस पर, प्रोफ़ाइलिंग एपीआई के संभावित ओवरहेड का असर नहीं पड़ता..

इंस्ट्रुमेंट किया गया डेटा

Angular कोड कैसे काम करता है और यह क्यों काम करता है, इसकी बेहतर जानकारी देने के लिए, स्टार्टअप और रेंडरिंग पाइपलाइन के कई हिस्सों को इंस्ट्रुमेंट किया जाता है. इनमें ये शामिल हैं:

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

कलर कोडिंग

कलर कोडिंग का इस्तेमाल, डेवलपर को यह बताने के लिए किया जाता है कि मेज़रमेंट की कोई एंट्री किस कैटगरी में आती है. उदाहरण के लिए, डेवलपर के लिखे गए TypeScript कोड को लागू करने वाली एंट्री के लिए इस्तेमाल किए गए रंग, Angular कंपाइलर से जनरेट किए गए कोड के लिए इस्तेमाल किए गए रंगों से अलग होते हैं.

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

ध्यान दें कि एपीआई को पास किया गया color argument, सीएसएस कलर वैल्यू नहीं है. यह एक सिमैंटिक टोकन है, जिसे DevTools के यूज़र इंटरफ़ेस (यूआई) से मेल खाने वाले रंग पर मैप किया जाता है. संभावित वैल्यू primary, secondary, और tertiary, हैं. साथ ही, इनके -dark और -light वैरिएंट के साथ-साथ error रंग भी है.

ट्रैक

लिखने के समय, सभी Angular रनटाइम डेटा को एक ही ट्रैक में जोड़ा जाता है. इसे "🅰️ Angular" के तौर पर लेबल किया जाता है. हालांकि, ट्रेस में एक से ज़्यादा ट्रैक जोड़े जा सकते हैं. साथ ही, अपने ट्रैक को ग्रुप भी किया जा सकता है. उदाहरण के लिए, console.timeStamp एपीआई को किए गए इन कॉल पर विचार करें:

console.timeStamp("Component 1", componentStart1, componentEnd1, "Components", "Client", "primary");
console.timeStamp("Component 2", componentStart2, componentEnd2, "Components", "Client", "primary");
console.timeStamp("Hook 1", hookStart, hookEnd, "Hooks", "Client", "primary");
console.timeStamp("Fetch data base", fetchStart, fetchEnd, "Server", "primary");

आपको ट्रैक में व्यवस्थित किया गया डेटा इस तरह दिखेगा:

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

Angular डेवलपर के लिए यह क्यों ज़रूरी है

इस डायरेक्ट इंटिग्रेशन का मकसद, परफ़ॉर्मेंस के विश्लेषण को ज़्यादा आसान और बेहतर बनाना है. Angular के इंटरनल परफ़ॉर्मेंस डेटा को सीधे **Performance** पैनल में दिखाने से, डेवलपर को ये फ़ायदे मिलेंगे:

• बेहतर विज़िबिलिटी: Angular के परफ़ॉर्मेंस इवेंट, जैसे कि कॉम्पोनेंट रेंडरिंग, बदलाव का पता लगाने वाले साइकल वगैरह को ब्राउज़र की टाइमलाइन में ज़्यादा बेहतर तरीके से दिखाया जाता है.
• बेहतर जानकारी: Angular की इंटरनल प्रोसेस के बारे में ज़्यादा जानकारी मिलती है. इससे परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने में मदद मिलती है.

इंटिग्रेशन चालू करना

एक्सटेंसिबिलिटी एपीआई का इस्तेमाल, Angular के वर्शन 20 से डेवलपमेंट बिल्ड में आधिकारिक तौर पर उपलब्ध है. इसे चालू करने के लिए, आपको अपने ऐप्लिकेशन या DevTools कंसोल में ग्लोबल यूटिलिटी `ng.enableProfiling()` को चलाना होगा. इंटिग्रेशन के बारे में ज़्यादा जानकारी के लिए, [Angular Docs](https://angular.dev/best-practices/profiling-with-chrome-devtools) पर जाएं

अन्य ज़रूरी बातें

कुछ ज़रूरी बातें, जिनका ध्यान रखना ज़रूरी है.

सोर्स मैप और छोटा किया गया कोड:

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

क्या बंडल किए गए ऐप्लिकेशन में, छोटे किए गए कोड की समस्या को सोर्स मैप से ठीक नहीं किया जा सकता?

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

Chrome DevTools एक्सटेंशन:

DevTools API का इस्तेमाल करने वाले Chrome एक्सटेंशन, DevTools को बढ़ाने के लिए सबसे ज़्यादा इस्तेमाल किए जाने वाले टूल हैं.

क्या यह एपीआई उपलब्ध होने के बाद, अब खास तौर पर प्रोफ़ाइलिंग के लिए बनाए गए टूल (जैसे कि Chrome DevTools एक्सटेंशन) की ज़रूरत नहीं है या इनका इस्तेमाल करने से बचना चाहिए?

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

आगे का रास्ता

एक्सटेंसिबिलिटी एपीआई की संभावना.

ज़्यादा फ़्रेमवर्क और ऐब्स्ट्रैक्शन के साथ काम करना

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

प्रोडक्शन बिल्ड

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