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

Barry Pollard

Michal Mocny

פורסם: 1 בפברואר 2023, עדכון אחרון: 15 בספטמבר 2025

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

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

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

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

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

מהי ניווט רך?

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

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

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

איך Chrome מיישם מעברים רכים?

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

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

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

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

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

• יכול להיות שהמדדים CLS ו-INP ינותחו לפי כתובת URL של ניווט רך, במקום להימדד לאורך משך מחזור החיים של הדף כולו.
• הערך largest-contentul-paint כבר סופי באינטראקציה, ולכן הוא משמש רק למדידה של ה-LCP הראשוני של הניווט 'הקשה', כך שלא נדרשת לוגיקה נוספת כדי לשנות את אופן המדידה.
• המדד החדש interaction-contentful-paint יופק מאינטראקציות, ואפשר להשתמש בו למדידת LCP עבור ניווטים רכים.
• כדי לשייך ניווטים רכים לכתובת ה-URL הנכונה, יכול להיות שתצטרכו להשתמש ברשומות האלה כדי להביא בחשבון את מאפיין navigationID החדש ברשומות הביצועים בקוד האפליקציה.
• לא כל המשתמשים יתמכו ב-API הזה של ניווט רך, במיוחד בגרסאות ישנות יותר של Chrome ובמשתמשים בדפדפנים אחרים. חשוב לזכור שחלק מהמשתמשים לא מדווחים על מדדי ניווט רך, גם אם הם מדווחים על מדדי הליבה לבדיקת חוויית המשתמש באתר.
• זו תכונה ניסיונית חדשה שלא מופעלת כברירת מחדל, ולכן מומלץ לבדוק אותה באתרים כדי לוודא שאין לה תופעות לוואי לא רצויות.

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

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

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

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

מפתחים יכולים להפעיל את התכונה הזו על ידי הפעלת הדגל ב-chrome://flags/#soft-navigation-heuristics. האפשרות המומלצת היא 'הפעלת שיוך מתקדם של צביעה (Eager Cached Pre-Paint Walk)', והיא תהפוך בקרוב לברירת המחדל. אפשר גם להפעיל את התכונה באמצעות ארגומנטים של שורת הפקודה --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution כשמפעילים את Chrome.

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

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

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

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (nav>Entry) = 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

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

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

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

איך מודדים TTFB?

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

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

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

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

איך מודדים גם את הגרסה הישנה וגם את הגרסה החדשה?

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

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

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

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

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

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

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

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

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

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

משוב

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

• משוב על ה-API צריך להישלח כבעיות ב-GitHub.
• אם הבעיה לא מופיעה בבעיות הידועות, צריך לדווח עליה במעקב אחר בעיות ב-Chrome.
• אפשר לשתף משוב כללי על מדדים בסיסיים של חוויית המשתמש בכתובת [email protected].

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

יומן שינויים

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

סיכום

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

תודות

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

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