מידע על מדידת אנימציות, על האופן שבו צריך לחשוב על פריימים של אנימציה ועל חלקות הדף באופן כללי.
בטח נתקלתם בדפים שהיו 'רעשים' או 'הקפיאו' במהלך גלילה או אנימציות. אנחנו אוהבים לומר שהחוויות האלה לא חלקות. כדי לטפל בבעיות מהסוג הזה, צוות Chrome עבד על הוספת תמיכה נוספת לכלים שלנו ב-Lab לזיהוי אנימציות, וגם על שיפורים מתמשכים באבחון צינור עיבוד הנתונים לעיבוד ב-Chromium.
אנחנו רוצים לשתף איתכם כמה מההתקדמות האחרונה, להציע הנחיות קונקרטיות לשימוש בכלים ולדון ברעיונות למדדים עתידיים של חלקות האנימציה. כמו תמיד, נשמח לקבל ממך משוב.
בפוסט הזה נדון בשלושה נושאים עיקריים:
- סקירה מהירה על אנימציות ועל פריימים של אנימציות.
- מה אנחנו חושבים כרגע לגבי מדידת רמת החלקות הכוללת של האנימציה.
- כמה הצעות מעשיות שתוכלו להשתמש בהן בכלים של המעבדה כבר היום.
מהן אנימציות?
אנימציות מעוררות את התוכן לחיים! אנימציות יכולות להפוך את החוויה ליותר טבעית, מובנת ומהנה, במיוחד בתגובה לאינטראקציות של המשתמשים.
עם זאת, אנימציות שהווטמעו בצורה לא טובה או הוספה של יותר מדי אנימציות עלולות לפגוע בחוויה ולהפוך אותה ללא מהנה בכלל. סביר להניח שכולנו נתקלים בממשקים עם יותר מדי אפקטים 'מועילים' של מעבר, שהופכים לחוויה שלילית כשהם פועלים בצורה לא טובה. לכן, יכול להיות שחלק מהמשתמשים מעדיפים תנועה מופחתת, וזו העדפה של משתמשים שצריך לכבד.
איך עבודות האנימציה פועלות?
לסיכום, צינור עיבוד הנתונים לעיבוד מורכב מכמה שלבים ברצף:
- סגנון: חישוב הסגנונות שחלים על הרכיבים.
- פריסה: יצירת הגיאומטריה והמיקום של כל רכיב.
- צביעה: מילוי הפיקסלים של כל רכיב בשכבות.
- שילוב: ציור השכבות במסך.
יש הרבה דרכים להגדיר אנימציות, אבל כולן פועלות בעיקרון באמצעות אחת מהשיטות הבאות:
- שינוי המאפיינים של פריסת המודעות.
- שינוי המאפיינים של paint.
- שינוי מאפיינים מורכבים.
השלבים האלה הם ברצף, ולכן חשוב להגדיר את האנימציות לפי מאפיינים שנמצאים בהמשך צינור עיבוד הנתונים. ככל שהעדכון מתבצע מוקדם יותר בתהליך, כך העלויות גבוהות יותר והסיכוי שהתהליך יהיה חלק קטן יותר. (פרטים נוספים זמינים במאמר ביצועי עיבוד).
אמנם קל להוסיף אנימציה לנכסי פריסה, אבל יש לכך עלויות, גם אם הן לא גלויות באופן מיידי. כשהדבר אפשרי, מומלץ להגדיר אנימציות לפי שינויים בנכסים מורכבים.
הגדרת אנימציות CSS מוצהר או שימוש באנימציות אינטרנט, ולוודא שמפעילים אנימציה במאפיינים מורכבים, הם שלבים ראשונים מצוינים להבטחת אנימציות חלקות ויעילות. עם זאת, גם אם תשתמשו באנימציות יעילות לא תהיה לכם ודאות שהן יפעלו בצורה חלקה, כי גם לאנימציות אינטרנט יעילות יש מגבלות ביצועים. לכן תמיד חשוב למדוד!
מהם פריים אנימציה?
עדכונים בפריסה החזותית של דף מסוים מופיעים לאחר זמן מה. שינוי חזותי יוביל ליצירת פריים חדש של אנימציה, שיומר בסופו של דבר במסך של המשתמש.
העדכון מוצג במרווח זמן מסוים, כך שהעדכונים החזותיים מקובצים. מסכים רבים מתעדכנים במרווח זמן קבוע, למשל 60 פעמים בשנייה (כלומר 60Hz). חלק מהמסכים המודרניים יותר יכולים להציע קצב רענון גבוה יותר (90-120Hz נעשים נפוצים יותר). לרוב, התצוגות האלה יכולות להתאים באופן פעיל בין שיעורי רענון לפי הצורך, או אפילו להציע שיעורי פריימים משתנים לחלוטין.
המטרה של כל אפליקציה, כמו משחק או דפדפן, היא לעבד את כל העדכונים החזותיים האלה בקבוצות וליצור בכל פעם פריים אנימציה מלא מבחינה חזותית עד למועד היעד. חשוב לציין שהמטרה הזו שונה לחלוטין ממשימות חשובות אחרות בדפדפן, כמו טעינת תוכן מהרשת במהירות או ביצוע משימות JavaScript ביעילות.
בשלב מסוים, יכול להיות שיהיה קשה מדי להשלים את כל העדכונים החזותיים עד למועד היעד שהוקצה על ידי המסך. במקרה כזה, הדפדפן משמיט פריים. המסך לא נכבה, הוא פשוט חוזר על עצמו. אותו עדכון חזותי יוצג למשך זמן ארוך יותר – אותו פריים של האנימציה שהוצג בהזדמנות הקודמת להצגת פריים.
זה קורה לעיתים קרובות! הוא לא בהכרח מורגש, במיוחד בתוכן סטטי או תוכן שנראה כמו מסמך, שהוא נפוץ במיוחד בפלטפורמת האינטרנט. הפסקות בפריימים נראות רק כשיש עדכונים חזותיים חשובים, כמו אנימציות, שעבורם אנחנו זקוקים למקור יציב של עדכוני אנימציה כדי להציג תנועה חלקה.
מה משפיע על פריטי האנימציה?
למפתחי אתרים יש השפעה רבה על היכולת של דפדפן לעבד ולציג עדכונים חזותיים במהירות וביעילות.
מספר דוגמאות:
- שימוש בתוכן גדול מדי או תוכן שדורש הרבה משאבים כדי לפענח אותו במהירות במכשיר היעד.
- שימוש ביותר מדי שכבות שדורשות יותר מדי זיכרון GPU.
- הגדרת סגנונות CSS או אנימציות אינטרנט מורכבים מדי.
- שימוש בתכנים שאינם מומלצים בעיצוב, שמשביתים אופטימיזציות של עיבוד מהיר.
- יותר מדי עבודה ב-JS בשרשור הראשי, מה שמוביל למשימות ארוכות שגורמות לחסימה של עדכונים חזותיים.
אבל איך אפשר לדעת מתי פריים של אנימציה לא עמד בלוח הזמנים שלו וגרם לפריים שהושמט?
אחת מהשיטות האפשריות היא שימוש בסקרים של requestAnimationFrame(), אבל יש לכך כמה חסרונות. requestAnimationFrame(), או 'rAF', מעדכנת את הדפדפן שרוצים לבצע אנימציה ומבקשת הזדמנות לעשות זאת לפני שלב הציור הבא בצינור עיבוד הנתונים לעיבוד. אם פונקציית ה-callback לא נקראת בזמן שאתם מצפים, סימן שלא בוצע ציור והושטו פריים אחד או יותר. באמצעות סקרים וספירה של מספר הפעמים שבהן נקרא 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 הראשי עלול להשפיע על היכולת לראות פריימים של אנימציה. כדאי לעיין בדוגמה לתנודות בפריימים כדי לראות איך אנימציה שמבוססת על rAF, כשיש יותר מדי עבודה ב-thread הראשי (למשל פריסה), תוביל לפריימים חסרים, לפחות קריאות חוזרות ל-rAF ול-FPS נמוך יותר.
כשהשרשור הראשי נתקע, העדכונים החזותיים מתחילים להאט. זה לא טוב.
כלים רבים למדידת ביצועים התמקדו במידה רבה ביכולת של הליבה להניב תוצאות בזמן, וביכולת של מסגרות האנימציה לפעול בצורה חלקה. אבל זה לא כל הסיפור! דוגמה:
בסרטון שלמעלה מוצג דף שמוסיף מדי פעם משימות ארוכות לשרשור הראשי. המשימות הארוכות האלה משבשות לחלוטין את היכולת של הדף לספק סוגים מסוימים של עדכונים חזותיים, וניתן לראות בפינה הימנית העליונה ירידה תואמת של requestAnimationFrame() דיווחים על FPS ל-0.
עם זאת, למרות המשימות הארוכות האלה, הדף ממשיך לגלול בצורה חלקה. הסיבה לכך היא שבדפדפנים מודרניים, הגלילה מתבצעת לעיתים קרובות בשרשור, ומנוהלת באופן מלא על ידי המאגר.
זו דוגמה שמכילה בו-זמנית הרבה פריימים שנשמטו בשרשור הראשי, אבל עדיין יש בה הרבה פריימים של גלילה שהועברו בהצלחה בשרשור המאגר. אחרי שהמשימה הארוכה מסתיימת, עדכון הציור של הליבה לא מציע שינוי חזותי. הסקרים של rAF הצביעו על ירידה של 0 בפריימים, אבל חזותית, המשתמש לא יוכל להבחין בהבדל.
כשמדובר בפריימים של אנימציה, הסיפור לא פשוט כל כך.
פריימים של אנימציה: עדכונים שחשוב לדעת
הדוגמה שלמעלה מראה שיש עוד דברים שחשוב לדעת מלבד requestAnimationFrame().
אז מתי עדכוני אנימציה ופריימים של אנימציה חשובים? ריכזנו כאן כמה קריטריונים שאנחנו שוקלים, ונשמח לקבל מכם משוב:
- עדכונים של ה-thread הראשי ושל ה-compositor
- חסרים עדכוני צבע
- זיהוי אנימציות
- איכות לעומת כמות
עדכונים של ה-thread הראשי ושל ה-compositor
עדכונים של פריימים באנימציה הם לא בוליאניים. לא תמיד אפשר להסיר פריימים לחלוטין או להציג אותם במלואם. יש הרבה סיבות לכך שפריים של אנימציה מוצג חלקית. במילים אחרות, יכול להיות שחלק מהתוכן לא עדכני, אבל יש בו גם עדכונים חזותיים חדשים.
הדוגמה הנפוצה ביותר לכך היא מצב שבו הדפדפן לא מצליח ליצור עדכון חדש של הליבה בתוך מועד ההגשה של המסגרת, אבל יש לו עדכון חדש של הליבה של המאגר (כמו הדוגמה של גלילה בשרשור שצוינה קודם).
אחת מהסיבות החשובות לשימוש באנימציות מוצגות כדי ליצור אנימציה של מאפיינים מורכבים היא שכך אפשר להפעיל את האנימציה באופן מלא על ידי חוט המאגר, גם כשהחוט הראשי עסוק. סוגים כאלה של אנימציות יכולים להמשיך ליצור עדכונים חזותיים ביעילות ובמקביל.
לעומת זאת, יכול להיות מצב שבו עדכון של חוט ראשי יהיה סוף סוף זמין להצגה, אבל רק אחרי שהוחמצו כמה מועדים להגשת מסגרות. בדפדפן יהיה עדכון חדש, אבל יכול להיות שהוא לא יהיה העדכון העדכני ביותר.
באופן כללי, אנחנו מתייחסים לפריימים שמכילים חלק מהעדכונים החזותיים החדשים, בלי כל העדכונים החזותיים החדשים, כפריים חלקי. פריימים חלקיים הם תופעה די נפוצה. באופן אידיאלי, עדכונים חלקיים אמורים לכלול לפחות את העדכונים החזותיים החשובים ביותר, כמו אנימציות, אבל זה יכול לקרות רק אם האנימציות מופעלות על ידי חוט המאגר.
חסרים עדכוני צבע
סוג אחר של עדכון חלקי הוא כשמדיה כמו תמונות לא מסתיימת פענוח ויצירת רסטר בזמן להצגת המסגרת.
לחלופין, גם אם הדף סטטי לחלוטין, יכול להיות שהדפדפנים עדיין לא יספיקו להציג את העדכונים החזותיים במהלך גלילה מהירה. הסיבה לכך היא שיכול להיות שהפירושים של הפיקסלים של התוכן מעבר לאזור התצוגה הגלוי יידחו כדי לחסוך בזיכרון ה-GPU. עיבוד הפיקסלים נמשך זמן מה, ויכול להיות שיחלפו יותר מסגרת אחת עד שכל התמונה תעובד אחרי גלילה גדולה, כמו תנועת אצבע מהירה. המצב הזה נקרא בדרך כלל תצוגת ריבועים.
בכל הזדמנות לעיבוד של פריים, אפשר לעקוב אחרי החלק של העדכונים החזותיים האחרונים שהגיע למסך. המדד של היכולת לעשות זאת במסגרת הרבה פריימים (או לאורך זמן) נקרא תפוקת פריימים.
אם המעבד הגרפי (GPU) יעסוק בדברים אחרים, יכול להיות שהדפדפן (או הפלטפורמה) יתחילו לצמצם את הקצב שבו הם מנסים לבצע עדכונים חזותיים, וכך יקטינו את שיעורי הפריימים בפועל. מבחינה טכנית, הפעולה הזו יכולה לצמצם את מספר העדכונים של הפריימים שהמערכת משאירה על הקרקע, אבל מבחינה חזותית עדיין תהיה ירידה בנפח התעבורה של הפריימים.
עם זאת, לא כל סוגי הקצב הנמוך של העברת הפריימים הם שליליים. אם הדף לא פעיל ברוב הזמן ואין בו אנימציות פעילות, קצב פריימים נמוך מושך ויזואלית באותה מידה כמו קצב פריימים גבוה (ויכול לחסוך בסוללה!).
מתי חשובה תפוקת הפריימים?
זיהוי אנימציות
תפוקה גבוהה של פריימים חשובה במיוחד בזמנים שבהם יש אנימציות חשובות. סוגי אנימציה שונים תלויים בעדכונים חזותיים משרשור ספציפי (ראשי, עיבוד או עובד), כך שהעדכון החזותי שלו תלוי בכך שהשרשור הזה יספק את העדכון שלו עד למועד היעד. אנחנו אומרים ששרשור מסוים משפיע על רמת החלקות בכל פעם שיש אנימציה פעילה שמבוססת על העדכון של אותו שרשור.
קל יותר להגדיר ולזהות סוגים מסוימים של אנימציות בהשוואה לסוגים אחרים. קל יותר להגדיר אנימציות מוצהרניות, או אנימציות שמבוססות על קלט מהמשתמש, מאשר אנימציות שמבוססות על JavaScript ומוטמעות כעדכונים תקופתיים למאפייני סגנון שניתן להפעיל בהם אנימציה.
גם עם requestAnimationFrame() אי אפשר תמיד להניח שכל קריאה ל-rAF יוצרת בהכרח עדכון חזותי או אנימציה. לדוגמה, שימוש בסקרים של rAF רק כדי לעקוב אחרי קצב הפריימים (כפי שמוצג למעלה) לא אמור להשפיע על מדידות החלקות, כי אין עדכון חזותי.
איכות לעומת כמות
לבסוף, זיהוי אנימציות ועדכוני פריימים של אנימציות הוא רק חלק מהסיפור, כי הוא מתעד רק את כמות העדכונים של האנימציה, ולא את האיכות שלה.
לדוגמה, יכול להיות שתראו קצב פריימים יציב של 60 fps בזמן הצפייה בסרטון. מבחינה טכנית, זהו נתון חלק לגמרי, אבל יכול להיות ששיעור הביטים של הסרטון עצמו נמוך או שיש בעיות באגירת נתונים ברשת. המדדים של חלקות האנימציה לא מתעדים את הבעיה הזו באופן ישיר, אבל היא עדיין עלולה להפריע למשתמש.
לחלופין, משחק שמשתמש ב-<canvas> (אולי אפילו באמצעות שיטות כמו offscreen canvas כדי להבטיח קצב פריימים יציב) עשוי להיות טכנית חלק לגמרי מבחינת פריימים של אנימציה, אבל לא מצליח לטעון נכסי משחק באיכות גבוהה לסצנה או מציג פגמים ברינדור.
וכמובן, יכול להיות שפשוט יש באתר אנימציות גרועות מאוד 🙂
אני מניח שהם היו די מגניבים בזמנו!
מצבים של מסגרת אנימציה אחת
מכיוון שפריימים עשויים להופיע באופן חלקי, או שפריימים עשויים להישמט בדרכים שלא משפיעות על רמת החלקות, התחלנו להתייחס לכל פריים כפריים שיש לו ציון של שלמות או של חלקות.
לפניכם הספקטרום של הדרכים שבהן אנחנו מפרשים את המצב של פריים בודד של אנימציה, בסדר מהמקרה הטוב ביותר למקרה הגרוע ביותר:
| No Update Desired | זמן חוסר פעילות, חזרה על הפריים הקודם. |
| הצגה מלאה | העדכון של השרשור הראשי בוצע עד למועד היעד, או שלא היה צורך בעדכון של השרשור הראשי. |
| מוצגת באופן חלקי | ב-Compositor בלבד. העדכון המאוחר של הליבה הראשית לא גרם לשינוי חזותי. |
| מוצגת באופן חלקי | Compositor בלבד. לשרשור הראשי היה עדכון חזותי, אבל העדכון הזה לא כלל אנימציה שמשפיעה על רמת החלקות. |
| מוצגת באופן חלקי | ב-Compositor בלבד: בשרשור הראשי בוצע עדכון חזותי שמשפיע על החלקות התמונה, אבל הגיע פריים לא עדכני והוא שימש במקום זאת. |
| מוצגת באופן חלקי | Compositor בלבד, ללא העדכון הראשי הרצוי, ובעדכון של Compositor יש אנימציה שמשפיעה על רמת החלקות. |
| מוצגת באופן חלקי | רק למעבד הווידאו, אבל לעדכון של מעבד הווידאו אין אנימציה שמשפיעה על רמת החלקות. |
| מסגרת חסרה | אין עדכון. לא היה צורך בעדכון הקומפוזבילי, והעדכון הראשי התעכב. |
| מסגרת חסרה | רצינו לעדכן את המאגר של ה-Compositor, אבל העדכון התעכב. |
| פריים לא עדכני | היה צורך בעדכון, הוא נוצר על ידי המרתח, אבל ה-GPU עדיין לא הציג אותו לפני מועד היעד של vsync. |
אפשר להפוך את המצבים האלה לסוג של ציון. אפשר גם להתייחס לדירוג הזה כסבירות לכך שהמשתמש יוכל לראות אותו. יכול להיות שלא תבחינו בפריים אחד שהושמט, אבל רצף של הרבה פריימים שהושמטו שמשפיע על רמת החלקות ברצף בהחלט יזוהה.
סיכום כל המידע: מדד 'אחוז הפריימים שהוחמצו'
לפעמים צריך להיכנס לעומק של המצב של כל פריים באנימציה, אבל כדאי גם להקצות פשוט ציון מהיר 'בקצרה' לחוויה.
מכיוון שפריימים עשויים להיות מוצגים באופן חלקי, וגם כי עדכוני פריימים שהושמטו לגמרי עשויים לא להשפיע על רמת החלקות, אנחנו רוצים להתמקד פחות בספירת הפריימים ויותר במידת חוסר היכולת של הדפדפן לספק עדכונים חזותיים מלאים כשזה חשוב.
המודל המנטלי צריך לעבור מהשלבים הבאים:
- פריימים לשנייה, עד
- זיהוי עדכוני אנימציה חסרים וחשובים, כדי
- Percentage Dropped (אחוז ההפלות) בתקופה נתונה.
מה שחשוב הוא החלק היחסי של הזמן שבו אתם ממתינים לעדכונים חשובים. לדעתנו, הדרך הזו תואמת לאופן הטבעי שבו המשתמשים חווים את חלקות התוכן באינטרנט בפועל. עד כה, השתמשנו במדדים הבאים כקבוצה ראשונית של מדדים:
- אחוז הניתוחים הממוצע: לכל הפריימים של האנימציה שאינם במצב מנוחה לאורך ציר הזמן כולו
- מקרה הגרוע ביותר של אחוז הפריימים שהוחמצו: כפי שנמדד בחלונות זמן נעים של שנייה אחת.
- המאיון ה-95 של אחוז הפריימים שהוחמצו: כפי שנמדד בחלונות זמן נעים של שנייה אחת.
כבר היום אפשר למצוא את הציונים האלה בכלים מסוימים למפתחים ב-Chrome. המדדים האלה מתמקדים רק בנתוני העברת הנתונים הכוללים של הפריימים, אבל אנחנו בודקים גם גורמים אחרים, כמו זמן האחזור של הפריימים.
רוצים לנסות בעצמכם את הכלים למפתחים?
HUD של ביצועים
ב-Chromium יש תצוגה נוחה של ביצועים (HUD) שמוסתר מאחורי דגל (chrome://flags/#show-performance-metrics-hud). בתצוגה הזו אפשר למצוא ציונים בזמן אמת של דברים כמו מדדי Core Web Vitals, וגם כמה הגדרות ניסיוניות של חלקלקות האנימציה על סמך אחוז הפריימים שהוחמצו לאורך זמן.
נתונים סטטיסטיים של רינדור פריימים
מפעילים את 'נתונים סטטיסטיים של עיבוד פריימים' ב-DevTools דרך הגדרות העיבוד כדי לראות תצוגה בזמן אמת של פריימים חדשים של אנימציה, שמסומנים בצבעים שונים כדי להבדיל בין עדכונים חלקיים לבין עדכוני פריימים שהושמטו לגמרי. מדד הפריימים לשנייה שמדווח הוא רק עבור פריימים שמוצגים במלואם.
'צפייה בפריימים' בהקלטות של פרופילי ביצועים ב-DevTools
החלונית 'ביצועים' ב-DevTools כוללת כבר זמן רב צפייה בפריימים. עם זאת, הוא לא תאם יותר לדרך שבה צינור עיבוד הנתונים המודרני לעיבוד גרפי עובד בפועל. לאחרונה ביצענו שיפורים רבים, גם בגרסה האחרונה של Chrome Canary, שאנחנו חושבים שיקלו מאוד על ניפוי באגים באנימציות.
מעכשיו, הפריימים בחלון הצפייה בפריימים מותאמים טוב יותר לגבולות של vsync, ומוצגים לפי צבעים בהתאם לסטטוס שלהם. עדיין אין תצוגה חזותית מלאה של כל הניואנסים שמפורטים למעלה, אבל אנחנו מתכננים להוסיף עוד תצוגות חזותיות בעתיד הקרוב.
מעקב ב-Chrome
לבסוף, באמצעות Chrome Tracing, הכלי המועדף לניתוח מעמיק של פרטים, תוכלו לתעד מעקב אחר 'עיבוד גרפיקה של תוכן אינטרנט' באמצעות ממשק המשתמש החדש של Perfetto (או about:tracing), ולצלול לעומק צינור עיבוד הנתונים של הגרפיקה ב-Chrome. זו יכולה להיות משימה מרתיעה, אבל הוספנו לאחרונה כמה דברים ל-Chromium כדי להקל עליה. סקירה כללית של האפשרויות הזמינות מופיעה במסמך החיים של פריים.
בעזרת אירועי מעקב אפשר לקבוע באופן סופי:
- אילו אנימציות פועלות (באמצעות אירועים בשם
TrackerValidation). - הצגת ציר הזמן המדויק של פריימים של אנימציה (באמצעות אירועים בשם
PipelineReporter). - אם האנימציה לא מתעדכנת בצורה חלקה, צריך לברר מה בדיוק מונע ממנה לפעול מהר יותר (באמצעות פירוט האירועים באירועים מסוג
PipelineReporter). - לגבי אנימציות שמבוססות על קלט, אפשר לראות כמה זמן חלף עד לקבלת עדכון חזותי (באמצעות אירועים בשם
EventLatency).
המאמרים הבאים
מטרת היוזמה Web Vitals היא לספק מדדים והנחיות ליצירת חוויית משתמש מעולה באינטרנט. מדדים מבוססי-מעבדה כמו Total Blocking Time (TBT) חיוניים לזיהוי ולאבחון של בעיות פוטנציאליות באינטראקטיביות. אנחנו מתכננים ליצור מדד דומה מבוסס-מעבדה למדידת חלקות האנימציה.
אנחנו נמשיך לעדכן אתכם בנושא בזמן שנמשיך לעבוד על רעיונות לתכנון מדד מקיף שמבוסס על נתונים של פריימים ספציפיים באנימציה.
בעתיד, אנחנו רוצים גם לתכנן ממשקי API שיאפשרו למדוד את חלקות האנימציה בצורה יעילה למשתמשים אמיתיים בשדה וגם במעבדה. כדאי לעקוב גם שם אחרי עדכונים.
משוב
אנחנו שמחים על כל השיפורים האחרונים בכלים למפתחים שנוספו ל-Chrome כדי למדוד את חלקות האנימציה. אנחנו מזמינים אתכם לנסות את הכלים האלה, לבצע בדיקת ביצועים של האנימציות שלכם ולספר לנו מה חשבתם.
אתם יכולים לשלוח את התגובות שלכם לקבוצת Google web-vitals-feedback, עם השורה '[מדדי חלקות]' בשורת הנושא. נשמח לשמוע מה דעתך.