אפליקציות Progressive Web Apps מאפשרות למפתחים ליצור סוג חדש של אפליקציות שמספקות חוויית משתמש מהימנה עם ביצועים גבוהים. עם זאת, כדי לוודא שאפליקציית אינטרנט עומדת ביעדי הביצועים הרצויים, למפתחים צריכה להיות גישה לנתוני מדידת ביצועים ברזולוציה גבוהה. מפרט ציר הזמן של ביצועים של W3C מגדיר ממשק כזה לדפדפנים כדי לספק גישה פרוגרמטית לנתוני תזמון ברמה נמוכה. כך אפשר ליצור תרחישים מעניינים לדוגמה:
- ניתוח ביצועים אופליין ומותאמים אישית
- כלים של צד שלישי לניתוח ביצועים ולתצוגה חזותית
- הערכת ביצועים שמשולבת בסביבות פיתוח משולבות (IDE) ובכלים אחרים למפתחים
הגישה לנתוני תזמון מהסוג הזה כבר זמינה ברוב הדפדפנים העיקריים לתזמון ניווט, לתזמון משאבים ולתזמון משתמשים. התוספת החדשה ביותר היא ממשק performance observer, שהוא למעשה ממשק סטרימינג לאיסוף נתוני תזמון ברמה נמוכה באופן אסינכרוני, כפי שהם נאספים על ידי הדפדפן. לממשק החדש יש כמה יתרונות קריטיים על פני השיטות הקודמות לגישה לציר הזמן:
- כיום, האפליקציות צריכות לבצע מדי פעם סקרים ולבדוק את ההבדלים בין המדידות השמורות, וזה תהליך יקר. הממשק הזה מציע להם קריאה חוזרת. (כלומר, אין צורך בסקרים). כתוצאה מכך, אפליקציות שמשתמשות ב-API הזה יכולות להיות מהירות יותר ויעילות יותר.
- הוא לא כפוף למגבלות של מאגרים (רוב המאגרים מוגדרים ל-150 פריטים כברירת מחדל), ומאפשר למנוע תנאי מרוץ בין צרכנים שונים שרוצים לשנות את המאגר.
- ההתראות של משקיף הביצועים מועברות באופן אסינכרוני, והדפדפן יכול לשלוח אותן במהלך זמן השהיה כדי להימנע מתחרות עם משימות רינדור קריטיות.
החל מגרסה 52 של Chrome, ממשק מעקב הביצועים מופעל כברירת מחדל. עכשיו נראה איך משתמשים בו.
<html>
<head>
<script>
var observer = new PerformanceObserver(list => {
list.getEntries().forEach(entry => {
// Display each reported measurement on console
if (console) {
console.log("Name: " + entry.name +
", Type: " + entry.entryType +
", Start: " + entry.startTime +
", Duration: " + entry.duration + "\n");
}
})
});
observer.observe({entryTypes: ['resource', 'mark', 'measure']});
performance.mark('registered-observer');
function clicked(elem) {
performance.measure('button clicked');
}
</script>
</head>
<body>
<button onclick="clicked(this)">Measure</button>
</body>
</html>
הדף הפשוט הזה מתחיל בתג סקריפט שמגדיר קוד JavaScript:
- יוצרים אובייקט
PerformanceObserverחדש ומעבירים פונקציית טיפול באירועים ל-constructor של האובייקט. ה-constructor מאתחלל את האובייקט כך שהמתנהל שלנו יקרא לו בכל פעם שקבוצה חדשה של נתוני מדידה תהיה מוכנה לעיבוד (נתוני המדידה יועברו כרשימה של אובייקטים). ה-handler מוגדר כאן כפונקציה אנונימית שפשוט מציגה את נתוני המדידה בפורמט במסוף. בתרחיש בעולם האמיתי, יכול להיות שהנתונים האלה יישמרו בענן לצורך ניתוח נוסף, או יועברו לכלי אינטראקטיבי להצגת נתונים. - אנחנו נרשמים לסוגי אירועי הזמן שאנחנו מעוניינים בהם באמצעות השיטה
observe(), ומפעילים את השיטהmark()כדי לסמן את הרגע שבו נרשמנו, שנחשב לתחילת מרווחי הזמן שלנו. - אנחנו מגדירים טיפול בקליק עבור לחצן שהוגדר בגוף הדף. פונקציית הטיפול בקליק הזו קוראת ל-method
measure()כדי לתעד נתוני תזמון לגבי מועד הלחיצה על הלחצן.
בגוף הדף, מגדירים לחצן, מקצים את פונקציית הטיפול בקליק לאירוע onclick ומוכנים לפעולה.
עכשיו, אם נטען את הדף ונפתח את הלוח של כלי הפיתוח ל-Chrome כדי לצפות במסוף JavaScript, בכל פעם שנלחץ על הלחצן תתבצע מדידת ביצועים. וכיוון שנרשמנו למעקב אחרי מדידות כאלה, הן מועברות למטפל האירועים שלנו באופן אסינכרוני, בלי צורך לבצע סקירה של ציר הזמן, שמציג את המדידות במסוף בזמן שהן מתרחשות:
הערך start מייצג את חותמת הזמן ההתחלתית של אירועים מסוג mark (לאפליקציה הזו יש רק אירוע אחד כזה). לאירועים מסוג measure אין שעת התחלה מובנית. הם מייצגים מדידות של תזמון שנלקחו ביחס לאירוע mark האחרון. לכן, ערכי משך הזמן שמוצגים כאן מייצגים את הזמן שחלף בין הקריאה ל-mark(), שמשמשת כנקודת התחלה של מרווח משותף, לכמה קריאות עוקבות ל-measure().
כפי שאפשר לראות, ממשק ה-API הזה פשוט למדי ומאפשר לאסוף נתוני ביצועים מסוננים ברזולוציה גבוהה בזמן אמת, בלי סקרים. כך אפשר יהיה לפתח כלים יעילים יותר למדידת ביצועים של אפליקציות אינטרנט.