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

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

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

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

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

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

מהו ניווט בסיסי?

פיתחנו את ההגדרה הבאה של ניווט בסיסי:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך אפשר למדוד ניווטים מהירים?

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

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

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

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

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

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

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

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

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 בשיטה 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 שונה.

כיצד למדוד את TTFB?

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

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

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

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

כיצד למדוד גם ישן וגם חדש?

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

המדד פרטים
TFC דיווח כ-0.
FCP בשלב זה, רק ה-FCP הראשון של הדף מדווח על ידי ספריית web-vitals.
LCP הזמן של הצגת התוכן (FCP) הגדול הבא, ביחס לשעת ההתחלה של הניווט הרך. צבעים קיימים שהוצגו מהניווט הקודם לא נלקחים בחשבון. לכן, ערך ה-LCP יהיה >= 0. כרגיל, הדיווח ידווח על אינטראקציה או כשהדף מועבר ברקע, מאחר שרק כך ניתן להשלים את ה-LCP.
CLS חלון השינויים הגדול ביותר בין זמני הניווט. כמו תמיד, כשהדף ברקע נמצא רק אז אפשר לסיים את ה-CLS באופן סופי. המערכת מדווחת על ערך 0 אם אין תנודות.
INP ערך ה-INP בין זמני הניווט. כמו תמיד, נדווח על כך באינטראקציה או כשהדף יתבסס על רקע, כמו שרק אז ניתן להשלים את ה-INP. הערך 0 לא מדווח אם לא מתקיימות אינטראקציות.

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

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

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

איך ניווטים רכים ידווחו ב-CrUX?

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

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

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

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

משוב

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

יומן שינויים

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

סיכום

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

אישורים

תמונה ממוזערת של ג'ורדן מדריד ב-UnFlood