সফট নেভিগেশন পরিমাপ করা

Barry Pollard

Michal Mocny

প্রকাশিত: ১ ফেব্রুয়ারি, ২০২৩, সর্বশেষ হালনাগাদ: ২৪ জুন, ২০২৬

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

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

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

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

ডেভেলপারদের মতামতের ভিত্তিতে আমরা প্রস্তাবটিতে বেশ কিছু উন্নতি করেছি এবং ক্রোম ১৫১ থেকে এই সমস্যাটি সমাধানে সহায়তার জন্য দুটি নতুন পারফরম্যান্স এপিআই চালু করার লক্ষ্য নিয়েছি।

সফট নেভিগেশন বলতে কী বোঝায়?

আমরা সফট নেভিগেশনের নিম্নলিখিত সংজ্ঞাটি প্রদান করেছি:

• ব্যবহারকারীর কোনো কার্যকলাপের মাধ্যমে নেভিগেশন শুরু হয়।
• এই নেভিগেশনের ফলে ব্যবহারকারীর কাছে URL-এ একটি দৃশ্যমান পরিবর্তন ঘটে।
• এই মিথস্ক্রিয়ার ফলে একটি দৃশ্যমান রঙের সৃষ্টি হয়।

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

সফট নেভিগেশনের জন্য ডেভটুলস সমর্থন

আমরা ট্রেস ভিউ-এর ডেভটুলস পারফরম্যান্স প্যানেলে সফট নেভিগেশনের জন্য সমর্থন যোগ করেছি:

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

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

ওয়েব ডেভেলপারদের জন্য ক্রোম কীভাবে সফট নেভিগেশন বাস্তবায়ন করে?

সফট নেভিগেশন ফিচারটি চালু করা হলে (এ বিষয়ে পরবর্তী অংশে আরও আলোচনা করা হবে), ক্রোম কিছু পারফরম্যান্স মেট্রিক্স রিপোর্ট করার পদ্ধতি পরিবর্তন করবে:

• প্রতিটি সফট নেভিগেশন শনাক্ত হওয়ার পর একটি soft-navigation PerformanceTiming ইভেন্ট নির্গত হবে।
• এই soft-navigation এন্ট্রিতে একটি navigationId , name অ্যাট্রিবিউটে নতুন URL এবং সূচনাকারী ইন্টারঅ্যাকশনের একটি interactionId অন্তর্ভুক্ত থাকবে।
• যেসব ইন্টারঅ্যাকশনের ফলে কন্টেন্টফুল পেইন্ট হয়, সেগুলোর পরে এক বা একাধিক interaction-contentful-paint এন্ট্রি নির্গত হবে। এতে একটি largestContentfulPaint এন্ট্রি থাকবে যা সফট নেভিগেশনের জন্য লার্জেস্ট কন্টেন্টফুল পেইন্ট (LCP) পরিমাপ করতে ব্যবহার করা যেতে পারে।
• প্রতিটি পারফরম্যান্স টাইমিং-এর ( first-paint , first-contentful-paint , largest-contentful-paint , interaction-contentful-paint , first-input-delay , event , এবং layout-shift ) সাথে navigationId অ্যাট্রিবিউটটি যুক্ত করা হয়। এটি সেই নেভিগেশন এন্ট্রির সাথে সঙ্গতিপূর্ণ, যার অধীনে ইভেন্টটি নির্গত হয়েছিল। উল্লেখ্য যে, যখন এই এন্ট্রিগুলো সফট নেভিগেশন জুড়ে বিস্তৃত থাকে, তখন এন্ট্রিটি কখন নির্গত হয়েছিল তার উপর নির্ভর করে সেগুলোতে পূর্ববর্তী বা পরবর্তী navigationId থাকতে পারে। এই বিষয়ে আরও বিস্তারিত জানতে "Report the metrics against the appropriate URL" বিভাগটি দেখুন।
• soft-navigation একটি getLargestInteractionContentfulPaint() ফাংশন অন্তর্ভুক্ত থাকবে, যা সেই ন্যাভিগেশনের জন্য বৃহত্তম interaction-contentful-paint এন্ট্রিটি পুনরুদ্ধার করবে। এটিকে সেই ন্যাভিগেশনের প্রাথমিক LCP হিসেবে ব্যবহার করা যাবে, এবং সেই ইন্টার‍্যাকশনের জন্য আরও interaction-contentful-paint এন্ট্রি পাওয়া গেলে LCP-টি আপডেট করা যাবে। উল্লেখ্য যে, এটি পূর্ববর্তী অরিজিন ট্রায়ালগুলিতে উপলব্ধ largestInteractionContentfulPaint অ্যাট্রিবিউটটিকে প্রতিস্থাপন করে।
• সম্ভাব্যভাবে কিছু interaction-contentful-paint এন্ট্রি সফট নেভিগেশন সংঘটিত হওয়ার আগেই ঘটে থাকতে পারে (যদি ইউআরএল আপডেটটি সেই পেইন্টগুলোর পরে না ঘটে)। এই ক্ষেত্রে, একটি সফট নেভিগেশন চূড়ান্ত হওয়ার পরে getLargestInteractionContentfulPaint() ফাংশনটি পুরোনো এন্ট্রিগুলো বাফার করা এবং পুনরায় খতিয়ে দেখার প্রয়োজনীয়তা এড়িয়ে যায়। উল্লেখ্য যে, getLargestInteractionContentfulPaint() দ্বারা ফেরত আসা এন্ট্রিটি হলো সেই মুহূর্তে সংঘটিত হওয়া বৃহত্তম interaction-contentful-paint এন্ট্রির একটি হুবহু অনুলিপি, তাই সেই এন্ট্রিটি পূর্ববর্তী navigationId ব্যবহার করে থাকতে পারে কারণ পেইন্টটি তখনই ঘটেছিল, কিন্তু এই পেইন্টগুলোকে নতুন navigationId সাপেক্ষে পরিমাপ করা উচিত।
• soft-navigation এন্ট্রিতে সেই ন্যাভিগেশনের FCP হিসেবে paintTime এবং presentationTime ও অন্তর্ভুক্ত থাকবে।
• মনে রাখবেন যে পরবর্তী ইন্টারঅ্যাকশনের পরেও interaction-contentful-paint এন্ট্রিগুলো নির্গত হবে, কিন্তু এগুলোকে বাদ দেওয়ার জন্য একটি URL-এর LCP-কে শুধুমাত্র সেইসব interaction-contentful-paint এন্ট্রির মধ্যে সীমাবদ্ধ রাখা উচিত যা সফট নেভিগেশনের interactionId সাথে মেলে এবং সেইসাথে কেবল তার ভেতরের largestContentfulPaint প্রপার্টিগুলোর মধ্যেই সীমাবদ্ধ রাখা উচিত।

এই পরিবর্তনগুলোর ফলে প্রতিটি পেজ নেভিগেশনের ভিত্তিতে কোর ওয়েব ভাইটালস—এবং এর সাথে সম্পর্কিত কিছু ডায়াগনস্টিক মেট্রিক—পরিমাপ করা যাবে, যদিও এক্ষেত্রে কিছু সূক্ষ্ম বিষয় বিবেচনা করার প্রয়োজন রয়েছে।

ক্রোমে সফট নেভিগেশন চালু করার ফলাফল কী?

এই ফিচারটি চালু করার পর সাইটের মালিকদের নিম্নলিখিত পরিবর্তনগুলো বিবেচনা করতে হবে:

• soft-navigation এন্ট্রিগুলো পর্যবেক্ষণ করার মাধ্যমে পারফরম্যান্স এন্ট্রিগুলোকে প্রতিটি 'নেভিগেশন'-এ 'বিভক্ত' করা যায়।
• CLS এবং INP মেট্রিকগুলোকে সম্পূর্ণ পেজ লাইফসাইকেল জুড়ে পরিমাপ করার পরিবর্তে, আপনার ইচ্ছামত ভাগ করা ইতিমধ্যেই সম্ভব, কিন্তু সফট নেভিগেশন ফিচারটি ব্যবহৃত অন্তর্নিহিত প্রযুক্তি নির্বিশেষে, কখন এটি ঘটে তার একটি প্রমিত পরিমাপ প্রদান করে।
• largest-contentful-paint এন্ট্রিটি একটি ইন্টারঅ্যাকশনের মাধ্যমে চূড়ান্ত করা হয় (যা একটি সফট নেভিগেশন শুরু করার জন্য প্রয়োজনীয়), তাই এটি শুধুমাত্র প্রাথমিক "হার্ড" নেভিগেশনের LCP পরিমাপের জন্য ব্যবহার করা যেতে পারে। এর মানে হলো, সফট নেভিগেশন পরিমাপ করার সময় এটি পরিবর্তিত হবে না, ফলে প্রাথমিক, হার্ড নেভিগেশন পেজ লোডের LCP আগের মতোই পরিমাপ করা যাবে।
• ইন্টারঅ্যাকশন থেকে নির্গত নতুন interaction-contentful-paint এন্ট্রিটির ভেতরের ' largestContentfulPaint ' প্রপার্টিটি দেখে সফট নেভিগেশনের জন্য LCP পরিমাপ করা যেতে পারে, কিন্তু এই এন্ট্রিটি কীভাবে ব্যবহার করা হবে সে সম্পর্কে কিছু বিবেচ্য বিষয় রয়েছে যা আমরা এই প্রবন্ধে আলোচনা করব।
• মনে রাখবেন যে, সব ব্যবহারকারী এই সফট নেভিগেশন ফিচারটি সমর্থন করবেন না, বিশেষ করে ক্রোমের পুরোনো সংস্করণ এবং অন্যান্য ব্রাউজার ব্যবহারকারীদের ক্ষেত্রে। এ বিষয়ে সচেতন থাকবেন যে, কিছু ব্যবহারকারী কোর ওয়েব ভাইটালস মেট্রিক্স রিপোর্ট করলেও সফট-নেভিগেশন-ভিত্তিক মেট্রিক্স রিপোর্ট নাও করতে পারেন।

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

সফট নেভিগেশনের মেট্রিকগুলো কীভাবে পরিমাপ করতে হয় সে সম্পর্কে আরও তথ্যের জন্য, “প্রতি সফট নেভিগেশনের জন্য কোর ওয়েব ভাইটালস পরিমাপ” বিভাগটি দেখুন।

ক্রোমে সফট নেভিগেশন কীভাবে চালু করব?

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

ডেভেলপারদের জন্য, chrome://flags/#soft-navigation-heuristics -এ ফ্ল্যাগটি চালু করে এটি সক্রিয় করা যেতে পারে। বিকল্পভাবে, Chrome চালু করার সময় --enable-features=SoftNavigationHeuristics কমান্ড লাইন আর্গুমেন্ট ব্যবহার করেও এটি সক্রিয় করা যায়। chrome://flags/#enable-experimental-web-platform-features ফ্ল্যাগটি সক্রিয় করলেও সফট নেভিগেশন চালু হয়ে যায়।

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

সফট নেভিগেশন এপিআই সমর্থনের বৈশিষ্ট্য সনাক্তকরণ

এপিআইটি সমর্থিত কিনা তা পরীক্ষা করতে আপনি নিম্নলিখিত কোডটি ব্যবহার করতে পারেন:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

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

যেহেতু সফট নেভিগেশন এখনও ডিফল্টরূপে সমর্থিত নয় এবং এই রূপান্তর পর্যায়ে রয়েছে, তাই এই ক্ষেত্রে নিম্নলিখিত বিকল্পটি ব্যবহার করা যেতে পারে:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

আমি কীভাবে সফট নেভিগেশন পরিমাপ করতে পারি?

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

সফট নেভিগেশন রিপোর্ট করুন

আপনি সফট নেভিগেশন পর্যবেক্ষণ করতে একটি PerformanceObserver ব্যবহার করতে পারেন। নিচে একটি উদাহরণ কোড স্নিপেট দেওয়া হলো যা buffered অপশন ব্যবহার করে এই পৃষ্ঠার পূর্ববর্তী সফট নেভিগেশনগুলো সহ সফট নেভিগেশন এন্ট্রিগুলো কনসোলে লগ করে:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

এটি পূর্ববর্তী নেভিগেশনের জন্য পৃষ্ঠার পূর্ণাঙ্গ মেট্রিক্স চূড়ান্ত করতে ব্যবহার করা যেতে পারে।

উপযুক্ত URL-এর সাপেক্ষে মেট্রিকগুলো রিপোর্ট করুন।

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

উপযুক্ত soft-navigation এন্ট্রির ' name ' অ্যাট্রিবিউটে মেট্রিক্স রিপোর্ট করার জন্য নতুন URL-টি থাকবে, এবং ' navigationId হবে এই ন্যাভিগেশনটির অনন্য রেফারেন্স (যেহেতু একটি সিঙ্গেল পেজ অ্যাপ্লিকেশনের জীবনকালে একই URL একাধিকবার ভিজিট করা হতে পারে)।

এটি প্রতিটি soft-navigation এন্ট্রি হিসেবে সেট করা উচিত এবং পরবর্তী soft-navigation এন্ট্রি না পাওয়া পর্যন্ত মেট্রিক্স রিপোর্ট করার জন্য ব্যবহার করা উচিত।

interaction-contentful-paint এর জন্য সঠিক URL রিপোর্ট করুন।

interaction-contentful-paint এন্ট্রিগুলো থেকে LCP গণনা করার ক্ষেত্রে অতিরিক্ত বিবেচনার প্রয়োজন, কারণ সব interaction-contentful-paint এন্ট্রিকে navigationId ব্যবহার করে ম্যাপ করা এবং সেই URL-এর জন্য LCP হিসেবে রিপোর্ট করা উচিত নয়:

• প্রথম সমস্যাটি হলো, যদি URL আপডেটের আগে পেইন্ট ঘটে, তাহলে সফট নেভিগেশন শুরু হওয়ার আগেই interaction-contentful-paint এন্ট্রি নির্গত হতে পারে। এই ক্ষেত্রে navigationId টি পুরোনো URL-এর জন্য হবে। যদি প্রথমে URL আপডেট করা হয়, তাহলে পেইন্টটি সফট নেভিগেশন সম্পন্ন করবে এবং সেক্ষেত্রে soft-navigation এন্ট্রিটি প্রথমে নির্গত হবে, এবং interaction-contentful-paint নতুন URL-টি থাকবে।
• দ্বিতীয় সমস্যাটি হলো যে, নতুন ইন্টারঅ্যাকশনগুলোর জন্যও interaction-contentful-paint এন্ট্রিগুলো নির্গত হতে থাকবে, কারণ এই পারফরম্যান্স মেট্রিকের পরিধি সফট নেভিগেশনের জন্য শুধু LCP-এর বাইরেও বিস্তৃত। আমরা কেবল LCP-এর সফট নেভিগেশন লোডের জন্য পেইন্টগুলো বিবেচনা করতে চাই, পরবর্তী ইন্টারঅ্যাকশনগুলোর জন্য নয়।

অতএব, সঠিক URL পাওয়ার জন্য interaction-contentful-paint এন্ট্রিগুলোকে soft-navigation-entries সাথে ম্যাপ করতে navigationId পরিবর্তে interactionId ব্যবহার করা উচিত। এটি পুরোনো navigationId যুক্ত যেকোনো এন্ট্রিকে সামলানোর পাশাপাশি LCP-এর জন্য বিবেচনা করা উচিত নয় এমন interaction-contentful-paint এন্ট্রিগুলোকেও ফিল্টার করে বাদ দেবে।

এছাড়াও, সফট-ন্যাভিগেশন soft-navigation entries নির্গত হওয়ার আগে ঘটা interaction-contentful-paint এন্ট্রিগুলোকে আরও সহজে পরিচালনা করার জন্য, আপনার soft-navigation এন্ট্রিগুলোর getLargestInteractionContentfulPaint() ফাংশনটিও প্রসেস করার কথা বিবেচনা করা উচিত।

সফট নেভিগেশনের startTime পাওয়া

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

উপযুক্ত soft-navigation এন্ট্রিতে ম্যাপ করে এবং এর startTime ব্যবহার করে একইভাবে ন্যাভিগেশন শুরুর সময় পাওয়া যেতে পারে।

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

সফট নেভিগেশন অনুযায়ী কোর ওয়েব ভাইটালস পরিমাপ করুন

কোর ওয়েব ভাইটালস পরিমাপ করতে, soft-navigation এন্ট্রিগুলো শুনুন এবং এগুলো পাওয়ার পর মেট্রিকগুলো রিসেট করুন। presentationTime এর উপর ভিত্তি করে এফসিপি (FCP) নির্গত করা যেতে পারে এবং getLargestInteractionContentfulPaint() এন্ট্রির মাধ্যমে এলসিপি (LCP) ইনিশিয়ালাইজ করা যেতে পারে। আইএনপি (INP) এবং সিএলএস (CLS)-কে ০ (শূন্য)-তে ইনিশিয়ালাইজ করতে হবে, যেমনটা একটি পেজ লোডের ক্ষেত্রে করা হয়।

এরপর LCP, INP, এবং CLS যথারীতি পরিমাপ ও পর্যবেক্ষণ করা যেতে পারে (তবে interactionId মিলে গেলে LCP-এর জন্য interaction-contentful-paint ব্যবহার করতে হবে)। পূর্বে আলোচিত পদ্ধতি অনুযায়ী, একটি URL-এর এন্ট্রিগুলোর নামকরণ করতে interactionId ব্যবহার করা যেতে পারে।

সময়গুলো এখনও মূল 'হার্ড' নেভিগেশন শুরুর সময়ের সাপেক্ষে ফেরত দেওয়া হবে। সুতরাং, উদাহরণস্বরূপ, একটি সফট নেভিগেশনের জন্য LCP গণনা করতে, আপনাকে interaction-contentful-paint সময়টি নিতে হবে এবং পূর্বে বিস্তারিতভাবে বর্ণিত উপযুক্ত সফট নেভিগেশন শুরুর সময়টি বিয়োগ করতে হবে, যাতে সফট নেভিগেশনের সাপেক্ষে একটি সময় পাওয়া যায়।

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

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

যেসব কন্টেন্ট নেভিগেশনের মধ্যে অপরিবর্তিত থাকে, সেগুলোর সাথে কী ধরনের আচরণ করা উচিত?

সফট নেভিগেশনের জন্য LCP (যা interaction-contentful-paint থেকে গণনা করা হয়) শুধুমাত্র নতুন পেইন্টগুলো পরিমাপ করবে, এবং কেবল সেই পেইন্টগুলোই পরিমাপ করবে যা নেভিগেশনটির কারণ হওয়া ইন্টারঅ্যাকশনের সাথে সম্পর্কিত। এর ফলে একটি ভিন্ন LCP পাওয়া যেতে পারে, উদাহরণস্বরূপ, সেই সফট নেভিগেশনটির একটি কোল্ড লোড থেকে অন্য একটি সফট লোডের ক্ষেত্রে।

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

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

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

TTFB কীভাবে পরিমাপ করা হয়?

একটি প্রচলিত পেজ লোডের ক্ষেত্রে টাইম টু ফার্স্ট বাইট (TTFB) হলো সেই সময়, যখন মূল অনুরোধের প্রথম বাইটগুলো ফেরত আসে।

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

একটি সহজতর পদ্ধতি হলো সফট নেভিগেশনের জন্য TTFB ০ রিপোর্ট করা—ঠিক যেভাবে আমরা ব্যাক/ফরোয়ার্ড ক্যাশ রিস্টোরের জন্য সুপারিশ করি। web-vitals লাইব্রেরি সফট নেভিগেশনের জন্য এই পদ্ধতিটিই ব্যবহার করে এবং এই মুহূর্তে এই মেট্রিকের জন্য আমরাও এটিই সুপারিশ করি।

আপনার কি উভয় পদ্ধতিতেই কোর ওয়েব ভাইটালস পরিমাপ করা উচিত?

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

LCP-এর ক্ষেত্রে, এর অর্থ হলো বর্তমান পদ্ধতির জন্য শুধু largest-contentful-paint এন্ট্রিগুলো বিবেচনা করা, এবং নতুন পদ্ধতির জন্য largest-contentful-paint ও interaction-contentful-paint উভয় এন্ট্রিই বিবেচনা করা।

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

এরপর বিশ্লেষণের জন্য মেট্রিকগুলোকে দুইবার বীকন করে সংরক্ষণ করতে হবে।

সফট নেভিগেশনের জন্য কোর ওয়েব ভাইটালস পরিমাপ করতে web-vitals লাইব্রেরি ব্যবহার করুন।

সমস্ত সূক্ষ্ম বিষয়গুলো বিবেচনা করার সবচেয়ে সহজ উপায় হলো web-vitals জাভাস্ক্রিপ্ট লাইব্রেরিটি ব্যবহার করা, যেটির একটি আলাদা soft-navs branch সফট নেভিগেশনের জন্য পরীক্ষামূলক সাপোর্ট রয়েছে (যা npm এবং unpkg- তেও পাওয়া যায়)। এটি নিম্নলিখিত উপায়ে পরিমাপ করা যেতে পারে (প্রয়োজন অনুযায়ী doTraditionalProcessing এবং doSoftNavProcessing প্রতিস্থাপন করে):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

web-vitals লাইব্রেরিটি আরও নিশ্চিত করে যে , পূর্বে উল্লিখিত হিসাবে , মেট্রিকগুলি সঠিক URL-এর বিপরীতে রিপোর্ট করা হচ্ছে, কারণ এটি কলব্যাকে প্রদত্ত এন্ট্রিগুলিতে navigationId এবং navigationURL উভয়ই অন্তর্ভুক্ত করে।

web-vitals লাইব্রেরি সফট নেভিগেশনের জন্য নিম্নলিখিত মেট্রিকগুলো রিপোর্ট করে:

এই পরিবর্তনগুলো কি কোর ওয়েব ভাইটালস পরিমাপের অংশ হয়ে উঠবে?

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

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

CrUX-এ সফট নেভিগেশনগুলো কীভাবে রিপোর্ট করা হবে?

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

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

আমরা নিম্নলিখিত স্থানগুলিতে এই API-টির বিষয়ে সক্রিয়ভাবে মতামত আহ্বান করছি:

• এপিআই (API) সম্পর্কিত মতামত গিটহাবে (GitHub) ইস্যু হিসেবে উত্থাপন করা উচিত।
• ক্রোমিয়াম বাস্তবায়নের ত্রুটিগুলো ক্রোমের ইস্যু ট্র্যাকারে উত্থাপন করা উচিত, যদি এটি এখনও জ্ঞাত সমস্যাগুলোর মধ্যে একটি না হয়ে থাকে।
• ওয়েব ভাইটালস সম্পর্কিত সাধারণ মতামত web-vitals-feedback@googlegroups.com ঠিকানায় জানানো যাবে।

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

পরিবর্তন তালিকা

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

উপসংহার

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

কৃতজ্ঞতা স্বীকার

আনস্প্ল্যাশে জর্ডান মাদ্রিদের তোলা থাম্বনেইল ছবি।

এই কাজটি ইয়োভ ভাইসের গুগলে থাকাকালীন প্রথম শুরু করা কাজেরই ধারাবাহিকতা। এই এপিআই-এর জন্য তাঁর প্রচেষ্টার জন্য আমরা ইয়োভকে ধন্যবাদ জানাই।