این مطالعه موردی گردش کار گام به گام اشکال‌زدایی و بهبود INP در React را توصیف می‌کند که توسط Trendyol با استفاده از ابزارهای Google مانند PageSpeed Insights (PSI) ، Chrome DevTools و scheduler.yield API استفاده می‌شود.
دو جزء حیاتی هر وب سایت تجارت الکترونیک، صفحه فهرست محصول (PLP) و صفحه جزئیات محصول (PDP) هستند. ترافیک تجارت الکترونیک اغلب از صفحات فهرست محصولات، خواه از طریق کمپین های ایمیل، رسانه های اجتماعی یا تبلیغات می آید. در نتیجه، بسیار مهم است که اطمینان حاصل شود که تجربه PLP با دقت طراحی شده است تا زمان خرید را کاهش دهد. اولویت بندی کیفیت تجربه کاربر برای دستیابی به موفقیت ضروری است. نشریات تحقیقاتی مانند Milliseconds Make Millions قبلاً تأثیر قابل توجه عملکرد وب را بر تمایل مصرف کنندگان به خرج کردن پول و تعامل با مارک های آنلاین نشان داده اند.
Trendyol یک پلتفرم تجارت الکترونیک با حدود 30 میلیون مشتری و 240000 فروشنده است که ما را به اولین تجارت در ترکیه با ارزش بیش از 10 میلیارد دلار و یکی از برترین پلتفرم های تجارت الکترونیک در جهان تبدیل کرده است.
Trendyol برای دستیابی به هدف خود در ارائه بهترین تجربه کاربری ممکن در مقیاس و در عین حال انعطاف‌پذیری محتوا و کار با نسخه قدیمی‌تر React، بر روی تعامل با رنگ بعدی (INP) به عنوان معیاری کلیدی برای بهبود تمرکز کرد. این مطالعه موردی سفر Trendyol برای بهبود INP در PLP خود را توصیف می‌کند که منجر به کاهش 50% INP و افزایش 1% در معیار نتایج جستجو می‌شود .
روند بررسی INP Trendyol
INP میزان پاسخگویی وب سایت به ورودی کاربر را اندازه گیری می کند. یک INP خوب نشان می‌دهد که مرورگر می‌تواند به سرعت و با اطمینان به تمام ورودی‌های کاربر پاسخ دهد و صفحه را مجدداً رنگ آمیزی کند، که جزء کلیدی یک تجربه کاربری خوب است.
سفر Trendyol برای بهبود INP در PLP خود با تجزیه و تحلیل کامل تجربه کاربر قبل از هر گونه بهبودی آغاز شد. بر اساس یک گزارش PSI، تجربه کاربری واقعی PLP دارای INP 963 میلی ثانیه در تلفن همراه بود، همانطور که در شکل بعدی نشان داده شده است.
برای اطمینان از پاسخگویی خوب، صاحبان سایت باید INP زیر یا 200 میلی ثانیه را هدف قرار دهند، به این معنی که در آن زمان، INP Trendyol در محدوده "ضعیف" بود.
خوشبختانه، PSI هم داده‌های میدانی را برای صفحات موجود در گزارش تجربه کاربر Chrome (CrUX) و هم داده‌های دقیق تشخیص آزمایشگاهی را ارائه می‌کند. با نگاهی به داده‌های آزمایشگاهی، ممیزی زمان اجرای جاوا اسکریپت Lighthouse نشان داد که اسکریپت search-result-v2 برای مدت زمان بیشتری نسبت به سایر اسکریپت‌های صفحه، موضوع اصلی را اشغال می‌کند.
برای شناسایی تنگناهای دنیای واقعی، از پانل عملکرد در ابزار توسعه کروم برای عیب‌یابی تجربه PLP و شناسایی منبع مشکل استفاده کردیم. شبیه‌سازی عملکرد تلفن همراه با کاهش سرعت 4 برابری CPU در Chrome DevTools یک کار طولانی 700-900 میلی‌ثانیه‌ای را در رشته اصلی نشان داد. اگر رشته اصلی بیش از 50 میلی ثانیه با وظایف دیگر مشغول باشد، ممکن است نتواند به ورودی کاربر به موقع پاسخ دهد و در نتیجه تجربه کاربری ضعیفی ایجاد می کند.
طولانی‌ترین کار به دلیل پاسخ تماس API Intersection Observer در اسکریپت نتایج جستجو در داخل یک جزء React ایجاد شد. در این مرحله، ما شروع به تجزیه و تحلیل این کار طولانی به قطعات کوچک کردیم تا به مرورگر فرصت های بیشتری برای پاسخگویی به کارهای با اولویت بالاتر - از جمله تعاملات کاربر - بدهیم.
به نظر می رسد که استفاده از عملیات setState که باعث ایجاد رندر مجدد React در بازخوانی Intersection Observer می شود، هزینه بالایی دارد، که ممکن است برای دستگاه های پایین رده با اشغال کردن نخ اصلی برای مدت طولانی مشکل ساز باشد.
یکی از روش هایی که توسعه دهندگان برای تقسیم وظایف به کارهای کوچکتر استفاده کرده اند، setTimeout است. ما از این تکنیک برای به تعویق انداختن اجرای فراخوان setState در یک کار جداگانه استفاده کردیم. اگرچه setTimeout اجازه می دهد تا اجرای جاوا اسکریپت را به تعویق بیندازید، هیچ کنترلی روی اولویت ارائه نمی دهد. این ما را بر آن داشت تا در تلاش برای تضمین ادامه اجرای اسکریپت پس از تسلیم شدن به رشته اصلی ، به آزمایش مبدا scheduler.yield بپیوندیم:
/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
if('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
entries.forEach(handleIntersection);
const maxNumberOfEntries = Math.max(...this.intersectingEntries);
if (Number.isFinite(maxNumberOfEntries)) {
await this.yieldToMain();
this.setState({ count: maxNumberOfEntries });
}
}, { threshold: 0.5 });
افزودن این روش تسلیم به کد PLP منجر به بهبود INP شد، زیرا وظیفه طولانی‌تر اصلی به مجموعه‌ای از کارهای کوچکتر تقسیم شده است، که اجازه می‌دهد کارهای با اولویت بالاتر - مانند تعاملات کاربر و کارهای رندر بعدی - زودتر از زمان انجام شود. آنها در غیر این صورت می داشتند.
توجه داشته باشید که Trendyol از چارچوب PuzzleJs برای پیاده سازی یک معماری micro-frontend با استفاده از React v16.9.0 استفاده می کند. با React 18 می توان به همان عملکرد دست یافت، اما به دلایل متعدد، Trendyol در حال حاضر قادر به ارتقاء آن نیست.
نتایج کسب و کار
برای اندازه‌گیری تأثیر بهبود INP اجرا شده، آزمایش A/B را اجرا کردیم تا ببینیم معیارهای کسب‌وکار چگونه تحت تأثیر قرار گرفته‌اند. به طور کلی، تغییرات ما در PLP منجر به بهبود قابل توجهی شد، از جمله کاهش 50٪ INP و همچنین افزایش 1٪ در نرخ کلیک از صفحه لیست ها به صفحه جزئیات محصول در هر جلسه کاربر. در شکل زیر می بینید که چگونه INP در PLP در طول زمان بهبود یافته است:
نتیجه
بهینه سازی INP یک فرآیند پیچیده و تکراری است، اما می توان آن را با یک گردش کار واضح آسان تر کرد. یک روش ساده برای اشکال زدایی و بهبود INP وب سایت شما بستگی به این دارد که آیا شما داده های میدانی خود را جمع آوری می کنید یا خیر. اگر نیستید، PSI و Lighthouse نقطه شروع خوبی هستند. هنگامی که صفحات دارای مشکلات را شناسایی کردید، می توانید از DevTools برای کاوش عمیق تر و تلاش برای بازتولید مشکلات استفاده کنید.
تسلیم شدن به موضوع اصلی هر از گاهی برای دادن فرصت های بیشتر به مرورگر برای انجام کارهای فوری، وب سایت شما را پاسخگوتر می کند و اطمینان حاصل می کند که مشتریان شما تجربه کاربری بهتری دارند. APIهای زمانبندی جدیدتر مانند scheduler.yield() این کار را آسانتر می کند.
تشکر ویژه از جرمی واگنر، بری پولارد و حسین جیرده از گوگل و تیم مهندسی ترندیول به خاطر مشارکتشان در این کار.