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

Barry Pollard

Michal Mocny

פורסם: 1 בפברואר 2023, עדכון אחרון: 30 במרץ 2026

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

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

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

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

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

מהי ניווט רך?

ההגדרה הבאה מתייחסת לניווט רך:

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

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

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

הוספנו תמיכה בניווטים רכים לחלונית הביצועים בכלי הפיתוח בתצוגת המעקב:

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

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

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

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

• אירוע soft-navigation PerformanceTiming יופק אחרי כל זיהוי של ניווט רך.
• הרשומה soft-navigation הזו תכלול את הערך navigationId, את כתובת ה-URL החדשה במאפיין name, וגם את הערך interactionId של האינטראקציה הראשונית.
• רשומה אחת או יותר של interaction-contentful-paint תופק אחרי אינטראקציות שגורמות לציור עם תוכן. אפשר להשתמש בזה כדי למדוד את המהירות שבה נטען רכיב התוכן הכי גדול (LCP) עבור ניווטים רכים, כשהאינטראקציה יוצרת ניווט רך.
• המאפיין navigationId מתווסף לכל אחד מהתזמונים של הביצועים (first-paint,‏ first-contentful-paint,‏ largest-contentful-paint,‏ interaction-contentful-paint,‏ first-input-delay,‏ event ו-layout-shift). הוא תואם לרשומה של הניווט שבה האירוע הופק. שימו לב: אם הרשומות האלה מתייחסות לניווטים רכים, הן עשויות להכיל את הערך הקודם או הבא של navigationId, בהתאם למועד שליחת הרשומה. מידע נוסף על כך זמין בקטע דיווח על המדדים ביחס לכתובת ה-URL המתאימה.
• הערך soft-navigation יכלול רשומה של largestInteractionContentfulPaint, כולל הרשומה הגדולה ביותר של interaction-contentful-paint שמופקת כחלק מהניווט. אפשר להשתמש בערך הזה כערך LCP הראשוני של הניווט הזה, ואז לעדכן את ערך ה-LCP ככל שמתקבלות עוד רשומות interaction-contentful-paint של האינטראקציה הזו.
• יכול להיות שחלק מהערכים של interaction-contentful-paint יתרחשו לפני המעבר הרך (אם עדכון כתובת ה-URL לא יקרה עד אחרי הצביעות האלה). במקרים כאלה, הרשומה הגדולה ביותר largestInteractionContentfulPaint מונעת את הצורך בחיץ ובבדיקה של רשומות ישנות. שימו לב שהערך largestInteractionContentfulPaint הוא עותק מדויק של הרשומה הגדולה ביותר interaction-contentful-paint, ולכן ברשומה הזו נעשה שימוש בערך הקודם navigationId כי זה הזמן שבו הציור התרחש, אבל צריך למדוד את הציורים האלה לפי הערך החדש navigationId.
• הערך soft-navigation יכלול גם את הערכים paintTime ו-presentationTime כ-FCP של הניווט הזה.
• חשוב לדעת שגם אחרי אינטראקציות נוספות יונפקו רשומות interaction-contentful-paint, אבל כדי לא לכלול אותן, צריך להגביל את LCP של כתובת URL לרשומות interaction-contentful-paint שתואמות לניווטים הרכים interactionId.

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

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

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

• מעקב אחרי הרשומות soft-navigation מאפשר לנתח את רשומות הביצועים לפי כל 'ניווט'.
• כבר עכשיו אפשר לפלח את המדדים CLS ו-INP לפי שיקול דעתכם, במקום למדוד אותם לאורך כל מחזור החיים של הדף. אבל Soft Navigation API מספק מדד סטנדרטי של מתי זה קורה, ללא קשר לטכנולוגיה הבסיסית שבה נעשה שימוש.
• הערך של largest-contentful-paint נקבע סופית באינטראקציה (שנדרשת כדי להתחיל בניווט רך), ולכן אפשר להשתמש בו רק למדידת ה-LCP של הניווט הראשוני 'הקשה'. המשמעות היא שהערך הזה לא ישתנה כשמודדים ניווטים רכים, כך שאפשר למדוד את LCP לטעינת הדף של הניווט הקשיח הראשוני, כמו תמיד.
• אפשר להשתמש בערך interaction-contentful-paint החדש שמופק מאינטראקציות כדי למדוד את LCP עבור מעברים רכים, אבל יש כמה שיקולים לגבי אופן השימוש בערך הזה, ונדון בהם במאמר הזה.
• חשוב לזכור שלא כל המשתמשים יתמכו ב-API הזה של ניווט רך, במיוחד בגרסאות ישנות יותר של Chrome ובמשתמשים בדפדפנים אחרים. חשוב לדעת שחלק מהמשתמשים לא מדווחים על מדדים שמבוססים על ניווט רך, גם אם הם מדווחים על Core Web Vitals.
• זו תכונה ניסיונית חדשה שלא מופעלת כברירת מחדל, ולכן מומלץ לבדוק אותה באתרים כדי לוודא שאין לה תופעות לוואי לא רצויות.

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

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

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

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

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

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

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

תמיכה ב-API לזיהוי תכונות של מעברים רכים

אפשר להשתמש בקוד הבא כדי לבדוק אם ה-API נתמך:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

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

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

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

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

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

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

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

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

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

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

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

המאפיין name של הרשומה המתאימה soft-navigation יכיל את כתובת ה-URL החדשה שאליה יש לדווח על מדדים, והמאפיין navigationId יהיה ההפניה הייחודית לניווט הזה (כי יכול להיות שכתובת ה-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;

דיווח על כתובת ה-URL הנכונה של interaction-contentful-paint

כדי לחשב את ה-LCP מתוך רשומות interaction-contentful-paint, צריך לקחת בחשבון עוד כמה דברים, כי לא צריך למפות את כל רשומות interaction-contentful-paint באמצעות navigationId ולדווח עליהן כ-LCP עבור כתובת ה-URL הזו:

• הבעיה הראשונה היא שאולי פריטי interaction-contentful-paint יופקו לפני הניווט הרך אם מתבצע רינדור לפני עדכון כתובת ה-URL. במקרים כאלה, הנתונים של navigationId יהיו עבור כתובת ה-URL הישנה. אם כתובת ה-URL מתעדכנת קודם, הצביעה תשלים את הניווט הרך, ובמקרה כזה הפלט של soft-navigation יופיע קודם, ובפלט של interaction-contentful-paint תופיע כתובת ה-URL החדשה.
• הבעיה השנייה היא שinteraction-contentful-paint, רשומות ימשיכו להיפלט לאינטראקציות חדשות יותר, כי ההיקף של מדד לבדיקת ביצועים זה חורג מעבר ל-LCP עבור מעברים רכים. אנחנו רוצים להתייחס רק לציורים של טעינת הניווט הרך לצורך חישוב ה-LCP, ולא לציורים של אינטראקציות עוקבות.

לכן, כדי לקבל את כתובת ה-URL הנכונה, צריך להשתמש ב-interactionId ולא ב-navigationId כדי למפות את הערכים interaction-contentful-paint ל-soft-navigation-entries. הפעולה הזו תטפל בכל הערכים עם navigationId ישנים, ותסנן את כל הערכים של interaction-contentful-paint שלא צריכים להיכלל בחישוב של LCP.

בנוסף, כדאי לעבד גם את רשומת largestInteractionContentfulPaint של רשומות soft-navigation, כדי לטפל בקלות רבה יותר ברשומות interaction-contentful-paint שמתרחשות לפני שרשומת soft-navigation entries מופקת.

הבנת המושג startTime של ניווטים רכים

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

אפשר לקבל את שעת ההתחלה של הניווט באופן דומה על ידי מיפוי לרשומה המתאימה soft-navigation ושימוש ב-startTime שלה.

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

מדידת Core Web Vitals לכל מעבר רך

כדי למדוד את המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), צריך להאזין לערכים soft-navigation ולאפס את המדדים כשמקבלים אותם. אפשר להפיק את ה-FCP על סמך presentationTime ואפשר לאתחל את ה-LCP ל-largestInteractionContentfulPaint. הערכים של INP ו-CLS צריכים להיות מאותחלים ל-0, כמו שהם מאותחלים לטעינת דף.

אחרי ההגדרה, אפשר למדוד את מדדי LCP,‏ INP ו-CLS ולעקוב אחריהם כרגיל (למעט השימוש ב-interaction-contentful-paint למדידת LCP, אם הערך של interactionId תואם). אפשר להשתמש ב-interactionId וב-navigationId כדי לתת שמות לרשומות של כתובות URL, כפי שצוין קודם.

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

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

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

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

הערך LCP עבור מעברים רכים (מחושב מ-interaction-contentful-paint) ימדוד רק צביעות חדשות, ורק צביעות שמשויכות לאינטראקציה שגרמה למעבר. לדוגמה, יכול להיות שערך ה-LCP יהיה שונה בהפעלה מההתחלה (cold load) של ניווט רך לעומת טעינה רכה.

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

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

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

איך מודדים TTFB?

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

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

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

האם כדאי למדוד את Core Web Vitals באמצעות שתי המתודולוגיות?

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

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

לכן, כשמדובר ב-LCP, צריך להתייחס רק לערכי largest-contentful-paint בשיטה הנוכחית, ולערכי largest-contentful-paint ו-interaction-contentful-paint בשיטה החדשה.

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

שימוש בספריית web-vitals למדידת מדדי חוויית המשתמש הבסיסיים (Core 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';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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});

בנוסף, ספריית web-vitals מוודאת שהמדדים מדווחים ביחס לכתובת ה-URL הנכונה כפי שצוין קודם, כי היא כוללת גם את navigationId וגם את navigationURL ברשומות שמועברות לקריאה החוזרת.

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

האם השינויים האלה יהפכו לחלק מהמדדים של Core Web Vitals?

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

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

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

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

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

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

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

משוב

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

• משוב על ה-API צריך להישלח כבעיות ב-GitHub.
• אם אתם נתקלים בבאגים בהטמעה של Chromium, אתם יכולים לדווח עליהם במעקב הבעיות של Chrome, בתנאי שהם לא מופיעים בבעיות הידועות.
• אפשר לשתף משוב כללי על מדדים בסיסיים של חוויית המשתמש בכתובת web-vitals-feedback@googlegroups.com.

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

יומן שינויים

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

סיכום

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

תודות

תמונה ממוזערת מאת Jordan Madrid ב-Unsplash

העבודה הזו היא המשך של עבודה שהתחילה על ידי יואב וייס כשהוא עבד ב-Google. אנחנו מודים ליואב על המאמצים שלו בפיתוח ה-API הזה.