Core Web Vitals সহজ ভাষায়: LCP, INP এবং CLS ব্যাখ্যা

Core Web Vitals আপনার ওয়েবসাইটের জন্য কোনো ব্যক্তিত্ব পরীক্ষা নয়

Core Web Vitals-কে প্রায়ই রহস্যময় স্কোরকার্ডের মতো দেখা হয়। কোনো পেজে লাল রঙের একটি সংখ্যা আসে, কেউ Slack-এ স্ক্রিনশট পোস্ট করে, আর টিম JavaScript framework নিয়ে তর্ক শুরু করে।

এটি বিশেষ কার্যকর নয়।

Core Web Vitals নিয়ে ভাবার ভালো উপায়টি আরও সহজ: এগুলো হলো বাস্তব ডিভাইসে বাস্তব মানুষের কাছে একটি পেজ ব্যবহারযোগ্য মনে হচ্ছে কি না, তার তিনটি মাপ। এগুলো performance, accessibility বা quality-র প্রতিটি দিক ধরে না। তবে এগুলো বিরক্তির তিনটি সাধারণ উৎস ধরতে পারে:

• মূল কনটেন্ট দেখা দিতে খুব বেশি সময় নেয়।
• ব্যবহারকারী কিছু করতে চাইলে পেজ ধীরে সাড়া দেয়।
• ব্যবহারকারী পড়ার বা ট্যাপ করার সময় layout লাফিয়ে বদলায়।

এই তিনটিই Core Web Vitals: LCP, INP এবং CLS।

Google এগুলোকে তার page experience signals-এর অংশ হিসেবে ব্যবহার করে, কিন্তু SEO-র দিকটি গুরুত্ব দেওয়ার সবচেয়ে ভালো কারণ নয়। ভালো কারণ হলো ধীর, লাফানো, সাড়া না-দেওয়া পেজ ব্যবহারকারীর সময় নষ্ট করে। এগুলো সাধারণত conversion খারাপ করে, support খারাপ করে, এবং সময়ের সঙ্গে খারাপভাবে পুরোনো হয়।

তিনটি মেট্রিক এক বাক্যে

বিস্তারিত আলোচনায় যাওয়ার আগে, সহজ ভাষায় সংক্ষিপ্ত সংস্করণটি হলো:

• LCP, বা Largest Contentful Paint, মূল দৃশ্যমান কনটেন্ট লোড হতে কত সময় লাগে তা মাপে।
• INP, বা Interaction to Next Paint, ভিজিটজুড়ে ব্যবহারকারীর interaction-এ পেজ কত দ্রুত সাড়া দেয় তা মাপে।
• CLS, বা Cumulative Layout Shift, পেজ অপ্রত্যাশিতভাবে কতটা নড়ে ওঠে তা মাপে।

সাধারণ threshold হলো:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s or faster | 2.5s–4.0s | Over 4.0s | | INP | 200ms or faster | 200ms–500ms | Over 500ms | | CLS | 0.1 or lower | 0.1–0.25 | Over 0.25 |

এই সংখ্যাগুলো সাধারণত বাস্তব user visit-এর 75th percentile-এ মূল্যায়ন করা হয়। এটি গুরুত্বপূর্ণ। আপনার লক্ষ্য একটি নিখুঁত lab run তৈরি করা নয়। লক্ষ্য হলো বেশিরভাগ ব্যবহারকারীর জন্য অভিজ্ঞতা ভালো করা, যার মধ্যে ধীর ফোন এবং অস্থির network ব্যবহারকারীরাও আছে।

আপনি যদি automated report-এর দিকে তাকিয়ে থাকেন এবং কোথা থেকে শুরু করবেন বুঝতে না পারেন, তাহলে diagnosis-কে panic থেকে আলাদা করা সহায়ক। এ workflow আরও বিস্তারিতভাবে বোঝাতে Lighthouse report না ঘাবড়ে কীভাবে পড়বেন, সে বিষয়ে আমাদের একটি আলাদা guide আছে।

LCP: পেজ কখন লোড হয়েছে বলে মনে হয়?

Largest Contentful Paint viewport-এর মধ্যে সবচেয়ে বড় দৃশ্যমান content element render হতে কত সময় নেয় তা মাপে। বাস্তবে সেটি প্রায়ই হয়:

• একটি hero image,
• একটি বড় heading,
• একটি featured article image,
• একটি product image,
• text-এর একটি বড় block।

LCP জানতে চায় না কখন প্রতিটি script, tracking pixel এবং below-the-fold image লোড শেষ হলো। এটি জানতে চায়: ব্যবহারকারী যে মূল জিনিসটি দেখতে এসেছিল, সেটি কখন দৃশ্যমান হলো?

এ কারণেই LCP পুরোনো ধাঁচের “page load time”-এর চেয়ে বেশি মানবিক মেট্রিক। কোনো পেজ technically দেরিতে loading শেষ করলেও মূল content দ্রুত দেখা দিলে সেটি দ্রুত মনে হতে পারে। উল্টোটিও সত্যি: hero area যদি তখনও ফাঁকা, ঝাপসা বা render delay-তে আটকে থাকে, তবুও পেজ load event fire করতে পারে।

দুর্বল LCP-এর সাধারণ কারণ

বেশিরভাগ খারাপ LCP সমস্যা কয়েকটি অনুমেয় জায়গা থেকে আসে:

1. ধীর server response

HTML document দেরিতে এলে, বাকি সবকিছুই দেরিতে শুরু হয়।

1. Render-blocking CSS বা JavaScript

Browser-এর কাছে content আছে, কিন্তু এখনও সেটি paint করতে পারছে না।

1. Unoptimised hero images

সবচেয়ে বড় element খুব বড়, ভুল format-এ, prioritised নয়, অথবা ভুল করে lazily loaded।

1. Web fonts text rendering দেরি করাচ্ছে

একটি বড় heading LCP element হতে পারে, এবং font loading সেটিকে দেরি করাতে বা visually বদলে দিতে পারে।

1. Client-side rendering delays

অর্থপূর্ণ content দেখানোর আগে যদি পেজের বড় JavaScript bundle দরকার হয়, LCP ক্ষতিগ্রস্ত হয়।

LCP কীভাবে উন্নত করবেন

প্রথমে আসল LCP element দিয়ে শুরু করুন। Browser কী মাপছে তা না জেনে random asset optimise করবেন না।

ব্যবহারিক fix-গুলোর মধ্যে আছে:

• HTML দ্রুত serve করুন: যেখানে উপযুক্ত cache করুন, backend work কমান, slow redirect এড়ান।
• LCP image optimise করুন: সঠিক dimensions, compression এবং format ব্যবহার করুন।
• Above-the-fold hero image lazy-load করবেন না।
• Main image সত্যিই priority হলে সতর্কভাবে fetchpriority="high" ব্যবহার করুন।
• Critical CSS inline করুন শুধু তখনই, যখন তা render delay অর্থপূর্ণভাবে কমায়।
• প্রথম meaningful render-এর আগে প্রয়োজনীয় JavaScript কমান।
• font-display: swap অথবা অন্য কোনো ইচ্ছাকৃত font strategy ব্যবহার করুন।

Images এবং fonts ঘন ঘন দায়ী হয়। Images-এর ক্ষেত্রে trade-off শুধু “small file good” নয়। Format choice, encoding effort এবং browser support—সবই গুরুত্বপূর্ণ, তাই আমরা কখন AVIF WebP-কে ছাড়িয়ে যায় এবং কখন যায় না সে বিষয়ে একটি practical decision tree রাখি। Type-heavy পেজের ক্ষেত্রে, web fonts এখনও বেশিরভাগ site-এ সবচেয়ে সহজ performance win-গুলোর একটি, কারণ অনেক site ব্যবহার করার চেয়ে বেশি font file পাঠায়।

INP: স্পর্শ করলে পেজ সাড়া দেয় কি?

Interaction to Next Paint responsiveness মাপে। আরও নির্দিষ্টভাবে বললে, ব্যবহারকারীর interaction এবং browser সেই interaction process করার পরের visual update-এর মধ্যে delay দেখে।

Interaction-এর মধ্যে আছে যেমন:

• button click করা,
• menu tap করা,
• checkbox select করা,
• form field-এ type করা,
• accordion খোলা।

INP 2024 সালে Core Web Vital হিসেবে First Input Delay-কে replace করেছে। পরিবর্তনটি ভালো ছিল। First Input Delay শুধু প্রথম interaction দেখত। INP আরও বিস্তৃত: এটি page visit জুড়ে interaction বিবেচনা করে এবং উচ্চ-latency interaction-কে পেজের responsiveness score হিসেবে report করে।

সহজ ভাষায়: INP এমন পেজ ধরে, যেগুলো loaded দেখায় কিন্তু আটকে আছে বলে মনে হয়।

আপনি সম্ভবত এমন পেজ ব্যবহার করেছেন। দেখতে ready। আপনি menu tap করেন। অর্ধেক সেকেন্ড কিছুই হয় না। আবার tap করেন। তারপর একসঙ্গে দুইটি জিনিস ঘটে। এটি INP সমস্যা।

দুর্বল INP-এর সাধারণ কারণ

INP সাধারণত main-thread সমস্যা। Browser সাড়া দিতে চায়, কিন্তু JavaScript, rendering work বা layout calculation পথে বাধা হয়ে আছে।

সাধারণ কারণগুলোর মধ্যে আছে:

• বড় JavaScript bundles,
• ব্যয়বহুল event handlers,
• client-rendered apps-এ hydration work,
• main thread-এর জন্য প্রতিযোগিতা করা third-party scripts,
• page load-এর পর long-running tasks,
• ছোট interaction থেকে trigger হওয়া complex DOM updates,
• layout thrashing, যেখানে code বারবার layout values পড়ে এবং লেখে।

Marketing tags, analytics, chat widgets এবং consent banners—সবই অবদান রাখতে পারে। এর মানে “সবকিছু সরিয়ে ফেলুন” নয়। এর মানে হলো পেজের প্রতিটি script-এর একটি cost আছে, এবং interaction latency-তেই সেই cost প্রায়ই দৃশ্যমান হয়।

INP কীভাবে উন্নত করবেন

INP উন্নত করা একটি magic attribute-এর বিষয় কম, বরং main-thread contention কমানোর বিষয় বেশি।

উপকারী পদ্ধতিগুলোর মধ্যে আছে:

• দীর্ঘ JavaScript task ছোট chunk-এ ভাগ করুন।
• পেজ usable হওয়ার পর পর্যন্ত non-essential work defer করুন।
• শুধু minify না করে unused JavaScript সরান।
• Event handlers ছোট এবং predictable রাখুন।
• খুব ছোট state change-এর জন্য interface-এর বড় অংশ re-render করা এড়ান।
• যেখানে সম্ভব simple visual state-এর জন্য CSS ব্যবহার করুন।
• Third-party scripts audit করুন এবং প্রয়োজন যেখানে, শুধু সেখানেই load করুন।

Interaction design-ও দেখুন। কোনো button যদি সঙ্গে সঙ্গে visual feedback দেয়, তাহলে follow-up work বেশি সময় নিলেও সেটি বেশি responsive মনে হতে পারে। এটি performance-এর substitute নয়, তবে ভালো interface engineering-এর অংশ। Accessible web buttons নিয়ে আমাদের checklist-এর সঙ্গে এর মিল আছে: clear states, proper semantics এবং predictable behaviour ব্যবহারকারী ও browser—উভয়কেই সাহায্য করে।

CLS: পেজ কি ব্যবহারকারীর প্রত্যাশিত জায়গায় স্থির থাকে?

Cumulative Layout Shift দৃশ্যমান element-এর অপ্রত্যাশিত movement মাপে। ব্যবহারকারী যদি একটি paragraph পড়া শুরু করে এবং তার ওপরে কোনো ad, image বা banner load হয়ে text নিচে ঠেলে দেয়, তাহলে সেটি CLS-এ অবদান রাখে।

CLS সেকেন্ডে মাপা হয় না। কত content নড়েছে এবং কত দূর নড়েছে, তার ভিত্তিতে এটি একটি score। কম হলে ভালো।

মূল শব্দটি হলো unexpected। ব্যবহারকারীর action থেকে হওয়া layout change সাধারণত একইভাবে গণনা করা হয় না। কেউ “show more” tap করলে এবং content expand হলে সেটি expected। তিন সেকেন্ড পর কোনো newsletter banner উপরে এসে সবকিছু নিচে ঠেলে দিলে সেটি expected নয়।

দুর্বল CLS-এর সাধারণ কারণ

CLS failure প্রায়ই খুব সাধারণ কারণে হয়:

• width এবং height attribute ছাড়া images,
• reserved space ছাড়া ads বা embeds,
• content-এর ওপর insert করা cookie banners,
• ভিন্ন metrics সহ web fonts swap হওয়া,
• late-loading promotional bars,
• পেজের ওপরের দিকে dynamically injected content।

Fix সাধারণত content আসার আগে space reserve করা। Browser যত তাড়াতাড়ি সম্ভব পেজের shape জানতে পারা উচিত।

CLS কীভাবে উন্নত করবেন

Visible shifts দিয়ে শুরু করুন। কোন element নড়ে তা শনাক্ত করতে recording দেখুন বা browser tooling ব্যবহার করুন।

তারপর boring fixes প্রয়োগ করুন:

• Images-এ explicit width এবং height attributes যোগ করুন।
• Responsive media containers-এর জন্য CSS aspect-ratio ব্যবহার করুন।
• Ads, embeds এবং iframes-এর জন্য fixed বা minimum space reserve করুন।
• Load-এর পর existing content-এর ওপর banner inject করা এড়ান।
• Final font-এর মতো similar metrics আছে এমন font fallbacks বেছে নিন।
• top, left, width বা height-এর মতো layout property বদলায় এমন animation এড়ান; transforms পছন্দ করুন।

CLS হলো অল্প কয়েকটি performance metric-এর একটি, যেখানে cleverness-এর চেয়ে discipline বেশি কাজে লাগে। পেজে stable boxes থাকলে সাধারণত score ভালো হয়।

Field data এবং lab data দুটোই দরকারি, কিন্তু তারা আলাদা প্রশ্নের উত্তর দেয়

বিভিন্ন tool ভিন্ন সংখ্যা দেখায়—এটি বিভ্রান্তির একটি সাধারণ উৎস। এটি স্বাভাবিক।

Field data আসে বাস্তব ব্যবহারকারীদের কাছ থেকে। এটি বাস্তব devices, networks, locations এবং browser conditions প্রতিফলিত করে। Google-এর Chrome User Experience Report field data-র একটি উদাহরণ।

Lab data আসে controlled test environment থেকে। Lighthouse পরিচিত উদাহরণ। এটি repeatable এবং debugging-এর জন্য দরকারি, কিন্তু আপনার ব্যবহারকারীর lived experience-এর একই জিনিস নয়।

ব্যবহারকারীদের বাস্তব সমস্যা আছে কি না নির্ধারণ করতে field data ব্যবহার করুন। সেই সমস্যা reproduce এবং debug করতে lab data ব্যবহার করুন।

এটিও মনে রাখুন যে Core Web Vitals সাধারণত প্রতি URL বা URL group অনুযায়ী assess করা হয়, আপনার brand-এর কোনো একক abstract property হিসেবে নয়। আপনার home page, blog article, pricing page এবং checkout-এর bottleneck খুব ভিন্ন হতে পারে।

কাজের একটি যুক্তিসংগত ক্রম

তিনটি metric-ই খারাপ হলে সব জায়গা থেকে শুরু করার প্রলোভন থাকে। সেটি প্রতিরোধ করুন।

একটি ব্যবহারিক ক্রম হলো:

1. আগে obvious CLS ঠিক করুন

Missing image dimensions এবং unstable banners প্রায়ই quick win।

1. গুরুত্বপূর্ণ templates-এর LCP উন্নত করুন

গুরুত্বপূর্ণ page-এ focus করুন: product pages, landing pages, articles, sign-up flows।

1. Real interactions দিয়ে INP investigate করুন

ব্যবহারকারীরা আসলে যে জিনিসগুলো click করে, সেগুলো click করুন। Menus, filters, forms এবং checkout controls প্রাথমিক load trace-এর চেয়ে বেশি কিছু দেখাতে পারে।

1. Third-party scripts audit করুন

যেগুলো তাদের cost justify করে, সেগুলো রাখুন। যেগুলো করে না, সেগুলো remove বা delay করুন।

1. Performance budget সেট করুন

Budget ছাড়া performance improvement decay করে। নতুন scripts, images এবং design components নীরবে কাজটিকে undo করে দেবে।

গুরুত্বপূর্ণ কথা: badge-এর জন্য optimise করবেন না। User journey-এর জন্য optimise করুন। Low-traffic page-এ সামান্য score improvement-এর চেয়ে একটু imperfect কিন্তু অনেক দ্রুত checkout interaction বেশি গুরুত্বপূর্ণ হতে পারে।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: যেহেতু LCP সাধারণত ছবির সমস্যা, প্রথম সহজ সাফল্য হিসেবে Image Compressor দিয়ে আপনার হিরো অ্যাসেট ছোট করুন।

<!-- tool-cta:end -->

Core Web Vitals আপনাকে কী বলে না

Core Web Vitals দরকারি, কিন্তু অসম্পূর্ণ।

এগুলো বলে না আপনার content ভালো কি না। আপনার navigation যুক্তিযুক্ত কি না বলে না। Accessibility guarantee করে না। Privacy, security, trust, readability বা পেজটি ব্যবহারকারীর প্রশ্নের উত্তর দেয় কি না—সেগুলো মাপে না।

এগুলো judgment-এর replacement-ও নয়। কোনো পেজ Core Web Vitals pass করেও unpleasant হতে পারে। কোনো complex application threshold মিস করেও তার constraints অনুযায়ী responsibly engineered হতে পারে।

LCP, INP এবং CLS-কে smoke alarm হিসেবে দেখুন। এগুলো বাজলে investigate করুন। চুপ থাকলে building maintain করে যান।