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

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

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

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

ক্রোম ১৫১ থেকে সফট নেভিগেশন ফিচারটি ডিফল্টরূপে সক্রিয় করা হয়েছে।

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

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

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

অথবা বিকল্পভাবে:

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

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

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

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

আপনি সফট নেভিগেশন পর্যবেক্ষণ করতে একটি 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 soft-navigation entries নির্গত হওয়ার আগে ঘটে যাওয়া interaction-contentful-paint এন্ট্রিগুলো পরিচালনা করার জন্য, আপনার প্রথমে সফট-ন্যাভিগেশন এন্ট্রিগুলোর 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 জাভাস্ক্রিপ্ট লাইব্রেরিটি ব্যবহার করা, যেটিতে v6.0.0 সংস্করণ থেকে সফট নেভিগেশনের সুবিধা রয়েছে। এটি নিম্নলিখিত উপায়ে পরিমাপ করা যেতে পারে (প্রয়োজন অনুযায়ী 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 লাইব্রেরি সফট নেভিগেশনের জন্য নিম্নলিখিত মেট্রিকগুলো রিপোর্ট করে:

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

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

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

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

অন্যান্য ব্রাউজারে সফট নেভিগেশন কীভাবে পরিচালনা করবেন?

যেসব ব্রাউজার এপিআই সমর্থন করে না, সেগুলোতে সফট নেভিগেশন প্রোগ্রামগতভাবে শনাক্ত করা কঠিন—আর ঠিক এই কারণেই আমরা এই এপিআইটি নিয়ে কাজ করেছি।

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

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

আমরা মাননির্ধারণ প্রক্রিয়ার কাজ চালিয়ে যাব এবং এই এপিআই-এর গুরুত্ব তুলে ধরতে অন্যান্য ব্রাউজার বিক্রেতাদের সাথেও আলোচনা করব।

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

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

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

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

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

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

উপসংহার

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

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

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

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