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

Rick Viscomi

ข้อมูลดิบของรายงาน UX ของ Chrome (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, ปีและเดือนของข้อมูลในรูปแบบ ปปปปดด

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

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

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

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

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

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

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

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

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

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

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

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

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

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