Long Animation Frames API (לו-Af מבוטא LoAF) הוא עדכון ל-Long Tasks API שנועד לספק הבנה טובה יותר של עדכוני ממשק משתמש (UI) איטיים. האפשרות הזו יכולה להיות שימושית כדי לזהות מסגרות של אנימציה איטית שעשויות להשפיע על מדד Interaction to Next Paint (INP) – מדד ליבה לבדיקת חוויית המשתמש באתר. המדד הזה מודד את הרספונסיביות, או כדי לזהות בעיות אחרות בממשק המשתמש שמשפיעות על החלקה.
סטטוס ה-API
בעקבות גרסת המקור לניסיון של Chrome 116 עד Chrome 122, ממשק LoAF API נשלח מ-Chrome 123.
ברקע: Long Tasks API
ממשק ה-API של Long Animation Frames הוא חלופה ל-API של משימות ארוכות, שזמין ב-Chrome כבר זמן מה (החל מגרסה Chrome 58). כפי ששמו מרמז, ה-Long Task API מאפשר לכם לעקוב אחרי משימות ארוכות, שהן משימות שתופסות את ה-thread הראשי במשך 50 אלפיות השנייה או יותר. אפשר לעקוב אחרי משימות ארוכות בממשק PerformanceLongTaskTiming עם PeformanceObserver:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'longtask', buffered: true });
משימות ארוכות צפויות לגרום לבעיות של תגובה למשתמשים. אם משתמש מנסה לבצע אינטראקציה בדף – למשל ללחוץ על לחצן או לפתוח תפריט – אבל ה-thread הראשי כבר מטפל במשימה ארוכה, האינטראקציה של המשתמש מתעכבת בהמתנה עד שהמשימה תושלם.
כדי לשפר את הרספונסיביות, מומלץ בדרך כלל לפרק משימות ארוכות. אם כל משימה ארוכה מחולקת לסדרה של כמה משימות קטנות יותר, ייתכן שיהיה אפשר לבצע ביניהן משימות חשובות יותר כדי למנוע עיכובים משמעותיים בתגובה לאינטראקציות.
לכן, כשמנסים לשפר את הרספונסיביות, בדרך כלל המאמץ הראשון הוא להריץ מעקב ביצועים ולבדוק משימות ארוכות. אפשר לעשות את זה באמצעות כלי ביקורת מבוסס-מעבדה כמו Lighthouse (שכולל ביקורת להימנע ממשימות ארוכות של שרשור ראשי), או לעיין במשימות ארוכות בכלי הפיתוח ל-Chrome.
בדיקות מבוססות-מעבדה בדרך כלל הן לא התחלה טובה לזיהוי בעיות רספונסיביות, כי הכלים האלה לא תמיד כוללים אינטראקציות. במקרים כאלה, מדובר בקבוצה קטנה של אינטראקציות סבירות. מומלץ למדוד את הסיבות לאינטראקציות איטיות בשטח.
החסרונות של Long Tasks API
מדידה של משימות ארוכות בשטח באמצעות 'תצפית ביצועים' היא שימושית במידה מסוימת. בפועל, המידע לא מספק מידע רב מעבר לעובדה שמשימה ארוכה בוצעה ולמשך כמה זמן.
בדרך כלל, הכלים של Real User Monitoring (RUM) משתמשים בנתון הזה כדי לבחון את מספר המשימות הארוכות או את משך הזמן שלהן או לזהות באילו דפים הן מתרחשות. עם זאת, ללא הפרטים הבסיסיים לגבי מה שגרם למשימה הארוכה, השימוש באפשרות הזו הוא מוגבל בלבד. ל-Long Tasks API יש רק מודל שיוך בסיסי, שמצביע על כך רק למאגר התגים שבו התרחשה המשימה הארוכה (המסמך ברמה העליונה או <iframe>), ולא לסקריפט או לפונקציה שקראו לו, כפי שמוצג ברשומה אופיינית:
{
"name": "unknown",
"entryType": "longtask",
"startTime": 31.799999997019768,
"duration": 136,
"attribution": [
{
"name": "unknown",
"entryType": "taskattribution",
"startTime": 0,
"duration": 0,
"containerType": "window",
"containerSrc": "",
"containerId": "",
"containerName": ""
}
]
}
גם ממשק ה-API של Tasks, לא הושלם, כי יכול להיות שהוא לא יכלול גם כמה משימות חשובות. עדכונים מסוימים, כמו רינדור, מתרחשים במשימות נפרדות, שרצוי לכלול יחד עם הביצוע הקודם, שגרם לעדכון הזה למדוד במדויק את 'העבודה הכוללת' באותה אינטראקציה. לפרטים נוספים על המגבלות של הסתמכות על משימות, קראו את הקטע 'איפה משימות ארוכות' הן קצרות' בהסבר.
הבעיה האחרונה היא שמדידת משימות ארוכות מדווחת רק על משימות נפרדות שנמשכות יותר מ-50 אלפיות השנייה. פריים של אנימציה יכול להיות מורכב מכמה משימות שקטנות מהמגבלה של 50 אלפיות השנייה, אבל בכל זאת לחסום את יכולת הדפדפן לבצע רינדור.
ממשק API למסגרות אנימציה ארוכות
Long Animation Frames API (LoAF) הוא ממשק API חדש שמטרתו לטפל בכמה מהחסרונות של Long Tasks API. בעזרת ה-API, המפתחים יכולים לקבל תובנות פרקטיות יותר שיעזרו לטפל בבעיות רספונסיביות ולשפר את ה-INP.
מהירות תגובה טובה פירושה שדף מגיב במהירות לאינטראקציות שבוצעו איתו. כדי לעשות את זה, צריכה להיות לכם אפשרות להציג את העדכונים שהמשתמשים צריכים לבצע בזמן, ומניעת החריגה מהעדכונים האלה. ל-INP מומלץ להגיב תוך 200 אלפיות השנייה, אבל בעדכונים אחרים (למשל, אנימציות) גם התגובה הזו עשויה להיות ארוכה מדי.
Long Animation Frames API הוא גישה חלופית למדידת עבודה חסומה. במקום למדוד את המשימות הנפרדות, ה-API של Long Animation Frames – כפי שמרמז השם שלו – מודד פריימים ארוכים של אנימציה. פריים אנימציה ארוך מופיע כשעדכון רינדור מתעכב יותר מ-50 אלפיות השנייה (זהו הסף לשימוש ב-Long Tasks API).
אפשר להבחין בפריימים ארוכים של אנימציה בדומה למשימות ארוכות עם PerformanceObserver, אבל במקום זאת, צריך לבחון סוג long-animation-frame:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'long-animation-frame', buffered: true });
אפשר גם לשלוח שאילתות לגבי פריימים ארוכים של אנימציה בציר הזמן של הביצועים. למשל:
const loafs = performance.getEntriesByType('long-animation-frame');
עם זאת, יש maxBufferSize לרשומות של ביצועים שאחריהן מושמטות רשומות חדשות יותר, לכן גישת PerformanceObserver היא הגישה המומלצת. הגודל של מאגר הנתונים הזמני של long-animation-frame מוגדר ל-200, בדיוק כמו הגודל של long-tasks.
היתרונות של צפייה בפריימים במקום משימות
היתרון המרכזי של לבחון את זה מנקודת מבט של פריים ולא מבחינת משימות הוא שאנימציה ארוכה יכולה להיות מורכבת מכל מספר של משימות שהובילו באופן מצטבר לפריים אנימציה ארוך. הגישה הזו מתייחסת לנקודה האחרונה שהוזכרה קודם, שבה ה-API של Long Tasks לא יכול להציג את סך כל המשימות הקטנות יותר שחוסמות רינדור, שלפני פריים של אנימציה.
יתרון נוסף של התצוגה החלופית הזו לגבי משימות ארוכות הוא היכולת לספק פירוטי תזמון של כל הפריים. במקום לכלול רק את השדה startTime ו-duration, כמו ה-API של המשימות ארוכות, ב-LoAF יש פירוט הרבה יותר מפורט של החלקים השונים של משך הפריים, כולל:
startTime: זמן ההתחלה של מסגרת האנימציה הארוכה ביחס לשעת ההתחלה של הניווט.duration: משך הזמן של מסגרת האנימציה הארוכה (לא כולל זמן ההצגה).renderStart: שעת ההתחלה של מחזור הרינדור, שכוללת קריאות חוזרות (callback) מסוגrequestAnimationFrame, חישוב סגנון ופריסה, שינוי גודל של אובייקט צפייה וקריאה חוזרת (callbacks) של צופה בהצטלבות.styleAndLayoutStart: תחילת התקופה של חישובי סגנון ופריסה.firstUIEventTimestamp: השעה של האירוע הראשון בממשק המשתמש (עכבר/מקלדת וכו') לטיפול במהלך הפריים הזה.blockingDuration: משך הזמן באלפיות השנייה שבו פריים האנימציה נחסם.
חותמות הזמן האלה מאפשרות לחלק את מסגרת האנימציה הארוכה לתזמונים:
| תזמון | החישוב |
|---|---|
| שעת ההתחלה | startTime |
| שעת הסיום | startTime + duration |
| משך העבודה | renderStart ? renderStart - startTime : duration |
| משך העיבוד | renderStart ? (startTime + duration) - renderStart: 0 |
| רינדור: משך הפריסה מראש | styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0 |
| עיבוד: משך הזמן של הסגנון והפריסה | styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0 |
פרטים נוספים על התזמונים הנפרדים האלה זמינים במסמך ההסבר, שמספק פרטים מפורטים לגבי הפעילות שתורמת לפריים ארוך של אנימציה.
שיוך (Attribution) טוב יותר
סוג הרשומה long-animation-frame כולל נתוני שיוך (Attribution) טובים יותר לגבי כל סקריפט שתרמו לפריים של אנימציה ארוכה.
בדומה ל-Long Tasks API, המידע הזה יופיע במגוון רשומות שיוך, שכל אחת מהן כוללת את הפרטים:
- גם
nameוגםEntryTypeיחזירוscript. invokerבעל משמעות שמציין איך הסקריפט נקרא (לדוגמה,'IMG#id.onload','Window.requestAnimationFrame'או'Response.json.then').invokerTypeשל נקודת הכניסה לסקריפט:user-callback: קריאה חוזרת (callback) ידועה שרשומה מ-API של פלטפורמת אינטרנט (לדוגמה,setTimeout,requestAnimationFrame).event-listener: האזנה לאירוע פלטפורמה (לדוגמה,click,load,keyup).resolve-promise: מטפל במובטח של פלטפורמה (לדוגמה,fetch(). חשוב לשים לב שבמקרה של הבטחות, כל הגורמים המטפלים באותן הבטחות מתערבבים יחד כ "סקריפט אחד").reject-promise: בהתאם ל-resolve-promise, אבל לדחייה.classic-script: הערכת סקריפטים (לדוגמה,<script>אוimport())module-script: זהה ל-classic-script, אבל לסקריפטים של מודול.
- נתוני תזמון נפרדים עבור הסקריפט:
startTime: השעה שבה הופעלה פונקציית הכניסה.duration: משך הזמן ביןstartTimeועד לסיום העיבוד של התור הבא של המיקרו-משימות.executionStart: השעה אחרי האיסוף.forcedStyleAndLayoutDuration: משך הזמן הכולל שהוקדש לעיבוד הפריסה והסגנון באילוץ של הפונקציה הזו (למידע נוסף על כיבוי).pauseDuration: משך הזמן הכולל שהוקדש לפעולות סינכרוניות ב'השהיה' (התראה, XHR סינכרוני).
- פרטי מקור הסקריפט:
sourceURL: השם של משאב הסקריפט (אם הוא זמין) או ריק אם הוא לא נמצא.sourceFunctionName: השם של פונקציית הסקריפט במקומות שבהם היא זמינה (או ריק אם לא נמצא).sourceCharPosition: המיקום של תו הסקריפט כאשר הוא זמין (או הערך 1- אם לא נמצא).
windowAttribution: המאגר (המסמך ברמה העליונה, או<iframe>) שבו התרחשה מסגרת האנימציה הארוכה.window: הפניה לאותו חלון מקור.
רשומות המקור מאפשרות למפתחים לדעת בדיוק איך נקרא כל סקריפט במסגרת האנימציה הארוכה, עד למיקום התו בסקריפט הקריאה. הנתון הזה מציין את המיקום המדויק במשאב JavaScript שהוביל למסגרת האנימציה הארוכה.
דוגמה לרשומת ביצועים long-animation-frame
דוגמה מלאה לרשומת ביצועים של long-animation-frame, המכילה סקריפט יחיד, היא:
{
"blockingDuration": 0,
"duration": 60,
"entryType": "long-animation-frame",
"firstUIEventTimestamp": 11801.099999999627,
"name": "long-animation-frame",
"renderStart": 11858.800000000745,
"scripts": [
{
"duration": 45,
"entryType": "script",
"executionStart": 11803.199999999255,
"forcedStyleAndLayoutDuration": 0,
"invoker": "DOMWindow.onclick",
"invokerType": "event-listener",
"name": "script",
"pauseDuration": 0,
"sourceURL": "https://web.dev/js/index-ffde4443.js",
"sourceFunctionName": "myClickHandler",
"sourceCharPosition": 17796,
"startTime": 11803.199999999255,
"window": [Window object],
"windowAttribution": "self"
}
],
"startTime": 11802.400000000373,
"styleAndLayoutStart": 11858.800000000745
}
כפי שניתן לראות, הדבר מספק לאתרים כמות חסרת תקדים של נתונים שיאפשרו לאתרים להבין את הגורם לעדכוני עיבוד איטיים.
שימוש ב-Long Animation Frames API בשדה
כלים כמו Chrome DevTools ו-Lighthouse – אמנם שימושיים לגילוי ולשחזור של בעיות – הם כלים לשיעור Lab שעלולים לפספס היבטים חשובים של חוויית המשתמש, שרק נתוני שטח יכולים לספק.
ה-API של מסגרת האנימציה הארוכה תוכנן לשימוש בשטח כדי לאסוף נתונים הקשריים חשובים לגבי אינטראקציות של משתמשים שלא הייתה אפשרות להשתמש בהן ב-Long Tasks API. כך תוכלו לזהות ולשחזר בעיות באינטראקטיביות, שיכול להיות שלא הייתם מגלים בדרך אחרת.
תכונה לזיהוי תמיכה ב-API של מסגרות אנימציה ארוכות
הקוד הבא יעזור לכם לבדוק אם ה-API נתמך:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
// Monitor LoAFs
}
קישור לפעולת ה-INP הארוכה ביותר
התרחיש לדוגמה הבולט ביותר של Long Animation Frames API הוא לעזור לאבחן ולפתור בעיות מסוג Interaction to Next Paint (INP). זו הייתה אחת מהסיבות העיקריות לכך שצוות Chrome פיתח את ה-API הזה. INP טוב הוא המקום שבו כל האינטראקציות מגיבות בתוך 200 אלפיות שנייה או פחות מהאינטראקציה, עד לציור הפריים.
'INP LoAF' הוא ה-LoAF שכולל את האינטראקציה של INP כפי שמוצג בתרשים הבא:
במקרים מסוימים, יכול להיות שאירוע INP יתפרס על שתי בקשות LoAF – בדרך כלל אם האינטראקציה מתרחשת אחרי שהפריים התחיל את החלק של הרינדור של הפריים הקודם, ולכן הגורם המטפל באירועים שהוא עיבד במסגרת הבאה:
במקרים נדירים, יכול להיות שהיא תכסה יותר משני אסימוני LoAF.
תיעוד הנתונים של LoAF המשויך לאינטראקציה של INP מאפשר לקבל מידע נוסף על האינטראקציה של INP כדי לעזור לאבחן אותה. האפשרות הזו שימושית במיוחד כדי להבין את עיכוב הקלט: אפשר לראות אילו סקריפטים אחרים פעלו במסגרת הזו.
כדאי גם להבין משך העיבוד ועיכוב במצגת לא מוסברים, אם הגורמים המטפלים באירועים לא משכפלים את הערכים שמוצגים עבור המשתמשים, כי יכול להיות שסקריפטים אחרים פועלים עבור המשתמשים, ויכול להיות שהם לא נכללים בבדיקות שלכם.
אין API ישיר שמאפשר לקשר רשומת INP לרשומה או לרשומות הקשורות ל-LoAF, למרות שניתן לעשות זאת בקוד על ידי השוואה בין זמני ההתחלה והסיום של כל אחד מהיעדים (יש לעיין בסקריפט לדוגמה של WhyNp).
הספרייה web-vitals כוללת את כל מזהי ה-LoAF שמצטלבים בנכס longAnimationFramesEntries של ממשק השיוך (Attribution) של INP מגרסה 4.
אחרי שמקשרים את הרשומה או את הערכים של LoAF, אפשר לכלול מידע עם ייחוס INP. האובייקט scripts מכיל חלק מהמידע החשוב ביותר, כי הוא יכול להראות מה עוד פעלו בפריימים האלה. לכן, אם משייכים את הנתונים האלה לשירות ניתוח הנתונים, תוכלו להבין טוב יותר למה האינטראקציות היו איטיות.
דיווח על שדות LoAF עבור האינטראקציה של INP הוא דרך טובה לזהות את בעיות האינטראקטיביות הדחופות ביותר בדף. לכל משתמש עשוי להיות אינטראקציה שונה עם הדף שלכם. כמו כן, אם יהיו מספיק נתוני שיוך של INP, נתוני השיוך (Attribution) של INP ייכללו במספר בעיות פוטנציאליות. כך ניתן למיין סקריפטים לפי נפח כדי לראות אילו סקריפטים קשורים ל-INP איטי.
דיווח על יותר נתוני אנימציה ארוכים לנקודת קצה של ניתוח נתונים
אחד החסרונות לבחינת רק את ה-INP LoAF הוא ייתכן שמפספסים תחומים פוטנציאליים אחרים לביצוע שיפורים שעשויים לגרום לבעיות INP עתידיות. כתוצאה מכך, תרגישו כאילו אתם רודפים אחרי הזנב ומתקנים בעיה שקשורה ל-INP בציפייה לשיפור משמעותי. רק כדי לגלות שהאינטראקציה הבאה האיטית ביותר תהיה טובה מעט מזו של ה-INP.
לכן, במקום להתמקד רק בהסתכלות על חוק ה-INP, כדאי לשקול את כל בקשות ה-LoAF לאורך משך החיים של הדף:
עם זאת, כל רשומה של LoAF מכילה נתונים רבים, כך שסביר להניח שלא תרצו לשווק את הכול בחזרה. במקום זאת, כדאי להגביל את הניתוח לחלק מה-LoAF או לנתונים מסוימים.
הנה כמה הצעות לדפוסים:
- צפייה בפריימים ארוכים של אנימציה עם אינטראקציות
- צפייה בפריימים של אנימציה שאורכם מעל סף מסוים
- צפייה בפריימים הארוכים ביותר של האנימציה
- זיהוי דפוסים נפוצים במסגרות אנימציה ארוכות
איזה מהדפוסים האלה הכי מתאים לכם, תלוי במרחק הדרך שלכם לאופטימיזציה ובאורך מסגרות האנימציה הנפוצות. באתר שלא עבר בעבר אופטימיזציה לתגובות, יכול להיות שיש הרבה מודעות LoAF שכדאי להגביל רק ל-LoAF עם אינטראקציות, להגדיר סף גבוה או לבדוק רק את הגרועות ביותר. במהלך פתרון הבעיות הנפוצות שקשורות לתגובות, אפשר להרחיב את השימוש בהן – לא להגביל רק אינטראקציות, להוריד ערכי סף או לחפש דפוסים מסוימים.
צפייה במסגרות אנימציה ארוכות עם אינטראקציות
כדי לקבל תובנות מעבר למסגרת האנימציה הארוכה של INP, אפשר לבחון את כל מודעות ה-LoAF עם אינטראקציות (שניתן לזהות באמצעות ערך של firstUIEventTimestamp).
זו גם יכולה להיות שיטה קלה יותר למעקב אחרי INP LoAF במקום לנסות למצוא קישור בין שני התחומים, דבר שיכול להיות מורכב יותר. ברוב המקרים הדוח יכלול את מספר ה-INP LoAF בביקור נתון. במקרים נדירים, האינטראקציות האלה עדיין מציגות אינטראקציות ארוכות שחשוב לתקן, כי זו עשויה להיות אינטראקציה עם INP עבור משתמשים אחרים.
הקוד הבא מתעד את כל רשומות LoAF שנמשכות יותר מ-150 אלפיות השנייה שבהן התרחשה אינטראקציה במהלך הפריים. הערכים של 150 נבחרים כאן כי הם מעט פחות מסף ה-INP ה'טוב' של 200 אלפיות השנייה. תוכלו לבחור ערך גבוה או נמוך יותר בהתאם לצרכים שלכם.
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS &&
entry.firstUIEventTimestamp > 0
) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
צפייה בפריימים של אנימציה שאורכם עולה על סף מסוים
אסטרטגיה נוספת היא לעקוב אחר כל מזהי ה-LoAF והשדרים שמגיעים מסף מסוים בחזרה לנקודת קצה של Analytics לצורך ניתוח במועד מאוחר יותר:
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
הרשומות של מסגרת האנימציה הארוכות יכולות להיות די גדולות, ולכן המפתחים צריכים להחליט אילו נתונים מהרשומה יישלחו לניתוח נתונים. לדוגמה, זמני הסיכום של הרשומה ואולי גם שמות הסקריפט, או קבוצה מינימלית אחרת של נתונים הקשריים אחרים שעשויים להיחשב כנחוצים.
צפייה במסגרות האנימציה הארוכות ביותר
במקום לקבוע סף מוגדר, יכול להיות שאתרים ירצו לאסוף נתונים במסגרת האנימציה הארוכה ביותר (פריימים) כדי לצמצם את נפח הנתונים שצריך לשייך אל הרשת. כך, לא משנה כמה זמן האנימציה מכילה את מספר הפריימים הגרועים ביותר של אנימציה בדף, רק הנתונים של האנימציה הגרועה ביותר, חמש או כל הפריימים הארוכים ביותר שנדרשים בהחלט מועברים בחזרה.
MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];
const observer = new PerformanceObserver(list => {
longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
(a, b) => b.blockingDuration - a.blockingDuration
).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });
אפשר גם לשלב את האסטרטגיות האלה – צריך לבחון רק את 10 יחידות ה-LoAF הגרועות ביותר, עם אינטראקציות שנמשכות יותר מ-150 אלפיות השנייה.
בזמן המתאים (רצוי באירוע visibilitychange) לחזור לניתוח הנתונים. כדי לבצע בדיקה מקומית, אפשר להשתמש ב-console.table מדי פעם:
console.table(longestBlockingLoAFs);
זהו דפוסים נפוצים במסגרות אנימציה ארוכות
כשיטה חלופית, כדאי לבחון סקריפטים נפוצים שמופיעים בתדירות הגבוהה ביותר ברשומות של מסגרות אנימציה ארוכות. אפשר לקבל דיווח חוזר על הנתונים ברמת הסקריפט ומיקום התו כדי לזהות משתמשים שמבצעים הפרות חוזרות ונשנות של המדיניות.
האפשרות הזו יכולה לעבוד טוב במיוחד בפלטפורמות שניתן להתאים אישית, שבהן ניתן לזהות מספר אתרים בעיצובים או ביישומי פלאגין שגורמים לבעיות בביצועים.
ניתן לסכם את זמן הביצוע של סקריפטים נפוצים או של מקורות של צד שלישי בפריימים ארוכים של אנימציה, ולקבל עליהם דיווח כדי לזהות תורמים נפוצים למסגרות אנימציה ארוכות באתר או באוסף של אתרים. לדוגמה, כדי לבחון כתובות URL:
const observer = new PerformanceObserver(list => {
const allScripts = list.getEntries().flatMap(entry => entry.scripts);
const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
allScripts.filter(script => script.sourceURL === sourceURL)
]));
const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
sourceURL,
count: scripts.length,
totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
}));
processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
// Example here logs to console, but could also report back to analytics
console.table(processedScripts);
});
observer.observe({type: 'long-animation-frame', buffered: true});
והדוגמה לפלט הזה היא:
(index) |
sourceURL |
count |
totalDuration |
|---|---|---|---|
0 |
'https://example.consent.com/consent.js' |
1 |
840 |
1 |
'https://example.com/js/analytics.js' |
7 |
628 |
2 |
'https://example.chatapp.com/web-chat.js' |
1 |
5 |
שימוש ב-Long Animation Frames API בכלים
ה-API מאפשר גם כלים נוספים למפתחים לניפוי באגים מקומי. בכלים מסוימים, כמו Lighthouse ו-Chrome DevTools, אפשר לאסוף חלק גדול מהנתונים האלה באמצעות פרטי מעקב ברמה נמוכה יותר, אבל שימוש ב-API ברמה גבוהה יותר הזה עשוי לאפשר לכלים אחרים לגשת לנתונים האלה.
הצגת נתונים של מסגרות אנימציה ארוכות בכלי הפיתוח
אפשר להציג פריימים ארוכים של אנימציה בכלי הפיתוח באמצעות ה-API performance.measure() שמוצג לאחר מכן במסלול תזמוני המשתמש של כלי הפיתוח לדוחות הביצועים, כדי להראות לכם איפה למקד את המאמצים לשיפור הביצועים:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
performance.measure('LoAF', {
start: entry.startTime,
end: entry.startTime + entry.duration,
});
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
בטווח הארוך, סביר להניח שהוא ישולב בכלי הפיתוח עצמו, אבל קטע הקוד הקודם מאפשר להציג אותו שם בינתיים.
שימוש בנתונים של מסגרות אנימציה ארוכות בכלים אחרים למפתחים
התוסף Web Vitals הראה את הערך במידע על תוצאות ניפוי הבאגים של סיכום הרישום ביומן כדי לאבחן בעיות בביצועים.
עכשיו המערכת גם מציגה נתונים של פריימים ארוכים של אנימציה לכל קריאה חוזרת ל-INP ולכל אינטראקציה:
שימוש בנתונים של מסגרות אנימציה ארוכות בכלי בדיקה אוטומטיים
באופן דומה, כלי בדיקה אוטומטיים בצינורות עיבוד נתונים של CI/CD יכולים לגלות פרטים על בעיות ביצועים פוטנציאליות על ידי מדידה של פריימים ארוכים של אנימציה בזמן הרצה של חבילות בדיקה שונות.
שאלות נפוצות
דוגמאות לשאלות נפוצות בנושא ה-API הזה:
למה לא רק להרחיב את היכולות של Long Tasks API או לחזור עליהן?
זו אפשרות חלופית לדיווח על מדידה דומה, אבל שונה, בסוף של בעיות פוטנציאליות של תגובה. חשוב לוודא שאתרים שמסתמכים על ממשק ה-API הקיים של Long Tasks ימשיכו לפעול כדי למנוע פגיעה בתרחישים לדוגמה קיימים.
אפשר להפיק תועלת מ-Long Tasks API מחלק מהתכונות של LoAF (כמו מודל שיוך טוב יותר), אבל אנחנו מאמינים שהתמקדות בפריימים במקום במשימות מעניקה הרבה יתרונות שהופכים את ה-API הזה לשונה לחלוטין מה-API הקיים של Long Tasks.
האם הגרסה הזו תחליף את Long Tasks API?
אנחנו מאמינים ש-Long Animation Frames API הוא API טוב יותר ומלא יותר למדידת משימות ארוכות, בשלב זה, אנחנו לא מתכננים להוציא משימוש את Long Tasks API.
נשמח לקבל משוב
אפשר לשלוח משוב ברשימת הבעיות ב-GitHub. אפשר גם לדווח על באגים בהטמעה של ה-API ב-Chrome בכלי למעקב אחרי בעיות של Chrome.
סיכום
ממשק ה-API של Long Animation Frames הוא API חדש ומלהיב עם יתרונות פוטנציאליים רבים בהשוואה לממשק ה-API הקודם של Long Tasks.
הוא מוכיח את עצמו ככלי מרכזי לטיפול בבעיות רספונסיביות כפי שנמדד על ידי INP. INP הוא מדד מאתגר לביצוע אופטימיזציה. אחת הדרכים שבהן צוות Chrome מעוניין לעזור למפתחים לזהות בעיות ולטפל בהן.
עם זאת, ההיקף של Long Animation Frames API כולל מידע מעבר ל-INP, והוא יכול לעזור בזיהוי גורמים אחרים של עדכונים איטיים שיכולים להשפיע על יצירה חלקה של חוויית המשתמש באתר.