ממשק API למסגרות אנימציה ארוכות

Barry Pollard
Noam Rosenthal

Long Animation Frames API (LoAF – הגייה של Lo-Af) הוא עדכון ל-Long Tasks API כדי לספק הבנה טובה יותר של עדכונים איטיים בממשק המשתמש (UI). המידע הזה יכול להיות שימושי לזיהוי פריימים איטיים של אנימציה שסביר להניח שישפיעו על מדד הליבה לבדיקת חוויית המשתמש באתר (Core Web Vital) Interaction to Next Paint (INP) שמודד תגובה, או לזהות בעיות jank אחרות בממשק המשתמש שמשפיעות על החלקות.

הסטטוס של ה-API

תמיכה בדפדפן

  • 123
  • x
  • x
  • x

בעקבות גרסת המקור לניסיון מ-Chrome 116 ל-Chrome 122, ה-API של LoAF נשלח מ-Chrome 123.

ממשק ה-API של משימות ארוכות

תמיכה בדפדפן

  • 58
  • 79
  • x
  • x

מקור

ממשק ה-API של מסגרת אנימציה ארוכה הוא חלופה לממשק ה-API של משימות ארוכות, שזמין ב-Chrome כבר זמן מה (החל מגרסה 58 של Chrome). כפי ששמו מרמז, ממשק ה-API של משימות ארוכות מאפשר לך לעקוב אחר משימות ארוכות, שהן משימות שתופסות את ה-thread הראשי במשך 50 אלפיות השנייה או יותר. אפשר לעקוב אחרי משימות ארוכות באמצעות הממשק PerformanceLongTaskTiming, עם PeformanceObserver:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

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

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

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

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

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

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

ממשק ה-API של מסגרת אנימציה ארוכה

תמיכה בדפדפן

  • 123
  • x
  • x
  • x

Long Animation Frames API (LoAF) הוא ממשק API חדש שמטרתו לטפל בחלק מהחסרונות של ה-Long Tasks API, כדי לאפשר למפתחים לקבל תובנות פרקטיות יותר שיעזרו לטפל בבעיות רספונסיביות ולשפר את ה-INP.

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

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

יתרון נוסף של התצוגה החלופית הזו במשימות ארוכות הוא היכולת להציג פירוטי תזמון של הפריים כולו. במקום לכלול רק startTime ו-duration, כמו ממשק ה-API של משימות ארוכות, LoAF כולל פירוט הרבה יותר מפורט של החלקים השונים של משך הפריים, כולל:

  • startTime: שעת ההתחלה של מסגרת האנימציה הארוכה ביחס לשעת ההתחלה של הניווט.
  • duration: משך הזמן של מסגרת האנימציה הארוכה (לא כולל זמן ההצגה).
  • renderStart: שעת ההתחלה של מחזור הרינדור, שכוללת requestAnimationFrame קריאות חוזרות, חישוב סגנון ופריסה, קריאות חוזרות (callback) של הצופה וצופה הצומת.
  • 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(). שימו לב שבמקרה של הבטחות, כל רכיבי ה-handler של אותן ההבטחות משולבים כ-script אחד).
    • 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
}

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

הפעלת ה-API של מסגרת אנימציה ארוכה

ה-API של 'מסגרות אנימציה ארוכות' מופעל כברירת מחדל ב-Chrome 123.

שימוש ב-Long Animation Frames API בשדה

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

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

תמיכה ב-API של זיהוי תכונות למסגרות אנימציה ארוכות

אפשר להשתמש בקוד הבא כדי לבדוק אם ה-API נתמך:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

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

if ('PerformanceLongAnimationFrameTiming' in window) {
  // Monitor LoAFs
}

דיווח על נתוני אנימציה ארוכה חזרה לנקודת קצה ב-Analytics

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

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 });

במועד המתאים (מומלץ לאירוע visibilitychange) לחזור לניתוח הנתונים. לביצוע בדיקות מקומיות, אפשר להשתמש ב-console.table מדי פעם:

console.table(longestBlockingLoAFs);

קישור לאינטראקציה הארוכה ביותר של INP

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

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

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

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

זיהוי דפוסים נפוצים בפריימים ארוכים של אנימציה

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

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

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

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

אפשר להציג מסגרות אנימציה ארוכות בכלי הפיתוח באמצעות ה-API performance.measure(). ה-API הזה מוצג לאחר מכן במסלול תזמוני המשתמש של DevTools בדוחות הביצועים כדי להראות איפה למקד את המאמצים לשיפור הביצועים:

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 });

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

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

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

שימוש בנתונים של מסגרות אנימציה ארוכות בכלי בדיקה אוטומטיים

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

שאלות נפוצות

הנה כמה מהשאלות הנפוצות בנושא ממשק API זה:

למה לא להרחיב או לחזור על השימוש ב-Long Tasks API?

זוהי בדיקה חלופית לדיווח על מדידה דומה – אבל בסופו של דבר שונה – של בעיות פוטנציאליות של תגובה. חשוב לוודא שאתרים שמסתמכים על ה-Long Tasks API הקיים ימשיכו לפעול כדי להימנע משיבושים בתרחישי השימוש הקיימים.

למרות ש-Long Tasks API עשוי להפיק תועלת מחלק מהתכונות של LoAF (כמו מודל שיוך טוב יותר), אנחנו מאמינים שהתמקדות במסגרות ולא במשימות מעניקה יתרונות רבים, שהופכים את ה-API הזה לשונה במהותו מ-Long Tasks API הקיים.

האם הוא יחליף את ממשק ה-API של משימות ארוכות?

אנחנו מאמינים ש-Long Animation Frames API הוא API טוב יותר ושלם יותר למדידת משימות ארוכות, אבל בשלב זה אנחנו לא מתכננים להוציא משימוש את ממשק ה-API של משימות ארוכות.

דרוש משוב

אפשר לספק משוב ברשימת הבעיות של GitHub, או לדווח על באגים ביישום ה-API של Chrome באתר המעקב אחר בעיות של Chrome.

סיכום

ה-API של ארוך מסגרות האנימציה הוא API חדש ונהדר עם הרבה יתרונות פוטנציאליים בהשוואה ל-Long Tasks API הקודם.

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

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

אישורים

תמונה ממוזערת מאת הנרי בי ב-UnFlood.