অনলাইন স্টোরের Core Web Vitals: LCP, INP ও CLS সহজ ব্যাখ্যা

LCP, INP ও CLS কী মাপে, 75তম পার্সেন্টাইলে ভালো ও খারাপের সীমা, ল্যাব বনাম ফিল্ড ডেটা এবং Shopify ও WooCommerce স্টোরে স্পিড বাড়ানোর সাধারণ সমাধান।

FixReports সম্পাদকীয় দল12 মিনিটে পড়ুন

Core Web Vitals হলো Google-এর তিনটি মেট্রিক, যা দেখায় আসল ভিজিটররা একটি পেজ কেমন অনুভব করেন: লোডিংয়ের জন্য Largest Contentful Paint (LCP), সাড়া দেওয়ার গতির (responsiveness) জন্য Interaction to Next Paint (INP), এবং ভিজ্যুয়াল স্থিতিশীলতার জন্য Cumulative Layout Shift (CLS)। একটি পেজ পাস করে যখন অন্তত 75% ভিজিট “ভালো” (good) সীমার মধ্যে থাকে: LCP 2.5 সেকেন্ডের মধ্যে, INP 200 মিলিসেকেন্ডের মধ্যে এবং CLS 0.1 বা তার কম; মোবাইল ও ডেস্কটপের জন্য এগুলো আলাদাভাবে মাপা হয়। অনলাইন স্টোরে খারাপ স্কোরের পেছনে সাধারণত থাকে বড় বা lazy-load করা হিরো ও প্রোডাক্ট ছবি, অ্যাপ ও ট্র্যাকিং স্ক্রিপ্ট, ওয়েব ফন্ট, এবং পেজ দেখা দেওয়ার পর কনটেন্টকে নিচে ঠেলে দেওয়া ব্যানার বা রিভিউ উইজেট।

মূল বিষয়গুলো

  • ভালো, উন্নতি প্রয়োজন ও খারাপ, এই তিন শ্রেণি বিচার করা হয় পেজ লোডের 75তম পার্সেন্টাইলে: LCP 4 সেকেন্ডের বেশি হলে খারাপ, INP 500 ms-এর বেশি হলে খারাপ, CLS 0.25-এর বেশি হলে খারাপ (web.dev (নতুন ট্যাবে খোলে))।
  • 12 মার্চ 2024 তারিখে INP, First Input Delay (FID)-এর জায়গায় Core Web Vital হয় (web.dev (নতুন ট্যাবে খোলে))।
  • Chrome UX Report-এর ফিল্ড ডেটা হলো 28 দিনের চলমান (rolling) গড়, এবং এতে iOS-এর Chrome অন্তর্ভুক্ত নয় (Chrome for Developers (নতুন ট্যাবে খোলে))।
  • Shopify-এর image_tag ফিল্টার টেমপ্লেটের প্রথম তিনটি সেকশনে ছবি eager-ভাবে এবং চতুর্থ সেকশন থেকে lazy-ভাবে লোড করে, যদি না আপনি তা বদলে দেন (Shopify (নতুন ট্যাবে খোলে))।
  • WordPress 6.3 থেকে কোর (core) সেই ছবিতে fetchpriority="high" যোগ করে, যেটিকে সবচেয়ে সম্ভাব্য LCP এলিমেন্ট বলে মনে করে (Make WordPress Core (নতুন ট্যাবে খোলে))।

Core Web Vitals-এর সীমাগুলো (threshold) কী কী?

একটি পেজ Core Web Vitals পূরণ করে যখন তিনটি মেট্রিকের ক্ষেত্রেই এর পেজ লোডের 75তম পার্সেন্টাইল ভালো সীমায় পড়ে।

মেট্রিকযা মাপেভালোউন্নতি প্রয়োজনখারাপ
LCPভিউপোর্টের সবচেয়ে বড় ছবি, ভিডিও বা টেক্সট ব্লক রেন্ডার হওয়া পর্যন্ত সময়2.5 s বা কম2.5 s-এর বেশি থেকে 4.0 s পর্যন্ত4.0 s-এর বেশি
INPক্লিক, ট্যাপ বা কি প্রেস থেকে পরের ফ্রেম আঁকা (paint) পর্যন্ত সময়200 ms বা কম200 ms-এর বেশি থেকে 500 ms পর্যন্ত500 ms-এর বেশি
CLSদৃশ্যমান কনটেন্ট অপ্রত্যাশিতভাবে কতটা সরে যায়0.1 বা কম0.1-এর বেশি থেকে 0.25 পর্যন্ত0.25-এর বেশি

সীমাগুলো অক্টোবর 2026 অনুযায়ী web.dev-এর LCP (নতুন ট্যাবে খোলে), INP (নতুন ট্যাবে খোলে) ও CLS (নতুন ট্যাবে খোলে) গাইড থেকে নেওয়া।

75তম পার্সেন্টাইলের মানে হলো ফলাফলটি শুধু সবচেয়ে দ্রুত ভিজিটরদের নয়, বেশির ভাগ ভিজিটরের অভিজ্ঞতা প্রতিফলিত করে, এবং Google মোবাইল ও ডেস্কটপ আলাদা করে (নতুন ট্যাবে খোলে) দেখে। PageSpeed Insights একটি পেজকে পাস করায় যখন তিনটি মেট্রিকই ভালো থাকে; যথেষ্ট INP ডেটা না থাকলে এটি শুধু LCP ও CLS দিয়ে বিচার করে (PageSpeed Insights docs (নতুন ট্যাবে খোলে))। Google বলছে, স্থিতিশীল (stable) Core Web Vitals বছরে একবারের বেশি বদলাবে না।

একটি স্টোরে LCP এলিমেন্ট প্রায়ই হিরো ব্যানার বা প্রধান প্রোডাক্ট ছবি, আর এ কারণেই ছবি কীভাবে লোড হয় তা এত গুরুত্বপূর্ণ।

মার্চ 2024-এ INP কেন FID-এর জায়গা নিল?

INP, FID-এর জায়গা নিয়েছে কারণ FID শুধু প্রথম ইন্টারঅ্যাকশন এবং তার বিলম্বের একটি অংশ মাপত, অথচ INP পুরো ভিজিটজুড়ে সব ইন্টারঅ্যাকশন দেখে।

Google মে 2023-এ ঘোষণা করে যে INP একটি Core Web Vital হবে, এবং পরিবর্তনটি কার্যকর হয় 12 মার্চ 2024 (নতুন ট্যাবে খোলে) তারিখে। FID শুধু প্রথম ইন্টারঅ্যাকশন জানাত, তাও শুধু তার ইনপুট বিলম্ব (input delay); ইভেন্ট হ্যান্ডলার চালাতে বা ফলাফল আঁকতে যে সময় লাগে তা নয়। INP পুরো ভিজিটজুড়ে ক্লিক, ট্যাপ ও কি প্রেস পর্যবেক্ষণ করে এবং ব্যতিক্রমী মানগুলো (outliers) বাদ দিয়ে সবচেয়ে দীর্ঘটি জানায়; স্ক্রলিং ও হোভার এতে গণ্য হয় না। CrUX ও PageSpeed Insights API ব্যবহারকারীদের পরিবর্তনের জন্য 9 সেপ্টেম্বর 2024 পর্যন্ত সময় ছিল (web.dev (নতুন ট্যাবে খোলে))।

প্রতিটি ইন্টারঅ্যাকশনের তিনটি অংশ: ইনপুট বিলম্ব (input delay, ব্যস্ত স্ক্রিপ্ট শেষ হওয়ার অপেক্ষা), প্রসেসিং সময় (processing duration, হ্যান্ডলার চালানো) এবং উপস্থাপন বিলম্ব (presentation delay, পরের ফ্রেম আঁকা) (web.dev (নতুন ট্যাবে খোলে))।

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

ল্যাব ডেটা আর ফিল্ড ডেটার পার্থক্য কী?

ল্যাব ডেটা আসে নির্দিষ্ট অবস্থায় করা একটি পরীক্ষা থেকে, আর ফিল্ড ডেটা সময়ের সঙ্গে আসল ভিজিটরদের কাছ থেকে সংগ্রহ করা হয়; কোনটি আগে ঠিক করবেন তা ঠিক করতে Google ফিল্ড ডেটা ব্যবহারের পরামর্শ দেয় (web.dev (নতুন ট্যাবে খোলে))।

ল্যাব ডেটাফিল্ড ডেটা
উৎসএকটি সিমুলেটেড পেজ লোড (Lighthouse, Chrome DevTools, PageSpeed Insights-এর ল্যাব অংশ)আসল Chrome ভিজিটর (Chrome UX Report), অথবা আপনার নিজের রিয়েল ইউজার মনিটরিং
অবস্থানির্দিষ্ট ডিভাইস ও নেটওয়ার্ক। Lighthouse-এর ডিফল্ট মোবাইল টেস্ট (নতুন ট্যাবে খোলে) “Slow 4G” (150 ms রাউন্ড ট্রিপ, 1.6 Mbps ডাউনলোড) এবং 4x CPU স্লোডাউন ব্যবহার করেআপনার ভিজিটরদের যে ডিভাইস, নেটওয়ার্ক ও অবস্থান থাকে
INPসাধারণ পেজ লোডে মাপা হয় না। Total Blocking Time (TBT) একটি মোটামুটি বিকল্প নির্দেশকআসল ইন্টারঅ্যাকশন থেকে মাপা হয়
যার জন্য সবচেয়ে উপযোগীডিবাগিং এবং রিলিজের আগে কোনো পরিবর্তন যাচাইভিজিটররা আসলে কী পাচ্ছেন তা জানা

TBT প্রতিটি মেইন-থ্রেড টাস্কের 50 ms-এর বেশি অংশগুলো যোগ করে; web.dev গড়পড়তা মোবাইল হার্ডওয়্যারে 200 ms-এর নিচে রাখার পরামর্শ দেয়, তবে বলে এটি INP-এর বিকল্প নয় (web.dev (নতুন ট্যাবে খোলে))।

Chrome UX Report (CrUX)-এর তিনটি বিষয় স্টোরের জন্য গুরুত্বপূর্ণ:

  • এটি একটি 28 দিনের চলমান গড় (নতুন ট্যাবে খোলে), যা প্রতিদিন হালনাগাদ হয়।
  • এটি ডেস্কটপ ও Android-এর Chrome কভার করে, সেই ব্যবহারকারীদের জন্য যাঁরা Chrome-এর রিপোর্টিং শর্ত পূরণ করেন। iOS-এর Chrome বাদ পড়ে, তাই যে স্টোরের ক্রেতারা বেশির ভাগই iPhone ব্যবহার করেন, সেটি তার দর্শকদের একটি অংশেরই ফিল্ড ডেটা দেখতে পায় (methodology (নতুন ট্যাবে খোলে))।
  • পেজ ও অরিজিন তখনই দেখা যায় যখন সেগুলো প্রকাশ্যে খুঁজে পাওয়া যায় এবং যথেষ্ট জনপ্রিয়, তাই কম ট্রাফিকের স্টোরের হয়তো শুধু অরিজিন-স্তরের ডেটা থাকে, বা কিছুই থাকে না।

Shopify-এর web performance dashboard (নতুন ট্যাবে খোলে)-ও 75তম পার্সেন্টাইলে আসল ব্যবহারকারীদের LCP, INP ও CLS দেখায়, তবে 28 দিনের বদলে 30 দিনের হিসাবে, তাই CrUX-এর সঙ্গে কিছু পার্থক্য আশা করুন।

স্টোরের পেজে LCP ধীর হয় কেন?

স্টোরে LCP সাধারণত ধীর হয় কারণ প্রধান ছবিটি খুব ভারী, দেরিতে খুঁজে পাওয়া যায়, অথবা lazy loading বা অ্যানিমেশনের মাধ্যমে ইচ্ছাকৃতভাবে দেরি করানো হয়।

  • LCP ছবিকে lazy-load করা। web.dev বলে এটি কখনো করবেন না (web.dev (নতুন ট্যাবে খোলে))। WordPress পেজ নিয়ে এর বিশ্লেষণে দেখা গেছে, নেটিভ lazy loading ব্যবহার করা সাইটগুলোতে 75তম পার্সেন্টাইলের LCP ধীর ছিল, এবং প্রথম স্ক্রিনে (above the fold) থাকা ছবিগুলো lazy-load না করায় এই অবনতি দূর হয়েছে (web.dev (নতুন ট্যাবে খোলে))।
  • দেরিতে খুঁজে পাওয়া ছবি। CSS background-image হিসেবে সেট করা, বা স্লাইডার স্ক্রিপ্ট দিয়ে ঢোকানো হিরো ছবি ব্রাউজার প্রথমে যে HTML স্ক্যান করে তাতে থাকে না। Shopify হিরো কনটেন্টের জন্য CSS ব্যাকগ্রাউন্ড এবং LCP ছবিতে fade-in ইফেক্ট ব্যবহার না করার পরামর্শ দেয় (Shopify (নতুন ট্যাবে খোলে))।
  • কম অগ্রাধিকার। লেআউট সম্পূর্ণ না হওয়া পর্যন্ত ছবি কম অগ্রাধিকারে লোড হয়, তাই Shopify LCP ছবিতে fetchpriority="high" দেওয়ার পরামর্শ দেয় (Shopify (নতুন ট্যাবে খোলে))। web.dev মনে করিয়ে দেয়, এক বা দুটির বেশি ছবিতে এটি দিলে এর উপকারিতা কমে যায় (web.dev (নতুন ট্যাবে খোলে))।
  • রেন্ডার আটকে দেওয়া CSS ও স্ক্রিপ্ট। <head>-এ বড় স্টাইলশিট ও সিনক্রোনাস স্ক্রিপ্ট ছবি পৌঁছানোর পরেও রেন্ডারিং দেরি করায় (web.dev (নতুন ট্যাবে খোলে))।
  • ফাইলের আকার ও ফন্ট। আধুনিক ফরম্যাট, srcset ও sizes, এবং একটি CDN ব্যবহার করুন। ওয়েব ফন্টের জন্য auto বা block ছাড়া অন্য কোনো font-display মান ব্যবহার করুন।
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

স্টোরের পেজে INP ধীর হয় কেন?

স্টোরে INP ধীর হওয়ার মানে সাধারণত মেইন থ্রেডে অতিরিক্ত JavaScript, যার বড় অংশ আসে অ্যাপ, ট্র্যাকিং ট্যাগ ও থিম ফিচার থেকে, ফলে ট্যাপগুলোকে অপেক্ষা করতে হয়।

রিভিউ, চ্যাট ও অ্যানালিটিক্স স্ক্রিপ্ট চলতে থাকা অবস্থায় কোনো ক্রেতা “কার্টে যোগ করুন” (Add to cart) ট্যাপ করলে সেই ট্যাপ অপেক্ষায় থাকে। যে ভ্যারিয়েন্ট পিকার পুরো প্রোডাক্ট ফর্ম আবার রেন্ডার করে, সেটি প্রসেসিং সময় বাড়ায়। বিশাল মেগা মেনু এবং অনেক সোয়াচ (swatch) থাকা কালেকশন গ্রিড উপস্থাপন বিলম্ব বাড়ায়।

web.dev দীর্ঘ টাস্কগুলো ভেঙে ছোট করা ও মেইন থ্রেডকে সুযোগ ছেড়ে দেওয়া (yield), আগে স্ক্রিন হালনাগাদ করে বাকিটা পিছিয়ে দেওয়া, এবং DOM ছোট রাখার পরামর্শ দেয় (web.dev (নতুন ট্যাবে খোলে))। Shopify স্টোরের জন্য নির্দিষ্ট কিছু ধাপ যোগ করে: প্রতিটি অ্যাপ, পিক্সেল ও থিম স্ক্রিপ্ট অডিট করুন, যা জরুরি নয় তা পিছিয়ে দিন (defer), ফিচারগুলো ইন্টারঅ্যাকশনের সময় লোড করুন, এবং কোনো টেস্ট না চললে A/B টেস্টিংয়ের anti-flicker স্নিপেট বন্ধ রাখুন (Shopify (নতুন ট্যাবে খোলে))।

প্রোডাক্ট ও কালেকশন পেজে লেআউট শিফট হয় কেন?

স্টোরে লেআউট শিফট বেশির ভাগ আসে প্রথম রেন্ডারের পর দেখা দেওয়া বা আকার বদলানো কনটেন্ট থেকে: মাপ (dimension) ছাড়া ছবি, অ্যানাউন্সমেন্ট ও কুকি বার, রিভিউ উইজেট, অ্যাপ ব্লক এবং ফন্ট বদল (font swap)।

web.dev সাধারণ কারণগুলোর তালিকা দেয়: অজানা মাপের মিডিয়া, বিদ্যমান কনটেন্টের ওপরে যোগ হওয়া কনটেন্ট, নিজে নিজে আকার বদলানো তৃতীয় পক্ষের উইজেট, এবং ফলব্যাক ফন্টের থেকে আকারে আলাদা ওয়েব ফন্ট (web.dev (নতুন ট্যাবে খোলে))। স্টোরে এর মানে হলো ওপরে ঢুকিয়ে দেওয়া ফ্রি-শিপিং বার, শিরোনামের পরে লোড হওয়া স্টার রেটিং, দামের নিচে কিস্তির (installment) বার্তা, এবং রেকমেন্ডেশন ক্যারোসেল। Shopify মনে করিয়ে দেয়, পপ-আপ কনটেন্টও শিফট ঘটাতে পারে (Shopify (নতুন ট্যাবে খোলে))।

ব্যবহারকারীর ইনপুটের 500 ms-এর মধ্যে হওয়া শিফট গণ্য হয় না, কিন্তু স্ক্রল করার সময় হওয়া শিফট গণ্য হয়, এবং ল্যাব টুল প্রায়ই সেগুলো ধরতে পারে না (web.dev (নতুন ট্যাবে খোলে))। ছবিতে width ও height বা CSS aspect-ratio দিন, উইজেটের জন্য জায়গা সংরক্ষণ করুন, ব্যানারগুলো ওভারলে হিসেবে দেখান, size-adjust দিয়ে ফন্ট বদলের শিফট কমান, এবং top বা left-এর বদলে transform দিয়ে অ্যানিমেশন করুন।

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Shopify-তে Core Web Vitals কীভাবে উন্নত করবেন?

Shopify-তে বেশির ভাগ উন্নতি আসে প্রথম ছবিটি উচ্চ অগ্রাধিকারে eager-ভাবে লোড করা, অ্যাপ স্ক্রিপ্ট ছাঁটাই করা এবং অ্যাডমিনের web performance রিপোর্টে ফলাফল যাচাই করা থেকে।

অ্যাডমিনে ডেটা দেখুন

Online Store > Themes পেজে একটি সারসংক্ষেপ দেখা যায়, আর LCP, INP ও CLS-এর পূর্ণ রিপোর্ট আছে Analytics > Reports-এর অধীনে। ডেটা আসতে সর্বোচ্চ 36 ঘণ্টা দেরি হতে পারে, এবং প্রাইভেট মোড (private mode) বন্ধ থাকতে হবে (Shopify Help Center (নতুন ট্যাবে খোলে))।

Liquid-এ ছবি লোডিং নিয়ন্ত্রণ করুন

image_tag ফিল্টার পেজের নিচের দিকের সেকশনগুলোতে ছবি lazy-load করে, যদি না আপনি preload সেট করেন (image_tag reference (নতুন ট্যাবে খোলে)): সেকশন 1 থেকে 3-এ eager, সেকশন 4 থেকে lazy। থিম এডিটরে section.index-এর মান nil থাকে বলে <= 3-এর বদলে > 3 দিয়ে পরীক্ষা করুন:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

প্রোডাক্ট গ্রিডে Shopify শুধু প্রথম কয়েকটি কার্ড eager-ভাবে লোড করার পরামর্শ দেয় (যেমন forloop.index <= 4) (Shopify (নতুন ট্যাবে খোলে))। preload: true কম ব্যবহার করুন; Shopify দেরিতে খুঁজে পাওয়া মাত্র এক বা দুটি রিসোর্স preload করার পরামর্শ দেয়।

অ্যাপ যা রেখে যায় তা সরান

Online Store > Edit theme > App embeds-এর অধীনে অব্যবহৃত app embed বন্ধ করুন (Shopify Help Center (নতুন ট্যাবে খোলে))। কোনো অ্যাপ আনইনস্টল করলে তার app block সরে যায়, কিন্তু যে অ্যাপগুলো সরাসরি থিম ফাইল এডিট করেছে সেগুলো “ghost code” রেখে যেতে পারে, যা Shopify-এর মতে কোয়ালিটি ও পারফরম্যান্সের সমস্যা তৈরি করতে পারে (Shopify (নতুন ট্যাবে খোলে))। Shopify আরও জানিয়েছে, 1 মার্চ 2027 থেকে script tag আর চলবে না। ফন্টের জন্য Shopify বাইরের ফন্ট সার্ভিসের বদলে নিজস্ব CDN বা সিস্টেম ফন্ট ব্যবহারের পরামর্শ দেয় (Shopify (নতুন ট্যাবে খোলে))।

WooCommerce-এ Core Web Vitals কীভাবে উন্নত করবেন?

WooCommerce-এ নিশ্চিত করুন যে প্লাগইনগুলো WordPress-এর ছবির অগ্রাধিকার নির্ধারণকে বাতিল করে দিচ্ছে না, কার্ট ও চেকআউট ছাড়া সবকিছু ক্যাশ করুন, এবং অপ্রয়োজনে সব জায়গায় লোড হওয়া স্ক্রিপ্টগুলো সরিয়ে দিন।

  • কোরের ইমেজ হ্যান্ডলিং বজায় রাখুন। WordPress 6.3 (8 আগস্ট 2023-এ প্রকাশিত) থেকে কোর সম্ভাব্য LCP ছবিতে fetchpriority="high" যোগ করে (ডিফল্টভাবে অন্তত 50,000 বর্গ পিক্সেলের ছবিতে) এবং প্রথম তিনটি কনটেন্ট ছবিতে lazy loading বাদ দেয় (Make WordPress Core (নতুন ট্যাবে খোলে))। কোনো অপটিমাইজেশন প্লাগইন নিজস্ব lazy loading যোগ করলে দেখে নিন সেটি হিরো ও প্রধান প্রোডাক্ট ছবিকে বাদ রাখে কি না।
  • পেজ ক্যাশ করুন, কার্ট নয়। WooCommerce-এর গাইড সার্ভার বা প্লাগইনভিত্তিক পেজ ক্যাশিং ও একটি CDN ব্যবহারের পরামর্শ দেয়, তবে কার্ট ও চেকআউট পেজ ক্যাশের বাইরে রাখতে বলে (WooCommerce developer docs (নতুন ট্যাবে খোলে))।
  • cart fragments পরীক্ষা করুন। WooCommerce 7.8 থেকে cart fragments স্ক্রিপ্ট শুধু সেখানেই লোড হয় যেখানে একটি Cart উইজেট আছে, কিন্তু কিছু থিম সেই উইজেট হার্ড-কোড করে রাখে। Mini-Cart ব্লক cart fragments ব্যবহার করে না (WooCommerce developer blog (নতুন ট্যাবে খোলে))।
  • ভারী প্লাগইন খুঁজে বের করুন। ধীর প্লাগইন খুঁজতে WooCommerce, Query Monitor ব্যবহারের এবং জরুরি নয় এমন JavaScript পিছিয়ে দেওয়ার পরামর্শ দেয়।

আপনার লেআউটে প্রথম স্ক্রিনে তিনটির বেশি ছবি থাকলে আপনি WordPress-এর সীমা বাড়াতে পারেন:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

সংশোধনের ফল দেখা যেতে কত সময় লাগে?

ল্যাব টেস্টে সংশোধনের প্রভাব সঙ্গে সঙ্গে দেখা যায়, কিন্তু ফিল্ড ডেটায় পুরোপুরি প্রতিফলিত হতে প্রায় চার সপ্তাহ পর্যন্ত লাগে, কারণ CrUX আগের 28 দিনের গড় নেয়।

পরিবর্তনের আগে ও পরে কয়েকবার ল্যাব টেস্ট চালান, কারণ একেকবারের ফলাফল ভিন্ন হয়; তারপর PageSpeed Insights, Search Console-এর Core Web Vitals রিপোর্ট বা Shopify-এর রিপোর্টে ফিল্ড সংখ্যাগুলো লক্ষ করুন। একটি বিনামূল্যের স্ক্যান প্রায় এক মিনিটে প্রাথমিক ধারণা দেয়। পারফরম্যান্স সংশোধন রিপোর্ট একটি থ্রটল করা মোবাইল ল্যাব টেস্ট (slow 4G, 4x CPU) চালায় এবং Chrome UX Report-এর ফিল্ড ডেটা যোগ করে, যার মধ্যে আপনার স্টোরের জন্য Google-এর কাছে যথেষ্ট ডেটা থাকলে INP-ও থাকে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Core Web Vitals কি Google সার্চ র‍্যাংকিংয়ে প্রভাব ফেলে?

Google বলছে, Core Web Vitals তাদের র‍্যাংকিং সিস্টেম ব্যবহার করে, তবে ভালো স্কোর শীর্ষ অবস্থানের নিশ্চয়তা দেয় না, এবং পেজ এক্সপেরিয়েন্স খারাপ হলেও Google সবচেয়ে প্রাসঙ্গিক কনটেন্টই দেখায় (Google Search Central (নতুন ট্যাবে খোলে))।

PageSpeed Insights আমার স্টোরের জন্য কোনো ফিল্ড ডেটা দেখায় না কেন?

CrUX শুধু সেই পেজ ও অরিজিনগুলো অন্তর্ভুক্ত করে, যেগুলো প্রকাশ্যে খুঁজে পাওয়া যায় এবং যেগুলোতে যথেষ্টসংখ্যক যোগ্য Chrome ভিজিটর আছেন। কম ট্রাফিকের স্টোরের হয়তো শুধু অরিজিন-স্তরের ডেটা থাকে, বা কিছুই থাকে না, তাই ল্যাব টেস্ট ও আপনার প্ল্যাটফর্মের নিজস্ব রিপোর্টের ওপর নির্ভর করুন।

পাস করতে কি Lighthouse স্কোর 90 বা তার বেশি লাগবে?

না। Lighthouse পারফরম্যান্স স্কোর একটি ল্যাব ফলাফল, অথচ Core Web Vitals মূল্যায়ন 75তম পার্সেন্টাইলের ফিল্ড ডেটা ব্যবহার করে, তাই একটি পেজ মাঝারি Lighthouse স্কোর নিয়েও পাস করতে পারে, আবার উঁচু স্কোর নিয়েও ফেল করতে পারে।

সব প্রোডাক্ট ছবি কি lazy-load করা উচিত?

না। প্রথম স্ক্রিনের নিচের ছবিগুলো lazy-load করুন, কিন্তু হিরো ও প্রধান প্রোডাক্ট ছবি eager-ভাবে লোড করুন, এবং এদের একটিতে fetchpriority="high" দিন।

আমার মোবাইলের ফলাফল ডেস্কটপের চেয়ে খারাপ কেন?

Google মোবাইল ও ডেস্কটপ আলাদাভাবে মাপে, আর ফোনের প্রসেসর ও নেটওয়ার্ক ধীর। Lighthouse-এর মোবাইল টেস্ট Slow 4G প্রোফাইল ও 4x CPU স্লোডাউন দিয়ে সেই অবস্থা সিমুলেট করে।

তথ্যসূত্র

সব গাইড