CrUX থেকে RUM ডেটা কেন আলাদা Core Web Vitals নম্বর দেখাতে পারে সেই সম্পর্কে জানুন।
প্রকাশিত: ১৫ আগস্ট, ২০২২, শেষবার আপডেট করা হয়েছে: ১৭ ডিসেম্বর, ২০২৫
Chrome User Experience Report (CrUX) থেকে ব্যবহারকারীর অভিজ্ঞতা সংক্রান্ত মেট্রিক পাওয়া যায়। এর মাধ্যমে জানা যায় যে Chrome ব্যবহারকারীরা ওয়েবে জনপ্রিয় ডেস্টিনেশনগুলি কীভাবে ব্যবহার করেন। যেসব ব্যবহারকারী সম্মতি দিয়েছেন, Chrome তাদের থেকে অটোমেটিক এই ডেটা সংগ্রহ করে এবং CrUX-এর যোগ্যতার মাপকাঠি অনুযায়ী তা উপলভ্য করা হয়।
তাই লক্ষ লক্ষ ওয়েবসাইটের জন্য CrUX ডেটা উপলভ্য। অনেক সাইটের মালিকের কাছে আগে ফিল্ড ডেটার অ্যাক্সেস ছিল না এবং CrUX অনেক সাইটকে প্রথমবারের মতো এর মূল্য দেখার সুযোগ করে দিয়েছে। পাবলিক ডেটাসেট হিসেবে, CrUX-কে প্রতিযোগিতামূলক বিশ্লেষণ এবং ব্যবহারকারীর অভিজ্ঞতা সংক্রান্ত মেট্রিক্সের বেঞ্চমার্কিংয়ের জন্যও ব্যবহার করা যেতে পারে।
রিয়েল ইউজার মনিটরিং (RUM) CrUX-এর মতোই, তবে Chrome অটোমেটিক ব্যবহারকারীর অভিজ্ঞতা সংক্রান্ত মেট্রিক সংগ্রহ করার পরিবর্তে, এই সংগ্রহ করার জন্য এবং আরও বিশ্লেষণের জন্য RUM প্রদানকারী বা অ্যানালিটিক্স সমাধানে এটি ফিড করার জন্য ওয়েবসাইটে কোড অন্তর্ভুক্ত করা হয়।
দুটি সমাধানই ব্যবহারকারীর অভিজ্ঞতা সংক্রান্ত মেট্রিক পরিমাপ করে, তাই এগুলি একই রকম হবে বলে ধরে নেওয়া স্বাভাবিক। আমরা পার্থক্য দেখলে বিভ্রান্ত হতে পারি। এই নির্দেশিকা থেকে জানতে পারবেন যে কেন এমন হতে পারে এবং সংখ্যাগুলি না মিললে কী করতে হবে সেই সম্পর্কে সাজেশন পাবেন।
RUM সলিউশনের সাথে CrUX সাপ্লিমেন্ট করার সুবিধা
CrUX হল বিভিন্ন সাইট জুড়ে একই ধরনের ভিউ দেখানোর জন্য একটি দুর্দান্ত টুল এবং—Core Web Vitals প্রোগ্রামের জন্য Google ডেটাসেট হিসেবে—সাইটগুলি সম্ভবত এটি কী দেখাচ্ছে তার উপর নজর রাখতে চাইবে। CrUX-এর লক্ষ্য হল ক্রস তুলনার জন্য লক্ষ লক্ষ ওয়েবসাইটের পরিসংখ্যানগতভাবে প্রাসঙ্গিক ওভারভিউ প্রদান করা।
তবে, ডেটা কেন এই সংখ্যা দেখাচ্ছে তা আরও গভীরভাবে তদন্ত করতে, CrUX-এর সাথে একটি সম্পূর্ণ RUM সলিউশন ব্যবহার করলে আপনি আরও বিস্তারিত তথ্য অ্যাক্সেস করতে পারবেন, যা সর্বজনীনভাবে কোয়েরি করা যায় এমন ডেটাসেটে উপলভ্য থাকে না। এটি আপনাকে বিভিন্ন উপায়ে আপনার মেট্রিক ব্যাখ্যা করতে এবং উন্নত করতে সাহায্য করতে পারে।
সমস্যা তদন্ত করার জন্য আরও গভীর বিশ্লেষণ
আপনার সাইটে কোনও সমস্যা থাকলে তা উল্লেখ করার জন্য CrUX প্রায়ই ব্যবহার করা যেতে পারে, তবে আপনার সাইটের ঠিক কোথায় সমস্যা আছে বা কেন আছে তা উল্লেখ করার জন্য নয়। RUM সলিউশন—web-vitals লাইব্রেরির মতো হোম-গ্রোন বা অনেক বাণিজ্যিক প্রোডাক্টের মধ্যে কিছু—এই ব্যবধান পূরণ করতে সাহায্য করতে পারে।
RUM সমাধান ব্যবহার করলে, আপনি সব পৃষ্ঠার জন্য এবং সব ব্রাউজারে আরও অনেক বেশি সূক্ষ্ম ডেটা অ্যাক্সেস করতে পারবেন। এছাড়াও, এটি আপনাকে CrUX-এর থেকে আলাদা উপায়ে এই ডেটা ভাগ ও বিশ্লেষণ করতে দেয়, যার ফলে আপনি সাইটের সমস্যাযুক্ত অংশগুলি আরও গভীরভাবে বিশ্লেষণ ও তদন্ত করতে পারেন। ব্যবহারকারীদের কোনও নির্দিষ্ট সেগমেন্টের দ্বারা কি তারা প্রভাবিত? অথবা নির্দিষ্ট অ্যাকশন নেওয়া ব্যবহারকারী? ঠিক কখন সমস্যাটি শুরু হয়েছিল? RUM টুলের মাধ্যমে পাওয়া অতিরিক্ত ডেটার সাহায্যে এইসব প্রশ্নের উত্তর দেওয়া অনেক সহজ হয়।
অন্যান্য ব্যবসার মেট্রিকের সাথে সম্পর্কযুক্ত
এছাড়াও, RUM আপনাকে সরাসরি যেকোনও বিজনেস মেট্রিকের সাথে আপনার ওয়েব পারফর্ম্যান্স মেট্রিক তুলনা করতে দেয়, পারফর্ম্যান্সে বিনিয়োগের মূল্য দেখায় এবং অন্য কোন পারফর্ম্যান্সের কাজকে অগ্রাধিকার দিতে হবে তা দেখায়। আমাদের কাছে এমন অনেক ব্যবসার কেস স্টাডি আছে যারা এই পারস্পরিক সম্পর্ক তৈরি করেছে, যেমন Farfetch বা The Economic Times।
পারফর্ম্যান্স সম্পর্কিত অন্যান্য ডেটা সংগ্রহ করা
RUM সলিউশন অন্যান্য কাস্টম মেট্রিক সংগ্রহ করার অনুমতি দেয়, যা সরাসরি আপনার নির্দিষ্ট ব্যবসার সাথে যুক্ত। এর একটি সুপরিচিত উদাহরণ হল Twitter-এর "প্রথম টুইট করার সময়" মেট্রিক। এই সাইট-নির্দিষ্ট পরিমাপগুলি তখন Core Web Vital-এর উন্নতি এবং ব্যবসায়িক মেট্রিক্সের সাথে সম্পর্কযুক্ত হতে পারে।
দুটি ফিল্ড ডেটা সেটের মধ্যে পার্থক্য
যার কাছে একটি ঘড়ি আছে, সে জানে কটা বাজে। যার কাছে দুটি ঘড়ি আছে, সে কখনও নিশ্চিত হতে পারে না।
সেগালের সূত্র
আপনার কাছে ডেটার দুটি সোর্স থাকলে, সেগুলি কেন আলাদা তা নিয়ে প্রায়ই বিভ্রান্তি ও হতাশা তৈরি হতে পারে। ল্যাব ও ফিল্ড মেট্রিক্সের মধ্যে পার্থক্য বোঝা যেমন গুরুত্বপূর্ণ, ঠিক তেমনই ফিল্ড ডেটার দুটি সোর্সের মধ্যেও পার্থক্য থাকতে পারে। আদর্শ পরিস্থিতিতে ডেটা একই হওয়ার কথা থাকলেও, বিভিন্ন কারণে তা আলাদা হতে পারে।
ল্যাব ডেটা বনাম ফিল্ড ডেটা
প্রথমে আপনাকে চেক করে দেখতে হবে যে আপনি ল্যাব (সিন্থেটিক) মেট্রিক নাকি ফিল্ড (RUM) মেট্রিক দেখছেন। RUM প্রোডাক্ট শুধুমাত্র ফিল্ড ডেটা দেখে বলে ধরে নেওয়া স্বাভাবিক হলেও, অনেক প্রোডাক্ট ল্যাব কম্পোনেন্টও অফার করে।
ল্যাব ডেটা অত্যন্ত উপযোগী কারণ এটি নির্দিষ্ট পরিস্থিতিতে পরিমাপ করা হয়। এটি প্রোডাকশন এনভায়রনমেন্টে অপ্রত্যাশিত পরিবর্তন বা রিগ্রেশন মনিটর করতে ব্যবহার করা যেতে পারে, যেখানে ফিল্ড পপুলেশন পরিবর্তনের কোনও প্রভাব পড়ে না। তবে, ল্যাব ডেটা আসল ব্যবহারকারীর অভিজ্ঞতাকে নাও দেখাতে পারে, তাই ফিল্ড মেট্রিক্স বেশ আলাদা ফলাফল দেখাতে পারে।
জনসংখ্যা
CrUX ও RUM সলিউশনের ব্যবহার করা ডেটাসেট আলাদা হতে পারে, কারণ কোন ব্রাউজার, ব্যবহারকারী, সাইট ও ডিভাইস তুলনা করা হচ্ছে তার উপর নির্ভর করে পৃষ্ঠা ভিজিট পরিমাপ করা হয়।
অন্তর্ভুক্ত ব্রাউজার
Chrome User Experience Report, নাম থেকেই বোঝা যায়, শুধুমাত্র Chrome-এর জন্য। Chromium-ভিত্তিক অনেক ব্রাউজার (Edge, Opera ও Brave-এর মতো আরও অনেক) Chrome কোডবেসের অনেক কিছু শেয়ার করলেও, শুধুমাত্র Chrome ব্যবহারকারীরাই CrUX-এ ডেটা ফিড করেন। এই বিধিনিষেধের অর্থ হল, iOS-এ Chrome ব্যবহারকারীরা অন্তর্ভুক্ত নন, কারণ এটি অন্তর্নিহিত Webkit ব্রাউজার ইঞ্জিন ব্যবহার করে। Android WebViews-কেও "Chrome" হিসেবে ধরা হয় না, তাই এইসব ব্যবহারকারীর ডেটা অন্তর্ভুক্ত করা হয় না—তবে Chrome কাস্টম ট্যাব অন্তর্ভুক্ত করা হয়।
Chrome হল বিশ্বের অন্যতম জনপ্রিয় ব্রাউজার—এবং তাই বেশিরভাগ ক্ষেত্রে আপনার সাইটের পারফরম্যান্সের একটি বিস্তৃত উপস্থাপনা দিতে পারে—শুধুমাত্র সেই ব্রাউজারটি পরিমাপ করা আপনার সমস্ত ব্যবহারকারীর পরিমাপ নয়। এটি RUM ও CrUX-এর মধ্যে একটি প্রধান পার্থক্য ব্যাখ্যা করতে পারে। এটি বিশেষ করে পারফর্ম্যান্স টেকনিকের ক্ষেত্রে প্রযোজ্য যা API বা ছবির ফর্ম্যাটের উপর নির্ভর করে, যেমন, শুধুমাত্র Chrome-এ উপলভ্য।
iOS ডেটার অভাবের কারণেও পক্ষপাতিত্ব হতে পারে। যেমন, iOS ব্যবহারকারীরা সাধারণত আরও বেশি পারফর্ম্যান্স করা ডিভাইস ব্যবহার করেন অথবা আরও বেশি দেশ থেকে ভিজিট করেন যেখানে আরও ভালো নেটওয়ার্ক ইনফ্রাস্ট্রাকচার আছে, তাদের অন্তর্ভুক্ত করলে সামগ্রিক পারফর্ম্যান্স মেট্রিক আরও ভালো হতে পারে। অন্যদিকে, CrUX-এর মতো এগুলি বাদ দিলে, সাইটের দর্শকদের নিম্ন সীমার দিকে ডেটা ঝুঁকে যেতে পারে (উদাহরণ কেস স্টাডি)। Android ব্যবহারকারীরা সাধারণত বিভিন্ন ধরনের ডিভাইস, ডিভাইসের ক্ষমতা এবং মার্কেট কভার করে।
RUM সলিউশন Chrome নয় এমন ব্রাউজার থেকে ডেটা পেতে পারে এবং বিশেষ করে Chromium-ভিত্তিক ব্রাউজার থেকে যা প্রায়শই একই মেট্রিক (যেমন Core Web Vitals) বিল্ট-ইন থাকে। Chromium-ভিত্তিক নয় এমন ব্রাউজারও RUM সলিউশন দ্বারা পরিমাপ করা হয়, তবে এতে আরও সীমিত সেট মেট্রিক থাকতে পারে। যেমন, Cumulative Layout Shift (CLS) শুধুমাত্র Chromium-ভিত্তিক ব্রাউজারে উপলভ্য। LCP, INP এবং এমনকি ফার্স্ট কন্টেন্টফুল পেইন্ট (FCP)-এর মতো অন্যান্য পেইন্ট-ভিত্তিক মেট্রিকগুলি বেশ ভিন্নভাবে পরিমাপ করা যেতে পারে (পরে দেখুন)।
চালু করেছেন এমন ব্যবহারকারী
Chrome ব্যবহারকারীদের মধ্যে সীমাবদ্ধ থাকার পাশাপাশি, CrUX আরও সীমাবদ্ধ কারণ এটি শুধুমাত্র Chrome ব্যবহারকারীদের একটি সাবসেট পরিমাপ করে যারা ব্রাউজার ইনস্টল করার সময় CrUX ডেটা শেয়ার করার জন্য অপ্ট-ইন করেছেন।
RUM প্রদানকারীরাও ব্যবহারকারীদের একটি সাবসেট দেখেন, সাধারণত কুকি ব্যানার প্রম্পটের কারণে—ব্যবহারকারীদের RUM ডেটা সংগ্রহে অপ্ট-ইন করতে বলা—অথবা ট্র্যাকিং ব্লকার। দ্বিতীয় বা পরবর্তী পৃষ্ঠায় কনফার্মেশন না দেওয়া হলে, এটি কিছু প্রাথমিক পৃষ্ঠা লোড করার ক্ষেত্রে বিরূপ প্রভাব ফেলতে পারে, যখন সাইটের কিছু অ্যাসেট আগের পৃষ্ঠা থেকে আগেই ক্যাশে করা হয়েছে। এটি ঘনঘন হলে, RUM-এ মেট্রিকগুলি বাস্তবে যেমন তার চেয়ে বেশি অনুকূল বলে মনে হতে পারে, যদি যথেষ্ট সংখ্যক ক্ষেত্রে ধীরগতির প্রাথমিক পৃষ্ঠা লোড বাদ দেওয়া হয়।
অন্তর্ভুক্ত সাইট
CrUX-এর উদ্দেশ্য হল শুধুমাত্র পাবলিক ওয়েবসাইটের ব্যাপারে রিপোর্ট করা, তাই অন্যান্য যোগ্যতার মাপকাঠি আছে যার ফলে CrUX-এ ডেটা লগ নাও হতে পারে। এইসব মাপকাঠির মধ্যে সবচেয়ে উল্লেখযোগ্য হল, ওয়েবসাইটটি সর্বজনীনভাবে খুঁজে পাওয়ার যোগ্য হতে হবে এবং অর্থপূর্ণ সিদ্ধান্ত নেওয়ার জন্য ন্যূনতম স্যাম্পেল সাইজ নিশ্চিত করার মতো যথেষ্ট জনপ্রিয় হতে হবে। বেশিরভাগ ক্ষেত্রে, এর ফলে CrUX-এ কোনও ডেটা উপলভ্য থাকবে না। ডেটা উপলভ্য কিন্তু আলাদা হওয়ার তুলনায় এটি কম বিভ্রান্তিকর পার্থক্য, তবে এটি কেন ঘটে তা ব্যাখ্যা করে।
তবে, কোনও সাইটের নির্দিষ্ট পৃষ্ঠা ইন্ডেক্স করার উপযুক্ত হিসেবে চিহ্নিত করা হলেও অন্যগুলি না হলে, আপনি CrUX-এ URL-এর সাবসেট দেখতে পেতে পারেন। অরিজিন সর্বজনীনভাবে খুঁজে পাওয়া গেলে, সেই অরিজিনের মধ্যে থাকা সব পৃষ্ঠা ভিউ অরিজিন-লেভেল ডেটায় অন্তর্ভুক্ত করা হবে, তবে URL-লেভেল ডেটা উপলভ্য নাও হতে পারে।
ডিভাইস
CrUX মোবাইল, ডেস্কটপ ও ট্যাবলেট অনুযায়ী ডেটা ভাগ করে - যদিও অনেক টুল প্রথম দুটির উপর ফোকাস করে এবং ট্যাবলেটের ডেটা নাও দেখাতে পারে অথবা মোবাইল বা ডেস্কটপের মধ্যে এটি অন্তর্ভুক্ত করতে পারে। মোবাইল বনাম ডেস্কটপে পারফর্ম্যান্সের বৈশিষ্ট্যগুলি বেশ আলাদা হতে পারে—ডেলিভার করা কন্টেন্ট এবং সেগুলি দেখার জন্য ডিভাইসের ক্ষমতা, দুটির ক্ষেত্রেই।
RUM ডেটা একইভাবে ট্রাফিককে ভাগ করতে দেবে, তবে প্রায়শই ডিফল্ট হিসেবে একত্রিত ডেটা দেখায়। RUM শুধুমাত্র ডিভাইসের ধরন (যেমন, মোবাইল) বা ব্রাউজার (যেমন, Chrome) অনুযায়ী ভাগ করার অনুমতি দিতে পারে, তবে শুধুমাত্র মোবাইল Chrome ট্রাফিক দেখার জন্য দুটিই নয়। CrUX ডেটার সাথে তুলনা করার সময়, ডিভাইসের ধরন এবং Chrome ব্রাউজার অনুযায়ী ফিল্টার করে আপনি একই ধরনের ডেটার সাথে তুলনা করছেন কিনা তা নিশ্চিত করুন।
স্যাম্পলিং
RUM সলিউশন সাধারণত অপ্ট-ইন করা ভিজিটরদের স্যাম্পলিং রেট অ্যাডজাস্ট করার অনুমতি দেয়, যেখানে ডেটা সংগ্রহ করা হয়। বিশ্লেষণ করার জন্য প্রয়োজনীয় ডেটার পরিমাণ কমাতে এবং বাণিজ্যিক RUM পরিষেবার খরচ কমাতে এটি ব্যবহার করা যেতে পারে। যদি সেই স্যাম্পেলের সাইজ খুব ছোট হয় এবং তা যদি বৃহত্তর জনসংখ্যার প্রতিনিধিত্ব না করে, তাহলে তার ফলে পাওয়া মেট্রিকও একইভাবে পক্ষপাতদুষ্ট হবে। আপনার সাইটের জন্য উপযুক্ত স্যাম্পেল সাইজ সম্পর্কে আপনার RUM প্রদানকারীর সাথে আলোচনা করুন।
ডেটার অ্যাগ্রিগেশন
ফিল্ড ডেটার প্রকৃতি অনুযায়ী, এতে একই মেট্রিকের অনেক ডেটা পয়েন্ট অন্তর্ভুক্ত থাকবে, যা ল্যাব ডেটার সাথে তুলনা করা হবে এবং একটি একক মান প্রদান করবে। রিপোর্টিংয়ের জন্য এই ডেটা আলাদাভাবে এগ্রিগেট করা হলে, CrUX ও RUM-এর মধ্যে পার্থক্যের আরেকটি কারণ হতে পারে।
টাইমস্প্যান
CrUX ডেটা ট্রাফিকের ২৮ দিনের স্লাইডিং উইন্ডোর উপর ভিত্তি করে তৈরি এবং এই টাইমফ্রেম পরিবর্তন করা সম্ভব নয়—যদিও CrUX BigQuery ডেটা প্রতি মাসের জন্য স্টোর করা হয়, যা আপনাকে আগের মাসগুলি দেখতে দেয় এবং CrUX History API সাপ্তাহিক সময়সীমার উপর ভিত্তি করে ঐতিহাসিক ডেটাও প্রদান করে। দুটিই এখনও ২৮ দিনের স্লাইডিং উইন্ডোর উপর ভিত্তি করে ডেটা প্রদান করে।
RUM ডেটা সাধারণত অনেক বেশি গ্র্যানুলারিটির অনুমতি দেয় যাতে পরিবর্তনের প্রভাব অনেক তাড়াতাড়ি দেখা যায়। তবে, কম সময়সীমা বেছে নিলে, ওয়েবসাইট ট্রাফিক ও ভিজিটরদের ওঠানামার কারণে RUM ডেটা অযথা প্রভাবিত হতে পারে। RUM ডেটার সাথে CrUX ডেটার তুলনা করার সময়, সবসময় নিশ্চিত করুন যে আপনি ২৮ দিনের পারফর্ম্যান্স দেখছেন। ডেটা একই রকম বলে আপনি সন্তুষ্ট হলে, RUM ডেটা আরও ভালভাবে বোঝার জন্য আপনি অন্যান্য টাইম ফ্রেম দেখতে পারেন।
পরিসংখ্যানের সমষ্টি
CrUX মেট্রিক ৭৫তম পার্সেন্টাইলে পরিমাপ করা হয়—অর্থাৎ, ৭৫% পৃষ্ঠা ভিউ যে ভ্যালু অর্জন করেছে তা দেখা হয়। ফিল্ড ডেটাতে চরম মান থাকবে এবং সবচেয়ে খারাপ ২৫% অভিজ্ঞতা সরিয়ে দিয়ে, এটি এমন একটি মান প্রদান করতে চায় যা বেশিরভাগ ভিজিটর যুক্তিসঙ্গতভাবে অর্জন করতে পারবেন বলে আশা করা যায়।
RUM প্রোডাক্টগুলি প্রায়শই ৭৫তম পার্সেন্টাইল, মিডিয়ান এবং অন্যান্য পার্সেন্টাইল সহ মেট্রিকগুলি কীভাবে একত্রিত করা যায় তার আরও বিস্তৃত বিকল্প দেয়। CrUX ডেটার সাথে RUM ভ্যালু তুলনা করার সময়, একই ধরনের ডেটা তুলনা করার জন্য আপনাকে ৭৫তম পার্সেন্টাইল ডেটা দেখতে হবে।
CrUX-এ হিস্টোগ্রাম ডেটাতে উপলভ্য সব ডেটা অন্তর্ভুক্ত থাকে—শুধু ৭৫তম শতকরা নয়—এবং প্রতিটি রেটিংয়ে পৃষ্ঠা ভিউয়ের সংখ্যা দেখায়, তবে মোট স্কোর ৭৫তম শতকরার উপর ভিত্তি করে হবে। এই CrUX ডেটা PageSpeed Insights-এর মতো টুলে দেখানো হয়:
মেট্রিকের মধ্যে পার্থক্য
ওয়েব পারফর্ম্যান্স পরিমাপ করার জন্য অনেক মেট্রিক ব্যবহার করা হয়, তাই দুটি আলাদা ডেটা সেট তুলনা করার সময়, কোন মেট্রিক পরিমাপ করা হচ্ছে এবং সেই মেট্রিক কীভাবে ব্যবহার করা হচ্ছে তা বোঝা গুরুত্বপূর্ণ।
পরিমাপ করা মেট্রিক
CrUX ডেটা হল Core Web Vitals উদ্যোগের Google ডেটাসেট এবং প্রাথমিকভাবে এই মেট্রিকগুলি (LCP, CLS এবং INP) পরিমাপ করে, এগুলির পরিপূরক হিসেবে আরও কয়েকটি অতিরিক্ত মেট্রিক আছে।
RUM টুলে সাধারণত এই Core Web Vitals অন্তর্ভুক্ত থাকে, তবে প্রায়শই অন্যান্য অনেক মেট্রিকও অন্তর্ভুক্ত থাকে। কিছু RUM প্রদানকারী, ব্যবহারকারীর অভিজ্ঞতা পরিমাপ করার জন্য, এই সব মেট্রিকের নিজস্ব কম্বিনেশন ব্যবহার করে, সম্ভবত "হ্যাপিনেস ইনডেক্স" বা এই ধরনের কিছু প্রদান করার জন্য। CrUX-এর সাথে RUM ডেটা তুলনা করার সময়, আপনি একই ধরনের ডেটা তুলনা করছেন কিনা তা নিশ্চিত করুন।
যেসব টুল Core Web Vitals-এর পাস বা ফেল স্ট্যাটাস মূল্যায়ন করে, সেগুলি কোনও পৃষ্ঠাকে তখনই পাস হিসেবে বিবেচনা করবে যখন সেটি সব Core Web Vitals-এর জন্য ৭৫তম পার্সেন্টাইলে সাজেস্ট করা টার্গেট পূরণ করবে। কোনও ইন্টার্যাকশন না হওয়া পৃষ্ঠার জন্য INP না থাকলে, শুধু LCP ও CLS পাস করতে হবে।
বিভিন্ন ব্রাউজার জুড়ে মেট্রিকের পার্থক্য
CrUX শুধুমাত্র Chrome ব্রাউজারে পরিমাপ করে এবং Chrome-এর প্রতিটি ভার্সনের সাথে এগুলি কীভাবে পরিবর্তিত হয় তা দেখতে আপনি Web Vitals Changelogs দেখতে পারেন।
তবে, RUM সমাধান আরও অনেক ধরনের ব্রাউজার থেকে পরিমাপ করবে। Chromium-ভিত্তিক ব্রাউজার (Edge, Opera ইত্যাদি) Chrome-এর মতোই হবে, তবে Chrome যদি Changelog-এ উল্লেখ করা নতুন পরিবর্তনগুলি প্রয়োগ করে, তাহলে তা আলাদা হতে পারে।
Chromium-ভিত্তিক নয় এমন ব্রাউজারের ক্ষেত্রে, পার্থক্য আরও বেশি স্পষ্ট হতে পারে। উদাহরণস্বরূপ, LCP, INP এবং FCP-এর মতো পেইন্ট-ভিত্তিক মেট্রিক Safari এবং Firefox-এ উপলভ্য, কিন্তু অন্যভাবে পরিমাপ করা হয়। এর ফলে, রিপোর্ট করা সময়ে উল্লেখযোগ্য পার্থক্য দেখা যেতে পারে। আগে যেমন বলা হয়েছে, আপনি যদি RUM-এর সাথে CrUX-এর তুলনা করতে চান, তাহলে Chrome ব্যবহারকারীদের ডেটা ফিল্টার করে নিলে একই ধরনের ডেটার মধ্যে তুলনা করা সহজ হবে।
মেট্রিক্স টাইমিং
Core Web Vitals মেট্রিক ওয়েব ব্রাউজার API-এর মাধ্যমে প্রদান করা হয়, তবে এর অর্থ এই নয় যে এগুলি ব্যবহার করে রিপোর্ট করা ভ্যালুর মধ্যে কোনও পার্থক্য থাকবে না। ঠিক কখন মেট্রিক পরিমাপ করা হচ্ছে—পৃষ্ঠা লোড হওয়ার সময় নাকি সম্পূর্ণ পৃষ্ঠা লাইফ সাইকেল জুড়ে—তার উপর ভিত্তি করে পার্থক্য হতে পারে। RUM টুল সবসময় একই পদ্ধতিতে মেট্রিক পরিমাপ নাও করতে পারে—এমনকি একই নাম ব্যবহার করলেও—এবং ডেটা পাওয়ার জন্য একই ব্রাউজার API ব্যবহার করলেও, যা বিভ্রান্তিকর হতে পারে।
Largest Contentful Paint (LCP) হল পেজ লোড সংক্রান্ত মেট্রিক। প্রাথমিক রেন্ডারের পরে বড় এলিমেন্ট লোড হলে, Web API-এর মাধ্যমে একাধিক LCP এলিমেন্ট রিপোর্ট করা হতে পারে। পৃষ্ঠা লোড হওয়া শেষ হলে বা ব্যবহারকারী পৃষ্ঠার সাথে ইন্টার্যাক্ট করলে, ফাইনাল LCP এলিমেন্ট দেখা যায়। তাই, এই দুটি ইভেন্টের আগে LCP এলিমেন্ট রিপোর্ট করা হলে পার্থক্য দেখা দিতে পারে।
এছাড়াও, ফিল্ড ডেটাতে, পৃষ্ঠা কীভাবে লোড করা হয়েছে তার উপর নির্ভর করে LCP এলিমেন্ট আলাদা হতে পারে। পৃষ্ঠার কন্টেন্টের উপরের অংশ দেখানোর জন্য ডিফল্ট পৃষ্ঠা লোডের ক্ষেত্রে, LCP এলিমেন্ট মূলত স্ক্রিনের সাইজের উপর নির্ভর করবে। তবে, ডকুমেন্টের আরও নিচের দিকে থাকা কোনও অ্যাঙ্কর লিঙ্কের মাধ্যমে পৃষ্ঠাটি খোলা হলে অথবা একইভাবে কোনও সিঙ্গেল পেজ অ্যাপে (SPA)—এই বিষয়ে পরে আরও আলোচনা করা হবে—ডিপ-লিঙ্কের মাধ্যমে খোলা হলে, LCP এলিমেন্ট আলাদা হতে পারে।
CrUX বা RUM-এ দেওয়া LCP টাইমিং ল্যাব টুলের মতো একই এলিমেন্টের উপর ভিত্তি করে তৈরি বলে ধরে নেবেন না। CrUX আপনাকে পৃষ্ঠা বা অরিজিন প্রতি সামগ্রিক LCP ভ্যালু প্রদান করবে, RUM এটিকে আরও ভাগ করতে পারে যাতে স্বতন্ত্র LCP সমস্যা সেশন শনাক্ত করা যায়।
Cumulative Layout Shift (CLS) পৃষ্ঠার লাইফটাইম জুড়ে পরিমাপ করা হয়, তাই প্রাথমিক পৃষ্ঠা-লোড CLS এমন পৃষ্ঠার প্রতিনিধিত্ব নাও করতে পারে যা পৃষ্ঠা লোড হওয়ার পরে এবং ব্যবহারকারী এটির সাথে ইন্টার্যাক্ট করার পরে আরও বেশি শিফ্ট ঘটায়। তাই, পৃষ্ঠা লোড হওয়ার পরে CLS ভ্যালু নিলে—যেমন অনেক RUM প্রোডাক্ট করে—ব্যবহারকারী পৃষ্ঠা ব্যবহার করা শেষ করার পরে CLS ভ্যালু নেওয়ার থেকে আলাদা ফলাফল পাওয়া যাবে।
Interaction to Next Paint (INP) রেসপন্সিভনেস মেট্রিক পরিমাপ করার জন্য ইনপুট প্রয়োজন এবং CLS-এর মতো একই পদ্ধতিতে পৃষ্ঠার লাইফটাইম জুড়ে সমস্ত ক্লিক, ট্যাপ ও কীবোর্ড ইন্টার্যাকশন পর্যবেক্ষণ করে। তাই, ব্যবহারকারী পৃষ্ঠায় একাধিক ইন্টার্যাকশন করার পরে পরিমাপ করা হলে, INP-এর রিপোর্ট করা ভ্যালু খুব আলাদা হতে পারে।
CrUX Core Web Vitals ডকুমেন্টেশন অনুসরণ করবে এবং পৃষ্ঠার সম্পূর্ণ লাইফটাইম জুড়ে এগুলি পরিমাপ করবে। অনেক RUM প্রোভাইডার বিভিন্ন কারণে পৃষ্ঠা লোড হওয়ার পরে বা অন্য কোনও সময়ে (যেমন, কোনও গুরুত্বপূর্ণ কল-টু-অ্যাকশনে ক্লিক করা হলে) এইসব মেট্রিক পরিমাপ করার সিদ্ধান্ত নেন।
দুটি ডেটা সোর্সের মধ্যে ব্যাখ্যাতীত পার্থক্য দেখার সময়, Core Web Vitals কখন পরিমাপ করা হয় সে সম্পর্কে আপনার RUM প্রদানকারীর কাছ থেকে একটি ধারণা পাওয়া গুরুত্বপূর্ণ।
সিঙ্গেল-পেজ অ্যাপ্লিকেশন
সিঙ্গেল-পেজ অ্যাপ্লিকেশন (SPA) ব্রাউজার লেভেলে প্রকৃত পৃষ্ঠা নেভিগেশন করার পরিবর্তে বর্তমান পৃষ্ঠার কন্টেন্ট আপডেট করার মাধ্যমে কাজ করে। এর অর্থ হল, ব্যবহারকারীরা পৃষ্ঠা নেভিগেশন হিসেবে এগুলি অনুভব করলেও, ব্রাউজার এগুলিকে পৃষ্ঠা নেভিগেশন হিসেবে দেখে না। ব্রাউজারের মাধ্যমে প্রদান করা Core Web Vitals API এগুলি বিবেচনা করবে না এবং তাই CrUX এইসব পৃষ্ঠা নেভিগেশনকে সাপোর্ট করে না। এই সমস্যার সমাধান করার জন্য কাজ চলছে—আরও তথ্যের জন্য সফ্ট নেভিগেশন পরিমাপ করা পোস্টটি দেখুন।
কিছু RUM পরিষেবা প্রদানকারী SPA-তে "সফ্ট নেভিগেশন" শনাক্ত করার চেষ্টা করে, তবে তারা যদি সেই "সফ্ট নেভিগেশন"-এ Core Web Vitals মেট্রিকও অ্যাট্রিবিউট করে, তাহলে CrUX-এর সাথে পার্থক্য দেখা যাবে কারণ অন্তর্নিহিত API অনেক মেট্রিকের জন্য এটি সমর্থন করে না।
CrUX এবং Web API-এর মধ্যে পার্থক্য
কোন পৃষ্ঠা ভিউ পরিমাপ করা হয় এবং কী পরিমাপ করা হয়, তার মধ্যে পার্থক্যের পাশাপাশি আরও কিছু জটিল পরিস্থিতি সম্পর্কে সচেতন থাকতে হবে, যার ফলে CrUX ও RUM ডেটার মধ্যে পার্থক্য হতে পারে। এর মধ্যে কিছু মেট্রিক পরিমাপ করার জন্য ব্যবহৃত ওয়েব API-এর সীমাবদ্ধতার কারণে এবং কিছু ক্ষেত্রে নির্দিষ্ট পরিস্থিতির জন্য API দ্বারা রিটার্ন করা ফলাফল আলাদাভাবে বিবেচনা করতে হয়। Core Web Vitals-এর ডকুমেন্টেশনে LCP ও CLS-এর জন্য এইসব পার্থক্য তালিকাভুক্ত করা আছে, তবে প্রধান পার্থক্যগুলি নিম্নলিখিত বিভাগেও উল্লেখ করা আছে।
ব্যাক/ফরোয়ার্ড ক্যাশে
CrUX ব্যাক/ফরোয়ার্ড ক্যাশে (বা bfcache) রিস্টোরকে পৃষ্ঠা নেভিগেশন হিসেবে বিবেচনা করে, যদিও এর ফলে প্রচলিত পৃষ্ঠা লোড হয় না। যেহেতু ওয়েব API এগুলিকে পৃষ্ঠা লোড হিসেবে বিবেচনা করে না, তাই CrUX-এর সাথে ম্যাচ করতে চাইলে, এই পৃষ্ঠাগুলি গণনা করার জন্য RUM সমাধানগুলিকে অতিরিক্ত পদক্ষেপ নিতে হবে। এগুলি হল উল্লেখযোগ্যভাবে দ্রুত পেজ লোড যা কোনও সাইটের জন্য রিপোর্ট করা সামগ্রিক আরও ভালো পারফর্ম্যান্সের ফল হতে পারে, তাই সেগুলি অন্তর্ভুক্ত না করলে সামগ্রিক পেজ পারফর্ম্যান্স মেট্রিক আরও খারাপ হতে পারে। আপনার RUM সলিউশন bfcache রিস্টোর করা পৃষ্ঠা ম্যানেজ করে কিনা তা বুঝতে, RUM সলিউশন দেখুন।
iframe
নিরাপত্তা ও গোপনীয়তার কারণে, টপ-লেভেল পৃষ্ঠার কাছে iframe-এর মধ্যে থাকা কন্টেন্টের অ্যাক্সেস থাকে না (এমনকি একই-উৎসের iframe-এর ক্ষেত্রেও নয়)। এর অর্থ হল, iframe-এর মধ্যে থাকা কন্টেন্টের পারফর্ম্যান্স মেট্রিক শুধুমাত্র iframe-এর মাধ্যমেই পরিমাপ করা যাবে, ফ্রেমিং পৃষ্ঠার Web API-এর মাধ্যমে নয়। iframe কন্টেন্টে LCP এলিমেন্ট বা এমন কন্টেন্ট থাকলে যা ব্যবহারকারীর CLS বা INP অভিজ্ঞতাকে প্রভাবিত করে, তাহলে এটি RUM সলিউশনে (Google web-vitals JavaScript লাইব্রেরি সহ) উপলভ্য হবে না।
তবে, CrUX পৃষ্ঠায় জাভাস্ক্রিপ্টের পরিবর্তে Chrome ব্রাউজার নিজেই পরিমাপ করে, তাই এই সীমাবদ্ধতাগুলি নেই এবং তাই Core Web Vitals রিপোর্ট করার সময় iframe-এর মধ্যে মেট্রিক পরিমাপ করে। এটি ব্যবহারকারীর অভিজ্ঞতাকে আরও সঠিকভাবে প্রতিফলিত করে, তবে iframe ব্যবহার করা সাইটের ক্ষেত্রে পার্থক্যের আরেকটি কারণ হতে পারে।
CrUX এবং RUM-এ LCP ডেটার মধ্যে কীভাবে পার্থক্য হতে পারে তার একটি উদাহরণ হল এম্বেড করা <video>। একটি playsinline অটোপ্লেয়িং <video> এলিমেন্টের প্রথম পেইন্ট করা ফ্রেমকে LCP ক্যান্ডিডেট হিসেবে গণ্য করা যেতে পারে, তবে জনপ্রিয় ভিডিও স্ট্রিমিং পরিষেবার জন্য এম্বেড করা কন্টেন্ট এইসব এলিমেন্টকে <iframe>-এ রাখতে পারে। CrUX এটি করতে পারে, কারণ এটি <iframe> কন্টেন্ট অ্যাক্সেস করতে পারে, কিন্তু RUM সমাধান তা পারে না।
ক্রস-অরিজিন রিসোর্স
অন্য ডোমেন থেকে পরিবেশিত LCP মিডিয়া PerformanceObserver API-তে রেন্ডার করার মোট সময় নাও দিতে পারে—যদি না Timing-Allow-Origin header (TAO) প্রদান করা হয়—টাইমিং অ্যাটাক কমানোর জন্য ব্রাউজার নিরাপত্তা বিধিনিষেধের কারণে। এটি রিসোর্স লোড হওয়ার সময়ের উপর নির্ভর করে, তবে কন্টেন্টটি আসলে কখন আঁকা হয়েছিল তার থেকে এটি বেশ আলাদা হতে পারে।
এর ফলে এমন এক অসম্ভব পরিস্থিতি তৈরি হতে পারে যেখানে ওয়েব API-এর মাধ্যমে FCP-এর আগে LCP রিপোর্ট করা হয়। এটি আসলে তা নয়, তবে এই নিরাপত্তা সংক্রান্ত বিধিনিষেধের কারণে এমনটি মনে হয়।
এটি ২০২৪ সালের শেষের দিকে সমাধান করা হয়েছে এবং Timing-Allow-Origin প্রদান না করা হলেও Chrome 133 থেকে কিছুটা কম রেজোলিউশনের রেন্ডার করার মোট সময় উপলভ্য।
আবার, CrUX, Core Web Vitals-এর জন্য রেন্ডার করার মোট সময় সংক্রান্ত ডেটা রিপোর্ট করে। সাইটগুলিকে ক্রস-অরিজিন কন্টেন্ট সীমিত করার পরামর্শ দেওয়া হয় যা Core Web Vitals মেট্রিক্সকে প্রভাবিত করে এবং আরও সঠিকভাবে পরিমাপ করতে চাইলে যেখানে সম্ভব TAO চালু করতে বলা হয়। অন্যান্য ক্রস-অরিজিন রিসোর্সের ক্ষেত্রেও একই ধরনের বিধিনিষেধ প্রযোজ্য হতে পারে।
ব্যাকগ্রাউন্ড ট্যাব
কোনও পৃষ্ঠা ব্যাকগ্রাউন্ড ট্যাবে খোলা না থাকলেও, এটি Web API ব্যবহার করে মেট্রিক্স নির্গত করবে। তবে, CrUX এগুলি রিপোর্ট করে না কারণ এগুলি এমন সময় দেয় যা ব্যবহারকারীর অভিজ্ঞতার সাথে সামঞ্জস্যপূর্ণ নয়। RUM সলিউশনের ক্ষেত্রেও এগুলি উপেক্ষা করা উচিত অথবা অন্ততপক্ষে এই পৃষ্ঠা ভিউ কীভাবে বিবেচনা করা হয় তা ব্যাখ্যা করা উচিত।
তাহলে, এই ব্যাপারে আমরা কী করতে পারি?
CrUX ও RUM ডেটার মধ্যে কেন পার্থক্য থাকতে পারে তা আমরা দেখিয়েছি, হয় প্রতিটি ডেটা যে পদ্ধতি ব্যবহার করে তার পার্থক্যের কারণে অথবা কোন ব্যবহারকারী ও পৃষ্ঠা ভিউ অন্তর্ভুক্ত বা বাদ দেওয়া হয়েছে তার কারণে। আদর্শগতভাবে, ডেটার দুটি সেটই আপনার সাইটের পারফর্ম্যান্সের প্রতিনিধিত্ব করবে যাতে তা উপযোগী হয়, তবে প্রদত্ত কারণগুলি থেকে বোঝা যাবে যে কেন প্রতিটি ক্ষেত্রে হুবহু একই সংখ্যা পাওয়ার সম্ভাবনা খুবই কম।
যেখানে পার্থক্য সামান্য (যেমন, ২.০ সেকেন্ড বনাম ২.২ সেকেন্ডের LCP রিপোর্ট করা) সেখানে দুটি ডেটাসেটই উপযোগী হবে এবং সাধারণত সিঙ্ক করা আছে বলে বিবেচনা করা যেতে পারে।
ডেটার যথার্থতা নিয়ে আপনার মনে প্রশ্ন জাগলে, আপনি সেই পার্থক্যগুলি বোঝার চেষ্টা করতে পারেন। এই পার্থক্যগুলি কমাতে, CrUX-এর সাথে আরও ঘনিষ্ঠভাবে অ্যালাইন করার জন্য RUM ডেটা কি ফিল্টার করা যেতে পারে (শুধুমাত্র Chrome ব্যবহারকারীদের জন্য, ডেস্কটপ বা মোবাইলের জন্য, ২৮ দিন ধরে ৭৫তম পার্সেন্টাইল মান সহ)?
যদি তাই হয়—এবং আপনি আরও কাছাকাছি ডেটা পান—তাহলে আপনাকে এখনও জিজ্ঞাসা করতে হবে যে আপনি কেন সামগ্রিক ডেটাতে এই পার্থক্যগুলি দেখছেন এবং এর অর্থ কী। Chrome ব্যবহার করেন না এমন ব্যবহারকারীরা কি আপনার মেট্রিককে ইতিবাচক বা নেতিবাচকভাবে প্রভাবিত করছেন? এটি কি আপনাকে পারফর্ম্যান্স সংক্রান্ত সমস্যা সম্পর্কে আরও ইনসাইট দেয়, যাতে আপনি অগ্রাধিকার দিতে পারেন?
আপনার নন-Chrome ব্যবহারকারীরা যদি আলাদা ফলাফল পান, তাহলে আপনি RUM-এর দেওয়া এই মূল্যবান ইনসাইট ব্যবহার করে আলাদাভাবে অপ্টিমাইজ করতে পারেন। যেমন, নির্দিষ্ট কিছু API নির্দিষ্ট কিছু ব্রাউজারে উপলভ্য নয়, তবে আপনি কাজ করে না এমন ব্রাউজারের জন্য বিকল্পের কথা বিবেচনা করতে পারেন যাতে তাদের অভিজ্ঞতাও উন্নত করা যায়। অথবা আপনি সীমাবদ্ধ ডিভাইস বা নেটওয়ার্কে ব্যবহারকারীদের একটি ভিন্ন, কিন্তু আরও পারফর্ম্যান্ট, অভিজ্ঞতা দিতে পারেন। CrUX-এর ডেটা Chrome-এর মধ্যেই সীমাবদ্ধ, তবে উন্নতির ক্ষেত্রে অগ্রাধিকার দিতে আপনার সাইটের সব ভিজিটরের অভিজ্ঞতা বিবেচনা করা উচিত। RUM ডেটা সেই ফাঁক পূরণ করতে পারে।
আপনি একবার কোনও পার্থক্যের কারণ বুঝতে পারলে, আপনার ওয়েবসাইটের ব্যবহারকারীর অভিজ্ঞতা বোঝার জন্য এবং সংখ্যাগুলি অভিন্ন না হলেও এটিকে উন্নত করতে সাহায্য করার জন্য উভয় টুলই অবিশ্বাস্যভাবে কার্যকর হতে পারে। CrUX ডেটার সাথে আপনার RUM ডেটা ব্যবহার করুন এবং CrUX আপনাকে উচ্চ স্তরে যা বলছে তা গভীরভাবে বিশ্লেষণ করুন। আপনার ট্রাফিককে ভাগ করে, আপনি আপনার সাইটের নির্দিষ্ট এলাকা বা ব্যবহারকারীর ভিত্তি চিহ্নিত করতে পারেন যার প্রতি মনোযোগ প্রয়োজন।
দুটি ডেটা সোর্সের মধ্যে প্রতিটি সংখ্যা হুবহু মেলানোর চেয়ে, আপনার করা উন্নতির ফলে প্রত্যাশিত ইতিবাচক প্রভাব পড়ছে কিনা তা দেখার জন্য ট্রেন্ডের দিকে নজর দেওয়া প্রায়শই বেশি গুরুত্বপূর্ণ। আগে যেমন উল্লেখ করা হয়েছে, RUM আপনাকে বিভিন্ন সময়সীমা দেখার সুযোগ করে দেয় যাতে আপনি ২৮ দিনের CrUX স্কোর কেমন হবে তা আগে থেকেই দেখতে পান—যদিও খুব ছোট সময়সীমা দেখলে ডেটা অস্পষ্ট হতে পারে, তাই CrUX ২৮ দিন ব্যবহার করে।
প্রায়ই এইসব বিভিন্ন মেট্রিক্সের ক্ষেত্রে কোনও "ঠিক" বা "ভুল" উত্তর হয় না - এগুলি আপনার ব্যবহারকারীদের এবং তারা আপনার সাইট কীভাবে ব্যবহার করছেন তা দেখার জন্য একটি ভিন্ন দৃষ্টিভঙ্গি মাত্র। এই পার্থক্যগুলি কেন ঘটে এবং আপনার সিদ্ধান্ত গ্রহণের ক্ষেত্রে সেগুলি কী ভূমিকা পালন করে তা বুঝতে পারলে, আপনার সাইটের দর্শকদের আরও ভাল পরিষেবা প্রদান করতে পারবেন।