← ব্লগে ফিরে যান
3 মিনিট পড়ারperformancecore-web-vitalsspaprivacy

Soft Navigations: ব্রাউজারের পদ্ধতিতে SPA-এর পারফরম্যান্স মাপা

Chrome-এর soft navigation heuristics অবশেষে Core Web Vitals-কে ক্লায়েন্ট-সাইড রুট পরিবর্তনের সঙ্গে যুক্ত করতে দেয়। জেনে নিন এই API কীভাবে কাজ করে এবং নজরদারি ছাড়াই কীভাবে এটি মাপবেন।

এক দশক ধরে Core Web Vitals কেবল সেই প্রথম পেজটিই বর্ণনা করত যা একজন ভিজিটর লোড করতেন। single-page application-এ এর পরের প্রতিটি রুট পরিবর্তন মেট্রিকের কাছে অদৃশ্য থাকত। Chrome-এর soft navigations পরীক্ষা এই ফাঁক পূরণ করে, এবং বদলে দেয় কীভাবে একটি প্রাইভেসি-ফার্স্ট অ্যানালিটিক্সের প্রকৃত ব্যবহারকারীর পারফরম্যান্স মাপা উচিত।

যে অন্ধ-বিন্দু soft navigations ঠিক করে

একটি প্রচলিত hard navigation ডকুমেন্টটি unload করে এবং একটি নতুন ডকুমেন্ট লোড করে। ব্রাউজার তার পারফরম্যান্স টাইমলাইন রিসেট করে, একটি নতুন LCP ফায়ার করে, এবং CLS ও INP শূন্য থেকে গুনতে শুরু করে। CrUX-এর মতো ফিল্ড টুল সবকিছু সেই একটিমাত্র URL-কে দায়ী করে।

SPA এভাবে কাজ করে না। প্রাথমিক লোডের পর React Router, Next.js-এর App Router, কিংবা SvelteKit History API ব্যবহার করে কনটেন্ট জায়গায় বসিয়ে বদলে দেয়। কোনো ডকুমেন্ট unload হয় না, তাই কোনো নতুন পারফরম্যান্স টাইমলাইন শুরু হয় না। একজন ব্যবহারকারী দশটি "পেজ" পর্যন্ত ক্লিক করে ঘুরতে পারেন, অথচ প্রতিটি Core Web Vital প্রবেশের URL-এই আটকে থাকে।

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

Chrome কীভাবে একটি soft navigation শনাক্ত করে

Chrome-এর heuristic একটি soft navigation রেকর্ড করার আগে ক্রমানুসারে তিনটি বিষয় ঘটার দাবি রাখে:

  1. নেভিগেশনটি একটি ব্যবহারকারী ইন্টারঅ্যাকশন দিয়ে শুরু হয় — একটি ক্লিক বা একটি key press।
  2. URL টি History API বা Navigation API দিয়ে পরিবর্তিত হয়।
  3. ইন্টারঅ্যাকশনের পর একটি DOM পরিবর্তন ঘটে, যা আগে থেকেই বিদ্যমান একটি DOM element বদলায়।

এই ধারাক্রমটি ইচ্ছাকৃতভাবে কঠোর। অ্যানালিটিক্সের জন্য ব্যাকগ্রাউন্ডে চালানো pushState, নিজে থেকে এগিয়ে চলা carousel, কিংবা ইন্টারঅ্যাকশন ছাড়া URL পরিবর্তন—এর কোনোটিই যোগ্য নয়। এই নির্ভুলতা গুরুত্বপূর্ণ: এর মানে একটি soft navigation এমন কিছুর সঙ্গে মেলে যা সত্যিই একজন মানুষ করেছেন, কোনো আনুষঙ্গিক স্ক্রিপ্ট কার্যকলাপের সঙ্গে নয়।

API-এর পৃষ্ঠতল

soft navigations একটি ডেডিকেটেড entry type ব্যবহার করে স্ট্যান্ডার্ড PerformanceObserver-এর মাধ্যমে প্রকাশ পায়। আপনি প্রতিটি observer-এর জন্য এটি চালু করেন:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.name, entry.startTime);
  }
}).observe({ type: "soft-navigation", buffered: true });

আরও গুরুত্বপূর্ণ: অন্যান্য পারফরম্যান্স entry একটি navigationId পায়। একটি soft navigation-এর পর নির্গত LCP, layout-shift, এবং event-timing entry নতুন ID বহন করে, ফলে আপনি প্রতিটি Core Web Vital-কে সেই রুটে পুনরায় দায়ী করতে পারেন যেখানে ব্যবহারকারী আসলে ছিলেন:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.navigationId এই LCP-কে একটি নির্দিষ্ট soft navigation-এর সঙ্গে যুক্ত করে
    send({ metric: "LCP", value: entry.startTime, navId: entry.navigationId });
  }
}).observe({ type: "largest-contentful-paint", buffered: true });

বর্তমানে এটি chrome://flags/#soft-navigation-heuristics ও একটি origin trial-এর পেছনে থাকে, এবং CrUX-এ এর উপস্থিতি সীমিত। স্থিতিশীল Chrome-এ এটি এখনও ডিফল্ট নয়, তাই ফিল্ড সংখ্যাগুলোকে দিকনির্দেশক হিসেবে দেখুন, চূড়ান্ত প্রমাণ হিসেবে নয়। web-vitals লাইব্রেরি তার reportSoftNavs অপশনের মাধ্যমে একই ডেটা প্রকাশ করে, যা হাতে observer না লিখে এটি যুক্ত করার বাস্তবসম্মত উপায়।

কেন এটি প্রাইভেসি-ফার্স্ট অ্যানালিটিক্সের অন্তর্ভুক্ত

soft navigation ডেটা বিশুদ্ধ timing। এতে কোনো শনাক্তকারী নেই, কোনো cookie নেই, এবং পেজ সেশনের পর টিকে থাকে এমন কিছু নেই—কেবল একটি সময়কাল, একটি স্থূল element type, একটি রুট path। এটি ঠিক সেই ধরনের সংকেত যা একটি cookie-বিহীন টুল সম্মতির যন্ত্রপাতি স্পর্শ না করেই সংগ্রহ করতে পারে।

ট্র্যাকার ইতিমধ্যেই SPA রুট পরিবর্তন গণনা করতে history.pushState-এ হুক করে। soft navigations সেই একই হুককে আরও সূক্ষ্ম করে: শুধু রুট কি বদলেছে জিজ্ঞাসার বদলে আপনি জিজ্ঞাসা করতে পারেন এটি কি ইন্টারঅ্যাকশন-চালিত নেভিগেশন ছিল, এবং এর পারফরম্যান্স কেমন। পারফরম্যান্স entry গুলো বিদ্যমান pageview beacon-এর পাশাপাশি /collect-এ যায়, যা 2 KB-এর কম স্ক্রিপ্টে বোঝা না বাড়িয়ে এবং দৈনিক-হ্যাশ পরিচয় মডেল না ভেঙে ফিল্ড পরিমাপ যোগ করে।

যে ফাঁদ এড়াতে হবে তা হলো soft navigations-কে আরও বেশি সংগ্রহের অজুহাত বানানো। কিছু RUM বিক্রেতা এই নতুন attribution ব্যবহার করে একটি সেশন জুড়ে প্রতি-ব্যবহারকারী নেভিগেশন যাত্রা সেলাই করবে—ঠিক সেই নজরদারি প্যাটার্ন যা প্রত্যাখ্যান করতেই cookie-বিহীন অ্যানালিটিক্সের অস্তিত্ব। মেট্রিকটি মূল্যবান ঠিক এই কারণে যে এটি aggregate থেকে যেতে পারে: প্রতি রুটে median INP, প্রতি রুটে LCP বণ্টন, কোনো ব্যক্তির কাছে ফিরে যাওয়ার পথ নেই।

soft navigations আপনার অ্যাপের গভীরতম, ধীরতম অংশগুলোকে প্রথমবারের মতো পরিমাপযোগ্য করে তোলে। timing সংগ্রহ করুন, বাকি সব ফেলে দিন, আর profile ছাড়াই পারফরম্যান্সের ছবি পেয়ে যান।