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

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

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

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

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

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

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

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

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

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

איך עובדות אנימציות?

לסיכום, צינור עיבוד הנתונים לעיבוד מורכב מכמה שלבים ברצף:

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

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

• שינוי המאפיינים של פריסת המודעות.
• שינוי המאפיינים של paint.
• שינוי מאפיינים מורכבים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הדוגמה שלמעלה מראה שיש עוד דברים שחשוב לדעת מלבד requestAnimationFrame().

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

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

עדכונים של ה-thread הראשי ושל ה-compositor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אני מניח שהם היו די מגניבים בזמנו!

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

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

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

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

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

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

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

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

1. פריימים לשנייה, עד
2. זיהוי עדכוני אנימציה חסרים וחשובים, כדי
3. 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 כדי להקל עליה. אפשר לקבל סקירה כללית של מה שזמין במסמך Life of a Frame.

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

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

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

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

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

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

משוב

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

אתם יכולים לשלוח את התגובות שלכם לקבוצת Google‏ web-vitals-feedback, עם השורה '[מדדי חלקות]' בשורת הנושא. נשמח לשמוע מה דעתך.