החל ממערך הנתונים של מרץ 2024, דוח חוויית המשתמש ב-Chrome (CrUX) כולל את המדד navigation_types
. כך מוצגים נתונים סטטיסטיים מצטברים לגבי סוגי הניווט של טעינות דפים עבור המאפיין שלגביו נשלח שאילתה.
סוגי ניווט שונים גורמים להבדלים במדדי הביצועים. לכן, כשבוחנים את הביצועים של האתר, חשוב להבין את התדירות היחסית של הסוגים השונים האלה. לדוגמה, כשבניווט נעשה שימוש בחזרה לדף הקודם (bfcache), זה בדרך כלל מוביל לניווט כמעט מיידי, שיבוא לידי ביטוי במדדים קטנים מאוד של LCP ו-FCP, ולירידה במדדי CLS ו-INP.
על ידי חשיפת הפירוט של סוגי הניווט, אנחנו מקווים לעודד את בעלי האתרים להיות מודעים לסוגי הניווט שבהם משתמשים באתרים שלהם, ולעודד כמה מסוגי הניווט המהירים יותר באמצעות בחינת ההגדרות של השמירה במטמון, חוסמי bfcache ועיבוד מראש.
המדד navigation_types
זמין בממשק ה-API היומי של CrUX, ב-CrUX History API (היסטוריה של 3 שבועות זמינה בהתחלה, ועד כיסוי שבועי מלא ב-6 החודשים הבאים), במערך הנתונים האחרון של CrUX BigQuery ובלוח הבקרה של CrUX. ההיסטוריה גם מאפשרת לבעלי האתרים לראות לאורך זמן שינויים בשימוש בסוג הניווט. כך תוכלו לעקוב אחרי שיפורים (למשל, הסרת החסימה של המטמון לדף הקודם/הבא). היא יכולה גם להסביר שינויים במדדים גם אם לא בוצעו שינויים באתרים שלהם.
אילו סוגי ניווט זמינים ב-CrUX?
בטבלה הבאה מוצגים סוגים שונים של ניווט ב-CrUX:
סוג | תיאור |
---|---|
navigate |
טעינת דף, שלא מתאימה לאף אחת מהקטגוריות האחרות. |
navigate_cache |
טעינת דף שבה המשאב הראשי (מסמך ה-HTML הראשי) הוצג ממטמון HTTP. לעיתים קרובות אתרים משתמשים בשמירה במטמון למשאבי משנה, אבל בדרך כלל מסמך ה-HTML הראשי נשמר במטמון באופן משמעותי. במקרים כאלה, היא יכולה להוביל לשיפורים משמעותיים בביצועים, כתוצאה מהיכולת לשמור במטמון באופן מקומי וב-CDN. |
reload |
המשתמש טען מחדש את הדף על ידי הקשה על לחצן 'טען מחדש', על ידי הקשה על Enter בסרגל הכתובות, או על ידי ביטול סגירת כרטיסייה. טעינות מחדש של דפים גורמות בדרך כלל לאימות מחדש לשרת כדי לבדוק אם הדף הראשי השתנה. אחוז גבוה של טעינות מחדש של דפים עשוי להצביע על משתמשים מתוסכלים. |
restore |
הדף נטען מחדש אחרי הפעלה מחדש של הדפדפן או כרטיסייה שהוסרה מסיבות של זיכרון. ב-Chrome ב-Android הם מדווחים כ-reload במקום זאת. |
back_forward |
ניווט דרך ההיסטוריה, כלומר הדף נצפה והוחזר לאחרונה. שמירה נכונה במטמון צריכה לספק חוויית שימוש מהירה למדי, אבל עדיין צריך לעבד את הדף ולהריץ את JavaScript, ובשני המקרים האלה מטמון לדף הקודם/הבא נמנע. |
back_forward_cache |
ניווט בהיסטוריה שהוצג מהמטמון לדף הקודם/הבא. אופטימיזציה של הדפים לניצול המטמון של המטמון אמורה להוביל לחוויות מהירות יותר. כדי לשפר את אחוז הניווטים בקטגוריה הזו, כדאי באתרים להסיר חוסמי bfcache. |
prerender |
הדף עובד מראש, וכתוצאה מכך, בדומה למטמון לדף הקודם/הבא, עשוי להיטען דף באופן כמעט מיידי. |
במקרים מסוימים, טעינת דף יכולה להתבסס על שילוב של כמה סוגי ניווט. במקרה כזה, הדיווח על CrUX מדווח על ההתאמה הראשונה בסדר הפוך מטבלה הקודמת (מלמטה למעלה).
המגבלות של סוגי הניווט ב-CrUX
CrUX הוא מערך נתונים ציבורי, ולכן רמת הפירוט של הדיווח שלו מוגבלת. בהרבה מקורות וכתובות URL, המדד navigation_types
לא זמין כי אין מספיק תנועה כשירה. מידע נוסף זמין במתודולוגיית CrUX.
בנוסף, אין ל-CrUX אפשרות לראות פירוט של מדדים אחרים לפי סוג הניווט, כי השינוי הזה יצמצם עוד יותר את מספר המקורות וכתובות ה-URL הזמינים ב-CrUX.
מומלץ להטמיע באתר מעקב אחר משתמשים בפועל (RUM) משלהם כדי שיוכלו לפלח את התנועה לפי קריטריונים כמו סוגי הניווט. לתשומת ליבכם: ייתכנו הבדלים בין סוגי הניווט בפתרונות האלה, בהתאם לסוגים שדווחו ולתצוגות הדפים שכלולות בדוח. במאמר למה נתוני CrUX שונים מנתוני ה-RUM?
RUM יכול גם לספק רמת פירוט גבוהה יותר לגבי בעיות ספציפיות בביצועים. לדוגמה: יכול להיות ש-CrUX משתמע שכדאי לשפר את הכשירות של bfcache, אבל ה-bfcache not managedReasons API יכול לציין בדיוק למה לא ניתן להציג טעינת דף מסוימת מהמטמון לדף הקודם/הבא.
סוגי ניווט ב-CrUX API
כדי לראות את סוגי הניווט ב-API, צריך לכלול בבקשה את המדד navigation_types
, או לא להגדיר מדד כך שכל המדדים ייכללו בו:
export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
--header 'Content-Type: application/json' \
--data '{"origin": "https://example.com", metrics: ["navigation_types"]}'
פורמט הבקשה מתואר בפירוט רב יותר במסמכי התיעוד של ה-API, כולל הסבר על קבלת מפתח ה-API ומדריך ה-API. הפעולה הזו תחזיר אובייקט כזה:
{
"record": {
"key": { "origin": "https://example.com" },
"metrics": {
"navigation_types": {
"fractions": {
"navigate": 0.5335,
"navigate_cache": 0.2646,
"reload": 0.0885,
"restore": 0.0023,
"back_forward": 0.0403,
"back_forward_cache": 0.0677,
"prerender": 0.0031
}
}
},
"collectionPeriod": {
"firstDate": { "year": 2024, "month": 3, "day": 6 },
"lastDate": { "year": 2024, "month": 4, "day": 2 }
}
}
}
בתגובה, CrUX מדווח על המדד navigation_types
כאובייקט עם שברים של טעינות דף לכל אחד מסוגי הניווט. כל שבר הוא ערך בין 0.0
(המציין 0% מטעינות הדף) ל-1.0
, (המציין 100% מטעינות הדפים) של המפתח הנתון.
ניתן לראות מהתשובה הזו שבתקופת האיסוף שהתחילה ב-6 במרץ 2024 – כולל 2 באפריל 2024 – 6.77% מהניווטים (טעינת דפים) הוצגו מהמטמון לדף הקודם/הבא של הדפדפן. בדומה לכך, חלק מהחלקים האחרים יכולים לעזור בזיהוי הזדמנויות לאופטימיזציה של טעינת דפים. שימו לב: לכל מפתח נתון (כולל שילוב של כתובת URL או מקור וגורם צורה), ערכי השברים של navigation_types
יסתכמו ב-1.0 בערך.
סוגי ניווט ב-CrUX History API
CrUX History API יכולה לספק סדרות זמנים לסוגי ניווט עם עד 25 נקודות נתונים לכל שבר. כך אפשר להמחיש את הערכים האלה לאורך זמן. כדי לשנות את הבקשה מ-CrUX API ל-CrUX History API, צריך להריץ אותה בנקודת הקצה (endpoint) queryHistoryRecord
במקום ב-queryRecord
. לדוגמה, בכלי CrUX History Colab מוצג המדד navigation_types
כעמודות מוערמות:
בצילום המסך הקודם, ההיסטוריה זמינה ל-3 תקופות איסוף בלבד (28 ימים כל אחת, 7 ימים ביניהן). אחרי שהנכס יאוכלס במלואו, הערך הזה יכסה את כל 25 תקופות האיסוף. הצגה חזותית של ההיסטוריה מאפשרת לוודא שהאופטימיזציות נכנסו לתוקף או שכבר הורדו. הדבר נכון במיוחד לגבי תצורה של מטמון HTTP, אופטימיזציה של דף לשמירה במטמון לדף הקודם/הבא ולעיבוד מראש.
סוגי ניווט ב-CrUX BigQuery
הטבלאות של CrUX ב-BigQuery כוללות עכשיו רשומת navigation_type
מכל סוג, ואילו התצוגות המפורטות בסיכום כוללות כמה עמודות navigation_types_*
– אחת לכל סוג.
טבלאות מפורטות
סכימת הטבלה המפורטת ב-CrUX BigQuery מספקת היסטוגרמות מפורטות של מדדי הביצועים באינטרנט, שמאפשרות לנו להראות בניתוח לדוגמה הזה כיצד יש קורלציה בין סוגי ניווט מסוימים לבין ביצועי טעינה מידית או טובה.
לדוגמה, בדקנו את השבר back_forward_cache
ואת המתאם שלו עם התדירות שבה דפים נטענים באופן מיידי (instant_lcp_density
מוגדר כ-LCP <= 200 אלפיות השנייה) ובאיזו תדירות נצפה LCP טוב (good_lcp_density
מוגדר כ-LCP <= 2500ms). הבחנו לקשר סטטיסטי חזק בין back_forward_cache
ל-instant_lcp_density
(סיסמאות=0.87) - שמוצג בתרשים הבא — וקיום מתאם בינוני בין back_forward_cache
ל-good_lcp_density
(סיסמאות=0.29).
יש תגובות טובות ל-Colab לניתוח הזה. כאן אנחנו דנים רק בשאילתה ששולפת את ערכי Navigation_types עבור המקורות הפופולריים ביותר ב-10, 000 מהטבלאות המפורטות ב-CrUX BigQuery:
- אנחנו נכנסים לטבלה
all.202403
כאן (עיינו בסעיףFROM
), ומסננים אתform_factor
לפיphone
ובוחרים מקורות עם דירוג פופולריות <= 10000 כדי למצוא את 10,000 המקורות הפופולריים ביותר (ראו את הסעיף בנושאWHERE
). - כשמריצים שאילתות על המדד
navigation_types
ב-BigQuery, צריך לחלק אותו בסכום הכולל של השברים שלnavigation_types
, כי הם יצטברו רק לפי מקור, אבל לא לפי שילוב (מקור, גורם צורה). - לא לכל המקורות יהיה
navigation_types
, לכן מומלץ להשתמש ב-SAVE_DIVIDE
.
WITH tmp AS (
SELECT
origin,
SUM(navigation_types.navigate.fraction) AS navigate,
SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
SUM(navigation_types.reload.fraction) AS reload,
SUM(navigation_types.restore AS restore,
SUM(navigation_types.back_forward.fraction) AS back_forward,
SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
SUM(navigation_types.prerender.fraction) AS prerender,
SUM(navigation_types.navigate.fraction
+ navigation_types.navigate_cache.fraction
+ navigation_types.reload.fraction
+ navigation_types.restore.fraction
+ navigation_types.back_forward.fraction
+ navigation_types.back_forward_cache.fraction
+ navigation_types.prerender.fraction) AS total
FROM
`chrome-ux-report.all.202403`
WHERE
experimental.popularity.rank <= 10000 AND
form_factor.name = 'phone'
GROUP BY
origin
)
SELECT
origin,
ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
tmp
טבלאות בעיצוב חדש
כשהסיכום מספיק, לעיתים קרובות קל יותר (וזול יותר) להריץ שאילתות על טבלאות שעברו עיבוד ( שמצורף אליהן). לדוגמה, השאילתה הבאה מחלצת את נתוני navigation_types
הזמינים מהטבלה chrome-ux-report.materialized.device_summary
. הטבלה הזו מסומנת לפי חודש, מקור וסוג מכשיר.
SELECT
yyyymm,
device,
navigation_types_navigate,
navigation_types_navigate_cache,
navigation_types_reload,
navigation_types_restore,
navigation_types_back_forward,
navigation_types_back_forward_cache,
navigation_types_prerender
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://example.com' AND
navigation_types_navigate IS NOT NULL
ORDER BY
yyyymm DESC,
device DESC
חשוב לזכור שהשברים האלה לא יסתכמו עד 1.0 בכל שורה, ולכן יש לחלק כל שבר בסכום התוצאות שהשאילתה צריכה לפרש אותן.
הסיבה לכך היא ש-navigation_type
שברים ב-chrome-ux-report.materialized.device_summary
– כמו צפיפות היסטוגרמות – מתווספים עד 1.0 לכל מקור במקום לכל מקור ומכשיר בכל תאריך. כך ניתן להציג את ההתפלגות של סוגי הניווט במכשירים שונים:
SELECT
device,
navigation_types_back_forward
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
navigation_types_back_forward |
---|---|
phone |
0.0663 |
desktop |
0.0179 |
tablet |
0.0009 |
בתוצאת השאילתה הזו, השברים משקפים את אחוז טעינות הדף של המקור https://www.google.com
: 6.63% מטעינות הדפים האלה היו מסוג ניווט back_forward
בטלפון, 1.79% במחשב ו-0.09% בטאבלט.
האחוז הגבוה משמעותית של back_forward
ב-phone
מצביע על כך שאנחנו יכולים לנסות למטב את טעינות הדפים האלה כדי שניתן יהיה להציג אותם מהמטמון לדף הקודם/הבא.
עם זאת, חשוב גם לשקול איזה חלק מטעינת הדף כבר מוצג על ידי המטמון לדף הקודם/הבא - כלומר, שיעור ההיט של bfcache. לפי השאילתה הבאה, יכול להיות שהמקור הספציפי הזה כבר עבר אופטימיזציה, לאור שיעורי ההיטים של יותר מ-60% בטלפון ובמחשבים.
SELECT
device,
navigation_types_back_forward_cache /
(navigation_types_back_forward + navigation_types_back_forward_cache)
AS back_forward_cache_hit_rate
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
back_forward_cache_hit_rate |
---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
לכן, נראה שהשיעור הגבוה של back_forward
בטלפונים לא נובע משימוש מופחת במטמון לדף הקודם/הבא, אלא משקף יותר את האופן שבו המשתמשים מנווטים אחורה וקדימה בטלפונים.
סוגי ניווט במרכז הבקרה של CrUX
הדרך הקלה ביותר לראות את סוגי הניווט היא דרך מרכז הבקרה של CrUX, שניתן לגשת אליו דרך הקישור הזה. כפי שניתן לראות בצילום המסך הבא, רק נתונים של חודש אחד זמינים בהתחלה, אך עם הזמן ההיסטוריה תמולא כך שתוכל לראות שינויים בסוגי בכל חודש.
כפי שניתן לראות, הדגשנו את סוגי הניווט המהירים יותר, שאותם יש לבקש לבצע אופטימיזציה, בחלק העליון של דף זה של מרכז השליטה.
סיכום
אנחנו מקווים שפירוט סוגי הניווט ב-CrUX יועיל לך, ויעזור לך להבין את ביצועי האתר ולבצע אופטימיזציה שלהם. על ידי הבטחת שימוש יעיל בשמירת HTTP במטמון, במטמון לדף הקודם/הבא ובעיבוד מראש, אתרים יכולים להשיג טעינה מהירה יותר של דפים מאשר טעינות דפים שמחייבות נסיעות חזרה לשרת.
אנחנו גם שמחים להעמיד את הנתונים בכל נקודות הגישה השונות של CrUX, כדי שמשתמשים יוכלו לצרוך את הנתונים כרצונם ולראות את פירוט הסוגים לפי כתובת URL עבור אלה שנחשפו בממשקי ה-API של CrUX.
נשמח לקבל משוב על התוספת הזו ל-CrUX ברשתות החברתיות או בקבוצת הדיון של CrUX.