নরম নেভিগেশন পরিমাপ সঙ্গে পরীক্ষা

Barry Pollard

Michal Mocny

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• প্রতিটি সফট নেভিগেশন শনাক্ত হওয়ার পর একটি soft-navigation PerformanceTiming ইভেন্ট নির্গত হবে।
• এই soft-navigation এন্ট্রিতে একটি navigationId , name অ্যাট্রিবিউটে নতুন URL এবং সূচনাকারী ইন্টারঅ্যাকশনের একটি interactionId অন্তর্ভুক্ত থাকবে।
• যেসব ইন্টারঅ্যাকশন কন্টেন্টফুল পেইন্ট ঘটায়, সেগুলোর পরে এক বা একাধিক interaction-contentful-paint এন্ট্রি নির্গত হবে। যখন কোনো ইন্টারঅ্যাকশন একটি সফট নেভিগেশন নির্গত করে, তখন সফট নেভিগেশনের জন্য লার্জেস্ট কন্টেন্টফুল পেইন্ট (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 একটি largestInteractionContentfulPaint এন্ট্রি অন্তর্ভুক্ত থাকবে, যেখানে ন্যাভিগেশনের অংশ হিসেবে নির্গত বৃহত্তম interaction-contentful-paint এন্ট্রিটি থাকবে। এটিকে সেই ন্যাভিগেশনের প্রাথমিক LCP হিসেবে ব্যবহার করা যেতে পারে, এবং সেই ইন্টারঅ্যাকশনের জন্য আরও interaction-contentful-paint এন্ট্রি পর্যবেক্ষণ করা হলে LCP-টি আপডেট করা যেতে পারে।
• সম্ভাব্যভাবে কিছু interaction-contentful-paint এন্ট্রি সফট নেভিগেশন ঘটার আগেই ঘটে থাকতে পারে (যদি URL আপডেটটি সেই পেইন্টগুলোর পরে না ঘটে)। এই ক্ষেত্রে, সবচেয়ে বড় largestInteractionContentfulPaint এন্ট্রিটি বাফার করার এবং পুরোনো এন্ট্রিগুলো পুনরায় দেখার প্রয়োজনীয়তা এড়িয়ে যায়। উল্লেখ্য যে, largestInteractionContentfulPaint হলো সবচেয়ে বড় interaction-contentful-paint এন্ট্রির একটি হুবহু অনুলিপি, তাই সেই এন্ট্রিটি পূর্ববর্তী navigationId ব্যবহার করবে কারণ পেইন্টটি তখনই ঘটেছিল, কিন্তু এই পেইন্টগুলোকে নতুন navigationId সাপেক্ষে পরিমাপ করা উচিত।
• soft-navigation এন্ট্রিতে সেই ন্যাভিগেশনের FCP হিসেবে paintTime এবং presentationTime ও অন্তর্ভুক্ত থাকবে।
• মনে রাখবেন যে পরবর্তী ইন্টারঅ্যাকশনের পরেও interaction-contentful-paint এন্ট্রিগুলো নির্গত হবে, কিন্তু এগুলোকে বাদ দেওয়ার জন্য একটি URL-এর LCP-কে শুধুমাত্র soft navigations interactionId সাথে মেলে এমন interaction-contentful-paint এন্ট্রিগুলোর মধ্যে সীমাবদ্ধ রাখা উচিত।

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

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

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

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

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

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

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

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

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

যেসব ওয়েবসাইট তাদের সকল ভিজিটরকে এর প্রভাব দেখানোর জন্য এটি চালু করতে চায়, তাদের জন্য ক্রোম ১৪৭ থেকে একটি অরিজিন ট্রায়াল চালু হবে। ট্রায়ালের জন্য সাইন আপ করে এবং HTML বা HTTP হেডারে অরিজিন ট্রায়াল টোকেনসহ একটি মেটা এলিমেন্ট অন্তর্ভুক্ত করার মাধ্যমে এটি সক্রিয় করা যাবে। আরও তথ্যের জন্য ‘ Get started with origin trials’ পোস্টটি দেখুন।

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

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

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

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 একাধিকবার ভিজিট করা হতে পারে)। এটি PerformanceEntry API-এর মাধ্যমে খুঁজে বের করা যেতে পারে।

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

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 এন্ট্রিগুলোর মধ্যে largestInteractionContentfulPaint এন্ট্রিটিকেও প্রসেস করার কথা আপনার বিবেচনা করা উচিত, যাতে soft-navigation entries নির্গত হওয়ার আগে ঘটা interaction-contentful-paint এন্ট্রিগুলোকে আরও সহজে হ্যান্ডেল করা যায়।

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

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

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

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

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

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

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

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

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

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

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

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 লাইব্রেরি সফট নেভিগেশনের জন্য নিম্নলিখিত মেট্রিকগুলো রিপোর্ট করে:

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

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

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

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

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

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

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

দলটি হিউরিস্টিক এবং প্রযুক্তিগত বাস্তবায়নের উপর মনোযোগ দিচ্ছে, যা আমাদের এই পরীক্ষার সাফল্য বিচার করতে সাহায্য করবে, তাই এই দিকগুলোতে এখনও কোনো সিদ্ধান্ত নেওয়া হয়নি।

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

আমরা নিম্নলিখিত স্থানগুলিতে এই পরীক্ষাটির বিষয়ে সক্রিয়ভাবে মতামত জানতে চাইছি:

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

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

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

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

উপসংহার

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

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

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

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