पब्लिश होने की तारीख: 10 नवंबर, 2026
Policybazaar, भारत के सबसे लोकप्रिय बीमा प्लैटफ़ॉर्म में से एक है. इसके 9.7 करोड़ से ज़्यादा रजिस्टर्ड ग्राहक हैं. इसके करीब 80% ग्राहक, हर महीने वेबसाइट पर आते हैं. इसकी पैरंट कंपनी, PB Fintech ने हाल ही में Pensionbazaar लॉन्च किया है. यह रिटायरमेंट की प्लानिंग के लिए एक एंड-टू-एंड प्लैटफ़ॉर्म है. यह Paisabazaar Marketing & Consulting Private Limited का एक ब्रैंड है.
दोनों टीमें पहले से ही कोडिंग एजेंट का इस्तेमाल करती हैं. ये एजेंट तेज़ी से कोड लिखते हैं, लेकिन यह नहीं देख पाते कि वह कोड ब्राउज़र में क्या करता है. एजेंट अक्सर पुराने वेब पैटर्न का इस्तेमाल करते थे. उनके पास यह जांचने का कोई तरीका नहीं था कि स्क्रीन सही तरीके से रेंडर हुई है या नहीं. इसलिए, इंजीनियरों को अब भी हर चीज़ की पुष्टि मैन्युअल तरीके से करनी पड़ती थी.
इस समस्या को हल करने के लिए, दोनों कंपनियों ने अपने एजेंटिक वर्कफ़्लो में दो टूल शामिल किए: मॉडर्न वेब गाइडेंस, ताकि मॉडल को मॉडर्न वेब स्टैंडर्ड के बारे में सिखाया जा सके. साथ ही, एजेंट के लिए Chrome DevTools, ताकि एजेंट को लाइव और हेडलेस ब्राउज़र दिया जा सके. इससे वे अपने काम की जांच और पुष्टि कर सकते हैं.
इसका असर इस तरह होगा:
92%
Policybazaar के करीब 30 लैंडिंग पेजों पर, मैन्युअल तरीके से ऑडिट करने में लगने वाला समय कम हुआ
>90%
पेंशनबाज़ार के नए पेजों को डेवलप और टेस्ट करने में लगने वाला समय, करीब चार दिनों से घटकर कुछ घंटे हो गया
>90%
Pensionbazaar की नई स्क्रीन के लिए, यूज़र इंटरफ़ेस (यूआई) से जुड़ी कम गड़बड़ियां मिलीं
चुनौती: कोड तेज़ी से लिखना, पुष्टि करने में समय लगना
Policybazaar और Pensionbazaar को दो अलग-अलग समस्याओं का सामना करना पड़ा. स्टैंडर्ड एआई कोडिंग वर्कफ़्लो, प्रोडक्शन लेवल पर इन्हें ऑप्टिमाइज़ नहीं कर पाए.
Pensionbazaar: लंबी क्यूए साइकल वाली नई स्क्रीन
Pensionbazaar को कई नई और जटिल स्क्रीन की ज़रूरत थी. जैसे, कई चरणों वाला रिटायरमेंट फ़्रीडम स्कोर कैलकुलेटर, कस्टमाइज़ किए जा सकने वाले निवेश के खर्च के अनुमान, और अपने-आप मिलने वाली सुझाव की रिपोर्ट. टीम ने इन्हें कोडिंग एजेंट और Figma एमसीपी सर्वर की मदद से बनाया था. हालांकि, दो समस्याओं की वजह से क्यूए साइकल लंबे समय तक चलते रहे.
सबसे पहले, एजेंट को कोडिंग के बारे में कुछ नहीं पता था. कोई बेस मॉडल, कोड जनरेट कर सकता था. हालांकि, वह रेंडर किए गए इंटरफ़ेस को नहीं देख सकता था, कंप्यूट की गई स्टाइल की तुलना डिज़ाइन की खास बातों से नहीं कर सकता था, लेआउट में हुए बदलावों का पता नहीं लगा सकता था या नेटवर्क वॉटरफ़ॉल को नहीं पढ़ सकता था. इस वजह से, यूज़र इंटरफ़ेस (यूआई) के कटने और लेआउट शिफ़्ट होने जैसी समस्याएं, मैन्युअल क्यूए तक पहुंच गईं.
दूसरा, जनरेट किया गया कोड पुराने डेटा पर आधारित था. आधुनिक वेब प्लैटफ़ॉर्म की जानकारी न होने की वजह से, एजेंट ने पुराने तरीकों का इस्तेमाल किया. उन्होंने पहले से मौजूद <dialog> एलिमेंट का इस्तेमाल करने के बजाय, JavaScript के भारी-भरकम मॉडल लिखे, ग़ैर-ज़रूरी पॉलीफ़िल जोड़े, और परफ़ॉर्मेंस से जुड़े संकेत, जैसे कि fetchpriority को छोड़ दिया.
Policybazaar: 30 लैंडिंग पेज और मैन्युअल ऑडिट
Policybazaar की लाइफ़ इंश्योरेंस टीम, बीमा से जुड़े अलग-अलग प्रॉडक्ट के लिए करीब 30 लैंडिंग पेज चलाती है. साथ ही, हर पेज पर अलग-अलग मार्केटिंग कैंपेन के लिए अलग-अलग वैरिएंट हो सकते हैं. इन पर हर दिन दो से तीन लाख लोग आते हैं. साथ ही, हर पेज के डिज़ाइन और कारोबारी नियमों को हर महीने अपडेट किया जाता है. टीम को Core Web Vitals स्कोर को ज़्यादा रखना होगा. साथ ही, यह पक्का करना होगा कि हर वैरिएंट को ऐक्सेस किया जा सके और वह हर स्क्रीन साइज़ पर सही तरीके से रेंडर हो.
ऑटोमेशन से पहले, एक इंजीनियर हर पेज की मैन्युअल तरीके से जांच करता था:
- असल उपयोगकर्ता डेटा इकट्ठा करने के लिए, PageSpeed Insights चलाएं.
- Core Web Vitals के स्कोर और सुझावों का आकलन करें.
- डेवलपमेंट या स्टेजिंग बिल्ड की जांच करें. साथ ही, स्कोर के पीछे की समस्याओं का पता लगाएं और कोड से जुड़ी गड़बड़ियों को ठीक करें.
यह प्रोसेस धीमी थी, इसमें बार-बार एक ही काम करना पड़ता था, और इसे बड़े पैमाने पर लागू नहीं किया जा सकता था. इसकी वजह से, ऑप्टिमाइज़ेशन के मौके छूट जाते थे, ऑडिट कवरेज में अंतर होता था, परफ़ॉर्मेंस में गिरावट का पता नहीं चलता था, और रिलीज़ में देरी होती थी.
अपने वर्कफ़्लो में बदलाव करने से पहले, टीमों ने तीन लक्ष्य तय किए: परफ़ॉर्मेंस ऑडिट पर डेवलपर के खर्च होने वाले समय को 80% से ज़्यादा कम करना और ऑडिट कवरेज को लगातार जारी रखना, पुष्टि की गई रिपोर्ट की मदद से क्यूए टर्नअराउंड को कम करना, और यूज़र इंटरफ़ेस (यूआई) से जुड़ी गड़बड़ियों को कम करना. ऐसा इसलिए, क्योंकि स्क्रीन अपने वायरफ़्रेम से मैच नहीं करती थी.
समाधान: पुष्टि करने के लिए कोड का लूप
Pensionbazaar ने कोड लिखने और उसकी जांच करने के बीच के अंतर को कम किया. एजेंट, कोड लिखता है और ब्राउज़र का एक नया इंस्टेंस शुरू करता है. इसके बाद, वह प्रोग्राम के हिसाब से पेज की जांच करता है, ताकि विज़ुअल पैरिटी, लेआउट में गड़बड़ी, कंसोल की गड़बड़ियों, और परफ़ॉर्मेंस का पता लगाया जा सके. साथ ही, वह बिना किसी मानवीय मदद के, मिली समस्याओं को ठीक करता है. एजेंट को Figma MCP से डिज़ाइन मिलता है. इससे वह रेंडर किए गए पेज की तुलना, डिज़ाइनर के बनाए गए डिज़ाइन से कर सकता है.
इस वीडियो में, इस लूप को काम करते हुए दिखाया गया है. एजेंट, नई स्क्रीन के लिए Figma डिज़ाइन को पढ़ता है और उसे लागू करता है. इसके बाद, वह रेंडर किए गए पेज की जांच करने और उसमें मौजूद अंतर को ठीक करने के लिए, एजेंट के लिए Chrome DevTools का इस्तेमाल करता है.
पहला चरण: एजेंट को मॉडर्न वेब स्टैंडर्ड के साथ ग्राउंड करना
Pensionbazaar की टीम चाहती थी कि जनरेट किया गया कोड, मॉडर्न वेब के सबसे सही तरीकों का पालन करे, मौजूदा प्लैटफ़ॉर्म की सुविधाओं का इस्तेमाल करे, और पुराने ब्राउज़र पर भी काम करे. मैन्युअल तरीके से जांच करना मुश्किल होता है. साथ ही, एजेंट हमेशा प्लैटफ़ॉर्म के बारे में अप-टू-डेट नहीं रहते. मॉडर्न वेब गाइडेंस से यह समस्या हल हो जाती है. यह एजेंट की एक स्किल है. इसे Chrome और वेब कम्यूनिटी के वेब विशेषज्ञों ने लिखा है और वे ही इसका रखरखाव करते हैं. इसमें 200 से ज़्यादा इस्तेमाल के उदाहरण शामिल हैं. यह एजेंट को आधुनिक वेब प्लैटफ़ॉर्म एपीआई की ओर ले जाता है. साथ ही, परफ़ॉर्मेंस और सुलभता के सबसे सही तरीकों की ओर ले जाता है, जो आपके बेसलाइन टारगेट के हिसाब से सही हों. अगर आपने कोई टारगेट सेट नहीं किया है, तो यह डिफ़ॉल्ट रूप से बेसलाइन वाइडली अवेलेबल पर सेट हो जाता है.
Figma फ़ाइलों से कॉन्टेक्स्ट फ़ेच करने के बाद, एजेंट कोड लिखते समय मॉडर्न वेब गाइडेंस का इस्तेमाल करता है. पेंशनबाज़ार के लिए, इससे कोड में तीन तरह के बदलाव हुए:
- नेटिव एलिमेंट ने JavaScript के वर्कअराउंड की जगह ले ली. एजेंट ने प्लान की जानकारी वाले मॉडल के लिए, पहले से मौजूद
<dialog>एलिमेंट और Popover API का इस्तेमाल किया. साथ ही, वित्तीय खास जानकारी वाले कार्ड के लिए, सीएसएस ग्रिड और फ़्लेक्सबॉक्स का इस्तेमाल किया. - एजेंट ने परफ़ॉर्मेंस से जुड़े ऐसे संकेत जोड़े जो आम तौर पर बेस मॉडल में नहीं होते.
इनमें, हीरो एलसीपी इमेज पर
fetchpriority="high", पेज के फ़ोल्ड के नीचे मौजूद प्लान कार्ड परloading="lazy", औरscheduler.yield()के साथ समय के हिसाब से एक्ज़ीक्यूशन बजट शामिल था. इससे पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को सुरक्षित रखा जा सकता है. - नई सुविधाओं की वजह से, पुराने ब्राउज़र पर वेबसाइटें काम करना बंद नहीं करती थीं. Pensionbazaar, ब्राउज़र के पुराने वर्शन के साथ काम करता है. इसके बारे में Browserslist में बताया गया है. एजेंट ने एक बार इस्तेमाल होने वाले पासवर्ड (ओटीपी) के फ़ील्ड में,
:user-invalidसीएसएस स्यूडो-क्लास औरautoComplete="one-time-code"जैसी सुविधाओं का इस्तेमाल किया. पुराने ब्राउज़र इन्हें अनदेखा कर देते हैं और मुख्य फ़ंक्शन काम करते रहते हैं.
बेस मॉडल भी ज़्यादा पीछे नहीं थे. परफ़ॉर्मेंस के मामले में, टीम ने पाया कि वे सबसे सही तरीकों के साथ करीब 70% अलाइन थे. एजेंट की अपनी रिपोर्ट में, मॉडर्न वेब गाइडेंस के 12 नियम शामिल थे. इनसे बाकी की कमियां भी दूर हो गईं. चार उदाहरण:
| क्षेत्र | बेस मॉडल गैप | मॉडर्न वेब गाइडेंस का नियम |
|---|---|---|
| इमेज लोड हो रही है | एक-दूसरे से मेल न खाने वाले कॉम्बिनेशन, जैसे कि fetchpriority="high" को loading="lazy" के साथ जोड़ना. |
इन्हें एक साथ इस्तेमाल करने पर साफ़ तौर पर पाबंदी लगाता है. साथ ही, हर पेज पर ज़्यादा प्राथमिकता वाली इमेज की संख्या को एक या दो तक सीमित करता है. |
| लेआउट की स्थिरता | परफ़ॉर्मेंस के लिए content-visibility: auto का सुझाव दिया गया, लेकिन contain-intrinsic-size को शामिल नहीं किया गया. |
कॉन्टेंट रेंडर होने पर, लेआउट में होने वाले बड़े बदलावों को रोकने के लिए, दोनों प्रॉपर्टी को जोड़ना ज़रूरी है. |
| मुख्य थ्रेड को रोकना | scheduler.yield() का इस्तेमाल सामान्य तौर पर किया गया है. इसमें समयसीमा का कोई पैटर्न नहीं है. |
पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को सुरक्षित रखने के लिए, समय के हिसाब से तय की गई समयसीमा (performance.now() + 50) को सख्ती से लागू करता है. |
| सर्विस वर्कर कैश मेमोरी | ऑफ़लाइन फ़ॉर्म सबमिशन को शामिल नहीं किया गया. | एजेंट को चेतावनी देता है कि सर्विस वर्कर, जीईटी अनुरोध के अलावा अन्य अनुरोधों को नेटिव तौर पर कैश मेमोरी में सेव नहीं कर सकते. |
पेंशनबाज़ार के लिए, हमारी प्राथमिकता पहले दिन से ही अच्छी क्वालिटी का कोड बनाना था, ताकि बाद में तकनीकी समस्याओं का सामना न करना पड़े. मॉडर्न वेब गाइडेंस ने हमारे कोडिंग एजेंट को मॉडर्न वेब स्टैंडर्ड और परफ़ॉर्मेंस के सबसे सही तरीकों को अपनाने के लिए प्रेरित किया. साथ ही, ब्राउज़र के साथ काम करने के हमारे खास लक्ष्यों का भी ध्यान रखा. इससे हमारे फ़्रंटएंड कोड रिव्यू काफ़ी आसान और तेज़ हो गए. साथ ही, हमारे डेवलपमेंट में लगने वाला समय भी कम हो गया.
अमन सोनी, इंजीनियरिंग मैनेजर, Policybazaar
दूसरा चरण: एजेंट को ब्राउज़र का ऐक्सेस देना
एजेंट के लिए Chrome DevTools, टूल का एक सेट है. इसमें एमसीपी सर्वर, सीएलआई, और एजेंट स्किल शामिल हैं. इनकी मदद से, कोडिंग एजेंट को रनटाइम डीबगिंग डेटा का रीयल-टाइम ऐक्सेस मिलता है. जैसे, कंसोल लॉग, नेटवर्क ट्रैफ़िक, सुलभता ट्री, और DevTools की अन्य सुविधाएं.
टीम ने अपने कोडिंग एजेंट Claude Code में, एजेंट के लिए Chrome DevTools को प्लग इन के तौर पर इंस्टॉल किया:
# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins
टीम चाहती थी कि हर टेस्ट, ब्राउज़र के क्लीन इंस्टेंस में चलाया जाए, ताकि इंस्टॉल किए गए Chrome एक्सटेंशन, नतीजों पर असर न डाल सकें. साथ ही, निजी या संवेदनशील डेटा लीक न हो. इसके लिए, एमसीपी सर्वर के कॉन्फ़िगरेशन में args कलेक्शन में --isolated जोड़ें:
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
अगर आपको टेस्ट के लिए, साइन इन किए हुए मौजूदा ब्राउज़र सेशन की ज़रूरत है, तो
--autoConnect का इस्तेमाल करें.
तीसरा चरण: एजेंट को अपने काम की जांच करने और उसे ठीक करने की अनुमति देना
इंजीनियरिंग टीम, एजेंट के निर्देशों में जांचों की सूची बनाती है. यह सूची, प्रॉम्प्ट या एजेंट की स्किल के तौर पर बनाई जाती है. मोटे तौर पर, एजेंट ये काम करता है:
- यह डीओएम ट्री और कंप्यूट की गई सीएसएस की जांच करता है. साथ ही, उनकी तुलना Figma डिज़ाइन से करता है.
- यह पेज के साइज़ को मोबाइल व्यूपोर्ट के हिसाब से बदलता है, ताकि यह जांचा जा सके कि पेज अलग-अलग स्क्रीन साइज़ के हिसाब से सही तरीके से काम करता है या नहीं.
- यह स्क्रिप्ट, रेंडर-ब्लॉकिंग रिसॉर्स, और परफ़ॉर्मेंस से जुड़ी अन्य समस्याओं की वजह से होने वाले लंबे ऐनिमेशन फ़्रेम (एलओएएफ़) का पता लगाने के लिए, परफ़ॉर्मेंस ट्रेस रिकॉर्ड करता है.
- यह कोड को फिर से लिखता है, ताकि डिज़ाइन से जुड़ी गड़बड़ियों, परफ़ॉर्मेंस की समस्याओं, और कंसोल से जुड़ी गड़बड़ियों को ठीक किया जा सके. इसके बाद, कोई इंजीनियर इसकी समीक्षा करता है.
यहां दी गई टेबल में बताया गया है कि एजेंट के लिए Chrome DevTools के कौनसे टूल, हर जांच के साथ काम करते हैं:
| चेक | टूल |
|---|---|
| अलग-अलग व्यूपोर्ट पर रिस्पॉन्सिवनेस की जांच करना | resize_page, पेज की विंडो का साइज़ बदलकर, उसे तय किए गए डाइमेंशन के मुताबिक कर देता है. emulate, खास डिवाइस के एनवायरमेंट को एम्युलेट करता है. take_screenshot, नतीजे को कैप्चर करता है. |
| डीओएम और कंप्यूट की गई सीएसएस की तुलना Figma डिज़ाइन से करें | take_snapshot, सुलभता ट्री के आधार पर पेज का टेक्स्ट स्नैपशॉट दिखाता है. get_css_styles, लागू किए गए सीएसएस नियमों को पढ़ता है. evaluate_script, पेज में JavaScript फ़ंक्शन चलाता है. |
| LoAF, रेंडर-ब्लॉकिंग रिसॉर्स, और Core Web Vitals से जुड़ी समस्याएं ढूंढना | click और drag, इंटरैक्शन को एम्युलेट करते हैं. performance_start_trace और performance_stop_trace, परफ़ॉर्मेंस ट्रेस रिकॉर्ड करते हैं. performance_analyze_insight, ट्रेस में मौजूद अहम जानकारी के लिए, गड़बड़ी की पूरी जानकारी देने वाला पेज दिखाता है. list_network_requests और get_network_request, नेटवर्क पर की जाने वाली गतिविधि दिखाते हैं. lighthouse_audit, एसईओ और सुलभता जैसी परफ़ॉर्मेंस से अलग चीज़ों का ऑडिट करता है. |
जब एजेंट को कोई समस्या मिलती है, जैसे कि छोटी स्क्रीन पर टेक्स्ट का कट जाना, फ़्लेक्स रैप का काम न करना या ऑप्टिमाइज़ न की गई इमेज की वजह से लेआउट शिफ़्ट होना, तो वह समस्या को ठीक करने के लिए एक छोटा लूप चलाता है:
- एजेंट के लिए Chrome DevTools, गड़बड़ी की सटीक जानकारी कैप्चर करता है.
- एजेंट, डेटा का विश्लेषण करता है और समस्या वाली सीएसएस या JavaScript को फिर से लिखता है.
- एजेंट, समस्या ठीक होने की पुष्टि करने के लिए पेज को फिर से लोड करता है.
एक स्क्रीन पर, एजेंट ने पेज को रेंडर किया और पाया कि हेडर का लेआउट, स्पेसिंग, और ग्रेडिएंट, डिज़ाइन से मेल नहीं खाते. इससे, .scss फ़ाइलों को ठीक कर दिया गया है. इसने पेज के साथ इंटरैक्ट भी किया. जैसे, अकॉर्डियन को बड़ा करके यह देखना कि उनके खुले होने की स्थितियां, डिज़ाइन से मेल खाती हैं या नहीं.
चौथा चरण: क्यूए टीम को पुष्टि की गई रिपोर्ट सौंपना
पुष्टि होने के बाद, एजेंट प्रोडक्शन के लिए तैयार कोड डिलीवर करता है. साथ ही, QA टीम के लिए ऑडिट रिपोर्ट भी उपलब्ध कराता है. इस रिपोर्ट में शामिल हैं:
- Figma डिज़ाइन के साथ विज़ुअल की तुलना, जो पिक्सल के अंतर को हाइलाइट करती है. इसे स्क्रीनशॉट, डीओएम स्नैपशॉट, और कंप्यूट की गई स्टाइल से बनाया गया है.
- अलग-अलग स्क्रीन साइज़ पर रेंडर किए गए पेज के स्क्रीनशॉट.
performance_start_traceऔरperformance_analyze_insightसे मिली, Core Web Vitals और परफ़ॉर्मेंस से जुड़ी गड़बड़ी की जानकारी. जैसे, Speed Index और पेज रिस्पॉन्स बंद रहने का कुल समय (टीबीटी).lighthouse_auditसे एसईओ, सबसे सही तरीकों, और सुलभता के लिए Lighthouse स्कोर.- इंटरैक्शन के लिए पास या फ़ेल की जांच, जैसे कि पंक्तियों और टॉगल को छोटा करना. साथ ही, कंसोल की गड़बड़ियां और ऐप्लिकेशन की स्थिति में बदलाव, जैसे कि पंक्तियों में बदलाव करना, पंक्तियों को मिटाना, और खाली स्थितियां.
30 कैंपेन पेजों पर एक जैसी रणनीति अपनाएं
Policybazaar ने अपने मुख्य प्लैटफ़ॉर्म पर, PageSpeed Insights की मदद से मैन्युअल तरीके से ऑडिट करने की सुविधा को हटा दिया. इसकी जगह, Kiro में एजेंट के लिए Chrome DevTools की मदद से ऑडिट करने की सुविधा को जोड़ा. कैंपेन पेज के लाइव होने से पहले, एक इंजीनियर मोबाइल और डेस्कटॉप के लिए, स्टेजिंग यूआरएल का ऑडिट ट्रिगर करता है. एजेंट, परफ़ॉर्मेंस और Lighthouse ऑडिट चलाता है. साथ ही, एजेंट के लिए Chrome DevTools, लैब डेटा के साथ-साथ Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) का रीयल-वर्ल्ड फ़ील्ड डेटा अपने-आप फ़ेच करता है. इसने PageSpeed Insights के चरण को पूरी तरह से बदल दिया.
इसके बाद, एजेंट परफ़ॉर्मेंस स्कोर, मिली गड़बड़ियां, और सुधारों की प्राथमिकता वाली सूची की जानकारी देता है, ताकि इंजीनियर उन्हें ठीक कर सके. रिलीज़ से पहले किए गए एक ऑडिट में, इसने उन एपीआई कॉल को फ़्लैग किया जो पेज लोड होने के दौरान एक के बाद एक ट्रिगर हुए और ज़रूरी रेंडरिंग प्रोसेस में रुकावट डाली. टीम ने पेज लाइव होने से पहले ही समस्या को ठीक कर दिया.
अब एजेंट, परफ़ॉर्मेंस के 12 ऑडिट उतने समय में पूरा कर लेता है जितने समय में एक इंजीनियर एक ऑडिट पूरा करता है. इसका मतलब है कि मैन्युअल तरीके से काम करने में लगने वाले समय में 92% की कमी आई.
उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, वेब परफ़ॉर्मेंस को बेहतर बनाए रखना हमारे लिए ज़रूरी है. हालांकि, दर्जनों लैंडिंग पेजों को मैन्युअल तरीके से ऑडिट करना, वॉटरफ़ॉल और ट्रेस का आकलन करना मुश्किल था. साथ ही, इसमें काफ़ी समय भी लगता था. एजेंट के लिए Chrome DevTools ने इस प्रोसेस को पूरी तरह बदल दिया. इससे हमारे इंजीनियर को परफ़ॉर्मेंस ऑडिट करने में 92% कम समय लगा. इससे उन्हें ज़्यादा मुश्किल टास्क पर फ़ोकस करने का मौका मिला.
अमन सोनी, इंजीनियरिंग मैनेजर, Policybazaar
असर
मॉडर्न वेब गाइडेंस और एजेंट के लिए Chrome DevTools की मदद से, Policybazaar और Pensionbazaar में फ़्रंटएंड टेस्टिंग की प्रोसेस को मैन्युअल और रिएक्टिव से ऑटोमेटेड और प्रोऐक्टिव बनाया गया. यहां दी गई टेबल में, बदलाव से पहले और बाद के वर्कफ़्लो की तुलना की गई है:
| क्षेत्र | पहले: मैन्युअल समीक्षा और बेस मॉडल | बाद में: मॉडर्न वेब गाइडेंस और एजेंट के लिए Chrome DevTools |
|---|---|---|
| परफ़ॉर्मेंस ऑडिटिंग की कोशिश (Policybazaar) | एक इंजीनियर ने PageSpeed Insights का इस्तेमाल किया, Core Web Vitals की समीक्षा की, और करीब 30 लैंडिंग पेजों में से हर एक के लिए मैन्युअल तरीके से सुधार लागू किए. | मैन्युअल तरीके से काम करने में 92% कम समय लगा. एजेंट ने उतने समय में 12 ऑडिट पूरे किए जितने में एक इंजीनियर ने एक ऑडिट किया. |
| ऑडिट कवरेज (Policybazaar) | कैंपेन के अलग-अलग वैरिएंट के लिए, ऑडिट कवरेज अलग-अलग था. | कैंपेन पेजों के लिए, परफ़ॉर्मेंस टेस्ट कवरेज 100% है. |
| New screen turnaround (Pensionbazaar) | कोड मिलने के बाद, पुष्टि होने में कुछ दिन लगते हैं. | कुछ घंटे, 90% से ज़्यादा तेज़. |
| डिज़ाइन पैरिटी से जुड़ी गड़बड़ियां (Pensionbazaar) | क्लिप किए गए यूज़र इंटरफ़ेस (यूआई) और लेआउट शिफ़्ट की मैन्युअल तरीके से क्वालिटी की जांच की गई. | यूज़र इंटरफ़ेस (यूआई) से जुड़ी गड़बड़ियों की संख्या में 90% से ज़्यादा की कमी आई. |
92% की कमी, टीम के 80% से ज़्यादा के लक्ष्य से ज़्यादा थी. लैंडिंग पेज के रिग्रेशन, स्टेजिंग या क्यूए तक पहुंचने से पहले ही पकड़ लिए जाते हैं. Pensionbazaar पर, कोड की जांच पहले ही हो जाती है. साथ ही, कई व्यूपोर्ट के स्क्रीनशॉट भी मिल जाते हैं. इससे डिज़ाइन, इंजीनियरिंग, और क्वालिटी अश्योरेंस के बीच होने वाली बातचीत कम हो जाती है.
आपकी टीम के लिए ज़रूरी बातें
- अपने एजेंट को भरोसेमंद दिशा-निर्देशों के आधार पर ट्रेनिंग दें. मॉडर्न वेब गाइडेंस जैसे चुने गए दिशा-निर्देश, एजेंट को पुराने पैटर्न से दूर रखते हैं. साथ ही, आपके कोड को बेसलाइन टारगेट के दायरे में रखते हैं.
- जब तक एजेंट रेंडर किए गए पेज की जांच न कर ले, तब तक उसे फ़्रंटएंड टास्क को पूरा हुआ के तौर पर मार्क न करने दें. एजेंट के लिए Chrome DevTools की मदद से, एजेंट किसी असली ब्राउज़र में लेआउट, व्यूपोर्ट, और परफ़ॉर्मेंस ट्रेस की जांच कर सकता है.
- लूप से बाहर निकलने के लिए, साफ़ तौर पर शर्तें तय करें. चरणों की सीमाएं सेट करें. साथ ही, पास और फ़ेल होने की साफ़ तौर पर शर्तें तय करें, ताकि एजेंट लूप में न फंसे और टोकन बर्बाद न हों.
- सबसे पहले, टेंप्लेट के हिसाब से बनाए गए उन पेजों को माइग्रेट करें जिन्हें अक्सर ऐक्सेस किया जाता है. क्लोज़्ड-लूप वर्कफ़्लो का सबसे ज़्यादा फ़ायदा तब मिलता है, जब काम को तेज़ी से पूरा करना ज़रूरी हो.
- क्लीन ब्राउज़र में ऑडिट चलाएं.
--isolatedका इस्तेमाल करें, ताकि एक्सटेंशन और कैश मेमोरी में सेव किया गया डेटा, नतीजों पर असर न डाले या निजी डेटा को ज़ाहिर न करे.