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