ข้อมูลดิบของรายงาน 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 ส่วนดังนี้- ชื่อโปรเจ็กต์ Cloud
chrome-ux-report
ซึ่งมีการจัดระเบียบข้อมูล CrUX ทั้งหมด - ชุดข้อมูล
all
ซึ่งแสดงข้อมูลในทุกประเทศ - ตาราง
202206
ปีและเดือนของข้อมูลในรูปแบบ YYYYMM
- ชื่อโปรเจ็กต์ Cloud
นอกจากนี้ยังมีชุดข้อมูลสำหรับทุกประเทศด้วย ตัวอย่างเช่น 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)
- dom_content_โหลด (DCL)
- ขณะโหลด (OL)
- Experiment.first_input_delay (FID)
ข้อมูลสำหรับแต่ละเมตริกจะได้รับการจัดระเบียบเป็นอาร์เรย์ของออบเจ็กต์ ในรูปแบบ 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 ที่รวดเร็วนั้นแตกต่างกันเพียงไม่กี่เปอร์เซ็นต์ในแต่ละเดือน
ปปปปดด | fast_fcp |
---|---|
202206 | 69.77% |
202205 | 70.71% |
202204 | 69.04% |
202203 | 69.82% |
202202 | 67.75% |
202201 | 58.96% |
202112 | 41.69% |
... | ... |
เทคนิคเหล่านี้ช่วยให้คุณดูประสิทธิภาพของต้นทาง คำนวณเปอร์เซ็นต์ของประสบการณ์ที่รวดเร็ว และติดตามเมื่อเวลาผ่านไปได้ ขั้นตอนถัดไป ให้ลองค้นหาต้นทาง 2 รายการขึ้นไปและเปรียบเทียบประสิทธิภาพของแหล่งที่มาเหล่านั้น
คำถามที่พบบ่อย
คําถามที่พบบ่อยเกี่ยวกับชุดข้อมูล CrUX BigQuery มีดังนี้
ฉันจะใช้ BigQuery แทนเครื่องมืออื่นๆ เมื่อใด
คุณจำเป็นต้องใช้ BigQuery ก็ต่อเมื่อคุณไม่สามารถรับข้อมูลเดียวกันนี้จากเครื่องมืออื่นๆ เช่น แดชบอร์ด CrUX และ PageSpeed Insights ตัวอย่างเช่น BigQuery ช่วยให้คุณแบ่งข้อมูลอย่างมีความหมาย และนำไปรวมกับชุดข้อมูลสาธารณะอื่นๆ เช่น HTTP Archive เพื่อดำเนินการขุดค้นข้อมูลขั้นสูงได้
การใช้ BigQuery มีข้อจำกัดไหม
ใช่ ข้อจำกัดที่สำคัญที่สุดคือโดยค่าเริ่มต้น ผู้ใช้จะค้นหาข้อมูลได้ 1 TB ต่อเดือนเท่านั้น หลังจากนั้นจะใช้อัตรามาตรฐาน $5/TB
ฉันจะดูข้อมูลเพิ่มเติมเกี่ยวกับ BigQuery ได้จากที่ใด
ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบของ BigQuery