প্রকাশিত: ২৩ জুন, ২০২২, সর্বশেষ হালনাগাদ: ১৮ নভেম্বর, ২০২৫
CrUX-এর মেট্রিকগুলো ব্রাউজার দ্বারা উন্মুক্ত করা স্ট্যান্ডার্ড ওয়েব প্ল্যাটফর্ম API-এর মাধ্যমে পরিচালিত হয়। বিশেষ করে BigQuery ডেটাসেটে, এই ডেটা অরিজিন-রেজোলিউশন অনুযায়ী একত্রিত করা হয়। সাইটের মালিকরা, যাদের তাদের সাইটের পারফরম্যান্স সম্পর্কে আরও বিস্তারিত (যেমন URL-স্তরের রেজোলিউশন) বিশ্লেষণ এবং অন্তর্দৃষ্টি প্রয়োজন, তারা তাদের নিজস্ব অরিজিনের জন্য বিস্তারিত রিয়েল ইউজার মেজারমেন্ট (RUM) ডেটা সংগ্রহ করতে একই API ব্যবহার করতে পারেন। উল্লেখ্য যে, যদিও সমস্ত API ক্রোমে উপলব্ধ, অন্যান্য ব্রাউজারগুলো মেট্রিকের সম্পূর্ণ সেট সমর্থন নাও করতে পারে।
অধিকাংশ মেট্রিকই একটি হিস্টোগ্রাম সমষ্টি হিসাবে উপস্থাপন করা হয়, যা বিন্যাসটির দৃশ্যমানতা এবং শতাংশ মানগুলির আনুমানিক হিসাব করতে সাহায্য করে।
ক্রমবর্ধমান বিন্যাস পরিবর্তন
কিউমুলেটিভ লেআউট শিফট (সিএলএস) হলো ভিজ্যুয়াল স্থিতিশীলতা পরিমাপের জন্য একটি গুরুত্বপূর্ণ ও ব্যবহারকারী-কেন্দ্রিক মেট্রিক, কারণ এটি পরিমাপ করতে সাহায্য করে যে ব্যবহারকারীরা কত ঘন ঘন অপ্রত্যাশিত লেআউট পরিবর্তনের সম্মুখীন হন — একটি কম সিএলএস পৃষ্ঠাটিকে আনন্দদায়ক রাখতে সাহায্য করে।
DOM কন্টেন্ট লোড হয়েছে
DOMContentLoaded সেই সময়টি রিপোর্ট করে, যখন স্টাইলশীট, ছবি এবং সাবফ্রেম লোড হওয়ার জন্য অপেক্ষা না করে প্রাথমিক HTML ডকুমেন্টটি সম্পূর্ণরূপে লোড ও পার্স করা হয়ে যায়।
প্রথম রঙ
ফার্স্ট পেইন্ট সেই সময়টি রিপোর্ট করে যখন ন্যাভিগেশনের পর ব্রাউজারটি প্রথম রেন্ডার হয়। এতে ডিফল্ট ব্যাকগ্রাউন্ড পেইন্ট অন্তর্ভুক্ত নয়, তবে নন-ডিফল্ট ব্যাকগ্রাউন্ড পেইন্ট অন্তর্ভুক্ত থাকে। পেজ লোডের ক্ষেত্রে এটিই প্রথম গুরুত্বপূর্ণ মুহূর্ত যা ডেভেলপারদের কাছে জরুরি — যখন ব্রাউজার পেজটি রেন্ডার করা শুরু করে।
প্রথম বিষয়বস্তুপূর্ণ পেইন্ট
ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) সেই সময়টি রিপোর্ট করে যখন ব্রাউজার সর্বপ্রথম কোনো টেক্সট, ছবি (ব্যাকগ্রাউন্ড ছবি সহ), সাদা নয় এমন ক্যানভাস বা SVG রেন্ডার করে। এর মধ্যে পেন্ডিং ওয়েবফন্টযুক্ত টেক্সটও অন্তর্ভুক্ত। এই সময়েই ব্যবহারকারীরা প্রথমবারের মতো পেজের কনটেন্ট পড়া শুরু করতে পারেন।
পরবর্তী পেইন্টের সাথে মিথস্ক্রিয়া
ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) হলো একটি ফিল্ড মেট্রিক যা রেসপন্সিভনেস মূল্যায়ন করে। INP সম্পূর্ণ পেজ লাইফসাইকেল জুড়ে সমস্ত ইন্টারঅ্যাকশনের লেটেন্সি লগ করে। সেই ইন্টারঅ্যাকশনগুলোর মধ্যে সর্বোচ্চ মান—অথবা যেসব পেজে অনেক ইন্টারঅ্যাকশন থাকে সেগুলোর ক্ষেত্রে সর্বোচ্চ মানের কাছাকাছি মান—পেজটির INP হিসেবে রেকর্ড করা হয়। একটি কম INP নিশ্চিত করে যে পেজটি সব সময় নির্ভরযোগ্যভাবে রেসপন্সিভ থাকবে।
২০২২ সালের ফেব্রুয়ারিতে CrUX ডেটাসেটে ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) যুক্ত করা হয়েছিল। এই নতুন মেট্রিকটি স্বতন্ত্র ইভেন্টগুলির এন্ড-টু-এন্ড লেটেন্সি পরিমাপ করে এবং একটি পেজের জীবনকাল জুড়ে তার সামগ্রিক রেসপন্সিভনেসের একটি আরও পূর্ণাঙ্গ চিত্র প্রদান করে।
বৃহত্তম বিষয়বস্তুপূর্ণ পেইন্ট
লার্জেস্ট কনটেন্টফুল পেইন্ট (LCP) হলো অনুভূত লোড স্পিড পরিমাপের জন্য একটি গুরুত্বপূর্ণ ও ব্যবহারকারী-কেন্দ্রিক মেট্রিক, কারণ এটি পেজ লোড টাইমলাইনের সেই মুহূর্তটিকে চিহ্নিত করে যখন পেজের মূল কনটেন্ট সম্ভবত লোড হয়ে গেছে — একটি দ্রুত LCP ব্যবহারকারীকে এই আশ্বাস দেয় যে পেজটি ব্যবহারযোগ্য।
বৃহত্তম বিষয়বস্তুপূর্ণ পেইন্ট রিসোর্স টাইপ
ব্যবহারকারী যখন প্রথম পৃষ্ঠাটিতে প্রবেশ করেন, তার সাপেক্ষে LCP ভিউপোর্টে দৃশ্যমান বৃহত্তম ছবি, টেক্সট ব্লক বা ভিডিওর রেন্ডার হওয়ার সময় রিপোর্ট করে।
web.dev/articles/lcp - LCP-এর জন্য কোন উপাদানগুলো বিবেচনা করা হয়
টেক্সট এবং ইমেজের (প্রথম ভিডিও ফ্রেমের ইমেজ সহ) লোডিং বৈশিষ্ট্য এবং অপটিমাইজেশন কৌশল প্রায়শই খুব ভিন্ন হয়। LCP রিসোর্স টাইপগুলোর অনুপাত বুঝতে পারলে আপনি আপনার LCP মেট্রিক্স এবং অপটিমাইজেশন পাথওয়ে আরও ভালোভাবে বুঝতে পারবেন।
আরও তথ্যের জন্য এলসিপি রিসোর্স টাইপস লঞ্চ ব্লগ পোস্টটি দেখুন।
বৃহত্তম বিষয়বস্তুপূর্ণ পেইন্ট চিত্রের উপাংশ
যখন PageSpeed Insights এই মেট্রিকটি কীভাবে উন্নত করা যায় তার উত্তর দেয় না, তখন LCP অপ্টিমাইজ করা একটি আরও জটিল কাজ হতে পারে। জটিল কাজগুলোকে সাধারণত ছোট ছোট ও সহজে পরিচালনাযোগ্য অংশে ভাগ করে নিয়ে প্রতিটি আলাদাভাবে সমাধান করাই শ্রেয়।
web.dev/articles/optimize-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-এর জন্য নির্দিষ্ট নয়।
আরও তথ্যের জন্য এলসিপি ইমেজ সাবপার্টস লঞ্চ ব্লগ পোস্টটি দেখুন।
নেভিগেশন প্রকার
নেভিগেশন টাইপস মেট্রিকটি নিম্নলিখিত নেভিগেশনগুলির পেজ ভিউয়ের শতাংশের একটি বিশদ বিবরণ প্রদান করে:
| প্রকার | বর্ণনা |
|---|---|
navigate | এমন একটি পৃষ্ঠা লোড, যা অন্য কোনো বিভাগের অন্তর্ভুক্ত নয়। |
navigate_cache | এমন একটি পেজ লোড, যার মূল রিসোর্স (মূল HTML ডকুমেন্ট) HTTP ক্যাশে থেকে পরিবেশন করা হয়েছিল। সাইটগুলো প্রায়শই সাব-রিসোর্সগুলোর জন্য ক্যাশিং ব্যবহার করে, কিন্তু মূল HTML ডকুমেন্টটি প্রায়শই অনেক কম ক্যাশ করা হয় এবং যখন তা করা সম্ভব হয়, তখন স্থানীয়ভাবে এবং একটি CDN-এ ক্যাশ করার ক্ষমতার ফলে পারফরম্যান্সে লক্ষণীয় উন্নতি হতে পারে। |
reload | ব্যবহারকারী রিলোড বোতামে চাপ দিয়ে, অ্যাড্রেস বারে এন্টার চেপে, অথবা কোনো ট্যাব বন্ধ করার পর তা পূর্বাবস্থায় ফিরিয়ে এনে পৃষ্ঠাটি পুনরায় লোড করেছেন। মূল পৃষ্ঠাটি পরিবর্তিত হয়েছে কিনা তা যাচাই করার জন্য পৃষ্ঠা পুনরায় লোড করার ফলে প্রায়শই সার্ভারে পুনরায় যাচাইকরণ করা হয়। উচ্চ হারে পৃষ্ঠা পুনরায় লোড হওয়া ব্যবহারকারীর অভিজ্ঞতায় সৃষ্ট বিরক্তির ইঙ্গিত দিতে পারে। |
restore | ব্রাউজার রিস্টার্ট করার পর, অথবা মেমোরির কারণে কোনো ট্যাব সরিয়ে ফেলার পর পেজটি পুনরায় লোড করা হয়েছিল। অ্যান্ড্রয়েডের ক্রোমে এগুলিকে পরিবর্তে 'রিলোড' হিসাবে রিপোর্ট করা হয়। |
back_forward | হিস্ট্রি নেভিগেশন মানে হলো, পেজটি সম্প্রতি দেখা হয়েছে এবং সেখানে আবার ফিরে আসা হয়েছে। সঠিক ক্যাশিং থাকলে, এই অভিজ্ঞতাগুলো বেশ দ্রুত হওয়ার কথা, কিন্তু তারপরেও পেজটি প্রসেস করা এবং জাভাস্ক্রিপ্ট এক্সিকিউট করার প্রয়োজন হয়—যে দুটি কাজই বিএফক্যাশ (bfcache) এড়িয়ে চলে। |
back_forward_cache | একটি হিস্ট্রি নেভিগেশন যা বিএফক্যাশ (bfcache) থেকে পরিবেশিত হতো। বাধাগুলো অপসারণ করে বিএফক্যাশের সুবিধা নেওয়ার জন্য আপনার পেজগুলোকে অপ্টিমাইজ করলে দ্রুততর অভিজ্ঞতা পাওয়া যাবে, ফলে সাইটগুলো দেখতে আরও ভালো লাগবে। |
prerender | পেজটি প্রি-রেন্ডার করা হয়েছিল, যার ফলে—bfcache-এর মতোই—পেজ প্রায় সঙ্গে সঙ্গে লোড হতে পারে। |
কিছু ক্ষেত্রে, একটি পেজ লোড একাধিক নেভিগেশন ধরনের সমন্বয় হতে পারে। সেক্ষেত্রে, CrUX টেবিলের বিপরীত ক্রমে (নিচ থেকে উপরে) প্রথম মিলটি রিপোর্ট করে।
নেভিগেশন প্রকার সংক্রান্ত ঘোষণা পোস্টে আরও তথ্য পাওয়া যাবে।
অনলোড
পৃষ্ঠা এবং এর উপর নির্ভরশীল রিসোর্সগুলো লোড হওয়া শেষ হলে লোড ইভেন্টটি ফায়ার হয়।
আসা-যাওয়ার সময়
সাম্প্রতিক নেটওয়ার্ক সংযোগগুলির উপর ভিত্তি করে, নেভিগেশন শুরুর সময়ে HTTP (অ্যাপ্লিকেশন লেয়ার) রাউন্ড ট্রিপ টাইমের একটি আনুমানিক হিসাব প্রদান করে। এই মেট্রিকটি নেটওয়ার্ক ইনফরমেশন এপিআই (Network Information API)- এর rtt প্রপার্টির উপর ভিত্তি করে তৈরি, যা পূর্ববর্তী ইফেক্টিভ কানেকশন টাইপ (ECT) ডাইমেনশনের জন্যও দায়ী ছিল।
আরও তথ্যের জন্য এলসিপি রিসোর্স টাইপস লঞ্চ ব্লগ পোস্টটি দেখুন।
পরীক্ষামূলক মেট্রিক্স
BigQuery ব্যবহার করে CrUX ডেটাসেটে পরীক্ষামূলক মেট্রিকগুলো পাওয়া যায়, যার মধ্যে কয়েকটি CrUX API- তেও উপলব্ধ। ব্যবহারকারীদের মতামতের ভিত্তিতে এই মেট্রিকগুলো বিকশিত হওয়ার সাথে সাথে নিয়মিত পরিবর্তিত হওয়ার সম্ভাবনা রয়েছে। সর্বশেষ পরিবর্তনগুলো সম্পর্কে অবগত থাকতে রিলিজ নোট দেখুন।
প্রথম বাইটের সময়
CrUX-এ TTFB শুধুমাত্র সম্পূর্ণ পেজ লোডের সময় সংগ্রহ করা হয়, অন্যান্য টাইমার (যেমন LCP ) থেকে ভিন্ন, যা ব্যাক/ফরোয়ার্ড ক্যাশে (bfcache) নেভিগেশন এবং প্রি-রেন্ডার করা পেজের ক্ষেত্রেও সংগ্রহ করা হয়। এই কারণে, TTFB-এর স্যাম্পল সাইজ অন্যান্য মেট্রিকের তুলনায় ছোট হতে পারে এবং সেগুলোর সাথে সরাসরি তুলনা করা আবশ্যক নয়। CrUX-এর TTFB-তে কোল্ড পেজ লোড, ক্যাশড পেজ লোড এবং একটি প্রতিষ্ঠিত সংযোগ থেকে লোড হওয়া পেজ (উদাহরণস্বরূপ, ইন্ট্রা-সাইট পেজ লোড) অন্তর্ভুক্ত থাকবে।
TTFB সার্ভার রেসপন্স টাইমের সরাসরি পরিমাপ নয়, কারণ এতে এর আগের পরিমাপগুলোও অন্তর্ভুক্ত থাকে, যেমন রিডাইরেক্ট টাইম, এবং রেসপন্সটি ক্যাশে, CDN নাকি সার্ভার থেকে পরিবেশন করা হচ্ছে, তার দ্বারাও এটি প্রভাবিত হয়। CrUX-এর মতো ফিল্ড ডেটার ক্ষেত্রে এটি বিশেষভাবে লক্ষণীয়, যেখানে ল্যাব টেস্টিং সাধারণত এই বিষয়গুলো দ্বারা কম প্রভাবিত হয়, কারণ সেখানে এন্ড ইউআরএল পরীক্ষা করা হয় এবং প্রায়শই বারবার ক্যাশিং পরিবর্তনগুলোকে বাতিল করে দেওয়া হয়।
জনপ্রিয়তা
জনপ্রিয়তা র্যাঙ্ক মেট্রিক হলো CrUX ডেটাসেটের মধ্যে সাইটের জনপ্রিয়তার একটি আপেক্ষিক পরিমাপ, যা অরিজিনে মোট নেভিগেশনের সংখ্যা দ্বারা মাপা হয়। র্যাঙ্কটি একটি log10 স্কেলে অর্ধ-ধাপসহ দেখানো হয় (যেমন শীর্ষ ১ হাজার, শীর্ষ ৫ হাজার, শীর্ষ ১০ হাজার, শীর্ষ ৫০ হাজার, শীর্ষ ১ লক্ষ, শীর্ষ ৫ লক্ষ, শীর্ষ ১০ লক্ষ, ইত্যাদি), যেখানে প্রতিটি র্যাঙ্ক তার পূর্ববর্তী র্যাঙ্ককে বাদ দিয়ে গণনা করা হয় (যেমন শীর্ষ ৫ হাজার আসলে ৪ হাজার ইউআরএল, যা থেকে শীর্ষ ১ হাজার বাদ দেওয়া হয়েছে)। ডেটাসেট বড় হওয়ার সাথে সাথে এর ঊর্ধ্বসীমাও পরিবর্তনশীল।
ব্যাপক বিশ্লেষণের জন্য একটি নির্দেশিকা হিসেবে জনপ্রিয়তা প্রদান করা হয়, যেমন শীর্ষ ১,০০০ উৎসের ক্ষেত্রে দেশভিত্তিক কর্মক্ষমতা নির্ধারণ করার জন্য।
বিজ্ঞপ্তি অনুমতি
যেসব ওয়েবসাইট ব্যবহারকারীদের নোটিফিকেশন দেখানোর অনুমতি চায়, সেগুলোর ক্ষেত্রে এই মেট্রিকটি অনুমতি গ্রহণের (গ্রহণ), প্রত্যাখ্যানের (অস্বীকার), উপেক্ষার (উপেক্ষা) বা খারিজের (বাতিল) নির্দেশনার প্রতি ব্যবহারকারীদের প্রতিক্রিয়ার আপেক্ষিক হারকে নির্দেশ করে।