এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

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

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

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

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

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

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

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

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

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

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

প্রথম ইনপুট বিলম্ব পরিমাপ করে যখন ইনপুট ঘটে তখন থেকে কখন ইনপুট পরিচালনা করা যায়

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

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

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

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

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

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

মাঠে টিটিআই পরিমাপের একটি নোট

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

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

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

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

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

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

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

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

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

একটি ঘটনার জীবনচক্রের পাঁচটি ধাপ

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

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

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

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

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

অ্যাসিঙ্ক্রোনাস কাজের উপর একটি নোট

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

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

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

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

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

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

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

প্রতিটি মিথস্ক্রিয়া প্রকারের জন্য DOM ইভেন্ট।
মিথষ্ক্রিয়া	শুরু শেষ	ডেস্কটপ ইভেন্ট	মোবাইল ইভেন্ট
কীবোর্ড	চাবি চাপা	`keydown`	`keydown`
	চাবি চাপা	`keypress`	`keypress`
	চাবি প্রকাশিত হয়েছে	`keyup`	`keyup`
আলতো চাপুন বা টেনে আনুন	স্টার্ট ট্যাপ করুন বা শুরু টেনে আনুন	`pointerdown`	`pointerdown`
	স্টার্ট ট্যাপ করুন বা শুরু টেনে আনুন	`mousedown`	`touchstart`
	উপরে আলতো চাপুন বা শেষ টেনে আনুন	`pointerup`	`pointerup`
		`mouseup`	`touchend`
		`click`	`mousedown`
			`mouseup`
			`click`
স্ক্রল করুন	N/A

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

শুরু এবং শেষ একটি নোট

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

কীবোর্ড

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

বিচ্ছিন্ন ইভেন্টের সময়কালের সাথে কীবোর্ড মিথস্ক্রিয়া

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

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

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

দ্রষ্টব্য: keypress ইভেন্টটি বাতিল করা হয়েছে, এবং এটি keydown ইভেন্টের মতো একই টাস্কে ফায়ার করা উচিত, তাই এর সময়কাল সর্বদা keydown সময়কালের সাথে ওভারল্যাপ হবে৷

বারবার কী প্রেস করার বিষয়ে একটি নোট

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

টোকা

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

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

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

আমরা কি কেবল pointerdown এবং pointerup আরও সংকীর্ণ করতে পারি?

একটি প্রাথমিক চিন্তা হল pointerdown এবং pointerup ইভেন্টগুলি ব্যবহার করা এবং ধরে নেওয়া যে তারা সমস্ত সময়কালকে কভার করে যা আমরা আগ্রহী। দুঃখের বিষয়, এটি এমন নয়, যেমনটি এই প্রান্তের ক্ষেত্রে দেখায়। এই সাইটটি মোবাইলে বা মোবাইল এমুলেশন দিয়ে খোলার চেষ্টা করুন এবং যেখানে "আমাকে ক্লিক করুন" বলে সেখানে আলতো চাপুন। এই সাইটটি ব্রাউজার ট্যাপ বিলম্ব ট্রিগার করে। এটি দেখা যায় যে pointerdown , pointerup এবং touchend দ্রুত প্রেরণ করা হয়, যেখানে mousedown , mouseup এবং প্রেরিত হওয়ার আগে বিলম্বের জন্য অপেক্ষা করুন click । এর মানে হল যে আমরা যদি শুধুমাত্র pointerdown এবং pointerup দিকে তাকাই তাহলে আমরা সিন্থেটিক ইভেন্টের সময়কাল মিস করব, যা ব্রাউজার ট্যাপ বিলম্বের কারণে বড় এবং অন্তর্ভুক্ত করা উচিত। তাই আমাদের pointerdown , pointerup পরিমাপ করা উচিত এবং সম্পূর্ণ মিথস্ক্রিয়া কভার করতে click ।

টেনে আনুন

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

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

স্ক্রোলিং

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

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

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

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

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

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

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

সর্বাধিক সময়কাল হাইলাইট সঙ্গে কীবোর্ড মিথস্ক্রিয়া

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

কীবোর্ড মিথস্ক্রিয়া যেখানে একই ফ্রেমে প্রেস এবং প্রকাশ ঘটে

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

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

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

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

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

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

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

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

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

একটি বিকল্প হল একটি মিথস্ক্রিয়াটির বিলম্বের জন্য একটি বাজেট সংজ্ঞায়িত করা, যা প্রকারের (স্ক্রোল, কীবোর্ড, ট্যাপ বা টেনে) উপর নির্ভর করতে পারে। উদাহরণস্বরূপ, যদি ট্যাপের জন্য বাজেট 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!

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

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

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

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

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

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

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

মাঠে টিটিআই পরিমাপের একটি নোট

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

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

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

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

একটি ঘটনার জীবনচক্রের পাঁচটি ধাপ

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

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

অ্যাসিঙ্ক্রোনাস কাজের উপর একটি নোট

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

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

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

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

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

প্রতিটি মিথস্ক্রিয়া প্রকারের জন্য ডিওএম ইভেন্টগুলি।
মিথষ্ক্রিয়া	শুরু শেষ	ডেস্কটপ ইভেন্টগুলি	মোবাইল ইভেন্ট
কীবোর্ড	কী চাপা	`keydown`	`keydown`
	কী চাপা	`keypress`	`keypress`
	কী প্রকাশিত	`keyup`	`keyup`
আলতো চাপুন বা টানুন	শুরু করুন বা টেনে আনুন শুরু করুন	`pointerdown`	`pointerdown`
	শুরু করুন বা টেনে আনুন শুরু করুন	`mousedown`	`touchstart`
	ট্যাপ আপ বা টানুন	`pointerup`	`pointerup`
		`mouseup`	`touchend`
		`click`	`mousedown`
			`mouseup`
			`click`
স্ক্রল করুন	N/A

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

শুরু এবং শেষে একটি নোট

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

কীবোর্ড

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

বিচ্ছিন্ন ইভেন্টের সময়কালের সাথে কীবোর্ড ইন্টারঅ্যাকশন

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

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

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

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

কীপ্রেসগুলি পুনরাবৃত্তি করার বিষয়ে একটি নোট

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

টোকা

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

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

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

আমরা কি কেবল pointerdown এবং pointerup আরও সংকীর্ণ করতে পারি?

একটি প্রাথমিক ধারণা হ'ল pointerdown এবং pointerup ইভেন্টগুলি ব্যবহার করা এবং ধরে নেওয়া যে তারা আমাদের আগ্রহী সমস্ত সময়কালকে কভার করে। দুঃখের বিষয়, এই এজ কেসটি যেমন দেখায় তেমন ক্ষেত্রে এটি হয় না। মোবাইলে এই সাইটটি খোলার চেষ্টা করুন, বা মোবাইল অনুকরণ দিয়ে এবং যেখানে এটি "আমাকে ক্লিক করুন" বলে ট্যাপ করার চেষ্টা করুন। এই সাইটটি ব্রাউজারের ট্যাপের বিলম্বকে ট্রিগার করে। এটি দেখা যায় যে pointerdown , pointerup এবং touchend দ্রুত প্রেরণ করা হয়, যেখানে mousedown , mouseup এবং প্রেরণের আগে বিলম্বের জন্য অপেক্ষা করুন click । এর অর্থ হ'ল আমরা যদি কেবল pointerdown এবং pointerup দিকে নজর রাখি তবে আমরা সিন্থেটিক ইভেন্টগুলি থেকে সময়কালটি মিস করব, যা ব্রাউজারের ট্যাপের বিলম্বের কারণে বড় এবং এটি অন্তর্ভুক্ত করা উচিত। সুতরাং আমাদের pointerdown , pointerup পরিমাপ করা উচিত এবং সম্পূর্ণ ইন্টারঅ্যাকশনটি কভার করতে click ।

টেনে আনুন

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

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

স্ক্রোলিং

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

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

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

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

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

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

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

সর্বোচ্চ সময়কাল হাইলাইট সহ কীবোর্ড ইন্টারঅ্যাকশন

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

কীবোর্ড ইন্টারঅ্যাকশন যেখানে একই ফ্রেমে প্রেস এবং রিলিজ ঘটে

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

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

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

প্রতি পৃষ্ঠায় সমস্ত ইন্টারঅ্যাকশন একত্রিত করুন

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

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

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

আমরা কোন নম্বরগুলি একত্রিত করার চেষ্টা করি?
আমরা কীভাবে এই সংখ্যাগুলিকে একত্রিত করব?

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

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

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

এটি ওয়েব পারফরম্যান্স এপিআইগুলিতে কেমন দেখাচ্ছে?

ইভেন্টের সময় থেকে কী অনুপস্থিত?

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

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

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

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

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.

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

ইমেল করে এই ধারণাগুলি সম্পর্কে আপনি কী ভাবেন তা আমাদের জানান: ওয়েব-ভিটালস-ফিডব্যাক@googlegroups.com!