چگونه redBus تعامل وب سایت خود را با Next Paint (INP) بهبود بخشید و فروش را 7٪ افزایش داد

بهینه سازی INP به redBus کمک کرد تا فروش را حدود 7٪ افزایش دهد.

Amit Kumar

Saurabh Rajpal

وب و قابلیت های آن با سرعت زیادی در حال پیشرفت است. اکنون می توانید تجربیات غنی و کاملی را در وب ایجاد کنید که می تواند به بسیاری از آنچه برنامه های بومی از نظر قابلیت ها می توانند دست پیدا کنند.

جاوا اسکریپت یک محرک اصلی برای تعامل در سراسر وب است، اما اگر با دقت از آن استفاده نشود، تعاملات ممکن است کند به نظر برسد و باعث شود کاربران تصور کنند که وب سایت شما پاسخگو نیست یا کاملاً خراب است. خوشبختانه، معیار Interaction to Next Paint (INP) برای رفع این مشکل خاص تجربه کاربر ایجاد شد.

INP تمام تعاملات ایجاد شده با یک صفحه را در طول چرخه عمر آن اندازه گیری می کند و یک مقدار واحد را گزارش می دهد که نشان دهنده سرعت وب سایت در پاسخگویی به ورودی های کاربر است. به بیان ساده، اگر INP یک صفحه در آستانه خوب یا کمتر از آن باشد، می توان گفت که تمام تعاملات انجام شده با یک صفحه به طور قابل اعتمادی سریع هستند.

redBus ، یک وب‌سایت رزرو و خرید بلیط اتوبوس مستقر در هند، تلاش زیادی برای بهبود INP وب‌سایت خود انجام داد، حتی در زمانی که هنوز یک معیار آزمایشی در نظر گرفته می‌شد. در نتیجه تلاش های آنها، آنها توانستند فروش خود را تا 7 درصد افزایش دهند که یک بار دیگر رابطه بین عملکرد وب و سلامت کسب و کار را نشان می دهد. در اینجا چیزی است که redBus برای بهبود INP وب سایت خود انجام داد.

اهداف برتر

هنگامی که redBus تصمیم گرفت تا INP وب سایت خود را بهینه کند، آنها سه هدف را در ذهن داشتند:

1. با تمرکز بر تأخیر تعامل بدون در نظر گرفتن سرعت شبکه و قابلیت های دستگاه، تجربه کاربری بهتری را برای کاربران فراهم کنید.
2. وب سایت آنها را بهینه سازی کنید تا تعاملات را در سریع ترین زمان ممکن حفظ کنید.
3. اطمینان حاصل کنید که پاسخ‌های API آن‌ها تا حد امکان سبک باشد تا از انتقال سریع داده‌ها به قسمت جلویی اطمینان حاصل شود.

سفر

redBus تأخیر تعامل را به دو صورت طبقه‌بندی کرد:

1. تأخیر تعامل ناشی از مسدود کردن جاوا اسکریپت در سرویس گیرنده. وقتی تعاملات از جاوا اسکریپت بیش از حد استفاده می کنند که رشته اصلی را مسدود می کند، رندر به تأخیر می افتد و این بر INP صفحه تأثیر می گذارد.
2. تأخیر شبکه ناشی از تماس های API. در حالی که فعالیت شبکه چیزی نیست که INP اندازه گیری کند، یک تعامل متکی به تماس با یک API راه دور می تواند در شبکه های کندتر احساس کندی داشته باشد، یا اگر درخواست ها منجر به پاسخ های بزرگ شود.

redBus در ابتدا کاملاً مطمئن بود که INP برای وب‌سایت آنها خوب است، اما داده‌های مانیتورینگ کاربر واقعی (RUM) برای این معیار در صدک 95 داستان متفاوتی را بیان کرد.

چگونه redBus INP را اندازه گیری کرد

redBus برای ردیابی نه تنها INP، بلکه تمام معیارهای مهم تجربه کاربر برای همه صفحات در وب‌سایت خود، به کتابخانه جاوا اسکریپت web-vitals ساخته شده توسط Google متکی بود. علاوه بر کتابخانه جاوا اسکریپت web-vitals ، redBus از ELK برای تجزیه و تحلیل داده های INP که در قسمت جلویی جمع آوری شده بود استفاده کرد.

با این حال، نحوه ردیابی INP وب سایت خود در این زمینه ممکن است کاملاً متفاوت از نحوه برخورد redBus با مشکل باشد. ما به شدت توصیه می کنیم قبل از شروع بهینه سازی تعاملات ، در مورد نحوه یافتن تعاملات آهسته در این زمینه مطالعه کنید تا یاد بگیرید چگونه INP را برای وب سایت خود به بهترین شکل ردیابی کنید، و متعاقباً چگونه آنها را در آزمایشگاه بازتولید کنید .

هنگامی که redBus سیستمی برای ردیابی INP ایجاد کرد، آنها قادر به تجزیه و تحلیل داده‌ها بودند تا درک بهتری از مکان‌هایی که تعامل کند وجود دارد به دست آورند.

موارد استفاده کنید

وقتی کاربران کرایه ها را در وب سایت redBus جستجو می کنند، می توانند تاریخ را در صفحه جستجو تغییر دهند تا کرایه های انتخاب شده را برای مقصد مورد نظر فیلتر کنند. تعامل برای تغییر تاریخ در این صفحه کند بود و دلیل INP ضعیف بود.

علاوه بر این، زمانی که کاربر در میان کرایه‌ها حرکت می‌کند، کرایه‌های اضافی به‌صورت تنبلی از API بارگیری می‌شوند. اگرچه خود پیمایش در نحوه اندازه‌گیری INP لحاظ نمی‌شود ، شنونده رویداد scroll خود کارهای زیادی را برنامه‌ریزی می‌کند که باید روی رشته اصلی اجرا شوند. این کار باعث ایجاد مشاجره در موضوع اصلی می شد که تأخیر تعامل را افزایش می داد و منجر به INP ضعیف در صفحه جستجو می شد.

چگونه redBus INP را برای صفحه جستجو بهینه کرد

برای بهبود INP صفحه جستجو، redBus چندین بهینه سازی انجام داد:

• کنترل کننده رویداد scroll به منظور کاهش تعداد دفعاتی که تماس برگشتی رویداد در یک دوره معین فعال می‌شود، بازگردانده شد. با کاهش فرکانس اجرای تماس رویداد scroll ، موضوع اصلی قادر بود سریعتر به تعاملات کاربر در صفحه جستجو پاسخ دهد.
• کار رندر حاصل با استفاده از یک requestAnimationFrame callback اولویت بندی شد. requestAnimationFrame به مرورگر می گوید که کار در callback باید قبل از فریم بعدی انجام شود.

علاوه بر این، بهینه سازی های بیشتر زیر در صفحه نتایج جستجو انجام شد:

• دسته‌های جدیدی از نتایج بر روی کارت دوم تا آخرین در صفحه نتایج جستجو به منظور بهبود تجربه کاربر و عملکرد بصری با راه‌اندازی بارگذاری تنبل زودتر واکشی شدند.
• نتایج کمتری در هر تماس شبکه در طول بارگیری تنبل واکشی شد. با کاهش واکشی از 30 به 10 نتیجه، کاهش در محدوده INP در 870 تا 900 به 350 تا 370 مشاهده شد.

در حالی که این تغییرات به طور قابل توجهی INP صفحه جستجو را بهبود بخشید، هنوز این مشکل وجود داشت که در آن رویداد change در فیلدهای ورودی صفحه جستجو، یک تابع کاهش دهنده گران قیمت را برای به روز رسانی رابط کاربری فراخوانی می کرد. این منجر به رندر غیر ضروری رابط کاربری شد که بر INP صفحه تأثیر گذاشت.

برای بهینه‌سازی این تعامل، redBus وضعیت مؤلفه‌های ورودی را به صورت محلی مدیریت می‌کند و تنها زمانی که رویداد blur ورودی فعال می‌شود، آن را با فروشگاه Redux همگام‌سازی می‌کند. این تغییر تعداد رندرها را کاهش داد و با تماس کمتر با کاهش دهنده، رندر ناخواسته رابط کاربری را حذف کرد.

با این تغییر، INP صفحه تا 72 درصد بهبود یافت و در نتیجه تجربه کاربری سریع‌تر و روان‌تری داشت که کاربران بیشتر با آن درگیر می‌شوند.

تاثیر کسب و کار

رابطه بین سلامت کسب و کار و عملکرد صفحه کاملاً شناخته شده است. اگرچه INP یک معیار نسبتاً جدید در مقایسه با دیگر Core Web Vitals است، redBus با تمرکز بر بهبود این معیار عملکرد مهم کاربر محور، نتایج کسب و کار بهتری را مشاهده کرد. نتیجه افزایش 7 درصدی فروش کلی بود.

به طور خلاصه، INP به ترسیم تصویری از مشکلات عملکرد زمان اجرا در وب سایت redBus کمک کرد. RedBus با آگاهی از اینکه باید پیشرفت هایی انجام شود، توانست مشکل را مشاهده کند، آن را بازتولید کند و از آن اطلاعات حیاتی برای بهینه سازی هایی استفاده کند که برای redBus و تجارت آن مفید بود.