מדידת מעברים רכים בין דפים

Barry Pollard
Michal Mocny

פורסם: 1 בפברואר 2023, עדכון אחרון: 8 ביולי 2026

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

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

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

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

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

מהו ניווט רך?

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

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

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

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

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

סמן ניווט רך בחלונית הביצועים עם נתונים מ-youtube.com.

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

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

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

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

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

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

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

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

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

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

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

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

התכונה 'מעברים חלקים בין דפים' אמורה להיות מופעלת כברירת מחדל ב-Chrome 151, אבל אפשר להפעיל אותה באופן מפורש כדי לבדוק אותה לפני כן.

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

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

תמיכה ב-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 המתאימה

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

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

צריך להגדיר את הערך הזה כערך של כל רשומה מסוג soft-navigation ולהשתמש בו כדי לדווח על מדדים עד לקבלת הרשומה הבאה מסוג soft-navigation.

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

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

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

קבלת startTime של ניווטים רכים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך מודדים TTFB?

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

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

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

האם כדאי למדוד את מדדי הליבה לבדיקת חוויית המשתמש באתר באמצעות שתי המתודולוגיות?

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

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

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

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

שימוש בספריית 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 מדווחת על המדדים הבאים לגבי מעברים רכים:

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

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

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

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

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

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

משוב

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

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

יומן שינויים

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

סיכום

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

תודות

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

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