נדרש משוב מהמפתח – frame Timing API

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

עם זאת, אצל רובנו יש פער בין מה שאנחנו יכולים לבדוק באופן סביר במכשירים שלנו לבין מה שהמשתמשים שלנו חווים. אם הם לא יקבלו 60fps חלקים, החוויה שלהם תיפגע ובסופו של דבר הם יעברו לאתר אחר ואנחנו נסבול. לכן, טוב ש-W3C דנה ב-API חדש שיכול לעזור לנו לראות מה המשתמשים שלנו רואים: Frame Timing API.

לאחרונה הקלטתי עם Jake Archibald סקירה כללית בווידאו על ה-API. אם אתם מעדיפים לצפות במקום לקרוא, כדאי לכם לצפות בסרטון:

שימושים ב-Frame Timing API

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

  • מעקב אחר מספר הפריימים לשנייה (fps) של אנימציות ה-JavaScript וה-CSS.
  • מעקב אחר חלקות הגלילה בדף (או אולי אחרי הרשימה הנחמדה עם הגלילה האינסופית).
  • התאמה אוטומטית של האפקטים של 'בידור' בהתאם לעומס הנוכחי במכשיר.
  • בדיקת רגרסיה של מדדי הביצועים בסביבת זמן הריצה.

נאום המעלית

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

var rendererEvents = window.performance.getEntriesByType("renderer");

כל אחת מהרשומות של שרשורי ה-renderer שתקבלו נראית בערך כך:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

כל רשומה היא למעשה אובייקט שמכיל מספר פריים ייחודי, חותמת זמן ברזולוציה גבוהה של מועד תחילת הפריים, ועוד אחת של משך הזמן שהפריים השתמש בו ב-CPU. בעזרת מערך של ערכים כאלה, אפשר לבדוק כל אחד מערכי startTime ולגלות אם החוט הראשי פועל במהירות 60fps. בעיקרון, "האם הערך של startTime בכל פריים עולה בקטעים של כ-16ms?"

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

בנוסף לשרשור של המרינר, אפשר גם למשוך נתונים לגבי תזמון של שרשור המאגר, שבו מתרחשים הציור והשילוב:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

כל אחד מהאירועים האלה מגיע עם מספר של מסגרת מקור, שאפשר להשתמש בו כדי לקשר אותו לאירועים של השרשור הראשי:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

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

מידע נוסף

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