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

Barry Pollard
Michal Mocny

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

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

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

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

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

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

מהי ניווט רך?

הגדרנו את המושג ניווט רך באופן הבא:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך מודדים את הזמן עד הבייט הראשון?

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

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

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

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

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

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

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

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

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

משוב

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

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

יומן שינויים

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

סיכום

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

תודות

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

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