تاریخ انتشار: ۱۰ نوامبر ۲۰۲۶
Policybazaar یکی از پلاتفرم‌های پیشرو بیمه در هند است که بیش‌از ۹۷ میلیون مشتری ثبت‌شده دارد. حدود ۸۰٪ مشتریانش هر ماه از وب‌سایت بازدید می‌کنند. شرکت مادر آن، PB Fintech، اخیراً Pensionbazaar را راه‌اندازی کرده است، یک پلاتفرم برنامه‌ریزی بازنشستگی سرتاسری، که نمانامی تحت Paisabazaar Marketing & Consulting Private Limited است.
هر دو تیم از قبل از عامل‌های کدنویسی استفاده می‌کنند که کد را به‌سرعت می‌نویسند، اما نمی‌توانند ببینند که آن کد در مرورگر چه کاری انجام می‌دهد. عوامل اغلب به الگوهای وب قدیمی دسترسی داشتند و راهی برای بررسی اینکه آیا صفحه به‌درستی رندر شده است یا نه نداشتند، بنابراین مهندسان همچنان مجبور بودند همه چیز را به‌صورت دستی تأیید کنند.
برای حل این مشکل، هر دو شرکت دو ابزار را در گردش کار عامل خود ترکیب کردند: راهنمای وب نوین برای آموزش استانداردهای وب نوین به مدل‌ها، و Chrome DevTools برای عامل‌ها برای ارائه یک مرورگر زنده و بدون واسط به آن عامل‌ها جهت بازرسی و تأیید کارشان.
تأثیر آن به این صورت است:
۹۲٪
تلاش کمتر برای ممیزی دستی در حدود ۳۰ صفحه مقصد Policybazaar
>۹۰٪
زمان توسعه و آزمایش سریع‌تر برای صفحه‌های جدید Pensionbazaar، از حدود چهار روز به چند ساعت
>۹۰٪
اشکالات واسط کاربر کمتری در صفحه‌های جدید Pensionbazaar گزارش شد
چالش: کد سریع، درستی‌سنجی کند
Policybazaar و Pensionbazaar با دو گلوگاه متفاوت مواجه شدند که گردش کارهای استاندارد کدنویسی هوش مصنوعی نمی‌توانستند آن‌ها را در سطح تولید بهینه‌سازی کنند.
Pensionbazaar: صفحه‌های جدید با چرخه‌های طولانی تضمین کیفیت
Pensionbazaar به ده‌ها صفحه جدید و پیچیده نیاز داشت، مانند ماشین‌حساب چندمرحله‌ای «امتیاز آزادی بازنشستگی»، پیش‌بینی‌های قابل‌سفارشی‌سازی هزینه سرمایه‌گذاری، و گزارش‌های توصیه‌ای خودکار. تیم آن‌ها را با عوامل کدنویسی و سرور MCP Figma ساخت، اما دو مشکل باعث شد چرخه‌های تضمین کیفیت طولانی بماند.
ابتدا، عامل‌ها در تاریکی کدنویسی می‌کردند. مدل پایه می‌تواند کد تولید کند، اما نمی‌تواند میانای رندرشده را ببیند، سبک‌های محاسبه‌شده را با مشخصات طراحی مقایسه کند، تغییرات چیدمان را شناسایی کند، یا آبشار شبکه را بخواند. بنابراین مشکلات مرتبطی مثل رابط کاربری بریده‌شده و تغییرات چیدمان تا مرحله تضمین کیفیت دستی پیش رفتند.
دوم اینکه کد تولیدشده در گذشته گیر کرده بود. بدون آگاهی از پلاتفرم وب مدرن، عامل‌ها به راه‌حل‌های قدیمی روی آوردند، به‌جای استفاده از عنصر داخلی <dialog>، مدال‌های سنگین جاوا اسکریپت نوشتند، شبیه‌سازهای مرورگر غیرضروری اضافه کردند، و نکات عملکردی مانند fetchpriority را نادیده گرفتند.
Policybazaar: ۳۰ صفحه مقصد و یک ممیزی دستی
تیم بیمه عمر Policybazaar حدود ۳۰ صفحه مقصد برای محصولات بیمه مختلف اجرا می‌کند و هر صفحه می‌تواند برای کمپین‌های بازاریابی مختلف تغییراتی داشته باشد. این دو سایت درمجموع روزانه ۲۰۰٬۰۰۰ تا ۳۰۰٬۰۰۰ بازدیدکننده دارند و هر صفحه به‌روزرسانی‌های ماهانه طراحی و منطق کسب‌وکار دریافت می‌کند. تیم باید امتیازهای Core Web Vitals را بالا نگه دارد و مطمئن شود که هر گونه قابل‌دسترس باقی می‌ماند و به‌درستی در هر اندازه صفحه‌نمایش ارائه می‌شود.
پیش‌از خودکارسازی، مهندسی هر صفحه را به‌صورت دستی ممیزی می‌کرد:
- PageSpeed Insights را اجرا کنید تا داده‌های کاربر واقعی را جمع‌آوری کنید.
- امتیازها و توصیه‌های «معیارهای کلیدی اصلی وب» را ارزیابی کنید.
- ساخت توسعه یا آماده‌سازی را بازرسی کنید، مشکلات پشت امتیازها را تشخیص دهید، و اصلاحات کد را اعمال کنید.
این فرایند کند، تکراری، و غیرقابل‌توسعه بود. این امر باعث می‌شد بهینه‌سازی‌ها ازقلم بیفتد، پوشش ممیزی ناسازگار باشد، پسرفتهای عملکرد شناسایی نشود، و انتشارها به‌تأخیر بیفتد.
تیم‌ها قبل‌از تغییر گردش کار خود، سه هدف تعیین کردند: کاهش زمان صرف‌شده توسط توسعه‌دهندگان برای ممیزی‌های عملکرد به میزان بیش‌از ۸۰٪ و درعین‌حال تداوم پوشش ممیزی، کوتاه‌تر کردن زمان تضمین کیفیت با گزارش‌های تأییدشده، و کاهش اشکالات میانای کاربر که به‌دلیل عدم تطابق صفحه با قاب سیمی آن ایجاد شده بود.
راه‌حل: حلقه کد برای درستی‌سنجی
Pensionbazaar فاصله بین نوشتن کد و بررسی آن را ازبین برد. عامل کد را می‌نویسد، یک نمونه مرورگر تمیز را راه‌اندازی می‌کند، صفحه را به‌صورت برنامه‌نویسی‌شده برای برابری بصری، شکستگی چیدمان، خطاهای کنسول و عملکرد ممیزی می‌کند، و مشکلات یافت‌شده را با حداقل مداخله انسانی برطرف می‌کند. عامل آن‌ها طرح را از Figma MCP دریافت می‌کند تا بتواند صفحه رندرشده را با آنچه طراحان درنظر داشتند مقایسه کند.
ویدیو زیر این حلقه را در عمل نشان می‌دهد. عامل طرح‌های Figma را برای صفحه جدید می‌خواند، آن را پیاده‌سازی می‌کند، و سپس از Chrome DevTools برای عامل‌ها استفاده می‌کند تا صفحه پردازش‌شده را بازرسی کند و تفاوت‌هایی را که پیدا می‌کند برطرف کند.
مرحله ۱: زمینه‌سازی کردن عامل در استانداردهای وب مدرن
تیم Pensionbazaar می‌خواست کد تولیدشده از بهترین شیوه‌های وب مدرن پیروی کند، از ویژگی‌های پلاتفرم فعلی استفاده کند، و همچنان در مرورگرهای قدیمی‌تر کار کند. بررسی دستی این موارد خسته‌کننده است و نمایندگان همیشه با پلاتفرم به‌روز نیستند. راهنمای وب نوین این مشکل را حل می‌کند. این یک مهارت عامل است که توسط کارشناسان وب از Chrome و انجمن وب نوشته و نگهداری می‌شود و بیش‌از ۲۰۰ مورد استفاده را پوشش می‌دهد. این ابزار عامل‌ها را به‌سمت میاناهای برنامه‌سازی کاربردی پلاتفرم وب مدرن و به‌سمت روال‌های مطلوب عملکرد و دسترس‌پذیری که با هدف «خط پایه» شما مطابقت دارد هدایت می‌کند. اگر هدفی تنظیم نکنید، به‌طور پیش‌فرض روی Baseline Widely Available تنظیم می‌شود.
پس‌از اینکه نماینده بافت را از فایل‌های Figma استخراج کرد، از «راهنمای وب نوین» برای نوشتن کد استفاده می‌کند. برای Pensionbazaar، این امر کد را به سه روش تغییر داد:
- عناصر بومی جایگزین راه‌حل‌های جاوا اسکریپت شدند. این عامل از عنصر توکار
<dialog>و Popover API برای مدال‌های جزئیات طرح، و از CSS Grid و Flexbox برای کارت‌های خلاصه مالی استفاده کرد. - عامل نکته‌های عملکردی را اضافه کرد که مدل‌های پایه معمولاً آن‌ها را حذف می‌کنند.
این موارد شامل
fetchpriority="high"در تصاویر LCP قهرمان،loading="lazy"در کارت‌های طرح زیر خط تا، و بودجه اجرای مبتنی بر زمان باscheduler.yield()برای محافظت از تعامل با رنگ بعدی (INP) بود. - ویژگی‌های نو مرورگرهای قدیمی‌تر را خراب نمی‌کردند. Pensionbazaar از نسخه‌های قدیمی‌تر مرورگر پشتیبانی می‌کند که آن‌ها را در Browserslist تعریف می‌کند. عامل از ویژگی‌هایی مثل
:user-invalidکلاس کاذب CSS وautoComplete="one-time-code"در فیلد گذرواژه یک‌بارمصرف (OTP) استفاده کرده است. مرورگرهای قدیمی‌تر آن‌ها را نادیده می‌گیرند و عملکرد اصلی همچنان کار می‌کند.
مدل‌های پایه چندان دور نبودند. ازنظر عملکرد، تیم متوجه شد که حدود ۷۰٪ با روال‌های مطلوب هم‌راستا هستند. گزارش خود نماینده ۱۲ قانون «راهنمای وب نوین» را فهرست کرد که شکاف باقی‌مانده را بست. چهار مثال:
| منطقه | شکاف مدل پایه | قانون «راهنمای وب نوین» |
|---|---|---|
| بار کردن تصویر | ترکیب‌های متناقض توهمی، مثل جفت کردن fetchpriority="high" با loading="lazy". |
ترکیب کردن آن‌ها را صریحاً ممنوع می‌کند و تصاویر با اولویت بالا را به یک یا دو تصویر در هر صفحه محدود می‌کند. |
| پایداری چیدمان | content-visibility: auto برای عملکرد پیشنهاد شد، اما contain-intrinsic-size حذف شد. |
برای جلوگیری از تغییرات شدید طرح‌بندی هنگام ارائه محتوا، باید این دو ویژگی را جفت کنید. |
| واگذاری رشته اصلی | از scheduler.yield() به‌صورت عمومی و بدون الگوی مهلت استفاده شده است. |
برای محافظت از «تعامل تا ترسیم بعدی» (INP)، مهلت زمانی سخت‌گیرانه‌ای (performance.now() + 50) اعمال می‌کند. |
| ذخیره‌سازی موقت «عامل خدماتی» | ارسال‌های فرم آفلاین را درنظر نگرفته‌اید. | به عامل هشدار می‌دهد که Service Workers نمی‌تواند درخواست‌های غیر GET را به‌طور بومی در حافظه پنهان ذخیره کند. |
برای Pensionbazaar، اولویت ما ساختن کد باکیفیت از روز اول بود تا بعداً از بدهی فنی جلوگیری کنیم. «راهنمای وب نوین» عامل کدنویسی ما را هدایت کرد تا استانداردهای وب نوین و روال‌های مطلوب عملکرد را اتخاذ کند و درعین‌حال به اهداف سازگاری مرورگر خاص ما احترام بگذارد. این کار بازبینی کد فرانت‌اند ما را به‌طور قابل‌توجهی آسان‌تر و سریع‌تر کرد و درنهایت زمان چرخه توسعه ما را بهبود بخشید.
آمان سونی، مدیر مهندسی، Policybazaar
مرحله ۲: ارائه مرورگر به نماینده
Chrome DevTools برای عامل‌ها مجموعه‌ای از ابزارها است، ازجمله یک سرور MCP، یک CLI، و مهارت‌های عامل، که به عامل‌های کدنویسی دسترسی هم‌زمان به داده‌های اشکال‌زدایی زمان اجرا، مانند گزارش‌های کنسول، ترافیک شبکه، درخت دسترس‌پذیری، و سایر قابلیت‌های DevTools می‌دهد.
تیم Chrome DevTools برای عامل‌ها را به‌عنوان افزونه در عامل کدنویسی خود، Claude Code، نصب کرد:
# 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 نصب‌شده نتوانند بر نتایج تأثیر بگذارند و داده‌های شخصی یا حساس لو نروند. برای دریافت آن،
--isolated را به آرایه args
در پیکربندی سرور MCP اضافه کنید:
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
اگر آزمایش‌هایتان به جلسه مرورگر واردشده به سیستم موجود نیاز دارد، از
--autoConnect استفاده کنید.
مرحله ۳: اجازه دهید نماینده کار خودش را بررسی و اصلاح کند
تیم مهندسی بررسی‌ها را در دستورالعمل‌های عامل، به‌صورت پیام‌واره یا مهارت عامل، فهرست می‌کند. در سطح بالا، عامل کارهای زیر را انجام می‌دهد:
- درخت DOM و CSS محاسبه‌شده را بازرسی می‌کند و آن‌ها را با طرح Figma مقایسه می‌کند.
- اندازه صفحه را به اندازه نمای تلفن همراه تغییر می‌دهد تا واکنش‌گرایی را آزمایش کند.
- ردیابی‌های عملکرد را برای یافتن قاب‌های پویانمایی طولانی (LoAF) ناشی از دستورگان‌ها، منابع مسدودکننده رندر، و دیگر مشکلات عملکردی ضبط می‌کند.
- پیش‌از اینکه مهندس کد را بازبینی کند، آن را بازنویسی می‌کند تا عدم تطابق طراحی، مشکلات عملکرد، و استثناهای کنسول را برطرف کند.
جدول زیر نشان می‌دهد کدام‌یک از ابزارهای Chrome DevTools برای عامل‌ها از هریک از این بررسی‌ها پشتیبانی می‌کند:
| بررسی کردن | ابزارها |
|---|---|
| آزمایش پاسخ‌گویی در سراسر ناحیه‌های نمایش | resize_page اندازه پنجره صفحه را به ابعاد صریح تغییر می‌دهد. emulate محیط‌های دستگاه خاصی را شبیه‌سازی می‌کند. take_screenshot نتیجه را ثبت می‌کند. |
| مقایسه DOM و CSS محاسبه‌شده با طراحی Figma | take_snapshot عکس آنی نوشتاری از صفحه را براساس درخت دسترس‌پذیری برمی‌گرداند. get_css_styles قوانین CSS اعمال‌شده را می‌خواند. evaluate_script عملکرد جاوا اسکریپت را در صفحه اجرا می‌کند. |
| پیدا کردن LoAF، منابع مسدودکننده پردازش، و مشکلات «معیارهای کلیدی اصلی وب» | click و drag تعاملات را شبیه‌سازی می‌کنند. performance_start_trace و performance_stop_trace ردیابی عملکرد را ضبط می‌کنند. performance_analyze_insight عیب‌یابی دقیقی برای اطلاعات آماری موجود در ردیابی برمی‌گرداند. list_network_requests و get_network_request فعالیت شبکه را نشان می‌دهند. lighthouse_audit بخش‌های غیرعملکردی مانند SEO و دسترس‌پذیری را ممیزی می‌کند. |
وقتی عامل مشکلی پیدا می‌کند، مثلاً بریده شدن نوشتار در صفحه‌نمایش‌های کوچک، شکستگی در flex wrap، یا تصویر بهینه‌نشده‌ای که باعث جابه‌جایی چیدمان می‌شود، یک حلقه اصلاح کوتاه اجرا می‌کند:
- Chrome DevTools برای عامل‌ها خطای دقیق را ضبط می‌کند.
- عامل داده‌ها را تجزیه‌وتحلیل می‌کند و CSS یا JavaScript مشکل‌ساز را بازنویسی می‌کند.
- نماینده صفحه را مجدداً بار می‌کند تا رفع مشکل را تأیید کند.
در یک صفحه، نماینده صفحه را رندر کرد و متوجه شد که چیدمان سرصفحه،
فاصله‌گذاری، و گرادیان با طراحی مطابقت ندارد. این ابزار .scss فایل مربوطه را اصلاح کرد. همچنین با صفحه تعامل داشت، مثلاً آکاردئون‌ها را ازهم باز کرد تا بررسی کند
که حالت باز آن‌ها با طراحی‌ها مطابقت داشته باشد.
مرحله ۴: تحویل گزارش درستی‌سنجی‌شده به تضمین کیفیت
وقتی درستی‌سنجی انجام شد، نماینده کد آماده تولید را به‌همراه گزارش ممیزی برای تیم تضمین کیفیت ارائه می‌دهد. گزارش شامل موارد زیر است:
- مقایسه تصویری با طرح Figma که تفاوت‌های پیکسل را برجسته می‌کند، ساخته‌شده از نماگرفت‌ها، عکس‌های آنی DOM، و سبک‌های محاسبه‌شده.
- نماگرفت‌های صفحه پردازش‌شده در اندازه‌های مختلف صفحه‌نمایش.
- «معیارهای کلیدی اصلی وب» و عیب‌یابی عملکرد از
performance_start_traceوperformance_analyze_insight، مانند «شاخص سرعت» و «مجموع زمان مسدودسازی». - امتیازهای Lighthouse برای بهینه‌سازی موتور جستجو، روال‌های مطلوب، و دسترس‌پذیری از
lighthouse_audit. - بررسی‌های موفق یا ناموفق برای تعامل‌ها، مثل جمع کردن ردیف‌ها و کلیدها، به‌علاوه خطاهای کنسول و تغییرات وضعیت برنامه، مثل ویرایش ردیف‌ها، حذف ردیف‌ها، و وضعیت‌های خالی.
همین رویکرد را برای ۳۰ صفحه پویش به‌کار ببرید
در پلاتفرم اصلی Policybazaar، اجرای دستی PageSpeed Insights با ممیزی‌های اجراشده ازطریق Chrome DevTools برای عامل‌ها در Kiro جایگزین شد. پیش‌از اینکه صفحه پویشی فعال شود، مهندسی ممیزی را در نشانی وب مرحله‌ای برای تلفن همراه و رایانه راه‌اندازی می‌کند. عامل ممیزی‌های عملکرد و Lighthouse را اجرا می‌کند و Chrome DevTools برای عامل‌ها به‌طور خودکار داده‌های میدانی واقعی «گزارش تجربه کاربری Chrome» (CrUX) را در کنار داده‌های آزمایشگاهی استخراج می‌کند. این کار جایگزین مرحله «اطلاعات آماری PageSpeed» به‌طور کامل شد.
سپس عامل امتیازهای عملکرد، گلوگاه‌هایی را که پیدا کرده است، و فهرست اولویت‌بندی‌شده‌ای از بهبودها را برای اصلاح توسط مهندس گزارش می‌کند. در یک ممیزی پیش‌انتشار، این ابزار فراخوانی‌های غیربحرانی API را که یکی پس‌از دیگری درطول بار شدن صفحه اجرا می‌شدند و با کار پردازش بحرانی رقابت می‌کردند پرچم‌گذاری کرد. تیم مربوطه مشکل را قبل‌از فعال شدن صفحه برطرف کرد.
اکنون این عامل ۱۲ ممیزی عملکرد را در مدت زمانی که یک مهندس برای تکمیل یک ممیزی نیاز دارد، انجام می‌دهد. این یعنی ۹۲٪ کاهش در تلاش دستی.
Web performance is important for us to maintain a good user experience, but manually auditing, evaluating waterfalls and traces across dozens of landing pages was tedious and a major bottleneck. Chrome DevTools برای عامل‌ها این فرایند را متحول کرد و زمان ممیزی عملکرد مهندسان ما را تا ۹۲٪ کاهش داد و به آن‌ها فرصت داد تا روی کارهای پیچیده‌تر تمرکز کنند.
آمان سونی، مدیر مهندسی، Policybazaar
تأثیر
«راهنمای وب نوین» و Chrome DevTools برای عامل‌ها، آزمایش سمت کاربر را در Policybazaar و Pensionbazaar از فرایندی دستی و واکنشی به فرایندی خودکار و پیش‌کنشی تبدیل کردند. جدول زیر گردش کار را قبل و بعداز تغییر مقایسه می‌کند:
| منطقه | قبل‌از: بازبینی دستی و مدل‌های پایه | بعداز: «راهنمای وب نوین» و Chrome DevTools برای عامل‌ها |
|---|---|---|
| تلاش برای ممیزی عملکرد (Policybazaar) | مهندسی PageSpeed Insights را اجرا کرد، Core Web Vitals را بررسی کرد، و اصلاحات را به‌صورت دستی برای هریک از حدود ۳۰ صفحه مقصد اعمال کرد. | ۹۲٪ تلاش دستی کمتر. عامل ۱۲ ممیزی را در مدت زمانی که یک مهندس برای یک ممیزی نیاز دارد تکمیل می‌کند. |
| پوشش ممیزی (Policybazaar) | پوشش ممیزی در گونه‌های پویش ناهمخوان بود. | پوشش ۱۰۰٪ آزمایش عملکرد برای صفحه‌های پویش. |
| New screen turnaround (Pensionbazaar) | چند روز از کد تا صفحه درستی‌سنجی‌شده. | چند ساعت، بیش‌از ۹۰٪ سریع‌تر. |
| اشکالات برابری طراحی (Pensionbazaar) | رابط کاربری بریده‌شده و تغییرات چیدمان به تضمین کیفیت دستی رسید. | بیش‌از ۹۰٪ اشکال‌های واسط کاربر کمتری مطرح شد. |
کاهش ۹۲ درصدی از هدف تیم که بیش‌از ۸۰ درصد بود فراتر رفت. پسرفتهای صفحه مقصد پیش‌از رسیدن به مرحله آماده‌سازی یا تضمین کیفیت شناسایی می‌شوند. در Pensionbazaar، کد ازقبل با نماگرفت‌هایی برای چندین دریچه دید ممیزی می‌شود که این امر رفت‌وبرگشت بین طراحی، مهندسی، و تضمین کیفیت را کاهش می‌دهد.
نکات مهم برای تیم شما
- عاملتان را با راهنمایی‌های معتبر تقویت کنید. راهنمایی‌های دست‌چین‌شده مانند «راهنمای وب نوین» عامل‌ها را از الگوهای منسوخ دور نگه می‌دارد و کد شما را در محدوده اهداف Baseline شما حفظ می‌کند.
- به عامل اجازه ندهید تکلیف فرانت‌اند را تا زمانی که صفحه رندرشده را بررسی نکرده است، به‌عنوان انجام‌شده علامت‌گذاری کند. Chrome DevTools برای عامل‌ها به عامل اجازه می‌دهد چیدمان، دریچه‌های دید، و ردهای عملکرد را در مرورگر واقعی بازرسی کند.
- معیارهای خروج واضحی برای حلقه تعیین کنید. محدودیت‌های مرحله و شرایط صریح قبولی و رد شدن را تنظیم کنید تا عامل در حلقه نیفتد و نشان‌ها را هدر ندهد.
- با صفحه‌های پرتکرار و مبتنی بر الگو شروع کنید. گردش‌های کار حلقه بسته بیشترین بازدهی را در جایی دارند که سرعت چرخه کاری مهم است.
- ممیزی‌ها را در مرورگری تمیز اجرا کنید. از
--isolatedاستفاده کنید تا افزونه‌ها و داده‌های ذخیره‌شده در حافظه نهان بر نتایج تأثیر نگذارند یا داده‌های شخصی را افشا نکنند.