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

Barry Pollard

Yoav Weiss

עדכון מאוגוסט 2024: הטראיל השני של גרסת המקור של Soft Navigations הסתיים ב-29 במאי. צוות Chrome משקיע זמן כדי לבדוק את המשוב מהניסוי ולשקול את השלבים הבאים לגבי ה-API הזה. אנחנו רוצים לטפל בכמה בעיות דיוק ואנחנו מאמינים שיידרש מקור ניסיון נוסף לפני שהתכונה תהיה מוכנה להתקדמות. בינתיים, המפתחים עדיין יכולים להתנסות בתכונה על ידי הפעלה של chrome://flags/#enable-experimental-web-platform-features.

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

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

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

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

מהי ניווט רך?

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

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

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

איך Chrome מטמיע ניווט רך?

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

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

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

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

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

• יכול להיות שאירועי FP, FCP ו-LCP נוספים יישלחו מחדש עבור ניווטים קלים. דוח חוויית המשתמש ב-Chrome (CrUX) יתעלם מהערכים הנוספים האלה, אבל הדבר עשוי להשפיע על כל מעקב אחר מדידות משתמשים (RUM) באתר שלך. אם יש לכם חששות לגבי ההשפעה של השינוי הזה על המדידות האלה, כדאי לפנות לספק ה-RUM. בקטע בנושא מדידת מדדי הליבה לבדיקת חוויית המשתמש (Core Web Vitals) לניווטים חלקים
• יכול להיות שתצטרכו להביא בחשבון את המאפיין החדש (והאופציונלי) navigationID ברשומות הביצועים שלכם בקוד האפליקציה באמצעות הרשומות האלה.
• רק דפדפנים המבוססים על Chromium יתמכו במצב החדש הזה. רבים מהמדדים החדשים זמינים רק בדפדפנים מבוססי Chromium, אבל חלקם (FCP ו-LCP) זמינים בדפדפנים האחרים, ויכול להיות שלא כולם שדרגו לגרסה האחרונה של הדפדפנים מבוססי Chromium. לכן, חשוב לזכור שחלק מהמשתמשים לא ידווחו על מדדי ניווט רך.
• זוהי תכונה חדשה וניסיונית שלא מופעלת כברירת מחדל, ולכן בעלי אתרים צריכים לבדוק אותה כדי לוודא שאין לה השפעות לוואי לא רצויות.

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

איך מפעילים ניווט רך ב-Chrome?

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

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

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

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

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

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

אפשר להשתמש ב-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), ביחס לזמן הניווט הרך הזה.

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

כדי לכלול רשומות של מדדי ניווט רך, צריך לכלול את includeSoftNavigationObservations: true בקריאה observe של צופה הביצועים.

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

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

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

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

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

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

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

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

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

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

איך מודדים את טופס ה-TTDFB?

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

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

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

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

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

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

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

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

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

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

אזהרה: ההטמעה של web-vitals נמצאת בפיתוח פעיל ועשויה להשתנות בעקבות פרסום של שינויים חדשים בהסתעפות הזו. אין תמיכה ב-FCP בניווט רך, כי לשם כך נדרשת עבודה נוספת ב-Chrome. משתמשים בספריית JavaScript‏ web-vitals צריכים להיות מודעים לכך אם הם רוצים להשתמש בספרייה הזו באתרי ייצור. הם צריכים ליצור עותק מקומי ולבדוק את הגרסה הזו, ולעקוב אחרי השינויים בהסתעפות.

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

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

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

איך יתבצע הדיווח על ניווטים רכים ב-CrUX?

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

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

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

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

משוב

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

• השיטות היעילות לניווט רך והסטנדרטיזציה שלהן.
• בעיות בהטמעה של Chrome של שיטות הניתוח האלה.
• משוב כללי על מדדי הליבה לבדיקת חוויית המשתמש באתר (Core Web Vitals) בכתובת [e-mail].

יומן שינויים

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

סיכום

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

תודות

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