কিভাবে CrUX BigQuery ডেটাসেট ব্যবহার করবেন

Rick Viscomi

ক্রোম ইউএক্স রিপোর্ট ( CrUX )-এর মূল ডেটা গুগল ক্লাউডের একটি ডেটাবেস BigQuery- তে পাওয়া যায়। BigQuery ব্যবহার করার জন্য একটি GCP প্রজেক্ট এবং SQL সম্পর্কে প্রাথমিক জ্ঞান প্রয়োজন।

এই নির্দেশিকায় শিখুন, কীভাবে BigQuery ব্যবহার করে CrUX ডেটাসেটের উপর কোয়েরি লিখে ওয়েবে ব্যবহারকারীর অভিজ্ঞতার অবস্থা সম্পর্কে অন্তর্দৃষ্টিপূর্ণ ফলাফল বের করা যায়।

• ডেটা কীভাবে সাজানো হয়েছে তা বুঝুন।
• একটি অরিজিনের পারফরম্যান্স মূল্যায়ন করার জন্য একটি সাধারণ কোয়েরি লিখুন।
• সময়ের সাথে সাথে পারফরম্যান্স ট্র্যাক করার জন্য একটি উন্নত কোয়েরি লিখুন।

ডেটা সংগঠন

একটি মৌলিক কোয়েরি দেখে শুরু করুন:

SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`

কোয়েরিটি চালানোর জন্য, কোয়েরি এডিটরে এটি লিখুন এবং 'Run query' বোতামটি চাপুন:

এই কোয়েরিটির দুটি অংশ রয়েছে:

• SELECT COUNT(DISTINCT origin) এর অর্থ হলো টেবিলে থাকা অরিজিনগুলোর সংখ্যা জানতে চাওয়া। সহজ কথায়, দুটি URL একই অরিজিনের অংশ হয় যদি তাদের স্কিম, হোস্ট এবং পোর্ট একই হয়।

• FROM chrome-ux-report.all.202206 উৎস টেবিলের ঠিকানা নির্দিষ্ট করে, যার তিনটি অংশ রয়েছে:

  • chrome-ux-report নামক ক্লাউড প্রজেক্টটির অধীনে সমস্ত CrUX ডেটা সংগঠিত থাকে।
  • all ডেটাসেটটি সমস্ত দেশের ডেটা উপস্থাপন করে।
  • 202206 সারণিটি, যেখানে উপাত্তের বছর ও মাস YYYYMM বিন্যাসে রয়েছে।

এছাড়াও প্রতিটি দেশের জন্য ডেটাসেট রয়েছে। উদাহরণস্বরূপ, chrome-ux-report.country_ca.202206 শুধুমাত্র কানাডা থেকে প্রাপ্ত ব্যবহারকারীর অভিজ্ঞতার ডেটা উপস্থাপন করে।

প্রতিটি ডেটাসেটের মধ্যে ২০১৭ সালের অক্টোবর মাস থেকে প্রতি মাসের জন্য সারণি রয়েছে। পূর্ববর্তী ক্যালেন্ডার মাসের জন্য নতুন সারণি নিয়মিতভাবে প্রকাশ করা হয়।

ডেটা টেবিলের কাঠামোতে (যা স্কিমা নামেও পরিচিত) নিম্নলিখিত বিষয়গুলো অন্তর্ভুক্ত থাকে:

• উদাহরণস্বরূপ, origin = 'https://www.example.com' , যা সেই ওয়েবসাইটের সমস্ত পৃষ্ঠার সামগ্রিক ব্যবহারকারী অভিজ্ঞতার বন্টনকে উপস্থাপন করে।
• পৃষ্ঠা লোড হওয়ার সময়কার সংযোগের গতি, উদাহরণস্বরূপ, effective_connection_type.name = '4G' ( ফেব্রুয়ারি ২০২৫ থেকে অপসারিত )
• ডিভাইসের ধরণ, উদাহরণস্বরূপ form_factor.name = 'desktop'
• ইউএক্স মেট্রিকগুলি নিজেরাই
  • first_paint (FP)
  • first_contentful_paint ( FCP )
  • largest_contentful_paint ( LCP )
  • dom_content_loaded (DCL)
  • onload (OL)
  • layout_instability.cumulative_layout_shift ( CLS )
  • interaction_to_next_paint ( INP )

প্রতিটি মেট্রিকের ডেটা অবজেক্টের একটি অ্যারে হিসাবে সাজানো থাকে। JSON নোটেশনে, first_contentful_paint.histogram.bin ফাইলটি দেখতে অনেকটা এইরকম হবে:

[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]

প্রতিটি বিনে মিলিসেকেন্ডে একটি শুরু ও শেষের সময় এবং সেই সময়সীমার মধ্যে ব্যবহারকারীর অভিজ্ঞতার শতাংশ নির্দেশকারী একটি ঘনত্ব থাকে। অন্য কথায়, এই কাল্পনিক উৎস, সংযোগের গতি এবং ডিভাইসের ধরনের জন্য FCP অভিজ্ঞতার ১২.৩৪% ১০০ মিলিসেকেন্ডের কম। সমস্ত বিন ঘনত্বের যোগফল হলো ১০০%।

BigQuery-তে টেবিলগুলোর কাঠামো ব্রাউজ করুন।

কর্মক্ষমতা মূল্যায়ন করুন

টেবিল স্কিমা সম্পর্কে আমাদের জ্ঞান ব্যবহার করে আমরা এমন একটি কোয়েরি লিখতে পারি যা এই পারফরম্যান্স ডেটা বের করে আনবে।

SELECT
  fcp
FROM
  `chrome-ux-report.all.202502`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  form_factor.name = 'phone' AND
  fcp.start = 0

ফলাফলটি হলো 0.01115 , যার অর্থ হলো এই অরিজিনে 4G এবং ফোনে ব্যবহারকারীদের অভিজ্ঞতার 1.115% 0 থেকে 100ms-এর মধ্যে হয়ে থাকে। যদি আমরা আমাদের কোয়েরিটিকে যেকোনো কানেকশন এবং যেকোনো ডিভাইসের ধরনের জন্য সাধারণীকরণ করতে চাই, তাহলে আমরা WHERE ক্লজ থেকে সেগুলোকে বাদ দিতে পারি এবং তাদের নিজ নিজ বিন ডেনসিটিগুলো যোগ করার জন্য SUM অ্যাগ্রিগেটর ফাংশনটি ব্যবহার করতে পারি:

SELECT
  SUM(fcp.density)
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start = 0

ফলাফলটি হলো 0.05355 , অথবা সমস্ত ডিভাইস এবং সংযোগের ধরণ জুড়ে ৫.৩৫৫%। আমরা কোয়েরিটি সামান্য পরিবর্তন করে ০–১০০০ms-এর "দ্রুত" FCP পরিসরে থাকা সমস্ত বিনের ঘনত্বগুলো যোগ করতে পারি:

SELECT
  SUM(fcp.density) AS fast_fcp
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start < 1000

এর ফলে আমরা 0.6977 পাই। অন্য কথায়, FCP রেঞ্জ সংজ্ঞা অনুসারে web.dev-এ FCP ব্যবহারকারীর অভিজ্ঞতার ৬৯.৭৭% "দ্রুত" বলে বিবেচিত হয়।

ট্র্যাক পারফরম্যান্স

এখন যেহেতু আমরা একটি অরিজিন সম্পর্কে পারফরম্যান্স ডেটা বের করে নিয়েছি, আমরা এটিকে পুরোনো টেবিলগুলোতে থাকা ঐতিহাসিক ডেটার সাথে তুলনা করতে পারি। তা করার জন্য, আমরা টেবিলের অ্যাড্রেসটিকে আগের কোনো মাসে পরিবর্তন করে লিখতে পারি, অথবা সব মাস কোয়েরি করার জন্য ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করতে পারি:

SELECT
  _TABLE_SUFFIX AS yyyymm,
  SUM(fcp.density) AS fast_fcp
FROM
  `chrome-ux-report.all.*`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start < 1000
GROUP BY
  yyyymm
ORDER BY
  yyyymm DESC

এখানে আমরা দেখতে পাচ্ছি যে, দ্রুত FCP অভিজ্ঞতার শতাংশ প্রতি মাসে কয়েক শতাংশ পয়েন্ট করে পরিবর্তিত হয়।

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

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

CrUX BigQuery ডেটাসেট সম্পর্কে প্রায়শই জিজ্ঞাসিত কিছু প্রশ্ন নিচে দেওয়া হলো:

অন্যান্য টুলের পরিবর্তে আমি কখন BigQuery ব্যবহার করব?

BigQuery তখনই প্রয়োজন হয়, যখন আপনি CrUX Vis এবং PageSpeed ​​Insights-এর মতো অন্যান্য টুল থেকে একই তথ্য পেতে পারেন না। উদাহরণস্বরূপ, BigQuery আপনাকে ডেটাকে অর্থপূর্ণ উপায়ে ভাগ করতে এবং এমনকি কিছু উন্নত ডেটা মাইনিং করার জন্য HTTP Archive-এর মতো অন্যান্য পাবলিক ডেটাসেটের সাথে যুক্ত করতে দেয়।

BigQuery ব্যবহারে কি কোনো সীমাবদ্ধতা আছে?

হ্যাঁ, সবচেয়ে গুরুত্বপূর্ণ সীমাবদ্ধতা হলো যে, ব্যবহারকারীরা ডিফল্টরূপে প্রতি মাসে কেবল ১ টেরাবাইট ডেটা কোয়েরি করতে পারেন। এর বেশি হলে, প্রতি টেরাবাইটের জন্য ৫ ডলারের সাধারণ হার প্রযোজ্য হয়।

আমি BigQuery সম্পর্কে আরও কোথায় জানতে পারব?

আরও তথ্যের জন্য BigQuery ডকুমেন্টেশন দেখুন।