كيفية استخدام مجموعة بيانات CrUX BigQuery

Rick Viscomi

تتوفّر البيانات الأولية من تقرير تجربة المستخدم على Chrome (CrUX) على BigQuery، وهي قاعدة بيانات على Google Cloud. يتطلب استخدام BigQuery توفُّر مشروع Google Cloud Platform ومعرفة أساسية بلغة 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 عنوان جدول المصدر الذي يتألف من ثلاثة أجزاء:

  • اسم المشروع على Google Cloud chrome-ux-report الذي يتم من خلاله تنظيم جميع بيانات CrUX
  • مجموعة البيانات all، التي تمثل البيانات في جميع البلدان
  • الجدول 202206، والسنة والشهر للبيانات بتنسيق YYYYMM

هناك أيضًا مجموعات بيانات لكل بلد. على سبيل المثال، لا يمثّل chrome-ux-report.country_ca.202206 سوى بيانات تجربة المستخدِم التي نشأت في كندا.

ضمن كل مجموعة بيانات، تتوفّر جداول لكل شهر منذ تشرين الأول (أكتوبر) 2017. يتم نشر جداول جديدة للشهر التقويمي السابق بانتظام.

تحتوي بنية جداول البيانات (المعروفة أيضًا باسم المخطط) على:

• المصدر، على سبيل المثال 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_loading (DCL)
  • onload (OL)
  • تخطيط_instability.global_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},
    ...
]

تحتوي كل سلة على وقت بدء ووقت انتهاء بالمللي ثانية وكثافة تمثل النسبة المئوية لتجارب المستخدم خلال هذا النطاق الزمني. بعبارة أخرى، إنّ 12.34% من تجارب "سرعة عرض المحتوى على الصفحة" (FCP) لهذا المصدر الافتراضي وسرعة الاتصال ونوع الجهاز تقل عن 100 ملي ثانية. مجموع كل كثافات السلة هو 100%.

تصفُّح بنية الجداول في BigQuery

تقييم الأداء

يمكننا استخدام معرفتنا بمخطط الجدول لكتابة استعلام يستخرج بيانات الأداء هذه.

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

والنتيجة هي 0.01115، ما يعني أنّ 1.115% من تجارب المستخدمين على هذا المصدر تتراوح بين 0 و100 ملي ثانية على شبكة الجيل الرابع وعلى الهاتف. إذا أردنا تعميم طلب البحث على أي اتصال وأي نوع جهاز، يمكننا حذفهما من العبارة 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، أو %5.355 على جميع الأجهزة وأنواع الاتصال. يمكننا تعديل الاستعلام بشكل طفيف وإضافة كثافات جميع السلال الموجودة في العمود "سريع" نطاق سرعة عرض المحتوى على الصفحة بين 0 و1,000 ملي ثانية:

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. بعبارة أخرى، إنّ 69.77% من تجارب المستخدمين التي تعتمد على سرعة عرض المحتوى على الصفحة (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 وإحصاءات PageSpeed. على سبيل المثال، تتيح لك BigQuery تقسيم البيانات بطرق مفيدة ودمجها مع مجموعات بيانات عامة أخرى مثل أرشيف HTTP لإجراء بعض عمليات التنقيب عن البيانات المتقدمة.

هل هناك أيّ قيود على استخدام BigQuery؟

نعم، يتمثل العامل الأهم في أنّه يمكن للمستخدمين تلقائيًا طلب بيانات 1 تيرابايت فقط كل شهر. وبعد ذلك، سيتم تطبيق السعر العادي الذي يبلغ 5 دولار أمريكي لكل تيرابايت.

أين يمكنني الاطّلاع على مزيد من المعلومات عن BigQuery؟

اطّلِع على مستندات BigQuery للحصول على مزيد من المعلومات.