Chrome 151-এর Soft Navigations API অবশেষে single-page apps (SPAs)-কে প্রতিটি ইন-অ্যাপ নেভিগেশনের জন্য Core Web Vitals রিপোর্ট করার সুযোগ দিচ্ছে, কিন্তু Google-এর CrUX ডেটাসেট এখনও শুধুমাত্র প্রথম hard load রেকর্ড করে, যার ফলে ডেভেলপারদের সামনে পারফরম্যান্সের দুটি ভিন্ন চিত্র ফুটে ওঠে।

কেন SPA মেট্রিক্স পিছিয়ে ছিল

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) এবং Cumulative Layout Shift (CLS)—hard navigations-এর কথা মাথায় রেখে সংজ্ঞায়িত করা হয়েছিল। একটি hard navigation একটি সম্পূর্ণ নতুন ডকুমেন্ট নিয়ে আসে এবং আগের পেজের state মুছে ফেলে।

React, Vue, Next.js বা এই জাতীয় ফ্রেমওয়ার্ক দিয়ে তৈরি SPA-তে খুব কমই hard navigations ঘটে। একটি লিঙ্কে ক্লিক করলে History API-এর মাধ্যমে URL আপডেট হয়, ব্যাকগ্রাউন্ডে ডেটা ফেচ (fetch) করা হয় এবং সম্পূর্ণ রিলোড ছাড়াই কন্টেন্ট পরিবর্তন করা হয়। বিদ্যমান Performance API শুধুমাত্র প্রাথমিক পেজ লোডটি ক্যাপচার করে, তাই ব্যবহারকারীরা যখন এক রুট থেকে অন্য রুট-এ যান, তখন তারা যে ল্যাটেন্সি (latency) অনুভব করেন তা LCP এবং INP-তে ধরা পড়ে না।

এই সীমাবদ্ধতা বা 'blind spot' Performance Timeline বা Google-এর Chrome User Experience Report (CrUX) থেকে ডেটা নেওয়া ড্যাশবোর্ডগুলোর ফলাফলকে ভুলভাবে উপস্থাপন করে। এগুলো প্রায়ই "shell" পেজের জন্য চমৎকার LCP দেখায়, কিন্তু অ্যাপের ভেতরের ধীরগতির লোডগুলোকে উপেক্ষা করে, যা পারফরম্যান্সের একটি ভুল ধারণা দেয়।

Chrome-এর Soft Navigations API

Chrome 151 চালু করেছে Soft Navigations API, যা কিছু নির্দিষ্ট SPA ইন্টারঅ্যাকশনকে প্রকৃত নেভিগেশন হিসেবে গণ্য করার জন্য একগুচ্ছ হিউরিস্টিকস (heuristics) ব্যবহার করে। এই API তিনটি সংকেত পর্যবেক্ষণ করে:

  • ব্যবহারকারী দ্বারা শুরু করা কোনো ইন্টারঅ্যাকশন (click, tap, keyboard event)
  • History API-এর মাধ্যমে URL পরিবর্তন
  • পরবর্তী paint ইভেন্ট যা নতুন কন্টেন্ট রেন্ডার করে

যখন এই তিনটি বিষয় মিলে যায়, Chrome Performance Timeline-এ একটি soft navigation লগ করে এবং একটি hard navigation-এর মতোই সেই ট্রানজিশনের জন্য Core Web Vitals গণনা করা হয়। ওপেন-সোর্স web-vitals লাইব্রেরি ২১ জুলাই থেকে এটি সাপোর্ট করা শুরু করেছে, ফলে ডেভেলপাররা তাদের ব্যবহৃত একই API দিয়ে এই সংখ্যাগুলো সংগ্রহ করতে পারবেন।

বাস্তবে, আপনি এখন প্রতিটি রুট পরিবর্তনের জন্য একটি LCP ভ্যালু, শেষ ইউজার ইনপুটের প্রকৃত ল্যাটেন্সি প্রতিফলিত করে এমন একটি INP এবং soft navigation-এর পরে লেআউট শিফট ক্যাপচার করে এমন একটি CLS দেখতে পাবেন।

ডেটার বিভাজন: Chrome বনাম CrUX

Google-এর CrUX (Chrome User Experience Report) PageSpeed Insights, Search Console এবং পরোক্ষভাবে র‍্যাঙ্কিং সিগন্যালগুলোকে চালিত করে। CrUX এখনও শুধুমাত্র hard-navigation ডেটা সংগ্রহ করে।

ফলে, আপনি দুটি সামঞ্জস্যপূর্ণ কিন্তু ভিন্ন ডেটা স্ট্রিম পাবেন:

  • Internal tools যা Performance Timeline থেকে ডেটা পড়ে, সেগুলো এখন রুট-লেভেল LCP, INP এবং CLS দেখায়, যা একটি SPA-তে ব্যবহারকারীরা আসলে কী অনুভব করছেন তার একটি বাস্তবসম্মত চিত্র দেয়।
  • Google-এর পাবলিক ডেটাসেটগুলো এখনও শুধুমাত্র প্রথম পেজ লোডের মেট্রিক্স দেখায়, যা Search Console রিপোর্ট করে এবং Google-এর র‍্যাঙ্কিং অ্যালগরিদমগুলো রেফারেন্স হিসেবে ব্যবহার করে।

দুটিই সঠিক; তারা শুধু ভিন্ন ভিন্ন মুহূর্ত পরিমাপ করে। শুধুমাত্র Search Console-এর ওপর নির্ভর করলে প্রাথমিক লোডের পরে ঘটে যাওয়া পারফরম্যান্সের অবনতি (regressions) আড়ালে পড়ে যেতে পারে, আবার শুধুমাত্র ইন্টারনাল ড্যাশবোর্ড Google-এর SEO-এর জন্য ব্যবহৃত বেসলাইনটি প্রতিফলিত করবে না।

ডেভেলপারদের যা খেয়াল রাখতে হবে

  • Browser support – Soft Navigations API বর্তমানে শুধুমাত্র Chromium-ভিত্তিক ব্রাউজারে উপলব্ধ। Safari এবং Firefox-এ এর সমতুল্য কিছু নেই, তাই আপনার ব্যবহারকারীদের একটি অংশের জন্য আপনাকে ফলব্যাক লজিক (fallback logic) রাখতে হবে।
  • Heuristic limits – API কিছু সংকেতের ভিত্তিতে একটি soft navigation নির্ধারণ করে। যদি আপনার অ্যাপ URL পরিবর্তন না করেই কন্টেন্ট আপডেট করে (যেমন: modal overlays বা infinite scroll), তবে API সেই ট্রানজিশনগুলো মিস করতে পারে, যা ডেটাতে গ্যাপ তৈরি করবে।
  • Testing before trusting – যেহেতু শনাক্তকরণ প্রক্রিয়াটি হিউরিস্টিক, তাই আপনার অ্যাপে বাস্তব জগতের কিছু ইন্টারঅ্যাকশন চালিয়ে দেখুন এবং রিপোর্ট করা মেট্রিক্সগুলোকে ম্যানুয়াল টাইমিংয়ের (যেমন: performance.mark ব্যবহার করে) সাথে তুলনা করুন। নির্ভুলতা নিশ্চিত করার পরেই কেবল নতুন সংখ্যাগুলোর ওপর ভিত্তি করে অপ্টিমাইজেশনের সিদ্ধান্ত নেওয়া উচিত।

মূল কথা

Chrome 151 SPA ডেভেলপারদের প্রতিটি ইন-অ্যাপ রুট পরিবর্তনের জন্য LCP, INP এবং CLS পরিমাপ করার দীর্ঘ প্রতীক্ষিত ক্ষমতা দিচ্ছে, কিন্তু Google-এর র‍্যাঙ্কিং ডেটা এখনও শুধুমাত্র প্রথম hard load-টি প্রতিফলিত করে। যতক্ষণ না CrUX এর সাথে তাল মেলাচ্ছে, ততক্ষণ টিমগুলোকে দুটি সমান্তরাল ডেটাসেট নিয়ে কাজ করতে হবে: একটি যা ব্যবহারকারীর প্রকৃত অভিজ্ঞতা জানায়, এবং অন্যটি যা সার্চ র‍্যাঙ্কিং নিয়ন্ত্রণ করে। প্রতিযোগিতামূলক ওয়েব ইকোসিস্টেমে পারফরম্যান্স-ফার্স্ট SPA বজায় রাখার জন্য এই দুটির মধ্যে ভারসাম্য বজায় রাখা এবং আরও ব্যাপক ব্রাউজার সাপোর্টের জন্য প্রস্তুতি নেওয়া অত্যন্ত গুরুত্বপূর্ণ হবে।