Long Animation Frames API

Barry Pollard

Noam Rosenthal

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 : زمان اولین رویداد رابط کاربری (موس/صفحه کلید و غیره) که در طول این فریم مدیریت می شود.
• blockingDuration : مدت زمانی بر حسب میلی ثانیه که فریم انیمیشن مسدود شده است.

این مُهرهای زمانی اجازه می‌دهند که فریم طولانی انیمیشن به زمان‌بندی تقسیم شود:

برای جزئیات بیشتر در مورد این زمان‌بندی‌های فردی، به توضیح‌دهنده مراجعه کنید ، که جزئیات دقیقی را در مورد اینکه کدام فعالیت به یک قاب انیمیشن طولانی کمک می‌کند، ارائه می‌دهد.

انتساب بهتر

نوع ورودی 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 در این زمینه استفاده کنید

ا��زارهایی مانند Chrome DevTools و Lighthouse - اگرچه برای کشف و بازتولید مسائل مفید هستند - ابزارهای آزمایشگاهی هستند که ممکن است جنبه‌های مهم تجربه کاربر را که فقط داده‌های میدانی می‌توانند ارائه کنند، از دست بدهند.

Long Animation Frames API طراحی شده است تا در میدان مورد استفاده قرار گیرد تا داده‌های زمینه‌ای مهم برای تعاملات کاربر را جمع‌آوری کند که Long Tasks API قادر به انجام آن نبود. این می تواند به شما در شناسایی و بازتولید مسائلی با تعامل که ممکن است در غیر این صورت کشف نمی کردید، کمک کند.

قابلیت شناسایی Long Animation Frames 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 میلی ثانیه یا کمتر از زمان تعامل تا زمانی که فریم نقاشی شود پاسخ داده می شود، و از آنجایی که Long Animation Frames API تمام فریم هایی را که 50 میلی ثانیه یا بیشتر طول می کشند اندازه گیری می کند، اکثر INP های مشکل ساز باید شامل داده های LoAF باشند تا به شما در تشخیص کمک کنند. آن فعل و انفعالات

"INP LoAF" LoAF است که شامل تعامل INP است، همانطور که در نمودار زیر نشان داده شده است:

در برخی موارد ممکن است که یک رویداد INP دو LoAF را در بر بگیرد—معمولاً اگر این تعامل پس از شروع بخش رندر فریم قبلی توسط فریم اتفاق بیفتد، و بنابراین کنترل کننده رویداد که در فریم بعدی پردازش می‌کند:

حتی ممکن است در برخی شرایط نادر، بیش از دو LoAF را در بر گیرد.

ثبت داده‌های LoAF(های) مرتبط با تعامل INP به شما امکان می‌دهد اطلاعات بیشتری در مورد تعامل INP برای کمک به تشخیص آن به دست آورید. این به ویژه برای درک تاخیر ورودی مفید است: همانطور که می بینید چه اسکریپت های دیگری در آن فریم اجرا می شدند.

همچنین درک مدت زمان پردازش غیرقابل توضیح و تأخیر ارائه می‌تواند مفید باشد اگر کنترل‌کننده‌های رویداد شما مقادیری را که برای آن‌ها مشاهده می‌شود بازتولید نمی‌کنند، زیرا ممکن است اسکریپت‌های دیگری برای کاربران شما در حال اجرا باشند که ممکن است در آزمایش خود شما لحاظ نشده باشند.

هیچ API مستقیمی برای پیوند دادن یک ورودی INP با ورودی یا ورودی های LoAF مربوط به آن وجود ندارد، اگرچه می توان این کار را به صورت کد با مقایسه زمان شروع و پایان هر کدام انجام داد (به اسکریپت مثال WhyNp مراجعه کنید).

کتابخانه web-vitals شامل تمام LoAF های متقاطع در ویژگی longAnimationFramesEntries رابط انتساب INP از نسخه 4 است.

هنگامی که ورودی یا ورودی های LoAF را پیوند دادید، می توانید اطلاعاتی را با انتساب INP اضافه کنید. شی scripts حاوی برخی از ارزشمندترین اطلاعات است، زیرا می تواند نشان دهد که چه چیز دیگری در آن فریم ها در ��ال اجرا است، بنابراین بازگرداندن آن داده ها به سرویس تجزیه و تحلیل شما به شما این امکان را می دهد که بیشتر در مورد چرایی کندی تعاملات درک کنید.

گزارش LoAF ها برای تعامل INP راه خوبی برای یافتن مهم ترین مسائل تعاملی در صفحه شما است. هر کاربر ممکن است با صفحه شما تعامل مت��اوتی د��شته باشد و با حجم کافی از داده های انتساب INP، تعدادی از مشکلات احتمالی در داده های انتساب INP گنجانده می شود. این به شما امکان می دهد اسکریپت ها را بر اساس حجم مرتب کنید تا ببینید کدام اسکریپت با INP کند مرتبط است.

داده های انیمیشن طولانی تر را به نقطه پایانی تجزیه و تحلیل گزارش دهید

یکی از نکات منفی نگاه کردن به LoAF(های) INP این است که ممکن است سایر زمینه‌های بالقوه را برای بهبودهایی که ممکن است باعث مشکلات INP در آینده شود از دست بدهید. این می‌تواند منجر به احساس تعقیب دنبال خود شود، جایی که مشکل INP را برطرف می‌کنید و انتظار دارید پیشرفت بزرگی را مشاهده کنید، فقط برای یافتن اینکه کندترین تعامل بعدی فقط مقدار کمی بهتر از آن است، بنابراین INP شما بهبود چندانی نمی‌یابد.

بنابراین به جای اینکه فقط به INP LoAF توجه کنید، ممکن است بخواهید همه LoAF ها را در طول عمر صفحه در نظر بگیرید:

با این حال، هر ورودی LoAF حاوی داده‌های قابل‌توجهی است، بنابراین احتمالاً نمی‌خواهید همه آن را به عقب برگردانید. در عوض، می‌خواهید تحلیل خود را به برخی از LoAFs یا برخی داده‌ها محدود کنید.

برخی از الگوهای پیشنهادی عبارتند از:

• فریم های طولانی انیمیشن را با تعامل مشاهده کنید
• فریم های انیمیشن را طولانی تر از یک آستانه خاص مشاهده کنید
• بدترین فریم های طولانی انیمیشن را مشاهده کنید
• الگوهای رایج در فریم های انیمیشن بلند را شناسایی کنید

اینکه کدام یک از این الگوها برای شما بهتر عمل می‌کند، بستگی به این دارد که چقدر در مسیر بهینه‌سازی شما قرار گرفته‌اید و فریم‌های انیمیشن طولانی چقدر رایج هستند. برای سایتی که قبلاً هرگز برای پاسخگویی بهینه سازی نشده است، ممکن است 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 ها را زیر نظر داشته باشیم و آنهایی که بیشتر از یک آستانه مشخص هستند را به نقطه پایانی تجزیه و تحلیل برای تجزیه و تحلیل بعدی بازگردانیم:

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

و مثال این خروجی این است:

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

در درازمدت، احتمالاً در خود DevTools گنجانده می‌شود، اما قطعه کد قبلی اجازه می‌دهد تا در این مدت در آنجا ظاهر شود.

از داده‌های فریم‌های انیمیشن طولانی در سایر ابزارهای توسعه‌دهنده استفاده کنید

برنامه افزودنی Web Vitals ارزش ثبت خلاصه اطلاعات اشکال زدایی را برای تشخیص مشکلات عملکرد نشان داده است .

اکنون همچنین داده های فریم انیمیشن طولانی را برای هر تماس INP و هر تعامل نشان می دهد:

از داده های فریم های انیمیشن طولانی در ابزارهای تست خودکار استفاده کنید

به طور مشابه، ابزارهای تست خودکار در خطوط لوله CI/CD می‌توانند با اندازه‌گیری فریم‌های طولانی انیمیشن در حین اجرای مجموعه‌های آزمایشی مختلف، جزئیات مربوط به مشکلات عملکرد بالقوه را نشان دهند.

سوالات متداول

برخی از سوالات متداول در مورد این API عبارتند از:

چرا روی Long Tasks API فقط تمدید یا تکرار نمی شود؟

این یک نگاه جایگزین برای گزارش یک اندازه گیری مشابه – اما در نهایت متفاوت – از مسائل احتمالی پاسخگویی است. مهم است که اطمینان حاصل شود که سایت‌های متکی به Long Tasks API موجود به کار خود ادامه می‌دهند تا از ایجاد اختلال در موارد استفاده موجود جلوگیری شود.

در حالی که Long Tasks API ممکن است از برخی از ویژگی‌های LoAF (مانند یک مدل انتساب بهتر) بهره مند شود، ما معتقدیم که تمرکز بر فریم‌ها به جای وظایف، مزایای زیادی را ارائه می‌کند که این API را اساساً متفاوت از Long Tasks API موجود می‌سازد.

چرا ورودی های اسکریپت ندارم؟

این ممکن است نشان دهد که فریم طولانی انیمیشن به دلیل جاوا اسکپت نیست، بلکه به دلیل کار رندر بزرگ است.

این همچنین می تواند زمانی اتفاق بیفتد که فریم طولانی انیمیشن به دلیل جاوا اسکریپت باشد ، اما به دلایل مختلف حفظ حریم خصوصی همانطور که قبلا ذکر شد (در درجه اول اینکه جاوا اسکریپت متعلق به صفحه نیست) نمی توان انتساب اسکریپت را ارائه کرد.

چرا ورودی های اسکریپت دارم اما اطلاعات منبعی ندارم یا محدود است؟

این ممکن است به دلایل مختلفی اتفاق بیفتد، از جمله اینکه منبع خوبی برای اشاره وجود ندارد .

اطلاعات اسکریپت همچنین برای اسکریپت‌های no-cors cross-origin محدود خواهد بود، اگرچه این مشکل را می‌توان با واکشی آن اسکریپت‌ها با استفاده از CORS با افزودن crossOrigin = "anonymous" به تماس <script> حل کرد.

به عنوان مثال، اسکریپت پیش فرض Google Tag Manager برای افزودن به صفحه:

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->

می توان آن را برای افزودن j.crossOrigin = "anonymous" بهبود بخشید تا امکان ارائه جزئیات اسناد کامل برای GTM فراهم شود.

آیا این جایگزین 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 است، و می تواند به شناسایی دلایل دیگر به روز رسانی کند کمک کند که می تواند بر روان بودن کلی تجربه کاربری یک وب سایت تأثیر بگذارد.

قدردانی

تصویر کوچک توسط هنری بی در Unsplash .