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