RAIL یک مدل عملکرد کاربرمحور است که ساختاری برای تفکر درباره عملکرد ارائه می‌دهد. این مدل تجربه کاربر را به کنش‌های کلیدی (برای مثال، ضربه زدن، پیمایش، بار کردن) تقسیم می‌کند و به شما کمک می‌کند اهداف عملکردی را برای هرکدام از آن‌ها تعریف کنید.
RAIL مخفف چهار جنبه متمایز از چرخه عمر برنامه وب است: پاسخ، پویانمایی، بیکار، و بارگیری. کاربران انتظارات عملکردی متفاوتی برای هریک از این زمینه‌ها دارند، بنابراین اهداف عملکردی براساس زمینه و پژوهش تجربه کاربری درباره نحوه درک کاربران از تأخیرها تعریف می‌شوند.
تمرکز روی کاربر
کاربران را نقطه کانونی تلاش‌هایتان برای بهبود عملکرد قرار دهید. جدول زیر سنجه‌های کلیدی را درباره نحوه درک کاربران از تأخیرهای عملکرد شرح می‌دهد:
درک کاربر از تأخیرهای عملکرد| ۰ تا ۱۶ میلی‌ثانیه | کاربران به‌طور استثنایی در ردیابی حرکت خوب هستند و وقتی پویانمایی‌ها روان نباشند، آن را دوست ندارند. تا زمانی که ۶۰ فریم جدید در هر ثانیه رندر شود، پویانمایی‌ها را روان می‌بینند. این یعنی ۱۶ میلی‌ثانیه برای هر فریم، ازجمله زمانی که طول می‌کشد تا مرورگر فریم جدید را روی صفحه بکشد، و حدود ۱۰ میلی‌ثانیه برای برنامه باقی می‌ماند تا فریم را تولید کند. |
| ۰ تا ۱۰۰ میلی‌ثانیه | در این بازه زمانی به کنش‌های کاربر پاسخ دهید تا کاربر احساس کند نتیجه فوری است. اگر بیشتر طول بکشد، ارتباط بین کنش و واکنش قطع می‌شود. |
| ۱۰۰ تا ۱۰۰۰ میلی‌ثانیه | در این پنجره، چیزها بخشی از پیشرفت طبیعی و مداوم تکالیف به‌نظر می‌رسند. برای اکثر کاربران در وب، بار کردن صفحه‌ها یا تغییر دادن نماها نشان‌دهنده یک تکلیف است. |
| ۱۰۰۰ میلی‌ثانیه یا بیشتر | بیش‌از ۱۰۰۰ میلی‌ثانیه (۱ ثانیه)، کاربران تمرکز خود را روی کاری که انجام می‌دهند ازدست می‌دهند. |
| ۱۰۰۰۰ میلی‌ثانیه یا بیشتر | بیش‌از ۱۰۰۰۰ میلی‌ثانیه (۱۰ ثانیه)، کاربران ناامید می‌شوند و احتمالاً کار را رها می‌کنند. ممکن است بعداً برگردند یا برنگردند. |
اهداف و دستورالعمل‌ها
در بافت RAIL، اصطلاحات اهداف و رهنمودها معانی خاصی دارند:
اهداف. سنجه‌های عملکرد کلیدی مربوط به تجربه کاربری. برای مثال، برای رنگ‌آمیزی در کمتر از ۱۰۰ میلی‌ثانیه تک‌ضرب بزنید. ازآنجایی‌که درک انسان نسبتاً ثابت است، بعید است این اهداف به‌زودی تغییر کنند.
دستورالعمل‌ها. توصیه‌هایی که به شما کمک می‌کند به اهدافتان برسید. این توصیه‌ها ممکن است مختص شرایط فعلی سخت‌افزار و اتصال شبکه باشد و بنابراین ممکن است درطول زمان تغییر کند.
پاسخ: پردازش رویدادها در کمتر از ۵۰ میلی‌ثانیه
هدف: تکمیل انتقال آغازشده توسط ورودی کاربر در ۱۰۰ میلی‌ثانیه، به‌طوری‌که کاربران احساس کنند تعاملات آنی است.
دستورالعمل‌ها:
برای اطمینان از پاسخ قابل‌مشاهده در ۱۰۰ میلی‌ثانیه، رویدادهای ورودی کاربر را در ۵۰ میلی‌ثانیه پردازش کنید. این امر برای اکثر ورودی‌ها، مانند کلیک کردن روی دکمه‌ها، تغییر دادن کنترل‌های فرم، یا شروع پویانمایی‌ها اعمال می‌شود. این موضوع برای کشیدن یا پیمایش با لمس صدق نمی‌کند.
اگرچه ممکن است غیرمنطقی به‌نظر برسد، اما پاسخ دادن فوری به ورودی کاربر همیشه تصمیم درستی نیست. می‌توانید از این پنجره ۱۰۰ میلی‌ثانیه‌ای برای انجام کارهای پرهزینه دیگر استفاده کنید، اما مراقب باشید که کاربر را مسدود نکنید. درصورت امکان، کارها را در پس‌زمینه انجام دهید.
برای کنش‌هایی که تکمیل آن‌ها بیش‌از ۵۰ میلی‌ثانیه طول می‌کشد، همیشه بازخورد ارائه دهید.
۵۰ میلی‌ثانیه یا ۱۰۰ میلی‌ثانیه؟
هدف این است که به ورودی در کمتر از ۱۰۰ میلی‌ثانیه پاسخ داده شود، پس چرا بودجه ما فقط ۵۰ میلی‌ثانیه است؟ دلیلش این است که معمولاً علاوه‌بر رسیدگی به ورودی، کارهای دیگری نیز انجام می‌شود و این کارها بخشی از زمان موجود برای پاسخ ورودی قابل‌قبول را اشغال می‌کنند. اگر برنامه‌ای درحال انجام کار در بخش‌های ۵۰ میلی‌ثانیه‌ای توصیه‌شده در زمان بیکاری باشد، به این معنی است که ورودی می‌تواند تا ۵۰ میلی‌ثانیه در صف قرار گیرد اگر در یکی از آن بخش‌های کاری رخ دهد. با درنظر گرفتن این موضوع، می‌توان فرض کرد که فقط ۵۰ میلی‌ثانیه باقی‌مانده برای رسیدگی به ورودی واقعی دردسترس است. این اثر در نمودار زیر نشان داده شده است که نشان می‌دهد چگونه ورودی دریافتی درطول یک تکلیف غیرفعال در صف قرار می‌گیرد و زمان پردازش دردسترس را کاهش می‌دهد:
پویانمایی: تولید یک قاب در ۱۰ میلی‌ثانیه
گل‌ها:
هر قاب را در پویانمایی در ۱۰ میلی‌ثانیه یا کمتر تولید کنید. ازنظر فنی، حداکثر بودجه برای هر فریم ۱۶ میلی‌ثانیه است (۱۰۰۰ میلی‌ثانیه / ۶۰ فریم در ثانیه ≈ ۱۶ میلی‌ثانیه)، اما مرورگرها برای پرداز هر فریم به حدود ۶ میلی‌ثانیه نیاز دارند، بنابراین دستورالعمل ۱۰ میلی‌ثانیه برای هر فریم است.
هدف را بر روان بودن بصری بگذارید. کاربران متوجه تغییر نرخ فریم می‌شوند.
دستورالعمل‌ها:
در نقاط پرفشار مانند پویانمایی‌ها، نکته کلیدی این است که هرجا می‌توانید کاری انجام ندهید و هرجا نمی‌توانید، حداقل مطلق را انجام دهید. هرزمان ممکن بود، از پاسخ ۱۰۰ میلی‌ثانیه‌ای برای پیش‌محاسبه کارهای پرهزینه استفاده کنید تا شانس خود را برای رسیدن به ۶۰ فریم در ثانیه به حداکثر برسانید.
برای استراتژی‌های مختلف بهینه‌سازی پویانمایی، عملکرد پرداز را ببینید.
- پویانمایی‌های بصری، مانند ورودی‌ها و خروجی‌ها، بینابین‌ها، و نشانگرهای بارگیری.
- درحال پیمایش کردن. این شامل پرتاب کردن می‌شود، یعنی زمانی که کاربر شروع به پیمایش می‌کند، سپس رها می‌کند و صفحه به پیمایش ادامه می‌دهد.
- درحال کشیدن. پویانمایی‌ها اغلب از تعاملات کاربر پیروی می‌کنند، مانند حرکت دادن نقشه یا نیشگون گرفتن برای بزرگ‌نمایی.
بیکار: بیشینه کردن زمان بیکاری
هدف: بیشینه کردن زمان بیکاری برای افزایش احتمال پاسخ دادن صفحه به ورودی کاربر ظرف ۵۰ میلی‌ثانیه.
دستورالعمل‌ها:
از زمان بیکاری برای تکمیل کارهای معوقه استفاده کنید. برای مثال، برای بارگیری اولیه صفحه، تا حد امکان داده کمتری بارگیری کنید، سپس از زمان بیکاری برای بارگیری بقیه استفاده کنید.
کار را در زمان بیکاری در ۵۰ میلی‌ثانیه یا کمتر انجام دهید. اگر بیشتر طول بکشد، ممکن است در توانایی برنامه برای پاسخ دادن به ورودی کاربر ظرف ۵۰ میلی‌ثانیه تداخل ایجاد شود.
اگر کاربری درطول کار زمان بیکاری با صفحه‌ای تعامل داشته باشد، تعامل کاربر باید همیشه بالاترین اولویت را داشته باشد و کار زمان بیکاری را قطع کند.
بار کردن: ارائه محتوا و تعاملی شدن در کمتر از ۵ ثانیه
وقتی صفحه‌ها به‌کندی بار می‌شوند، توجه کاربر منحرف می‌شود و کاربر احساس می‌کند که کار خراب شده است. سایت‌هایی که سریع بار می‌شوند جلسه‌های میانگین طولانی‌تر، نرخ پرش کمتر، و رؤیت‌پذیری آگهی بالاتری دارند.
گل‌ها:
برای عملکرد بارگیری سریع نسبت به قابلیت‌های دستگاه و شبکه کاربران بهینه‌سازی کنید. درحال‌حاضر، هدف خوب برای بارگیری‌های اول این است که صفحه بار شود و در ۵ ثانیه یا کمتر در دستگاه‌های همراه میان‌رده با اتصال‌های 3G کند تعاملی باشد.
برای بارگیری‌های بعدی، هدف خوب این است که صفحه در کمتر از ۲ ثانیه بار شود.
دستورالعمل‌ها:
عملکرد بارگیری را در دستگاه‌های همراه و اتصال‌های شبکه‌ای که در میان کاربران شما رایج است آزمایش کنید. می‌توانید از گزارش تجربه کاربری Chrome برای اطلاع از توزیع اتصال کاربران خود استفاده کنید. اگر داده‌ها برای سایت شما دردسترس نیست، The Mobile Economy 2019 پیشنهاد می‌کند که یک خط پایه جهانی خوب، یک تلفن Android میان‌رده، مانند Moto G4، و یک شبکه 3G کند (تعریف‌شده به‌عنوان ۴۰۰ میلی‌ثانیه RTT و سرعت انتقال ۴۰۰ کیلوبیت بر ثانیه) است. این ترکیب در WebPageTest دردسترس است.
به‌خاطر داشته باشید که اگرچه دستگاه کاربر تلفن همراه معمولی شما ممکن است ادعا کند که در اتصال 2G، 3G، یا 4G است، در واقعیت سرعت اتصال مؤثر اغلب به‌دلیل ازدست رفتن بسته و تفاوت شبکه به‌طور قابل‌توجهی کندتر است.
لازم نیست همه چیز را در کمتر از ۵ ثانیه بار کنید تا حس بار شدن کامل را ایجاد کنید. بار کردن کُند تصاویر، دسته‌های جاوا اسکریپت تقسیم کد، و بهینه‌سازی‌های دیگر پیشنهادشده در web.dev را درنظر بگیرید.
ابزارهای اندازه‌گیری RAIL
چند ابزار برای کمک به شما در خودکارسازی اندازه‌گیری‌های RAIL وجود دارد. اینکه از کدام‌یک استفاده کنید بستگی به نوع اطلاعاتی دارد که نیاز دارید و نوع گردش کاری که ترجیح می‌دهید.
Chrome DevTools
Chrome DevTools تحلیل عمیقی از هر اتفاقی که هنگام بار شدن یا اجرا شدن صفحه‌تان رخ می‌دهد ارائه می‌دهد. برای آشنایی با میانای کاربری پانل عملکرد، شروع به کار با تجزیه‌وتحلیل عملکرد زمان اجرا را ببینید.
ویژگی‌های DevTools زیر به‌طور خاص مرتبط هستند:
واحد پردازش مرکزی را محدود کنید تا دستگاهی با قدرت کمتر شبیه‌سازی شود.
شبکه را محدود کنید تا اتصال‌های کندتر شبیه‌سازی شود.
فعالیت رشته اصلی را مشاهده کنید تا هر رویدادی را که در رشته اصلی هنگام ضبط رخ داده است مشاهده کنید.
فعالیت‌های رشته اصلی را در یک جدول مشاهده کنید تا فعالیت‌ها را براساس اینکه کدام‌یک بیشترین زمان را گرفته‌اند مرتب کنید.
فریم در ثانیه (FPS) را تجزیه‌وتحلیل کنید تا بسنجید که آیا پویانمایی‌هایتان واقعاً روان اجرا می‌شوند یا نه.
استفاده از واحد پردازش مرکزی، اندازه پشته جاوااسکریپت، گره‌های DOM، چیدمان‌ها در ثانیه، و موارد دیگر را به‌طور هم‌زمان با پایشگر عملکرد پایش کنید.
درخواست‌های شبکه را که درحین ضبط کردن با بخش شبکه رخ داده است تجسم کنید.
هنگام ضبط، نماگرفت بگیرید تا دقیقاً ببینید صفحه هنگام بار شدن، یا اجرای پویانمایی، و غیره چه ظاهری داشته است.
تعاملات را مشاهده کنید تا به‌سرعت تشخیص دهید که پس‌از تعامل کاربر با صفحه چه اتفاقی افتاده است.
مشکلات عملکرد پیمایش را به‌طور هم‌زمان پیدا کنید با برجسته کردن صفحه هرگاه شنونده‌ای که احتمالاً مشکل‌ساز است فعال شود.
رویدادهای رنگ‌آمیزی را به‌صورت هم‌زمان مشاهده کنید تا رویدادهای رنگ‌آمیزی پرهزینه را که ممکن است به عملکرد پویانمایی‌های شما آسیب برسانند، شناسایی کنید.
Lighthouse
Lighthouse در Chrome DevTools، در PageSpeed Insights، به‌عنوان افزونه Chrome، به‌عنوان ماژول Node.js، و در WebPageTest دردسترس است. نشانی وب را به آن می‌دهید، دستگاهی میان‌رده با اتصال 3G کُند را شبیه‌سازی می‌کند، مجموعه‌ای از ممیزی‌ها را در صفحه اجرا می‌کند، و سپس گزارشی درباره عملکرد بار کردن و همچنین پیشنهادهایی برای بهبود به شما ارائه می‌دهد.
ممیزی‌های زیر به‌طور ویژه مرتبط هستند:
پاسخ
حداکثر تأخیر ورودی اول بالقوه. تخمین می‌زند که چقدر طول می‌کشد تا برنامه‌تان به ورودی کاربر پاسخ دهد، براساس زمان بیکاری رشته اصلی.
از شنوندگان غیرفعال برای بهبود عملکرد پیمایش استفاده نمی‌کند.
مجموع زمان مسدودسازی. مدت‌زمان کلی را که صفحه برای پاسخ دادن به ورودی کاربر (مثل کلیک موشواره، تک‌ضرب روی صفحه‌نمایش، یا فشار دادن صفحه‌کلید) مسدود شده است می‌سنجد.
زمان تا تعامل. زمانی را می‌سنجد که کاربر می‌تواند به‌طور مداوم با همه عناصر صفحه تعامل داشته باشد.
بار کردن
عامل خدماتی‌ای را که صفحه و start_url را کنترل می‌کند ثبت نمی‌کند. یک کارگر خدمات می‌تواند منابع مشترک را در دستگاه کاربر ذخیره کند و زمان صرف‌شده برای واکشی منابع ازطریق شبکه را کاهش دهد.
سرعت بار شدن صفحه در شبکه‌های تلفن همراه به‌اندازه کافی سریع نیست.
Defer offscreen images (به‌تعویق انداختن تصاویر خارج‌از صفحه). بار کردن تصاویر خارج از صفحه را تا زمانی که به آن‌ها نیاز باشد به‌تعویق بیندازید.
اندازه تصاویر را به‌درستی تنظیم کنید. تصاویری را که به‌طور قابل‌توجهی بزرگ‌تر از اندازه پرداز زده‌شده در ناحیه نمایش تلفن همراه هستند ارائه نکنید.
از افزایش بیش‌ازحد اندازه DOM جلوگیری کنید. بایت‌های شبکه را کاهش دهید با ارسال فقط گره‌های DOM که برای رندر کردن صفحه لازم است.
WebPageTest
WebPageTest ابزاری برای عملکرد وب است که از مرورگرهای واقعی برای دسترسی به صفحه‌های وب و جمع‌آوری سنجه‌های زمان‌بندی استفاده می‌کند. نشانی وبی را در webpagetest.org/easy وارد کنید تا گزارش مفصلی درباره عملکرد بار کردن صفحه در دستگاه Moto G4 واقعی با اتصال 3G کُند دریافت کنید. همچنین می‌توانید آن را طوری پیکربندی کنید که شامل ممیزی Lighthouse باشد.
خلاصه
RAIL لنزی برای نگاه کردن به تجربه کاربری وب‌سایت به‌عنوان سفری متشکل از تعاملات متمایز است. درک کنید که کاربران چگونه سایت شما را درک می‌کنند تا اهداف عملکردی را با بیشترین تأثیر بر تجربه کاربر تعیین کنید.
تمرکز بر کاربر.
به ورودی کاربر در کمتر از ۱۰۰ میلی‌ثانیه پاسخ دهید.
هنگام پویانمایی یا پیمایش، یک قاب را در کمتر از ۱۰ میلی‌ثانیه تولید کنید.
زمان بدون فعالیت رشته اصلی را به حداکثر برسانید.
محتوای تعاملی را در کمتر از ۵۰۰۰ میلی‌ثانیه بار کنید.