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

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 בשיטה 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 שונה.

איך מודדים את זמן אחזור הבקשה (TTFB)?

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

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

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

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

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

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

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

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

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

מדד	פרטים
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