← ব্লগে ফিরুন
ব্যবহারিক গাইডসাইটের গতিcore web vitalslcpinpcls

২০২৬-এ সাইটের গতি: Core Web Vitals, অফিসিয়াল সীমা এবং আমাদের মোবাইল ব্লগের ঘটনা

২০২৬-এ সাইটের গতি: Core Web Vitals, অফিসিয়াল সীমা এবং আমাদের মোবাইল ব্লগের ঘটনা

সার্ভার ০.২৩ সেকেন্ডে সাড়া দিচ্ছিল, তবু ফোনে লেখাগুলো একেবারেই দেখা যাচ্ছিল না। Core Web Vitals-এর অফিসিয়াল সীমা, সার্চে প্রভাব নিয়ে Google কী বলে, এবং আমাদের নিজের ঘটনা: কারণ, কভার ~২ MB থেকে ২১৩ KB এবং আপনার সাইটে কী দেখবেন।

Google কোন গতি-মাপকে মূল ধরে?

Google কোন গতি-মাপকে মূল ধরে?: চিত্র

Core Web Vitals তিনটি মাপ। LCP (লোডিং): সবচেয়ে বড় উপাদান ২.৫ সেকেন্ডের মধ্যে দেখা দিতে হবে। INP (প্রতিক্রিয়া): পাতাকে ২০০ মিলিসেকেন্ডের মধ্যে কাজে সাড়া দিতে হবে। CLS (দৃশ্য স্থিতি): লেআউট সরণ ০.১ বা কম। পাতা লোডের ৭৫তম পার্সেন্টাইলে, মোবাইল ও ডেস্কটপে আলাদাভাবে মাপা হয়, আর তিনটিই ভালো হলে তবেই পাতা পাস করে। INP ২০২৪-এ FID-এর জায়গা নিয়েছে। web.dev স্পষ্ট বলেছে, স্থিতিশীল মাপ বছরে একবারের বেশি বদলায় না; তাই কিছু ব্লগের «২০২৬-এর নতুন সীমা» Google নিশ্চিত করেনি।

গতি কি র‍্যাঙ্কিংয়ে প্রভাব ফেলে?

Google বলে, Core Web Vitals পাতার অভিজ্ঞতার অন্য দিকগুলোর সঙ্গে মিলে সেটিই প্রতিফলিত করে যা তার মূল র‍্যাঙ্কিং ব্যবস্থা পুরস্কৃত করতে চায়, এবং ভালো স্কোরের জোরালো পরামর্শ দেয়। র‍্যাঙ্কিংয়ে গতির আলাদা ওজন Google জানায়নি, তাই এটি জাদুর বোতাম নয়, শর্তগুলোর একটি। আসল ব্যবহারকারীর তথ্য Search Console-এর Core Web Vitals রিপোর্টে।

নিজেদের সাইটে আমরা কী পেলাম?

নিজেদের সাইটে আমরা কী পেলাম?: চিত্র

১১ নভেম্বর ২০২৬ আমরা ফোনে Metriverra ব্লগ খুলি — আর লেখা লোড হচ্ছিল «খুব ধীরে»। মাপে দেখা গেল সার্ভার ০.২৩ সেকেন্ডে সাড়া দিচ্ছে, অর্থাৎ সমস্যা সার্ভারে নয়। ১৯টি লেখার তালিকা ছিল একটি ব্লক, যাতে দেখা দেওয়ার অ্যানিমেশন ছিল — ব্লকের ১২% স্ক্রিনে এলে তবেই চালু হতো। ফোনে ব্লকের উচ্চতা ছিল ৮,৫০৯ পিক্সেল, স্ক্রিন ৮৪৪ — মাত্র ৯.৯%: সীমা কখনো ছোঁয়া যেত না, লেখাগুলো অদৃশ্য থাকত। তার ওপর কভার পাঠানো হতো পূর্ণ আকারে, তালিকায় প্রায় ২ MB। আমরা তালিকা থেকে অ্যানিমেশন সরিয়েছি, ১০ ও ৯টি লেখার পাতা করেছি এবং ছোট কভার পাঠাচ্ছি: ১২টি কভার প্রায় ২ MB-এর বদলে ২১৩ KB।

আপনার সাইটে কী যাচাই করবেন?

Search Console-এর Core Web Vitals রিপোর্ট খুলে মোবাইল পাতা দিয়ে শুরু করুন। শুধু সার্ভারের সাড়ার সময় নয়, আসল মোবাইল উইন্ডোতে পাতা দেখুন: স্ক্রিপ্ট চলার আগ পর্যন্ত লুকানো বিষয়বস্তু ব্যবহারকারী দেখবেনই না। স্ক্রিনের মাপে ছবি দিন (srcset), প্রথম স্ক্রিনের নিচের ছবি দেরিতে লোড করুন, কিন্তু মূল ছবি নয়। ছবির জায়গা আগে থেকে রাখুন যাতে লেআউট লাফায় না। আর মনে রাখুন, ভারী স্ক্রিপ্ট ও ট্যাগ প্রতিক্রিয়া, অর্থাৎ INP, খারাপ করে।

এখন কী করবেন

  1. Search Console-এর Core Web Vitals রিপোর্ট খুলুন এবং মোবাইল URL দিয়ে শুরু করুন।
  2. মূল পাতাগুলো মোবাইল উইন্ডোতে দেখুন: অ্যানিমেশন ও স্ক্রিপ্টের অপেক্ষা ছাড়াই বিষয়বস্তু দেখা যায় কিনা।
  3. স্ক্রিনের মাপে ছবি দিন এবং তালিকা ও কার্ডে ছোট কপি।
  4. প্রথম স্ক্রিনের মূল ছবি দেরিতে লোড করবেন না, শুধু নিচেরগুলো।
  5. প্রতিটি বড় পরিবর্তনের পর মাপ দেখুন, বছরে একবার নয়।

Metriverra-তে দর্শকের আচরণ ও কনভার্সন প্রতিদিন দেখা যায়, তাই গতি বদলের পর বাউন্স ও বিক্রির আগে-পরে তুলনা সহজ।

সংক্ষেপে

  • Google-এর সীমা: LCP ≤ ২.৫ সে., INP ≤ ২০০ মি.সে., CLS ≤ ০.১ (৭৫তম পার্সেন্টাইল)।
  • স্থিতিশীল মাপ বছরে সর্বোচ্চ একবার বদলায়; «২০২৬-এর নতুন সীমা» Google নিশ্চিত করেনি।
  • Google: Core Web Vitals তা-ই প্রতিফলিত করে যা র‍্যাঙ্কিং ব্যবস্থা পুরস্কৃত করে।
  • আমাদের ঘটনা: সার্ভার ০.২৩ সে., কিন্তু অ্যানিমেশনের কারণে ফোনে লেখা অদৃশ্য ছিল।
  • তালিকার কভার: ~২ MB → ২১৩ KB।

সূত্র: web.dev — Web Vitals · Google Search Central — Understanding Core Web Vitals and Google search results

পরেরটি পড়ুন

পরেরটি পড়ুন