Core Web Vitals: যে তিনটি সংখ্যা সত্যিই র্যাঙ্কিং বদলায়
LCP, INP ও CLS ঠিক করে দেয় Google আপনার সাইটকে কীভাবে দেখে এবং ব্যবহারকারী কী অভিজ্ঞতা পান। প্রতিটি কী মাপে, কোন সীমা গুরুত্বপূর্ণ, আর বাস্তবে কোন সমাধানগুলো কাজ করে।
পারফরম্যান্স নিয়ে বেশির ভাগ পরামর্শই কিছু কৌশলের তালিকা, কিন্তু কোনটি আপনার সাইটের জন্য আসলে জরুরি তা বোঝার উপায় থাকে না। Core Web Vitals সেই সমস্যার সমাধান করে, কারণ এটি পুরো বিষয়টিকে তিনটি সংখ্যায় নামিয়ে আনে — যেগুলো Google বাস্তব ব্যবহারকারীদের উপর পরিমাপ করে।
সীমারেখা
একটি পেজ পাস করে তখনই, যখন বাস্তব ভিজিটের ৭৫% তিনটি মেট্রিকেই "ভালো" সীমার মধ্যে থাকে। এই শেষ অংশেই অনেকে ভুল করেন: অফিসের ওয়াই-ফাইতে আপনার দ্রুতগতির ল্যাপটপ কোনো পরিমাপ নয়। আসল ব্যবহারকারীদের ফিল্ড ডেটাই পরিমাপ।
| মেট্রিক | ভালো | উন্নতি দরকার | খারাপ |
|---|---|---|---|
| LCP — Largest Contentful Paint | ≤ ২.৫ সে | ২.৫–৪.০ সে | > ৪.০ সে |
| INP — Interaction to Next Paint | ≤ ২০০ মি.সে | ২০০–৫০০ মি.সে | > ৫০০ মি.সে |
| CLS — Cumulative Layout Shift | ≤ ০.১ | ০.১–০.২৫ | > ০.২৫ |
LCP: প্রধান জিনিসটি কত দ্রুত দেখা যায়
LCP মাপে ভিউপোর্টের সবচেয়ে বড় উপাদানটি কখন রেন্ডার শেষ করে — সাধারণত একটি হিরো ইমেজ, ভিডিও পোস্টার, বা বড় কোনো টেক্সট ব্লক।
ক্লায়েন্টদের সাইটে আমরা যে একটিমাত্র পরিবর্তনে সবচেয়ে বেশি ফল পাই, তা হলো LCP উপাদানটিকে ছবি নয়, টেক্সট বানানো। ফন্ট ও HTML পৌঁছানোমাত্র টেক্সট রেন্ডার হয়। কিন্তু হিরো ইমেজকে আগে খুঁজে পেতে হয়, নামাতে হয়, ডিকোড করতে হয় — আর ঢাকার 4G সংযোগে এতে প্রায়ই বাড়তি দুই সেকেন্ড চলে যায়।
হিরো ইমেজ বাদ দেওয়া সম্ভব না হলে:
- এটিকে
priority(বাfetchpriority="high") দিন, যাতে lazy-load না হয় - ডকুমেন্টের head-এ preload করুন, যাতে CSS-এর জন্য অপেক্ষা করতে না হয়
- মূল ৩০০০px ফাইল নয়, যে মাপে দেখানো হবে সেই মাপে AVIF বা WebP দিন
- এমন কোনো ক্লায়েন্ট কম্পোনেন্টের ভেতরে রাখবেন না, যা রেন্ডারের আগে hydrate হয়
// LCP ইমেজ কখনোই lazy হবে না — এই একটি ছবিই অপেক্ষা করতে পারে না।
<Image
src="/hero.avif"
alt="আর্কিটেকচার ডায়াগ্রাম দেখছে টিম"
width={1200}
height={675}
priority
sizes="(max-width: 768px) 100vw, 1200px"
/>INP: পেজ কত দ্রুত সাড়া দেয়
২০২৪ সালে INP, First Input Delay-এর জায়গা নিয়েছে এবং এটি অনেক বেশি কঠোর। FID কেবল প্রসেসিং শুরুর আগের বিলম্ব মাপত। INP মাপে পুরো চক্র — ইনপুট, প্রসেসিং এবং পরবর্তী পেইন্ট — পেজের প্রতিটি ইন্টারঅ্যাকশনের জন্য, তারপর সবচেয়ে খারাপটির কাছাকাছি একটি মান জানায়।
খারাপ INP-এর কারণ প্রায় সবসময়ই মেইন থ্রেডে অতিরিক্ত JavaScript চলা। সাধারণ কারণগুলো:
- বড় ক্লায়েন্ট-সাইড বান্ডল, যা এমন কম্পোনেন্টও hydrate করে যাদের দরকার ছিল না
- ক্লিক হ্যান্ডলারে ভারী কাজ, যা পিছিয়ে দেওয়া বা debounce করা যেত
- থার্ড-পার্টি স্ক্রিপ্ট — চ্যাট উইজেট, অ্যানালিটিক্স, ট্যাগ ম্যানেজার
কাঠামোগত সমাধান হলো কম JavaScript পাঠানো। React Server Components-এ এর মানে
"use client" কে পাতার দিকে রাখা: স্ক্রল ট্র্যাক করা হেডারকে ক্লায়েন্ট কম্পোনেন্ট
হতে হবে, কিন্তু তার নিচের সেকশনটিকে নয়।
CLS: পেজ কতটা নড়ে
CLS ঠিক করা সবচেয়ে সহজ, আর ব্যবহারকারীর জন্য সবচেয়ে বিরক্তিকর — উপরে বিজ্ঞাপন লোড হওয়ায় ট্যাপ গিয়ে পড়ে ভুল বাটনে।
তিনটি নিয়মেই বেশির ভাগ সমস্যা দূর হয়:
- ছবি, ভিডিও ও iframe-এ সবসময়
widthওheight(বাaspect-ratio) দিন, যাতে ফাইল আসার আগেই ব্রাউজার জায়গা রেখে দেয়। - পরে আসা যেকোনো কিছুর জন্য আগেই জায়গা রাখুন — ব্যানার, কুকি নোটিশ, এম্বেড। কনটেইনারে নির্দিষ্ট উচ্চতা দিন, নিচের কন্টেন্ট ঠেলে সরাতে দেবেন না।
- মানানসই ফলব্যাকসহ
font-display: swapব্যবহার করুন। খুব ভিন্ন মাপের ফলব্যাক ফন্ট থেকে সোয়াপ হলে চোখে পড়ার মতো রিফ্লো হয়;size-adjustদুটি ফন্টের মাপ কাছাকাছি রাখে।
ল্যাব নয়, ফিল্ড ডেটা মাপুন
Lighthouse একটি সিমুলেটেড সংযোগে ল্যাব স্কোর দেয়। রিগ্রেশন ধরতে এটি কাজের, কিন্তু Google এর ভিত্তিতে র্যাঙ্ক করে না।
আসল সংখ্যার জন্য ব্যবহার করুন:
- Chrome UX Report (CrUX) — Core Web Vitals মূল্যায়নের পেছনের প্রকৃত ডেটাসেট
- Search Console-এর Core Web Vitals রিপোর্ট — URL প্যাটার্ন অনুযায়ী CrUX ডেটা
web-vitalsলাইব্রেরি দিয়ে রিয়েল-ইউজার মনিটরিং, যা ডিভাইস, দেশ ও সংযোগের ধরন অনুযায়ী স্কোর মিলিয়ে দেখতে দেয়
বাংলাদেশি দর্শকদের জন্য শেষেরটি সবচেয়ে গুরুত্বপূর্ণ। সিমুলেটেড ডেস্কটপে ৯৮ স্কোর পাওয়া সাইটও ফিল্ড মূল্যায়নে ফেল করতে পারে, কারণ বেশির ভাগ ভিজিট আসে মোবাইল ডেটায় চলা মাঝারি মানের অ্যান্ড্রয়েড ফোন থেকে।
কোথা থেকে শুরু করবেন
মাত্র তিনটি কাজ করলে:
- নিশ্চিত করুন LCP উপাদানটি টেক্সট, নয়তো preload করা ও সঠিক মাপের ছবি
- কোন কম্পোনেন্টের সত্যিই ক্লায়েন্ট-সাইড JavaScript দরকার তা যাচাই করে বাকিগুলো সরান
- প্রতিটি ছবিতে স্পষ্ট মাপ দিন এবং পরে লোড হওয়া কন্টেন্টের জন্য জায়গা রাখুন
সাধারণত এতেই একটি ফেল করা সাইট ভালো সীমার মধ্যে চলে আসে, নতুন করে কিছু লিখতে হয় না।
আপনার সাইটের পারফরম্যান্স অডিট ও নির্দিষ্ট অগ্রাধিকারভিত্তিক সমাধান চান? যোগাযোগ করুন — প্রস্তাব পাঠানোর আগে আমরা আপনাকে সংখ্যাগুলো পাঠাব।