২০২৬ সালে Core Web Vitals: LCP, INP ও CLS ঠিক করা

Core Web Vitals হলো তিনটি সংখ্যা, যা Google আপনার সাইটের সত্যিকারের ভিজিটরদের কাছ থেকে মাপে, আর যা র‍্যাঙ্কিংয়ে যোগ হয়। খুব বেশি নয় — কনটেন্ট আর প্রাসঙ্গিকতাই মূল — তবে সমমানের দুটি পাতার মধ্যে এগুলো সত্যিকারের নিষ্পত্তিকারক, আর আপনার সাইট ব্যবহার করে আরাম লাগে কি না তারও মোটামুটি ভালো পরিমাপ।

তিনটি, আর প্রতিটির আসল মানে:

উত্তীর্ণ হতে হলে তিনটিতেই, ৭৫% ভিজিটের ক্ষেত্রে "ভালো" পেতে হবে। আর ২০২৬ সালে বেশিরভাগ সাইট ব্যর্থ হয় INP-তে।

শুরু করুন এখান থেকে: ফিল্ড ডেটা, আপনার Lighthouse স্কোর নয়

সবচেয়ে প্রচলিত ভুলটি হলো ভুল সংখ্যাটি অপ্টিমাইজ করা।

ল্যাব ডেটা — Lighthouse, PageSpeed Insights-এর স্কোর, আপনার নিজের অডিট — একটি কৃত্রিম ডিভাইস ও নেটওয়ার্কে চালানো সিমুলেশন। রোগনির্ণয়ে কাজের। কিন্তু Google এটি ব্যবহার করে না।

ফিল্ড ডেটা — Chrome UX Report — সত্যিকারের ডিভাইসে, সত্যিকারের নেটওয়ার্কে থাকা সত্যিকারের Chrome ব্যবহারকারী। র‍্যাঙ্কিংয়ে এটাই গোনা হয়।

এরা নিয়মিতই একমত হয় না, আর একটি নির্দিষ্ট দিকে: আপনার Lighthouse স্কোর তৈরি হয় এমন একটি সিমুলেটেড পেজ লোড থেকে, যেখানে কেউ কিছু স্পর্শই করে না। এটি অর্থবহ কোনো INP তৈরি করতেই পারে না, কারণ পেজটির সঙ্গে কেউ ইন্টার‌্যাক্ট করেনি।

তাই: PageSpeed Insights খুলুন আর ওপরের অংশটি পড়ুন, "Discover what your real users are experiencing"। যদি বলে যথেষ্ট ডেটা নেই, তার মানে CRUX-এর জন্য আপনার সাইটে ট্র্যাফিক কম, আর Vitals এখন আপনার র‍্যাঙ্কিংয়ের উদ্বেগ নয় — পরিশ্রমটা বরং কনটেন্টে দিন।

INP: যেটিতে ব্যর্থ হতে হয়

২০২৪ সালের মার্চে INP FID-র জায়গা নেয়, আর এটি অনেক কঠিন পরীক্ষা। FID মাপত কেবল ইভেন্ট হ্যান্ডলার শুরু হওয়ার আগের বিলম্ব। INP মাপে পুরোটা: ইনপুট বিলম্ব, হ্যান্ডলার চলা, আর পরের ফ্রেমটি আঁকা। এটি মোটামুটি ভিজিটের সবচেয়ে খারাপ ইন্টার‌্যাকশনটি জানায়।

কোনো সাইট ৩০ মিলিসেকেন্ডে FID পাস করে ৬০০ মিলিসেকেন্ডে INP ফেল করতে পারত, কারণ হ্যান্ডলার শুরু হওয়ার পরের ওই ৫৭০ মিলিসেকেন্ডের কাজ FID কখনো মাপতই না।

খারাপ INP-র কারণ, কোনটি কতবার দায়ী সেই ক্রমে:

1. মেইন থ্রেডে অতিরিক্ত জাভাস্ক্রিপ্ট। JS আর রেন্ডারিংয়ের জন্য ব্রাউজার একক থ্রেডের। দীর্ঘ কোনো কাজ ট্যাপটিকে আটকে রাখে।
2. তৃতীয় পক্ষের স্ক্রিপ্ট। অ্যানালিটিক্স, চ্যাট উইজেট, হিটম্যাপ, বিজ্ঞাপনের স্ক্রিপ্ট, ট্যাগ ম্যানেজার। সাধারণত সবচেয়ে বড় একক অবদান এগুলোরই, আর এগুলোই সবচেয়ে কম খতিয়ে দেখা হয়।
3. ব্যয়বহুল ইভেন্ট হ্যান্ডলার। এমন ক্লিক যা বড় একটি রি-রেন্ডার ঘটায়, বা এমন স্ক্রল হ্যান্ডলার যা প্রতিটি ফ্রেমে লেআউটের কাজ করে।
4. বড় DOM। কয়েক হাজার নোড থাকলে প্রতিটি স্টাইল পুনর্গণনা ব্যয়বহুল হয়ে যায়।

যা সত্যিই ঠিক করে:

• যেসব তৃতীয় পক্ষের স্ক্রিপ্টের যৌক্তিকতা দেখাতে পারছেন না, সেগুলো সরান। defer নয় — সরান। পেজে কী কী আছে আর প্রতিটি কী কাজে, তা খতিয়ে দেখুন। বেশিরভাগ সাইটে অন্তত একটি ট্যাগ চলে, যেটি কেউ কবে বসিয়েছিল মনে নেই।
• যা থাকল তা defer করুন। প্রথম ইন্টার‌্যাকশনের জন্য দরকার নেই এমন সবকিছু তার পরে লোড হোক।
• দীর্ঘ কাজ ভাগ করুন। একবারে সব না করে কাজের খণ্ডগুলোর মাঝে মেইন থ্রেডকে জায়গা ছেড়ে দিন।
• কম জাভাস্ক্রিপ্ট পাঠান। React-এ তার মানে কাজ সার্ভারে সরানো — Server Components মূলত এ কারণেই আছে।
• সঙ্গে সঙ্গে দৃশ্যমান সাড়া দিন। কাজটি সত্যিই ধীর হলেও, পরের ফ্রেমেই একটি চাপা অবস্থা বা স্পিনার আঁকলে মাপা ইন্টার‌্যাকশন ভালো হয় — আর তার চেয়েও বড় কথা, অনুভূত ইন্টার‌্যাকশন ভালো হয়।

LCP: যেটি নিয়ে মানুষ এমনিতেই কাজ করে

LCP হলো পর্দার ওপরের সবচেয়ে বড় উপাদানটির রেন্ডার শেষ হওয়ার মুহূর্ত — সাধারণত হিরো ছবি, কখনো একটি শিরোনাম ব্লক।

এটি চারটি অংশে ভাগ হয়, আর কোনটি আপনার সমস্যা তা জানলে অনেক অনুমান বেঁচে যায়:

1. Time to First Byte। সার্ভার। TTFB ৮০০ মিলিসেকেন্ড হলে বীরত্ব ছাড়া ২.৫ সেকেন্ডের LCP পাওয়া যাবে না। আগে হোস্ট ঠিক করুন — WordPress দ্রুত করা আর শেয়ার্ড হোস্টিং বাছাই দুটোতেই এটি আছে।
2. রিসোর্স লোড বিলম্ব। HTML আসা আর ব্রাউজারের LCP ছবিটি আনা শুরু করার মাঝের ফাঁক। প্রায় সবসময়ই ছবিটি দেরিতে আবিষ্কৃত হয় বলে — সিএসএসে, জাভাস্ক্রিপ্টে, বা লেজি-লোডে।
3. রিসোর্স লোড সময়। ছবিটি নামতে যত সময়। আকার আর ফরম্যাট।
4. রেন্ডার বিলম্ব। ছবি নেমে গেছে, কিন্তু রেন্ডার আটকে রাখা কোনো স্টাইলশিট বা ফন্টের কারণে আঁকা যাচ্ছে না।

সমাধান, কার্যকারিতার ক্রমে:

• LCP ছবিটি কখনো লেজি-লোড করবেন না। নিজের হাতে করা LCP ব্যর্থতার সবচেয়ে প্রচলিত রূপ এটাই। হিরো ছবিতে loading="lazy" সরাসরি মাপকাঠিটিকেই দেরি করায়।
• সেটি preload করুন, যাতে ব্রাউজার সিএসএস পার্স করার পরে নয়, সঙ্গে সঙ্গেই সেটি আনতে শুরু করে।
• আধুনিক ফরম্যাট দিন — WebP বা AVIF, যে প্রস্থে সত্যিই দেখানো হবে সেই মাপে।
• TTFB ঠিক করুন, যদি সেটিই প্রধান অংশ হয়। ধীর অরিজিনের ক্ষতি কোনো ফ্রন্ট-এন্ড কাজ পুষিয়ে দেয় না।
• ফন্টের দিকে নজর দিন। font-display: swap লেখা অদৃশ্য থাকার সময়টুকু ঠেকায়; ফলব্যাকে আঁকা হয়ে পরে বদলে যাওয়া শিরোনাম LCP-র জন্য কিছুই না আঁকার চেয়ে অনেক ভালো।

CLS: ঠিক করা সবচেয়ে সহজ, ভোগান্তি সবচেয়ে বিরক্তিকর

CLS মাপে পেজ লোড হওয়ার সময় কনটেন্ট কতটা লাফায়। এটির নাম না জেনেই ব্যবহারকারীরা এটির নামে অভিযোগ করেন — বিজ্ঞাপন লোড হওয়ায় ট্যাপটা ভুল জায়গায় পড়া।

চারটি কারণ, আর চারটিরই সমাধানের চেহারা এক: আগেভাগে জায়গাটা বরাদ্দ রাখুন।

1. মাপ ছাড়া ছবি। সবসময় width ও height, বা একটি aspect-ratio দিন। তখন ফাইল আসার আগেই ব্রাউজার বাক্সটি বরাদ্দ করে রাখে।
2. বিজ্ঞাপন ও এমবেড। কনটেইনারে একটি নির্দিষ্ট ন্যূনতম উচ্চতা দিন। শূন্য থেকে হাজির হওয়া বিজ্ঞাপনের স্লট নিচের সবকিছু ঠেলে দেয় — ঠিক এ কারণেই এই সাইটের বিজ্ঞাপন ইউনিটগুলো স্ক্রিপ্ট চলার আগেই নিজেদের উচ্চতা বরাদ্দ করে রাখে।
3. ওয়েব ফন্ট। আলাদা মাপের ফলব্যাক বদলানোর সময় লেখা নতুন করে সাজায়। size-adjust আর ascent-override ডেসক্রিপ্টর এটি কমায়।
4. ওপরে ঢোকানো কনটেন্ট। কুকি ব্যানার, প্রচারের স্ট্রিপ, নোটিফিকেশন বার। হয় জায়গা বরাদ্দ রাখুন, নয়তো ঢোকানোর বদলে ওপরে ভাসিয়ে দিন।

⚠ অভিজ্ঞতা থেকে একটি সতর্কতা। এই সাইটে একবার এমন একটি পার্টিকল-অ্যানিমেশন কনটেইনার গিয়েছিল, যেটি তার ক্যানভাস position: fixed হওয়ার আগে কিছুক্ষণের জন্য পুরো ভিউপোর্ট সমান হয়ে যেত, গোটা পেজ নিচে ঠেলে দিয়ে আবার ফিরে আসত। মাপা CLS: ১.০৫ — ব্যর্থতার সীমার দশ গুণ। সমাধান ছিল কনটেইনারটিকে শূন্য মাপে বেঁধে দেওয়া এক লাইন, আর তাতে পেজটি ০.০২-এ নেমে আসে। শিক্ষাটি সাধারণীকরণযোগ্য: পেইন্টের পরে বসে এমন যেকোনো কিছু শুরু থেকেই তার চূড়ান্ত জায়গাটা দখল করে রাখা উচিত।

কাজের একটি বাস্তব ক্রম

তিনটি একসঙ্গে অপ্টিমাইজ করবেন না। ফিল্ড ডেটা ধরে এগোন।

1. ফিল্ড ডেটা নিন। CRUX ডেটা না থাকা মানে এখনো র‍্যাঙ্কিংয়ে প্রভাব নেই; বরং গিয়ে কনটেন্ট লিখুন।
2. কোন মাপকাঠিতে ব্যর্থ হচ্ছেন খুঁজুন। সাধারণত INP।
3. INP-র জন্য: আগে তৃতীয় পক্ষের স্ক্রিপ্ট খতিয়ে দেখুন। এটাই সবচেয়ে বড় হাতিয়ার আর সবচেয়ে কম মজার, তাই এটাই বাদ পড়ে।
4. LCP-র জন্য: হিরো ছবিটি লেজি-লোড হচ্ছে কি না দেখুন, তারপর TTFB দেখুন। বেশিরভাগটাই ওই দুটো।
5. CLS-র জন্য: ছবিতে মাপ দিন আর দেরিতে আসা যেকোনো কিছুর জন্য জায়গা বরাদ্দ রাখুন।
6. ২৮ দিন পর আবার মাপুন। CRUX ২৮ দিনের চলমান জানালা, তাই আজ ডিপ্লয় করা সমাধান পুরোপুরি দেখাতে চার সপ্তাহ লাগে। এখানেই মানুষ আতঙ্কিত হয়ে আরও পাঁচটা জিনিস বদলায়।

যেসব কাজে সময় দেওয়ার মানে নেই

• Lighthouse-এ ১০০ স্কোরের পেছনে ছোটা। এটি ল্যাব সিমুলেশন, যার ওজনগুলো ফিল্ডের সীমার সঙ্গে মেলে না। ১০০ পাওয়া সাইট Vitals-এ ফেল করতে পারে, আর ৭০ পাওয়া সাইট স্বচ্ছন্দে পাস করতে পারে।
• সীমা পেরোনোর পরেও সূক্ষ্ম অপ্টিমাইজেশন। এগুলো পাস/ফেল ব্যান্ড, ধারাবাহিক কোনো র‍্যাঙ্কিং মাপ নয়। ১.২ সেকেন্ডের LCP ২.৪ সেকেন্ডের LCP-র চেয়ে ভালো র‍্যাঙ্ক করে না।
• কোন মাপকাঠিতে আর কেন ব্যর্থ হচ্ছেন তা না মেপেই "পারফরম্যান্সের জন্য" সাইট নতুন করে লেখা। Vitals-এর বেশিরভাগ সমস্যা নির্দিষ্ট তিনটি জিনিস, কোনো আর্কিটেকচার নয়।

মাপা আর ঠিক করা যদি আপনার সপ্তাহের ভালো ব্যবহার না হয়, তাহলে আমরা এটি সার্ভিস হিসেবেও করি, বাংলা ও ইংরেজি দুই ভাষাতেই।

Google-এর নমুনা নয়, নিজের ভিজিটরদের মাপা

Chrome UX Report-এর ফিল্ড ডেটা দিয়েই Google র‍্যাঙ্ক করে, কিন্তু এর দুটি সীমা আছে: এটি ২৮ দিনের চলমান গড়, আর এটি কেবল Chrome ব্যবহারকারীদের ঢাকে, তাও যথেষ্ট ট্র্যাফিক থাকা সাইটে। এতে এটি ডিবাগিংয়ের খারাপ টুল হয়ে দাঁড়ায় — যতক্ষণে সংখ্যাটা নড়ে, ততক্ষণে আপনি ভুলে গেছেন কী বদলেছিলেন।

সমাধান হলো নিজেরটা মাপা, ব্রাউজার যে এপিআই দিয়ে জানায় সেটি দিয়েই:

<script type="module">
  import { onLCP, onINP, onCLS } from 'https://unpkg.com/web-vitals?module'
  const send = m => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, rating: m.rating, path: location.pathname,
  }))
  onLCP(send); onINP(send); onCLS(send)
</script>

এতে তিনটি জিনিস পাবেন, যা CRUX দিতে পারে না:

প্রতি পাতার সংখ্যা। CRUX জানায় অরিজিন স্তরে, আর জনপ্রিয় পাতার ক্ষেত্রে প্রতি URL-এ। আপনার নিজের ডেটা বলে দেয় কোন একটি টেমপ্লেট গড়টাকে টেনে নামাচ্ছে — আর সাধারণত পুরো উত্তরটা ওটাই।

তাৎক্ষণিক ফিডব্যাক। কোনো ডিপ্লয়ের প্রভাব চার সপ্তাহ পরে নয়, সেদিনই দেখতে পান।

কারণ চিহ্নিত করা। web-vitals লাইব্রেরির অ্যাট্রিবিউশন বিল্ড জানায় কোন উপাদানটি LCP ছিল আর কোন ইন্টার‌্যাকশনটি সবচেয়ে খারাপ INP দিয়েছে। এতে "INP ৪৮০ মিলিসেকেন্ড" বদলে হয় "লিস্টিং পাতার ফিল্টার ড্রপডাউনটি ৪৮০ মিলিসেকেন্ড নেয়", যা নিয়ে সত্যিই কিছু করা যায়।

যেখানে আপনি এমনিতেই অ্যানালিটিক্স পাঠান, সেখানেই পাঠান। পরিমাণ সামান্য, আর এতে Core Web Vitals ত্রৈমাসিক রিপোর্ট কার্ড থেকে বদলে গিয়ে এমন একটি সাধারণ প্রকৌশল মাপকাঠি হয়, যা নিয়ে কাজ করা যায়।

সচরাচর জিজ্ঞাসা

২০২৬ সালে ভালো INP কত? সত্যিকারের ভিজিটের ৭৫তম পার্সেন্টাইলে ২০০ মিলিসেকেন্ড বা কম। ৫০০-র ওপরে খারাপ। ২০২৪ সালের মার্চে INP FID-র জায়গা নেয় আর এটি পাস করা অনেক কঠিন, কারণ এটি কেবল প্রাথমিক বিলম্ব নয়, পরের পেইন্টসহ পুরো ইন্টার‌্যাকশনটাই মাপে।

আমার PageSpeed স্কোর ভালো, তবু Core Web Vitals ফেল করছে কেন? কারণ এরা আলাদা জিনিস মাপে। স্কোরটি ল্যাব সিমুলেশন; Core Web Vitals মূল্যায়ন হয় সত্যিকারের Chrome ব্যবহারকারীদের ফিল্ড ডেটা দিয়ে। ল্যাব পরীক্ষা INP অর্থবহভাবে মাপতেও পারে না, কারণ পেজটির সঙ্গে কিছুই ইন্টার‌্যাক্ট করে না।

Core Web Vitals কি সত্যিই র‍্যাঙ্কিংয়ে প্রভাব ফেলে? হ্যাঁ, পেজ এক্সপিরিয়েন্স সংকেতের অংশ হিসেবে — তবে সামান্য। প্রাসঙ্গিকতা আর কনটেন্টের মানই মূল। সমমানের পাতাগুলোর মধ্যে নিষ্পত্তিকারক হিসেবে, আর নিজে থেকেই একটি সত্যিকারের ব্যবহারকারী-অভিজ্ঞতার মাপকাঠি হিসেবে দেখুন।

সমাধানের ফল দেখতে কত সময় লাগে? ফিল্ড ডেটা ২৮ দিনের চলমান জানালা, তাই আজ ডিপ্লয় করা সমাধান পুরোপুরি প্রতিফলিত হতে প্রায় চার সপ্তাহ লাগে। ডিপ্লয় করুন, অপেক্ষা করুন, তারপর আবার মাপুন — মাঝখানে আরও পাঁচটা পরিবর্তন চাপিয়ে দেবেন না।

খারাপ CLS-র কারণ কী? width ও height ছাড়া ছবি, জায়গা বরাদ্দ না রেখে হাজির হওয়া বিজ্ঞাপন ও এমবেড, লেখা নতুন করে সাজানো ফন্ট বদল, আর বিদ্যমান কনটেন্টের ওপরে ঢোকানো কনটেন্ট। উপাদানটি আসার আগেই জায়গা বরাদ্দ রেখে সবগুলোই ঠিক হয়।

আমার সাইটে কি মাপার মতো যথেষ্ট ট্র্যাফিক আছে? PageSpeed Insights-এ ফিল্ড ডেটা না দেখালে আপনার সাইট Chrome UX Report-এর সীমার নিচে। তখন Core Web Vitals-এর কোনো মাপযোগ্য র‍্যাঙ্কিং প্রভাব আপনার ক্ষেত্রে নেই, আর পরিশ্রমটা কনটেন্টে দেওয়াই ভালো।