הנתונים הגולמיים של דוח חוויית המשתמש ב-Chrome (CrUX) זמינים ב-BigQuery, מסד נתונים ב-Google Cloud. כדי להשתמש ב-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
מציין את הכתובת של טבלת המקור, שכוללת שלושה חלקים:- שם הפרויקט ב-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'
- מדדי חוויית המשתמש עצמם
- הצגת תמונה ראשונה (FP)
- first_contentful_ Paint (FCP)
- dom_content_loaded (DCL)
- onload (OL)
- ניסיוני.first_input_delay (FID)
הנתונים של כל מדד מאורגנים כמערך אובייקטים. בסימון JSON, first_contentful_paint.histogram.bin
ייראה כך:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
כל סל מכיל זמני התחלה וסיום באלפיות שנייה, וצפיפות שמייצגת את אחוז חוויות המשתמש בטווח הזמן הזה. במילים אחרות, 12.34% מחוויות ה-FCP של המקור היפותטי, מהירות החיבור וסוג המכשיר האלה הן פחות מ-100 אלפיות השנייה. הסכום של כל הדחיסות של bin הוא 100%.
הערכת הביצועים
אנחנו יכולים להשתמש בידע שלנו לגבי סכימת הטבלה כדי לכתוב שאילתה שמחלצת את נתוני הביצועים האלה.
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
כדי לחבר את כל ערכי הצפיפות של 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% בכל המכשירים וסוגי החיבורים. אנחנו יכולים לשנות מעט את השאילתה ולהוסיף את הדחיסות לכל הסלים שנמצאים בטווח ה-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 משתנה בכמה אחוזים בכל חודש.
yyyymm | fast_fcp |
---|---|
202206 | 69.77% |
202205 | 70.71% |
202204 | 69.04% |
202203 | 69.82% |
202202 | 67.75% |
202201 | 58.96% |
202112 | 41.69% |
... | ... |
בעזרת הטכניקות האלה אפשר לחפש את הביצועים של מקור מסוים, לחשב את אחוז החוויה המהירה ולעקוב אחרי הביצועים לאורך זמן. בשלב הבא, כדאי להריץ שאילתות על שני מקורות או יותר ולהשוות את הביצועים שלהם.
שאלות נפוצות
אלו כמה מהשאלות הנפוצות לגבי מערך הנתונים של CrUX BigQuery:
מתי כדאי להשתמש ב-BigQuery ולא בכלים אחרים?
BigQuery נדרש רק אם לא ניתן לקבל את אותו המידע מכלים אחרים, כמו 'לוח הבקרה של CrUX' ו-'מדדי מהירות דף'. לדוגמה, BigQuery מאפשר לפלח את הנתונים בדרכים משמעותיות ואפילו לאחד אותם למערכי נתונים ציבוריים אחרים, כמו ארכיון HTTP, כדי לבצע כריית נתונים מתקדמת.
האם יש מגבלות על השימוש ב-BigQuery?
כן. המגבלה החשובה ביותר היא שכברירת מחדל, משתמשים יכולים להריץ שאילתות רק על נתונים בנפח של 1TB בחודש. מלבד זאת, התעריף הרגיל של $5/TB חל.
איפה אפשר לקבל מידע נוסף על BigQuery?
מידע נוסף זמין במסמכי התיעוד של BigQuery.