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

ফিলিপ ওয়ালটন
ফিলিপ ওয়ালটন
এক্স

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

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

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

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

কিন্তু শুধুমাত্র একটি মেট্রিক উদ্দেশ্যমূলক মানদণ্ডের উপর ভিত্তি করে এবং পরিমাণগতভাবে পরিমাপ করা যেতে পারে, এর মানে এই পরিমাপগুলি দরকারী নয়।

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

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

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

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

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

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

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

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

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

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

পরীক্ষাগারে

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

মাঠে

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

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

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

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

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

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

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

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

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

  • ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) : পৃষ্ঠাটি লোড হওয়া শুরু হওয়ার সময় থেকে পৃষ্ঠার বিষয়বস্তুর কোনো অংশ স্ক্রিনে রেন্ডার করার সময় পরিমাপ করে। ( ল্যাব , ক্ষেত্র )
  • লার্জেস্ট কনটেন্টফুল পেইন্ট (LCP) : পৃষ্ঠাটি লোড হতে শুরু করার সময় থেকে স্ক্রীনে সবচেয়ে বড় টেক্সট ব্লক বা ইমেজ এলিমেন্ট রেন্ডার করা পর্যন্ত সময় পরিমাপ করে। ( ল্যাব , ক্ষেত্র )
  • প্রথম ইনপুট বিলম্ব (এফআইডি) : কোনো ব্যবহারকারী যখন প্রথমবার আপনার সাইটের সাথে ইন্টারঅ্যাক্ট করে (যখন তারা একটি লিঙ্কে ক্লিক করে, একটি বোতামে আলতো চাপ দেয় বা একটি কাস্টম, জাভাস্ক্রিপ্ট-চালিত নিয়ন্ত্রণ ব্যবহার করে) তখন থেকে ব্রাউজার আসলে সক্ষম হওয়ার সময় পর্যন্ত পরিমাপ করে যে মিথস্ক্রিয়া প্রতিক্রিয়া. ( ক্ষেত্র )
  • নেক্সট পেইন্টের সাথে ইন্টারঅ্যাকশন (আইএনপি) : পৃষ্ঠার সাথে করা প্রতিটি ট্যাপ, ক্লিক বা কীবোর্ড ইন্টারঅ্যাকশনের লেটেন্সি পরিমাপ করে এবং - ইন্টারঅ্যাকশনের সংখ্যার উপর ভিত্তি করে - পৃষ্ঠার সবচেয়ে খারাপ ইন্টারঅ্যাকশন লেটেন্সি (বা সর্বোচ্চের কাছাকাছি) নির্বাচন করে একটি পৃষ্ঠার সামগ্রিক প্রতিক্রিয়া বর্ণনা করার জন্য একটি একক, প্রতিনিধিত্বমূলক মান। ( ল্যাব , ক্ষেত্র )
  • টোটাল ব্লকিং টাইম (TBT) : FCP এবং TTI এর মধ্যে মোট সময় পরিমাপ করে যেখানে ইনপুট রেসপন্সিভনেস প্রতিরোধ করার জন্য প্রধান থ্রেডটি যথেষ্ট দীর্ঘ সময়ের জন্য ব্লক করা হয়েছিল। ( ল্যাব )
  • Cumulative Layout Shift (CLS) : পৃষ্ঠাটি যখন লোড হওয়া শুরু হয় এবং যখন এর জীবনচক্রের অবস্থা লুকানো হয় তখন এর মধ্যে ঘটে যাওয়া সমস্ত অপ্রত্যাশিত লেআউট শিফটের ক্রমবর্ধমান স্কোর পরিমাপ করে। ( ল্যাব , ক্ষেত্র )
  • টাইম টু ফার্স্ট বাইট (TTFB) : কোনো রিসোর্সের প্রথম বাইট দিয়ে ব্যবহারকারীর অনুরোধে সাড়া দিতে নেটওয়ার্কের যে সময় লাগে তা পরিমাপ করে। ( ল্যাব , ক্ষেত্র )

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

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

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

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

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

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

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