Long Animation Frames API (LoAF - تلفظ Lo-Af) بهروزرسانی Long Tasks API است تا درک بهتری از بهروزرسانیهای رابط کاربر آهسته (UI) ارائه دهد. این میتواند برای شناسایی فریمهای پویانمایی آهسته که احتمالاً بر معیار Interaction to Next Paint (INP) Core Web Vital که میزان پاسخدهی را اندازهگیری میکند، تأثیر میگذارد، یا برای شناسایی سایر جابهجاییهای رابط کاربری که بر صافی تأثیر میگذارند، مفید باشد.
وضعیت API
پس از آزمایش اولیه از Chrome 116 به Chrome 122 ، LoAF API از Chrome 123 ارسال شد.
Long Tasks API
Long Animation Frames API جایگزینی برای Long Tasks API است که مدتی است (از Chrome 58) در Chrome موجود است. همانطور که از نامش پیداست، Long Task API به شما اجازه می دهد تا کارهای طولانی را نظارت کنید، کارهایی که رشته اصلی را برای 50 میلی ثانیه یا بیشتر اشغال می کنند. کارهای طولانی را می توان با استفاده از رابط PerformanceLongTaskTiming
، با PeformanceObserver
مانیتور کرد:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'longtask', buffered: true });
کارهای طولانی احتمالا باعث مشکلات پاسخگویی می شوند. اگر کاربر سعی کند با یک صفحه تعامل داشته باشد - به عنوان مثال، روی یک دکمه کلیک کند یا یک منو باز کند - اما موضوع اصلی در حال حاضر با یک کار طولانی سروکار دارد، در این صورت تعامل کاربر در انتظار تکمیل آن کار به تاخیر می افتد .
برای بهبود پاسخگویی، اغلب توصیه می شود کارهای طولانی را از بین ببرید . اگر هر کار طولانی به جای آن به مجموعه ای از وظایف متعدد و کوچکتر تقسیم شود، ممکن است اجازه دهد تا وظایف مهم تری در بین آنها اجرا شود تا از تأخیر قابل توجه در پاسخگویی به تعاملات جلوگیری شود.
بنابراین هنگام تلاش برای بهبود پاسخگویی، اولین تلاش اغلب اجرای یک ردیابی عملکرد و بررسی وظایف طولانی است. این میتواند از طریق یک ابزار ممیزی مبتنی بر آزمایشگاه مانند Lighthouse (که دارای ممیزی از کارهای طولانی رشته اصلی اجتناب شود )، یا با مشاهده کارهای طولانی در ابزار توسعه کروم باشد.
آزمایش مبتنی بر آزمایشگاه اغلب محل شروع ضعیفی برای شناسایی مسائل مربوط به پاسخگویی است، زیرا این ابزارها ممکن است شامل تعاملات نباشند—در صورت وجود، زیرمجموعه کوچکی از تعاملات احتمالی هستند. در حالت ایدهآل، میتوانید دلایل کندی تعاملات را در این زمینه اندازهگیری کنید.
کاستی های Long Tasks API
اندازهگیری کارهای طولانی در میدان با استفاده از مشاهدهگر عملکرد فقط تا حدودی مفید است. در واقع، اطلاعات زیادی فراتر از این که یک کار طولانی اتفاق افتاده است، و اینکه چقدر طول کشیده است، نمی دهد.
ابزارهای نظارت بر کاربر واقعی (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": ""
}
]
}
Long Tasks API نیز یک نمای ناقص است، زیرا ممکن است برخی از وظایف مهم را نیز حذف کند. برخی بهروزرسانیها - مانند رندر کردن - در وظایف جداگانهای اتفاق میافتند که در حالت ایدهآل باید همراه با اجرای قبلی گنجانده شوند که باعث شد آن بهروزرسانی بهدقت «کل کار» آن تعامل را اندازهگیری کند. برای جزئیات بیشتر در مورد محدودیتهای تکیه بر وظایف، به بخش «جایی که کارهای طولانی کوتاه میآیند» توضیحدهنده مراجعه کنید.
مسئله نهایی این است که اندازه گیری کارهای طولانی فقط در مورد کارهای فردی گزارش می دهد که بیش از حد مجاز 50 میلی ثانیه طول می کشد. یک فریم انیمیشن میتواند از چندین کار زیر این حد 50 میلیثانیه تشکیل شود، اما در مجموع هنوز توانایی مرورگر را برای رندر کردن مسدود میکند.
Long Animation Frames API
Long Animation Frames API (LoAF) یک API جدید است که به دنبال رفع برخی از کاستیهای Long Tasks API است تا توسعهدهندگان را قادر سازد تا بینشهای عملیتری برای کمک به رفع مشکلات پاسخگویی و بهبود INP به دست آورند.
پاسخگویی خوب به این معنی است که یک صفحه به سرعت به تعاملات ایجاد شده با آن پاسخ می دهد. این شامل این می شود که بتوانید هر به روز رسانی مورد نیاز کاربر را به موقع رنگ آمیزی کنید و از مسدود کردن این به روز رسانی ها جلوگیری کنید. برای INP، توصیه میشود در 200 میلیثانیه یا کمتر پاسخ دهید ، اما برای بهروزرسانیهای دیگر (مثلاً انیمیشنها) حتی ممکن است خیلی طولانی باشد.
Long 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
.
مزایای نگاه کردن به فریم ها به جای وظایف
مزیت اصلی نگاه کردن به این موضوع از منظر فریم و نه از منظر وظایف، این است که یک انیمیشن طولانی میتواند از هر تعداد کار تشکیل شود که در مجموع به یک فریم انیمیشن طولانی منجر شود. این به آخرین نکتهای که قبلاً اشاره شد، میپردازد، جایی که مجموع بسیاری از کارهای کوچکتر و مسدودکننده رندر قبل از یک فریم انیمیشن ممکن است توسط Long Tasks API ظاهر نشود.
مزیت دیگر این نمای جایگزین در کارهای طولانی، توانایی ارائه زمان بندی خرابی کل فریم است. LoAF به جای اینکه فقط یک startTime
و یک duration
شامل شود، مانند Long Tasks API، شامل تفکیک بسیار دقیق تری از بخش های مختلف مدت زمان فریم است، از جمله:
-
startTime
: زمان شروع قاب طولانی انیمیشن نسبت به زمان شروع ناوبری. -
duration
: مدت زمان فریم طولانی انیمیشن (بدون احتساب زمان ارائه). -
renderStart
: زمان شروع چرخه رندر، که شامل پاسخ تماسهایrequestAnimationFrame
، محاسبه سبک و طرحبندی، تغییر اندازه ناظر و تماسهای ناظر تقاطع است. -
styleAndLayoutStart
: آغاز دوره زمانی صرف شده در محاسبات سبک و چیدمان. -
firstUIEventTimestamp
: زمان اولین رویداد UI (ماوس/صفحه کلید و غیره) که در طول این فریم مدیریت می شود. -
blockingDuration
: مدت زمانی که فریم انیمیشن مسدود شده بود بر حسب میلی ثانیه.
این مُهرهای زمانی اجازه میدهند که فریم طولانی انیمیشن به زمانبندی تقسیم شود:
زمان سنجی | محاسبه |
---|---|
زمان شروع | startTime |
زمان پایان | startTime + duration |
مدت زمان کار | renderStart ? renderStart - startTime : duration |
مدت زمان رندر | renderStart ? (startTime + duration) - renderStart: 0 |
رندر: مدت زمان قبل از طرح | styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0 |
رندر: مدت زمان سبک و چیدمان | styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0 |
برای جزئیات بیشتر در مورد این زمانبندیهای فردی، به توضیحدهنده مراجعه کنید ، که جزئیات دقیقی را در مورد اینکه کدام فعالیت به یک قاب انیمیشن طولانی کمک میکند، ارائه میدهد.
انتساب بهتر
نوع ورودی long-animation-frame
شامل داده های اسناد بهتر هر اسکریپت است که به یک قاب انیمیشن طولانی کمک می کند.
مشابه با Long Tasks API، این مورد در آرایهای از ورودیهای انتساب ارائه میشود که هر کدام به شرح زیر است:
- یک
name
وEntryType
هر دوscript
را برمیگردانند. - یک
invoker
معنادار، که نشان میدهد چگونه اسکریپت فراخوانی شده است (به عنوان مثال،'IMG#id.onload'
،'Window.requestAnimationFrame'
یا'Response.json.then'
). -
invokerType
نقطه ورود اسکریپت:-
user-callback
: یک پاسخ تماس شناخته شده ثبت شده از یک API پلتفرم وب (به عنوان مثال،setTimeout
،requestAnimationFrame
). -
event-listener
: شنونده یک رویداد پلتفرم (مثلاًclick
،load
،keyup
). -
resolve-promise
: Handler یک وعده پلتفرم (مثلاfetch()
. توجه داشته باشید که در مورد وعدهها، همه کنترلکنندههای همان وعدهها به عنوان یک «اسکریپت» با هم ترکیب میشوند).
-
reject-promise
: طبقresolve-promise
، اما برای رد. -
classic-script
: ارزیابی اسکریپت (به عنوان مثال،<script>
یاimport()
) -
module-script
: همانندclassic-script
، اما برای اسکریپت های ماژول.
-
- داده های زمان بندی را برای آن اسکریپت جدا کنید:
-
startTime
: زمانی که تابع ورودی فراخوانی شد. -
duration
: مدت زمان بینstartTime
و زمانی که پردازش صف ریز وظیفه بعدی به پایان رسید. -
executionStart
: زمان پس از کامپایل. -
forcedStyleAndLayoutDuration
: کل زمان صرف شده برای پردازش طرح/سبک اجباری در داخل این تابع (به thrashing مراجعه کنید). -
pauseDuration
: کل زمان صرف شده در "مکث" عملیات همزمان (هشدار، XHR همزمان).
-
- جزئیات منبع اسکریپت:
-
sourceURL
: نام منبع اسکریپت در صورت وجود (یا خالی در صورت یافت نشدن). -
sourceFunctionName
: نام تابع اسکریپت که در دسترس است (یا خالی اگر یافت نشد). -
sourceCharPosition
: موقعیت کاراکتر اسکریپت در صورت موجود بودن (یا -1 در صورت یافت نشدن).
-
-
windowAttribution
: محفظه (سند سطح بالا، یا یک<iframe>
) که قاب انیمیشن طولانی در آن قرار دارد. -
window
: ارجاع به پنجره همان منبع.
در صورت ارائه، ورودیهای منبع به توسعهدهندگان اجازه میدهد تا دقیقاً بدانند که هر اسکریپت در قاب طولانی انیمیشن چگونه فراخوانی شده است، تا موقعیت کاراکتر در اسکریپت فراخوان. این مکان دقیق را در یک منبع جاوا اسکریپت نشان می دهد که منجر به قاب طولانی انیمیشن می شود.
نمونهای از ورودی اجرای 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
Long Animation Frames API به طور پیش فرض از Chrome 123 فعال شده است.
استفاده از Long Animation Frames API در این زمینه
ابزارهایی مانند Lighthouse - اگرچه برای کشف و بازتولید مسائل مفید هستند - ابزارهای آزمایشگاهی هستند که ممکن است جنبههای مهم تجربه کاربر را که فقط دادههای میدانی میتوانند ارائه کنند، از دست بدهند. Long Animation Frames API را می توان در این زمینه برای جمع آوری داده های زمینه ای مهم برای تعاملات کاربر که Long Tasks API نمی توانست استفاده کرد. این می تواند به شما کمک کند تا مسائلی را با تعاملی که ممکن است در غیر این صورت کشف نکرده باشید، آشکار و بازتولید کنید.
برخی از استراتژیهای پیشنهادی در ادامه فهرست میشوند، اما تیم Chrome مشتاق شنیدن بازخورد در مورد این API و نحوه استفاده توسعهدهندگان و ارائهدهندگان RUM از اطلاعاتی است که API ارائه میدهد.
قابلیت شناسایی Long Animation Frames API
برای بررسی اینکه آیا API پشتیبانی می شود می توانید از کد زیر استفاده کنید:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
// Monitor LoAFs
}
در حالی که فریمهای انیمیشن طولانی هنوز به طور پیشفرض پشتیبانی نمیشوند و در این حالت انتقال هستند، میتوان از جایگزین زیر در این مورد استفاده کرد:
if ('PerformanceLongAnimationFrameTiming' in window) {
// Monitor LoAFs
}
گزارش داده های انیمیشن طولانی به نقطه پایانی تجزیه و تحلیل
همانطور که نشان داده شده است، ورودی عملکرد LoAF شامل اطلاعات ارزشمندی است. یک استراتژی این است که همه LoAF ها را زیر نظر داشته باشیم و آنهایی که بالاتر از یک آستانه مشخص هستند را به نقطه پایانی تجزیه و تحلیل برای تجزیه و تحلیل بعدی بازگردانیم:
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ها، فریم(های) LoAF مربوط به ورودی INP می تواند به عنوان داده انتساب برای ارائه جزئیات بیشتر در مورد چگونگی بهبود INP استفاده شود.
در حال حاضر هیچ API مستقیمی برای پیوند دادن یک ورودی INP با ورودی یا ورودی های LoAF مربوط به آن وجود ندارد، اگرچه می توان این کار را به صورت کد با مقایسه زمان شروع و پایان هر یک انجام داد (به این اسکریپت مثال مراجعه کنید).
گزارش فریم های طولانی انیمیشن با تعامل
یک رویکرد جایگزین که نیاز به کد کمتری دارد، ارسال همیشه بزرگترین (یا X بزرگترین) ورودیهای LoAF در جایی که یک تعامل در طول فریم رخ میدهد (که میتواند با وجود یک مقدار 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 DevTools توانستهاند بسیاری از این دادهها را با استفاده از جزئیات ردیابی سطح پایینتر جمعآوری کنند، داشتن این API سطح بالاتر میتواند به ابزارهای دیگر اجازه دسترسی به این دادهها را بدهد.
نمایش داده های فریم های طولانی انیمیشن در DevTools
میتوانید با استفاده از API performance.measure()
فریمهای انیمیشن طولانی را در DevTools نشان دهید، که سپس در مسیر زمانبندی کاربر 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 در بلندمدت مفید باشد، احتمالاً در خود DevTools گنجانده میشود، اما قطعه کد قبلی به آن اجازه میدهد تا در این مدت در آنجا ظاهر شود.
استفاده از دادههای فریمهای انیمیشن طولانی در سایر ابزارهای توسعهدهنده
برنامه افزودنی Web Vitals ارزش ثبت خلاصه اطلاعات اشکال زدایی را برای تشخیص مشکلات عملکرد نشان داده است . اکنون API راهاندازی شده است، ابزارهایی مانند آن میتوانند به راحتی دادهها را بهدست آورند تا به توسعهدهندگان کمک کنند تا تلاشهای خود را کجا متمرکز کنند. همچنین قصد داریم این را به کتابخانه جاوا اسکریپت حیاتی وب در نسخه 4 اضافه کنیم.
استفاده از داده های فریم های انیمیشن طولانی در ابزارهای تست خودکار
ابزارهای تست خودکار مشابه، شاید در خطوط لوله CI/CD، می توانند جزئیات مربوط به مشکلات عملکرد بالقوه را با اندازه گیری فریم های طولانی انیمیشن در حین اجرای مجموعه های آزمایشی مختلف نشان دهند.
سوالات متداول
برخی از سوالات متداول در مورد این API عبارتند از:
چرا روی Long Tasks API فقط تمدید یا تکرار نمی شود؟
این یک نگاه جایگزین به گزارش یک اندازه گیری مشابه – اما در نهایت متفاوت – از مسائل احتمالی پاسخگویی است. مهم است که اطمینان حاصل شود که سایتهای متکی به Long Tasks API به کار خود ادامه میدهند تا از ایجاد اختلال در موارد استفاده موجود جلوگیری شود.
در حالی که Long Tasks API ممکن است از برخی از ویژگیهای LoAF (مانند یک مدل انتساب بهتر) بهره مند شود، ما معتقدیم که تمرکز بر فریمها به جای وظایف، مزایای زیادی را ارائه میکند که این API را اساساً متفاوت از Long Tasks API موجود میسازد.
آیا این جایگزین Long Tasks API خواهد شد؟
در حالی که ما معتقدیم Long Animation Frames API API بهتر و کاملتری برای اندازهگیری کارهای طولانی است، در حال حاضر، هیچ برنامهای برای منسوخ کردن Long Tasks API وجود ندارد.
بازخورد می خواستم
بازخورد را می توان در لیست مشکلات GitHub ارائه کرد، یا اشکالات در اجرای Chrome از API را می توان در ردیاب مشکل کروم ثبت کرد.
نتیجه
Long Animation Frames API یک API جدید و هیجان انگیز با مزایای بالقوه زیادی نسبت به Long Tasks API قبلی است.
ثابت شده است که این یک ابزار کلیدی برای رسیدگی به مسائل مربوط به پاسخگویی است که توسط INP اندازه گیری می شود. INP معیاری چالش برانگیز برای بهینه سازی است و این API راهی است که تیم Chrome به دنبال تسهیل شناسایی و رسیدگی به مشکلات برای توسعه دهندگان است.
دامنه Long Animation Frames API فراتر از فقط INP است، و می تواند به شناسایی دلایل دیگر به روز رسانی کند کمک کند که می تواند بر روان بودن کلی تجربه کاربری یک وب سایت تأثیر بگذارد.