लंबे ऐनिमेशन फ़्रेम एपीआई

Barry Pollard
Noam Rosenthal

लॉन्ग ऐनिमेशन फ़्रेम एपीआई (LoAF - इसका मतलब है Lo-Af), Long Tasks API का एक अपडेट है. इससे यूज़र इंटरफ़ेस (यूआई) के धीमे अपडेट को बेहतर तरीके से समझने में मदद मिलती है. यह ऐसे धीमे ऐनिमेशन फ़्रेम की पहचान करने के लिए काम का हो सकता है जो इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) की वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक पर असर डाल सकते हैं. यह मेट्रिक, रिस्पॉन्स को मेज़र करने के लिए या स्मूदनेस पर असर डालने वाले यूआई के जैंक की पहचान करती है.

एपीआई की स्थिति

ब्राउज़र सहायता

  • 123
  • x
  • x
  • x

Chrome 116 से Chrome 122 तक का ऑरिजिन ट्रायल करने के बाद, LoAF API को Chrome 123 से शिप कर दिया गया है.

लंबे Tasks एपीआई

ब्राउज़र सहायता

  • 58
  • 79
  • x
  • x

सोर्स

लांग ऐनिमेशन फ़्रेम एपीआई, लांग Tasks एपीआई का एक विकल्प है. यह सुविधा Chrome में कुछ समय से (Chrome 58 के बाद से) उपलब्ध है. जैसा कि इसके नाम से ही पता चलता है, लॉन्ग टास्क एपीआई से लंबे टास्क मॉनिटर किए जा सकते हैं. ये टास्क ऐसे टास्क होते हैं जो 50 मिलीसेकंड या उससे ज़्यादा समय तक मुख्य थ्रेड में शामिल होते हैं. PerformanceLongTaskTiming इंटरफ़ेस का इस्तेमाल करके, लंबे टास्क की निगरानी की जा सकती है. इसके लिए, PeformanceObserver का इस्तेमाल करें:

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

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

लंबे टास्क पूरे करने पर, रिस्पॉन्स मिलने से जुड़ी समस्याएं हो सकती हैं. अगर कोई उपयोगकर्ता किसी पेज से इंटरैक्ट करने की कोशिश करता है, जैसे कि किसी बटन पर क्लिक करना या मेन्यू खोलना, लेकिन मुख्य थ्रेड पहले से ही किसी लंबे टास्क से इंटरैक्ट कर रहा है, तो उपयोगकर्ता के इंटरैक्शन को देर से पूरा किया जाएगा.

जवाब देने के तरीके को बेहतर बनाने के लिए, हमारी सलाह है कि आप लंबे टास्क को छोटे-छोटे हिस्सों में बांटें. अगर हर लंबे टास्क को कई छोटे टास्क में बांट दिया जाता है, तो हो सकता है कि इन टास्क के बीच ज़्यादा ज़रूरी टास्क पूरे हो जाएं. इससे, इंटरैक्शन के जवाब देने में ज़्यादा समय नहीं लगता.

इसलिए, रिस्पॉन्स को बेहतर बनाने की कोशिश करते समय, सबसे पहले अक्सर परफ़ॉर्मेंस ट्रेस चलाना और लंबे टास्क देखना होता है. इसके लिए, लैब आधारित ऑडिटिंग टूल का इस्तेमाल किया जा सकता है. जैसे, Lighthouse (जिसमें मुख्य थ्रेड वाले लंबे टास्क से बचें ऑडिट में) या Chrome DevTools में लंबे टास्क पर नज़र रखना.

लैब-आधारित टेस्टिंग अक्सर जवाब देने से जुड़ी समस्याओं की पहचान के लिए एक खराब शुरुआती जगह है, क्योंकि इन टूल में हो सकता है कि इंटरैक्शन शामिल न हों—जब वे ऐसा करते हैं, तो वे संभावित इंटरैक्शन का एक छोटा सबसेट होते हैं. आम तौर पर, फ़ील्ड में धीमे इंटरैक्शन की वजहों को मापा जाएगा.

लाॅंग Tasks एपीआई की कमियां

परफ़ॉर्मेंस ऑब्ज़र्वर की मदद से, फ़ील्ड में लंबे टास्क को मेज़र करना सिर्फ़ थोड़ा मददगार होता है. असल में, कोई लंबा टास्क और उसमें लगने वाले समय के अलावा, वह ज़्यादा जानकारी नहीं देता.

रीयल यूज़र मॉनिटरिंग (आरयूएम) टूल का इस्तेमाल, अक्सर लंबे टास्क की संख्या या अवधि का रुझान दिखाने के लिए किया जाता है. इसके अलावा, यह पता लगाने के लिए भी इसका इस्तेमाल किया जाता है कि वे किन पेजों पर होंगे. हालांकि, इस बारे में पूरी जानकारी मौजूद नहीं है कि यह टास्क किस वजह से हुआ. हालांकि, यह सिर्फ़ सीमित इस्तेमाल के बारे में है. लंबे टास्क एपीआई में सिर्फ़ एक बेसिक एट्रिब्यूशन मॉडल होता है, जिससे आपको सिर्फ़ यह पता चलता है कि लंबा टास्क किस कंटेनर (टॉप लेवल का दस्तावेज़ या <iframe>) में हुआ है. हालांकि, यह उस स्क्रिप्ट या फ़ंक्शन की जानकारी नहीं देता जिसमें इसे नाम दिया गया है, जैसा कि किसी सामान्य एंट्री में दिखाया गया है:

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

लाॅंग Tasks एपीआई को एक अधूरा व्यू माना जाता है. इसकी वजह यह है कि इसमें कुछ ज़रूरी टास्क भी शामिल नहीं किए जा सकते. रेंडरिंग जैसे कुछ अपडेट, अलग-अलग टास्क में होते हैं. आम तौर पर, इन्हें पहले किए गए एक्ज़ीक्यूशन के साथ शामिल किया जाना चाहिए. इसकी वजह से, उस अपडेट की वजह से उस इंटरैक्शन के "कुल काम" को सही तरीके से मेज़र किया जाता है. टास्क पर भरोसा कैसे करें, इस बारे में ज़्यादा जानने के लिए, जानकारी देने वाले पेज का "लंबे टास्क कहां कम हो जाते हैं" सेक्शन देखें.

आखिरी समस्या यह है कि लंबे टास्क को मेज़र करने से सिर्फ़ उन टास्क की रिपोर्ट मिलती है जिनमें 50 मिलीसेकंड से ज़्यादा समय लगता है. किसी ऐनिमेशन फ़्रेम में 50 मिलीसेकंड की इस सीमा से कम के कई टास्क करके बनाए जा सकते हैं, लेकिन इन सभी टास्क से ब्राउज़र को रेंडर होने में भी दिक्कत हो सकती है.

लंबे ऐनिमेशन फ़्रेम वाला एपीआई

ब्राउज़र सहायता

  • 123
  • x
  • x
  • x

लंबी ऐनिमेशन फ़्रेम एपीआई (एलओएएफ़) एक नया एपीआई है. यह लाॅंग Tasks एपीआई की कमियों को ठीक करने की कोशिश करता है. इसकी मदद से डेवलपर, जवाब देने से जुड़ी समस्याओं को ठीक करने और आईएनपी को बेहतर बनाने के लिए, काफ़ी अहम जानकारी हासिल कर पाते हैं.

बेहतर रिस्पॉन्स का मतलब है कि कोई पेज, उसके साथ किए गए इंटरैक्शन पर तुरंत जवाब देता है. इसमें उपयोगकर्ता की ज़रूरत के हिसाब से, समय पर अपडेट लागू करना और इन अपडेट को ब्लॉक होने से रोकना शामिल है. आईएनपी के लिए, हमारा सुझाव है कि आप 200 मिलीसेकंड या उससे कम समय में जवाब दें. हालांकि, दूसरे अपडेट (जैसे, ऐनिमेशन) के लिए, वे बहुत लंबे हो सकते हैं.

लंबे ऐनिमेशन फ़्रेम एपीआई, ब्लॉक करने की प्रोसेस को मापने का एक वैकल्पिक तरीका है. लंबे ऐनिमेशन फ़्रेम एपीआई, अलग-अलग टास्क को मेज़र करने के बजाय, लंबे ऐनिमेशन फ़्रेम को मेज़र करता है. इस एपीआई के नाम का मतलब है, जैसा कि इसके नाम से पता चलता है. लंबा ऐनिमेशन फ़्रेम तब होता है, जब रेंडरिंग अपडेट में 50 मिलीसेकंड से ज़्यादा की देरी होती है. यह समयावधि, लंबे टास्क एपीआई के थ्रेशोल्ड के बराबर होती है.

लंबे ऐनिमेशन फ़्रेम, 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 है, जिसके बाद नई एंट्री हटा दी जाती हैं. इसलिए, हमारा सुझाव है कि Performance खबरों को एक बार में लागू करने का सुझाव दिया जाता है. long-animation-frame का बफ़र साइज़ 200 पर सेट होता है. यह long-tasks के बराबर होता है.

टास्क के बजाय फ़्रेम देखने के फ़ायदे

इसे टास्क के नज़रिए से देखने के बजाय, फ़्रेम के नज़रिए से देखने का सबसे बड़ा फ़ायदा यह है कि लंबे ऐनिमेशन को कई टास्क बनाकर एक साथ बनाया जा सकता है. इससे एक लंबा ऐनिमेशन फ़्रेम बन जाता है. इससे हम पहले बताए गए आखिरी पॉइंट तक पहुंच जाते हैं. यहां लंबे टास्क एपीआई, किसी ऐनिमेशन फ़्रेम से पहले के छोटे और रेंडर ब्लॉक करने वाले टास्क को नहीं दिखा सकते.

लंबे टास्क के लिए इस वैकल्पिक व्यू का एक फ़ायदा यह भी है कि पूरे फ़्रेम के टाइम ब्रेकडाउन की सुविधा दी जा सकती है. लाॅग Tasks एपीआई की तरह ही startTime और duration को शामिल करने के बजाय, 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 एंट्री टाइप में, हर उस स्क्रिप्ट का बेहतर एट्रिब्यूशन डेटा शामिल होता है जिसकी वजह से लंबे ऐनिमेशन फ़्रेम की सुविधा मिलती है.

लांग Tasks एपीआई की तरह ही, इसे भी एट्रिब्यूशन एंट्री के कलेक्शन में दिया जाएगा. इसमें हर जानकारी की जानकारी होगी:

  • 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
}

जैसा कि देखा जा सकता है, इससे वेबसाइटों को बहुत ज़्यादा डेटा मिलता है. इससे, वे रेंडर करते समय होने वाले अपडेट की वजह को समझ पाती हैं.

लॉन्ग ऐनिमेशन फ़्रेम एपीआई चालू करना

लंबे ऐनिमेशन फ़्रेम एपीआई को Chrome 123 में, डिफ़ॉल्ट रूप से चालू किया जाता है.

फ़ील्ड में लंबे ऐनिमेशन फ़्रेम वाले एपीआई इस्तेमाल करना

Lighthouse जैसे टूल, लैब टूल हैं. इनसे उपयोगकर्ताओं को समस्याओं का पता लगाने और उन्हें फिर से जनरेट करने में मदद मिलती है. हालांकि, ऐसा हो सकता है कि इन टूल से उपयोगकर्ता अनुभव के वे अहम हिस्से छूट जाएं जो सिर्फ़ फ़ील्ड डेटा से मिल सकते हैं. लंबा ऐनिमेशन फ़्रेम एपीआई फ़ील्ड में, उपयोगकर्ता के इंटरैक्शन से जुड़ा ज़रूरी डेटा इकट्ठा करने के लिए इस्तेमाल किया जा सकता है. यह डेटा, लंबे टास्क एपीआई के ज़रिए नहीं इकट्ठा किया जा सकता. इसकी मदद से, बातचीत से जुड़ी ऐसी समस्याओं को सामने लाया जा सकता है और उनके बारे में बताया जा सकता है जिनके बारे में आपको शायद पता न हो.

आगे कुछ रणनीतियां सुझाई गई हैं. हालांकि, Chrome की टीम इस एपीआई पर सुझाव या राय जानना चाहती है. साथ ही, यह भी जानना चाहती है कि डेवलपर और RUM की सेवाएं देने वाली कंपनियां, एपीआई से मिलने वाली जानकारी का इस्तेमाल करके खुद को किस तरह देखेंगे.

लंबे ऐनिमेशन फ़्रेम वाले एपीआई से जुड़ी सहायता का पता लगाने वाली सुविधा

एपीआई काम करता है या नहीं, यह जांचने के लिए इस कोड का इस्तेमाल करें:

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

अगर लंबे ऐनिमेशन फ़्रेम अभी डिफ़ॉल्ट रूप से काम नहीं करते और इस ट्रांज़िशन स्थिति में हैं, तो ऐसे में नीचे दिए गए विकल्प का इस्तेमाल किया जा सकता है:

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

लंबे ऐनिमेशन डेटा को Analytics एंडपॉइंट पर वापस रिपोर्ट करना

जैसा कि दिखाया गया है, 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 });

लंबे ऐनिमेशन फ़्रेम की एंट्री काफ़ी बड़ी हो सकती हैं. इसलिए, डेवलपर को यह तय करना चाहिए कि एंट्री में से कौनसा डेटा Analytics को भेजा जाए. उदाहरण के लिए, एंट्री की खास जानकारी वाले समय और स्क्रिप्ट के नाम या काम की जानकारी से जुड़े अन्य डेटा का ऐसा कम से कम सेट जो ज़रूरी हो.

सबसे खराब लंबे ऐनिमेशन फ़्रेम पर नज़र रखना

जिस डेटा की ज़रूरत है उसे कम करने के लिए, साइटें सबसे लंबे ऐनिमेशन फ़्रेम (या फ़्रेम) का डेटा इकट्ठा कर सकती हैं. इसलिए, यह ज़रूरी नहीं है कि किसी पेज पर कितने लंबे ऐनिमेशन फ़्रेम बनाए गए हों, सबसे खराब, पांच या कितने भी लंबे ऐनिमेशन फ़्रेम का डेटा ही वापस आता है.

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 इंटरैक्शन से लिंक करना

सबसे खराब एलओएएफ़ को दिखाने के लिए, आईएनपी एंट्री से जुड़े एलओएएफ़ फ़्रेम का इस्तेमाल एट्रिब्यूशन डेटा के तौर पर किया जा सकता है. इसका इस्तेमाल आईएनपी को बेहतर बनाने के बारे में ज़्यादा जानकारी देने के लिए किया जा सकता है.

फ़िलहाल, आईएनपी एंट्री को इससे जुड़ी एलओएएफ़ एंट्री या एंट्री से लिंक करने के लिए कोई डायरेक्ट एपीआई नहीं है. हालांकि, हर एक के शुरू और खत्म होने के समय की तुलना करके कोड में ऐसा किया जा सकता है. इस स्क्रिप्ट के उदाहरण को देखें.

इंटरैक्शन के साथ लंबे ऐनिमेशन फ़्रेम की रिपोर्ट करना

दूसरा तरीका, जिसके लिए कम कोड की ज़रूरत होती है वह हमेशा सबसे बड़ी (या सबसे ऊपर X सबसे बड़ी) एलओएएफ़ एंट्री भेजना होगा, जहां फ़्रेम के दौरान इंटरैक्शन हुआ हो. इसका पता firstUIEventTimestamp वैल्यू से लगाया जा सकता है. ज़्यादातर मामलों में, इसमें किसी विज़िट के लिए आईएनपी इंटरैक्शन शामिल होता है. बहुत कम मामलों में, जब यह इंटरैक्शन नहीं होता है, तब भी ऐसे लंबे इंटरैक्शन दिखते हैं जिन्हें ठीक करना ज़रूरी है, क्योंकि ये अन्य उपयोगकर्ताओं के लिए आईएनपी इंटरैक्शन हो सकते हैं.

नीचे दिया गया कोड, 150 मिलीसेकंड से ज़्यादा की उन सभी LoAF एंट्री को लॉग करता है जहां फ़्रेम के दौरान इंटरैक्शन हुआ था. यहां 150 को इसलिए चुना गया है, क्योंकि यह 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 });

लंबे ऐनिमेशन फ़्रेम में सामान्य पैटर्न की पहचान करना

दूसरा तरीका यह होगा कि लंबी ऐनिमेशन फ़्रेम एंट्री में सबसे ज़्यादा दिखने वाली सामान्य स्क्रिप्ट पर ध्यान दिया जाए. बार-बार उल्लंघन करने वालों की पहचान करने के लिए, डेटा को स्क्रिप्ट और/या वर्ण की स्थिति के लेवल पर रिपोर्ट किया जा सकता है.

यह खास तौर पर, पसंद के मुताबिक बनाए जा सकने वाले ऐसे प्लैटफ़ॉर्म के लिए कारगर साबित हो सकता है जहां परफ़ॉर्मेंस से जुड़ी समस्याएं पैदा करने वाली थीम या प्लग इन को कई साइटों में आसानी से पहचाना जा सकता है.

लंबे ऐनिमेशन फ़्रेम में, सामान्य स्क्रिप्ट या तीसरे पक्ष के ऑरिजिन को चलाने के समय को जोड़ और रिपोर्ट करके, किसी साइट या साइटों के कलेक्शन में लंबे ऐनिमेशन फ़्रेम में आम तौर पर योगदान देने वाले लोगों की पहचान की जा सकती है. उदाहरण के लिए, यूआरएल देखने के लिए:

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

टूलिंग में लंबे ऐनिमेशन फ़्रेम एपीआई का इस्तेमाल करना

एपीआई, लोकल डीबगिंग के लिए अन्य डेवलपर टूल की अनुमति भी दे सकता है. लाइटहाउस और Chrome DevTools जैसे कुछ टूल, कम लेवल वाले ट्रेसिंग की जानकारी का इस्तेमाल करके, बहुत सारा डेटा इकट्ठा कर पाए हैं. हालांकि, हाई लेवल के इस एपीआई की मदद से, दूसरे टूल इस डेटा को ऐक्सेस कर सकते हैं.

DevTools में लंबे ऐनिमेशन फ़्रेम का डेटा दिखाना

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 में शामिल किया जा सकता है. हालांकि, इस दौरान पिछले कोड स्निपेट की मदद से, इसे वहां दिख सकता है.

अन्य डेवलपर टूल में लंबे ऐनिमेशन फ़्रेम के डेटा का इस्तेमाल करना

परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने के लिए, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाले एक्सटेंशन ने, लॉग करने की खास जानकारी वाली डीबग की जानकारी में वैल्यू दिखाई है. अब एपीआई लॉन्च हो गया है. ऐसे टूल आसानी से डेटा दिखा सकते हैं, ताकि डेवलपर को यह जानकारी मिल सके कि उन्हें किन बातों पर ध्यान देना है. हम इसे वर्शन 4 में वेब की ज़रूरी जानकारी की JavaScript लाइब्रेरी में जोड़ने की भी योजना बना रहे हैं.

ऑटोमेटेड टेस्टिंग टूल में लंबे ऐनिमेशन फ़्रेम का डेटा इस्तेमाल करना

इसी तरह, ऑटोमेटेड टेस्टिंग टूल, शायद CI/CD पाइपलाइन में, लंबे ऐनिमेशन फ़्रेम को मेज़र करके, परफ़ॉर्मेंस से जुड़ी संभावित समस्याओं के बारे में जानकारी दे सकते हैं. ऐसा अलग-अलग टेस्ट सुइट चलाते समय किया जा सकता है.

अक्सर पूछे जाने वाले सवाल

इस एपीआई के बारे में अक्सर पूछे जाने वाले कुछ सवाल हैं:

क्यों न सिर्फ़long Tasks API का इस्तेमाल किया जाए या इसे दोहराया जाए?

यह जवाब देने से जुड़ी संभावित समस्याओं के आंकलन का एक वैकल्पिक रूप है, जिसकी रिपोर्टिंग से मिलते-जुलते तरीकों का इस्तेमाल किया जा सकता है. हालांकि, यह अलग है. यह पक्का करना ज़रूरी है कि लाॅन्ग टास्क एपीआई का इस्तेमाल करने वाली साइटें, काम करना जारी रखें. ऐसा करने से, इस्तेमाल के मौजूदा उदाहरणों में कोई रुकावट नहीं आएगी.

हालांकि, LoAF की कुछ सुविधाओं (जैसे कि एक बेहतर एट्रिब्यूशन मॉडल) से, लंबे टास्क एपीआई को फ़ायदा मिल सकता है, लेकिन हमारा मानना है कि टास्क के बजाय फ़्रेम पर फ़ोकस करने से कई फ़ायदे मिलते हैं. इसकी वजह से, यह मौजूदा लंबे टास्क एपीआई की तुलना में बुनियादी तौर पर अलग एपीआई बन जाता है.

क्या यह लंबे टास्क एपीआई की जगह लेगा?

हालांकि, हमें लगता है कि लंबा ऐनिमेशन फ़्रेम एपीआई, लंबे टास्क मापने के लिए एक बेहतर और ज़्यादा जानकारी वाला एपीआई है. हालांकि, इस समय लॉन्ग टास्क एपीआई को बंद करने की कोई योजना नहीं है.

सुझाव, शिकायत या राय चाहिए

GitHub से जुड़ी समस्याओं की सूची में सुझाव दिए जा सकते हैं या Chrome में एपीआई लागू करते समय होने वाली गड़बड़ियों को Chrome के समस्या ट्रैकर में दर्ज किया जा सकता है.

नतीजा

लंबी ऐनिमेशन फ़्रेम वाला एपीआई, एक नया और मज़ेदार एपीआई है. इसमें, लंबे टास्क एपीआई के पिछले वर्शन की तुलना में, कई फ़ायदे हो सकते हैं.

आईएनपी के मुताबिक, यह रिस्पॉन्सिबिलिटी की समस्याओं को हल करने का अहम टूल है. आईएनपी, ऑप्टिमाइज़ करने में मुश्किल मेट्रिक है. साथ ही, यह एपीआई एक ऐसा एपीआई है जिसे Chrome की टीम, डेवलपर के लिए समस्याओं को पहचानने और उन्हें हल करने में आसान बनाना चाहती है.

लाॅंग ऐनिमेशन फ़्रेम एपीआई का दायरा, आईएनपी से अलग है. साथ ही, यह धीमे अपडेट की दूसरी वजहों को पहचानने में मदद कर सकता है, जो किसी वेबसाइट पर उपयोगकर्ता अनुभव को बेहतर बनाने पर असर डाल सकती हैं.

स्वीकार हैं

Unsplash पर हेनरी बी की ओर से थंबनेल इमेज.