ওয়েব পারফরম্যান্স এপিআই-এর একটি গভীর বিশ্লেষণ, প্রচলিত টাইমিং পরিমাপ থেকে শুরু করে কোর ওয়েব ভাইটালের মতো আধুনিক ব্যবহারকারী-কেন্দ্রিক মেট্রিকস, এবং সামগ্রিক পারফরম্যান্সের জন্য তাদের কীভাবে সংযোগ স্থাপন করা যায়।
ঘড়ির বাইরে: ওয়েব পারফরম্যান্স এপিআই-কে বাস্তব ব্যবহারকারীর অভিজ্ঞতার সাথে সংযুক্ত করা
ডিজিটাল অর্থনীতিতে, গতি কেবল একটি বৈশিষ্ট্য নয়; এটি ব্যবহারকারীর অভিজ্ঞতার ভিত্তি। একটি ধীর ওয়েবসাইট ব্যবহারকারীদের হতাশ করতে পারে, বাউন্স রেট বাড়াতে পারে এবং রাজস্বে সরাসরি প্রভাব ফেলতে পারে। বছরের পর বছর ধরে, ডেভেলপাররা পারফরম্যান্স পরিমাপের জন্য window.onload-এর মতো টাইমিং মেট্রিকসের উপর নির্ভর করেছে। কিন্তু দ্রুত লোড সময় কি সত্যিই একজন সুখী ব্যবহারকারীর সমতুল্য? উত্তর প্রায়শই না।
একটি পৃষ্ঠা তার সমস্ত প্রযুক্তিগত সম্পদ এক সেকেন্ডের নিচে লোড করতে পারে, তবুও এটি কোনও বাস্তব ব্যক্তির কাছে ধীর এবং ব্যবহার অনুপযোগী মনে হতে পারে। এই সংযোগটি ওয়েব ডেভেলপমেন্টে একটি গুরুত্বপূর্ণ বিবর্তনকে তুলে ধরে: প্রযুক্তিগত টাইমিং পরিমাপ থেকে মানব অভিজ্ঞতা পরিমাপের দিকে স্থানান্তর। আধুনিক ওয়েব পারফরম্যান্স দুটি দৃষ্টিভঙ্গির একটি গল্প: ওয়েব পারফরম্যান্স এপিআই দ্বারা প্রদত্ত দানাদার, নিম্ন-স্তরের ডেটা এবং Google-এর কোর ওয়েব ভাইটালসের মতো উচ্চ-স্তরের, ব্যবহারকারী-কেন্দ্রিক মেট্রিকস।
এই ব্যাপক নির্দেশিকা সেই ব্যবধান পূরণ করবে। আমরা ওয়েব পারফরম্যান্স এপিআই-এর শক্তিশালী স্যুট অন্বেষণ করব যা আমাদের ডায়াগনস্টিক সরঞ্জাম হিসাবে কাজ করে। তারপর, আমরা আধুনিক ব্যবহারকারীর অভিজ্ঞতার মেট্রিকসগুলিতে প্রবেশ করব যা আমাদের বলে পারফরম্যান্স কেমন *অনুভূত* হয়। সবচেয়ে গুরুত্বপূর্ণভাবে, আমরা ডটগুলি সংযোগ করব, আপনাকে দেখাব কিভাবে আপনার বিশ্বব্যাপী দর্শকদের জন্য একটি খারাপ ব্যবহারকারীর অভিজ্ঞতার মূল কারণগুলি নির্ণয় এবং ঠিক করতে নিম্ন-স্তরের টাইমিং ডেটা ব্যবহার করতে হয়।
ভিত্তি: ওয়েব পারফরম্যান্স এপিআই বোঝা
ওয়েব পারফরম্যান্স এপিআই হল স্ট্যান্ডার্ড ব্রাউজার ইন্টারফেসের একটি সেট যা ডেভেলপারদের একটি ওয়েব পৃষ্ঠার নেভিগেশন এবং রেন্ডারিং সম্পর্কিত অত্যন্ত বিস্তারিত এবং নির্ভুল টাইমিং ডেটাতে অ্যাক্সেস দেয়। এগুলি পারফরম্যান্স পরিমাপের ভিত্তি, যা আমাদের সাধারণ স্টপওয়াচগুলির বাইরে যেতে এবং নেটওয়ার্ক অনুরোধ, পার্সিং এবং রেন্ডারিংয়ের জটিল নৃত্য বুঝতে দেয়।
নেভিগেশন টাইমিং এপিআই: পৃষ্ঠার যাত্রা
নেভিগেশন টাইমিং এপিআই মূল ডকুমেন্ট লোড হতে যে সময় লাগে তার একটি বিস্তারিত বিবরণ প্রদান করে। এটি ব্যবহারকারী নেভিগেশন শুরু করার মুহূর্ত (যেমন একটি লিঙ্কে ক্লিক করা) থেকে পৃষ্ঠাটি সম্পূর্ণরূপে লোড হওয়ার মুহূর্ত পর্যন্ত মাইলফলকগুলি ক্যাপচার করে। এটি পৃষ্ঠা লোড প্রক্রিয়ার দিকে আমাদের প্রথম এবং সবচেয়ে মৌলিক দৃষ্টিভঙ্গি।
আপনি একটি সাধারণ জাভাস্ক্রিপ্ট কলের মাধ্যমে এই ডেটা অ্যাক্সেস করতে পারেন:
const navigationEntry = performance.getEntriesByType('navigation')[0];
console.log(navigationEntry.toJSON());
এটি টাইমস্ট্যাম্পে ভরা একটি অবজেক্ট প্রদান করে। কিছু মূল বৈশিষ্ট্যগুলির মধ্যে রয়েছে:
- fetchStart: যখন ব্রাউজার ডকুমেন্ট ফেচ করা শুরু করে।
- responseStart: যখন ব্রাউজার সার্ভার থেকে প্রতিক্রিয়ার প্রথম বাইট পায়।
fetchStartএবংresponseStart-এর মধ্যেকার সময়কে প্রায়শই Time to First Byte (TTFB) বলা হয়। - domContentLoadedEventEnd: যখন প্রাথমিক HTML ডকুমেন্ট সম্পূর্ণরূপে লোড এবং পার্স করা হয়েছে, স্টাইলশীট, ছবি এবং সাবফ্রেমগুলি শেষ না হওয়া পর্যন্ত অপেক্ষা না করে।
- loadEventEnd: যখন পৃষ্ঠার সমস্ত সংস্থান (ছবি, CSS, ইত্যাদি সহ) সম্পূর্ণরূপে লোড হয়েছে।
অনেক দিন ধরে, loadEventEnd ছিল স্বর্ণমান। তবে, এর সীমাবদ্ধতা গুরুতর: এটি ব্যবহারকারী কখন অর্থপূর্ণ কন্টেন্ট *দেখতে* পায় বা পৃষ্ঠাটির সাথে *ইন্টারঅ্যাক্ট* করতে পারে কিনা তা কিছুই বলে না। এটি একটি প্রযুক্তিগত মাইলফলক, মানব নয়।
রিসোর্স টাইমিং এপিআই: উপাদানগুলির বিশদ বিবরণ
একটি ওয়েব পৃষ্ঠা খুব কমই একটি একক ফাইল। এটি HTML, CSS, JavaScript, ছবি, ফন্ট এবং API কলগুলির একটি সমাবেশ। রিসোর্স টাইমিং এপিআই আপনাকে এই পৃথক সংস্থানগুলির প্রতিটির জন্য নেটওয়ার্ক টাইমিং পরিদর্শন করতে দেয়।
এটি বাধাগুলি সনাক্ত করার জন্য অবিশ্বাস্যভাবে শক্তিশালী। একটি দূরবর্তী মহাদেশের একটি কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN) থেকে একটি বড়, অপ্টিমাইজ করা হিরো ছবি কি প্রাথমিক রেন্ডার ধীর করে দিচ্ছে? একটি তৃতীয় পক্ষের অ্যানালিটিক্স স্ক্রিপ্ট কি প্রধান থ্রেড ব্লক করছে? রিসোর্স টাইমিং আপনাকে এই প্রশ্নগুলির উত্তর দিতে সাহায্য করে।
আপনি এইভাবে সমস্ত সংস্থানগুলির একটি তালিকা পেতে পারেন:
const resourceEntries = performance.getEntriesByType('resource');
resourceEntries.forEach(resource => {
if (resource.duration > 200) { // 200ms-এর বেশি সময় নেওয়া সংস্থানগুলি খুঁজুন
console.log(`ধীর সংস্থান: ${resource.name}, সময়কাল: ${resource.duration}ms`);
}
});
মূল বৈশিষ্ট্যগুলির মধ্যে রয়েছে name (সংস্থানের URL), initiatorType (কী কারণে সংস্থানটি লোড হয়েছিল, যেমন 'img', 'script'), এবং duration (এটি ফেচ করতে নেওয়া মোট সময়)।
ব্যবহারকারীর টাইমিং এপিআই: আপনার অ্যাপ্লিকেশনের লজিক পরিমাপ করা
কখনও কখনও, পারফরম্যান্সের বাধা সম্পদ লোড করার ক্ষেত্রে নয়, বরং ক্লায়েন্ট-সাইড কোডের মধ্যে থাকে। কোনও API থেকে ডেটা প্রাপ্তির পরে আপনার সিঙ্গেল-পেজ অ্যাপ্লিকেশন (SPA) একটি জটিল উপাদান রেন্ডার করতে কত সময় নেয়? ব্যবহারকারীর টাইমিং এপিআই আপনাকে কাস্টম, অ্যাপ্লিকেশন-নির্দিষ্ট পরিমাপ তৈরি করতে দেয়।
এটি দুটি প্রধান পদ্ধতির সাথে কাজ করে:
- performance.mark(name): পারফরম্যান্স বাফারে একটি নামকরণ করা টাইমস্ট্যাম্প তৈরি করে।
- performance.measure(name, startMark, endMark): দুটি মার্কের মধ্যেকার সময়কাল গণনা করে এবং একটি নামকরণ করা পরিমাপ তৈরি করে।
উদাহরণ: একটি পণ্য তালিকার উপাদান রেন্ডার করার সময় পরিমাপ করা।
// যখন আপনি ডেটা ফেচ করা শুরু করেন
performance.mark('product-list-fetch-start');
fetch('/api/products')
.then(response => response.json())
.then(data => {
// ফেচ করার পরে, রেন্ডার করার আগে
performance.mark('product-list-render-start');
renderProductList(data);
// রেন্ডারিং সম্পন্ন হওয়ার ঠিক পরে
performance.mark('product-list-render-end');
// একটি পরিমাপ তৈরি করুন
performance.measure(
'Product List Render Time',
'product-list-render-start',
'product-list-render-end'
);
});
এটি আপনাকে আপনার অ্যাপ্লিকেশনের সেই অংশগুলি পরিমাপ করার জন্য সুনির্দিষ্ট নিয়ন্ত্রণ দেয় যা ব্যবহারকারীর কর্মপ্রবাহের জন্য সবচেয়ে গুরুত্বপূর্ণ।
PerformanceObserver: আধুনিক, দক্ষ পদ্ধতি
অবিরাম `performance.getEntriesByType()` পোলিং অদক্ষ। `PerformanceObserver` এপিআই পারফরম্যান্স এন্ট্রিগুলির জন্য শোনার একটি অনেক ভাল উপায় সরবরাহ করে। আপনি নির্দিষ্ট এন্ট্রি প্রকারগুলিতে সাবস্ক্রাইব করেন, এবং ব্রাউজার আপনার কলব্যাক ফাংশনটিকে অ্যাসিঙ্ক্রোনাসভাবে অবহিত করে কারণ সেগুলি রেকর্ড করা হয়। ওভারহেড যুক্ত না করে পারফরম্যান্স ডেটা সংগ্রহ করার জন্য এটি প্রস্তাবিত উপায়।
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(`এন্ট্রির ধরণ: ${entry.entryType}, নাম: ${entry.name}`);
}
});
observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });
এই অবজারভারটি কেবল উপরের প্রচলিত মেট্রিকসগুলিই নয়, আমরা পরবর্তীতে আলোচনা করব এমন আধুনিক, ব্যবহারকারী-কেন্দ্রিক মেট্রিকসগুলিও সংগ্রহ করার মূল চাবিকাঠি।
ব্যবহারকারী-কেন্দ্রিকতার দিকে স্থানান্তর: কোর ওয়েব ভাইটালস
একটি পৃষ্ঠা 2 সেকেন্ডে লোড হয়েছিল তা জানা দরকারী, তবে এটি গুরুত্বপূর্ণ প্রশ্নগুলির উত্তর দেয় না: ব্যবহারকারী কি সেই 2 সেকেন্ডে একটি খালি স্ক্রিনের দিকে তাকিয়ে ছিল? তারা কি পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করতে পারত, নাকি এটি জমে গিয়েছিল? পড়ার চেষ্টা করার সময় বিষয়বস্তু অপ্রত্যাশিতভাবে লাফিয়ে গিয়েছিল?
এটি মোকাবেলার জন্য, Google কোর ওয়েব ভাইটালস (CWV) চালু করেছে, যা তিনটি মূল মাত্রায় একটি পৃষ্ঠার বাস্তব-বিশ্বের ব্যবহারকারীর অভিজ্ঞতা পরিমাপ করার জন্য ডিজাইন করা মেট্রিকসের একটি সেট: লোডিং, ইন্টারঅ্যাকটিভিটি, এবং ভিজ্যুয়াল স্থিতিশীলতা।
Largest Contentful Paint (LCP): অনুভূত লোডিং পরিমাপ করা
LCP ভিউপোর্টের মধ্যে দৃশ্যমান বৃহত্তম ছবি বা টেক্সট ব্লকের রেন্ডার টাইম পরিমাপ করে। এটি যখন ব্যবহারকারী অনুভব করে যে পৃষ্ঠার প্রধান বিষয়বস্তু লোড হয়েছে তার একটি চমৎকার প্রক্সি। এটি সরাসরি ব্যবহারকারীর প্রশ্নটির উত্তর দেয়: "এই পৃষ্ঠাটি কি এখনও দরকারী?"
- ভালো: 2.5 সেকেন্ডের নিচে
- উন্নতির প্রয়োজন: 2.5s এবং 4.0s এর মধ্যে
- খারাপ: 4.0 সেকেন্ডের উপরে
loadEventEnd-এর বিপরীতে, LCP ব্যবহারকারী প্রথমে যা দেখে তার উপর মনোযোগ দেয়, যা অনুভূত লোড গতির একটি অনেক বেশি নির্ভুল প্রতিফলন করে।
Interaction to Next Paint (INP): প্রতিক্রিয়াশীলতা পরিমাপ করা
INP হল First Input Delay (FID)-এর উত্তরসূরি এবং মার্চ 2024-এ একটি অফিসিয়াল কোর ওয়েব ভাইটাল হয়ে উঠেছে। যেখানে FID শুধুমাত্র *প্রথম* মিথস্ক্রিয়ার বিলম্ব পরিমাপ করত, INP পৃষ্ঠার জীবনকাল জুড়ে *সমস্ত* ব্যবহারকারীর মিথস্ক্রিয়া (ক্লিক, ট্যাপ, কী প্রেস) এর লেটেন্সি পরিমাপ করে। এটি দীর্ঘতম মিথস্ক্রিয়া প্রতিবেদন করে, কার্যকরভাবে ব্যবহারকারী যে সবচেয়ে খারাপ প্রতিক্রিয়াশীলতা অনুভব করে তা সনাক্ত করে।
INP ব্যবহারকারীর ইনপুট থেকে পরবর্তী ফ্রেম আঁকা পর্যন্ত সম্পূর্ণ সময় পরিমাপ করে, ভিজ্যুয়াল প্রতিক্রিয়া প্রতিফলিত করে। এটি ব্যবহারকারীর প্রশ্নটির উত্তর দেয়: "যখন আমি এই বোতামে ক্লিক করি, তখন কি পৃষ্ঠাটি দ্রুত প্রতিক্রিয়া জানায়?"
- ভালো: 200 মিলিসেকেন্ডের নিচে
- উন্নতির প্রয়োজন: 200ms এবং 500ms এর মধ্যে
- খারাপ: 500ms এর উপরে
উচ্চ INP সাধারণত একটি ব্যস্ত প্রধান থ্রেডের কারণে ঘটে, যেখানে দীর্ঘ-চলমান জাভাস্ক্রিপ্ট কাজগুলি ব্রাউজারকে ব্যবহারকারীর ইনপুটে প্রতিক্রিয়া জানাতে বাধা দেয়।
Cumulative Layout Shift (CLS): ভিজ্যুয়াল স্থিতিশীলতা পরিমাপ করা
CLS একটি পৃষ্ঠার ভিজ্যুয়াল স্থিতিশীলতা পরিমাপ করে। এটি লোডিং প্রক্রিয়ার সময় স্ক্রিনে অপ্রত্যাশিতভাবে কতটুকু কন্টেন্ট সরে যায় তা পরিমাপ করে। একটি উচ্চ CLS স্কোর ব্যবহারকারীর হতাশার একটি সাধারণ কারণ, যেমন যখন আপনি একটি বোতামে ক্লিক করার চেষ্টা করেন, কিন্তু তার উপরে একটি বিজ্ঞাপন লোড হয়, বোতামটিকে নিচে ঠেলে দেয় এবং আপনাকে বিজ্ঞাপনটিতে ক্লিক করতে বাধ্য করে।
CLS ব্যবহারকারীর প্রশ্নটির উত্তর দেয়: "উপাদানগুলি সর্বত্র লাফানো ছাড়াই আমি কি এই পৃষ্ঠাটি ব্যবহার করতে পারি?"
- ভালো: 0.1 এর নিচে
- উন্নতির প্রয়োজন: 0.1 এবং 0.25 এর মধ্যে
- খারাপ: 0.25 এর উপরে
উচ্চ CLS-এর সাধারণ কারণগুলির মধ্যে রয়েছে মাত্রা ছাড়া ছবি বা iframe, দেরিতে লোড হওয়া ওয়েব ফন্ট, বা পৃষ্ঠার জন্য জায়গা রিজার্ভ না করে গতিশীলভাবে ইনজেক্ট করা কন্টেন্ট।
সেতুবন্ধন: খারাপ ব্যবহারকারীর অভিজ্ঞতা নির্ণয়ের জন্য এপিআই ব্যবহার
এটাই যেখানে সবকিছু একসাথে আসে। কোর ওয়েব ভাইটালস আমাদের বলে ব্যবহারকারীর অভিজ্ঞতা *কেমন* ছিল (যেমন, একটি ধীর LCP)। ওয়েব পারফরম্যান্স এপিআই আমাদের বলে কেন এটি ঘটেছে। তাদের একত্রিত করে, আমরা কেবল পারফরম্যান্স পর্যবেক্ষণ থেকে সক্রিয়ভাবে নির্ণয় এবং ঠিক করা পর্যন্ত রূপান্তরিত হই।
একটি ধীর LCP নির্ণয়
কল্পনা করুন আপনার রিয়েল ইউজার মনিটরিং (RUM) টুল একটি নির্দিষ্ট অঞ্চলের ব্যবহারকারীদের জন্য 4.5 সেকেন্ডের খারাপ LCP রিপোর্ট করছে। কিভাবে এটি ঠিক করবেন? আপনাকে LCP সময়কে তার উপাদান অংশে ভাগ করতে হবে।
- Time to First Byte (TTFB): সার্ভার কি প্রতিক্রিয়া জানাতে ধীর? Navigation Timing API ব্যবহার করুন।
responseStart - requestStartসময়কাল আপনাকে একটি সুনির্দিষ্ট TTFB দেয়। যদি এটি বেশি হয়, তবে সমস্যাটি আপনার ব্যাকএন্ড, সার্ভার কনফিগারেশন, বা ডেটাবেসে রয়েছে, ফ্রন্টএন্ডে নয়। - Resource Load Delay & Time: LCP উপাদানটি কি লোড হতে ধীর? প্রথমে, LCP উপাদানটি সনাক্ত করুন (যেমন, একটি হিরো ছবি)। আপনি উপাদানটি নিজেই পেতে `'largest-contentful-paint'`-এর জন্য একটি `PerformanceObserver` ব্যবহার করতে পারেন। তারপর, সেই উপাদানের URL-এর জন্য এন্ট্রি খুঁজে পেতে Resource Timing API ব্যবহার করুন। এর টাইমলাইন বিশ্লেষণ করুন:
connectStartথেকেconnectEndপর্যন্ত কি দীর্ঘ ছিল (ধীর নেটওয়ার্ক)?responseStartথেকেresponseEndকি দীর্ঘ ছিল (একটি বিশাল ফাইলের আকার)? এটি কি CSS বা JavaScript-এর মতো রেন্ডার-ব্লকিং সংস্থানগুলির দ্বারা ব্লক হওয়ার কারণেfetchStartবিলম্বিত হয়েছিল? - Element Render Delay: এটি সংস্থান লোড হওয়া শেষ হওয়ার পরে এটি পর্দায় আঁকা হওয়ার সময়। এটি প্রধান থ্রেড অন্যান্য কাজ সম্পাদন করার সাথে ব্যস্ত থাকার কারণে ঘটতে পারে, যেমন একটি বড় জাভাস্ক্রিপ্ট বান্ডিল কার্যকর করা।
Navigation এবং Resource Timing ব্যবহার করে, আপনি দ্রুত সনাক্ত করতে পারেন যে একটি ধীর LCP একটি ধীর সার্ভার, একটি রেন্ডার-ব্লকিং স্ক্রিপ্ট, বা একটি বিশাল, অপ্টিমাইজ না করা ছবির কারণে হয়েছে কিনা।
Poor INP তদন্ত করা
আপনার ব্যবহারকারীরা অভিযোগ করছেন যে "Add to Cart" বোতামে ক্লিক করা ধীর। আপনার INP মেট্রিক "Poor" রেঞ্জে রয়েছে। এটি প্রায় সবসময় একটি প্রধান থ্রেডের সমস্যা।
- Long Tasks সনাক্ত করা: Long Tasks API এখানে আপনার প্রাথমিক হাতিয়ার। এটি 50ms-এর বেশি সময় নেওয়া প্রধান থ্রেডের যেকোনো কাজ রিপোর্ট করে, কারণ 50ms-এর বেশি কিছু ব্যবহারকারীর কাছে লক্ষণীয় বিলম্বের ঝুঁকি তৈরি করে। `'longtask'` এন্ট্রিগুলির জন্য শোনার জন্য একটি `PerformanceObserver` সেট আপ করুন।
- ব্যবহারকারীর কর্মের সাথে সম্পর্কযুক্ত করা: একটি দীর্ঘ কাজ কেবল তখনই সমস্যা হয় যদি এটি ব্যবহারকারী ইন্টারঅ্যাক্ট করার চেষ্টা করার সময় ঘটে। আপনি একটি INP ইভেন্টের `startTime` (
PerformanceObserver`'event'` টাইপের উপর পর্যবেক্ষণ করা) এবং সেই সময়ে ঘটে যাওয়া যে কোনও দীর্ঘ কাজের টাইমিংয়ের সাথে সম্পর্কযুক্ত করতে পারেন। এটি আপনাকে ঠিক কোন জাভাস্ক্রিপ্ট ফাংশন ব্যবহারকারীর ইন্টারঅ্যাকশনকে ব্লক করেছে তা বলে দেয়। - নির্দিষ্ট হ্যান্ডলার পরিমাপ করা: আরও সূক্ষ্ম পরিমাপ পেতে User Timing API ব্যবহার করুন। `performance.mark()` এবং `performance.measure()` দিয়ে আপনার সমালোচনামূলক ইভেন্ট হ্যান্ডলারগুলি (যেমন "Add to Cart"-এর জন্য 'click' হ্যান্ডলার) মুড়ে দিন। এটি আপনাকে ঠিক বলবে আপনার নিজের কোডটি কার্যকর হতে কত সময় নিচ্ছে এবং এটি দীর্ঘ কাজের উৎস কিনা।
High CLS মোকাবেলা করা
ব্যবহারকারীরা রিপোর্ট করেছেন যে মোবাইল ডিভাইসগুলিতে একটি নিবন্ধ পড়ার সময় টেক্সট জাম্প করে। আপনার CLS স্কোর 0.3।
- Layout Shifts পর্যবেক্ষণ করা: `'layout-shift'` এন্ট্রিগুলির জন্য শোনার জন্য একটি `PerformanceObserver` ব্যবহার করুন। প্রতিটি এন্ট্রিতে একটি `value` (CLS স্কোরে এর অবদান) এবং `sources`-এর একটি তালিকা থাকবে, যা সরে যাওয়া DOM উপাদানগুলি। এটি আপনাকে বলে *কী* সরে গেছে।
- অপরাধী সংস্থান খুঁজে বের করা: পরবর্তী প্রশ্ন হল *কেন* এটি সরে গেছে। একটি সাধারণ কারণ হল দেরিতে লোড হওয়া একটি সংস্থান যা অন্যান্য কন্টেন্টকে নিচে ঠেলে দেয়। আপনি একটি `layout-shift` এন্ট্রির `startTime`-কে Resource Timing API থেকে এন্ট্রিগুলির `responseEnd` সময়ের সাথে সম্পর্কযুক্ত করতে পারেন। যদি একটি লেআউট শিফট একটি বিজ্ঞাপনের স্ক্রিপ্ট বা একটি বড় চিত্র লোড হওয়া শেষ হওয়ার ঠিক পরে ঘটে, তবে আপনি সম্ভবত আপনার অপরাধীকে খুঁজে পেয়েছেন।
- প্রোঅ্যাকটিভ সমাধান: ফিক্সের জন্য প্রায়শই ছবি এবং বিজ্ঞাপনের জন্য মাত্রা সরবরাহ করা (`
`) বা গতিশীল কন্টেন্ট লোড হওয়ার আগে পৃষ্ঠায় এটির জন্য জায়গা রিজার্ভ করা জড়িত। রিসোর্স টাইমিং আপনাকে সনাক্ত করতে সাহায্য করে কোন সংস্থানগুলির উপর আপনার প্রোঅ্যাকটিভ হওয়া দরকার।
ব্যবহারিক প্রয়োগ: একটি বিশ্বব্যাপী পর্যবেক্ষণ ব্যবস্থা তৈরি করা
এই এপিআইগুলি বোঝা এক জিনিস; আপনার বিশ্বব্যাপী ব্যবহারকারী বেসের অভিজ্ঞতা নিরীক্ষণ করার জন্য সেগুলিকে স্থাপন করা পরবর্তী ধাপ। এটি Real User Monitoring (RUM)-এর ডোমেন।
`PerformanceObserver` দিয়ে সবকিছু একসাথে করা
আপনি এই সমস্ত গুরুত্বপূর্ণ ডেটা সংগ্রহ করার জন্য একটি একক, শক্তিশালী স্ক্রিপ্ট তৈরি করতে পারেন। লক্ষ্য হল আপনি যে পারফরম্যান্স পরিমাপ করার চেষ্টা করছেন তা প্রভাবিত না করে মেট্রিকস এবং তাদের প্রসঙ্গ সংগ্রহ করা।
এখানে একটি শক্তিশালী অবজারভার সেটআপের একটি ধারণাগত স্নিপেট রয়েছে:
const collectedMetrics = {};
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === 'largest-contentful-paint') {
collectedMetrics.lcp = entry.startTime;
} else if (entry.entryType === 'layout-shift') {
collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value;
} else if (entry.entryType === 'event') {
// INP গণনার একটি সরলীকৃত দৃশ্য
const duration = entry.duration;
if (duration > (collectedMetrics.inp || 0)) {
collectedMetrics.inp = duration;
}
}
// ... অন্যান্য এন্ট্রি প্রকারের জন্য যেমন 'longtask'
}
});
observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });
নির্ভরযোগ্যভাবে ডেটা পাঠানো
আপনার ডেটা সংগ্রহ করার পরে, আপনাকে এটি বিশ্লেষণ এবং সংরক্ষণের জন্য একটি অ্যানালিটিক্স ব্যাকএন্ডে পাঠাতে হবে। পৃষ্ঠা আনলোড বিলম্বিত না করে বা দ্রুত ট্যাব বন্ধ করা ব্যবহারকারীদের ডেটা হারানো ছাড়া এটি করা অত্যন্ত গুরুত্বপূর্ণ।
`navigator.sendBeacon()` এপিআই এর জন্য এটি উপযুক্ত। এটি একটি সার্ভারে অল্প পরিমাণে ডেটা পাঠানোর একটি নির্ভরযোগ্য, অ্যাসিঙ্ক্রোনাস উপায় সরবরাহ করে, এমনকি যদি পৃষ্ঠাটি আনলোড করা হয়। এটি কোনও প্রতিক্রিয়া আশা করে না, এটিকে হালকা ওজনের এবং নন-ব্লকিং করে তোলে।
window.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
const payload = JSON.stringify(collectedMetrics);
navigator.sendBeacon('/api/performance-analytics', payload);
}
});
একটি বিশ্বব্যাপী দৃশ্যের গুরুত্ব
Lighthouse-এর মতো ল্যাব টেস্টিং টুলগুলি অমূল্য, তবে তারা নিয়ন্ত্রিত পরিবেশে চলে। এই এপিআইগুলি থেকে সংগৃহীত RUM ডেটা আপনাকে বিভিন্ন দেশ, নেটওয়ার্ক শর্ত এবং ডিভাইসে আপনার ব্যবহারকারীরা কী অনুভব করে তার গ্রাউন্ড ট্রুথ বলে দেয়।
আপনার ডেটা বিশ্লেষণ করার সময়, সর্বদা এটি সেগমেন্ট করুন। আপনি আবিষ্কার করতে পারেন যে:
- উত্তর আমেরিকার ব্যবহারকারীদের জন্য আপনার LCP চমৎকার, তবে অস্ট্রেলিয়ার ব্যবহারকারীদের জন্য খারাপ কারণ আপনার প্রধান চিত্র সার্ভার মার্কিন যুক্তরাষ্ট্রে অবস্থিত।
- আপনার INP মাঝারি-রেঞ্জের অ্যান্ড্রয়েড ডিভাইসগুলিতে বেশি, যা উদীয়মান বাজারগুলিতে জনপ্রিয়, কারণ আপনার জাভাস্ক্রিপ্ট তাদের জন্য খুব সিপিইউ-ইনটেনসিভ।
- আপনার CLS শুধুমাত্র নির্দিষ্ট স্ক্রিন আকারের সমস্যাযুক্ত যেখানে একটি CSS মিডিয়া ক্যোয়ারী একটি বিজ্ঞাপনকে ভুলভাবে রিসাইজ করার কারণ হয়।
এই স্তরের সেগমেন্টেড অন্তর্দৃষ্টি আপনাকে সেই অপ্টিমাইজেশানগুলিকে অগ্রাধিকার দিতে দেয় যা আপনার প্রকৃত ব্যবহারকারী বেসের উপর সবচেয়ে বেশি প্রভাব ফেলবে, তারা যেখানেই থাকুক না কেন।
উপসংহার: পরিমাপ থেকে আয়ত্ত পর্যন্ত
ওয়েব পারফরম্যান্সের বিশ্ব পরিপক্ক হয়েছে। আমরা সাধারণ প্রযুক্তিগত টাইমিং থেকে ব্যবহারকারীর অনুভূত অভিজ্ঞতার একটি পরিশীলিত উপলব্ধির দিকে চলেছি। যাত্রায় তিনটি মূল পদক্ষেপ জড়িত:
- অভিজ্ঞতা পরিমাপ করুন: কোর ওয়েব ভাইটালস (LCP, INP, CLS) সংগ্রহ করতে `PerformanceObserver` ব্যবহার করুন। এটি আপনাকে বলে *কী* ঘটছে এবং ব্যবহারকারীর কাছে *কেমন* অনুভূত হয়।
- কারণ নির্ণয় করুন: গভীর খননের জন্য মৌলিক টাইমিং এপিআই (Navigation, Resource, User, Long Tasks) ব্যবহার করুন। এটি আপনাকে বলে *কেন* অভিজ্ঞতা খারাপ।
- সুনির্দিষ্টভাবে কাজ করুন: নির্দিষ্ট ব্যবহারকারী বিভাগগুলির জন্য সমস্যার মূল কারণ চিহ্নিত করে তথ্যপূর্ণ, লক্ষ্যযুক্ত অপ্টিমাইজেশানগুলি তৈরি করতে সম্মিলিত ডেটা ব্যবহার করুন।
উচ্চ-স্তরের ব্যবহারকারীর মেট্রিকস এবং নিম্ন-স্তরের ডায়াগনস্টিক এপিআই উভয়কেই আয়ত্ত করে, আপনি একটি সামগ্রিক পারফরম্যান্স কৌশল তৈরি করতে পারেন। আপনি অনুমান করা বন্ধ করে দেন এবং এমন একটি ওয়েব অভিজ্ঞতা তৈরি করেন যা কেবল প্রযুক্তিগতভাবে দ্রুত নয়, বরং একটি যা প্রতিটি ব্যবহারকারীর কাছে, প্রতিটি ডিভাইসে, বিশ্বের সব জায়গায় দ্রুত, প্রতিক্রিয়াশীল এবং আনন্দদায়ক মনে হয়।