למדו על מדידת אנימציות, איך לחשוב על פריימים של אנימציה ועל החלקות בדפים באופן כללי.
סביר להניח שנתקלתם בדפים ש"מפצים" או "קופאים" במהלך גלילה או אנימציות. חשוב לנו לומר שהחוויות האלה לא חלקות. כדי לטפל בבעיות כאלה, צוות Chrome עובד על הוספת תמיכה לכלים במעבדה לזיהוי אנימציה, וכן משפרים באופן קבוע את האבחון של צינור העיבוד ב-Chromium.
נשמח לשתף איתכם פרטים על ההתקדמות שלנו בזמן האחרון, להציע הדרכה ספציפית לשימוש בכלים ולדון ברעיונות לגבי מדדים עתידיים של חלקות אנימציה. כמו תמיד, נשמח לקבל מכם משוב.
פוסט זה יעסוק בשלושה נושאים עיקריים:
- מבט מהיר על אנימציות ומסגרות של אנימציות.
- מה אנחנו חושבים כרגע על מדידת החלקות הכולל באנימציה.
- ריכזנו כאן כמה הצעות מעשיות שיעזרו לכם להשתמש בכלים של שיעור ה-Lab היום.
מהן אנימציות?
אנימציות מעוררות תוכן לחיים! כאשר מעבירים תוכן, במיוחד בתגובה לאינטראקציות של המשתמשים, אנימציות יכולות להעניק חוויה טבעית, מובנת ומהנה יותר.
אבל אנימציות שהוטמעו בצורה גרועה או סתם מוסיפים יותר מדי אנימציות עלולים לפגוע בחוויית השימוש ולגרום לה להיות לא נהניתי בכלל. סביר להניח שכולנו השתמשנו בממשק שהוסיף יותר מדי אפקטים 'מועילים', שלמעשה הופכים לעוינים לחוות כשהביצועים שלהם חלשים. לכן, משתמשים מסוימים עשויים להעדיף תנועה מצומצמת, העדפת משתמש שחשוב לכבד.
איך פועלות אנימציות?
לסיכום קצר, צינור עיבוד הנתונים לעיבוד מורכב מכמה שלבים רציפים:
- סגנון: חישוב העיצובים שחלים על הרכיבים.
- פריסה: יצירת הגאומטריה והמיקום של כל רכיב.
- צבע: ממלאים את הפיקסלים של כל רכיב בשכבות.
- מרוכב: משרטטים את השכבות על המסך.
יש דרכים רבות להגדיר אנימציות, אבל באופן בסיסי כולן פועלות באמצעות אחת מהאפשרויות הבאות:
- שינוי מאפייני הפריסה.
- התאמת מאפייני הצבע.
- התאמת מאפיינים מרוכבים.
מכיוון שהשלבים האלה הם רציפים, חשוב להגדיר אנימציות במונחים של מאפיינים שנמצאים בהמשך צינור עיבוד הנתונים. ככל שהעדכון מתבצע מוקדם יותר, כך העלויות גבוהות יותר והסבירות שהוא לא יפעל בצורה חלקה. (פרטים נוספים זמינים במאמר רינדור ביצועים).
אמנם נוח ליצור אנימציה של מאפייני פריסה, אבל יש עלויות לעשות זאת, גם אם העלויות האלה לא מופיעות מיד. צריך להגדיר את האנימציות במונחים של שינויים במאפיינים מורכבים ככל האפשר.
הגדרת הנפשות CSS להצהרה או שימוש באנימציות אינטרנט, והקפדה על הנפשה של מאפיינים מרוכבים הם הצעד הראשון שצריך לבצע כדי להבטיח אנימציות חלקות ויעילות. עם זאת, זה לבדו לא מבטיח עקביות, כי גם לאנימציות אינטרנט יעילות יש מגבלות ביצועים. לכן חשוב תמיד למדוד!
מהן פריימים של אנימציה?
עובר זמן עד שעדכונים בייצוג החזותי של הדף מופיעים. שינוי חזותי יוביל לפריים אנימציה חדש, שבסופו של דבר יעובד במסך של המשתמש.
הצגת עדכונים במרווח זמן מסוים, כך שהעדכונים החזותיים מקובצים. מסכים רבים מתעדכנים במרווח זמן קבוע, כמו 60 פעמים בשנייה (60 הרץ). במסכים מודרניים יותר אפשר ליהנות מקצב רענון גבוה יותר (נכון לעכשיו, קצב רענון גבוה יותר (90 עד 120 הרץ). לעיתים קרובות המסכים האלה יכולים להשתנות באופן פעיל בין קצבי הרענון לפי הצורך, או אפילו להציע קצב פריימים משתנה לחלוטין.
המטרה של כל אפליקציה, כמו משחק או דפדפן, היא לעבד את כל העדכונים הוויזואליים שבאצווה וליצור פריים אנימציה מלא בזמן האחרון, בכל פעם. שימו לב שהיעד הזה שונה לחלוטין ממשימות דפדפן חשובות אחרות, כמו טעינת תוכן מהרשת במהירות או ביצוע יעיל של משימות 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 הראשי (כמו פריסה), תגרום לצמצום פריימים ולפחות קריאות חוזרות (callback) של rAF ולירידה ב-FPS.
כשה-thread הראשי מתקזז, העדכונים החזותיים מתחילים לפעול. זה לא בסדר!
כלי מדידה רבים התמקדו במידה רבה ביכולת של ה-thread הראשי להניב תוצאות בזמן, וכדי שפריימים של אנימציה יפעלו בצורה חלקה. אבל זה לא כל הסיפור! לדוגמה:
בסרטון שלמעלה מוצג דף שמחדיר מדי פעם משימות ארוכות ל-thread הראשי. המשימות הארוכות האלה הורסות לחלוטין את היכולת של הדף לספק סוגים מסוימים של עדכונים חזותיים, ובפינה הימנית העליונה ניתן לראות ירידה מקבילה של requestAnimationFrame() FPS בדיווח ל-0.
ובכל זאת, למרות המשימות הארוכות האלה, הדף ממשיך לגלול באופן חלק. הסיבה לכך היא שבדפדפנים מודרניים, הגלילה בדרך כלל מחולקת לשרשורים, והמונעת כולה על ידי המחבר.
זו דוגמה שמכילה בו-זמנית הרבה פריימים שהושמטו ב-thread הראשי, אבל עדיין יש הרבה פריימים של גלילה בשרשור של הקומפוזיטור. אחרי שהמשימה הארוכה מסתיימת, בכל מקרה אין שינוי חזותי בעדכון הראשי ב-thread. בסקרים של rAF נמצאה ירידה בפריים ל-0, אבל מבחינת הראייה המשתמשים לא יבחינו בהבדל!
כשמדובר בפריימים של אנימציה, הסיפור לא כל כך פשוט.
מסגרות אנימציה: העדכונים החשובים
הדוגמה שלמעלה ממחישה שהסיפור כולל יותר מ-requestAnimationFrame() בלבד.
אז מתי עדכוני אנימציה ומסגרות אנימציה חשובים? הנה כמה קריטריונים שאנחנו חושבים עליהם, ונשמח לקבל עליהם משוב:
- עדכונים בקשר לשרשורים ראשיים ולרכיבי Compositor
- חסרים עדכונים לגבי צבעים
- זיהוי אנימציות
- איכות לעומת כמות
עדכונים בקשר לשרשורים ראשיים ולרכיבי Compositor
עדכונים של מסגרת אנימציה אינם בוליאניים. זה לא מקרה שבו הפריימים מושמטים במלואם או מוצגים במלואם. יכולות להיות סיבות רבות לכך שמעוטרת באנימציה מוצגת באופן חלקי באופן חלקי. במילים אחרות, הוא יכול לכלול בו-זמנית תוכן מיושן וגם כמה עדכונים חזותיים חדשים.
הדוגמה הכי נפוצה למצב הזה היא כשהדפדפן לא מצליח ליצור עדכון ראשי חדש לשרשורים במהלך המועד האחרון לפריים, אבל יש לו עדכון חדש לשרשור המרכיב (כמו הדוגמה של גלילה בשרשור מוקדם יותר).
אחת הסיבות החשובות לכך שמומלץ להשתמש באנימציות מוצהרות כדי להנפיש מאפיינים מרוכבים היא שה-thread הראשי לא פנוי. סוגי האנימציות האלה יכולים להמשיך ליצור עדכונים חזותיים בצורה יעילה ובמקביל.
מצד שני, יכולים להיות מקרים שבהם עדכון ראשי של ה-thread זמין בסופו של דבר להצגה, אבל רק אחרי שפספסתם כמה מועדים אחרונים לפריימים. כאן יהיה לדפדפן עדכון מסוים, אבל יכול להיות שהוא לא העדכני ביותר.
באופן כללי, אנחנו מחשיבים פריימים שמכילים עדכונים חזותיים חדשים, בלי כל העדכונים החזותיים החדשים, כמסגרת חלקית. פריימים חלקיים הם די נפוצים. במצב אידיאלי, עדכונים חלקיים יכללו לפחות את העדכונים החזותיים החשובים ביותר, כמו אנימציות, אבל הם יכולים להתרחש רק אם האנימציות מונעות על ידי השרשור של המחבר.
חסרים עדכונים לגבי צבעים
סוג נוסף של עדכון חלקי הוא כשמדיה כמו תמונות לא הסתיימה והופכת אותה לרסטר בזמן להצגת המסגרת.
גם אם הדף סטטי לחלוטין, ייתכן שדפדפנים עדיין לא יעבדו עדכונים חזותיים במהלך הגלילה המהירה. הסיבה לכך היא שתצוגת הפיקסלים של תוכן מחוץ לאזור התצוגה הגלוי עשויה להימחק כדי לחסוך בזיכרון ה-GPU. לוקח זמן לעבד פיקסלים, ויכול להיות שיידרש יותר זמן מפריים אחד כדי לעבד את הכול אחרי גלילה גדולה, כמו הנפת אצבע. השיטה הזו נקראת בדרך כלל לוח דמקה.
בכל הזדמנות של עיבוד פריים אפשר לעקוב אחרי כמה מהעדכונים החזותיים האחרונים הגיעו בפועל למסך. מדידת היכולת לעשות זאת במשך פריימים רבים (או זמן רב) נקראת גם תפוקת פריימים.
אם ה-GPU תקוע, ייתכן שהדפדפן (או הפלטפורמה) יתחיל אפילו לווסת את הקצב שבו הוא מנסה לבצע עדכונים חזותיים וכתוצאה מכך יפחית את קצב הפריימים האפקטיבי. מבחינה טכנית הדבר עשוי להפחית את מספר העדכונים לפריים, אבל מבחינת המראה הוא עדיין ייראה כתפוקת פריימים נמוכה יותר.
עם זאת, לא כל הסוגים של תפוקת פריימים נמוכה הם בלתי טובים. אם הדף לרוב לא פעיל ואין בו אנימציות פעילות, קצב פריימים נמוך מושך מבחינה ויזואלית כמו קצב פריימים גבוה (ובנוסף, הוא יכול לחסוך בצריכת הסוללה).
אז מתי יש חשיבות לתפוקת הפריימים?
זיהוי אנימציות
תפוקת פריימים גבוהה חשובה, במיוחד בתקופות שבהן יש אנימציות חשובות. סוגי אנימציה שונים תלויים בעדכונים חזותיים משרשור ספציפי (ראשי, מחבר או worker), ולכן העדכון החזותי שלו תלוי בשרשור הזה שיספק את העדכון במהלך תאריך היעד. לדעתנו, שרשור נתון משפיע על החלקות בכל פעם שיש אנימציה פעילה שתלויה בעדכון השרשור הזה.
יש סוגים של אנימציות שקל יותר להגדיר ולזהות, מאשר סוגים אחרים. אנימציות מוצהרות, או אנימציות שמבוססות על קלט של משתמש, ברורות יותר להגדרה של אנימציות שמבוססות על JavaScript, שמוטמעות כעדכונים תקופתיים במאפייני סגנון שאפשר להנפיש.
גם עם requestAnimationFrame() אי אפשר תמיד להניח שכל קריאה ל-rAF יוצרת בהכרח עדכון חזותי או אנימציה. לדוגמה, שימוש בסקרים rAF רק כדי לעקוב אחרי קצב הפריימים (כפי שמוצג למעלה) לא אמור להשפיע על מדידות החלקות, כי אין עדכון חזותי.
איכות לעומת כמות
לבסוף, זיהוי עדכונים של אנימציות ומסגרות של אנימציה הוא עדיין רק חלק מהסיפור, כי הוא מתעד רק את כמות עדכוני האנימציה, ולא את האיכות.
לדוגמה, ייתכן שתראו קצב פריימים יציב של 60 FPS בזמן צפייה בסרטון. מבחינה טכנית, הפעולה הזו חלקה לחלוטין, אבל יכול להיות שבסרטון עצמו יש קצב העברת נתונים נמוך או בעיות באחסון זמני ברשת. הנתונים האלה לא מתועדים ישירות על ידי מדדי חלקות האנימציה, אבל הם עדיין עשויים להשפיע על המשתמש.
לחלופין, משחק שמשתמש ב-<canvas> (אולי אפילו שימוש בטכניקות כמו קנבס מחוץ למסך כדי להבטיח קצב פריימים יציב) עשוי להיות חלק לגמרי מבחינה טכנית מבחינת פריימים של אנימציה, ועדיין לא לטעון נכסי משחק באיכות גבוהה לסצנה או להצגת ארטיפקטים.
וכמובן, אתר יכול לכלול כמה אנימציות ממש גרועות 🙂
כלומר, נראה לי שהם היו די מגניבים בזמנם החופשי!
המצבים של מסגרת אנימציה יחידה
יכול להיות שפריימים יוצגו באופן חלקי או שפריימים נשמטים בדרכים שלא משפיעות על החלקות, לכן התחלנו לחשוב על כל פריים שיש בו ציון שלמות או חלקות.
זהו מגוון הדרכים שבהן אנחנו מפרשים את המצב של פריים אנימציה יחיד, במיון מהטוב ביותר לגרוע ביותר:
| לא רצוי לעדכן | זמן ללא פעילות, חזרה על הפריים הקודם. |
| הצגה מלאה | העדכון של ה-thread הראשי בוצע במסגרת המועד האחרון, או שלא היה צורך בעדכון ה-thread הראשי. |
| מוצג באופן חלקי | מחבר בלבד. בעדכון ה-thread הראשי המתעכב לא היה שינוי חזותי. |
| מוצג באופן חלקי | קומפוזיציה בלבד. ל-thread הראשי היה עדכון חזותי, אבל העדכון הזה לא כלל אנימציה שמשפיעה על החלקות. |
| מוצג באופן חלקי | קומפוזיציה בלבד. ל-thread הראשי היה עדכון חזותי שמשפיע על החלקות, אבל במקום זאת הגיעה מסגרת לא עדכנית. |
| מוצג באופן חלקי | קומפוזיטור בלבד; ללא העדכון הראשי הרצוי, והעדכון של הקומפוזיטור כולל אנימציה שמשפיעה על החלקות. |
| מוצג באופן חלקי | לקומפוזיטור בלבד, אבל בעדכון של הקומפוזיטור אין אנימציה שמשפיעה על החלקות. |
| מסגרת נעצרה | אין עדכון. לא היה רצוי לעדכן את הרכיב, והעיכוב העיקרי היה. |
| מסגרת נעצרה | היה צורך בעדכון של הרכיב, אך הוא נדחה. |
| מסגרת לא עדכנית | היה צורך בעדכון, הוא הופק על ידי הכלי לעיבוד, אבל ה-GPU עדיין לא הציג אותו לפני המועד האחרון ל-vsync. |
אפשר להפוך את המצבים האלה לדירוג מסוים. אולי אחת הדרכים לפרש את הציון הזה היא להחשיב אותו כהסתברות שהמשתמש יוכל לראות אותו. יכול להיות שלא ניתן יהיה לתעד הרבה תמונות של פריים בודד, אבל רצף של הרבה פריימים שמנופלים שמשפיע על החלקות בשורה הוא בטוח!
סיכום של כל המידע הזה: מדד 'שיעור הפריימים שהפסיקו להיות'
לפעמים צריך להתעמק במצב של כל פריים של אנימציה, אבל כדאי גם להקצות דירוג מהיר של חוויית משתמש.
מכיוון שמסגרות עשויות להיות מוצגות באופן חלקי,ומכיוון שעדכוני מסגרות עשויים לדלג עליהם באופן מלא לא משפיעים על החלקות, אנחנו רוצים להתמקד פחות בספירת פריימים בלבד, אלא בהיקף שבו הדפדפן לא יכול לספק עדכונים ויזואליים מלאים כשזה רלוונטי.
המודל המנטלי צריך לנוע מ:
- FPS, כדי
- זיהוי עדכוני אנימציה חסרים וחשובים,
- האחוז ירד בתקופה נתונה.
מה שחשוב הוא לדעת: משך הזמן שצריך להמתין לעדכונים חשובים. לדעתנו הדבר תואם את הדרך הטבעית שבה משתמשים חווים את החלקות של תוכן האינטרנט בפועל. עד כה השתמשנו בנתונים הבאים כקבוצת מדדים ראשונית:
- האחוז הממוצע הושמט: לכל פריימים של אנימציה שלא היו פעילים לאורך כל ציר הזמן
- המקרה הגרוע ביותר של 'פריימים שנטשו' על ידי Percent: כפי שנמדד במשך שנייה אחת של חלונות זזים.
- האחוזון ה-95 של 'אחוז פריימים שנטשו': כפי שנמדד במהלך שנייה אחת של חלונות זמן זזים.
היום תוכלו למצוא את הציונים האלה בחלק מהכלים למפתחים ב-Chrome. המדדים האלה מתמקדים רק בתפוקת פריימים כוללת, אבל אנחנו מעריכים גם גורמים אחרים, כמו זמן אחזור של פריימים.
נסה זאת בעצמך בכלים למפתחים!
HUD של ביצועים
ב-Chromium יש HUD מצוין של ביצועים שמסתתר מאחורי דגל (chrome://flags/#show-performance-metrics-hud). בדוח אפשר למצוא ניקוד בזמן אמת לדברים כמו מדדי ליבה לבדיקת חוויית המשתמש באתר, וגם כמה הגדרות ניסיוניות לשינוי חלק של האנימציה, שמבוססות על אחוז הפריימים שהושמטו לאורך זמן.
נתונים סטטיסטיים של רינדור פריימים
אפשר להפעיל את 'נתונים סטטיסטיים של עיבוד פריימים' בכלי הפיתוח דרך הגדרות הרינדור, כדי לראות תצוגה בזמן אמת של פריימים חדשים של אנימציה, שמקודדים לפי צבעים כדי להבחין בין עדכונים חלקיים לבין עדכוני פריימים מלאים. קצב הפריימים המדווח מיועד לפריימים שמוצגים במלואם בלבד.
'צפייה בפריים' בהקלטות של פרופיל ביצועים בכלי הפיתוח
לחלונית הביצועים של כלי הפיתוח יש כבר הרבה זמן צפייה ב-Frames. עם זאת, התהליך קצת לא מסונכרן עם האופן שבו צינור עיבוד הנתונים המודרני לעיבוד פועל. היה הרבה שיפורים לאחרונה, גם בגרסה האחרונה של Chrome Canary, שלדעתנו תקל מאוד על בעיות בניפוי באגים באנימציה.
היום תוכלו לראות שהפריימים במציג המסגרות מתאימים יותר לגבולות vsync ומקודדים לפי צבעים. עדיין אין תצוגה מלאה לכל הדקויות שפורטו למעלה, אבל אנחנו מתכננים להוסיף עוד תכונות בעתיד הקרוב.
מעקב ב-Chrome
לבסוף, באמצעות Chrome Trace, הכלי המועדף להתעמקות בפרטים, תוכלו לתעד מעקב אחר 'רינדור תוכן באינטרנט' באמצעות ממשק המשתמש החדש של Perfetto (או about:tracing), ולהתעמק בצינור עיבוד הנתונים הגרפי של Chrome. זו יכולה להיות משימה מרתיעה, אבל יש כמה דברים שנוספו לאחרונה ל-Chromium כדי להקל עליכם. תוכלו לקבל סקירה כללית על המידע שזמין במסמך Life of a Frame.
באמצעות אירועי מעקב אפשר לקבוע בוודאות את הפרטים הבאים:
- אילו האנימציות פועלות (באמצעות אירועים בשם
TrackerValidation). - קבלת ציר הזמן המדויק של פריימים באנימציה (באמצעות אירועים שנקראים
PipelineReporter). - כדי לקבל עדכונים מרגשים לגבי אנימציה, צריך להבין מה בדיוק מונע מהאנימציה לפעול מהר יותר (באמצעות פירוט האירועים בתוך אירועי
PipelineReporter). - באנימציות המבוססות על קלט, ניתן לבדוק כמה זמן לוקח עד לקבלת עדכון חזותי (באמצעות אירועים בשם
EventLatency).
המאמרים הבאים
המטרה של יוזמת Web Vitals לספק מדדים והנחיות לבניית חוויות משתמש מעולות באינטרנט. מדדים המבוססים על מעבדה, כמו זמן חסימה כולל (TBT), חיוניים לאיתור ולאבחון של בעיות אינטראקטיביות פוטנציאליות. אנחנו מתכננים לעצב מדד דומה שמבוסס על שיעור ה-Lab כדי שהאנימציה תפעל בצורה חלקה.
נעדכן אותך בזמן שנמשיך לעבוד על רעיונות לעיצוב מדד מקיף המבוסס על נתונים נפרדים של מסגרת אנימציה.
בעתיד נתכנן גם ממשקי API שיאפשרו למדוד ביצועים של חלקות האנימציה עבור משתמשים אמיתיים בשדה וגם בשיעור ה-Lab. מומלץ לעקוב גם אחרי העדכונים:
משוב
אנחנו נרגשים לקראת כל השיפורים האחרונים והכלים למפתחים שנשלחו ב-Chrome כדי למדוד חלקות אנימציה. נסה את הכלים האלה, בדוק את האנימציות שלך וספר לנו לאן הן מובילות!
תוכלו לשלוח תגובות לקבוצת web-vitals-feedback Google באמצעות הפקודה '[Smoothness Metrics]' בשורת הנושא. אנחנו מצפים לשמוע מה דעתכם!