واجهة برمجة التطبيقات لإطارات الصور المتحركة الطويلة

واجهة برمجة التطبيقات Long Animation Frames API هي تحديث لواجهة Long Tasks API تهدف إلى توفير فهم أفضل لتحديثات واجهة المستخدم البطيئة. يمكن أن يكون ذلك مفيدًا لتحديد إطارات الصور المتحركة البطيئة التي يُحتمل أن تؤثر في مقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP) الذي يقيس معدّل الاستجابة، أو لتحديد البيانات غير النشطة الأخرى في واجهة المستخدم التي تؤثر في السلاسة.

حالة واجهة برمجة التطبيقات

التوافق مع المتصفح

  • 123
  • x
  • x
  • x

بعد مرحلة التجربة والتقييم من Chrome 116 إلى Chrome 122، تم شحن LoAF API من Chrome 123.

واجهة برمجة التطبيقات "المهام الطويلة"

التوافق مع المتصفح

  • 58
  • 79
  • x
  • x

المصدر

تعد واجهة برمجة التطبيقات طويلة 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 (التي تتضمن عملية تدقيق تجنُّب المهام الطويلة للسلسلة الرئيسية) أو من خلال الاطّلاع على المهام الطويلة في "أدوات مطوري البرامج في Chrome".

غالبًا ما يكون الاختبار المستند إلى المختبر نقطة انطلاق سيئة لتحديد مشاكل الاستجابة، لأنّ هذه الأدوات قد لا تتضمّن التفاعلات. وعندما تفعل ذلك، تكون مجموعة فرعية صغيرة من التفاعلات المحتملة. من الناحية المثالية، يمكنك قياس أسباب التفاعلات البطيئة في المجال.

عيوب واجهة برمجة التطبيقات "long Tasks API"

يمكن أن يكون قياس المهام الطويلة في الميدان باستخدام "أداة مراقبة الأداء" مفيدًا إلى حدٍ ما. في الواقع، لا يوفر هذا القدر الكبير من المعلومات بخلاف حقيقة حدوث مهمة طويلة، والمدة التي استغرقتها.

غالبًا ما تستخدم أدوات مراقبة المستخدم الفعلي (RUM) هذا الإذن لتحديد عدد المهام التي تستغرق وقتًا طويلاً أو مدّتها، أو تحديد الصفحات التي تحدث فيها، ولكن بدون التفاصيل الأساسية لسبب المهمة الطويلة، يتم استخدام هذا الإجراء بشكل محدود فقط. لا تتضمن واجهة برمجة تطبيقات "مهام طويلة" سوى نموذج تحديد مصدر أساسي، والذي يخبرك في أفضل حالاته بالحاوية التي حدثت فيها المهمة الطويلة (مستند المستوى الأعلى أو <iframe>)، وليس النص البرمجي أو الوظيفة التي تم تسميتها، كما هو موضّح في الإدخال النموذجي:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

واجهة برمجة تطبيقات "مهام Google" هي أيضًا عرض غير مكتمل، نظرًا لأنها قد تستبعد أيضًا بعض المهام المهمة. تحدث بعض التعديلات، مثل العرض، في مهام منفصلة يجب تضمينها مع عملية التنفيذ السابقة التي أدّت إلى إجراء هذا التعديل لقياس "إجمالي العمل" لهذا التفاعل بدقة. لمزيد من التفاصيل حول حدود الاعتماد على المهام، راجِع قسم "المراجع التي تستغرق وقتًا طويلاً" في الشرح.

المشكلة الأخيرة هي أن قياس المهام الطويلة تقارير فقط عن المهام الفردية التي تستغرق وقتًا أطول من حد 50 ميلي ثانية. يمكن لإطار الصور المتحركة أن يضم عدة مهام تقل عن 50 ملي ثانية كحدّ أقصى، إلا أنّ هذه المهام تؤدّي مجتمعةً إلى حظر عرض المتصفّح.

واجهة برمجة التطبيقات لإطارات الصور المتحركة الطويل

التوافق مع المتصفح

  • 123
  • x
  • x
  • x

واجهة برمجة التطبيقات Long Animation Frames API هي واجهة برمجة تطبيقات جديدة تهدف إلى معالجة بعض أوجه القصور في واجهة برمجة التطبيقات "long Tasks API" تتيح للمطوّرين الحصول على المزيد من الإحصاءات القابلة للاستخدام للمساعدة في معالجة مشاكل الاستجابة وتحسين INP.

وتعني سرعة الاستجابة أنّ الصفحة تستجيب بسرعة للتفاعلات التي تتم معها. ويشمل ذلك القدرة على رسم أي تحديثات يحتاجها المستخدم في الوقت المناسب، وتجنب منع حدوث هذه التحديثات. بالنسبة إلى مقياس INP، ننصحك بالاستجابة خلال 200 ملّي ثانية أو أقل، ولكن بالنسبة إلى التعديلات الأخرى (مثل الصور المتحركة) التي قد تكون طويلة جدًا،

تُعدّ واجهة برمجة التطبيقات Long Animation Frames API طريقة بديلة لقياس حظر العمل. بدلاً من قياس المهام الفردية، تقيس واجهة برمجة التطبيقات Long Animation Frames API لقطات الصور المتحركة الطويلة، كما يوحي اسمها. الإطار الطويل للصور المتحركة هو عندما يتأخر تحديث العرض لأكثر من 50 ملي ثانية (وهو الحد الأدنى المطلوب لواجهة برمجة تطبيقات "مهام Google" الطويلة).

يمكن ملاحظة إطارات الصور المتحركة الطويلة بالطريقة نفسها التي تتم بها ملاحظة المهام الطويلة التي تتضمّن 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 لإدخالات الأداء، يتم بعد ذلك تجاهل الإدخالات الأحدث، لذلك ننصح باستخدام منهج PerformanceMonitorer. وتم ضبط حجم المخزن المؤقت long-animation-frame على 200، وهذا هو حجم المخزن المؤقت long-tasks.

مزايا النظر إلى الإطارات بدلاً من المهام

الميزة الرئيسية للنظر إلى هذا من منظور الإطار بدلاً من منظور المهام، هي أن الرسوم المتحركة الطويلة يمكن أن تتكون من أي عدد من المهام التي نتجت بشكل تراكمي عن إطار رسوم متحركة طويل. يعالج ذلك النقطة الأخيرة المذكورة سابقًا، والتي من خلالها قد لا يتم عرض مجموع العديد من المهام الأصغر حجمًا والتي تمنع عرض المحتوى قبل إطار الرسوم المتحركة من خلال واجهة برمجة التطبيقات "مهام Google" الطويلة.

تتمثل إحدى المزايا الإضافية لطريقة العرض البديلة هذه للمهام الطويلة، في القدرة على توفير تقسيمات التوقيت للإطار بالكامل. بدلاً من تضمين startTime وduration، مثل واجهة برمجة تطبيقات "مهام Google" الطويلة، يتضمّن LoAF تقسيمًا أكثر تفصيلاً للأجزاء المختلفة لمدة الإطار، بما في ذلك:

  • startTime: وقت بدء إطار الصورة المتحركة الطويل مقارنةً بوقت بدء التنقّل
  • duration: مدة إطار الصورة المتحركة الطويل (لا تشمل وقت العرض التقديمي)
  • renderStart: وقت بدء دورة العرض، والتي تتضمن requestAnimationFrame من عمليات رد الاتصال، وحساب النمط والتنسيق، ومراقب تغيير الحجم، وعمليات استدعاء مراقب التقاطع.
  • styleAndLayoutStart: بداية الفترة الزمنية المُستغرقة في العمليات الحسابية للأنماط والتنسيقات.
  • firstUIEventTimestamp: وقت أول حدث لواجهة المستخدم (الماوس/لوحة المفاتيح، وما إلى ذلك) الذي يتم التعامل معه أثناء عرض هذا الإطار.
  • 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 بيانات تحديد مصدر أفضل لكل نص برمجي ساهمت في إنشاء إطار رسوم متحركة طويل.

على غرار واجهة برمجة تطبيقات "مهام Google" الطويلة، سيتم تقديم هذه الواجهة في مجموعة من إدخالات تحديد المصدر، على أن يكون لكل إدخال التفاصيل التالية:

  • ستعرض name وEntryType كلاهما script.
  • تمثّل هذه السمة invoker مفيدة، وتشير إلى طريقة استدعاء النص البرمجي (على سبيل المثال، 'IMG#id.onload' أو 'Window.requestAnimationFrame' أو 'Response.json.then').
  • invokerType لنقطة إدخال النص البرمجي:
    • user-callback: رد اتصال معروف تم تسجيله من واجهة برمجة تطبيقات للمنصّة على الويب (على سبيل المثال، 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 123.

استخدام واجهة برمجة التطبيقات Long Animation Frames في الحقل

إنّ أدوات مثل Lighthouse مفيدة في اكتشاف المشاكل وإعادة إنتاجها، وهي أدوات معملية قد تفتقد جوانب مهمة من تجربة المستخدم لا يمكن أن توفّرها سوى البيانات الميدانية. يمكن استخدام واجهة برمجة التطبيقات Long Animation Frames API في الميدان لجمع البيانات السياقية المهمة لتفاعلات المستخدمين التي لا يمكن لواجهة برمجة تطبيقات "مهام طويلة" الوصول إليها. يمكن أن يساعدك ذلك في اكتشاف المشاكل التي لم تكتشفها بطريقة أخرى، وتساهم في إعادة إنتاجها.

فيما يلي بعض الإستراتيجيات المقترحة، إلا أن فريق Chrome حريص على معرفة التعليقات حول واجهة برمجة التطبيقات هذه وكيف يرى المطورون وموفرو RUM أنفسهم باستخدام المعلومات التي توفرها واجهة برمجة التطبيقات.

ميزة ترصد دعم واجهة برمجة التطبيقات لإطارات الصور المتحركة الطويل

يمكنك استخدام الرمز التالي لاختبار ما إذا كانت واجهة برمجة التطبيقات متوافقة:

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

يمكن استخدام البديل التالي في هذه الحالة بينما لا تكون إطارات الصور المتحركة الطويلة غير متوافقة بعد بشكل تلقائي وهي في حالة الانتقال هذه:

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

الإبلاغ عن بيانات الصور المتحركة الطويلة وإعادتها إلى نقطة نهاية الإحصاءات

إنّ إدخال أداء LoAF يتضمّن معلومات قيّمة، كما هو موضّح. تتمثل إحدى الإستراتيجيات في مراقبة جميع نماذج LoAFs وإحالة تلك التي تتجاوز حدًا معينًا إلى نقطة نهاية التحليلات لتحليلها لاحقًا:

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.

لا تتوفّر حاليًا واجهة برمجة تطبيقات مباشرة لربط إدخال 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 في الأدوات

ويمكن أن تسمح واجهة برمجة التطبيقات أيضًا باستخدام أدوات إضافية للمطوّرين لتصحيح الأخطاء المحلية. جمعت بعض الأدوات، مثل Lighthouse وChrome DevTools، الكثير من هذه البيانات باستخدام تفاصيل تتبُّع منخفضة المستوى، إلا أنّ استخدام واجهة برمجة تطبيقات ذات مستوى أعلى قد يسمح لأدوات أخرى بالوصول إلى هذه البيانات.

عرض بيانات اللقطات المتحركة الطويلة في "أدوات مطوري البرامج"

يمكنك عرض إطارات الصور المتحركة الطويلة في "أدوات مطوري البرامج" باستخدام واجهة برمجة التطبيقات 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 });

وإذا ثبتت فائدة واجهة برمجة التطبيقات هذه على المدى الطويل، من المحتمل أن يتم دمجها في "أدوات مطوّري البرامج" نفسها، ولكن مقتطف الرمز السابق يسمح بعرضها في تلك الأدوات في الوقت الحالي.

استخدام بيانات إطارات الصور المتحركة الطويلة في أدوات المطوّرين الأخرى

أظهرت إضافة "مؤشرات أداء الويب" القيمة في معلومات تصحيح الأخطاء الخاصة بملخّص التسجيل من أجل تشخيص مشاكل الأداء. بعد إطلاق واجهة برمجة التطبيقات، يمكن لأدوات مثل هذه عرض البيانات بسهولة أكبر لمساعدتهم في إطلاع المطوّرين على الجوانب التي يجب تركيز جهودهم عليها. ونخطّط أيضًا لإضافة هذه الميزة إلى مكتبة JavaScript لـ "مؤشرات أداء الويب" في الإصدار 4.

استخدام بيانات إطارات الصور المتحركة الطويلة في أدوات الاختبار الآلية

وبالمثل، يمكن لأدوات الاختبار التلقائية، ربما في مسارات CI/CD، أن تعرض تفاصيل حول مشاكل الأداء المحتملة عن طريق قياس إطارات الصور المتحركة الطويلة أثناء تشغيل مجموعات اختبار مختلفة.

الأسئلة الشائعة

من بين الأسئلة الشائعة حول واجهة برمجة التطبيقات هذه ما يلي:

لماذا لا تكتفي بتوسيع نطاق واجهة برمجة تطبيقات "مهام Google" أو تكرارها؟

هذه نظرة بديلة للإبلاغ عن مقياس مشابه، ولكن مختلف في النهاية، لمشاكل الاستجابة المحتملة. من المهم التأكّد من استمرار عمل المواقع الإلكترونية التي تعتمد على واجهة برمجة تطبيقات "مهام طويلة" الحالية لتجنُّب إيقاف حالات الاستخدام الحالية.

على الرغم من أنّ واجهة برمجة تطبيقات "مهام طويلة" قد تستفيد من بعض ميزات LoAF (مثل نموذج تحديد مصدر أفضل)، نعتقد أنّ التركيز على الإطارات بدلاً من المهام يوفّر العديد من المزايا التي تجعل من هذه الواجهة واجهة برمجة تطبيقات مختلفة تمامًا عن واجهة برمجة التطبيقات "مهام طويلة" الحالية.

هل سيحل ذلك محل واجهة برمجة تطبيقات "مهام Google" الطويلة؟

نحن نعتقد أنّ واجهة برمجة التطبيقات Long Animation Frames API أفضل وأكثر اكتمالاً لقياس المهام الطويلة، إلا أنّه في الوقت الحالي لا تتوفّر أي خطط لإيقاف واجهة برمجة التطبيقات "long Tasks API" نهائيًا.

مطلوب إرسال ملاحظات

يمكن تقديم الملاحظات من خلال قائمة مشاكل GitHub، أو يمكن تسجيل الأخطاء في تنفيذ Chrome لواجهة برمجة التطبيقات في أداة تتبّع المشاكل في Chrome.

الخلاصة

واجهة برمجة التطبيقات Long Animation Frames API هي واجهة برمجة تطبيقات جديدة ومثيرة ذات العديد من المزايا المحتملة عن واجهة برمجة التطبيقات "long Tasks API" السابقة.

وهو يثبت أنّه أداة رئيسية لمعالجة مشاكل الاستجابة وفق معايير "مدى استجابة الصفحة لتفاعلات المستخدم" (INP). ويشكّل مقياس INP مقياسًا صعبًا لتحسين الأداء، وتشكّل واجهة برمجة التطبيقات هذه إحدى الطرق التي يسعى فريق Chrome من خلالها إلى تسهيل عملية تحديد المشاكل وحلّها للمطوّرين.

مع ذلك، إنّ نطاق واجهة برمجة التطبيقات Long Animation Frames API يمتد إلى ما هو أبعد من مقياس INP فقط، ويمكن أن يساعد في تحديد الأسباب الأخرى لبطء التحديثات التي قد تؤثر في سلاسة تجربة المستخدم على الموقع الإلكتروني بشكل عام.

شكر وتقدير

صورة مصغّرة من هنري بي في UnLaunch.