วิธีใช้ชุดข้อมูล CrUX BigQuery

Rick Viscomi

ข้อมูลดิบของรายงาน Chrome UX (CrUX) พร้อมให้บริการใน BigQuery ซึ่งเป็นฐานข้อมูลใน Google Cloud การใช้ BigQuery ต้องมีโปรเจ็กต์ GCP และความรู้พื้นฐานเกี่ยวกับ SQL

ในคู่มือนี้ คุณจะได้เรียนรู้วิธีใช้ BigQuery เพื่อเขียนการค้นหาในชุดข้อมูล CrUX เพื่อดึงผลลัพธ์เชิงลึกเกี่ยวกับสถานะประสบการณ์ของผู้ใช้บนเว็บ

• ทำความเข้าใจวิธีจัดระเบียบข้อมูล
• เขียนการค้นหาพื้นฐานเพื่อประเมินประสิทธิภาพของต้นทาง
• เขียนการค้นหาขั้นสูงเพื่อติดตามประสิทธิภาพเมื่อเวลาผ่านไป

การจัดระเบียบข้อมูล

เริ่มต้นด้วยการดูการค้นหาพื้นฐาน

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

หากต้องการเรียกใช้การค้นหา ให้ป้อนการค้นหาลงในเครื่องมือแก้ไขการค้นหา แล้วกดปุ่ม "เรียกใช้การค้นหา"

การค้นหานี้มี 2 ส่วน ดังนี้

• SELECT COUNT(DISTINCT origin) หมายถึงการค้นหาจํานวนต้นทางในตาราง โดยคร่าวๆ แล้ว URL 2 รายการจะอยู่ในต้นทางเดียวกันหากมีรูปแบบ โฮสต์ และพอร์ตเดียวกัน

• FROM chrome-ux-report.all.202206 ระบุที่อยู่ของตารางแหล่งที่มา ซึ่งมี 3 ส่วน ดังนี้

  • ชื่อโปรเจ็กต์ที่อยู่ในระบบคลาวด์ chrome-ux-report ซึ่งเป็นที่จัดระเบียบข้อมูล CrUX ทั้งหมด
  • ชุดข้อมูล all ซึ่งแสดงข้อมูลจากทุกประเทศ
  • ตาราง 202206 ซึ่งแสดงปีและเดือนของข้อมูลในรูปแบบ YYYYMM

นอกจากนี้ยังมีชุดข้อมูลสำหรับทุกประเทศด้วย เช่น chrome-ux-report.country_ca.202206 แสดงเฉพาะข้อมูลประสบการณ์ของผู้ใช้ที่มาจากแคนาดา

ภายในชุดข้อมูลแต่ละชุดจะมีตารางสำหรับทุกเดือนตั้งแต่ปี 201710 ระบบจะเผยแพร่ตารางใหม่สำหรับเดือนก่อนหน้าตามปฏิทินเป็นประจำ

โครงสร้างของตารางข้อมูล (หรือที่เรียกว่า สคีมา) ประกอบด้วยข้อมูลต่อไปนี้

• ต้นทาง เช่น origin = 'https://www.example.com' ซึ่งแสดงการกระจายประสบการณ์ของผู้ใช้โดยรวมสำหรับทุกหน้าในเว็บไซต์นั้น
• ความเร็วในการเชื่อมต่อ ณ เวลาที่การโหลดหน้าเว็บ เช่น effective_connection_type.name = '4G' (นำออกตั้งแต่เดือนกุมภาพันธ์ 2025)
• ประเภทอุปกรณ์ เช่น form_factor.name = 'desktop'
• เมตริก UX เอง
  • 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)

ระบบจะจัดระเบียบข้อมูลสำหรับเมตริกแต่ละรายการเป็นอาร์เรย์ของออบเจ็กต์ first_contentful_paint.histogram.bin ในรูปแบบ JSON จะมีลักษณะคล้ายกับตัวอย่างต่อไปนี้

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

แต่ละ Bin จะมีเวลาเริ่มต้นและเวลาสิ้นสุดเป็นมิลลิวินาที รวมถึงความหนาแน่นที่แสดงเปอร์เซ็นต์ของประสบการณ์ของผู้ใช้ภายในช่วงเวลานั้น กล่าวคือ ประสบการณ์ FCP 12.34% สำหรับต้นทาง ความเร็วในการเชื่อมต่อ และประเภทอุปกรณ์สมมตินี้มีค่าน้อยกว่า 100 มิลลิวินาที ผลรวมของความหนาแน่นของ Bin ทั้งหมดคือ 100%

เรียกดูโครงสร้างของตารางใน 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 ซึ่งหมายความว่าประสบการณ์ของผู้ใช้ 1.115% ในต้นทางนี้มีค่าอยู่ระหว่าง 0 ถึง 100 มิลลิวินาทีบน 4G และโทรศัพท์ หากต้องการทำให้การค้นหาเป็นแบบทั่วไปสำหรับทุกการเชื่อมต่อและทุกประเภทอุปกรณ์ เราสามารถละเว้นการเชื่อมต่อและประเภทอุปกรณ์ออกจากคําสั่ง WHERE และใช้ฟังก์ชันตัวรวบรวม SUM เพื่อรวมความหนาแน่นของ Bin ที่เกี่ยวข้องทั้งหมด

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% ในอุปกรณ์และการเชื่อมต่อทุกประเภท เราสามารถแก้ไขการค้นหาเล็กน้อยและรวมความหนาแน่นของ Bin ทั้งหมดที่อยู่ในช่วง FCP "เร็ว" ที่ 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 กล่าวคือ ประสบการณ์ของผู้ใช้ FCP 69.77% ใน 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 ที่เร็วจะแตกต่างกันไป 2-3 เปอร์เซ็นต์ในแต่ละเดือน

เทคนิคเหล่านี้จะช่วยให้คุณค้นหาประสิทธิภาพของต้นทาง คำนวณเปอร์เซ็นต์ของประสบการณ์ที่เร็ว และติดตามประสิทธิภาพเมื่อเวลาผ่านไปได้ ขั้นตอนถัดไป ให้ลองค้นหาต้นทาง 2 รายการขึ้นไปแล้วเปรียบเทียบประสิทธิภาพของต้นทางเหล่านั้น

คำถามที่พบบ่อย

ต่อไปนี้คือคำถามที่พบบ่อยเกี่ยวกับชุดข้อมูล CrUX BigQuery

ฉันควรใช้ BigQuery เมื่อใดแทนที่จะใช้เครื่องมืออื่นๆ

คุณควรใช้ BigQuery ก็ต่อเมื่อไม่สามารถรับข้อมูลเดียวกันจากเครื่องมืออื่นๆ เช่น CrUX Vis และ PageSpeed Insights ตัวอย่างเช่น BigQuery ช่วยให้คุณแบ่งข้อมูลออกเป็นส่วนๆ ในรูปแบบที่มีความหมาย และยังช่วยให้คุณรวมข้อมูลดังกล่าวกับชุดข้อมูลสาธารณะอื่นๆ เช่น HTTP Archive เพื่อทำการขุดข้อมูลขั้นสูงได้ด้วย

การใช้ BigQuery มีข้อจำกัดไหม

มี ข้อจำกัดที่สำคัญที่สุดคือโดยค่าเริ่มต้น ผู้ใช้จะค้นหาข้อมูลได้เพียง 1 TB ต่อเดือน หากเกินกว่านั้น ระบบจะคิดค่าบริการมาตรฐานที่ $5/TB

ฉันจะดูข้อมูลเพิ่มเติมเกี่ยวกับ BigQuery ได้จากที่ใด

ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบของ BigQuery