একটি ভাল প্রতিক্রিয়াশীলতা মেট্রিকের দিকে

প্রতিক্রিয়াশীলতা পরিমাপ সম্পর্কে আমাদের চিন্তাভাবনা সম্পর্কে জানুন এবং আমাদের প্রতিক্রিয়া দিন।

অ্যানি সুলিভান

হংবো গান

নিকোলাস পেনা মোরেনো

ক্রোম স্পিড মেট্রিক্স টিমে, আমরা ওয়েব পৃষ্ঠাগুলি ব্যবহারকারীর ইনপুটে কত দ্রুত সাড়া দেয় সে সম্পর্কে আমাদের বোঝার গভীরতা নিয়ে কাজ করছি। আমরা প্রতিক্রিয়াশীলতা মেট্রিক্স উন্নত করার জন্য কিছু ধারণা শেয়ার করতে চাই এবং আপনার প্রতিক্রিয়া শুনতে চাই।

এই পোস্টটি দুটি প্রধান বিষয় কভার করবে:

1. আমাদের বর্তমান প্রতিক্রিয়াশীলতা মেট্রিক, ফার্স্ট ইনপুট বিলম্ব (FID) পর্যালোচনা করুন এবং ব্যাখ্যা করুন কেন আমরা কিছু বিকল্পের পরিবর্তে FID বেছে নিয়েছি।
2. কিছু উন্নতি উপস্থাপন করুন যা আমরা বিবেচনা করছি যেগুলি পৃথক ইভেন্টের শেষ থেকে শেষ লেটেন্সিকে আরও ভালভাবে ক্যাপচার করা উচিত। এই উন্নতিগুলির লক্ষ্য হল একটি পৃষ্ঠার সারাজীবনের সামগ্রিক প্রতিক্রিয়াশীলতার আরও সামগ্রিক চিত্র ক্যাপচার করা।

প্রথম ইনপুট বিলম্ব কি?

প্রথম ইনপুট বিলম্ব (এফআইডি) মেট্রিক পরিমাপ করে যে একটি পৃষ্ঠায় প্রথম ব্যবহারকারীর ইন্টারঅ্যাকশন প্রক্রিয়া শুরু করতে ব্রাউজার কত সময় নেয়। বিশেষ করে, এটি ব্যবহারকারীর ডিভাইসের সাথে ইন্টারঅ্যাক্ট করার সময় এবং ব্রাউজার প্রকৃতপক্ষে ইভেন্ট হ্যান্ডলার প্রক্রিয়াকরণ শুরু করতে সক্ষম হওয়ার সময়ের মধ্যে পার্থক্য পরিমাপ করে। FID শুধুমাত্র ট্যাপ এবং কী প্রেসের জন্য পরিমাপ করা হয়, যার মানে হল যে এটি শুধুমাত্র নিম্নলিখিত ইভেন্টগুলির প্রথম ঘটনাকে বিবেচনা করে:

• click
• keydown
• mousedown
• pointerdown (শুধুমাত্র যদি এটি pointerup দ্বারা অনুসরণ করা হয়)

নিম্নলিখিত চিত্রটি FID চিত্রিত করে:

এফআইডি সেই ইভেন্ট হ্যান্ডলারদের চালানোর জন্য ব্যয় করা সময়কে অন্তর্ভুক্ত করে না, বা স্ক্রীন আপডেট করার জন্য ব্রাউজার দ্বারা করা কোনো কাজও অন্তর্ভুক্ত নয়। এটি একটি ইনপুট পরিচালনা করার সুযোগ পাওয়ার আগে মূল থ্রেডটি কতটা সময় ব্যস্ত ছিল তা পরিমাপ করে। এই ব্লকিং টাইমটি সাধারণত দীর্ঘ জাভাস্ক্রিপ্ট টাস্কের কারণে হয়, কারণ এগুলি যে কোনও সময়ে বন্ধ করা যায় না, তাই ব্রাউজার ইনপুট প্রক্রিয়াকরণ শুরু করার আগে বর্তমান কাজটি অবশ্যই সম্পূর্ণ করতে হবে।

কেন আমরা FID বেছে নিলাম?

আমরা বিশ্বাস করি প্রকৃত ব্যবহারকারীর অভিজ্ঞতা পরিমাপ করা জরুরী যাতে নিশ্চিত করা যায় যে মেট্রিকের উন্নতিগুলি ব্যবহারকারীকে প্রকৃত সুবিধা দেয়৷ আমরা FID পরিমাপ করা বেছে নিয়েছি কারণ এটি ব্যবহারকারীর অভিজ্ঞতার অংশকে প্রতিনিধিত্ব করে যখন ব্যবহারকারী এমন একটি সাইটের সাথে ইন্টারঅ্যাক্ট করার সিদ্ধান্ত নেয় যা সবেমাত্র লোড করা হয়েছে। FID এমন কিছু সময় ক্যাপচার করে যা ব্যবহারকারীকে একটি সাইটের সাথে তাদের মিথস্ক্রিয়া থেকে প্রতিক্রিয়া দেখার জন্য অপেক্ষা করতে হয়। অন্য কথায়, FID হল একজন ব্যবহারকারী ইন্টারঅ্যাক্ট করার পর যে পরিমাণ সময় অপেক্ষা করে তার উপর একটি নিম্ন সীমা।

অন্যান্য মেট্রিক্স যেমন টোটাল ব্লকিং টাইম (TBT) এবং টাইম টু ইন্টারঅ্যাকটিভ (TTI) দীর্ঘ টাস্কের উপর ভিত্তি করে এবং FID এর মত, লোডের সময় প্রধান থ্রেড ব্লক করার সময়ও পরিমাপ করে। যেহেতু এই মেট্রিকগুলি ক্ষেত্র এবং ল্যাব উভয় ক্ষেত্রেই পরিমাপ করা যেতে পারে, তাই অনেক বিকাশকারী জিজ্ঞাসা করেছেন কেন আমরা FID এর চেয়ে এইগুলির একটিকে পছন্দ করি না৷

এর বেশ কিছু কারণ রয়েছে। সম্ভবত সবচেয়ে গুরুত্বপূর্ণ কারণ হল এই মেট্রিক্স সরাসরি ব্যবহারকারীর অভিজ্ঞতা পরিমাপ করে না। এই সমস্ত মেট্রিক্স পৃষ্ঠায় কতটা জাভাস্ক্রিপ্ট চলে তা পরিমাপ করে। যদিও জাভাস্ক্রিপ্ট দীর্ঘ সময় ধরে চলার ফলে সাইটগুলিতে সমস্যা দেখা দেয়, এই কাজগুলি ব্যবহারকারীর অভিজ্ঞতাকে প্রভাবিত করে না যদি ব্যবহারকারী যখন পৃষ্ঠাটির সাথে ইন্টারঅ্যাক্ট না করে থাকে। একটি পৃষ্ঠার টিবিটি এবং টিটিআই-তে দুর্দান্ত স্কোর থাকতে পারে তবে ধীর বোধ করতে পারে বা ব্যবহারকারীদের জন্য দ্রুত বোধ করার সময় এটি একটি খারাপ স্কোর থাকতে পারে। আমাদের অভিজ্ঞতায়, এই পরোক্ষ পরিমাপের ফলে কিছু সাইটের জন্য দুর্দান্ত কাজ করে কিন্তু বেশিরভাগ সাইটের জন্য নয়। সংক্ষেপে, দীর্ঘ টাস্ক এবং টিটিআই ব্যবহারকারী-কেন্দ্রিক নয় এই সত্যটি এই দুর্বল প্রার্থীদের করে তোলে।

যদিও ল্যাব পরিমাপ অবশ্যই গুরুত্বপূর্ণ এবং ডায়াগনস্টিকসের জন্য একটি অমূল্য হাতিয়ার, তবে ব্যবহারকারীরা কীভাবে সাইটগুলিকে অনুভব করেন তা আসলেই গুরুত্বপূর্ণ। বাস্তব-ব্যবহারকারীর অবস্থার প্রতিফলন করে এমন একটি ব্যবহারকারী-কেন্দ্রিক মেট্রিক থাকার মাধ্যমে, আপনি অভিজ্ঞতা সম্পর্কে অর্থপূর্ণ কিছু ক্যাপচার করার নিশ্চয়তা পাবেন। আমরা সেই অভিজ্ঞতার একটি ছোট অংশ দিয়ে শুরু করার সিদ্ধান্ত নিয়েছি, যদিও আমরা জানি যে এই অংশটি সম্পূর্ণ অভিজ্ঞতার প্রতিনিধি নয়৷ এই কারণেই আমরা একজন ব্যবহারকারী তাদের ইনপুটগুলি পরিচালনা করার জন্য অপেক্ষা করার সময়টির একটি বৃহত্তর অংশ ক্যাপচার করার জন্য কাজ করছি৷

আমরা কি উন্নতি বিবেচনা করছি?

আমরা একটি নতুন মেট্রিক বিকাশ করতে চাই যা আজকে FID যা পরিমাপ করে তা প্রসারিত করে তবুও ব্যবহারকারীর অভিজ্ঞতার সাথে এর শক্তিশালী সংযোগ বজায় রাখে।

আমরা নতুন মেট্রিক চাই:

1. সমস্ত ব্যবহারকারীর ইনপুটগুলির প্রতিক্রিয়াশীলতা বিবেচনা করুন (শুধু প্রথমটি নয়)
2. প্রতিটি ইভেন্টের সম্পূর্ণ সময়কাল ক্যাপচার করুন (শুধু বিলম্ব নয়)।
3. একই যৌক্তিক ব্যবহারকারীর ইন্টারঅ্যাকশনের অংশ হিসাবে ঘটতে পারে এমন ইভেন্টগুলিকে একত্রে গোষ্ঠীভুক্ত করে এবং সেই মিথস্ক্রিয়াটির বিলম্বকে এর সমস্ত ইভেন্টের সর্বাধিক সময়কাল হিসাবে সংজ্ঞায়িত করে৷
4. একটি পৃষ্ঠায় ঘটে যাওয়া সমস্ত মিথস্ক্রিয়াগুলির জন্য একটি সামগ্রিক স্কোর তৈরি করুন, তার পুরো জীবনচক্র জুড়ে৷

সফল হওয়ার জন্য, আমাদের উচ্চ আত্মবিশ্বাসের সাথে বলতে সক্ষম হওয়া উচিত যে এই নতুন মেট্রিকে একটি সাইট যদি খারাপভাবে স্কোর করে, তবে এটি ব্যবহারকারীর ইন্টারঅ্যাকশনে দ্রুত সাড়া দিচ্ছে না।

সম্পূর্ণ ইভেন্ট সময়কাল ক্যাপচার

প্রথম সুস্পষ্ট উন্নতি হল একটি ইভেন্টের বৃহত্তর এন্ড-টু-এন্ড লেটেন্সি ক্যাপচার করার চেষ্টা করা। উপরে উল্লিখিত হিসাবে, FID শুধুমাত্র ইনপুট ইভেন্টের বিলম্বের অংশ ক্যাপচার করে। ইভেন্ট হ্যান্ডলারগুলিকে প্রকৃতপক্ষে প্রক্রিয়া করতে ব্রাউজারটি যে সময় নেয় তার জন্য এটি হিসাব করে না।

একটি ইভেন্টের জীবনচক্রের বিভিন্ন পর্যায় রয়েছে, যেমনটি এই চিত্রটিতে দেখানো হয়েছে:

একটি ইনপুট প্রক্রিয়া করার জন্য Chrome যে পদক্ষেপগুলি নেয় তা হল:

1. ব্যবহারকারীর কাছ থেকে ইনপুট ঘটে। যে সময়ে এটি ঘটে সেটি হল ইভেন্টের timeStamp ।
2. কোন ইভেন্টের অন্তর্গত কোন HTML ফ্রেম (প্রধান ফ্রেম বা কিছু আইফ্রেম) তা নির্ধারণ করতে ব্রাউজার হিট টেস্টিং করে। তারপর ব্রাউজার সেই HTML ফ্রেমের দায়িত্বে থাকা উপযুক্ত রেন্ডারার প্রক্রিয়ার কাছে ইভেন্টটি পাঠায়।
3. রেন্ডারার ইভেন্টটি গ্রহণ করে এবং এটিকে সারিবদ্ধ করে যাতে এটি করার জন্য উপলব্ধ হলে এটি প্রক্রিয়া করতে পারে।
4. রেন্ডারার তার হ্যান্ডলার চালানোর মাধ্যমে ইভেন্ট প্রক্রিয়া করে। এই হ্যান্ডলাররা অতিরিক্ত অ্যাসিঙ্ক্রোনাস কাজ সারিবদ্ধ করতে পারে, যেমন setTimeout এবং ফেচ, যা ইনপুট পরিচালনার অংশ। কিন্তু এই মুহুর্তে, সিঙ্ক্রোনাস কাজ সম্পূর্ণ হয়।
5. পর্দায় একটি ফ্রেম আঁকা হয় যা ইভেন্ট হ্যান্ডলারদের চলমান ফলাফল প্রতিফলিত করে। মনে রাখবেন যে ইভেন্ট হ্যান্ডলারদের দ্বারা সারিবদ্ধ কোনো অ্যাসিঙ্ক্রোনাস কাজ এখনও অসমাপ্ত থাকতে পারে।

উপরের ধাপগুলি (1) এবং (3) এর মধ্যে সময় হল একটি ইভেন্টের বিলম্ব , যা FID পরিমাপ করে৷

উপরের ধাপ (1) এবং (5) এর মধ্যে সময় হল একটি ইভেন্টের সময়কাল ৷ এটি আমাদের নতুন মেট্রিক পরিমাপ করবে।

ইভেন্টের সময়কালের মধ্যে বিলম্ব অন্তর্ভুক্ত থাকে, তবে এতে ইভেন্ট হ্যান্ডলারের কাজ এবং সেই হ্যান্ডলারগুলি চালানোর পরে পরবর্তী ফ্রেমটি আঁকার জন্য ব্রাউজারকে যে কাজ করতে হবে তাও এতে অন্তর্ভুক্ত থাকে। একটি ইভেন্টের সময়কাল বর্তমানে এন্ট্রির সময়কাল বৈশিষ্ট্যের মাধ্যমে ইভেন্ট টাইমিং API- এ উপলব্ধ।

ইভেন্টগুলিকে মিথস্ক্রিয়ায় গোষ্ঠীবদ্ধ করুন

বিলম্ব থেকে সময়কাল পর্যন্ত মেট্রিক পরিমাপ বাড়ানো একটি ভাল প্রথম পদক্ষেপ, কিন্তু এটি এখনও মেট্রিকের একটি গুরুত্বপূর্ণ ফাঁক রেখে যায়: এটি ব্যক্তিগত ইভেন্টগুলিতে ফোকাস করে এবং পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার ব্যবহারকারীর অভিজ্ঞতা নয়।

একক ব্যবহারকারীর ইন্টারঅ্যাকশনের ফলে অনেকগুলি বিভিন্ন ইভেন্ট ফায়ার হতে পারে, এবং প্রতিটিকে আলাদাভাবে পরিমাপ করা ব্যবহারকারীর অভিজ্ঞতার একটি পরিষ্কার চিত্র তৈরি করে না। আমরা নিশ্চিত করতে চাই যে আমাদের মেট্রিক যতটা সম্ভব নির্ভুলভাবে ট্যাপ করার, কী টিপে, স্ক্রলিং করা এবং টেনে আনার সময় একজন ব্যবহারকারীকে প্রতিক্রিয়ার জন্য অপেক্ষা করতে হয় এমন সম্পূর্ণ সময় ধরে রাখে। তাই আমরা প্রতিটির লেটেন্সি পরিমাপ করার জন্য ইন্টারঅ্যাকশনের ধারণাটি প্রবর্তন করছি।

মিথস্ক্রিয়া প্রকার

নিম্নলিখিত সারণীতে আমরা যে চারটি মিথস্ক্রিয়াকে সংজ্ঞায়িত করতে চাই সেই DOM ইভেন্টগুলির সাথে তারা যুক্ত রয়েছে তা তালিকাভুক্ত করে৷ মনে রাখবেন যে এই ধরনের ব্যবহারকারীর ইন্টারঅ্যাকশন ঘটলে প্রেরিত সমস্ত ইভেন্টের সেটের মতো এটি পুরোপুরি একই নয়। উদাহরণস্বরূপ, যখন একজন ব্যবহারকারী স্ক্রল করে, তখন একটি স্ক্রোল ইভেন্ট পাঠানো হয়, কিন্তু স্ক্রলিং প্রতিফলিত করার জন্য স্ক্রীন আপডেট হওয়ার পরে এটি ঘটে, তাই আমরা এটিকে ইন্টারঅ্যাকশন লেটেন্সির অংশ হিসেবে বিবেচনা করি না।

উপরে তালিকাভুক্ত প্রথম তিনটি ইন্টারঅ্যাকশন (কীবোর্ড, ট্যাপ, এবং টেনে) বর্তমানে FID দ্বারা আচ্ছাদিত। আমাদের নতুন প্রতিক্রিয়াশীলতা মেট্রিকের জন্য, আমরা স্ক্রলিংও অন্তর্ভুক্ত করতে চাই, যেহেতু স্ক্রলিং ওয়েবে অত্যন্ত সাধারণ এবং একটি পৃষ্ঠা ব্যবহারকারীদের কাছে কতটা প্রতিক্রিয়াশীল মনে করে তার একটি গুরুত্বপূর্ণ দিক।

কীবোর্ড

একটি কীবোর্ড ইন্টারঅ্যাকশনের দুটি অংশ থাকে: যখন ব্যবহারকারী কী টিপে এবং কখন এটি ছেড়ে দেয়। এই ব্যবহারকারীর ইন্টারঅ্যাকশনের সাথে তিনটি সম্পর্কিত ইভেন্ট রয়েছে: keydown , keyup এবং keypress । নিম্নলিখিত চিত্রটি একটি কীবোর্ড ইন্টারঅ্যাকশনের জন্য keydown এবং keyup বিলম্ব এবং সময়কাল চিত্রিত করে:

উপরের চিত্রে, সময়কালগুলি বিচ্ছিন্ন করা হয়েছে কারণ keydown আপডেটের ফ্রেমটি keyup হওয়ার আগে উপস্থাপন করা হয়েছে, তবে এটি সর্বদা এমন হওয়ার প্রয়োজন নেই। উপরন্তু, মনে রাখবেন যে রেন্ডারার প্রক্রিয়ায় একটি টাস্কের মাঝখানে একটি ফ্রেম উপস্থাপন করা যেতে পারে যেহেতু ফ্রেম তৈরি করার জন্য প্রয়োজনীয় শেষ ধাপগুলি রেন্ডারার প্রক্রিয়ার বাইরে সম্পন্ন করা হয়।

ব্যবহারকারী কী টিপে যখন keydown এবং keypress ঘটে, যখন ব্যবহারকারী কীটি প্রকাশ করে তখন keyup ঘটে। সাধারণত মূল বিষয়বস্তু আপডেটটি ঘটে যখন কী টিপানো হয়: পাঠ্যটি পর্দায় উপস্থিত হয়, বা সংশোধক প্রভাব প্রয়োগ করা হয়। এটি বলেছে, আমরা আরও বিরল ক্ষেত্রে ক্যাপচার করতে চাই যেখানে keyup আকর্ষণীয় UI আপডেটগুলিও উপস্থাপন করবে, তাই আমরা সামগ্রিক সময় নেওয়ার দিকে তাকাতে চাই।

কীবোর্ড মিথস্ক্রিয়া দ্বারা নেওয়া সামগ্রিক সময় ক্যাপচার করার জন্য, আমরা keydown এবং keyup ইভেন্টগুলির সর্বাধিক সময়কাল গণনা করতে পারি।

টোকা

আরেকটি গুরুত্বপূর্ণ ব্যবহারকারীর মিথস্ক্রিয়া হল যখন ব্যবহারকারী একটি ওয়েবসাইটে ট্যাপ বা ক্লিক করে। keypress অনুরূপ, কিছু ইভেন্ট ব্যবহারকারীর চাপ দেওয়ার সাথে সাথে গুলি করা হয় এবং অন্যগুলি প্রকাশের সাথে সাথে, উপরের চিত্রে দেখানো হয়েছে, নোট করুন যে একটি ট্যাপের সাথে যুক্ত ইভেন্টগুলি ডেস্কটপ বনাম মোবাইলে একটু ভিন্ন।

একটি ট্যাপ বা ক্লিকের জন্য, রিলিজটি সাধারণত এমন একটি যা বেশিরভাগ প্রতিক্রিয়াকে ট্রিগার করে, কিন্তু, কীবোর্ড ইন্টারঅ্যাকশনের মতো, আমরা সম্পূর্ণ মিথস্ক্রিয়া ক্যাপচার করতে চাই। এবং এই ক্ষেত্রে এটি করা আরও গুরুত্বপূর্ণ কারণ ট্যাপ প্রেসে কিছু UI আপডেট থাকা আসলে অস্বাভাবিক নয়।

আমরা এই সমস্ত ইভেন্টের জন্য ইভেন্টের সময়কাল অন্তর্ভুক্ত করতে চাই, কিন্তু তাদের মধ্যে অনেকগুলি সম্পূর্ণরূপে ওভারল্যাপ করায়, আমাদের শুধুমাত্র pointerdown , pointerup পরিমাপ করতে হবে এবং সম্পূর্ণ মিথস্ক্রিয়া কভার করতে click ।

টেনে আনুন

আমরা ড্র্যাগিংকেও অন্তর্ভুক্ত করার সিদ্ধান্ত নিয়েছি যেহেতু এটির সাথে একই রকম সম্পর্কিত ইভেন্ট রয়েছে এবং যেহেতু এটি সাধারণত সাইটগুলিতে গুরুত্বপূর্ণ UI আপডেট করে। কিন্তু আমাদের মেট্রিকের জন্য আমরা শুধুমাত্র ড্র্যাগ স্টার্ট এবং ড্র্যাগ এন্ড বিবেচনা করতে চাই - ড্র্যাগের প্রাথমিক এবং শেষ অংশ। এটি যুক্তিযুক্ত করা সহজ করার পাশাপাশি বিবেচিত অন্যান্য মিথস্ক্রিয়াগুলির সাথে লেটেন্সিগুলিকে তুলনীয় করে তোলার জন্য। এটি mouseover মতো ক্রমাগত ইভেন্টগুলি বাদ দেওয়ার আমাদের সিদ্ধান্তের সাথে সামঞ্জস্যপূর্ণ।

আমরা ড্র্যাগ এবং ড্রপ API এর মাধ্যমে প্রয়োগ করা ড্র্যাগগুলি বিবেচনা করছি না কারণ তারা শুধুমাত্র ডেস্কটপে কাজ করে।

স্ক্রোলিং

একটি সাইটের সাথে ইন্টারঅ্যাক্ট করার সবচেয়ে সাধারণ ফর্মগুলির মধ্যে একটি হল স্ক্রোলিং এর মাধ্যমে। আমাদের নতুন মেট্রিকের জন্য, আমরা ব্যবহারকারীর প্রাথমিক স্ক্রলিং ইন্টারঅ্যাকশনের জন্য লেটেন্সি পরিমাপ করতে চাই। বিশেষ করে, ব্যবহারকারী একটি স্ক্রোল করার জন্য অনুরোধ করেছে তা সম্পর্কে আমরা ব্রাউজারের প্রাথমিক প্রতিক্রিয়া সম্পর্কে যত্নশীল। আমরা পুরো স্ক্রোলিং অভিজ্ঞতা কভার করব না। অর্থাৎ, স্ক্রলিং অনেক ফ্রেম তৈরি করে, এবং আমরা স্ক্রলের প্রতিক্রিয়া হিসাবে উৎপন্ন প্রাথমিক ফ্রেমের দিকে আমাদের মনোযোগ কেন্দ্রীভূত করব।

শুধু প্রথম কেন? একটির জন্য, পরবর্তী ফ্রেমগুলি একটি পৃথক মসৃণতা প্রস্তাব দ্বারা ক্যাপচার করা যেতে পারে। অর্থাৎ, একবার ব্যবহারকারীকে স্ক্রল করার প্রথম ফলাফল দেখানো হলে, বাকিটা স্ক্রল করার অভিজ্ঞতা কতটা মসৃণ মনে হয় তার পরিপ্রেক্ষিতে পরিমাপ করা উচিত। অতএব, আমরা মনে করি যে মসৃণতার প্রচেষ্টা এটিকে আরও ভালভাবে ধরতে পারে। সুতরাং, FID-এর মতো, আমরা বিচ্ছিন্ন ব্যবহারকারীর অভিজ্ঞতার সাথে লেগে থাকতে বেছে নিই: ব্যবহারকারীর অভিজ্ঞতা যেগুলির সাথে নির্দিষ্ট সময়ের সাথে সম্পর্কিত এবং যার জন্য আমরা সহজেই তাদের লেটেন্সি গণনা করতে পারি। সামগ্রিকভাবে স্ক্রোল করা একটি অবিচ্ছিন্ন অভিজ্ঞতা, তাই আমরা এই মেট্রিকে এটির সমস্ত পরিমাপ করতে চাই না।

তাহলে কেন স্ক্রল পরিমাপ? আমরা Chrome এ যে স্ক্রলিং কর্মক্ষমতা সংগ্রহ করেছি তা দেখায় যে স্ক্রোলিং সাধারণত খুব দ্রুত হয়। এটি বলেছে, আমরা এখনও বিভিন্ন কারণে আমাদের নতুন মেট্রিকে প্রাথমিক স্ক্রোল বিলম্বগুলি অন্তর্ভুক্ত করতে চাই। প্রথমত, স্ক্রোলিং দ্রুত হয় কারণ এটি এত বেশি অপ্টিমাইজ করা হয়েছে, কারণ এটি খুবই গুরুত্বপূর্ণ। কিন্তু ব্রাউজার অফার করে এমন কিছু পারফরম্যান্স লাভকে বাইপাস করার জন্য একটি ওয়েবসাইটের জন্য এখনও উপায় রয়েছে। ক্রোমের সবচেয়ে সাধারণ একটি হল প্রধান থ্রেডে ঘটতে জোর করে স্ক্রলিং করা। তাই আমাদের মেট্রিক বলতে সক্ষম হওয়া উচিত কখন এটি ঘটে এবং ব্যবহারকারীদের জন্য খারাপ স্ক্রলিং কার্যকারিতা সৃষ্টি করে। দ্বিতীয়ত, স্ক্রোলিং উপেক্ষা করা খুব গুরুত্বপূর্ণ। আমরা উদ্বিগ্ন যে যদি আমরা স্ক্রলিং বাদ দিই তাহলে আমাদের একটি বড় ব্লাইন্ডস্পট থাকবে, এবং ওয়েব ডেভেলপাররা সঠিকভাবে লক্ষ্য না করে স্ক্রলিং কর্মক্ষমতা সময়ের সাথে সাথে হ্রাস পেতে পারে।

ব্যবহারকারীর স্ক্রোল করার সময় বেশ কিছু ইভেন্ট পাঠানো হয়, যেমন touchstart , touchmove এবং scroll । স্ক্রল ইভেন্ট ব্যতীত, এটি মূলত স্ক্রোলিংয়ের জন্য ব্যবহৃত ডিভাইসের উপর নির্ভরশীল: মোবাইল ডিভাইসে আঙুল দিয়ে স্ক্রোল করার সময় স্পর্শ ঘটনাগুলি প্রেরণ করা হয়, যখন মাউসের চাকা দিয়ে স্ক্রোল করার সময় চাকার ঘটনা ঘটে। প্রাথমিক স্ক্রোলিং শেষ হওয়ার পরে স্ক্রোল ইভেন্টগুলি বরখাস্ত করা হয়। এবং সাধারণভাবে, কোনো DOM ইভেন্ট স্ক্রলিং ব্লক করে না, যদি না ওয়েবসাইটটি নন-প্যাসিভ ইভেন্ট শ্রোতাদের ব্যবহার করে। তাই আমরা DOM ইভেন্টগুলি থেকে সম্পূর্ণরূপে স্ক্রল করার কথা মনে করি। আমরা যা পরিমাপ করতে চাই তা হল সেই সময় থেকে যখন ব্যবহারকারী একটি স্ক্রোল অঙ্গভঙ্গি তৈরি করার জন্য যথেষ্ট নড়াচড়া করে যে প্রথম ফ্রেমটি দেখায় যে স্ক্রলিং ঘটেছে।

কিভাবে একটি মিথস্ক্রিয়া এর বিলম্বিতা সংজ্ঞায়িত?

যেমনটি আমরা উপরে উল্লেখ করেছি, যে ইন্টারঅ্যাকশনগুলির একটি "নিচে" এবং "উপর" উপাদান রয়েছে সেগুলিকে আলাদাভাবে বিবেচনা করতে হবে যাতে ব্যবহারকারী তাদের আঙুল চেপে ধরে কাটানো সময়কে দায়ী করা না হয়।

এই ধরনের মিথস্ক্রিয়াগুলির জন্য, আমরা তাদের সাথে যুক্ত সমস্ত ইভেন্টের সময়কাল জড়িত করতে দেরি করতে চাই। যেহেতু মিথস্ক্রিয়াটির প্রতিটি "নিচে" এবং "আপ" অংশের জন্য ইভেন্টের সময়কাল ওভারল্যাপ হতে পারে, তাই ইন্টারঅ্যাকশন লেটেন্সির সবচেয়ে সহজ সংজ্ঞা যা এটি অর্জন করে তা হল এটির সাথে যুক্ত যেকোনো ইভেন্টের সর্বাধিক সময়কাল। আগের থেকে কীবোর্ড ডায়াগ্রামে ফিরে উল্লেখ করে, এটি keydown সময়কাল হবে, কারণ এটি keyup চেয়ে দীর্ঘ:

keydown এবং keyup সময়কাল পাশাপাশি ওভারল্যাপ হতে পারে। উদাহরণস্বরূপ এটি ঘটতে পারে যখন উভয় ইভেন্টের জন্য উপস্থাপিত ফ্রেম একই হয়, যেমন নিম্নলিখিত চিত্রে:

সর্বাধিক ব্যবহার করার এই পদ্ধতির সুবিধা এবং অসুবিধা রয়েছে এবং আমরা আপনার প্রতিক্রিয়া শুনতে আগ্রহী:

• প্রো : আমরা কীভাবে স্ক্রোল পরিমাপ করতে চাই তার সাথে এটি সারিবদ্ধ হয় যে এটি শুধুমাত্র একটি একক সময়কাল মান পরিমাপ করে।
• প্রো : এটির লক্ষ্য কীবোর্ড ইন্টারঅ্যাকশনের মতো ক্ষেত্রে গোলমাল কমানো, যেখানে keyup সাধারণত কিছুই করে না এবং যেখানে ব্যবহারকারী কী টিপতে পারে এবং দ্রুত বা ধীরে ধীরে ছেড়ে দিতে পারে।
• কন : এটি ব্যবহারকারীর সম্পূর্ণ অপেক্ষার সময় ক্যাপচার করে না। উদাহরণস্বরূপ, এটি একটি ড্র্যাগের শুরু বা শেষ ক্যাপচার করবে, তবে উভয়ই নয়।

স্ক্রোলিং এর জন্য (যাতে শুধুমাত্র একটি একক সম্পর্কিত ইভেন্ট আছে) আমরা স্ক্রল করার ফলে প্রথম ফ্রেম তৈরি করতে ব্রাউজারটির যে সময় লাগে তার লেটেন্সি সংজ্ঞায়িত করতে চাই। অর্থাৎ, লেটেন্সি হল প্রথম DOM ইভেন্টের ইভেন্ট timeStamp (যেমন touchmove , যদি একটি আঙুল ব্যবহার করা হয়) এর মধ্যে ডেল্টা যা একটি স্ক্রল ট্রিগার করার জন্য যথেষ্ট বড় এবং প্রথম পেইন্ট যা স্ক্রোলিং ঘটছে প্রতিফলিত করে।

প্রতি পৃষ্ঠায় সমস্ত মিথস্ক্রিয়া একত্রিত করুন

একবার আমরা একটি ইন্টারঅ্যাকশনের লেটেন্সি কী তা নির্ধারণ করেছি, আমাদের একটি পৃষ্ঠা লোডের জন্য একটি সমষ্টিগত মান গণনা করতে হবে, যাতে অনেক ব্যবহারকারীর ইন্টারঅ্যাকশন থাকতে পারে। একটি সমষ্টিগত মান আমাদের করতে সক্ষম করে:

• ব্যবসার মেট্রিক্সের সাথে ফর্ম পারস্পরিক সম্পর্ক।
• অন্যান্য কর্মক্ষমতা মেট্রিক্সের সাথে পারস্পরিক সম্পর্ক মূল্যায়ন করুন। আদর্শভাবে, আমাদের নতুন মেট্রিক যথেষ্ট স্বাধীন হবে যে এটি বিদ্যমান মেট্রিক্সের সাথে মান যোগ করে।
• সহজে হজম করা সহজ উপায়ে টুলিংয়ের মানগুলিকে সহজেই প্রকাশ করুন।

এই সমষ্টিটি সম্পাদন করার জন্য আমাদের দুটি প্রশ্নের সমাধান করতে হবে:

1. কোন সংখ্যা আমরা একত্রিত করার চেষ্টা করি?
2. কিভাবে আমরা যারা সংখ্যা একত্রিত না?

আমরা বেশ কয়েকটি বিকল্প অন্বেষণ এবং মূল্যায়ন করছি। আমরা এই সমষ্টিতে আপনার চিন্তা স্বাগত জানাই.

একটি বিকল্প হল একটি মিথস্ক্রিয়াটির বিলম্বের জন্য একটি বাজেট সংজ্ঞায়িত করা, যা প্রকারের (স্ক্রোল, কীবোর্ড, ট্যাপ বা টেনে) উপর নির্ভর করতে পারে। উদাহরণস্বরূপ, যদি ট্যাপের জন্য বাজেট 100 ms হয় এবং একটি ট্যাপের লেটেন্সি 150 ms হয় তাহলে সেই ইন্টারঅ্যাকশনের জন্য বাজেটের পরিমাণ 50 ms হবে। তারপরে আমরা পৃষ্ঠায় ব্যবহারকারীর ইন্টারঅ্যাকশনের জন্য বাজেটের চেয়ে বেশি বিলম্বের সর্বাধিক পরিমাণ গণনা করতে পারি।

আরেকটি বিকল্প হল পৃষ্ঠার সারাজীবনের মিথস্ক্রিয়াগুলির গড় বা মধ্যম লেটেন্সি গণনা করা। তাই যদি আমাদের 80 ms, 90 ms এবং 100 ms এর লেটেন্সি থাকে, তাহলে পৃষ্ঠাটির গড় বিলম্ব হবে 90 ms। ইন্টারঅ্যাকশনের ধরণের উপর নির্ভর করে বিভিন্ন প্রত্যাশার জন্য আমরা গড় বা মধ্যম "অধিক বাজেট" বিবেচনা করতে পারি।

ওয়েব পারফরম্যান্স API তে এটি কেমন দেখাচ্ছে?

ইভেন্ট টাইমিং থেকে কি অনুপস্থিত?

দুর্ভাগ্যবশত এই পোস্টে উপস্থাপিত সমস্ত ধারণা ইভেন্ট টাইমিং API ব্যবহার করে ক্যাপচার করা যাবে না। বিশেষ করে, API-এর সাথে প্রদত্ত ব্যবহারকারীর ইন্টারঅ্যাকশনের সাথে সম্পর্কিত ঘটনাগুলি জানার কোন সহজ উপায় নেই। এটি করার জন্য, আমরা API এ একটি interactionID যোগ করার প্রস্তাব করেছি ।

ইভেন্ট টাইমিং এপিআই-এর আরেকটি ঘাটতি হল যে স্ক্রোল ইন্টারঅ্যাকশন পরিমাপ করার কোন উপায় নেই, তাই আমরা এই পরিমাপগুলি সক্ষম করার জন্য কাজ করছি (ইভেন্ট টাইমিং বা একটি পৃথক API এর মাধ্যমে)।

আপনি এখন কি চেষ্টা করতে পারেন?

এই মুহূর্তে, ট্যাপ/ড্র্যাগ এবং কীবোর্ড ইন্টারঅ্যাকশনের জন্য সর্বাধিক লেটেন্সি গণনা করা এখনও সম্ভব। নিম্নলিখিত কোড স্নিপেট এই দুটি মেট্রিক্স তৈরি করবে।

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

প্রতিক্রিয়া

আমাদের ইমেল করে এই ধারণাগুলি সম্পর্কে আপনি কী মনে করেন তা আমাদের জানান: web-vitals-feedback@googlegroups.com!