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

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

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

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

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

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

מידע נוסף

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