এসপিএ, কোর ওয়েব ভাইটালস এবং কোর ওয়েব ভাইটালস কীভাবে এগুলিকে বিবেচনা করে, সে সম্পর্কে সাধারণ প্রশ্নের উত্তর।
প্রকাশিত: ১৪ সেপ্টেম্বর, ২০২১, সর্বশেষ হালনাগাদ: ১১ আগস্ট, ২০২৬
২০২০ সালের মে মাসে ওয়েব ভাইটালস উদ্যোগটি প্রথম চালু করার পর থেকে, আমরা ক্রোম টিমের পক্ষ থেকে এই প্রোগ্রামটি সম্পর্কে অনেক চমৎকার প্রশ্ন ও মতামত পেয়েছি।
সম্ভবত যে বিষয়টি নিয়ে আমরা সবচেয়ে বেশি প্রশ্ন পেয়েছি, এবং যার উত্তর দেওয়াও সম্ভবত সবচেয়ে কঠিন, তা হলো একটি সিঙ্গেল-পেজ অ্যাপ্লিকেশনে (SPA) কোর ওয়েব ভাইটালস কীভাবে পরিমাপ করা যায়, এবং সেইসাথে SPA আর্কিটেকচারগুলো কীভাবে কোর ওয়েব ভাইটালস স্কোরকে প্রভাবিত করে।
এই প্রশ্নগুলোর উত্তর দেওয়া কঠিন, কারণ সমস্যাটি বেশ সূক্ষ্ম। তাই এই পোস্টে আমরা যথাসম্ভব বিস্তারিত তথ্য ও প্রেক্ষাপটসহ সবচেয়ে সাধারণ প্রশ্নগুলোর উত্তর দেওয়ার চেষ্টা করব।
তবে, বিস্তারিত আলোচনায় যাওয়ার আগে এটা বলা গুরুত্বপূর্ণ যে, একটি সাইট তৈরি করতে কোন আর্কিটেকচার বা প্রযুক্তি ব্যবহার করা হবে, সে বিষয়ে গুগলের কোনো বিশেষ পছন্দ নেই। আমরা বিশ্বাস করি যে, এসপিএ (SPA) এবং মাল্টি-পেজ অ্যাপ্লিকেশন (MPA) উভয়ই ব্যবহারকারীদের উচ্চমানের অভিজ্ঞতা প্রদানে সক্ষম, এবং ওয়েব ভাইটালস উদ্যোগের মাধ্যমে আমাদের উদ্দেশ্য হলো এমন মেট্রিকস প্রদান করা যা প্রযুক্তি নির্বিশেষে সেই অভিজ্ঞতাকে পরিমাপ করবে।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
এই বিষয়ে আমরা প্রায়শই যে প্রশ্নগুলো পেয়ে থাকি, তার কয়েকটি নিচে দেওয়া হলো। আমাদের ফিডব্যাক গ্রুপে অথবা কোনো ইস্যু উত্থাপনের মাধ্যমে এই প্রায়শই জিজ্ঞাসিত প্রশ্নাবলীতে (FAQ) যোগ করার জন্য আমরা মতামত গ্রহণ করতে আগ্রহী।
কোর ওয়েব ভাইটালস মেট্রিক্সে কি এসপিএ রুট ট্রানজিশন অন্তর্ভুক্ত আছে?
প্রথম চালু হওয়ার সময়, প্রতিটি কোর ওয়েব ভাইটালস মেট্রিক বর্তমান, শীর্ষ-স্তরের পেজ নেভিগেশনের সাপেক্ষে পরিমাপ করা হতো। যদি কোনো পেজ ডায়নামিকভাবে নতুন কন্টেন্ট লোড করত এবং অ্যাড্রেস বারে পেজটির ইউআরএল আপডেট করত, তাহলে কোর ওয়েব ভাইটালস মেট্রিকগুলো কীভাবে পরিমাপ করা হয় তার উপর এর কোনো প্রভাব পড়ত না।
মেট্রিক মানগুলি রিসেট করা হয়নি, এবং প্রতিটি মেট্রিক পরিমাপের সাথে যুক্ত URL-টি হলো সেই URL, যেটিতে ব্যবহারকারী নেভিগেট করে পৃষ্ঠাটি লোড করা শুরু করেছিলেন।
ক্রোম ১৫১ নতুন এপিআই চালু করেছে যা এসপিএ রাউট ট্রানজিশন জুড়ে কোর ওয়েব ভাইটালস পরিমাপ করতে দেয়। এই লেখাটি লেখার সময় (আগস্ট ২০২৬), এই এপিআইগুলো web-vitals মতো পরিমাপ লাইব্রেরি, আরইউএম সলিউশন এবং ক্রোম ডেভটুলস-এর মতো টুলিং-এ সবেমাত্র ব্যবহৃত হতে শুরু করেছে। ক্রোম এখনও ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্ট (CrUX)- এ এগুলোকে একীভূত করার কোনো সময়সীমা প্রকাশ করেনি। এছাড়াও, অন্যান্য ব্রাউজার ইঞ্জিনগুলো এখনও এই নতুন এপিআইগুলো সমর্থন করে না এবং তাই শুধুমাত্র সেই ব্রাউজারগুলোর জন্য সম্পূর্ণ পেজ লোডের ক্ষেত্রে কোর ওয়েব ভাইটালস পরিমাপ করা যায়।
এই সমস্যাটি সমাধান করা কঠিন ছিল কেন?
বর্তমানে একটি SPA তৈরি করার কোনো প্রমিত পদ্ধতি নেই, এবং এমনকি জনপ্রিয় SPA ও রাউটিং লাইব্রেরিগুলোর মধ্যেও অ্যাপভেদে ব্যবহারকারীর অভিজ্ঞতা বেশ ভিন্ন হতে পারে:
- কিছু এসপিএ শুধুমাত্র নতুন "সম্পূর্ণ পৃষ্ঠা" কন্টেন্ট লোড করার সময় ইউআরএল আপডেট করে, অন্যদিকে অন্যান্য সাইট সামান্য কন্টেন্ট পরিবর্তন বা এমনকি শুধু ইউআই অবস্থার পরিবর্তনের জন্যও ইউআরএল আপডেট করে।
- কিছু এসপিএ হিস্ট্রি এপিআই ব্যবহার করে ইউআরএল আপডেট করে, আবার অন্যগুলো পুরোনো ব্রাউজার সমর্থন করার জন্য হ্যাশ পরিবর্তন ব্যবহার করে (এবং কিছু আবার ইউআরএল একেবারেই আপডেট করে না)।
- কিছু এসপিএ প্রথমে কন্টেন্ট লোড করে এবং তারপর ইউআরএল আপডেট করে, আবার অন্যগুলো কন্টেন্ট লোড করার আগেই ইউআরএল আপডেট করে।
- কিছু এসপিএ একটিমাত্র জাভাস্ক্রিপ্ট টাস্কের মাধ্যমে একবারে, সিনক্রোনাসভাবে, সমস্ত কন্টেন্ট লোড করে, অন্যদিকে অন্যগুলো একাধিক টাস্ক জুড়ে অ্যাসিঙ্ক্রোনাসভাবে ট্রানজিশনের মাধ্যমে কন্টেন্ট নিয়ে আসে (যেখানে ট্রানজিশন শেষ হওয়ার কোনো স্পষ্ট ইভেন্ট থাকে না)।
- কিছু এসপিএ সবসময় নেটওয়ার্ক থেকে কন্টেন্ট লোড করে, অন্যদিকে অন্যগুলো আগে থেকেই সমস্ত কন্টেন্ট লোড করে রাখে, যাতে রাউট পরিবর্তনের সাথে সাথে মেমোরি থেকে তা তাৎক্ষণিকভাবে লোড হয়।
এই পার্থক্যগুলোর কারণে বৃহৎ পরিসরে একটি এসপিএ রুট পরিবর্তন, বা এমনকি একটি এসপিএ-কেই সংজ্ঞায়িত করা ও চিহ্নিত করা অত্যন্ত কঠিন হয়ে পড়ে।
কিছু ক্ষেত্রে একটি SPA রাউট পরিবর্তন যৌক্তিকভাবে একটি MPA পেজ লোডের অনুরূপ হয়, এবং সেক্ষেত্রে বিদ্যমান Core Web Vitals মেট্রিকগুলো প্রয়োগ করা গেলে খুব ভালো হতো।
তবে, অন্যান্য সমস্ত ইউআরএল পরিবর্তন থেকে 'প্রকৃত' রুট পরিবর্তনকে নির্ভরযোগ্যভাবে শনাক্ত করার জন্য সুনির্দিষ্ট কার্যপ্রণালী—এবং এই ধরনের পরিবর্তনের শুরু ও শেষের সুস্পষ্ট সংকেত—না থাকলে, এই ক্ষেত্রে কোর ওয়েব ভাইটালস মেট্রিক্স রিপোর্ট করা হলে ডেটা ঘোলাটে হয়ে যাবে এবং তা সাইটের প্রকৃত ব্যবহারকারীর অভিজ্ঞতার ক্ষেত্রে কম উপযোগী বা কম প্রতিনিধিত্বমূলক হয়ে পড়বে।
সফট নেভিগেশন কাজটি দুটি নতুন পারফরম্যান্স এপিআই-এর মাধ্যমে এর একটি সমাধান দিয়েছে:
-
PerformanceSoftNavigationপরিমাপ করে কখন ব্যবহারকারীর কোনো ইন্টারঅ্যাকশনের ফলে পেইন্ট এবং ইউআরএল উভয়ই পরিবর্তিত হয়। এই তিনটি বিষয়ের সমন্বয়, ব্যবহৃত ফ্রেমওয়ার্ক এবং পূর্বে উল্লিখিত কিছু পার্থক্য নির্বিশেষে, একটি "সফট নেভিগেশন"-এর প্রমিত সংজ্ঞা প্রদান করে। এটি পারফরম্যান্স টাইমলাইনকে পৃথক "নেভিগেশন"-এ বিভক্ত করার সুযোগ দেয়, যার ফলে প্রতিটি নেভিগেশনের জন্য CLS এবং INP পরিমাপ করা যায়। -
InteractionContentfulPaintযা একটি ইন্টারঅ্যাকশনের পরে "কন্টেন্টফুল পেইন্ট" পরিমাপ করে, যার ফলে এই সফট নেভিগেশনগুলির জন্য FCP এবং LCP পরিমাপ করা যায়।
এই দুটি এপিআই-এর সমন্বয়ের মাধ্যমে সম্পূর্ণ পেজ লোড এবং সফট নেভিগেশন উভয় ক্ষেত্রেই কোর ওয়েব ভাইটালস পরিমাপ করা যায়।
কোর ওয়েব ভাইটালস-এর ক্ষেত্রে এসপিএ রাউট পরিবর্তন কি সম্পূর্ণ পেজ লোডের সমান?
না, এই ধরণের নেভিগেশনগুলির মধ্যে এখনও অনেক পার্থক্য রয়েছে, যার ফলে কোর ওয়েব ভাইটাল মেট্রিক্সে ভিন্নতা দেখা দিতে পারে।
একটি সফট নেভিগেশনে পেজে কন্টেন্ট থাকে এবং নতুন "পেজটি" দেখানোর জন্য সেই কন্টেন্টের কিছু অংশ বা সম্পূর্ণ অংশ আপডেট করা হয়। অনেক দিক থেকে এটি একটি আনক্যাশড সম্পূর্ণ পেজ লোড এবং পেজের কিছু বা সমস্ত রিসোর্স ক্যাশড থাকা অবস্থায় পেজ লোডের পার্থক্যের মতোই, তবে এটি আরও একটি চরম অবস্থা, কারণ কিছু কন্টেন্ট রেন্ডারড অবস্থাতেই থেকে যেতে পারে।
তাত্ত্বিকভাবে প্রধান পার্থক্য হবে সফট নেভিগেশনের অনেক দ্রুততর হওয়ার সম্ভাবনা। কিন্তু আরও কিছু সূক্ষ্ম পার্থক্যও রয়েছে।
নতুন সফট নেভিগেশন এপিআইগুলো শুধুমাত্র নতুন কন্টেন্ট বিবেচনা করে। তাই, কোনো পেজ যদি তার <h1> এবং টেক্সট কন্টেন্ট আপডেট করে, কিন্তু পেজগুলোর মধ্যে একই হিরো ইমেজ রেখে দেয়, তাহলে সেই হিরো ইমেজটি রি-পেইন্ট না হলে সেটিকে LCP ক্যান্ডিডেট হিসেবে বিবেচনা করা হবে না। এর ফলে, একই পেজটি সম্পূর্ণ পেজ লোড হিসেবে লোড হচ্ছে, নাকি অন্য কোনো বিদ্যমান পেজ থেকে সফট নেভিগেশন হিসেবে লোড হচ্ছে, তার উপর ভিত্তি করে LCP টাইম গণনা করার জন্য কোন এলিমেন্টগুলো ব্যবহৃত হবে, তাতে পার্থক্য দেখা দেবে।
একইভাবে, সফট নেভিগেশনের জন্য INP কম হতে পারে, কারণ সাইটটি চালানোর জন্য প্রয়োজনীয় অনেক জাভাস্ক্রিপ্ট ইতিমধ্যেই লোড হয়ে যায়। একইভাবে, একটি সফট নেভিগেশনের CLS কম (বা বেশি!) হতে পারে, যদি একই কন্টেন্ট সম্পূর্ণ পেজ লোডের সময় CLS তৈরি করে কিন্তু সফট নেভিগেশনের জন্য তা লোড বা পুনরায় রেন্ডার করার প্রয়োজন না হয়।
সম্পূর্ণ পৃষ্ঠা লোড হওয়ার সময় (নেভিগেশন ইন্টারঅ্যাকশন প্রক্রিয়াকরণের পর থেকে পরিমাপ করা হয়) এবং সফট নেভিগেশনের সময় (ইন্টারঅ্যাকশন শুরুর সময় থেকে পরিমাপ করা হয়) পরিমাপ নেওয়ার ক্ষেত্রেও সামান্য পার্থক্য রয়েছে।
পূর্বেই যেমন বলা হয়েছে, এই পার্থক্যগুলোর অনেকগুলোই আনক্যাশড বনাম ক্যাশড পেজের মতো, এবং কোর ওয়েব ভাইটালস যা পরিমাপ করার চেষ্টা করে, সেই ধারণাটি এক্ষেত্রেও প্রযোজ্য। তবে, কোর ওয়েব ভাইটালস সংক্রান্ত সমস্যাগুলো তদন্ত করার সময় এই সূক্ষ্ম বিষয়গুলো বোঝাটা জরুরি।
এমপিএ-দের তুলনায় এসপিএ-দের জন্য কোর ওয়েব ভাইটালস-এ ভালো করা কি বেশি কঠিন?
SPA আর্কিটেকচারের অন্তর্নিহিত এমন কিছুই নেই যা একটি SPA-এর পৃষ্ঠাকে MPA-এর অনুরূপ পৃষ্ঠার মতোই দ্রুত লোড হতে এবং সমস্ত কোর ওয়েব ভাইটালস মেট্রিক্সে সমান ভালো স্কোর করতে বাধা দেবে।
তবে, সঠিকভাবে অপ্টিমাইজ করা এমপিএ-গুলির কোর ওয়েব ভাইটালস থ্রেশহোল্ড পূরণের ক্ষেত্রে কিছু সুবিধা রয়েছে যা এসপিএ-গুলির নেই। পূর্বে আলোচিত সফট নেভিগেশন সংক্রান্ত কাজের মাধ্যমে এই সমস্যাটি অনেকাংশে সমাধান করা হয়েছে, কিন্তু যখন এই নতুন এপিআইগুলি এখনও ব্যবহৃত হচ্ছে না, তখনো এমনটা হতে পারে। এর কারণ হলো, এমপিএ আর্কিটেকচারে প্রতিটি "পেজ" একটি সম্পূর্ণ-পেজ নেভিগেশন হিসেবে লোড হয় (ডাইনামিকভাবে কন্টেন্ট ফেচ করে বিদ্যমান পেজে যুক্ত করার পরিবর্তে), যার অর্থ হলো, যারা একটি এমপিএ ভিজিট করেন, তাদের সাইটটি থেকে একাধিক পেজ লোড করার সম্ভাবনা বেশি থাকে। এর ফলে, একটি এমপিএ-র সমস্ত পেজ লোডের একটি বৃহত্তর অংশে কিছু বা সমস্ত সাব-রিসোর্স ক্যাশড অবস্থায় থাকে।
এটা ঠিক যে, একটি SPA-এর চেয়ে একটি MPA-কে Core Web Vitals মেট্রিক্সে ভালো পারফর্ম করতে হলে কয়েকটি বিষয় সত্য হতে হয়:
- ৭৫তম পার্সেন্টাইলে একই-অরিজিন পেজ লোড যেন ক্রস-অরিজিন পেজ লোডের চেয়ে প্রকৃতপক্ষে দ্রুততর হয়, তা নিশ্চিত করার জন্য এমপিএ-তে অপ্টিমাইজড সাব-রিসোর্স ক্যাশিং থাকা প্রয়োজন।
- এমপিএ পরিদর্শনকারী ব্যবহারকারীদের একাধিক পৃষ্ঠা পরিদর্শন করতে হয়, যাতে সাইটটি ক্যাশিংয়ের সুবিধা পেতে পারে, যার ফলে পৃষ্ঠাগুলো দ্রুত লোড হয়।
যেহেতু কোর ওয়েব ভাইটালস মূল্যায়নে পেজ ভিজিটের ৭৫তম পার্সেন্টাইল বিবেচনা করা হয় , তাই ডেটাসেটে অধিক সংখ্যক ও ভালো পারফর্ম করা পেজ ভিজিট থাকলে, ডিস্ট্রিবিউশনের ৭৫তম পার্সেন্টাইলে থাকা ভিজিটটি প্রস্তাবিত থ্রেশহোল্ডের মধ্যে থাকার সম্ভাবনা বেড়ে যায়।
মনে রাখবেন যে, কোর ওয়েব ভাইটালস স্কোর তুলনা করার সময় একটি গুরুত্বপূর্ণ বিষয় হলো ডেটা কীভাবে একত্রিত করা হয়েছে—অর্থাৎ, ডিস্ট্রিবিউশনের ডেটাসেটে আপনার সাইট বা অরিজিনের সমস্ত পেজ অন্তর্ভুক্ত আছে, নাকি শুধু একটি নির্দিষ্ট পেজ ইউআরএল-এর পেজ লোডগুলো রয়েছে।
একটি অরিজিনের সমস্ত পেজের স্কোর একত্রিত করার সময়, স্বতন্ত্র দ্রুত পেজগুলো পুরো অরিজিনের জন্য ৭৫তম পার্সেন্টাইল উন্নত করতে পারে। তবে, স্বতন্ত্র পেজ অনুযায়ী স্কোর একত্রিত করার সময়, একটি পেজের স্কোর তার পরের পেজের স্কোরকে প্রভাবিত করবে না। অন্য কথায়, পেজ অনুযায়ী একটি এমপিএ-এর স্কোর একত্রিত করার সময়, চেকআউট পেজে দেখা দ্রুত ক্যাশে লোড সাইটের ল্যান্ডিং পেজে অভিজ্ঞ ধীর প্রাথমিক লোডের স্কোর উন্নত করবে না ।
আপনি PageSpeed Insights অথবা Chrome User Experience Report API ব্যবহার করে বিভিন্ন অ্যাগ্রিগেশন পদ্ধতির জন্য আপনার সাইটের স্কোর যাচাই করতে পারেন, যা স্বতন্ত্র পেজের URL এবং সম্পূর্ণ অরিজিন উভয়ের জন্যই স্কোর রিপোর্ট করে।
এসপিএ আর্কিটেকচার কোর ওয়েব ভাইটালস স্কোরকে প্রভাবিত করার আরেকটি উপায় হলো সেইসব মেট্রিক, যেগুলো একটি পেজের সম্পূর্ণ জীবনকাল বিবেচনা করে। যেহেতু এসপিএ ভিজিট করা ব্যবহারকারীরা পুরো সেশন জুড়ে একই "পেজে" থাকার প্রবণতা দেখায়, তাই সময়ের সাথে সাথে জমা হওয়া মেট্রিকগুলো এমপিএ-র তুলনায় এসপিএ-র জন্য বেশি ক্ষতিকর হতে পারে।
সফট নেভিগেশনের কাজের ফলে, আমরা মনে করি যে কোর ওয়েব ভাইটালস পরিমাপের ক্ষেত্রে এসপিএ-গুলোর কোনো অসুবিধা থাকবে না। তবে, সমস্ত টুলিং এবং রিপোর্টিং সলিউশন জুড়ে এই এপিআই-গুলোর সম্পূর্ণ ইন্টিগ্রেশনে সময় লাগবে।
যদি SPA আর্কিটেকচার ব্যবহারকারীর অভিজ্ঞতা উন্নত করে, তবে সেই উন্নতি কি মেট্রিক্সে প্রতিফলিত হওয়া উচিত নয়?
হ্যাঁ, তাই হওয়া উচিত। বর্তমানে ওয়েবে এসপিএ (SPA) বিভিন্ন উপায়ে প্রয়োগ করা হয় বলে, অভিজ্ঞতা ঠিক কতটা উন্নত হয়েছে তা বৃহৎ পরিসরে পরিমাপ করা কঠিন ছিল। এখন আমাদের কাছে এই পরিমাপ সমস্যার একটি সমাধান আছে, এবং যখন এই নতুন এপিআই (API) গুলো ব্যবহার করা হবে, তখন এসপিএ-তে স্থানান্তরের ফলে হওয়া যেকোনো উন্নতি মেট্রিক্সে প্রতিফলিত হওয়া উচিত।
সত্যিটা হলো, ওয়েব পারফরম্যান্স ইন্ডাস্ট্রি (গুগল সহ) ঐতিহাসিকভাবে একটি পেজ লোড হওয়ার পরের পারফরম্যান্সের জন্য ব্যবহারকারী-কেন্দ্রিক মেট্রিক্স তৈরিতে ততটা সময় ও শ্রম বিনিয়োগ করেনি, যতটা তারা পেজটি লোড হওয়ার সময় করেছে। এর কারণ এটা নয় যে পোস্ট-লোড পারফরম্যান্স গুরুত্বপূর্ণ নয়, বরং কারণ হলো পোস্ট-লোড ইউএক্স (UX) এবং ইন্টারঅ্যাকশনগুলো অনেক বেশি বৈচিত্র্যময় ও অস্পষ্ট—যার ফলে এগুলোর জন্য মেট্রিক্স ডিজাইন করা কঠিন হয়ে পড়ে।
কিন্তু এখন এসপিএ-র পারফরম্যান্স পরিমাপ করার জন্য আমাদের কাছে আরও বেশি পোস্ট-লোড মেট্রিকস থাকলেও, শুধুমাত্র পোস্ট-লোড অভিজ্ঞতা উন্নত হয়েছে বলেই আমরা লোড অভিজ্ঞতাকে উপেক্ষা করতে চাইব না।
ওয়েব ভাইটালস উদ্যোগের অন্যতম লক্ষ্য হলো একটি ওয়েব পেজ লোড ও ব্যবহারের যত বেশি সম্ভব দিক জুড়ে ভালো ব্যবহারকারী অভিজ্ঞতাকে উৎসাহিত করা এবং তার জন্য প্রণোদনা দেওয়া। আমরা এমন পরিস্থিতিকে উৎসাহিত করতে চাই না যেখানে খারাপ অভিজ্ঞতাকে ন্যায্য বলে মনে করা হয়, যদি যথেষ্ট ভালো অভিজ্ঞতার মাধ্যমে তা পুষিয়ে নেওয়া যায়। ব্যবহারকারীরা চান পেজ দ্রুত লোড হোক এবং দ্রুত নতুন কন্টেন্টে চলে যাক, এবং আমরা এমন মেট্রিকস ডিজাইন করার চেষ্টা করেছি যা এই ধরনের অভিজ্ঞতাকেই প্রাধান্য দেয়।
আমরা আমাদের সাইটটি এমপিএ থেকে এসপিএ-তে পরিবর্তন করার পর আমাদের স্কোর কমে গেছে। এটা কি প্রত্যাশিত?
এটা নির্ভর করে। একটি বড় ধরনের আর্কিটেকচার মাইগ্রেশনের পর আপনার স্কোর পরিবর্তিত হওয়ার বেশ কিছু কারণ থাকতে পারে, তবে ওয়ার্ম ক্যাশ লোডের সংখ্যা কমে যাওয়াও এই পরিবর্তনের একটি কারণ হতে পারে।
এটি যাচাই করার একটি সহজ উপায় হলো, আপনার ল্যান্ডিং পেজগুলোর একটির MPA এবং SPA উভয় সংস্করণই Lighthouse দিয়ে পরীক্ষা করে দেখা। যদি SPA সংস্করণটির ক্ষেত্রে Core Web Vitals মেট্রিকগুলোর কোনোটিতে Lighthouse স্কোর কম হয়, তাহলে সম্ভবত আপডেটের পর লোড হওয়ার অভিজ্ঞতা সত্যিই খারাপ হয়ে গেছে।
কোর ওয়েব ভাইটালস-এ ভালো স্কোর করার জন্য আমার সাইটটিকে কি SPA থেকে MPA-তে পরিবর্তন করা উচিত?
সম্ভবত না। আপনার এসপিএ স্ট্যাক নিয়ে যদি আপনি সন্তুষ্ট না হন এবং এমপিএ আরও ভালো ইউজার এক্সপেরিয়েন্স দেবে বলে বিশ্বাস করার মতো কারণ থাকে, তবেই আপনার এসপিএ থেকে এমপিএ-তে পরিবর্তন করা উচিত।
সফট নেভিগেশনের কাজের মাধ্যমে আমরা পরিমাপ সংক্রান্ত সমস্যাগুলোর সমাধান করতে পেরেছি বলে মনে করি, তাই শুধুমাত্র এই কারণে স্থান পরিবর্তন করার কোনো মানে হয় না।
তবে, যদি আপনার কাছে দেখানোর মতো কারণ থাকে যে শুধু পরিমাপের উন্নতিই নয়, বরং কর্মক্ষমতারও উন্নতি হবে, তাহলে এসপিএ থেকে এমপিএ-তে (বা এর বিপরীতক্রমে!) যাওয়ার একটি কারণ থাকতে পারে।
যদি Core Web Vitals স্কোর শুধুমাত্র একটি SPA-এর ল্যান্ডিং পেজগুলোর জন্যই রিপোর্ট করা হয়, তাহলে রাউট ট্রানজিশনের পরের 'পেজগুলোতে' যে সমস্যাগুলো হয়, সেগুলো আমি কীভাবে ডিবাগ করব?
গুগলের যে টুলগুলো কোর ওয়েব ভাইটালস মেট্রিকের জন্য ফিল্ড ডেটা রিপোর্ট করে (যেমন সার্চ কনসোল এবং পেজস্পিড ইনসাইটস), সেগুলো তাদের ডেটা ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্ট (CrUX) থেকে সংগ্রহ করে। এবং CrUX ডেটা একত্রিত করে হয় উৎস অনুসারে অথবা পেজ ইউআরএল অনুসারে (অর্থাৎ, পেজ লোড হওয়ার সময়কার ইউআরএল)।
আমরা CrUX-কে তার একত্রিত ডেটাতে SPA রুট অনুযায়ী ডেটা অন্তর্ভুক্ত করার সুযোগ দেওয়ার জন্য কাজ করছি। তবে, একজন সাইট মালিক হিসেবে, আপনার স্কোর কীভাবে পরিবর্তিত হতে পারে তা বোঝার জন্য আপনি এখন এর আগেই নতুন API ব্যবহার করে SPA রুট অনুযায়ী Core Web Vitals পরিমাপ করতে পারেন।
এই বিষয়ে আরও বিস্তারিত তথ্য এবং সর্বোত্তম অনুশীলনের জন্য দেখুন: সফট নেভিগেশন পরিমাপ ।
এসপিএ-এর তুলনায় এমপিএ-রা যাতে কোনো অন্যায্য সুবিধা না পায়, তা নিশ্চিত করতে গুগল কী করছে?
পূর্বে যেমন উল্লেখ করা হয়েছে, সফট নেভিগেশনের কাজের ফলে আমরা বিশ্বাস করি যে, আমাদের গৃহীত পদক্ষেপের কারণে এই ক্ষেত্রে এসপিএ-গুলোর কোনো অসুবিধা হওয়ার কথা নয়, যদিও সমস্ত টুলিং এবং রিপোর্টিং সলিউশন জুড়ে সম্পূর্ণ ইন্টিগ্রেশন হতে সময় লাগবে।
ভিন্ন উৎস থেকে এবং একই উৎস থেকে করা পেজ ভিজিট আলাদাভাবে মূল্যায়ন করুন।
বর্তমানে কোর ওয়েব ভাইটালস মেট্রিক্স সমস্ত পেজ ভিজিটকে একটি একক বিভাগে একত্রিত করে—এগুলো নতুন বনাম পুরাতন ভিজিট, ল্যান্ডিং পেজ বনাম চেকআউট পেজ, কিংবা এমন কোনো একত্রীকরণ পদ্ধতির মধ্যে পার্থক্য করে না যেখানে ক্যাশে স্টেট পারফরম্যান্সের উপর প্রভাব ফেলতে পারে।
SPA এবং MPA পারফরম্যান্সের মধ্যকার পার্থক্যকে স্বাভাবিক করার একটি উপায় হতে পারে বিভিন্ন ধরনের ভিজিটের ক্ষেত্রে ভিন্ন ভিন্ন গুরুত্ব আরোপ করা, এমনকি সম্পূর্ণ ভিন্ন থ্রেশহোল্ড সুপারিশও ব্যবহার করা যেতে পারে।
যদিও আমরা কার্যকর ক্যাশে বাস্তবায়নকে পুরস্কৃত করতে চাই, আমরা চাই না যে সাইটের ভেতরের দ্রুত নেভিগেশন ধীরগতির ল্যান্ডিং পেজ লোডের ঘাটতি পূরণ করে ফেলুক। আমরা এটাও চাই না যে, শুধুমাত্র মেট্রিক স্কোর উন্নত করার জন্য সাইটগুলো দীর্ঘ পেজগুলোকে ভেঙে কয়েকটি ছোট পেজে পরিণত করতে উৎসাহিত হোক।
বিভিন্ন উৎস থেকে এবং একই উৎস থেকে করা পেজ ভিজিট আলাদাভাবে মূল্যায়ন করার মাধ্যমে আমরা এটা নিশ্চিত করতে পারি যে উভয় ধরনের অভিজ্ঞতাই গুরুত্বপূর্ণ, এবং একই সাথে কোনো নির্দিষ্ট সাইটে এক ধরনের অভিজ্ঞতার আপেক্ষিক জনপ্রিয়তা যেন কোনো বিশেষ মেট্রিকের বণ্টনকে প্রভাবিত না করে।
শেষ কথা
গুগল ওয়েব ভাইটালস মেট্রিক্স উন্নত করতে এবং ব্যবহারকারীদের জন্য গুরুত্বপূর্ণ উচ্চ-মানের অভিজ্ঞতা পরিমাপ ও উৎসাহিত করা নিশ্চিত করতে গভীরভাবে প্রতিশ্রুতিবদ্ধ। তা সত্ত্বেও, আমরা স্বীকার করি যে বর্তমানে পরিমাপে কিছু ঘাটতি রয়েছে। মেট্রিক্সগুলো এখন এসপিএ (SPA) রুট ট্রানজিশন অন্তর্ভুক্ত করতে সক্ষম, যা প্রধান ঘাটতিগুলোর মধ্যে একটির সমাধান করে।
আমরা আরও বিশ্বাস করি যে এই নতুন এপিআইগুলির (বিশেষ করে InteractionContentfulPaint ) সফট নেভিগেশনের জন্য কোর ওয়েব ভাইটালস পরিমাপের বাইরেও আরও ব্যবহার এবং সম্ভাব্য সুবিধা রয়েছে। যেহেতু এগুলি প্রবর্তনের মূল কারণটির সমাধান করা হয়েছে, আমরা এখন এগুলির উপর ভিত্তি করে কাজ চালিয়ে যেতে অত্যন্ত আগ্রহী।
আমি আশা করি এই পোস্টটি এই জটিল এবং সূক্ষ্ম বিষয়টির উপর কিছুটা আলোকপাত করতে সাহায্য করেছে। বরাবরের মতো, বর্তমান বা ভবিষ্যৎ ওয়েব ভাইটালস মেট্রিক্স সম্পর্কে আপনার কোনো মতামত থাকলে web-vitals-feedback@googlegroups.com- এ ইমেল করুন।