RAIL হল একটি ব্যবহারকারী-কেন্দ্রিক পারফর্ম্যান্স মডেল যা পারফর্ম্যান্স সম্পর্কে চিন্তাভাবনা করার জন্য একটি স্ট্রাকচার প্রদান করে। মডেলটি ব্যবহারকারীর অভিজ্ঞতাকে মূল অ্যাকশনে (যেমন, ট্যাপ, স্ক্রল, লোড) ভাগ করে এবং আপনাকে তাদের প্রত্যেকের জন্য পারফর্ম্যান্সের লক্ষ্য নির্ধারণ করতে সাহায্য করে।
RAIL হল ওয়েব অ্যাপ লাইফ সাইকেলের চারটি স্বতন্ত্র দিক: রেসপন্স, অ্যানিমেশন, আইডল ও লোড। এইসব প্রসঙ্গের প্রতিটির জন্য ব্যবহারকারীদের পারফর্ম্যান্স সংক্রান্ত প্রত্যাশা আলাদা হয়, তাই প্রসঙ্গ এবং ব্যবহারকারীরা বিলম্বকে কীভাবে দেখেন তার উপর UX রিসার্চের উপর ভিত্তি করে পারফর্ম্যান্সের লক্ষ্য নির্ধারণ করা হয়।
ব্যবহারকারীর উপর ফোকাস করা
পারফর্ম্যান্সের উন্নতির জন্য ব্যবহারকারীদের উপর ফোকাস করুন। নিচের সারণীতে ব্যবহারকারীরা কীভাবে পারফর্ম্যান্স ডিলেকে দেখেন তার মূল মেট্রিক বর্ণনা করা আছে:
পারফর্ম্যান্স ডিলে সম্পর্কে ব্যবহারকারীর ধারণা| ০ থেকে ১৬ মিলিসেকেন্ড | ব্যবহারকারীরা মোশন ট্র্যাক করার ব্যাপারে অত্যন্ত দক্ষ এবং অ্যানিমেশন স্মুথ না হলে তারা পছন্দ করেন না। প্রতি সেকেন্ডে ৬০টি নতুন ফ্রেম রেন্ডার করা হলে, অ্যানিমেশন মসৃণ বলে মনে হয়। অর্থাৎ, ফ্রেম প্রতি ১৬ মিলি সেকেন্ড, যার মধ্যে ব্রাউজারের স্ক্রিনে নতুন ফ্রেম আঁকার জন্য প্রয়োজনীয় সময়ও অন্তর্ভুক্ত, যার ফলে অ্যাপের কাছে ফ্রেম তৈরি করার জন্য প্রায় ১০ মিলি সেকেন্ড সময় থাকে। |
| ০ থেকে ১০০ ms | এই সময়ের মধ্যে ব্যবহারকারীর অ্যাকশনের উত্তর দিন এবং ব্যবহারকারীকে বুঝতে দিন যে ফলাফল অবিলম্বে পাওয়া যাবে। এর থেকে বেশি সময় লাগলে, অ্যাকশন ও প্রতিক্রিয়ার মধ্যে কানেকশন ভেঙে যায়। |
| ১০০ থেকে ১০০০ ms | এই উইন্ডোর মধ্যে, টাস্কের স্বাভাবিক ও ধারাবাহিক অগ্রগতির অংশ হিসেবে সবকিছুকে মনে হয়। ওয়েবে বেশিরভাগ ব্যবহারকারীর ক্ষেত্রে, পৃষ্ঠা লোড করা বা ভিউ পরিবর্তন করাকে একটি টাস্ক হিসেবে ধরা হয়। |
| ১০০০ মি.সে. বা তার বেশি | ১০০০ মিলিসেকেন্ডের (১ সেকেন্ড) বেশি সময় লাগলে, ব্যবহারকারীরা যে টাস্কটি করছেন তার থেকে মনোযোগ হারিয়ে ফেলেন। |
| ১০০০০ মিলি-সেকেন্ড বা তার বেশি | ১০০০০ মিলিসেকেন্ডের (১০ সেকেন্ড) বেশি সময় লাগলে, ব্যবহারকারীরা বিরক্ত হয়ে পড়েন এবং টাস্কটি সম্পূর্ণ না করেই ছেড়ে দেন। তারা পরে ফিরে আসতে পারে বা নাও আসতে পারে। |
লক্ষ্য ও নির্দেশিকা
RAIL-এর প্রসঙ্গে, লক্ষ্য এবং নির্দেশিকা শব্দগুলির নির্দিষ্ট অর্থ আছে:
লক্ষ্য. ব্যবহারকারীর অভিজ্ঞতা সম্পর্কিত মূল পারফর্ম্যান্স মেট্রিক। যেমন, ১০০ মিলিসেকেন্ডের কম সময়ে পেইন্ট করতে ট্যাপ করুন। মানুষের উপলব্ধি যেহেতু তুলনামূলকভাবে স্থির, তাই এই লক্ষ্যগুলি শীঘ্রই পরিবর্তন হওয়ার সম্ভাবনা নেই।
নির্দেশিকা। লক্ষ্য পূরণ করতে সাহায্য করে এমন সাজেশন। এগুলি বর্তমান হার্ডওয়্যার ও নেটওয়ার্ক কানেকশনের অবস্থার উপর নির্ভর করে নির্দিষ্ট হতে পারে এবং তাই সময়ের সাথে সাথে পরিবর্তিত হতে পারে।
প্রতিক্রিয়া: ৫০ মিলিসেকেন্ডের কম সময়ে ইভেন্ট প্রসেস করা
লক্ষ্য: ব্যবহারকারীর ইনপুটের মাধ্যমে শুরু হওয়া ট্রানজিশন ১০০ মিলিসেকেন্ডের মধ্যে সম্পূর্ণ করা, যাতে ব্যবহারকারী বুঝতে পারেন যে ইন্টার্যাকশনটি তাৎক্ষণিক হয়েছে।
নির্দেশিকা:
১০০ মিলিসেকেন্ডের মধ্যে দৃশ্যমান প্রতিক্রিয়া নিশ্চিত করতে, ৫০ মিলিসেকেন্ডের মধ্যে ব্যবহারকারীর ইনপুট ইভেন্ট প্রসেস করুন। এটি বেশিরভাগ ইনপুটের ক্ষেত্রে প্রযোজ্য, যেমন বোতামে ক্লিক করা, ফর্ম কন্ট্রোল টগল করা বা অ্যানিমেশন শুরু করা। এটি টাচ ড্র্যাগ বা স্ক্রল করার ক্ষেত্রে প্রযোজ্য নয়।
যদিও এটি স্বজ্ঞাত বলে মনে হতে পারে, তবে ব্যবহারকারীর ইনপুটে অবিলম্বে প্রতিক্রিয়া জানানো সবসময় সঠিক সিদ্ধান্ত নয়। আপনি এই ১০০ মি.সে. উইন্ডো ব্যবহার করে অন্যান্য ব্যয়বহুল কাজ করতে পারেন, তবে ব্যবহারকারীকে ব্লক না করার ব্যাপারে সতর্ক থাকুন। সম্ভব হলে, ব্যাকগ্রাউন্ডে কাজ করুন।
যেসব অ্যাকশন সম্পূর্ণ হতে ৫০ মিলিসেকেন্ডের বেশি সময় লাগে, সেগুলির জন্য সবসময় মতামত দিন।
৫০ মিলি.সে নাকি ১০০ মিলি.সে?
১০০ মিলিসেকেন্ডের কম সময়ে ইনপুটের উত্তর দেওয়াই হল লক্ষ্য, তাহলে আমাদের বাজেট কেন মাত্র ৫০ মিলিসেকেন্ড? এর কারণ হল, ইনপুট ম্যানেজ করার পাশাপাশি সাধারণত অন্যান্য কাজও করা হয় এবং সেই কাজ গ্রহণযোগ্য ইনপুট রেসপন্সের জন্য উপলভ্য সময়ের কিছুটা অংশ নিয়ে নেয়। কোনও অ্যাপ্লিকেশন যদি আইডল টাইমে সাজেস্ট করা ৫০ মিলিসেকেন্ডের চাঙ্কে কাজ করে, তাহলে এর অর্থ হল, ইনপুট ৫০ মিলিসেকেন্ড পর্যন্ত সারিবদ্ধ করা যেতে পারে, যদি এটি কাজের সেই চাঙ্কগুলির একটির সময় ঘটে। এই কারণে, এটি ধরে নেওয়া নিরাপদ যে প্রকৃত ইনপুট হ্যান্ডলিংয়ের জন্য শুধুমাত্র বাকি থাকা ৫০ মিলিসেকেন্ড উপলভ্য। এই প্রভাবটি নিচের ডায়াগ্রামে দেখানো হয়েছে, যেখানে দেখা যাচ্ছে যে কোনও আইডল টাস্ক চলাকালীন প্রাপ্ত ইনপুট কীভাবে সারিবদ্ধ করা হয়, যার ফলে উপলভ্য প্রসেসিং টাইম কমে যায়:
অ্যানিমেশন: ১০ মিলিসেকেন্ডে একটি ফ্রেম তৈরি করুন
লক্ষ্য:
অ্যানিমেশনের প্রতিটি ফ্রেম ১০ মিলি সেকেন্ড বা তার কম সময়ে তৈরি করুন। টেকনিক্যালি, প্রতিটি ফ্রেমের জন্য সর্বাধিক বাজেট হল ১৬ মিলি-সেকেন্ড (১০০০ মিলি-সেকেন্ড / ৬০ ফ্রেম প্রতি সেকেন্ড ≈ ১৬ মিলি-সেকেন্ড), কিন্তু প্রতিটি ফ্রেম রেন্ডার করতে ব্রাউজারের প্রায় ৬ মিলি-সেকেন্ড সময় লাগে, তাই ফ্রেম প্রতি ১০ মিলি-সেকেন্ডের নির্দেশিকা দেওয়া হয়েছে।
ভিজ্যুয়াল মসৃণতার দিকে লক্ষ্য রাখুন। ফ্রেম রেট পরিবর্তিত হলে ব্যবহারকারীরা তা লক্ষ্য করেন।
নির্দেশিকা:
অ্যানিমেশনের মতো হাই প্রেসার পয়েন্টে, মূল বিষয় হল যেখানে আপনি কিছু করতে পারবেন না সেখানে কিছু না করা এবং যেখানে আপনি পারবেন না সেখানে একেবারে ন্যূনতম করা। যখনই সম্ভব, ১০০ মিলিসেকেন্ডের রেসপন্স ব্যবহার করে দামী কাজ আগে থেকে হিসেব করে নিন যাতে ৬০ fps-এ পৌঁছানোর সম্ভাবনা সর্বাধিক হয়।
বিভিন্ন অ্যানিমেশন অপ্টিমাইজেশন স্ট্র্যাটেজির জন্য রেন্ডারিং পারফর্ম্যান্স দেখুন।
- ভিজ্যুয়াল অ্যানিমেশন, যেমন প্রবেশ ও প্রস্থান, টুইন এবং লোডিং ইন্ডিকেটর।
- স্ক্রল করা হচ্ছে। এর মধ্যে ফ্লিং করা অন্তর্ভুক্ত, অর্থাৎ ব্যবহারকারী স্ক্রল করা শুরু করে ছেড়ে দেন এবং পৃষ্ঠাটি স্ক্রল হতে থাকে।
- টেনে আনা। অ্যানিমেশন প্রায়ই ব্যবহারকারীর ইন্টার্যাকশন অনুসরণ করে, যেমন ম্যাপ প্যান করা বা জুম করার জন্য পিঞ্চ করা।
আইডল: আইডল টাইম সর্বাধিক করুন
লক্ষ্য: আইডল টাইম সর্বাধিক করা যাতে ৫০ মিলিসেকেন্ডের মধ্যে ব্যবহারকারীর ইনপুটের ভিত্তিতে পৃষ্ঠা উত্তর দেওয়ার সম্ভাবনা বৃদ্ধি পায়।
নির্দেশিকা:
স্থগিত কাজ সম্পূর্ণ করতে অলস সময় ব্যবহার করুন। যেমন, প্রাথমিক পৃষ্ঠা লোডের জন্য, যতটা সম্ভব কম ডেটা লোড করুন, তারপর বাকিটা লোড করতে আইডল টাইম ব্যবহার করুন।
আইডল টাইমে ৫০ মিলিসেকেন্ড বা তার কম সময়ে কাজ সম্পূর্ণ করুন। এর থেকে বেশি সময় নিলে, ৫০ মিলিসেকেন্ডের মধ্যে ব্যবহারকারীর ইনপুটের উত্তর দেওয়ার ক্ষেত্রে অ্যাপের ক্ষমতা বিঘ্নিত হতে পারে।
আইডল টাইম টাস্ক চলাকালীন কোনও ব্যবহারকারী পৃষ্ঠার সাথে ইন্টার্যাক্ট করলে, ব্যবহারকারীর ইন্টার্যাকশনকে সবচেয়ে বেশি অগ্রাধিকার দিতে হবে এবং আইডল টাইম টাস্ককে বাধা দিতে হবে।
লোড: কন্টেন্ট ডেলিভার করা এবং ৫ সেকেন্ডের কম সময়ে ইন্টার্যাক্টিভ হওয়া
পৃষ্ঠা ধীরে লোড হলে, ব্যবহারকারীর মনোযোগ অন্যদিকে চলে যায় এবং ব্যবহারকারী মনে করেন যে টাস্কটি সম্পূর্ণ হয়নি। যেসব সাইট দ্রুত লোড হয় সেগুলিতে গড় সেশনের সময়সীমা বেশি, বাউন্স রেট কম এবং বিজ্ঞাপন ভিউয়েবিলিটি বেশি হয়।
লক্ষ্য:
আপনার ব্যবহারকারীদের ডিভাইস ও নেটওয়ার্কের ক্ষমতা অনুযায়ী দ্রুত লোড হওয়ার পারফর্ম্যান্সের জন্য অপ্টিমাইজ করুন। বর্তমানে, প্রথমবার লোড করার জন্য একটি ভাল লক্ষ্য হল পৃষ্ঠাটি লোড করা এবং ধীরগতির 3G কানেকশন সহ মিড-রেঞ্জ মোবাইল ডিভাইসে ৫ সেকেন্ড বা তার কম সময়ে ইন্টার্যাক্টিভ হওয়া।
পরবর্তী লোডের জন্য, ২ সেকেন্ডের কম সময়ে পৃষ্ঠা লোড করা একটি ভালো লক্ষ্য।
নির্দেশিকা:
আপনার ব্যবহারকারীদের মধ্যে সাধারণ মোবাইল ডিভাইস এবং নেটওয়ার্ক কানেকশনে আপনার লোড পারফর্ম্যান্স পরীক্ষা করুন। আপনার ব্যবহারকারীদের কানেকশন ডিস্ট্রিবিউশন জানতে Chrome User Experience Report ব্যবহার করতে পারেন। আপনার সাইটের জন্য ডেটা উপলভ্য না থাকলে, The Mobile Economy 2019-এর সাজেশন অনুযায়ী, একটি ভাল গ্লোবাল বেসলাইন হল Moto G4-এর মতো মিড-রেঞ্জ Android ফোন এবং স্লো 3G নেটওয়ার্ক (৪০০ ms RTT এবং ৪০০ kbps ট্রান্সফার স্পিড হিসেবে সংজ্ঞায়িত)। এই কম্বিনেশন WebPageTest-এ উপলভ্য।
মনে রাখবেন, আপনার সাধারণ মোবাইল ব্যবহারকারীর ডিভাইস 2G, 3G বা 4G কানেকশনে আছে বলে দাবি করলেও, বাস্তবে কার্যকর কানেকশন স্পিড প্যাকেট লস এবং নেটওয়ার্কের তারতম্যের কারণে প্রায়শই উল্লেখযোগ্যভাবে ধীর হয়।
সম্পূর্ণ লোড হওয়ার অনুভূতি তৈরি করার জন্য আপনাকে ৫ সেকেন্ডের মধ্যে সবকিছু লোড করতে হবে না। ছবি ধীরে ধীরে লোড করা, জাভাস্ক্রিপ্ট বান্ডেল কোড-স্প্লিট করা এবং web.dev-এ সাজেস্ট করা অন্যান্য অপ্টিমাইজেশন বিবেচনা করুন।
RAIL পরিমাপ করার টুল
আপনার RAIL পরিমাপ অটোমেট করতে সাহায্য করার জন্য কয়েকটি টুল রয়েছে। আপনি কোনটি ব্যবহার করবেন তা নির্ভর করে আপনার কী ধরনের তথ্য প্রয়োজন এবং আপনি কী ধরনের ওয়ার্কফ্লো পছন্দ করেন তার উপর।
Chrome DevTools
আপনার পৃষ্ঠা লোড বা রান হওয়ার সময় যা কিছু ঘটে, Chrome DevTools সেইসব কিছুর গভীর বিশ্লেষণ প্রদান করে। পারফর্ম্যান্স প্যানেল UI সম্পর্কে জানতে রানটাইম পারফর্ম্যান্স বিশ্লেষণ করা শুরু করুন দেখুন।
DevTools-এর নিম্নলিখিত ফিচারগুলি বিশেষভাবে প্রাসঙ্গিক:
কম শক্তিশালী ডিভাইস সিমুলেট করতে, আপনার CPU থ্রটল করুন।
স্লো কানেকশন সিমুলেট করতে নেটওয়ার্ক থ্রটল করুন।
আপনি রেকর্ড করার সময় মূল থ্রেডে হওয়া প্রতিটি ইভেন্ট দেখতে মূল থ্রেড অ্যাক্টিভিটি দেখুন।
কোন অ্যাক্টিভিটি সবচেয়ে বেশি সময় নিয়েছে তার ভিত্তিতে অ্যাক্টিভিটি সাজাতে টেবিলে মূল থ্রেড অ্যাক্টিভিটি দেখুন।
আপনার অ্যানিমেশন সত্যিই মসৃণভাবে চলছে কিনা তা পরিমাপ করতে ফ্রেম প্রতি সেকেন্ড (FPS) বিশ্লেষণ করুন।
পারফর্ম্যান্স মনিটর-এর মাধ্যমে রিয়েল-টাইমে CPU ব্যবহার, JS হিপ সাইজ, DOM নোড, প্রতি সেকেন্ডে লেআউট এবং আরও অনেক কিছু মনিটর করুন।
নেটওয়ার্ক বিভাগ ব্যবহার করে রেকর্ড করার সময় হওয়া নেটওয়ার্ক অনুরোধ ভিজ্যুয়ালাইজ করুন।
রেকর্ড করার সময় স্ক্রিনশট ক্যাপচার করুন যাতে পৃষ্ঠা লোড হওয়ার সময় বা অ্যানিমেশন চালু হওয়ার সময় পৃষ্ঠাটি ঠিক কেমন দেখতে ছিল তা প্লেব্যাক করে দেখা যায়।
ব্যবহারকারী কোনও পৃষ্ঠার সাথে ইন্টার্যাক্ট করার পরে কী হয়েছে তা দ্রুত শনাক্ত করতে ইন্টার্যাকশন দেখুন।
সম্ভাব্য সমস্যাযুক্ত লিসেনার ফায়ার করলেই পৃষ্ঠা হাইলাইট করার মাধ্যমে রিয়েল-টাইমে স্ক্রল পারফর্ম্যান্স সংক্রান্ত সমস্যা খুঁজে নিন।
রিয়েল-টাইমে পেইন্ট ইভেন্ট দেখুন যাতে ব্যয়বহুল পেইন্ট ইভেন্ট শনাক্ত করা যায় যা আপনার অ্যানিমেশনের পারফর্ম্যান্সকে ক্ষতিগ্রস্ত করতে পারে।
লাইটহাউস
Lighthouse, Chrome DevTools-এ, PageSpeed Insights-এ, Chrome এক্সটেনশন হিসেবে, Node.js মডিউল হিসেবে এবং WebPageTest-এর মধ্যে উপলভ্য। আপনি এটিকে একটি URL দিলে, এটি স্লো 3G কানেকশন সহ একটি মিড-রেঞ্জ ডিভাইস সিমুলেট করে, পৃষ্ঠায় একাধিক অডিট চালায় এবং তারপরে আপনাকে লোড পারফর্ম্যান্সের একটি রিপোর্ট দেয়, সেইসাথে কীভাবে উন্নতি করা যায় তার সাজেশনও দেয়।
নিম্নলিখিত অডিটগুলি বিশেষভাবে প্রাসঙ্গিক:
প্রতিক্রিয়া
সর্বাধিক সম্ভাব্য ফার্স্ট ইনপুট ডিলে। মূল থ্রেড নিষ্ক্রিয় থাকার সময়ের উপর ভিত্তি করে, ব্যবহারকারীর ইনপুটের উত্তর দিতে আপনার অ্যাপের কত সময় লাগবে তা অনুমান করে।
স্ক্রল করার পারফর্ম্যান্স উন্নত করতে প্যাসিভ লিসেনার ব্যবহার করে না।
Total Blocking Time। মাউস ক্লিক, স্ক্রিন ট্যাপ বা কীবোর্ড প্রেসের মতো ব্যবহারকারীর ইনপুটে সাড়া দেওয়া থেকে কোনও পৃষ্ঠা ব্লক করা মোট সময় পরিমাপ করে।
Time To Interactive. ব্যবহারকারী কখন পৃষ্ঠার সব এলিমেন্টের সাথে ধারাবাহিকভাবে ইন্টার্যাক্ট করতে পারবেন তা পরিমাপ করে।
লোড করুন
এমন কোনও সার্ভিস ওয়ার্কার রেজিস্টার করে না যা পৃষ্ঠা ও start_url কন্ট্রোল করে। সার্ভিস ওয়ার্কার ব্যবহারকারীর ডিভাইসে সাধারণ রিসোর্স ক্যাশে করতে পারে, যার ফলে নেটওয়ার্ক থেকে রিসোর্স ফেচ করার সময় কমে যায়।
অফস্ক্রিন ছবি ডিফার করা। অফস্ক্রিন ছবিগুলি প্রয়োজন না হওয়া পর্যন্ত লোড করা স্থগিত রাখুন।
ছবির সাইজ ঠিক করুন। মোবাইল ভিউপোর্টে রেন্ডার করা সাইজের থেকে অনেক বড় ছবি পরিবেশন করবেন না।
DOM-এর সাইজ যাতে অতিরিক্ত না হয়ে যায় তার জন্য কী করবেন জানুন। নেটওয়ার্ক বাইট কমান শুধুমাত্র পৃষ্ঠা রেন্ডার করার জন্য প্রয়োজনীয় DOM নোড শিপিং করে।
WebPageTest
WebPageTest হল একটি ওয়েব পারফর্ম্যান্স টুল যা ওয়েব পৃষ্ঠা অ্যাক্সেস করতে এবং টাইমিং মেট্রিক সংগ্রহ করতে আসল ব্রাউজার ব্যবহার করে। webpagetest.org/easy-এ গিয়ে URL লিখুন এবং স্লো 3G কানেকশন সহ আসল Moto G4 ডিভাইসে পেজ লোড হওয়ার পারফর্ম্যান্সের বিস্তারিত রিপোর্ট পান। এছাড়াও, আপনি এটি কনফিগার করতে পারেন যাতে একটি Lighthouse অডিট অন্তর্ভুক্ত থাকে।
সারাংশ
RAIL হল একটি লেন্স যা কোনও ওয়েবসাইটের ব্যবহারকারীর অভিজ্ঞতাকে বিভিন্ন ইন্টার্যাকশনের মাধ্যমে তৈরি হওয়া একটি জার্নি হিসেবে দেখে। ব্যবহারকারীর অভিজ্ঞতার উপর সবচেয়ে বেশি প্রভাব ফেলে এমন পারফর্ম্যান্স লক্ষ্য সেট করতে, ব্যবহারকারীরা আপনার সাইটকে কীভাবে দেখেন তা বুঝুন।
ব্যবহারকারীর উপর ফোকাস করুন।
১০০ মিলিসেকেন্ডের কম সময়ে ব্যবহারকারীর ইনপুটের উত্তর দিন।
অ্যানিমেট বা স্ক্রল করার সময় ১০ মিলিসেকেন্ডের কম সময়ে ফ্রেম তৈরি করুন।
মূল থ্রেডের আইডল টাইম সর্বাধিক করুন।
৫০০০ মিলিসেকেন্ডের কম সময়ে ইন্টার্যাক্টিভ কন্টেন্ট লোড করুন।