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

Barry Pollard

Michal Mocny

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

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

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

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

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

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

מהי ניווט רך?

ההגדרה של ניווט רך היא:

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

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

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

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

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

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

איך 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 בתוך הניווטים האלה.

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

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

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

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

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

מידע נוסף על מדידת המדדים של ניווטים רכים זמין בקטע מדידת 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 המתאימה

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

מדידת Core Web Vitals לפי ניווט רך

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

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

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

הערך 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 באמצעות שתי המתודולוגיות?

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

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

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

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

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

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

משוב

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

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

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

יומן שינויים

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

סיכום

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

תודות

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

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