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

Barry Pollard

Michal Mocny

প্রকাশিত: ১ ফেব্রুয়ারি, ২০২৩, শেষবার আপডেট করা হয়েছে: ২০ সেপ্টেম্বর, ২০২৬

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

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

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

Chrome টিম কিছু সময় ধরে এই চ্যালেঞ্জটি বিবেচনা করেছে এবং "সফ্ট-নেভিগেশন" কী এবং এর জন্য কীভাবে Core Web Vitals পরিমাপ করা যেতে পারে তার একটি সংজ্ঞা মানসম্মত করতে চাইছে—একইভাবে যেভাবে প্রচলিত মাল্টি-পেজ আর্কিটেকচারে (MPA) বাস্তবায়িত ওয়েবসাইটগুলি পরিমাপ করা হয়।

ডেভেলপারদের মতামতের ভিত্তিতে আমরা প্রস্তাবে বেশ কিছু উন্নতি করেছি এবং Chrome 151 থেকে এই সমস্যা সমাধানে সাহায্য করার জন্য দুটি নতুন পারফর্ম্যান্স API লঞ্চ করেছি। এছাড়াও, আমরা Chrome User Experience Report (CrUX)-এ পরীক্ষামূলক মেট্রিক্স হিসেবে সফট নেভিগেশন মেট্রিক্স উপলভ্য করেছি।

সফ্ট নেভিগেশন কী?

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

• ব্যবহারকারীর অ্যাকশনের মাধ্যমে নেভিগেশন শুরু করা হয়।
• নেভিগেশনের ফলে ব্যবহারকারীর কাছে দৃশ্যমান URL পরিবর্তন হয়।
• ইন্টার‍্যাকশনের ফলে একটি দৃশ্যমান পেইন্ট তৈরি হয়।

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

সফ্ট নেভিগেশনের জন্য DevTools সহায়তা

আমরা DevTools-এর পারফর্ম্যান্স প্যানেলে লাইভ মেট্রিক্স ভিউতে এবং ইনসাইট ও মার্কার সহ ট্রেস ভিউতে সফট নেভিগেশনের জন্য সহায়তা যোগ করেছি:

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

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

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

এইসব পরিবর্তনের ফলে Core Web Vitals—এবং কিছু সংশ্লিষ্ট ডায়াগনস্টিক মেট্রিক—প্রতি পৃষ্ঠা নেভিগেশন অনুযায়ী পরিমাপ করা যাবে, যদিও কিছু সূক্ষ্ম পার্থক্য আছে যা বিবেচনা করতে হবে।

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

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

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

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

সফ্ট নেভিগেশনের জন্য মেট্রিক কীভাবে পরিমাপ করতে হয় সেই সম্পর্কে আরও তথ্যের জন্য, সফ্ট নেভিগেশন বিভাগ অনুযায়ী Core Web Vitals পরিমাপ করা দেখুন।

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

Chrome 151 থেকে সফট নেভিগেশন ফিচার ডিফল্ট হিসেবে চালু করা হয়েছে।

সফ্ট নেভিগেশন API সাপোর্ট শনাক্ত করার ফিচার

API কাজ করে কিনা তা পরীক্ষা করতে আপনি নিম্নলিখিত কোড ব্যবহার করতে পারেন:

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-এর সাথে মেট্রিক রিপোর্ট করুন

সফ্ট নেভিগেশন দেখা গেলে, আগের পৃষ্ঠার Core Web Vitals চূড়ান্ত করা উচিত এবং তারপরে আগের URL-এর জন্য রিপোর্ট করা উচিত এবং নতুন 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 পেতে soft-navigation-entries-এ interaction-contentful-paint এন্ট্রি ম্যাপ করার জন্য navigationId-এর পরিবর্তে interactionId ব্যবহার করা উচিত। এটি পুরনো navigationId-এর সাথে যেকোনও এন্ট্রি ম্যানেজ করবে এবং সেইসাথে যেকোনও interaction-contentful-paint এন্ট্রি ফিল্টার করবে যা LCP-এর জন্য বিবেচনা করা উচিত নয়।

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

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

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

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

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

প্রতিটি সফ্ট নেভিগেশনের জন্য Core Web Vitals পরিমাপ করা

Core Web Vitals পরিমাপ করতে, soft-navigation এন্ট্রি শুনুন, এগুলি পাওয়ার পরে মেট্রিক রিসেট করুন। presentationTime-এর উপর ভিত্তি করে FCP এমিট করা যেতে পারে এবং getLargestInteractionContentfulPaint() এন্ট্রিতে LCP ইনিশিয়ালাইজ করা যেতে পারে। INP, CLS, 0-তে ইনিশিয়ালাইজ করা উচিত, কারণ পৃষ্ঠা লোড করার জন্য এগুলি প্রয়োজন।

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

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

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

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

নেভিগেশনের মধ্যে একই থাকে এমন কন্টেন্ট কীভাবে ট্রিট করা উচিত?

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

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

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

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

TTFB কীভাবে পরিমাপ করবেন?

প্রথাগত পৃষ্ঠা লোডের জন্য Time to First Byte (TTFB) হল আসল অনুরোধের প্রথম বাইট ফিরে আসতে যে সময় লাগে।

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

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

আপনার কি দুটি পদ্ধতিতেই Core Web Vitals পরিমাপ করা উচিত?

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

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

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

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

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

এই পরিবর্তনগুলি কি Core Web Vitals পরিমাপের অংশ হবে?

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

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

আমরা CrUX-এ Core Web Vitals মেট্রিক্সের এক্সপেরিমেন্টাল ভার্সন লঞ্চ করেছি। এগুলি প্রথম সফ্ট নেভিগেশনের পরে "হার্ড নেভিগেশন" CLS এবং INP শেষ করে এবং প্রতিটি সফ্ট নেভিগেশনের জন্য অতিরিক্ত LCP, CLS এবং INP পরিমাপও অন্তর্ভুক্ত করে। আমরা ২০২৭ সালের মে মাসে এই পরীক্ষামূলক মেট্রিকগুলিকে স্থিতিশীল মেট্রিকগুলিতে উন্নীত করার পরিকল্পনা করেছি। আরও তথ্যের জন্য CrUX-এ এখন এক্সপেরিমেন্টাল সফট নেভিগেশন মেট্রিক উপলভ্য ব্লগ পোস্ট দেখুন।

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

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

URL পরিবর্তনের উপর নজর রাখতে Navigation API ব্যবহার করা সম্ভব, যা URL অনুযায়ী INP স্লাইস করার অনুমতি দিতে পারে (এবং একইভাবে CLS, যদিও এটি এই মুহূর্তে শুধুমাত্র Chromium-এ কাজ করে, তাই এটি পরিমাপ করা হবে না)। তবে, এটি পেইন্ট মেট্রিক (FCP এবং LCP) সমাধান করে না যা শুধুমাত্র আনুমানিক হতে পারে।

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

আমরা স্ট্যান্ডার্ডাইজেশন প্রসেসের মাধ্যমে কাজ করা চালিয়ে যাব এবং এই API-এর গুরুত্ব বোঝাতে অন্যান্য ব্রাউজার ভেন্ডরের সাথে যোগাযোগ করব।

মতামত

আমরা নিম্নলিখিত জায়গাগুলিতে এই API সম্পর্কে মতামত জানার ব্যাপারে খুবই আগ্রহী:

• API সম্পর্কে মতামত GitHub-এ সমস্যা হিসেবে জানাতে হবে।
• Chromium ইমপ্লিমেন্টেশনে কোনও সমস্যা থাকলে তা Chrome-এর ইস্যু ট্র্যাকারে জানাতে হবে, যদি এটি এখনও পরিচিত সমস্যার মধ্যে না পড়ে।
• Web Vitals সংক্রান্ত সাধারণ মতামত web-vitals-feedback@googlegroups.com-এ শেয়ার করা যেতে পারে।

সন্দেহ থাকলে খুব বেশি চিন্তা করবেন না, আমরা যেকোনও একটি জায়গায় মতামত শুনতে চাই এবং দুটি জায়গাতেই সমস্যাগুলি আনন্দের সাথে সমাধান করব এবং সঠিক লোকেশনে সমস্যাগুলি রিডাইরেক্ট করব।

পরিবর্তনের লগ

এই API ডেভেলপ করার সময়, এতে অনেক পরিবর্তন করা হয়েছে, যা স্টেবল API-এর চেয়েও বেশি। আরও তথ্যের জন্য আপনি সফ্ট নেভিগেশন চেঞ্জলগ দেখতে পারেন।

উপসংহার

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

স্বীকৃতি

Unsplash-এ জর্ডন মাদ্রিদ-এর তোলা থাম্বনেল ছবি

এই কাজটি Yoav Weiss-এর শুরু করা কাজের ধারাবাহিকতা, যা তিনি Google-এ থাকাকালীন শুরু করেছিলেন। এই API-এর জন্য Yoav-এর প্রচেষ্টাকে আমরা ধন্যবাদ জানাই।