Chrome DevTools Performance Panel: कोड एक्ज़ीक्यूशन का विश्लेषण

Chrome DevTools में Performance panel को पहली बार खोलें तो ऐसा लगता है जैसे किसी ने आपकी स्क्रीन पर रंगीन क्रेयॉन का पूरा डिब्बा उड़ेल दिया हो। दर्जनों रंग-बिरंगी बार्स, आधा दर्जन ट्रैक्स, और नीचे तीन टैब जो सब एक जैसी ही चीज़ दिखाते लगते हैं लेकिन थोड़ा अलग ढंग से। कोई आश्चर्य नहीं कि ज़्यादातर डेवलपर्स एक trace रिकॉर्ड करते हैं, घबरा जाते हैं, और वापस console.log डिबगिंग पर लौट जाते हैं। मैं भी सालों तक यही करता रहा - जब तक मैंने वाकई बैठकर यह नहीं समझा कि हर हिस्सा क्या मतलब रखता है, और अब जब भी कुछ “धीमा महसूस होता है” तो यही पहला टूल होता है जिसकी ओर मैं हाथ बढ़ाता हूँ।

यह पैनल सीखने की मेहनत के लायक क्यों है

Lighthouse आपको एक स्कोर देता है। Performance panel आपको क्यों बताता है। यह आपके पेज के चलने के दौरान ब्राउज़र द्वारा किए जाने वाले हर काम की एक पूरी टाइमलाइन रिकॉर्ड करता है - हर JavaScript फ़ंक्शन कॉल, हर लेआउट रीकैल्क्युलेशन, हर पेंट, हर नेटवर्क रिक्वेस्ट - और आपको इसे फ्रेम-दर-फ्रेम स्क्रब करने देता है [1]।

इसे थर्मामीटर और CT स्कैन के फ़र्क की तरह सोचिए। थर्मामीटर (Lighthouse, PageSpeed Insights, आपका Core Web Vitals डैशबोर्ड) आपको बताता है कि कुछ गड़बड़ है। Performance panel आपको ठीक-ठीक बताता है कि कौन-सा “अंग” समस्या पैदा कर रहा है, और किस मिनट से वह गड़बड़ करने लगा।

आज जब आप पैनल खोलते हैं, तो आपका स्वागत एक Live Metrics स्क्रीन से होता है जो रीयल-टाइम Core Web Vitals - LCP, CLS, और INP - दिखाती है, और जैसे-जैसे आप पेज पर क्लिक करते हैं ये अपडेट होते रहते हैं [3]। यह अपेक्षाकृत नया फ़ीचर है, और सच में काफ़ी काम का है क्योंकि यह जानने के लिए कि कुछ टूटा हुआ है या नहीं, आपको trace रिकॉर्ड करने की ज़रूरत भी नहीं पड़ती।

अपना पहला trace रिकॉर्ड करना: runtime बनाम reload

दो बिल्कुल अलग चीज़ें हैं जिन्हें आप शायद मापना चाहें, और DevTools इनमें से हर एक के लिए एक बटन देता है:

Record (गोल बटन) - तब की गतिविधि कैप्चर करता है जब आप किसी लाइव पेज के साथ इंटरैक्ट करते हैं। इसे स्क्रॉलिंग, टाइपिंग, बटन क्लिक करने, मोडल खोलने - यानी पेज लोड हो जाने के बाद होने वाली किसी भी चीज़ के लिए इस्तेमाल करें।
Record and reload - पूरे पेज लोड को कैप्चर करता है, navigation से लेकर “fully loaded” तक। DevTools पहले बचे हुए स्क्रीनशॉट्स और traces हटाने के लिए about:blank पर जाता है, फिर आपके पेज को रीलोड करता है और लोड पूरा होने के कुछ सेकंड बाद अपने आप रिकॉर्डिंग बंद कर देता है [3]।

रिकॉर्ड दबाने से पहले, capture settings खोलने के लिए गियर आइकन पर क्लिक करें। यहीं ज़्यादातर उपयोगी सेटिंग्स मौजूद होती हैं:

Screenshots - एक फ़िल्म स्ट्रिप कैप्चर करता है ताकि आप देख सकें कि हर समय-बिंदु पर यूज़र ने वास्तव में क्या देखा था
Force garbage collection - रिकॉर्डिंग शुरू होने से पहले एक GC रन ट्रिगर करता है, यह तब काम आता है जब आप मेमोरी से जुड़ी jank ढूँढ रहे हों
CPU and network throttling - इस पर आगे विस्तार से बात करेंगे
JavaScript samples - विस्तृत call stacks को दृश्यमान रखता है (यह डिफ़ॉल्ट रूप से ऑन रहता है, और इसे बंद करने से flame chart काफ़ी कम उपयोगी हो जाता है, इसलिए बिना किसी कारण के इसे न छेड़ें)
CSS selector stats - दिखाता है कि style recalculation के दौरान कौन-से selectors महँगे साबित होते हैं
Advanced paint instrumentation - paint ऑपरेशन का विस्तृत डेटा दिखाता है [2]

मेरी सलाह है कि पहले एक छोटा trace रिकॉर्ड करें - किसी इंटरैक्शन के बस 3-5 सेकंड भी काफ़ी हैं। लंबी रिकॉर्डिंग्स में नेविगेट करना मुश्किल होता है और इन्हें प्रोसेस करते समय DevTools धीमा पड़ सकता है। छोटी, केंद्रित रिकॉर्डिंग्स पढ़ने में आसान और विश्लेषण में तेज़ होती हैं।

Flame chart पढ़ना: main thread को समझना

यही वह हिस्सा है जो लोगों को डराता है, तो आइए थोड़ा धीरे चलें। Flame chart Main ट्रैक में होता है और समय के साथ main thread पर हो रही हर चीज़ को विज़ुअलाइज़ करता है [1]।

X-अक्ष समय है। बाएँ से दाएँ, बिल्कुल एक सामान्य टाइमलाइन की तरह।
Y-अक्ष call stack की गहराई है। ऊपर मौजूद फ़ंक्शन अपने नीचे वाले फ़ंक्शन को कॉल करता है, जो उससे नीचे वाले किसी और फ़ंक्शन को कॉल करता है। ध्यान दें कि यह पारंपरिक flame graph के मुक़ाबले “उल्टा” है - DevTools में, parents अपने children के नीचे नहीं बल्कि ऊपर बैठते हैं [6]।
हर बार एक फ़ंक्शन कॉल (या ब्राउज़र इवेंट) है। चौड़ी बार का मतलब है कि उसे एक्ज़ीक्यूट होने में ज़्यादा समय लगा।
रंग कैटेगरी दर्शाते हैं - पीला scripting (आपका JS) के लिए, बैंगनी rendering (style/layout) के लिए, हरा painting के लिए, और ग्रे “other”/idle गतिविधि के लिए।

यह रहा वह डायग्राम जिसने आख़िरकार मेरे लिए यह बात साफ़ कर दी:

flame chart anatomy

जैसे ही आप बार्स पर क्लिक करना शुरू करेंगे, दो शब्द आपको बार-बार दिखेंगे:

Self time - फ़ंक्शन खुद कितनी देर चला, उसके द्वारा कॉल की गई किसी भी चीज़ को छोड़कर।
Total time - self time के साथ-साथ इसके children ने जो भी किया वह सब।

एक चौड़ी processData() बार का मतलब अपने आप यह नहीं है कि processData() ही समस्या है। हो सकता है यह सिर्फ़ JSON.parse() के चारों ओर एक पतला रैपर हो, जो असल में सारा काम कर रहा हो। Self time आपको बताता है कि असली दोषी कौन है; total time आपको बताता है कि अपराध स्थल के सबसे क़रीब कौन खड़ा है [6]।

Call Tree, Bottom-Up, Event Log: वही डेटा, तीन अलग नज़रिए

जब आप flame chart में किसी बार पर क्लिक करते हैं, तो पैनल का निचला हिस्सा विवरण दिखाने लगता है। वहाँ तीन टैब होते हैं, और सच कहूँ तो यह समझने में मुझे शर्मनाक हद तक ज़्यादा समय लग गया कि कब कौन-सा टैब इस्तेमाल करना है।

व्यू	क्या दिखाता है	किसके लिए सबसे अच्छा
Call Tree	root activities से शुरू होने वाला टॉप-डाउन व्यू, जिसे उनके children में विस्तारित किया जा सकता है	प्रोग्राम के फ़्लो को फ़ॉलो करना - “किसने किसे ट्रिगर किया”
Bottom-Up	उल्टा व्यू, उन फ़ंक्शनों से शुरू होकर जहाँ असल में समय खर्च हुआ, पूरी रिकॉर्डिंग में एकत्रित किया गया	पूरे trace में अपने सबसे बड़े अपराधी को ढूँढना
Event Log	हर इवेंट की कालक्रमानुसार सूची, टाइमस्टैम्प के साथ, कैटेगरी और duration के लिए फ़िल्टर के साथ	यह पता लगाना कि कोई चीज़ कब हुई, ख़ासकर नेटवर्क रिक्वेस्ट्स और यूज़र इंटरैक्शन्स

Call Tree इस सवाल का जवाब देता है “हम यहाँ तक कैसे पहुँचे?” - यह root activities दिखाता है और आपको यह जानने देता है कि किस फ़ंक्शन ने सबसे ज़्यादा काम किया [1]। Bottom-Up टैब इसे उलट देता है: यह हर फ़ंक्शन के Self Time को उसके सभी occurrences में एकत्रित कर देता है, जिससे जो फ़ंक्शन सबसे ज़्यादा CPU खा रहा है वह सीधे ऊपर आ जाता है, चाहे उसे कहीं से भी कॉल किया गया हो [2]। अगर आप सिर्फ़ एक ही टैब सीखना चाहें, तो यही सीखें - “ठीक है, यही फ़ंक्शन समस्या है” तक पहुँचने का यह सबसे तेज़ रास्ता है।

Event Log का संबंध CPU समय से कम और क्रम (sequence) से ज़्यादा है - मैं यहाँ तब जाता हूँ जब मुझे ठीक-ठीक यह जानना हो कि किसी layout shift के सापेक्ष कोई नेटवर्क रिक्वेस्ट कब फ़ायर हुई, साथ ही Loading, Scripting, Rendering, या Painting कैटेगरी के हिसाब से फ़िल्टरिंग की सुविधा भी मिलती है [2]।

Call Tree और Bottom-Up दोनों regex search, case-sensitive मैचिंग, और “group by” विकल्पों (URL के अनुसार, कैटेगरी के अनुसार, या खुद activity के अनुसार) को सपोर्ट करते हैं, जो ज़रूरी हो जाता है जब आपके trace में हज़ारों एंट्रीज़ हों [2]।

50-मिलीसेकंड का नियम: long tasks का शिकार

इस पूरे लेख का सबसे महत्वपूर्ण अकेला नंबर यह है: 50 मिलीसेकंड। main thread पर किसी भी निर्बाध काम का ऐसा हिस्सा जो इससे ज़्यादा समय तक चलता है, उसे आधिकारिक रूप से “long task” कहा जाता है, और DevTools बार के कोने में एक लाल त्रिकोण लगाकर इसे फ़्लैग करता है, जिसमें 50ms से ऊपर वाला हिस्सा लाल रंग से शेड किया जाता है [5]।

यह इतना मायने क्यों रखता है? क्योंकि main thread एक समय में सिर्फ़ एक ही काम कर सकता है। जब यह आपके 380ms वाले onClick हैंडलर को चलाने में व्यस्त है, तब यह किसी टैप, स्क्रॉल, या की-प्रेस का जवाब नहीं दे सकता। यूज़र का इनपुट बस एक क्यू में पड़ा रह जाता है। यही सीधा कारण है कि आपका Interaction to Next Paint (INP) स्कोर गिर जाता है - और INP Google के तीन Core Web Vitals में से एक है।

इन्हें ढूँढने के लिए मेरा वर्कफ़्लो:

वह इंटरैक्शन रिकॉर्ड करें जो jank जैसा महसूस होता है।
लाल त्रिकोण वाली बार्स के लिए Main ट्रैक स्कैन करें।
सबसे चौड़ी वाली बार पर क्लिक करें।
Bottom-Up पर स्विच करें, Self Time के अनुसार सॉर्ट करें, और देखें कि कौन-सा फ़ंक्शन thread को जकड़े हुए है।
उस फ़ंक्शन को ठीक करें।

एक शानदार वास्तविक उदाहरण एक डेवलपर का है जिसने सर्च रिज़ल्ट्स पेज को trace किया और पाया कि हर API रिस्पॉन्स एक Redux dispatch ट्रिगर करता था, जो पूरे component tree को फिर से रेंडर कर देता था। list virtualization अपनाने के बाद एक ही हैंडलर का long task खर्च 400ms से घटकर 70ms रह गया - और उनका p75 First Input Delay 140ms से घटकर 25-30ms हो गया, मोबाइल डिवाइसों पर तो 85% सुधार देखा गया [7]। एक अन्य केस स्टडी में सिर्फ़ इनपुट को debounce करने और DOM अपडेट्स को batch करने से एक प्रोडक्ट फ़िल्टर का blocking time 118ms से घटकर 22ms हो गया [6]। ये कोई काल्पनिक आँकड़े नहीं हैं - यही वो काम है जिसके लिए यह पैनल बना है।

तो एक बार long task मिल जाने के बाद उसे असल में ठीक कैसे करें? कुछ आज़माए हुए तरीके:

काम को टुकड़ों में बाँटें - setTimeout() का उपयोग करके हर टुकड़े को उसके अपने task में डालें - यह मूल, थोड़ा hacky लेकिन काम का तरीका है [5]।
scheduler.yield() का इस्तेमाल करें - यह आधुनिक, इसी काम के लिए बनाया गया API है। await scheduler.yield() आपके फ़ंक्शन को रोक देता है, ब्राउज़र को किसी ज़्यादा ज़रूरी चीज़ (जैसे वह इनपुट इवेंट) को संभालने देता है, और फिर ठीक वहीं से दोबारा शुरू हो जाता है जहाँ इसे रोका गया था [5]।
उन ब्राउज़रों के लिए gracefully fallback करें जो अभी इसे सपोर्ट नहीं करते:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

जब काम के लिए DOM एक्सेस की बिल्कुल ज़रूरत न हो, तो Web Workers का उपयोग करके काम को main thread से पूरी तरह हटा दें।
गैर-ज़रूरी स्क्रिप्ट्स को defer या lazy-load करें ताकि वे पेज लोड के दौरान main thread के लिए होड़ न करें।

Throttling: अपने गेमिंग लैपटॉप को बजट Android फ़ोन जैसा महसूस कराना

यह रहा एक असहज सच: आपकी dev मशीन आपसे झूठ बोल रही है। आप आठ कोर और गीगाबिट फ़ाइबर वाले लैपटॉप पर टेस्ट कर रहे हैं। आपके ज़्यादातर यूज़र्स कमज़ोर 4G वाले मिड-रेंज फ़ोन पर हैं। Performance panel की throttling सेटिंग्स ख़ास तौर पर इसी अंतर को पाटने के लिए मौजूद हैं।

सेटिंग	विकल्प	यह क्या सिमुलेट करती है
CPU throttling	No throttling, 4x slowdown, 6x slowdown, या एक calibrated कस्टम प्रीसेट	धीमे प्रोसेसर - “4x” का मतलब है कि हर चीज़ को एक्ज़ीक्यूट होने में 4 गुना ज़्यादा समय लगता है [4]
Network throttling	Fast 4G, Slow 4G, कस्टम प्रीसेट्स	वास्तविक दुनिया की कनेक्शन स्पीड और लेटेंसी
Calibrated CPU throttling	आपकी असली मशीन को बेंचमार्क करता है और एक कस्टम प्रीसेट बनाता है	low/mid-tier मोबाइल डिवाइसों के लिए ज़्यादा सटीक मिलान [4]

यहाँ एक सीमा के बारे में ईमानदार होना ज़रूरी है: DevTools किसी फ़ोन के CPU को पूरी तरह emulate नहीं कर सकता, क्योंकि मोबाइल चिप्स का आर्किटेक्चर डेस्कटॉप CPU से मूलतः अलग होता है (अलग core types, thermal throttling, वग़ैरह) [4]। 4x/6x मल्टीप्लायर एक मोटा अनुमान भर है, न कि डिब्बे में बंद कोई फ़ोन। नया calibration फ़ीचर - जो आपकी मशीन को बेंचमार्क करके एक ज़्यादा यथार्थवादी प्रीसेट तैयार करता है - इस अंतर को पाटने की दिशा में एक सार्थक क़दम है, लेकिन मैं अब भी throttled नतीजों को “दिशा में सही” मानूँगा, न कि “बिल्कुल वैसा जैसा कोई Pixel 4a दिखाएगा।”

फिर भी, मोटा-मोटा throttling भी काफ़ी कुछ उजागर कर देता है। मैंने ऐसे इंटरैक्शन देखे हैं जो मेरी dev मशीन पर तुरंत महसूस होते थे, लेकिन 6x CPU slowdown ऑन करते ही 600ms से ज़्यादा के freeze में बदल गए। अगर आपकी टीम में “throttling ऑन करके टेस्ट करने” की आदत नहीं है, तो शायद यही वह सबसे क़ीमती बदलाव है जो आप आज अपनी टेस्टिंग रूटीन में कर सकते हैं।

Live metrics और Insights साइडबार: Core Web Vitals, बिल्कुल अंदर ही समाहित

Performance panel के नए डिज़ाइन में एक Live Metrics लैंडिंग पेज जोड़ा गया है जो LCP, CLS, और INP को रीयल टाइम में अपडेट होते हुए दिखाता है - और सबसे ज़रूरी बात, यह आपके local (lab) डेटा और Chrome UX Report (CrUX) से लिए गए field डेटा को साथ-साथ दिखाता है, ताकि आप देख सकें कि आपका टेस्ट सेशन वास्तविक यूज़र्स के अनुभव से कितना मेल खाता है [3] [8]।

trace रिकॉर्ड करने के बाद, Insights साइडबार सामने आता है। यहीं हाल के बदलाव असल में चमकते हैं - यह मूल रूप से Lighthouse-शैली के audits को आपके असली trace डेटा के साथ मिला देता है [8]:

फ़ेज़ के अनुसार LCP breakdown - आपके Largest Contentful Paint को Time to First Byte, resource load delay, resource load time, और element render delay में बाँटता है, ताकि आपको पता चले कि किस फ़ेज़ पर काम करना है [9]
Render-blocking requests - उन स्क्रिप्ट्स/स्टाइल्स को फ़्लैग करता है जो first paint को रोक रहे हैं, अक्सर “इस critical CSS को inline करें” जैसा एक-लाइन का सुझाव भी देता है [9]
Layout Shift clusters - CLS पैदा करने वाले shifts को “session windows” में समूहित करता है ताकि आप देख सकें कि कौन-से DOM बदलाव इसके लिए ज़िम्मेदार हैं [9]
क्लिक करने योग्य culprits - फ़्लैग किए गए LCP element या INP target पर क्लिक करते ही आप सीधे Elements panel में उस नोड पर पहुँच जाते हैं [8]

जल्दी से “good/needs improvement/poor” का अंदाज़ा लगाने के लिए याद रखने लायक थ्रेशोल्ड: 2.5 सेकंड से कम LCP अच्छा है, 0.1 से कम CLS अच्छा है, और 200ms से कम INP अच्छा है [9]। अगर Insights panel इनमें से किसी को लाल रंग में फ़्लैग करता है, तो वही आपका शुरुआती बिंदु है - बिना सोचे-समझे flame chart में मत भटकिए।

एक अलग Performance Monitor panel के बारे में भी जानना उपयोगी है - यह एक हल्का, हमेशा-चालू डैशबोर्ड है जो live CPU उपयोग, JS heap साइज़, DOM नोड काउंट, और event listener काउंट दिखाता है। मुझे कुछ भी रिकॉर्ड करने से पहले इसे खोलना पसंद है, बस यह अंदाज़ा लगाने के लिए कि कहीं समय के साथ कोई चीज़ मेमोरी लीक या listeners जमा तो नहीं कर रही [15]।

शोर को छाँटना: ignore lists और third parties को धुँधला करना

एक असली trace भरा-पूरा होता है। Analytics स्क्रिप्ट्स, ad tags, चैट विजेट्स, आपके फ्रेमवर्क की आंतरिक चीज़ें - ये सब बार्स के रूप में दिखकर आपका ध्यान खींचने की होड़ करते हैं। DevTools शोर को कम करने के कुछ तरीके देता है:

स्क्रिप्ट्स को ignore list में जोड़ें - flame chart में किसी भी एंट्री पर राइट-क्लिक करें और “Add script to ignore list” चुनें। उस स्क्रिप्ट के फ़्रेम्स एक ही एंट्री में सिमट जाते हैं, और वही ignore list तब भी लागू होती है जब आप Sources panel में कोड के बीच step कर रहे हों। ये नियम DevTools सेशन्स के बीच बने रहते हैं [11]।
“Dim 3rd parties” चेकबॉक्स - trace में third-party स्क्रिप्ट्स और नेटवर्क रिक्वेस्ट्स को धूसर (grey) कर देता है ताकि first-party कोड विज़ुअली उभरकर दिखे [10]।
Summary टैब की first/third-party टेबल - एक नया जोड़ है जो first-party कोड, third-party कोड, और ब्राउज़र एक्सटेंशन्स द्वारा खर्च किए गए समय को अलग-अलग दिखाता है, और trace में hover करने पर हाइलाइट हो जाता है [10]।
Cmd/Ctrl+F से सर्च करें - पूरे trace में activity के नामों को खोजता है, साथ ही regex और case-sensitivity के टॉगल भी मिलते हैं [2]।

नेविगेशन में एक और बदलाव जानने लायक है: DevTools अब “Modern” बनाम “Classic” स्क्रॉलिंग मोड्स देता है। Classic मोड में, आपका स्क्रॉल व्हील ज़ूम करता है और Shift+scroll pan करता है। Modern मोड में यह उल्टा है - सीधा स्क्रॉल टाइमलाइन को pan करता है, ठीक वैसे जैसा आप किसी भी अन्य पेज पर उम्मीद करते हैं, और Shift+scroll ज़ूम करता है [10]। अगर पैनल में स्क्रॉल करना आपको कभी उल्टा महसूस हुआ है, तो यही इसकी वजह है।

ईमानदारी से कहूँ तो, यह उन फ़ीचर्स में से एक है जिसके बारे में काश मुझे महीनों पहले पता होता - ignore list की मदद से यह सब समेटा जा सकता है, यह जानने से पहले मैंने “अपने” फ़ंक्शनों को ढूँढने के लिए webpack-bundled vendor कोड को मैन्युअल रूप से स्क्रॉल करते हुए बहुत ज़्यादा समय बर्बाद किया।

अपने निष्कर्षों को annotate करना, सेव करना, और शेयर करना

कुछ दिलचस्प मिला? बस उसका स्क्रीनशॉट लेकर “look at this 😬” के साथ Slack पर मत चिपकाइए - trace को खुद ही annotate करें। DevTools 131 से, आप किसी रिकॉर्डिंग पर सीधे annotations जोड़ सकते हैं [12]:

Entries को लेबल करें - किसी भी बार पर राइट-क्लिक (या डबल-क्लिक) करें और एक टेक्स्ट नोट जोड़ें जो बताए कि यह क्या है या यह धीमा क्यों है
Entries को लिंक करें - कारण-और-प्रभाव दिखाने के लिए दो trace आइटम्स के बीच एक तीर खींचें, जैसे “इस नेटवर्क रिक्वेस्ट ने इस re-render को ट्रिगर किया”
Time ranges - पूरे सेक्शन को हाइलाइट करने के लिए shift-click करके खींचें (drag), यह “यह third-party चैट विजेट initialize हो रहा है” जैसा मार्क करने में उपयोगी है

जब आप पूरा कर लें, तो action bar में डाउनलोड आइकन पर क्लिक करें और Save trace चुनें। आप चाहें तो पेज की सभी स्क्रिप्ट कंटेंट और source maps की एक कॉपी भी शामिल कर सकते हैं - यानी जो भी बाद में आपका trace खोलेगा उसे आपका असली सोर्स कोड और एक काम करता हुआ Sources panel मिलेगा, सिर्फ़ minified गड़बड़-कोड नहीं [13]। मदद माँगने के लिए यह सच में शानदार है: किसी समस्या को बग रिपोर्ट में बताने के बजाय, आप एक .json trace फ़ाइल अटैच करके कह सकते हैं “इसे DevTools में खोलें और Main ट्रैक में 2-सेकंड के निशान के आसपास देखें।”

Gemini को अपने साथ trace पढ़ने देना

इन सबके ऊपर सबसे नई परत AI असिस्टेंस की है। Chrome के DevTools में अब एक “Debug with AI” विकल्प है (पहले इसे “Ask AI” कहा जाता था) जो किसी trace एंट्री पर राइट-क्लिक करने पर दिखाई देता है, और आपने जो भी क्लिक किया है उसके आधार पर context-aware प्रॉम्प्ट्स देता है [14]।

इससे भी ज़्यादा दिलचस्प बात यह है कि अब आप सिर्फ़ किसी एक अलग-थलग बार के बारे में पूछने तक सीमित नहीं हैं। trace रिकॉर्ड करने के बाद, आप Gemini से पूरे trace के बारे में बातचीत कर सकते हैं - टाइमलाइन, Insights साइडबार के निष्कर्ष, और यहाँ तक कि field डेटा भी - सब एक ही बातचीत में, किसी ख़ास इवेंट में जाने से पहले [14]। AI ख़ुद-ब-ख़ुद प्रासंगिक संदर्भ (कोई ख़ास long task, कोई render-blocking रिक्वेस्ट) ला सकता है, बिना आपके पहले से उसे मैन्युअली चुने।

ईमानदारी से कहूँ तो, मुझे “AI लेकिन DevTools के लिए” वाले आइडिया पर शक था - यह पहले से ही जटिल टूल में जोड़ा गया एक गिमिक जैसा लगता था। लेकिन “यह LCP इतना धीमा क्यों है?” पूछना और इसके जवाब में सीधी-सादी भाषा में एक स्पष्टीकरण मिलना जो ज़िम्मेदार सही resource और phase की ओर इशारा करे - यह जूनियर डेवलपर्स के लिए (या मेरे लिए, सोमवार की सुबह कॉफ़ी से पहले) LCP breakdown को network waterfall के साथ मैन्युअली मिलाने से कहीं ज़्यादा तेज़ रास्ता है।

सब कुछ एक साथ

अगर आप सिर्फ़ एक वर्कफ़्लो याद रखना चाहते हैं, तो यह रहा:

DevTools खोलें, Performance पर जाएँ, और किसी स्पष्ट red flag के लिए Live Metrics पर एक नज़र डालें।
वास्तविक यूज़र्स से मेल खाने के लिए throttling चालू करके Record (या Record and reload) दबाएँ।
धीमा इंटरैक्शन करें, फिर रोकें।
पहले Insights साइडबार देखें - हो सकता है यह सीधे आपको जवाब दे दे।
red-flagged long tasks के लिए Main ट्रैक स्कैन करें।
सबसे चौड़ी दोषी बार पर क्लिक करें, Bottom-Up पर स्विच करें, Self Time के अनुसार सॉर्ट करें।
असली फ़ंक्शन को ठीक करें, दोबारा रिकॉर्ड करें, और तुलना करें।

अगली बार जब आपकी टीम में कोई कहे “पेज बस धीमा सा लग रहा है,” तो आपको कंधे उचकाकर “हाँ, आजकल JS भारी हो गया है” कहने की ज़रूरत नहीं है। आप एक trace खोल सकते हैं, किसी ख़ास 380ms वाली बार की ओर इशारा कर सकते हैं, और ठीक-ठीक बता सकते हैं कि यह किस फ़ंक्शन का है।