דף זה תורגם על ידי Cloud Translation API.

סוגי ניווט זמינים עכשיו ב-CrUX

Barry Pollard

Johannes Henkel

החל ממערך הנתונים של מרץ 2024, דוח חוויית המשתמש ב-Chrome (CrUX) כולל מדד navigation_types. כאן מוצגים נתונים סטטיסטיים מצטברים לגבי סוגי הניווט של טעינות דפים עבור המאפיין שלגביו נשלחה שאילתה.

סוגי ניווט שונים גורמים להבדלים במדדי הביצועים, כך שכשבוחנים את ביצועי האתר, כדאי להבין את התדירות היחסית של הסוגים השונים האלה. לדוגמה, כשניווט משתמש במטמון לדף הקודם/הבא (bfcache), התוצאה היא בדרך כלל ניווט כמעט מיידי, שמשתקף במדדי LCP ו-FCP קטנים מאוד, ובמדדי CLS ו-INP נמוכים מאוד.

באמצעות חשיפת הפירוט של סוגי הניווט, אנחנו מקווים לעודד את בעלי האתרים להיות מודעים יותר לסוגי הניווט שבהם משתמשים באתרים שלהם, ולנסות לעודד כמה מסוגי הניווט המהירים יותר על ידי בדיקת הגדרת השמירה במטמון, חסימת bfcache ועיבוד מראש.

המדד navigation_types זמין ב-daily CrUX API, ב-CrUX History API (עם היסטוריה זמינה של 3 שבועות בהתחלה, והכיסוי שלה גדל מדי שבוע לכיסוי מלא במהלך 6 החודשים הבאים), במערך הנתונים האחרון של CrUX ב-BigQuery ובלוח הבקרה של CrUX. ההיסטוריה מאפשרת לבעלי אתרים גם לראות שינויים בשימוש בסוגי הניווט לאורך זמן. כך אפשר לעקוב אחרי השיפורים (לדוגמה, הסרת חסימה של המטמון לדף הקודם/הבא). הוא גם יכול להסביר את השינויים במדדים, גם אם לא בוצעו שינויים באתרים שלהם.

הבחנה בין סוגי הניווט CrUX השונים בטבלה הבאה:

סוג	תיאור
`navigate`	טעינת דף, שלא מתאימה לאף אחת מהקטגוריות האחרות.
`navigate_cache`	טעינת דף שעבורה הוצג המשאב הראשי (מסמך ה-HTML הראשי) ממטמון ה-HTTP. לעיתים קרובות אתרים משתמשים בשמירה במטמון של משאבי משנה, אבל בדרך כלל מסמך ה-HTML הראשי נשמר באופן משמעותי פחות במטמון. כשהדבר אפשרי, ניתן לשפר באופן משמעותי את הביצועים מהיכולת לשמור במטמון באופן מקומי וב-CDN.
`reload`	המשתמש טען מחדש את הדף על ידי לחיצה על לחצן הטעינה מחדש, על ידי הקשה על Enter בסרגל הכתובות או על ידי ביטול סגירת כרטיסייה. טעינות מחדש של דפים בדרך כלל מובילות לאימות מחדש חזרה לשרת כדי לבדוק אם הדף הראשי השתנה. אחוז גבוה של טעינות מחדש של דפים עשוי להצביע על תסכול בקרב המשתמשים.
`restore`	הדף נטען מחדש אחרי הפעלה מחדש של הדפדפן או כרטיסייה שהוסרה משיקולי זיכרון. ב-Chrome ב-Android, הערכים האלה מדווחים כ-`reload` במקום זאת.
`back_forward`	ניווט בהיסטוריה, כלומר הדף נראה והוחזרה אליו לאחרונה. כשהשמירה במטמון נכונה, החוויה באתרים האלה צריכה להיות מהירה יחסית, אבל עדיין יש צורך בעיבוד של הדף ובהפעלת JavaScript – ומשתי הפלטפורמות האלה נמנעת השמירה במטמון לדף הקודם/הבא.
`back_forward_cache`	ניווט בהיסטוריה שהוצג מהמטמון לדף הקודם/הבא. אופטימיזציה של הדפים כדי לנצל את המטמון לדף הקודם/הבא אמורה להאיץ את חוויית המשתמש. אתרים צריכים להסיר חוסמי מטמון לדף הקודם/הבא כדי לשפר את אחוז הניווטים בקטגוריה הזו.
`prerender`	הדף עבר עיבוד מראש, בדומה למטמון לדף הקודם/הבא – יכול לגרום לטעינת דפים כמעט מיידית.

במקרים מסוימים, טעינת דף יכולה להיות שילוב של כמה סוגי ניווט. במקרה כזה, מערכת CrUX מדווחת על ההתאמה הראשונה בסדר הפוך מהטבלה הקודמת (מלמטה למעלה).

המגבלות של סוגי הניווט ב-CrUX

מכיוון ש-CrUX הוא מערך נתונים ציבורי, רמת הפירוט של הדיווח שלו מוגבלת. בכתובות URL ומקורות רבים, המדד navigation_types לא זמין כי יש מספיק תנועה שעומדת בדרישות. מידע נוסף זמין במתודולוגיית CrUX.

בנוסף, אי אפשר לקבל ב-CrUX פירוט של מדדים אחרים לפי סוג ניווט, כי זה יצמצם עוד יותר את מספר המקורות וכתובות ה-URL שזמינים ב-CrUX.

מומלץ שאתרים יטמיעו מעקב אחר משתמשים אמיתיים (RUM) כדי לפלח את התנועה לפי קריטריונים כמו סוגי הניווט. לתשומת ליבכם: יכולים להיות הבדלים בסוגי הניווט בפתרונות האלה, בהתאם לסוגים המדווחים והצפיות בדפים שנכללות במאמר. למה נתוני CrUX שונים מנתוני ה-RUM שלי?

RUM יכול גם לספק רמת פירוט גבוהה יותר לגבי בעיות ספציפיות בביצועים. לדוגמה, יכול להיות ש-CrUX ירמז שכדאי לשפר את הכשירות של המטמון לדף הקודם/הבא, bfcache not deletedReasons 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, יש להריץ אותה בנקודת הקצה queryHistoryRecord במקום ב-queryRecord. לדוגמה, בדוח CrUX History Colab שלנו מוצג המדד navigation_types כעמודות מוערםות:

תרשים עמודות אופקי מוערם שבו מוצגת ההיסטוריה של סוגי הניווט במשך 3 שבועות, כשרוב הניווטים הם 'ניווט' ללא שינויים משמעותיים במהלך שלושת השבועות. — סוגי ניווט לאורך זמן

בצילום המסך הקודם, ההיסטוריה זמינה רק ל-3 תקופות איסוף (28 ימים כל אחת, בהפרש של 7 ימים). אחרי שהאכלוס יהיה מלא, המדד הזה יכסה את כל 25 התקופות של איסוף הנתונים. הצגה חזותית של ההיסטוריה מאפשרת לוודא שהאופטימיזציות נכנסו לתוקף או שהתבצעו חזרה למצב הקודם. זה נכון במיוחד לגבי הגדרות של מטמון HTTP, אופטימיזציה של דף למטמון לדף הקודם/הבא ולעיבוד מראש.

סוגי ניווט ב-CrUX BigQuery

עכשיו טבלאות CrUX ב-BigQuery כוללות רשומת navigation_type, מכל סוג. התצוגות המהותיות של סיכום כוללות כמה עמודות navigation_types_* – אחת לכל סוג.

טבלאות מפורטות

סכימת הטבלאות המפורטת ב-CrUX BigQuery מספקת היסטוגרמות מפורטות של מדדי הביצועים באינטרנט, שמאפשרות לנו להראות בניתוח לדוגמה הזה את הקשר בין סוגי ניווט מסוימים לבין ביצועי טעינה מיידית או טובים.

לדוגמה, בדקנו את השבר back_forward_cache ואת הקשר שלו לתדירות הטעינה של דפים באופן מיידי (instant_lcp_density מוגדר כ-LCP <= 200ms) ולתדירות שבה מדד LCP טוב נראה (ערך good_lcp_density הוגדר כ-LCP <= 2,500ms). שמנו לב שיש מתאם סטטיסטי חזק בין back_forward_cache ל-instant_lcp_density (~0.87) – שמוצג בתרשים הבא – ויש מתאם בינוני בין back_forward_cache ל-good_lcp_density (~0.29).

תרשים התאמה שמציג קשר חזק בין שיעור הטעינה של דפים מיידיים לבין החלק של טעינת הדף במטמון לדף הקודם/הבא — הקשר בין טעינות דפים מיידיות לשימוש במטמון לדף הקודם/הבא

התקבלה תגובה טובה ב-Colab לניתוח הזה; כאן נדון רק בשאילתה שמחלצת מהטבלאות המפורטות ב-CrUX BigQuery את השברים מסוג Navigation_types של 10, 000 המקורות הפופולריים ביותר:

אנחנו נכנסים לטבלה all.202403 כאן (ראו סעיף FROM), ומסננים לפי form_factor לפי phone, ובוחרים מקורות עם דירוג פופולריות <= 10,000 כדי להציג את 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 מצביע על כך שאנחנו יכולים לנסות לבצע אופטימיזציה של טעינות הדפים האלה כדי שניתן יהיה להציג אותם מהמטמון לדף הקודם/הבא.

עם זאת, חשוב גם לקחת בחשבון איזה חלק מטעינות הדפים כבר מוצג על ידי המטמון לדף הקודם/הבא – כלומר, שיעור ההיטים של המטמון לדף הקודם/הבא. השאילתה הבאה מצביעה על כך שייתכן שהמקור הספציפי הזה כבר עבר אופטימיזציה, בהתחשב ב-> 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.