הנתונים הגולמיים של דוח חוויית המשתמש ב-Chrome (CrUX) זמינים ב-BigQuery, מסד נתונים ב-Google Cloud. כדי להשתמש ב-BigQuery צריך פרויקט GCP וידע בסיסי ב-SQL.
במדריך הזה תלמדו איך להשתמש ב-BigQuery כדי לכתוב שאילתות על מערך הנתונים של CrUX כדי לחלץ תוצאות מועילות לגבי המצב של חוויות המשתמש באינטרנט:
- הסבר על האופן שבו הנתונים מסודרים
- כתיבת שאילתה בסיסית כדי להעריך את הביצועים של המקור
- כתיבת שאילתה מתקדמת כדי לעקוב אחר ביצועים לאורך זמן
ארגון הנתונים
נתחיל בבחינת שאילתה בסיסית:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
כדי להריץ את השאילתה, מזינים אותה בעורך השאילתות ולוחצים על 'הרצת השאילתה' לחצן:
לשאילתה הזו יש שני חלקים:
המשמעות של
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'
- מדדי חוויית המשתמש עצמם
- first_ Paint (FP)
- first_contentful_ Paint (FCP)
- dom_content_available (DCL)
- onload (OL)
- substitute.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 אלפיות השנייה. הסכום של כל ערכי הדחיסות הוא 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 משתנה בכמה אחוזים בכל חודש.
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 ו-PageSpeed Insights. לדוגמה, BigQuery מאפשר לחלק את הנתונים בדרכים משמעותיות ואפילו לאחד אותם למערכי נתונים ציבוריים אחרים, כמו HTTP Archive כדי לבצע כריית נתונים מתקדמת.
האם יש מגבלות על השימוש ב-BigQuery?
כן, המגבלה החשובה ביותר היא שכברירת מחדל, משתמשים יכולים לשלוח שאילתות רק על נתונים בנפח 1TB בחודש. מעבר לכך, חל התעריף הרגיל של $5/TB.
איפה אפשר לקבל מידע נוסף על BigQuery?
מידע נוסף זמין במסמכי התיעוד של BigQuery.