पब्लिश होने की तारीख: 30 जनवरी, 2026
परफ़ॉर्मेंस के लिए एआई असिस्टेंस की सुविधा बनाते समय, इंजीनियरिंग से जुड़ी मुख्य चुनौती यह थी कि Gemini को DevTools में रिकॉर्ड किए गए परफ़ॉर्मेंस ट्रेस के साथ आसानी से काम करने के लिए बनाया जाए.
लार्ज लैंग्वेज मॉडल (एलएलएम), 'कॉन्टेक्स्ट विंडो' में काम करते हैं. इसका मतलब है कि वे एक बार में सिर्फ़ सीमित जानकारी को प्रोसेस कर सकते हैं. इस क्षमता को टोकन में मापा जाता है. Gemini मॉडल के लिए, एक टोकन में करीब चार वर्ण होते हैं.
परफ़ॉर्मेंस ट्रेस, बड़ी JSON फ़ाइलें होती हैं. इनका साइज़ अक्सर कई मेगाबाइट होता है. रॉ ट्रेस भेजने से, मॉडल की कॉन्टेक्स्ट विंडो तुरंत खत्म हो जाएगी. साथ ही, आपके सवालों के लिए कोई जगह नहीं बचेगी.
परफ़ॉर्मेंस के लिए एआई की मदद पाने की सुविधा उपलब्ध कराने के लिए, हमें एक ऐसा सिस्टम बनाना पड़ा जो एलएलएम के लिए ज़्यादा से ज़्यादा काम का डेटा उपलब्ध करा सके. साथ ही, इसमें कम से कम टोकन का इस्तेमाल हो. इस ब्लॉग में, आपको उन तकनीकों के बारे में जानकारी मिलेगी जिनका इस्तेमाल हमने किया है. साथ ही, अपने प्रोजेक्ट के लिए इन तकनीकों को अपनाया जा सकता है.
शुरुआती कॉन्टेक्स्ट को अपनी ज़रूरत के मुताबिक बनाना
किसी वेबसाइट की परफ़ॉर्मेंस को डीबग करना एक मुश्किल काम है. डेवलपर के पास ये विकल्प होते हैं: संदर्भ के लिए पूरे ट्रेस को देखना, कोर वेब वाइटल और ट्रेस के समय से जुड़े स्पैन पर फ़ोकस करना या ज़्यादा जानकारी देखना और क्लिक या स्क्रोल जैसे अलग-अलग इवेंट और उनसे जुड़े कॉल स्टैक पर फ़ोकस करना.
डीबग करने की प्रोसेस में मदद करने के लिए, DevTools की एआई सहायता को डेवलपर के काम करने के तरीके से मेल खाना चाहिए. साथ ही, सिर्फ़ काम के डेटा का इस्तेमाल करके, डेवलपर के काम से जुड़ी सलाह देनी चाहिए. इसलिए, हमने हमेशा पूरा ट्रेस भेजने के बजाय, एआई की मदद से काम करने वाली एक सुविधा बनाई है. यह सुविधा, आपके डीबग करने के टास्क के आधार पर डेटा को बांटती है:
| डीबग करने से जुड़ा टास्क | एआई की मदद से जुड़ी सुविधा को भेजा गया डेटा |
|---|---|
| परफ़ॉर्मेंस ट्रेस के बारे में चैट करना | ट्रेस की खास जानकारी: यह टेक्स्ट पर आधारित रिपोर्ट होती है. इसमें ट्रेस और डीबग करने के सेशन की हाई-लेवल की जानकारी शामिल होती है. इसमें पेज का यूआरएल, थ्रॉटलिंग की शर्तें, परफ़ॉर्मेंस की अहम मेट्रिक (एलसीपी, आईएनपी, सीएलएस), उपलब्ध इनसाइट की सूची, और अगर उपलब्ध हो, तो CrUX की खास जानकारी शामिल होती है. |
| परफ़ॉर्मेंस के बारे में अहम जानकारी के बारे में चैट करना | ट्रेस की खास जानकारी और चुनी गई परफ़ॉर्मेंस इनसाइट का नाम. |
| ट्रेस से मिले टास्क के बारे में चैट करना | ट्रेस की खास जानकारी और सीरियलाइज़ किया गया कॉल-ट्री, जिसमें चुना गया टास्क मौजूद है. |
| नेटवर्क के अनुरोध के बारे में चैट करना | ट्रेस की खास जानकारी, चुनी गई अनुरोध कुंजी, और टाइमस्टैंप |
| ट्रेस एनोटेशन जनरेट करना | सीरियलाइज़ किया गया कॉल-ट्री, जिसमें चुना गया टास्क मौजूद है. सीरियलाइज़ किए गए ट्री से पता चलता है कि कौनसा टास्क चुना गया है. |
ट्रेस की खास जानकारी, Gemini को शुरुआती कॉन्टेक्स्ट देने के लिए भेजी जाती है. Gemini, एआई असिस्टेंट का बुनियादी मॉडल है. एआई से जनरेट किए गए एनोटेशन के लिए, इसे शामिल नहीं किया जाता.
एआई को टूल उपलब्ध कराना
DevTools में एआई असिस्टेंस, एजेंट के तौर पर काम करता है. इसका मतलब है कि यह डेवलपर के शुरुआती प्रॉम्प्ट और इसके साथ शेयर किए गए शुरुआती कॉन्टेक्स्ट के आधार पर, ज़्यादा डेटा के लिए अपने-आप क्वेरी कर सकता है. ज़्यादा डेटा के बारे में क्वेरी करने के लिए, हमने एआई की मदद से काम करने वाले फ़ंक्शन का एक सेट दिया है. एआई इन फ़ंक्शन को कॉल कर सकता है. इसे फ़ंक्शन कॉलिंग या टूल का इस्तेमाल कहा जाता है.
हमने एजेंट के लिए, पहले बताई गई डीबग करने की प्रोसेस के आधार पर, फ़ंक्शन का एक सेट तय किया है. ये फ़ंक्शन, शुरुआती कॉन्टेक्स्ट के आधार पर ज़रूरी मानी जाने वाली खास जानकारी को बारीकी से देखते हैं. यह ठीक उसी तरह काम करता है जिस तरह कोई डेवलपर, परफ़ॉर्मेंस से जुड़ी गड़बड़ियों को ठीक करता है. फ़ंक्शन का सेट इस तरह है:
| फ़ंक्शन | ब्यौरा |
|---|---|
getInsightDetails(name) |
यह फ़ंक्शन, परफ़ॉर्मेंस की किसी खास अहम जानकारी के बारे में ज़्यादा जानकारी दिखाता है. उदाहरण के लिए, एलसीपी को फ़्लैग क्यों किया गया, इस बारे में जानकारी. |
getEventByKey(key) |
यह फ़ंक्शन, किसी एक इवेंट के लिए ज़्यादा जानकारी वाली प्रॉपर्टी दिखाता है. |
getMainThreadTrackSummary(start, end) |
यह फ़ंक्शन, दिए गए बाउंड के लिए मुख्य थ्रेड की गतिविधि की खास जानकारी दिखाता है. इसमें टॉप-डाउन, बॉटम-अप, और तीसरे पक्ष की खास जानकारी शामिल होती है. |
getNetworkTrackSummary(start, end) |
यह फ़ंक्शन, दिए गए समय के हिसाब से नेटवर्क गतिविधि की खास जानकारी दिखाता है. |
getDetailedCallTree(event_key) |
यह परफ़ॉर्मेंस ट्रेस पर, किसी मुख्य थ्रेड इवेंट के लिए पूरा कॉल ट्री दिखाता है |
getFunctionCode(url, line, col) |
यह फ़ंक्शन, किसी संसाधन में किसी खास जगह पर तय किए गए फ़ंक्शन का सोर्स कोड दिखाता है. इस पर परफ़ॉर्मेंस ट्रेस से मिले रनटाइम परफ़ॉर्मेंस डेटा का एनोटेशन होता है |
getResourceContent(url) |
यह कुकी, पेज पर इस्तेमाल किए गए टेक्स्ट रिसॉर्स का कॉन्टेंट दिखाती है. जैसे, एचटीएमएल या सीएसएस. |
इन फ़ंक्शन कॉल के लिए डेटा को सीमित करके, हम यह पक्का करते हैं कि सिर्फ़ काम की जानकारी, तय किए गए फ़ॉर्मैट में कॉन्टेक्स्ट विंडो में शामिल हो. इससे टोकन के इस्तेमाल को ऑप्टिमाइज़ किया जा सकता है.
एजेंट के ऑपरेशन का उदाहरण
आइए, एक उदाहरण से समझते हैं कि एआई की मदद से काम करने वाली सुविधा, ज़्यादा जानकारी पाने के लिए फ़ंक्शन कॉलिंग का इस्तेमाल कैसे करती है. "यह अनुरोध पूरा होने में इतना समय क्यों लग रहा है?" वाले शुरुआती प्रॉम्प्ट के बाद, एआई की मदद से, इन फ़ंक्शन को एक-एक करके कॉल किया जा सकता है:
getEventByKey: उपयोगकर्ता की ओर से चुने गए अनुरोध के लिए, समय के बारे में पूरी जानकारी (टीटीएफ़बी, डाउनलोड करने में लगने वाला समय) फ़ेच करता है.getMainThreadTrackSummary: देखें कि अनुरोध शुरू होने के समय, मुख्य थ्रेड व्यस्त (ब्लॉक की गई) तो नहीं थी.getNetworkTrackSummary: यह विश्लेषण करें कि क्या उसी समय अन्य संसाधन बैंडविड्थ के लिए प्रतिस्पर्धा कर रहे थे.getInsightDetails: देखें कि क्या ट्रेस की खास जानकारी में पहले से ही कोई ऐसी अहम जानकारी दी गई है जो इस अनुरोध से जुड़ी है और परफ़ॉर्मेंस में रुकावट डाल रही है.
इन कॉल के नतीजों को मिलाकर, एआई की मदद से समस्या का पता लगाया जा सकता है. साथ ही, कार्रवाई करने के लिए सुझाव दिए जा सकते हैं. जैसे, getFunctionCode का इस्तेमाल करके कोड को बेहतर बनाने का सुझाव देना या getResourceContent के आधार पर संसाधन लोड करने की प्रोसेस को ऑप्टिमाइज़ करना.
हालांकि, काम का डेटा पाना सिर्फ़ आधा काम है. ज़्यादा जानकारी देने वाले फ़ंक्शन से भी, बहुत ज़्यादा डेटा मिल सकता है. एक और उदाहरण के तौर पर, getDetailedCallTree सैकड़ों नोड वाला ट्री दिखा सकता है. स्टैंडर्ड JSON में, नेस्टिंग के लिए सिर्फ़ { और } का इस्तेमाल किया जाता है!
इसलिए, एक ऐसे फ़ॉर्मैट की ज़रूरत है जो टोकन के हिसाब से किफ़ायती हो, लेकिन एलएलएम के लिए समझने और रेफ़रंस देने के लिए काफ़ी स्ट्रक्चर्ड हो.
डेटा को क्रम से लगाना
आइए, इस चुनौती को हल करने के हमारे तरीके के बारे में ज़्यादा जानें. इसके लिए, हम कॉल ट्री के उदाहरण का इस्तेमाल करेंगे. ऐसा इसलिए, क्योंकि परफ़ॉर्मेंस ट्रेस में ज़्यादातर डेटा कॉल ट्री से बना होता है. रेफ़रंस के लिए, यहां दिए गए उदाहरण में कॉल स्टैक में मौजूद एक टास्क को JSON में दिखाया गया है:
{
"id": 2,
"name": "animate",
"selected": true,
"duration": 150,
"selfTime": 20,
"children": [3, 5, 6, 7, 10, 11, 12]
}
एक परफ़ॉर्मेंस ट्रेस में इनमें से हज़ारों हो सकते हैं. जैसा कि यहां दिए गए स्क्रीनशॉट में दिखाया गया है. हर छोटे रंगीन बॉक्स को इस ऑब्जेक्ट स्ट्रक्चर का इस्तेमाल करके दिखाया जाता है.

यह फ़ॉर्मैट, DevTools में प्रोग्राम के हिसाब से काम करने के लिए अच्छा है. हालांकि, एलएलएम के लिए यह फ़ॉर्मैट काम का नहीं है. इसकी वजहें यहां दी गई हैं:
- अनावश्यक कुंजियां:
"duration","selfTime", और"children"जैसी स्ट्रिंग, कॉल ट्री के हर नोड के लिए दोहराई जाती हैं. इसलिए, अगर किसी मॉडल को 500 नोड वाला ट्री भेजा जाता है, तो वह उन सभी कुंजियों के लिए 500 बार टोकन इस्तेमाल करेगा. - ज़्यादा जानकारी वाली सूचियां:
childrenके ज़रिए हर चाइल्ड आईडी को अलग-अलग लिस्ट करने से, बहुत ज़्यादा टोकन खर्च होते हैं. ऐसा खास तौर पर उन टास्क के लिए होता है जो कई डाउनस्ट्रीम इवेंट ट्रिगर करते हैं.
परफ़ॉर्मेंस के लिए एआई की मदद से इस्तेमाल किए गए सभी डेटा के लिए, टोकन-इफ़िशिएंट फ़ॉर्मैट को लागू करने की प्रोसेस चरण-दर-चरण पूरी की गई.
पहला इटरेशन
जब हमने परफ़ॉर्मेंस के लिए एआई की मदद से काम करना शुरू किया, तब हमने शिपिंग की स्पीड को ऑप्टिमाइज़ किया. टोकन ऑप्टिमाइज़ेशन के लिए, हमने बुनियादी तरीका अपनाया. इसमें हमने मूल JSON से ब्रेसिज़ और कॉमा हटा दिए. इससे हमें इस तरह का फ़ॉर्मैट मिला:
allUrls = [...]
Node: 1 - update
Selected: false
Duration: 200
Self Time: 50
Children:
2 - animate
Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children:
3 - calculatePosition
5 - applyStyles
6 - applyStyles
7 - calculateLayout
10 - applyStyles
11 - applyStyles
12 - applyStyles
Node: 3 - calculatePosition
Selected: false
Duration: 15
Self Time: 2
URL: 0
Children:
4 - getBoundingClientRect
...
हालांकि, यह पहला वर्शन, रॉ JSON से थोड़ा ही बेहतर था. इसमें अब भी आईडी और नामों के साथ नोड चाइल्ड की सूची दी गई है. साथ ही, हर लाइन के आगे जानकारी देने वाली, बार-बार इस्तेमाल की गई कुंजियां (Node:, Selected:, Duration:, …) जोड़ी गई हैं.
चाइल्ड नोड की सूचियों को ऑप्टिमाइज़ करना
ऑप्टिमाइज़ेशन को बेहतर बनाने के लिए, हमने नोड के चाइल्ड के नाम हटा दिए हैं. उदाहरण के लिए, calculatePosition, applyStyles, … एआई असिस्टेंट के पास फ़ंक्शन कॉलिंग के ज़रिए सभी नोड का ऐक्सेस होता है. साथ ही, यह जानकारी पहले से ही नोड हेड (Node: 3 - calculatePosition) में मौजूद होती है. इसलिए, इस जानकारी को दोहराने की ज़रूरत नहीं है., इससे हमें Children को पूर्णांकों की एक आसान सूची में बदलने में मदद मिली:
Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children: 3, 5, 6, 7, 10, 11, 12
..
हालांकि, यह पहले की तुलना में काफ़ी बेहतर था, लेकिन अब भी इसमें सुधार किया जा सकता था. पिछले उदाहरण को देखने पर, आपको पता चल सकता है कि Children लगभग क्रम से है. इसमें सिर्फ़ 4, 8, और 9 मौजूद नहीं हैं.
इसकी वजह यह है कि हमने पहली बार परफ़ॉर्मेंस ट्रेस से ट्री डेटा को क्रम से लगाने के लिए, डेप्थ-फ़र्स्ट सर्च (डीएफ़एस) एल्गोरिदम का इस्तेमाल किया था. इस वजह से, सिबलिंग नोड के लिए आईडी क्रम से नहीं थे. इसलिए, हमें हर आईडी को अलग-अलग लिस्ट करना पड़ा.
हमें पता चला कि अगर हम ब्रेड्थ-फ़र्स्ट सर्च (बीएफ़एस) का इस्तेमाल करके ट्री को फिर से इंडेक्स करते हैं, तो हमें क्रम से आईडी मिलेंगे. इससे एक और ऑप्टिमाइज़ेशन किया जा सकेगा. अलग-अलग आईडी की सूची बनाने के बजाय, अब हम सैकड़ों बच्चों को भी एक ही कॉम्पैक्ट रेंज से दिखा सकते हैं. जैसे, मूल उदाहरण के लिए 3-9.
ऑप्टिमाइज़ की गई Children सूची के साथ फ़ाइनल नोड नोटेशन ऐसा दिखता है:
allUrls = [...]
Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children: 3-9
कुंजियों की संख्या कम करना
नोड की सूचियों को ऑप्टिमाइज़ करने के बाद, हमने गैर-ज़रूरी कुंजियों को हटाना शुरू किया. हमने पिछले फ़ॉर्मैट से सभी कुंजियां हटा दी हैं. इससे हमें यह मिला:
allUrls = [...]
2;animate;150;20;0;3-10
यह मॉडल, टोकन का कम इस्तेमाल करता है. हालांकि, हमें Gemini को यह निर्देश देना पड़ा कि वह इस डेटा को कैसे समझे. इसलिए, जब हमने पहली बार कॉल ट्री को Gemini पर भेजा, तो हमने यह प्रॉम्प्ट शामिल किया:
...
Each call frame is presented in the following format:
'id;name;duration;selfTime;urlIndex;childRange;[S]'
Key definitions:
* id: A unique numerical identifier for the call frame.
* name: A concise string describing the call frame (e.g., 'Evaluate Script', 'render', 'fetchData').
* duration: The total execution time of the call frame, including its children.
* selfTime: The time spent directly within the call frame, excluding its children's execution.
* urlIndex: Index referencing the "All URLs" list. Empty if no specific script URL is associated.
* childRange: Specifies the direct children of this node using their IDs. If empty ('' or 'S' at the end), the node has no children. If a single number (e.g., '4'), the node has one child with that ID. If in the format 'firstId-lastId' (e.g., '4-5'), it indicates a consecutive range of child IDs from 'firstId' to 'lastId', inclusive.
* S: **Optional marker.** The letter 'S' appears at the end of the line **only** for the single call frame selected by the user.
....
इस फ़ॉर्मैट के ब्यौरे के लिए टोकन की लागत लगती है. हालांकि, यह एक स्टैटिक लागत है, जिसे पूरी बातचीत के लिए एक बार चुकाया जाता है. पिछली बार ऑप्टिमाइज़ेशन करने से हुई बचत, इस बार के ऑप्टिमाइज़ेशन की लागत से ज़्यादा है.
नतीजा
एआई का इस्तेमाल करके कॉन्टेंट बनाते समय, टोकन के इस्तेमाल को ऑप्टिमाइज़ करना बहुत ज़रूरी है. हमने रॉ जेएसओएन से खास कस्टम फ़ॉर्मैट पर स्विच करके, ब्रड्थ-फ़र्स्ट सर्च की मदद से ट्री को फिर से इंडेक्स करके, और मांग पर डेटा फ़ेच करने के लिए टूल कॉल का इस्तेमाल करके, Chrome DevTools में एआई असिस्टेंस के इस्तेमाल किए गए टोकन की संख्या को काफ़ी कम कर दिया है.
परफ़ॉर्मेंस ट्रेस के लिए एआई की मदद से काम करने की सुविधा चालू करने के लिए, इन ऑप्टिमाइज़ेशन को लागू करना ज़रूरी था. कॉन्टेक्स्ट विंडो की सीमा कम होने की वजह से, यह इतने बड़े डेटा को प्रोसेस नहीं कर सकता. हालांकि, ऑप्टिमाइज़ किए गए फ़ॉर्मैट में परफ़ॉर्मेंस एजेंट की सुविधा मिलती है. यह एजेंट, बातचीत के इतिहास को लंबे समय तक सेव रख सकता है. साथ ही, बिना किसी रुकावट के ज़्यादा सटीक और संदर्भ के हिसाब से जवाब दे सकता है.
हमें उम्मीद है कि इन तकनीकों से आपको एआई के लिए डिज़ाइन करते समय, अपने डेटा स्ट्रक्चर पर दोबारा गौर करने में मदद मिलेगी. वेब ऐप्लिकेशन में एआई का इस्तेमाल शुरू करने के लिए, web.dev पर एआई के बारे में जानें पर जाएं.