মেট্রিক্স

প্রকাশিত: ২৩ জুন, ২০২২, সর্বশেষ আপডেট: ১৩ অক্টোবর, ২০২৬

CrUX-এ মেট্রিক ব্রাউজার দ্বারা প্রকাশিত স্ট্যান্ডার্ড ওয়েব প্ল্যাটফর্ম API দ্বারা পরিচালিত হয়। বিশেষ করে BigQuery ডেটাসেটে, এই ডেটা অরিজিন-রেজোলিউশনে অ্যাগ্রিগেট করা হয়। সাইটের মালিকদের যদি আরও বিস্তারিত (যেমন, URL-লেভেল রেজোলিউশন) বিশ্লেষণ এবং তাদের সাইটের পারফর্ম্যান্সের ইনসাইট প্রয়োজন হয়, তাহলে তারা একই API ব্যবহার করে তাদের নিজস্ব অরিজিনের জন্য বিস্তারিত রিয়েল ইউজার মেজারমেন্ট (RUM) ডেটা সংগ্রহ করতে পারেন। মনে রাখবেন, Chrome-এ সব API উপলভ্য থাকলেও, অন্যান্য ব্রাউজারে সম্পূর্ণ মেট্রিক সেট কাজ নাও করতে পারে।

বেশিরভাগ মেট্রিককে হিস্টোগ্রাম অ্যাগ্রিগেশন হিসেবে দেখানো হয়, এর ফলে ডিস্ট্রিবিউশন ও পার্সেন্টাইল ভ্যালুর আনুমানিক হিসেব ভিজ্যুয়ালাইজ করা যায়।

কিউমুলেটিভ লেআউট শিফ্ট

"Cumulative Layout Shift (CLS) হল ভিজ্যুয়াল স্থিতিশীলতা পরিমাপ করার জন্য একটি গুরুত্বপূর্ণ, ব্যবহারকারী-কেন্দ্রিক মেট্রিক কারণ এটি ব্যবহারকারীরা কত ঘন ঘন অপ্রত্যাশিত লেআউট শিফ্টের অভিজ্ঞতা পান তা পরিমাপ করতে সাহায্য করে — কম CLS নিশ্চিত করতে সাহায্য করে যে পৃষ্ঠাটি আনন্দদায়ক।"

web.dev/articles/cls

DOM কন্টেন্ট লোড হয়েছে

"স্টাইলশিট, ছবি এবং সাবফ্রেম লোডিং শেষ হওয়ার অপেক্ষা না করে যখন পৃষ্ঠার প্রাথমিক HTML ডকুমেন্ট সম্পূর্ণভাবে লোড এবং পার্স করা হয় তখন DOMContentLoaded সেই সময় রিপোর্ট করে।"

MDN

ফার্স্ট পেন্ট

"নেভিগেশনের পরে ব্রাউজার প্রথমবার রেন্ডার করার সময় ফার্স্ট পেইন্ট রিপোর্ট করে। এর মধ্যে ডিফল্ট ব্যাকগ্রাউন্ড পেইন্ট অন্তর্ভুক্ত থাকে না, তবে নন-ডিফল্ট ব্যাকগ্রাউন্ড পেইন্ট অন্তর্ভুক্ত থাকে। পেজ লোড হওয়ার সময় ডেভেলপাররা এই প্রথম গুরুত্বপূর্ণ মুহূর্তটি নিয়ে চিন্তা করেন - যখন ব্রাউজার পেজ রেন্ডার করা শুরু করে।"

Paint Timing API

First Contentful Paint

"First Contentful Paint (FCP) সেই সময়কে রিপোর্ট করে যখন ব্রাউজার প্রথম কোনও টেক্সট, ছবি (ব্যাকগ্রাউন্ড ছবি সহ), সাদা নয় এমন ক্যানভাস বা SVG রেন্ডার করে। এর মধ্যে ওয়েবফন্ট পেন্ডিং থাকা টেক্সট অন্তর্ভুক্ত। এই প্রথমবার ব্যবহারকারীরা পৃষ্ঠার কন্টেন্ট দেখা শুরু করতে পারেন।"

Paint Timing API

Interaction to Next Paint

"Interaction to Next Paint (INP) হল একটি ফিল্ড মেট্রিক যা রেসপন্সিভনেস মূল্যায়ন করে। সম্পূর্ণ পৃষ্ঠা লাইফসাইকেল জুড়ে সমস্ত ইন্টার‍্যাকশনের লেটেন্সি INP লগ করে। সেইসব ইন্টার‍্যাকশনের সর্বোচ্চ মান—অথবা অনেক ইন্টার‍্যাকশন সহ পৃষ্ঠার জন্য সর্বোচ্চ মানের কাছাকাছি—পৃষ্ঠার INP হিসেবে রেকর্ড করা হয়। কম INP নিশ্চিত করে যে পৃষ্ঠাটি সব সময় নির্ভরযোগ্যভাবে রেসপন্সিভ হবে।"

web.dev/articles/inp

ফেব্রুয়ারি ২০২২-এ CrUX ডেটাসেটে Interaction to Next Paint (INP) যোগ করা হয়েছে। এই নতুন মেট্রিকটি স্বতন্ত্র ইভেন্টের এন্ড-টু-এন্ড লেটেন্সি ক্যাপচার করে এবং কোনও পৃষ্ঠার সামগ্রিক রেসপন্সিভনেস সম্পর্কে আরও সামগ্রিক ছবি প্রদান করে।

লার্জেস্ট কন্টেন্টফুল পেন্ট

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

web.dev/articles/lcp

Largest Contentful Paint রিসোর্সের ধরন

"ব্যবহারকারী প্রথমবার পৃষ্ঠায় নেভিগেট করার সময় থেকে ভিউপোর্টে দেখা যায় এমন সবচেয়ে বড় ছবি, টেক্সটের ব্লক বা ভিডিওর রেন্ডার করার মোট সময় সম্পর্কে LCP রিপোর্ট করে।"

web.dev/articles/lcp - LCP-এর জন্য কোন কোন এলিমেন্ট বিবেচনা করা হয়

টেক্সট ও ছবি (প্রথম ভিডিও ফ্রেমের ছবি সহ) প্রায়শই খুব আলাদা আলাদা লোডিং বৈশিষ্ট্য ও অপ্টিমাইজেশন টেকনিক থাকে। LCP রিসোর্স ধরনের অনুপাত বুঝতে পারলে, আপনি LCP মেট্রিক ও অপ্টিমাইজেশন পাথ আরও ভালোভাবে বুঝতে পারবেন।

আরও তথ্যের জন্য LCP রিসোর্সের ধরন লঞ্চ করা সংক্রান্ত ব্লগ পোস্ট দেখুন।

Largest Contentful Paint ছবির সাবপার্ট

"PageSpeed Insights-এ এই মেট্রিক কীভাবে উন্নত করা যায় সেই বিষয়ে কোনও উত্তর না পেলে, LCP-এর জন্য অপ্টিমাইজ করা আরও কঠিন হয়ে যেতে পারে। জটিল টাস্কের ক্ষেত্রে, সাধারণত সেগুলিকে ছোট, আরও ম্যানেজ করা যায় এমন টাস্কে ভাগ করা এবং প্রতিটি আলাদাভাবে সমাধান করা ভালো।"

web.dev/articles/optimize-lcp - LCP ব্রেকডাউন করে সাবপার্টে ভাগ করা

LCP ছবিকে সবচেয়ে গুরুত্বপূর্ণ উপবিভাগে ভাগ করলে, প্রতিটি বিভাগকে কীভাবে অপ্টিমাইজ করা যায় সেই বিষয়ে নির্দিষ্ট সাজেশন ও পেশাদার পদ্ধতি ব্যবহার করার সুযোগ পাওয়া যায়।

LCP ছবির সাবপার্ট চারটি আলাদা মেট্রিক্সে প্রদান করা হয়:

• largest_contentful_paint_image_time_to_first_byte
• largest_contentful_paint_image_resource_load_delay
• largest_contentful_paint_image_resource_load_duration
• largest_contentful_paint_image_element_render_delay

সাবপার্ট শুধুমাত্র ছবির জন্য অন্তর্ভুক্ত করা হয় এবং এতে প্রথম ভিডিও ফ্রেমের ছবি অন্তর্ভুক্ত করা হয় না কারণ সেগুলি একটু বেশি জটিল হয় কারণ আমরা সম্পূর্ণ ডাউনলোড করার সময় পরিমাপ করতে পারি না (মনে রাখবেন, প্রথম ভিডিও ফ্রেম LCP রিসোর্স টাইপ মেট্রিকের মধ্যে অন্তর্ভুক্ত করা হয়, যেখানে সেই জটিলতা প্রাসঙ্গিক নয়)।

টেক্সটের সাবপার্টও অন্তর্ভুক্ত করা হয় না কারণ সেগুলি কম উপযোগী এবং ছবির LCP নম্বর বিকৃত করে। যেসব সাইট মূলত টেক্সট LCP দিয়ে তৈরি, সেগুলির ক্ষেত্রে সামগ্রিক TTFB ও সামগ্রিক FCP মেট্রিক হল উপযোগী ব্রেকডাউন—তবে মনে রাখবেন যে এগুলি সব LCP-এর ক্ষেত্রে প্রযোজ্য এবং টেক্সট LCP-এর জন্য নির্দিষ্ট নয়।

আরও তথ্যের জন্য LCP ইমেজ সাবপার্ট লঞ্চ ব্লগ পোস্ট দেখুন।

নেভিগেশনের ধরন

নেভিগেশনের ধরন মেট্রিক নিম্নলিখিত নেভিগেশনের পৃষ্ঠা দেখার শতকরা হারের ব্রেকডাউন প্রদান করে:

ধরন	বিবরণ
navigate	পৃষ্ঠা লোড, যা অন্য কোনও বিভাগের মধ্যে পড়ে না।
navigate_cache	কোনও পৃষ্ঠা লোড করার সময়, প্রধান রিসোর্স (প্রধান HTML ডকুমেন্ট) HTTP ক্যাশে থেকে পরিবেশন করা হয়। সাব-রিসোর্সের জন্য সাইট প্রায়ই ক্যাশিং ব্যবহার করে, কিন্তু মূল HTML ডকুমেন্ট প্রায়ই অনেক কম ক্যাশ করা হয় এবং যখন এটি করা যায়, তখন এটি স্থানীয়ভাবে এবং CDN-এ ক্যাশ করার ফলে পারফর্ম্যান্সে লক্ষণীয় উন্নতি হতে পারে।
reload	ব্যবহারকারী রিলোড বোতামে ক্লিক করে, অ্যাড্রেস বারে এন্টার প্রেস করে অথবা বন্ধ করা ট্যাব ফিরিয়ে এনে পেজটি রিলোড করেছেন। পৃষ্ঠা আবার লোড করা হলে, মূল পৃষ্ঠাটি পরিবর্তিত হয়েছে কিনা তা চেক করার জন্য সার্ভারে আবার যাচাই করতে হয়। পেজ রিলোডের হার বেশি হলে তা ব্যবহারকারীর অভিজ্ঞতাকে খারাপ করতে পারে।
restore	ব্রাউজার রিস্টার্ট করার পরে বা মেমরি সংক্রান্ত কারণে সরিয়ে দেওয়া ট্যাব আবার লোড করা হয়েছে। Android-এর জন্য Chrome-এ এগুলি 'রিলোড' হিসেবে রিপোর্ট করা হয়।
back_forward	ইতিহাস নেভিগেশন, অর্থাৎ পৃষ্ঠাটি সম্প্রতি দেখা হয়েছে এবং আবার খোলা হয়েছে। সঠিক ক্যাশিংয়ের মাধ্যমে, এগুলি যথেষ্ট দ্রুত অভিজ্ঞতা প্রদান করতে পারে, তবে এর জন্য এখনও পৃষ্ঠা প্রসেস করা ও জাভাস্ক্রিপ্ট এক্সিকিউট করা প্রয়োজন—এই দুটি কাজই bfcache এড়িয়ে যায়।
back_forward_cache	ইতিহাস নেভিগেশন যা ব্যাক-ফরোয়ার্ড ক্যাশে থেকে দেখানো হয়েছে। ব্লকার সরিয়ে bfcache-এর সুবিধা নিতে আপনার পৃষ্ঠা অপ্টিমাইজ করলে, আরও দ্রুত অভিজ্ঞতা পাওয়া যাবে, তাই সাইটগুলি
prerender	পৃষ্ঠাটি প্রিরেন্ডার করা হয়েছে যা—bfcache-এর মতো—প্রায় সঙ্গে সঙ্গে পৃষ্ঠা লোড করতে পারে।

কিছু ক্ষেত্রে, পৃষ্ঠা লোড একাধিক ধরনের নেভিগেশনের একটি কম্বিনেশন হতে পারে। সেই ক্ষেত্রে, CrUX টেবিলের বিপরীত ক্রমে (নিচ থেকে উপরে) প্রথম ম্যাচ রিপোর্ট করে।

নেভিগেশনের ধরন সংক্রান্ত ঘোষণা পোস্টে আরও তথ্য পাওয়া যাবে।

অনলোড

"পৃষ্ঠা এবং এর উপর নির্ভরশীল রিসোর্স লোড হওয়া শেষ হলে লোড ইভেন্ট ফায়ার করা হয়।"

MDN

যাতায়াতের মোট সময়

সাম্প্রতিক নেটওয়ার্ক কানেকশনের উপর ভিত্তি করে, নেভিগেশন শুরু হওয়ার সময় HTTP (অ্যাপ্লিকেশন লেয়ার) রাউন্ড ট্রিপের সময়ের একটি অনুমান প্রদান করে। এই মেট্রিক Network Information API-এর rtt প্রপার্টির উপর ভিত্তি করে তৈরি করা হয়েছে, যা আগের কার্যকর কানেকশনের ধরন (ECT) ডাইমেনশনের জন্য দায়ী একই API।

আরও তথ্যের জন্য LCP রিসোর্স ধরনের লঞ্চ ব্লগ পোস্ট দেখুন।

এক্সপেরিমেন্টাল মেট্রিক

BigQuery ব্যবহার করে CrUX ডেটাসেট এবং CrUX API, দু'টিতেই পরীক্ষামূলক মেট্রিক উপলভ্য, তবে সব মেট্রিক দু'টিতেই উপলভ্য নয়। ব্যবহারকারীর মতামতের ভিত্তিতে এই মেট্রিকগুলি পরিবর্তন হতে পারে। লেটেস্ট পরিবর্তন সম্পর্কে আপ-টু-ডেট থাকতে রিলিজ নোট চেক করুন।

এক্সপেরিমেন্টাল সফ্ট নেভিগেশন Core Web Vitals মেট্রিক

অক্টোবর ২০২৬-এর রিলিজে সফট নেভিগেশন সহ কোর ওয়েব ভাইটাল মেট্রিকের এক্সপেরিমেন্টাল ভার্সন প্রকাশ করা হয়েছে:

• experimental_largest_contentful_paint_with_softnavs
• experimental_interaction_to_next_paint_with_softnavs
• experimental_cumulative_layout_shift_with_softnavs

এইসব মেট্রিকের মধ্যে সম্পূর্ণ পৃষ্ঠা লোড হওয়া এবং সফ্ট নেভিগেশন অন্তর্ভুক্ত।

আরও জানতে Chrome UX রিপোর্টে পরীক্ষামূলক Core Web Vitals মেট্রিক নিয়ে আসা দেখুন।

প্রথম বাইট পেতে সময়

CrUX-এ TTFB শুধুমাত্র সম্পূর্ণ পৃষ্ঠা লোড হওয়ার সময় সংগ্রহ করা হয়, অন্যান্য টাইমারের (যেমন LCP) মতো নয়, যা ব্যাক/ফরোয়ার্ড ক্যাশে (bfcache) নেভিগেশন এবং প্রিরেন্ডার করা পৃষ্ঠা থেকেও সংগ্রহ করা হয়। তাই, TTFB-এর স্যাম্পেল সাইজ অন্যান্য মেট্রিকের থেকে ছোট হতে পারে এবং সরাসরি সেগুলির সাথে তুলনা করা নাও যেতে পারে। CrUX-এ TTFB-এর মধ্যে কোল্ড পেজ লোড, ক্যাশে করা পেজ লোড এবং আগে থেকে তৈরি কানেকশন থেকে পেজ লোড (যেমন, ইন্ট্রা-সাইট পেজ লোড) অন্তর্ভুক্ত থাকবে।

TTFB হল সার্ভারের রেসপন্স টাইমের সরাসরি পরিমাপ নয়, কারণ এতে রিডাইরেক্ট টাইম সহ তার আগের পরিমাপ অন্তর্ভুক্ত থাকে এবং কোনও উত্তর ক্যাশে বা CDN বা সার্ভার থেকে পরিবেশন করা হচ্ছে কিনা তার দ্বারা প্রভাবিত হয়। এটি CrUX-এর মতো ফিল্ড ডেটার ক্ষেত্রে বিশেষভাবে স্পষ্ট, যেখানে ল্যাব টেস্টিং সাধারণত এইসব ফ্যাক্টর দ্বারা কম প্রভাবিত হয় কারণ এন্ড URL টেস্ট করা হয় এবং প্রায়শই বারবার ক্যাশিং পরিবর্তনগুলিকে বাতিল করে।

জনপ্রিয়তা

জনপ্রিয়তার র‍্যাঙ্ক মেট্রিক হল CrUX ডেটাসেটের মধ্যে সাইটের জনপ্রিয়তার তুলনামূলক পরিমাপ, যা অরিজিনে মোট নেভিগেশনের সংখ্যা দ্বারা পরিমাপ করা হয়। র‍্যাঙ্ক হল হাফ স্টেপ সহ log10 স্কেলে (যেমন, সেরা ১ হাজার, সেরা ৫ হাজার, সেরা ১০ হাজার, সেরা ৫০ হাজার, সেরা ১০০ হাজার, সেরা ৫০০ হাজার, সেরা ১০ লাখ ইত্যাদি) যেখানে প্রতিটি র‍্যাঙ্ক আগেরটিকে বাদ দেয় (যেমন, সেরা ৫ হাজার আসলে ৪ হাজার URL, সেরা ১ হাজার বাদ দিয়ে)। ডেটা সেট যত বড় হতে থাকে, সর্বোচ্চ সীমাও তত বাড়তে থাকে।

জনপ্রিয়তা সংক্রান্ত তথ্য বিস্তারিত বিশ্লেষণের জন্য গাইড হিসেবে প্রদান করা হয়, যেমন, সেরা ১,০০০টি অরিজিনের জন্য দেশ অনুযায়ী পারফর্ম্যান্স নির্ধারণ করা।

বিজ্ঞপ্তির অনুমতি

যেসব ওয়েবসাইট ব্যবহারকারীকে বিজ্ঞপ্তি দেখানোর অনুমতি চায়, তাদের ক্ষেত্রে এই মেট্রিক প্রম্পটে ব্যবহারকারীর দেওয়া উত্তরের আপেক্ষিক ফ্রিকোয়েন্সি দেখায়: গ্রহণ, প্রত্যাখ্যান, এড়িয়ে যাওয়া বা বাতিল করা।

বিজ্ঞাপন মেট্রিক্স

বিজ্ঞাপনদাতাদের মতো সাইট ও অন্যান্যদের জন্য Chrome, প্রকৃত ব্যবহারকারীদের বিজ্ঞাপনের অভিজ্ঞতা ও তার প্রভাব আরও ভালোভাবে বোঝার জন্য, সর্বজনীন মেট্রিক ও টুলিং প্রদান করে।

• বিজ্ঞাপনের সংখ্যা: এই মেট্রিক থেকে জানা যায় যে একজন সাধারণ ব্যবহারকারী সাইটে একবারে কতগুলি বিজ্ঞাপন দেখছেন।
• বিজ্ঞাপনের ঘনত্ব: এই মেট্রিক কন্টেন্ট ও বিজ্ঞাপন দৃশ্যমানতার মধ্যে একজন সাধারণ ব্যবহারকারীর ভারসাম্যকে বর্ণনা করে।
• বিজ্ঞাপনের ওজন: সিপিইউ: এই মেট্রিক বিজ্ঞাপনের মাধ্যমে সিপিইউ ব্যবহার বর্ণনা করে, যা পারফর্ম্যান্সকে প্রভাবিত করতে পারে।
• বিজ্ঞাপনের ওজন: নেটওয়ার্ক: এই মেট্রিক বিজ্ঞাপনের মাধ্যমে নেটওয়ার্ক রিসোর্স ব্যবহার করার পরিমাণ বর্ণনা করে।

আমরা আশা করি যে এই মেট্রিকগুলি বিশেষ করে ওয়েব বিজ্ঞাপনদাতাদের জন্য এবং বিজ্ঞাপন দেখানোর জন্য তারা যে পরিষেবাগুলি ব্যবহার করে তার জন্য উপযোগী হবে। বিজ্ঞাপন ইকোসিস্টেমের বিভিন্ন স্টেকহোল্ডারদের থেকে আমরা জানতে পেরেছি যে এই মেট্রিকগুলি তাদের বিজ্ঞাপনের সুযোগের মূল্যায়ন এবং বিজ্ঞাপন প্রোডাক্ট সংক্রান্ত সিদ্ধান্ত নেওয়ার ক্ষেত্রে সাহায্য করতে পারে।

আরও তথ্যের জন্য বিজ্ঞাপন মেট্রিক্স লঞ্চ ব্লগ পোস্ট এবং বিজ্ঞাপন পরিমাপ সংক্রান্ত ডকুমেন্টেশন দেখুন।