ניסוי במדידת ניווטים רכים

Barry Pollard

Yoav Weiss

מאז ההשקה, מיזם הליבה לבדיקת חוויית המשתמש באתר נועד למדוד את חוויית המשתמש בפועל באתר, ולא את הפרטים הטכניים לגבי האופן שבו אתר נוצר או נטען. שלושת המדדים של Core Web Vitals נוצרו כמדדים שמתמקדים במשתמשים – התפתחות של מדדים טכניים קיימים, כמו DOMContentLoaded או load, שמודדים תזמונים שבדרך כלל לא קשורים לאופן שבו המשתמשים תפסו את ביצועי הדף. לכן הטכנולוגיה שבה נעשה שימוש בבניית האתר לא אמורה להשפיע על הציון שהאתר מספק.

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

הרבה מסגרות JavaScript משתמשות במודל הזה, אבל כל אחת בדרך אחרת. מעקב זה שונה מ"דף" מבחינת הדפדפן, ולכן תמיד היה קשה למדוד זאת: היכן יש לצייר את הקו בין אינטראקציה בדף הנוכחי, ולא להחשיב את זה כדף חדש?

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

מהו ניווט עם תכונות חכמות?

לשם כך הכנו את ההגדרה הבאה לניווט רך:

• הניווט מתחיל בפעולת משתמש.
• הניווט גורם לשינוי גלוי בכתובת ה-URL למשתמש ולשינוי בהיסטוריה.
• בעקבות הניווט יתבצע שינוי ב-DOM.

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

איך Chrome משלב ניווטים עם יכולת שחזור?

לאחר ההפעלה של היוריסטיקה קלה לניווט (מידע נוסף על כך בקטע הבא), Chrome ישנה את האופן שבו הוא מדווח על מדדי ביצועים מסוימים:

• אירוע soft-navigation PerformanceTiming יושמע אחרי כל זיהוי של ניווט עם יכולת שחזור.
• ה-API של הביצועים יספק גישה לרשומה של תזמון soft-navigation, כפי שנדרש על ידי האירוע soft-navigation PerformanceTiming.
• המדדים First Paint (FP), First Contentful Paint (FCP) והמהירות שבה נטען רכיב התוכן הכי גדול (LCP) יאופסו ויועברו מחדש במופעים המתאימים הבאים של המצבים האלה. (הערה: FP ו-FCP לא מוטמעים).
• מאפיין navigationId יתווסף לכל תזמונים של הביצועים (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event ו-layout-shift) התואמים לרשומת הניווט שאליה האירוע היה קשור, ויאפשר את החישוב של Cumulative Layout Shift (CLS) ו-מהירות התגובה לצבע הבא (INP).

השינויים האלה יאפשרו למדוד את מדדי הליבה לבדיקת חוויית המשתמש באתר – ואת חלק ממדדי האבחון המשויכים לכל ניווט בדף, אבל יש כמה ניואנסים שצריך להביא בחשבון.

מה ההשלכות של הפעלת ניווטים עם יכולת שחזור ב-Chrome?

אלה כמה מהשינויים שבעלי אתרים צריכים לקחת בחשבון אחרי שמפעילים את התכונה הזו:

• יכול להיות שאירועי FP, FCP ו-LCP נוספים יישלחו מחדש עבור ניווטים קלים. דוח חוויית המשתמש ב-Chrome (CrUX) יתעלם מהערכים הנוספים האלה, אבל הדבר עשוי להשפיע על כל מעקב אחר מדידות משתמשים (RUM) באתר שלך. אם יש לכם חששות אם השינוי ישפיע על המדידות האלה, פנו לספק ה-RUM. עיינו בקטע על מדידת מדדי הליבה לבדיקת חוויית המשתמש באתר בשביל ניווטים קלים.
• ייתכן שיהיה צורך להביא בחשבון את המאפיין החדש (והאופציונלי) navigationID ברשומות של נתוני הביצועים באמצעות הרשומות האלה.
• רק דפדפנים המבוססים על Chromium יתמכו במצב החדש הזה. רבים מהמדדים החדשים ביותר זמינים רק בדפדפנים המבוססים על Chromium, אבל חלקם (FCP, LCP) זמינים בדפדפנים אחרים, ולא כולם שדרגו לגרסה העדכנית ביותר של הדפדפנים שמבוססים על Chromium. לכן, חשוב לשים לב לכך שחלק מהמשתמשים לא ידווחו על מדדי הניווט הרך.
• מדובר בתכונה ניסיונית חדשה שאינה מופעלת כברירת מחדל. לכן, בעלי האתרים צריכים לבדוק את התכונה כדי לוודא שאין תופעות לוואי לא רצויות אחרות.

מידע נוסף על מדידת המדדים של ניווטים רכים זמין במאמר מדידת מדדי הליבה לבדיקת חוויית המשתמש באתר לכל ניווט רך.

איך מפעילים ניווטים עם יכולת ניווט ב-Chrome?

ניווטים רכים לא מופעלים כברירת מחדל ב-Chrome, אבל הם זמינים לניסוי על ידי הפעלה מפורשת של התכונה הזו.

אצל מפתחים, אפשר להפעיל את האפשרות הזו על ידי הפעלת הדגל תכונות ניסיוניות של פלטפורמת האינטרנט ב-chrome://flags/#enable-experimental-web-platform-features או באמצעות שימוש בארגומנט של שורת הפקודה --enable-experimental-web-platform-features כשמפעילים את Chrome.

איך אפשר למדוד ניווטים עם יכולת ניווט?

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

דיווח על ניווטים עם יכולת ניווט

אתם יכולים להשתמש בPerformanceObserver כדי לבדוק ניווטים עם יכולת שחזור. לפניכם קטע קוד לדוגמה לרישום כניסות עם יכולת ניווט רכה למסוף – כולל ניווטים רכים קודמים בדף הזה באמצעות האפשרות buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

אפשר להשתמש בכך כדי להשלים מדדים של כל משך החיים של הניווט הקודם.

דיווח על המדדים מול כתובת ה-URL המתאימה

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

אפשר להשתמש במאפיין navigationId של המאפיין PerformanceEntry המתאים כדי לקשר את האירוע לכתובת ה-URL הנכונה. אפשר לבדוק את זה באמצעות ה-API של PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

צריך להשתמש במאפיין pageUrl הזה כדי לדווח על המדדים מול כתובת ה-URL הנכונה, במקום כתובת ה-URL הנוכחית שייתכן ששימשה אותם בעבר.

מקבלים startTime של ניווטים עם יכולת שחזור

ניתן לקבל את שעת ההתחלה של הניווט באופן דומה:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime הוא הזמן של האינטראקציה הראשונית (לדוגמה, לחיצה על לחצן) שגרמה להפעלת הניווט הרך.

כל התזמונים של הביצועים, כולל תזמונים של ניווטים רכים, מדווחים כזמן מההתחלתי ה'קשה' בזמן הניווט בדף. לכן, שעת ההתחלה של הניווט הרך נדרשת כדי לקבוע את ערכי ברירת המחדל של זמני הטעינה של הניווט עם יכולת רכה (למשל LCP), ביחס לזמן הניווט הרך.

מדידת מדדי הליבה לבדיקת חוויית המשתמש באתר לכל ניווט רך

כדי לכלול רשומות של מדדי ניווט עם תכונות רכות, צריך לכלול את includeSoftNavigationObservations: true בקריאה של בודק הביצועים ל-observe.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

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

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

איך יש להתייחס לתוכן שלא משתנה בין הניווטים?

הפרמטרים FP, FCP ו-LCP בניווטים רכים ימדדו צבעים חדשים בלבד. כתוצאה מכך, ערך LCP שונה, לדוגמה, מעומס קר של הניווט הרך ועד לטעינה רכה.

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

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

איך מודדים את טופס ה-TTDFB?

זמן עד בייט ראשון (TTFB) לטעינה רגילה של דף, מייצג את הזמן שבו מוחזרים הבייטים הראשונים של הבקשה המקורית.

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

שיטה פשוטה יותר היא לדווח על ערך 'TTDFB' של 0 בניווטים רכים, באותו אופן שבו אנחנו ממליצים על שחזורים של מטמון לדף הקודם/הבא. זו השיטה שמשמשת את הספרייה web-vitals לניווטים רכים.

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

איך מודדים גם ישן וגם חדש?

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

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

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

צריך להשתמש בספרייה web-vitals כדי למדוד את מדדי הליבה לבדיקת חוויית המשתמש באתר עבור ניווטים קלים

הדרך הקלה ביותר להביא בחשבון את כל הניואנסים היא להשתמש בספריית ה-JavaScript web-vitals, שכוללת תמיכה ניסיונית בניווטים קלים נפרד soft-navs branch (שזמין גם ב-npm וב-unpkg). אפשר למדוד את זה באופן הבא (מחליפים את doTraditionalProcessing ואת doSoftNavProcessing בהתאם לצורך):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

מוודאים שהמדדים מדווחים על כתובת ה-URL הנכונה כפי שצוין קודם לכן.

הספרייה web-vitals מדווחת על המדדים הבאים לגבי ניווטים עם יכולת שחזור:

האם השינויים האלה יהפכו לחלק מהמדידות של מדדי הליבה לבדיקת חוויית המשתמש באתר?

זהו ניסוי ניווט רך שמתאים בדיוק לו – ניסוי. אנחנו רוצים לבחון את היוריסטיקה ולבדוק אם הם משקפים בצורה מדויקת יותר את חוויית המשתמש לפני שאנחנו מקבלים החלטה אם לשלב אותם ביוזמה Core Web Vitals. אנחנו שמחים מאוד להשתתף בניסוי הזה, אבל אנחנו לא יכולים להבטיח אם ומתי הוא יחליף את המדידות הנוכחיות.

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

איך יתבצע הדיווח על ניווטים עם יכולת שחזור ב-CrUX?

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

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

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

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

משוב

אנחנו מבקשים משוב על הניסוי הזה במקומות הבאים:

• היוריסטיקה וסטנדרטיזציה של הניווטים הקלים.
• בעיות בהטמעה ב-Chrome של היוריסטיקה הזו.
• משוב כללי על תפקוד האפליקציה בכתובת web-vitals-feedback@googlegrouops.com.

יומן שינויים

מכיוון שה-API הזה נמצא בשלבי ניסוי, מתרחשים בו כמה שינויים, יותר מאשר בממשקי API יציבים. אפשר לקרוא פרטים נוספים ביומן השינויים ההיוריסטיים בניווט רך.

סיכום

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

אישורים

תמונה ממוזערת של ג'ורדן מדריד בביטול הפתיחה