Core Web Vitals পর্যবেক্ষণ

প্রকল্পের ডোমেইনের নির্বাচিত পাবলিক পৃষ্ঠার LCP, CLS ও লোডিংয়ের মেট্রিক দেখুন। প্রতি URL-এর পাঁচটি মেট্রিক এবং আলাদা হোমপেজের সারাংশে Speed Index পড়ুন; নির্দিষ্ট সংশোধন পরের ল্যাব ফলাফল দিয়ে যাচাই করুন। এগুলো নিয়ন্ত্রিত পরীক্ষা, বাস্তব ব্যবহারকারীর ফিল্ড ডেটা নয়।

Core Web Vitals পর্যবেক্ষণ করুন প্ল্যান তুলনা করুন

Core Web Vitals পরীক্ষা

LCP

যেসব নির্বাচিত URL-এ মূল কনটেন্ট দেরিতে দেখা যায়, সেগুলো খুঁজুন।

CLS

নির্বাচিত URL-এ অপ্রত্যাশিত লেআউট পরিবর্তন পরীক্ষা করুন।

দৈনিক ল্যাব পরীক্ষা

বর্তমান মান লিখে রাখুন এবং নির্দিষ্ট সংশোধনের পরে পরবর্তী ল্যাব ফলাফল দেখুন।

পর্যবেক্ষিত URL-এর ল্যাব পারফরম্যান্স মেট্রিক দেখানো Screpy Core Web Vitals ড্যাশবোর্ড
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Uber-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Philips-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে FedEx Express-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Bosch-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Champion-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Iconfinder-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে T-Mobile-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Carrefour-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Stanley-এর লোগো
Screpy SEO প্ল্যাটফর্মের গ্রাহক আস্থা বিভাগে Skoda-এর লোগো

Largest Contentful Paint পর্যবেক্ষণ করুন

Largest Contentful Paint মাপে পরীক্ষার দৃশ্যমান অংশে পরিমাপের উপযুক্ত সবচেয়ে বড় ছবি, লেখার ব্লক বা ভিডিও কখন দেখা যায়। পর্যবেক্ষিত প্রতিটি URL-এর LCP দিয়ে বেছে নিন কোন পৃষ্ঠার লোডিং আরও বিস্তারিতভাবে পরীক্ষা করা দরকার।

  • Screpy LCP সেকেন্ডে দেখায়: ২.৫ সেকেন্ড পর্যন্ত ভালো, ২.৫-এর বেশি থেকে ৪ সেকেন্ড পর্যন্ত উন্নতি দরকার এবং ৪ সেকেন্ডের বেশি হলে দুর্বল।
  • FCP দ্রুত কিন্তু LCP ধীর হলে মূল উপাদানের আগে কিছু কনটেন্ট দেখা গেছে। পুরো পৃষ্ঠা ফাঁকা ছিল ধরে না নিয়ে ওই উপাদান কীভাবে আসে ও দৃশ্যমান হয় তা পরীক্ষা করুন।
  • ডেভেলপারের পারফরম্যান্স বিশ্লেষণ দিয়ে সংশ্লিষ্ট ছবি, ফন্ট বা রেন্ডারিংয়ের বিলম্ব নিশ্চিত করুন। সংখ্যাটি একা উপাদান শনাক্ত করে না বা কোন সংশোধন করতে হবে বলে দেয় না।

Cumulative Layout Shift পরিমাপ করুন

পৃষ্ঠা দ্রুত লোড হলেও কোনো বোতাম বা অনুচ্ছেদ অপ্রত্যাশিতভাবে সরে যেতে পারে। Cumulative Layout Shift পর্যবেক্ষিত প্রতিটি URL-এর ল্যাব স্থিতিশীলতার স্কোর দেয়, যাতে লোডিংয়ের গতি থেকে আলাদা করে এই নড়াচড়া পরীক্ষা করতে পারেন।

  • CLS সময়ের পরিমাপ নয়: Screpy-তে ০.১ পর্যন্ত ভালো, ০.১-এর বেশি থেকে ০.২৫ পর্যন্ত উন্নতি দরকার এবং ০.২৫-এর বেশি হলে দুর্বল।
  • ছবি, বিজ্ঞাপন ও এমবেড করা কনটেন্টের জন্য রাখা জায়গা এবং ফন্টের পরিবর্তন দেখুন। এগুলো সম্ভাব্য কারণ; Screpy-এর স্কোর কোন উপাদান সরেছে তা শনাক্ত করে না।
  • লোডিং পরীক্ষায় কম CLS পেলেই ভিজিটের পরের দিকে কোনো নড়াচড়া নেই বলা যায় না। লোডিং শেষ হওয়ার পরে সমস্যা দেখা দিলে সংশ্লিষ্ট ইন্টারঅ্যাকশন ও বাস্তব ব্যবহারকারীর ফিল্ড ডেটা দেখুন।

Total Blocking Time পরীক্ষা করুন

Total Blocking Time লোডিংয়ের সময় ব্যবহারকারীর ইনপুটে সাড়া দিতে দেরি করাতে পারে এমন মূল থ্রেডের কাজ বুঝতে সাহায্য করে। LCP ও FCP-এর সঙ্গে TBT পড়ুন: কনটেন্ট দ্রুত দেখা গেলেই পৃষ্ঠা দ্রুত সাড়া দিতে পারবে এমন নয়।

  • TBT মিলিসেকেন্ডে দেখানো হয়: ২০০ ms পর্যন্ত ভালো, ২০০-এর বেশি থেকে ৬০০ ms পর্যন্ত উন্নতি দরকার এবং ৬০০ ms-এর বেশি হলে দুর্বল।
  • ব্লকিং সময় হলো পরিমাপের সময়সীমার মধ্যে দীর্ঘ কাজগুলোর ৫০ ms-এর বেশি অংশের যোগফল। এটি JavaScript চলার মোট সময় নয়।
  • TBT বেশি হলে কোড বদলানোর আগে ডেভেলপার টুল দিয়ে দীর্ঘ কাজ ও অপ্রয়োজনীয় স্ক্রিপ্ট বিশ্লেষণ করুন। ড্যাশবোর্ডের মান কোনো নির্দিষ্ট স্ক্রিপ্টকে বিলম্বের কারণ হিসেবে শনাক্ত করে না।
  • TBT, INP নয়। INP ইন্টারঅ্যাকশন মাপে এবং সেই ইন্টারঅ্যাকশন চালিয়ে ল্যাবেও পরীক্ষা করা যায়; Screpy-এর এই ফিচার INP পরিমাপ জানায় না।

FCP ও TTFB তুলনা করুন

First Contentful Paint প্রথম দৃশ্যমান কনটেন্টের সময় জানায়; Time to First Byte জানায় কখন প্রতিক্রিয়া আসতে শুরু করেছে। একই URL-এর দুটো মান পড়লে প্রাথমিক প্রতিক্রিয়ার বিলম্বকে কনটেন্ট স্ক্রিনে দেখাতে লাগা সময় থেকে আলাদা করতে পারেন।

  • FCP সেকেন্ডে দেখানো হয়: ১.৮ সেকেন্ড পর্যন্ত ভালো, ১.৮-এর বেশি থেকে ৩ সেকেন্ড পর্যন্ত উন্নতি দরকার এবং ৩ সেকেন্ডের বেশি হলে দুর্বল।
  • TTFB মিলিসেকেন্ডে দেখানো হয়: ৮০০ ms পর্যন্ত ভালো, ৮০০-এর বেশি থেকে ১,৮০০ ms পর্যন্ত উন্নতি দরকার এবং ১,৮০০ ms-এর বেশি হলে দুর্বল। সংযোগ, রিডাইরেক্ট ও প্রতিক্রিয়ার আচরণ এর ওপর প্রভাব ফেলতে পারে।
  • TTFB কম কিন্তু FCP ধীর হলে প্রথম কনটেন্ট কী আটকে দিচ্ছে পরীক্ষা করুন। প্রতিক্রিয়া ধীর হলে আগে কনটেন্ট পৌঁছানোর দিকটি দেখুন; কোনো একটি মান একা সার্ভার বা রেন্ডারিংয়ের কারণ প্রমাণ করে না।

গুরুত্বপূর্ণ ওয়েবপৃষ্ঠা পর্যবেক্ষণ করুন

একটি হোমপেজের ফলাফলকে পুরো সাইটের ফলাফল মনে না করে প্রকল্পের বাছাই করা পাবলিক পৃষ্ঠাগুলো পর্যবেক্ষণ করুন। প্ল্যানে প্রকল্পের জন্য থাকা সীমা ব্যবহার করুন সেই পৃষ্ঠায়, যেখানে লোডিং বা লেআউট সমস্যা সবচেয়ে বেশি প্রভাব ফেলবে।

  • প্রকল্প তৈরি হলে তার হোমপেজ যোগ হয়। প্ল্যানে পর্যবেক্ষণের সুযোগ থাকলে প্রকল্পের ডোমেইন বা সাবডোমেইনের আরও পাবলিক URL যোগ করুন।
  • পণ্য, বিভাগ, নিবন্ধ ও কনভার্সনের প্রবেশ পৃষ্ঠা থেকে প্রতিনিধিত্বমূলক URL বেছে নিন। একই টেমপ্লেটের পুনরাবৃত্ত সমস্যা আরও তদন্তের কারণ হতে পারে, কিন্তু একটি URL পরীক্ষা সেই টেমপ্লেটের সব পৃষ্ঠা মাপে না।
  • URL যোগ করার সময় প্রোটোকল ও হোস্টের রূপ এক করা হয়, না থাকলে HTTPS যোগ হয় এবং ফ্র্যাগমেন্ট বাদ যায়। পাথ ও কোয়েরি প্যারামিটার গুরুত্বপূর্ণ থাকে; একই স্বাভাবিকীকৃত URL আবার যোগ করা যায় না।
  • যোগ করা পৃষ্ঠা ফলাফলের টেবিলে দেখা যাওয়ার আগে প্রথম নির্ধারিত পরীক্ষার জন্য অপেক্ষা করে। URL যোগ করলেই সঙ্গে সঙ্গে পরীক্ষা শুরু হয় না।
  • সরানো নিশ্চিত করে পৃষ্ঠার পর্যবেক্ষণ বন্ধ করুন এবং সীমার মধ্যে জায়গা খালি করুন। পর্যবেক্ষিত রেকর্ড সরানো হয়; পৃষ্ঠা আপনার সাইট বা Google থেকে মুছে যায় না।

হোমপেজের পারফরম্যান্স দেখুন

URL টেবিলের উপরের সারাংশ প্রকল্পের পরীক্ষা করা হোমপেজ ব্যবহার করে। এতে Speed Index-সহ বর্তমান ল্যাব পরিমাপ একসঙ্গে থাকে; নিচের টেবিলে দেখানো পাঁচটি মেট্রিক প্রতিটি পর্যবেক্ষিত URL-এর জন্য আলাদা থাকে।

  • হোমপেজের সারাংশে FCP, LCP, CLS, TTFB, TBT ও Speed Index পড়ুন। এগুলো হোমপেজের মান, পর্যবেক্ষিত পৃষ্ঠাগুলোর গড় নয়।
  • Speed Index জানায় লোডিংয়ের সময় দৃশ্যমান কনটেন্ট কত দ্রুত তৈরি হয়। Screpy সেকেন্ড দেখায়: ৩.৪ পর্যন্ত ভালো, ৩.৪-এর বেশি থেকে ৫.৮ পর্যন্ত উন্নতি দরকার এবং ৫.৮-এর বেশি হলে দুর্বল।
  • প্রতিটি বার বর্তমান পরিমাপ দেখায়। এটি সংরক্ষিত প্রবণতার গ্রাফ, দর্শকের শতাংশ বা Google-এর ফিল্ড ডেটার ৭৫তম পার্সেন্টাইল নয়।
  • হোমপেজের পরীক্ষা করা ফলাফল না থাকলে সারাংশ পাওয়া যায় না। অন্য কোনো পর্যবেক্ষিত URL-এর ফলাফল তার বদলে দেওয়া হয় না।

দৈনিক ল্যাব পরীক্ষা অনুসরণ করুন

উপযুক্ত সক্রিয় পৃষ্ঠা এক দিন পরে পরবর্তী নির্ধারিত পরীক্ষার জন্য যোগ্য হয়। নির্দিষ্ট পরিবর্তনের পর বর্তমান ফলাফল দেখুন; ঠিক একটি নির্দিষ্ট সময়ে পরীক্ষা হবে ধরে না নিয়ে প্ল্যানের যোগ্যতা ও পরীক্ষা সম্পন্ন হওয়ার অবস্থা বিবেচনা করুন।

  • ফলাফল পৃষ্ঠার URL বা CWV অবস্থা অনুযায়ী সাজিয়ে পর্যালোচনা করুন। প্রতিটি পরীক্ষিত URL-এর FCP, LCP, CLS, TTFB ও TBT দেখা যায়।
  • CWV ব্যাজ উপলব্ধ LCP, CLS ও TBT-এর সবচেয়ে দুর্বল শ্রেণি ব্যবহার করে। পাস মানে এই উপলব্ধ মানগুলো ভালো; FAIL-এর মধ্যে উন্নতি দরকার ও দুর্বল দুটোই পড়ে।
  • সারিতে পাস থাকলেও অনুপস্থিত মানগুলো পরীক্ষা করুন। কোনো মেট্রিক না থাকা ভালো পরিমাপ হিসেবে গণনা হয় না; ব্যাজ Google-এর বাস্তব ব্যবহারকারীর LCP, INP ও CLS মূল্যায়নের নিশ্চয়তা দেয় না।
  • কোনও ডেটা নেই মানে ল্যাবের সিদ্ধান্ত পাওয়া যাচ্ছে না। কোনো মান না থাকা শূন্য নয় এবং ব্যর্থ পরীক্ষা পৃষ্ঠা সুস্থ থাকার প্রমাণ নয়।
  • সংশোধন প্রকাশের আগে বর্তমান মানগুলো লিখে রাখুন, তারপর একই URL-এর পরের ফলাফলের সঙ্গে তুলনা করুন। টেবিলে বর্তমান ফলাফল থাকে, আগের ও পরের সংরক্ষিত ইতিহাস নয়।

SEO MCP দিয়ে পারফরম্যান্স ডেটা পড়ুন

হোমপেজের সংরক্ষিত ল্যাব সারাংশ AI কথোপকথন বা REST ইন্টিগ্রেশনে ব্যবহার করুন। উপলব্ধ পরিমাপের ব্যাখ্যা ও নির্দিষ্ট তদন্তের পরামর্শ চান, তবে প্রমাণকে প্রস্তাবিত সংশোধন থেকে আলাদা রাখুন।

  • পরিচয় যাচাই করে আপনার প্রবেশাধিকার আছে এমন প্রকল্প বেছে নিন। REST ব্যবহারের জন্য প্রকল্পের প্ল্যানে Core Web Vitals উপলব্ধ থাকাও দরকার।
  • উত্তরে হোমপেজের URL, সংরক্ষিত পরীক্ষার সময় এবং উপলব্ধ FCP, LCP, CLS, TTFB, TBT ও Speed Index থাকে। এটি হোমপেজের ডেটা, সব পর্যবেক্ষিত পৃষ্ঠার তালিকা নয়।
  • পরীক্ষা করা হোমপেজ না থাকলে সারাংশ ফেরে না; আলাদা কোনো পরিমাপ না থাকলে সেটি অনুপলব্ধই থাকে। সিদ্ধান্তের আগে সহকারীকে ডেটার ঘাটতি চিহ্নিত করতে বলুন।
  • Core Web Vitals MCP টুল সংরক্ষিত ডেটা পড়ে। এটি নতুন পরীক্ষা শুরু করে না, পৃষ্ঠা যোগ করে না, দায়ী উপাদান শনাক্ত করে না এবং TBT-কে INP-তে রূপান্তর করে না।

Core Web Vitals নিয়ে কথা বলুন। SEO MCP দিয়ে।

SEO MCP দিয়ে প্রকল্পের হোমপেজের সংরক্ষিত ল্যাব সারাংশ পড়ুন। URL ও পরীক্ষার সময়সহ উপলব্ধ মেট্রিক বুঝুন এবং কী তদন্ত করবেন বাছুন; সব পৃষ্ঠার রিপোর্ট বা নতুন পরীক্ষা পাওয়ার ধারণা করবেন না।

  1. Screpy: হ্যালো! example.com-এর জন্য Core Web Vitals দেখি। আপনি কী জানতে চান?
  2. আপনি: example.com-এর হোমপেজের সংরক্ষিত ল্যাব ফলাফল ব্যাখ্যা করো এবং কী এখনও জানা নেই বলো।
  3. Screpy: হোমপেজের এই উদাহরণে LCP ৩.২ সেকেন্ড, তাই উন্নতি দরকার; CLS ০.০৪ এবং ভালো। মান ব্যবহারের আগে সংরক্ষিত URL ও পরীক্ষার সময় দেখুন। এই দুটি সংখ্যা সব মেট্রিক দেখায় না, INP মাপে না বা দায়ী উপাদান শনাক্ত করে না। তদন্তের পরামর্শ দিতে পারি, নতুন পরীক্ষা চালাতে পারি না। হোমপেজের ল্যাব মানের উদাহরণ: LCP: ৩.২ সেকেন্ড. CLS: ০.০৪.
  4. আপনি: এটিকে একটি ছোট কর্মপরিকল্পনায় সাজাও।
  5. Screpy: তথ্যভিত্তিক ফলাফল ও পরামর্শ আলাদা রাখব। প্রমাণ দেখুন, একটি পরিবর্তন বেছে নিন এবং পরে ফলাফল যাচাই করুন। আপনার পরবর্তী পদক্ষেপ: পর্যালোচনা: প্রতিটি ফলাফলের উৎস ও তারিখ যাচাই করুন।. সিদ্ধান্ত: প্রথম পরিবর্তনটি বেছে নিন।. যাচাই: পরিবর্তনের পর ফলাফল তুলনা করুন।.
  6. আপনি: প্রমাণগুলো সহজ ভাষায় বুঝিয়ে দিতে পারো?
  7. Screpy: হ্যাঁ। সমর্থিত কোনো ফলাফল সম্পর্কে জিজ্ঞেস করলে সেটি কী দেখায়, কোথা থেকে এসেছে এবং কী অনিশ্চিত রয়েছে তা ব্যাখ্যা করতে পারি। অনুপস্থিত ডেটা অনুপস্থিতই থাকে; পরামর্শ মানেই স্বয়ংক্রিয় সংশোধন নয়।

ধীর URL-কে পরীক্ষাযোগ্য পারফরম্যান্স সংশোধনে রূপ দিন।

URL ও পরিমাপ পদ্ধতি স্থির রাখুন, দুর্বলতম মেট্রিক দিয়ে তদন্ত সীমিত করুন এবং পরবর্তী পরীক্ষায় একটি পরিবর্তন যাচাই করুন।

  1. 01

    প্রতিনিধিত্বমূলক পাবলিক URL বেছে নিন

    প্রকল্পের ডোমেইন বা সাবডোমেইনের পাবলিক URL বেছে নিন। প্রকল্পের সীমার মধ্যে হোমপেজ, কনভার্সনের প্রবেশ পৃষ্ঠা ও গুরুত্বপূর্ণ টেমপ্লেটের একটি প্রতিনিধিত্বমূলক URL দিয়ে শুরু করুন।

  2. 02

    নির্ধারিত ল্যাব পরীক্ষায় বেসলাইন তৈরি হতে দিন

    উপযুক্ত সক্রিয় URL নিয়মিত নির্ধারিত ল্যাব পরীক্ষা পায়। প্রথম চেষ্টার পরে পরীক্ষিত URL-এর উপলব্ধ FCP, LCP, CLS, TTFB ও TBT দেখুন; আলাদা হোমপেজের সারাংশে Speed Index-ও থাকে।

  3. 03

    দুর্বল মেট্রিক থেকে লক্ষ্যভিত্তিক অনুমানে যান

    দুর্বল মেট্রিক অনুযায়ী নির্দিষ্ট তদন্ত বাছুন: মূল কনটেন্টের জন্য LCP, অপ্রত্যাশিত নড়াচড়ার জন্য CLS, ব্লকিং কাজের জন্য TBT এবং প্রাথমিক লোডিংয়ের জন্য FCP ও TTFB। হোমপেজের Speed Index দৃশ্যমান অগ্রগতির প্রেক্ষাপট দেয়, কোনো কারণ প্রমাণ করে না।

  4. 04

    একটি কারণ বদলে আবার মাপুন

    নির্দিষ্ট পরিবর্তনের আগে বর্তমান মান লিখে রাখুন, URL স্থির রাখুন এবং পরবর্তী নির্ধারিত ফলাফল তুলনা করুন। প্যানেলে বর্তমান পরিমাপ থাকে: আগের মান আলাদা করে রাখুন এবং একবারের ওঠানামাকে প্রমাণ না ধরে পুনরাবৃত্ত পরিবর্তন পরীক্ষা করুন।

অবনতি সবচেয়ে গুরুত্বপূর্ণ হবে এমন পৃষ্ঠা পর্যবেক্ষণ করুন।

কম-মূল্যের পৃষ্ঠায় ভরা ড্যাশবোর্ডের চেয়ে ছোট, প্রতিনিধিত্বমূলক URL সেট তদন্ত করা সহজ। ব্যবসার জন্য গুরুত্বপূর্ণ যাত্রা ও পুনর্ব্যবহারযোগ্য টেমপ্লেট দিয়ে শুরু করুন।

প্রধান ল্যান্ডিং পৃষ্ঠা

পণ্য, সেবা বা ক্যাম্পেইন পরিচয় করানো পৃষ্ঠা পর্যবেক্ষণ করুন, কারণ ধীর প্রথম অভিজ্ঞতা আবিষ্কার ও কনভার্সন—উভয় কাজকে প্রভাবিত করতে পারে।

শেয়ার করা পৃষ্ঠা টেমপ্লেট

একই টেমপ্লেটে পুনরাবৃত্ত হতে পারে এমন পারফরম্যান্স সমস্যা প্রকাশ করতে প্রতিনিধিত্বমূলক একটি পণ্য, বিভাগ, নিবন্ধ বা ডকুমেন্টেশন URL বেছে নিন।

কনভার্সন পাথ

স্ক্রিপ্ট, এমবেড, পরীক্ষা বা তৃতীয়-পক্ষ ট্যাগ পারফরম্যান্স বদলালে মূল্য, সাইনআপ, লিড ও চেকআউট প্রবেশ পৃষ্ঠা দৃশ্যমান রাখুন।

রিলিজ-সংবেদনশীল পৃষ্ঠা

একই ধরণ বিস্তৃতভাবে প্রয়োগের আগে পুনর্নকশা, ফ্রেমওয়ার্ক পরিবর্তন, নতুন মিডিয়া, ট্যাগ-ম্যানেজার আপডেট বা ডেলিভারি পরিবর্তনে প্রভাবিত URL ট্র্যাক করুন।

ল্যাব ফলাফল অতিরঞ্জিত না করে ব্যাখ্যা করুন।

Screpy নিয়মিত পারফরম্যান্স পরীক্ষা কার্যকর করার জন্য তৈরি। প্রকৃত প্রশ্ন ফিল্ড ডেটা, কারণ নির্ণয় বা র‍্যাঙ্কিং প্রভাব হলে এই সীমাগুলো ফলাফলকে সঠিক রাখে।

ল্যাব ডেটা, ফিল্ড ডেটা নয়

Screpy নিয়ন্ত্রিত পৃষ্ঠা পরীক্ষা চালায়। ফলাফল Chrome UX Report বা Google Search Console-এ জানানো চলমান বাস্তব ব্যবহারকারী ডেটাসেটকে প্রতিনিধিত্ব করে না।

TBT, INP নয়

TBT পরিমাপ করা লোডিং সময়ের ব্লকিং কাজ বোঝায়। INP-এর জন্য ইন্টারঅ্যাকশন পরিমাপ দরকার এবং ইন্টারঅ্যাকশন চালিয়ে ল্যাবেও পরীক্ষা করা যায়; তবে Screpy-এর এই ফিচার INP দেয় না বা বাস্তব ব্যবহারকারীর প্রতিক্রিয়ার প্রমাণের বিকল্প হয় না।

সিদ্ধান্ত মূল কারণ নয়

দুর্বল মেট্রিক কোথায় তদন্ত করবেন তা জানায়। কী বদলাবেন ঠিক করার আগে প্রকৃত এলিমেন্ট, অনুরোধ, স্ক্রিপ্ট, টেমপ্লেট বা সার্ভার আচরণ নিশ্চিত করুন।

পারফরম্যান্স র‍্যাঙ্কিংয়ের নিশ্চয়তা নয়

ভালো পৃষ্ঠা অভিজ্ঞতা ব্যবহারকারী ও সার্চের মানকে সহায়তা করে, তবে প্রাসঙ্গিক কনটেন্ট, ক্রলযোগ্যতা, ইনডেক্সিং, লিংক বা অন্যান্য সার্চ সংকেতের বিকল্প নয়।

প্রশ্নের সঙ্গে মানানসই পারফরম্যান্স ওয়ার্কফ্লো ব্যবহার করুন।

নির্বাচিত URL-এর নিয়মিত ল্যাব ফলাফল পর্যবেক্ষণ করুন, পুনরাবৃত্ত প্রযুক্তিগত ধরণের জন্য বিস্তৃত ওয়েবসাইট অডিট করুন অথবা Screpy-কে ফিল্ড-ডেটা রিপোর্টের সঙ্গে তুলনার আগে পরিমাপ পদ্ধতি পড়ুন।

Screpy ডকুমেন্টেশন

ল্যাব পারফরম্যান্স পরীক্ষা ব্যাখ্যা করতে শিখুন

URL বাছাই, ল্যাব মেট্রিক পড়া ও ফিল্ড ডেটা থেকে আলাদা করতে গাইড ব্যবহার করুন। নির্দিষ্ট উন্নতি পরবর্তী ফলাফল দিয়ে যাচাই করার আগে শুরুর মান আলাদা করে লিখে রাখুন।

Core Web Vitals গাইড পড়ুন

Core Web Vitals-এর সাধারণ প্রশ্ন

ল্যাব বনাম ফিল্ড ডেটা, LCP, CLS, TBT, সহায়ক স্পিড মেট্রিক, দৈনিক পরীক্ষা, URL বাছাই, সিদ্ধান্ত ও পৃষ্ঠা-অভিজ্ঞতার দাবির সীমা বুঝুন।

Screpy কেন INP-এর বদলে TBT দেখায়?

এই ফিচার লোডিং মাপে ও ব্লকিংয়ের নির্দেশক হিসেবে TBT দেয়; INP-এর জন্য দরকারি ইন্টারঅ্যাকশন মাপে না। ইন্টারঅ্যাকশন চালিয়ে INP ল্যাবেও পরীক্ষা করা যায়, তবে TBT মান INP নয় এবং লোডিংয়ের পরের সব ইন্টারঅ্যাকশন বোঝায় না।

পর্যবেক্ষিত URL কত ঘন ঘন পরীক্ষা করা হয়?

উপযুক্ত সক্রিয় URL এক দিন পরে পরবর্তী নির্ধারিত পরীক্ষার যোগ্য হয়। প্রকল্পের প্ল্যান ও পরীক্ষা সম্পন্ন হওয়ার সুযোগ সময়কে প্রভাবিত করে; প্রতিদিন একই সময়ে ফলাফলের নিশ্চয়তা নেই। নতুন URL প্রথম পরীক্ষার চেষ্টার পরে টেবিলে দেখা যায়।

Screpy Core Web Vitals পর্যবেক্ষণ কী পরিমাপ করে?

Screpy-এর URL টেবিলে ল্যাবের FCP, LCP, CLS, TTFB ও TBT থাকে। পরীক্ষা করা হোমপেজের সারাংশে Speed Index-ও থাকে। টেবিলে পাস/FAIL সিদ্ধান্ত দেখা যায়; পরিচয় যাচাই করা API ও MCP উত্তরে হোমপেজের URL ও সংরক্ষিত পরীক্ষার সময়ও থাকে। এগুলো বাস্তব ব্যবহারকারীর পরিমাপ নয়।

Screpy-তে পাস মানে কি URL Google-এর Core Web Vitals পাস করেছে?

না। টেবিলের সিদ্ধান্ত উপলব্ধ ল্যাব LCP, CLS ও TBT-এর সবচেয়ে দুর্বল শ্রেণি ব্যবহার করে এবং কিছু মান অনুপস্থিত থাকতে পারে। Google INP-সহ বাস্তব ব্যবহারকারীর Core Web Vitals ডেটা নিজস্ব ডেটার প্রাপ্যতা ও পার্সেন্টাইলের নিয়মে মূল্যায়ন করে। এই সিদ্ধান্তের আগে উপলব্ধ মেট্রিক ও সংশ্লিষ্ট ফিল্ড রিপোর্ট দেখুন।

প্রথমে কোন পৃষ্ঠা পর্যবেক্ষণ করা উচিত?

হোমপেজ, গুরুত্বপূর্ণ পাবলিক ল্যান্ডিং পৃষ্ঠা, কনভার্সনের প্রবেশ পৃষ্ঠা ও গুরুত্বপূর্ণ প্রতিটি টেমপ্লেটের একটি প্রতিনিধিত্বমূলক URL দিয়ে শুরু করুন। যোগ করা URL প্রকল্পের ডোমেইন বা সাবডোমেইনের হতে হবে এবং প্ল্যানের সীমায় থাকতে হবে। একটি টেমপ্লেট নমুনা তার সব পৃষ্ঠা পরীক্ষা করে না।

কোন মেট্রিকগুলো অফিসিয়াল Core Web Vitals?

Google বর্তমানে Largest Contentful Paint, Interaction to Next Paint ও Cumulative Layout Shift-কে Core Web Vitals হিসেবে সংজ্ঞায়িত করে। Screpy ল্যাব পরীক্ষায় LCP ও CLS মাপে এবং FCP, TTFB ও Speed Index-এর পাশে TBT-কে ল্যাব প্রতিক্রিয়াশীলতার ডায়াগনস্টিক হিসেবে জানায়; TBT-কে INP হিসেবে দেখায় না।

Core Web Vitals উন্নত করলে কি উচ্চ র‍্যাঙ্কিং নিশ্চিত হবে?

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

Screpy Core Web Vitals ডেটা কি বাস্তব ব্যবহারকারীর ওপর ভিত্তি করে?

না। Screpy পরীক্ষিত URL-এর নিয়ন্ত্রিত ল্যাব পরিমাপ জানায়। Chrome UX Report বা Google Search Console-এর ফিল্ড ডেটা চলমান সংগ্রহ সময়ে বাস্তব ভিজিট প্রতিফলিত করে এবং ডিভাইস, নেটওয়ার্ক, ভূগোল ও ব্যবহারকারীর আচরণভেদে আলাদা হতে পারে।