ব্যবহারকারী-কেন্দ্রিক কর্মক্ষমতা মেট্রিক্স

ফিলিপ ওয়ালটন

আমরা সবাই শুনেছি যে পারফরম্যান্স কতটা গুরুত্বপূর্ণ। কিন্তু যখন আমরা পারফরম্যান্স সম্পর্কে কথা বলি, এবং ওয়েবসাইটগুলিকে "দ্রুত" করার কথা বলি, তখন আমরা বিশেষভাবে কী বোঝাতে চাই?

সত্য যে কর্মক্ষমতা আপেক্ষিক:

  • একটি সাইট একজন ব্যবহারকারীর জন্য দ্রুত হতে পারে (একটি শক্তিশালী ডিভাইস সহ একটি দ্রুত নেটওয়ার্কে) কিন্তু অন্য ব্যবহারকারীর জন্য ধীর হতে পারে (নিম্ন-সম্পন্ন ডিভাইস সহ একটি ধীর নেটওয়ার্কে)।
  • দুটি সাইট ঠিক একই সময়ে লোডিং শেষ করতে পারে, তবুও একটি দ্রুত লোড হতে পারে বলে মনে হতে পারে (যদি এটি কিছু প্রদর্শনের জন্য শেষ পর্যন্ত অপেক্ষা না করে ধীরে ধীরে সামগ্রী লোড করে)।
  • একটি সাইট দ্রুত লোড হতে পারে বলে মনে হতে পারে কিন্তু তারপর ব্যবহারকারীর ইন্টারঅ্যাকশনে ধীরে ধীরে (বা একেবারেই না) সাড়া দেয়।

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

মেট্রিক্স সংজ্ঞায়িত করা

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

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

গত কয়েক বছর ধরে, ক্রোম টিমের সদস্যরা— W3C ওয়েব পারফরম্যান্স ওয়ার্কিং গ্রুপের সহযোগিতায়—একটি নতুন API এবং মেট্রিক্সের সেট মানক করার জন্য কাজ করছে যা ব্যবহারকারীরা কীভাবে একটি ওয়েব পৃষ্ঠার পারফরম্যান্স অনুভব করে তা আরও সঠিকভাবে পরিমাপ করে৷

মেট্রিকগুলি ব্যবহারকারীদের জন্য প্রাসঙ্গিক তা নিশ্চিত করতে সাহায্য করার জন্য, আমরা সেগুলিকে কয়েকটি মূল প্রশ্নে ফ্রেম করি:

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

কিভাবে মেট্রিক্স পরিমাপ করা হয়

কর্মক্ষমতা মেট্রিক্স সাধারণত দুটি উপায়ে পরিমাপ করা হয়:

  • ল্যাবে: একটি সামঞ্জস্যপূর্ণ, নিয়ন্ত্রিত পরিবেশে একটি পৃষ্ঠা লোড অনুকরণ করতে সরঞ্জাম ব্যবহার করে৷
  • ক্ষেত্রে : প্রকৃত ব্যবহারকারীরা প্রকৃতপক্ষে পৃষ্ঠাটি লোড করছে এবং ইন্টারঅ্যাক্ট করছে

এই বিকল্পগুলির কোনটিই অগত্যা অন্যটির চেয়ে ভাল বা খারাপ নয় - আসলে আপনি ভাল কার্যক্ষমতা নিশ্চিত করতে সাধারণত উভয়ই ব্যবহার করতে চান৷

পরীক্ষাগারে

নতুন বৈশিষ্ট্যগুলি বিকাশ করার সময় ল্যাবে পরীক্ষা কার্যকারিতা অপরিহার্য। বৈশিষ্ট্যগুলি উত্পাদনে প্রকাশ করার আগে, প্রকৃত ব্যবহারকারীদের উপর তাদের কার্যকারিতা বৈশিষ্ট্যগুলি পরিমাপ করা অসম্ভব, তাই বৈশিষ্ট্যটি প্রকাশের আগে ল্যাবে তাদের পরীক্ষা করা হল কর্মক্ষমতা রিগ্রেশন প্রতিরোধ করার সর্বোত্তম উপায়৷

মাঠে

অন্যদিকে, ল্যাবে পরীক্ষা করা কার্যসম্পাদনের জন্য একটি যুক্তিসঙ্গত প্রক্সি হলেও, প্রকৃত ব্যবহারকারীরা আপনার সাইটের অভিজ্ঞতার প্রতিফলন ঘটায় না।

ব্যবহারকারীর ডিভাইসের ক্ষমতা এবং তাদের নেটওয়ার্ক অবস্থার উপর ভিত্তি করে একটি সাইটের কর্মক্ষমতা নাটকীয়ভাবে পরিবর্তিত হতে পারে। একজন ব্যবহারকারী পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করছে কিনা (বা কিভাবে) তার উপর ভিত্তি করে এটি পরিবর্তিত হতে পারে।

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

আপনার সাইটটি আপনার ব্যবহারকারীদের জন্য কীভাবে পারফর্ম করে তা সত্যিকারভাবে জানার একমাত্র উপায় হল প্রকৃতপক্ষে এর কার্যকারিতা পরিমাপ করা যখন সেই ব্যবহারকারীরা লোড করে এবং এর সাথে ইন্টারঅ্যাক্ট করে। এই ধরনের পরিমাপকে সাধারণত রিয়েল ইউজার মনিটরিং (RUM) বলা হয়।

মেট্রিক্সের প্রকার

ব্যবহারকারীরা কীভাবে পারফরম্যান্স বুঝতে পারে তার সাথে প্রাসঙ্গিক আরও বেশ কয়েকটি ধরণের মেট্রিক্স রয়েছে।

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

এই সমস্ত ধরণের পারফরম্যান্স মেট্রিক্সের পরিপ্রেক্ষিতে, এটি আশা করা যায় যে কোনও একক মেট্রিক একটি পৃষ্ঠার সমস্ত কর্মক্ষমতা বৈশিষ্ট্য ক্যাপচার করার জন্য যথেষ্ট নয়।

পরিমাপ করার জন্য গুরুত্বপূর্ণ মেট্রিক

কিছু ক্ষেত্রে, অনুপস্থিত এলাকাগুলি কভার করার জন্য নতুন মেট্রিক চালু করা হবে, কিন্তু অন্যান্য ক্ষেত্রে সেরা মেট্রিকগুলি বিশেষভাবে আপনার সাইটের জন্য তৈরি করা হয়।

কাস্টম মেট্রিক্স

আগে কভার করা পারফরম্যান্স মেট্রিকগুলি ওয়েবে বেশিরভাগ সাইটের পারফরম্যান্স বৈশিষ্ট্য সম্পর্কে একটি সাধারণ বোঝার জন্য ভাল। তারা তাদের প্রতিযোগীদের সাথে তাদের পারফরম্যান্সের তুলনা করার জন্য সাইটের জন্য একটি সাধারণ মেট্রিক্স থাকার জন্যও ভাল।

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

এই ধরনের ক্ষেত্রে মোকাবেলা করার জন্য, ওয়েব পারফরম্যান্স ওয়ার্কিং গ্রুপটি নিম্ন-স্তরের APIগুলিকেও প্রমিত করেছে যা আপনার নিজস্ব কাস্টম মেট্রিক্স বাস্তবায়নের জন্য কার্যকর হতে পারে:

আপনার সাইটের নির্দিষ্ট কর্মক্ষমতা বৈশিষ্ট্য পরিমাপ করতে এই APIগুলি কীভাবে ব্যবহার করবেন তা জানতে কাস্টম মেট্রিক্সের নির্দেশিকা পড়ুন।