לשיפור מדד חלקות האנימציה

ניתן ללמוד על מדידת אנימציות, על מסגרות אנימציה ועל ההחלקה הכללית של הדף.

סביר להניח שנתקלתם בדפים עם "גמגם" או "להקפיא" במהלך הגלילה או אנימציות. אנחנו אומרים שחוויות השימוש האלה לא חלקות. לכתובת של סוגי הבעיות האלה, צוות Chrome פועל על הוספת תמיכה לכלים בשיעור ה-Lab שלנו לזיהוי אנימציה, ולשיפור קבוע לאבחון של צינור עיבוד הנתונים ב-Chromium.

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

הפוסט הזה יעסוק בשלושה נושאים עיקריים:

• הצצה מהירה באנימציות ובפריימים של אנימציה.
• המחשבות שלנו כרגע לגבי מדידת החלק היחסי של האנימציה.
• כמה הצעות פרקטיות שתוכלו ליישם בכלים של שיעור ה-Lab.

מהן אנימציות?

אנימציות מעוררות תוכן לחיים! על ידי העברת תוכן, במיוחד בתגובה לאינטראקציות של משתמשים, אנימציות יכולות להעניק חוויה להרגיש יותר טבעית, בצורה מובנת ומהנה.

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

איך פועלות אנימציות?

חזרה קצרה – צינור עיבוד הנתונים לעיבוד מורכב מכמה שלבים רציפים:

1. סגנון: מחשבים את סגנונות שחלים על הרכיבים.
2. פריסה: יוצרים את ואת המיקום של כל רכיב.
3. צבע: ממלאים את פיקסלים של כל רכיב בשכבות.
4. מורכב: משרטטים את ארבע שכבות שונות.

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

• שינוי הפריסה נכסים.
• שינוי של צבע נכסים.
• כוונון המורכב נכסים.

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

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

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

מהם מסגרות אנימציה?

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

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

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

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

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

מה משפיע על פריימים באנימציה?

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

מספר דוגמאות:

• שימוש בתוכן גדול מדי או בתוכן שדורש משאבים רבים מכדי לפענח במהירות מכשיר היעד.
• שימוש ביותר מדי שכבות נדרש יותר מדי זיכרון GPU.
• הגדרה של סגנונות CSS מורכבים או אנימציות אינטרנט.
• שימוש באנטי-תבניות שמשביתים אופטימיזציה של רינדור מהיר.
• יותר מדי JS פועלים ב-thread הראשי, מה שמוביל למשימות ארוכות שחוסמות רכיבים חזותיים

אבל איך אפשר לדעת מתי פריים של אנימציה פספס את המועד האחרון וגרם פריים נפגם?

אחת מהשיטות האפשריות היא requestAnimationFrame() אבל יש לו כמה חסרונות. requestAnimationFrame(), או "rAF", אומרת לדפדפן שאתם רוצים לבצע אנימציה ומבקשת לעשות זאת לפני שלב הציור הבא בצינור העיבוד. אם המיקום לא מתבצעת קריאה לפונקציית הקריאה החוזרת בזמן שציפיתם, צבע לא בוצע, ודילגת על פריים אחד או יותר. באמצעות סקרים ו אם סופרים את התדירות שבה קוראים ל-rAF, אפשר לחשב סוג של 'פריימים לשנייה'. (FPS).

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

לא מומלץ להשתמש בסקרים מסוג requestAnimationFrame() מכמה סיבות:

• כל סקריפט צריך להגדיר לולאת סקרים משלו.
• היא יכולה לחסום את הנתיב הקריטי.
• גם אם הדגימה ב-rAF מהירה, היא יכולה למנוע requestIdleCallback() מהיכולת לתזמן חסימות ארוכות ללא פעילות כאשר משתמשים בהן באופן רציף (חסימה חורג ממסגרת אחת).
• באופן דומה, היעדר חסימות ארוכות ללא פעילות מונעות מהדפדפן לתזמן משימות ממושכות (כמו איסוף אשפה ארוך יותר ורקע אחר, או עבודה ספקולטיבית).
• אם התכונה 'סקרים' מופעלת או מושבתת, אתם מפספסים מקרים שבהם תקציב הפריים אירעה חריגה.
• הסקרים ידווחו על תוצאות שגויות במקרים שבהם הדפדפן משתמש בתדירות עדכון משתנה (לדוגמה, בגלל סטטוס אספקת החשמל או החשיפה).
• והכי חשוב, הוא לא מתעד את כל סוגי האנימציה עדכונים!

עבודה רבה מדי על ה-thread הראשי עלולה להשפיע על היכולת לראות פריימים של אנימציה. כדאי לך לנסות את Jank דוגמה כדי לראות איך אנימציה שמבוססת על rAF, כשיש יותר מדי עבודה על ה-thread הראשי (למשל, פריסה), יובילו לירידה בפריימים, לפחות קריאות חוזרות ב-rAF ופחות FPS.

כשה-thread הראשי תקוע, העדכונים החזותיים מתחילים לפעול. זה ממש קשה!

כלי מדידה רבים התמקדו באופן נרחב ביכולת לבצע כדי להפיק בזמן הנכון וכדי שפריימים של אנימציה יפעלו בצורה חלקה. אבל זה לא כל הסיפור! עיינו בדוגמה הבאה:

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

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

זאת דוגמה שמכילה בו-זמנית הרבה פריימים שהושמטו אבל עדיין יש הרבה פריימים של גלילה שהועברו בהצלחה של קומפוזיטור. אחרי שהמשימה הארוכה מסתיימת, עדכון הצבע של ה-thread הראשי אין שינוי חזותי להציע בכל מקרה. סקרי rAF ציעו ירידה בפריים ל-0, אבל באופן חזותי, המשתמש לא יבחינו בהבדל!

כשמדובר בפריימים של אנימציה, הסיפור לא פשוט כל כך.

פריימים של אנימציה: עדכונים חשובים

הדוגמה שלמעלה ממחישה שהסיפור כולל פרטים נוספים מלבד requestAnimationFrame()

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

• עדכוני שרשור ראשי ומחבר
• חסרים עדכונים של צבע
• זיהוי אנימציות
• איכות לעומת כמות

עדכוני שרשור ראשי ומחבר

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

הדוגמה הנפוצה ביותר לכך היא כשהדפדפן לא מצליח להפיק עדכון של ה-thread הראשי עד למועד האחרון של המסגרת אבל יש בו שרשור חדש של יוצר (למשל, הדוגמה הקודמת לגלילה בשרשור).

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

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

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

חסרים עדכונים של צבע

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

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

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

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

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

אז מתי חשוב לתפוקת הפריים?

זיהוי אנימציות

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

יש סוגים של אנימציות שקל יותר להגדיר ולזהות אותן. קל יותר להגדיר אנימציות הצהרות או אנימציות המונעות על ידי המשתמש מאשר אנימציות מבוססות JavaScript שהוטמעו כעדכונים תקופתיים של של מאפייני סגנון.

גם עם requestAnimationFrame() לא תמיד יכול להניח שכל קריאה ל-rAF יוצרת בהכרח תצוגה או לעדכן אנימציה. לדוגמה, שימוש בסקרים מסוג rAF רק כדי לעקוב אחרי קצב הפריימים (כפי שמתואר למעלה) לא אמורה להשפיע על מדידת החלקות, אין עדכון חזותי.

איכות לעומת כמות

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

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

או משחק שמשתמש ב-<canvas> (אולי אפילו משתמש בטכניקות כמו מחוץ למסך קנבס להבטיח קצב פריימים יציב) עשויה להיות חלקה מבחינה טכנית פריימים של אנימציה, ובמקביל לא טוענים נכסי משחק באיכות גבוהה או הצגת ארטיפקטים של רינדור.

כמובן, אתר יכול להכיל אנימציות ממש גרועות 🙂

כלומר, הם היו די מגניבים בזמנם!

מצבים של מסגרת אנימציה יחידה

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

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

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

סיכום של הכול: מדד 'אחוז פריימים שנטשו'

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

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

המודל המנטלי צריך לעבור מ:

1. FPS, עד
2. זיהוי עדכוני אנימציה חסרים וחשובים, כדי
3. אחוז הירידה בתקופה נתונה.

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

• אחוז ממוצע של ירידה: לכל מסגרות האנימציה הלא פעילות במהלך כל ציר הזמן
• המקרה הגרוע ביותר של שיעור פריימים שנשלפו: כפי שנמדד במהלך שנייה אחת של החלקה חלונות זמן.
• האחוזון ה-95 של אחוזי הפריימים שהושמטו: לפי מדידה של יותר משנייה חלונות זמן נעים.

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

כדאי לנסות את הכלים למפתחים

HUD ביצועים

ב-Chromium יש HUD מדויק של ביצועים שמסתתר מאחורי דגל (chrome://flags/#show-performance-metrics-hud). אפשר למצוא שם גם שידורים חיים ציונים בתכונות כמו Core Web Vitals וגם כמה הגדרות ניסיוניות. להחלקה של אנימציה על סמך אחוז פריימים ששחררו לאורך זמן.

נתונים סטטיסטיים של רינדור פריימים

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

צפייה בפריימים בהקלטות של פרופיל הביצועים של כלי הפיתוח

הביצועים של כלי הפיתוח בחלונית יש כבר היו מסגרות Viewer. עם זאת, הוא יצא פחות מסונכרן עם האופן שבו צינור עיבוד הנתונים המודרני עובד בפועל. יש שיפור רב מהזמן האחרון, גם Chrome Canary, שלדעתנו יקל משמעותית על בעיות בניפוי באגים באנימציה.

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

מעקב ב-Chrome

לבסוף, בעזרת Chrome Tracing, הכלי המועדף עליכם להתעמק בפרטים אל הפרטים אפשר להקליט 'רינדור תוכן באינטרנט' לעקוב דרך Perfetto החדש ממשק משתמש (או about:tracing), והעמקה לצינור עיבוד נתונים גרפי. זאת יכולה להיות משימה מרתיעה, אבל יש כמה דברים נוסף לאחרונה ל-Chromium כדי שיהיה קל יותר. אפשר לקבל סקירה כללית של זמין בחייו של מסגרת מהמסמך.

באמצעות אירועי מעקב אפשר לקבוע באופן סופי:

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

המאמרים הבאים

המטרה של יוזמת Web Vitals היא לספק מדדים והנחיות לגבי לבניית חוויות משתמש מעולות באינטרנט. מדדים מבוססי Lab, כמו Total זמן החסימה (TBT) הוא חיוני זיהוי ואבחון בעיות אינטראקטיביות אפשריות. אנחנו מתכננים תכננו מדד דומה מבוסס-מעבדה לגבי רמת החלקה של אנימציה.

נעדכן אתכם כשנמשיך לעבוד על רעיונות לעיצוב מדד מקיף שמבוסס על נתוני פריימים של אנימציה בודדת.

בעתיד, נרצה גם לעצב ממשקי API שיאפשרו למדוד החלקה באנימציה עם ביצועים טובים למשתמשים אמיתיים וגם בשיעור ה-Lab. בקרוב יהיו עדכונים גם שם!

משוב

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

אפשר לשלוח את התגובות אל web-vitals-feedback Google קבוצה עם "[Smoothness Metrics]" בשורת הנושא. אנחנו ממש מחפשים נשמח לשמוע מה דעתך.