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

Barry Pollard

Michal Mocny

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

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

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

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

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

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

איך אפשר למדוד מעברים רכים?

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

סיכום

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

תודות

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

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