এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

LCP ইমেজ সাবপার্ট এবং RTT এখন CrUX এ উপলব্ধ

Barry Pollard

Johannes Henkel

প্রকাশিত: 11 ফেব্রুয়ারি, 2025

ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্ট (CrUX) এর ফেব্রুয়ারি 2025 রিলিজে বেশ কিছু উত্তেজনাপূর্ণ নতুন (এবং পরিবর্তিত!) মেট্রিক্স রয়েছে:

সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP) ইমেজ সাবপার্ট এবং রিসোর্স প্রকার
রাউন্ড ট্রিপ টাইম (RTT) বিবরণ
ইফেক্টিভ কানেকশন টাইপ (ECT) ডাইমেনশন অপসারণ

এইগুলির প্রত্যেকটিই CrUX-এ উপলব্ধ উৎপত্তি এবং URL-এর কার্যক্ষমতার মেট্রিক্স সম্পর্কে আরও বেশি অন্তর্দৃষ্টি প্রদান করে এবং কেন এই পোস্টে আমরা বিস্তারিত জানাব।

এলসিপি ডায়াগনস্টিক তথ্য

আমরা মূলত Google I/O 2022-এ LCP সাবপার্টের ধারণাটি একটি কার্যকরী কৌশল হিসেবে চালু করেছি যাতে LCP-এর ছবি সহ পৃষ্ঠাগুলির LCP সময়কে ছোট ছোট উপাদানে ভাগ করা যায় যাতে আপনি উচ্চ LCP-এর সঠিক কারণ(গুলি) অপ্টিমাইজ করার জন্য আপনার প্রচেষ্টা ব্যয় করছেন।

সেই আলোচনায় HTTP আর্কাইভ ল্যাব ডেটার বিশ্লেষণে দেখা গেছে যে চিত্র ডাউনলোডের সময় প্রায়শই LCP সময়ের সবচেয়ে ছোট অংশ ছিল। অনেক ল্যাব টুল (Google এর নিজস্ব লাইটহাউস সহ) ঘন ঘন ইমেজ ফরম্যাট এবং সাইজ অপ্টিমাইজ করার পরামর্শে মনোযোগ দেয় যাতে ডাউনলোডের সময় কমাতে এবং পারফরম্যান্স উন্নত হয়। যদিও এখনও সঠিক, বিশ্লেষণে দেখা গেছে যে উপদেশের উপর বেশি জোর দেওয়া হয়েছে এবং ব্রাউজার দ্বারা ছবিটি খুঁজে পাওয়ার এবং ডাউনলোড করা শুরু করার আগে একটি বড় সমস্যা বিলম্বে ছিল।

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

LCP ইমেজ সাবপার্টস

এই প্রকাশের মাধ্যমে, সাইটের মালিকরা তাদের নিজস্ব সাইটগুলি ইমেজ LCP-এর জন্য, মূল বা URL স্তরে সাবপার্টের জন্য চেক করতে পারেন।

সাবপার্টগুলি শুধুমাত্র চিত্রগুলির জন্য উপলব্ধ এবং এতে প্রথম ভিডিও ফ্রেম চিত্রগুলি অন্তর্ভুক্ত নয় (যা একটু বেশি জটিল কারণ আমরা সম্পূর্ণ ডাউনলোডের সময় পরিমাপ করতে পারি না)৷ টেক্সট সাবপার্টগুলিও অন্তর্ভুক্ত করা হয় না কারণ সেগুলি কম দরকারী এবং ইমেজ LCPs নম্বরগুলিকে বিকৃত করবে। যে সাইটগুলি মূলত টেক্সট এলসিপি দিয়ে তৈরি তাদের জন্য সামগ্রিক TTFB এবং সামগ্রিক FCP মেট্রিকগুলি দরকারী ব্রেকডাউন-যদিও নোট করুন যেগুলি সমস্ত এলসিপি জুড়ে এবং পাঠ্য এলসিপিগুলির জন্য নির্দিষ্ট নয়৷ অবশেষে, ইমেজ সাবপার্টগুলি শুধুমাত্র সম্পূর্ণ পৃষ্ঠা লোডের জন্য সংগ্রহ করা হয় - LCP মেট্রিকের বিপরীতে যা ব্যাক-ফরোয়ার্ড নেভিগেশন এবং প্রি-রেন্ডার করা পৃষ্ঠাগুলিতেও সংগ্রহ করা হয়।

ফেব্রুয়ারি 2025 থেকে CrUX API এবং CrUX History API- এ এই ডেটা যোগ করা হয়েছে (দ্রষ্টব্য: BigQuery নয়)। CrUX History API এর লঞ্চের সময় দুই সপ্তাহের ডেটা রয়েছে এবং এটি সময়ের সাথে সাথে পুরো 25-সপ্তাহের ইতিহাসে বৃদ্ধি পাবে। এপিআইগুলি মিলিসেকেন্ডে প্রকাশ করা প্রতিটি সাবপার্টের 75 তম পার্সেন্টাইল হিসাবে ডেটা উপলব্ধ করে।

উদাহরণস্বরূপ, PHONE পেজভিউগুলির জন্য https://web.dev/ জন্য LCP ইমেজ সাবপার্ট পেতে আপনি নিম্নলিখিত কার্ল কমান্ডটি ব্যবহার করতে পারেন ( আপনার নিজস্ব কী দিয়ে API_KEY প্রতিস্থাপন করা):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": [
              "largest_contentful_paint_image_time_to_first_byte",
              "largest_contentful_paint_image_resource_load_delay",
              "largest_contentful_paint_image_resource_load_duration",
              "largest_contentful_paint_image_element_render_delay"]}'

এবং আপনি এই মত কিছু ফিরে পাবেন:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_image_element_render_delay": {
        "percentiles": {
          "p75": 2088
        }
      },
      "largest_contentful_paint_image_resource_load_delay": {
        "percentiles": {
          "p75": 828
        }
      },
      "largest_contentful_paint_image_resource_load_duration": {
        "percentiles": {
          "p75": 417
        }
      },
      "largest_contentful_paint_image_time_to_first_byte": {
        "percentiles": {
          "p75": 2385
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

আমরা এই ডেটা অন্তর্ভুক্ত করার জন্য CrUX Vis টুল আপডেট করেছি এবং আশা করি যে অন্যান্য তৃতীয়-পক্ষের সরঞ্জামগুলিও এই মূল্যবান ডেটা প্রকাশ করতে CrUX API ব্যবহার করে:

CrUX Vis-এ LCP ইমেজ সাবপার্টস গ্রাফ চারটি সাবপার্টের জন্য দুটি ডেটা পয়েন্ট দেখাচ্ছে — CrUX Vis-এ LCP ইমেজ সাবপার্ট।

এই উদাহরণে, আমরা দেখতে পারি যে একটি জনপ্রিয় মিডিয়া সাইটের জন্য রিসোর্স লোডের সময়কাল সবচেয়ে ছোট উপাদান। এই সাইটের উন্নতির আসল সুযোগ TTFB , এবং রিসোর্স লোড বিলম্বের মধ্যে রয়েছে, উপাদান রেন্ডার বিলম্বের একটি ছোট সুযোগ সহ।

প্রতিটি সাবপার্টে উচ্চ মান বিভিন্ন সমস্যার নির্দেশক:

হাই টাইম টু ফার্স্ট বাইট (TTFB) সাধারণত সার্ভার, নেটওয়ার্ক বা রিডাইরেক্ট সমস্যাগুলিকে নির্দেশ করে যেমনটি Optimize TTFB- এ ব্যাখ্যা করা হয়েছে।
উচ্চ সম্পদ লোড বিলম্ব নির্দেশ করে যে ব্রাউজার দ্বারা LCP চিত্রটি দেরিতে আবিষ্কৃত হয়েছে—উদাহরণস্বরূপ, একটি LCP চিত্র যা ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট দ্বারা ইনজেকশন করা হয় যা চালানোর জন্য কিছু সময় নেয়।
উচ্চ সম্পদ লোড সময়কাল যেখানে আপনি ইমেজ ডাউনলোড আকার হ্রাস করা উচিত.
উচ্চ উপাদান রেন্ডার বিলম্ব যখন ইমেজ উপলব্ধ হয় (সম্ভবত <link rel=preload> এর মাধ্যমে কিন্তু দীর্ঘ সময়ের জন্য ব্যবহার করা হয় না—আবার প্রায়ই ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের কারণে ছবিটি দেখানোর প্রয়োজন হয়।

মূল পয়েন্ট: যেহেতু তারা অনেক পৃষ্ঠা ভিউ জুড়ে সমষ্টিগত ডেটা উপস্থাপন করে, তাই ছবির সাবপার্টগুলি 75 তম পার্সেন্টাইলে প্রদান করা হয় তাই সাবপার্টগুলির যোগফল সামগ্রিক LCP 75 তম পার্সেন্টাইলের সমান হবে বলে আশা করা যায় না। LCP ইমেজ সাবপার্টগুলিকে 75 তম পার্সেন্টাইল LCP মানের সঠিক ভাঙ্গনের পরিবর্তে আপেক্ষিক সাবপার্ট গুরুত্বের ইঙ্গিত দিতে ব্যবহার করা উচিত।

আমরা আশা করি যে এই ডেটাটি CrUX-এ উৎপত্তি এবং URL-স্তরে ( সাধারণ যোগ্যতার মাপকাঠি সাপেক্ষে) উভয় ক্ষেত্রেই উপলব্ধ করা সাইটগুলিকে তাদের LCP মেট্রিক অপ্টিমাইজ করা সহজ করতে সাহায্য করে৷

LCP সম্পদের ধরন

যেহেতু সাবপার্টগুলি ইমেজ এলসিপিগুলির জন্য সবচেয়ে ভাল দেখা হয়, তাই CrUX এই ডেটা শুধুমাত্র ছবি সহ পৃষ্ঠাগুলিতে সীমাবদ্ধ করে। অতএব, এটা বোঝা গুরুত্বপূর্ণ যে আপনার কতগুলি এলসিপি টেক্সট এলসিপির বিপরীতে ইমেজ এলসিপি (যেমন <h1> শিরোনাম এবং দীর্ঘ অনুচ্ছেদ, উদাহরণস্বরূপ)।

LCP ইমেজ সাবপার্টস ছাড়াও, CrUX API-এ এখন একটি রিসোর্স ব্রেকডাউন অন্তর্ভুক্ত রয়েছে যা পাঠ্য এবং চিত্রের মধ্যে LCP পৃষ্ঠা লোডের বিভাজন দেখায়।

উদাহরণস্বরূপ, PHONE পেজভিউগুলির জন্য https://web.dev/ জন্য LCP রিসোর্স প্রকারগুলি পেতে আপনি নিম্নলিখিত কার্ল কমান্ডটি ব্যবহার করতে পারেন (আবার, আপনার নিজের কী দিয়ে API_KEY প্রতিস্থাপন করুন):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["largest_contentful_paint_resource_type"]}'

এবং আপনি এই মত কিছু ফিরে পাবেন:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_resource_type": {
        "fractions": {
          "image": 0.0155,
          "text": 0.9845
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

এই ডেটা প্রদর্শনের জন্য CrUX Vis আপডেট করা হয়েছে:

CrUX Vis-এ LCP রিসোর্স প্রকারের গ্রাফ দুটি রিসোর্স প্রকারের জন্য দুটি ডেটা পয়েন্ট দেখাচ্ছে। — CrUX Vis-এ LCP সম্পদের ধরন

উদাহরণ স্বরূপ web.dev-এর হোম পেজের জন্য আমরা দেখতে পাচ্ছি যে 98.5% এলসিপি আসলে টেক্সট এলসিপি ছিল, তাই এলসিপি ইমেজ সাবপার্টগুলি এই পৃষ্ঠার জন্য কম উপযোগী। সেই ক্ষেত্রে, আমরা একটি সম্ভাব্য ভাল ডায়াগনস্টিক ব্রেকডাউন হিসাবে আসল TTFB এবং FCP মেট্রিক্স ব্যবহার করতে পারি।

গুরুত্বপূর্ণ: LCP রিসোর্স টাইপ ছবির ভগ্নাংশে ভিডিও অন্তর্ভুক্ত করে, কারণ একটি ভিডিওর প্রথম ফ্রেম LCP-এর জন্য গণনা করা হয় (পাশাপাশি অ্যানিমেটেড ছবির জন্য)। যাইহোক, LCP ইমেজ সাবপার্টগুলি শুধুমাত্র প্রকৃত ইমেজ উপাদানগুলির জন্য, যেহেতু রিসোর্স ডাউনলোডের সময় ভিডিও স্ট্রিম করার জন্য গণনা করা একটু জটিল তাই এই সময়ে অন্তর্ভুক্ত করা হয়নি। অনুরূপ কারণে রিসোর্স প্রকারগুলি শুধুমাত্র সম্পূর্ণ পৃষ্ঠা লোডের জন্য সংগ্রহ করা হয় - LCP মেট্রিকের বিপরীতে যা ব্যাক-ফরোয়ার্ড নেভিগেশন এবং প্রি-রেন্ডার করা পৃষ্ঠাগুলিতেও সংগ্রহ করা হয়।

এলসিপি রিসোর্স প্রকারগুলি হল এলসিপি বোঝার এবং উন্নত করার জন্য আরেকটি দরকারী ডায়গনিস্টিক টুল, বিশেষ করে এলসিপি ইমেজ সাবপার্টগুলি কতটা দরকারী তা জানার জন্য।

RTT ডায়াগনস্টিক তথ্য

আমরা আগস্ট 2024-এ প্রথম চালু করা RTT মেট্রিকও প্রসারিত করেছি।

RTT ট্রাই-বিন

আমরা CrUX API-তে ট্রাই-বিন যুক্ত করেছি যেগুলি RTT ঘনত্বের তিনটি গ্রুপিং দেখায়:

নেটওয়ার্ক লেটেন্সি	শুরু করুন	শেষ
কম	0 মিলিসেকেন্ড	<75 মিলিসেকেন্ড
মাঝারি	75 মিলিসেকেন্ড	< 275 মিলিসেকেন্ড
উচ্চ	275 মিলিসেকেন্ড	∞

এই বিনগুলি পূর্ববর্তী ECT বিভাগগুলির তুলনায় আরও তথ্যপূর্ণ যা 4g বিভাগে 270 মিলিসেকেন্ডের কম সবকিছু অন্তর্ভুক্ত করে। নেটওয়ার্কিং প্রযুক্তিতে অগ্রগতির সাথে সাথে যেগুলি চালু হয়েছে, বেশিরভাগ সাইটগুলি তাদের বেশিরভাগ ট্রাফিক সেই বিভাগে দেখেছে যে এই শ্রেণীকরণটিকে কম উপযোগী করে তুলেছে।

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

এই বিনগুলি CrUX API-এ উপলব্ধ, উদাহরণস্বরূপ PHONE পৃষ্ঠাদর্শনের জন্য web.dev জন্য (আবার, API_KEY আপনার নিজের কী দিয়ে প্রতিস্থাপন করা):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["round_trip_time"]}'

যা এই মত কিছু প্রদান করে:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "round_trip_time": {
        "histogram": [
          {
            "start": 0,
            "end": 75,
            "density": 0.1524
          },
          {
            "start": 75,
            "end": 275,
            "density": 0.6641
          },
          {
            "start": 275,
            "density": 0.1835
          }
        ],
        "percentiles": {
          "p75": 230
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

ডিস্ট্রিবিউশন নির্বাচন করা হলে বিনগুলি CrUX Vis-এ দেখানো হয়:

CrUX-এ RTT গ্রাফ শেষ দুটি ডেটা পয়েন্টের জন্য RTT ডেটা এবং ডিস্ট্রিবিউশন ব্রেক ডাউনগুলির একটি সম্পূর্ণ ডেটা সিরিজের সাথে — CrUX Vis-এ RTT ডেটা।

BigQuery-এ RTT

ট্রাই-বিনগুলিকে অন্তর্ভুক্ত করার জন্য CrUX API-এ RTT মেট্রিক প্রসারিত করার পাশাপাশি, আমরা মাসিক BigQuery ডেটাসেটে কাঁচা টেবিলের 25 মিলিসেকেন্ডের বালতিতে একটি সম্পূর্ণ হিস্টোগ্রাম এবং ট্রাই-বিন এবং বস্তুগত টেবিলে p75 মান সহ ডেটা উপলব্ধ করেছি।

এটি CrUX API-এ উপলব্ধ ট্রাই-বিনের বাইরে ডেটা বিতরণের গভীরতর বোঝার অনুমতি দেয়। এটি আমাদের ইসিটি ব্রেকডাউনটিকে পুনরায় তৈরি করার অনুমতি দেয় যা এই মাস থেকে CrUX থেকে সরানো হয়েছে (পরে আরও) - পূর্ববর্তী 270 মিলিসেকেন্ড থ্রেশহোল্ডের পরিবর্তে 4g এর জন্য 275 মিলিসেকেন্ড থ্রেশহোল্ডের সামান্য পরিবর্তনের সাথে৷ ECT ব্রেকডাউন (এখন RTT ডেটা থেকে পাওয়া) CrUX BigQuery বাস্তবায়িত সারণীতে পাওয়া যাচ্ছে যাতে CrUX ড্যাশবোর্ডের মতো টুল এই ব্রেকডাউন দেখাতে পারে।

BigQuery ডেটাসেটে দেশ অনুযায়ী ডেটাও অন্তর্ভুক্ত থাকে ( ISO 3166-1 দ্বারা সংজ্ঞায়িত)। এটি আরও গভীর বিশ্লেষণের অনুমতি দেয় যা কিছু ব্যবহারকারীর জন্য পারফরম্যান্স মেট্রিক্স কেন খারাপ তা ব্যাখ্যা করতে কার্যকর হতে পারে। উদাহরণস্বরূপ, আমরা https://www.google.com এর ডেটা দেখে Google ফোন ব্যবহারকারীদের ডেটা দেখতে পারি:

SELECT
  `chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
  least(500, p75_rtt) AS capped_p75_rtt,
  p75_rtt
FROM
  `chrome-ux-report.materialized.country_summary`
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202501 AND
  device = 'phone'
ORDER BY
  p75_rtt DESC,
  country_code

তারপরে আমরা একটি জিও মানচিত্রে ডেটা কল্পনা করি:

সাব-সাহারান, মধ্যপ্রাচ্য ও মধ্য এশিয়ার কিছু অংশ এবং হলুদ, কমলা ও লাল রঙে চীন ছাড়া বেশিরভাগ দেশ সবুজের বিভিন্ন শেডে দেশ অনুসারে RTT ভিজ্যুয়ালাইজেশন। — `https://www.google.com` জন্য দেশ অনুযায়ী 75তম পার্সেন্টাইল ফোন RTT
( ইন্টারেক্টিভ চার্ট সহ তথ্য উৎস )।

আমরা দেখতে পাচ্ছি যে, যখন বিশ্বের বেশিরভাগ অংশে (বিশেষ করে "পশ্চিম বিশ্ব") খুব ভাল RTT আছে, সাব-সাহারান আফ্রিকা, মধ্যপ্রাচ্যের কিছু অংশ এবং এশিয়ার কিছু অংশ বেশি লড়াই করছে। প্রকৃতপক্ষে গ্রাফটি 500 মিলিসেকেন্ড RTT-তে ক্যাপ করা হয়েছে কারণ সম্পূর্ণ ডেটা ব্যবহার করে রঙগুলিকে তির্যক করা হয়েছে—বিশেষ করে ইরিত্রিয়ার সাথে 3,850 মিলিসেকেন্ডের 75তম শতাংশে!

ট্র্যাফিক প্যাটার্ন পরিবর্তন হলে এটিও কার্যকর হতে পারে। উদাহরণস্বরূপ, উচ্চতর RTT সহ সেইসব দেশের ব্যবহারকারীদের একটি বৃহত্তর অনুপাত সাইটটি কিছু পরিবর্তন না করা সত্ত্বেও খারাপ কোর ওয়েব ভাইটাল পরিসংখ্যান ব্যাখ্যা করতে পারে।

যদিও সাইটগুলি সরাসরি RTT উন্নত করতে পারে না, এই ডেটা সাইটের দর্শকদের দ্বারা উপলব্ধ করা হলে তা সারা বিশ্বে আপনার সাইটের ব্যবহারকারীদের আরও ভালভাবে বোঝার অনুমতি দেয়৷ এটি ভবিষ্যতে বিশ্লেষণের জন্য অনেক সুযোগ তৈরি করে এবং আমরা আশা করি গবেষকরা এই ডেটাসেট থেকে আকর্ষণীয় অন্তর্দৃষ্টি খুঁজে পাবেন।

ECT মাত্রা অপসারণ

ফেব্রুয়ারী 2025-এর রিলিজে চূড়ান্ত পরিবর্তন হল BigQuery থেকে কার্যকরী কানেকশন টাইপ (ECT) ডাইমেনশনের অবসর গ্রহণ (আমরা ইতিমধ্যেই সেপ্টেম্বর 2024 থেকে APIs থেকে RTT সরিয়ে দিয়েছিলাম যখন আমরা RTT মেট্রিকটিকে এর প্রতিস্থাপন হিসাবে চালু করেছিলাম)।

এই পোস্টে আগেই উল্লেখ করা হয়েছে, RTT মেট্রিক একটি সাইটের দর্শকদের সংযোগের বিশদ বিবরণ আরও সূক্ষ্মভাবে দেখার অনুমতি দেয়। এমনকি আপনি সেই হিস্টোগ্রামগুলি থেকে ইসিটি বালতিগুলি পুনরায় তৈরি করতে পারেন। (প্রযুক্তিগতভাবে, ইসিটি আরটিটি এবং ডাউনলিংক গতির সংমিশ্রণ হওয়া উচিত , তবে ক্রোম শুধুমাত্র আরটিটি ব্যবহার করেছে ।)

একটি গুরুত্বপূর্ণ পার্থক্য হল যে ECT একটি CrUX মাত্রা ছিল —অর্থাৎ অন্যান্য মেট্রিক্স ECT দ্বারা বিভক্ত করা যেতে পারে। RTT হল একটি মাত্রার পরিবর্তে একটি CrUX মেট্রিক , তাই RTT দ্বারা LCP দেখা সম্ভব নয়, তবে শুধুমাত্র অন্যান্য মাত্রা (ডিভাইসের ধরন এবং দেশ) দ্বারা RTTগুলি দেখা সম্ভব।

এটি আরও সীমিত শোনাতে পারে, কিন্তু মাত্রা থেকে মেট্রিকে সরানো আসলে CrUX-এ আরও ডেটা আনলক করে। কারণ আমরা ডেটা দেখাতে সক্ষম হওয়ার আগে CrUX-এর নির্দিষ্ট ন্যূনতম থ্রেশহোল্ড রয়েছে৷ আমরা ইতিমধ্যেই 2022 সালে মাত্রাগুলিকে ঐচ্ছিক করে দিয়েছি যার অর্থ আমরা ECT বা ডিভাইস সরিয়ে দিয়েছি যেখানে উচ্চ স্তরে রিপোর্ট করার প্রয়োজন হয়, কিন্তু যে মেট্রিকগুলি বেশিরভাগ পৃষ্ঠা লোডের মধ্যে ছিল না ( ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) , বিভিন্ন নেভিগেশন প্রকার এবং এখন LCP ইমেজ সাবপার্টস) প্রায়শই BigQuery-তে উৎপত্তির জন্য উপলব্ধ ছিল না।

মাত্রার সংখ্যা কমিয়ে, ডেটা কম সেগমেন্ট করা হয়, তাই এই ন্যূনতম প্রয়োজনীয়তা পূরণ করে উৎপত্তির সংখ্যা বৃদ্ধি করা হয়। জানুয়ারিতে, আমরা 68.1% উত্সের জন্য INP রিপোর্ট করি, যেখানে ডিসেম্বরের ডেটাসেটের জন্য, আমরা শুধুমাত্র 64.5% উত্সের জন্য INP রিপোর্ট করেছি৷ এই রিলিজে নেভিগেশন টাইপ, LCP সাবপার্টস এবং রিসোর্স টাইপ-এর ক্ষেত্রেও মেকানিজম প্রযোজ্য—তারা সবাই ECT ডাইমেনশন অপসারণের ফলে উপকৃত হয়। CrUX API-এ, বর্ধিত কভারেজ ফেব্রুয়ারির শুরু থেকে কার্যকর হয়েছে।

পূর্ববর্তী ডেটাসেটের সাথে সামঞ্জস্যের জন্য ECT কলামগুলি BigQuery-এ থাকবে এবং বাস্তবায়িত দৃশ্যের ECT ডেটা উপলব্ধ থাকবে, তবে নতুন RTT p75 এবং ট্রাই-বিন ছাড়াও RTT তথ্যের উপর ভিত্তি করে ( 3g এবং 4g জন্য 5 মিলিসেকেন্ডের পার্থক্য সহ)।

উপসংহার

পাবলিক CrUX ডেটাসেটে আরও মেট্রিক্স যুক্ত করা সাইটের মালিক এবং গবেষকদের কার্যক্ষমতা সংক্রান্ত সমস্যা নির্ণয় এবং শেষ পর্যন্ত ঠিক করতে সাহায্য করার জন্য অনেক বেশি তথ্য দেয়।

একটি সর্বজনীন ডেটাসেট হিসাবে, CrUX-এর কিছু নির্দিষ্ট সীমাবদ্ধতা রয়েছে যা আমরা দেখাতে পারি—উদাহরণস্বরূপ, পৃথক উপাদান নির্বাচকরা কখনই CrUX-এ দেখানো যাবে না। এই স্তরের বিশদ বিবরণের সন্ধানকারী সাইট মালিকদেরকে একটি RUM সমাধান প্রয়োগ করার জন্য দৃঢ়ভাবে পরামর্শ দেওয়া হচ্ছে, যা ততটা সীমাবদ্ধ হবে না।

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