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

Barry Pollard

Noam Rosenthal

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

एपीआई का स्टेटस

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

• 123
• 123
• x
• x

सोर्स

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

बैकग्राउंड: Long Tasks API

ब्राउज़र के इस्तेमाल से जुड़ी सहायता

• 58
• 79
• x
• x

सोर्स

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

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

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

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

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

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

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

Long Tasks API की कमियां

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

रीयल यूज़र मॉनिटरिंग (आरयूएम) टूल, अक्सर इसका इस्तेमाल लंबे टास्क की संख्या या अवधि के रुझान को ट्रैक करने या यह पता लगाने के लिए करते हैं कि ये टास्क किन पेजों पर होते हैं. हालांकि, लंबे टास्क की वजह के बारे में जानकारी के बिना, इसका इस्तेमाल सीमित तौर पर ही किया जा सकता है. 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

ब्राउज़र के इस्तेमाल से जुड़ी सहायता

• 123
• 123
• x
• x

सोर्स

Long Animation Frames API (LoAF) एक नया एपीआई है. इसका मकसद, Long Tasks API की कुछ कमियों को ठीक करना है. इससे डेवलपर को ज़्यादा अहम जानकारी मिलती है, ताकि वे ऐप्लिकेशन के तेज़ी से काम करने से जुड़ी समस्याओं को हल कर सकें और INP को बेहतर बना सकें. साथ ही, ऐप्लिकेशन के आसानी से काम करने से जुड़ी समस्याओं के बारे में भी जानकारी पा सकें.

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

ब्लॉकिंग के काम को मेज़र करने का एक अन्य तरीका, Long Animation Frames API है. Long Animation Frames API, अलग-अलग टास्क को मेज़र करने के बजाय, लंबे ऐनिमेशन फ़्रेम को मेज़र करता है. जब रेंडरिंग अपडेट में 50 मिलीसेकंड से ज़्यादा समय लगता है, तब उसे लंबा ऐनिमेशन फ़्रेम कहा जाता है. यह समय, Long Tasks API के थ्रेशोल्ड के बराबर होता है.

लंबे ऐनिमेशन फ़्रेम, उन टास्क की शुरुआत से मापे जाते हैं जिनके लिए रेंडर करना ज़रूरी होता है. अगर किसी संभावित लंबे ऐनिमेशन फ़्रेम में पहले टास्क को रेंडर करने की ज़रूरत नहीं है, तो रेंडर न करने वाले टास्क के पूरा होने पर, लंबा ऐनिमेशन फ़्रेम खत्म हो जाता है. इसके बाद, अगले टास्क के साथ एक नया संभावित लंबा ऐनिमेशन फ़्रेम शुरू हो जाता है. ऐसे लंबे ऐनिमेशन फ़्रेम को, 50 मिलीसेकंड से ज़्यादा समय तक रेंडर न होने पर भी, Long Animation Frames API में शामिल किया जाता है. हालांकि, इसके लिए renderStart का समय 0 होना चाहिए. इससे, ब्लॉक होने वाले काम को मेज़र करने में मदद मिलती है.

लंबे ऐनिमेशन फ़्रेम को उसी तरह देखा जा सकता है जिस तरह 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 से नहीं दिखाया जा सकता.

लंबे टास्क के लिए, इस वैकल्पिक व्यू का एक और फ़ायदा यह है कि इससे पूरे फ़्रेम के लिए, समय के ब्रेकडाउन की जानकारी मिलती है. Long Tasks API की तरह, सिर्फ़ startTime और duration शामिल करने के बजाय, LoAF में फ़्रेम की अवधि के अलग-अलग हिस्सों की ज़्यादा जानकारी शामिल होती है.

फ़्रेम के टाइमस्टैंप और अवधि

• startTime: नेविगेशन के शुरू होने के समय के हिसाब से, लंबे ऐनिमेशन फ़्रेम के शुरू होने का समय.
• duration: लंबे ऐनिमेशन फ़्रेम की अवधि (प्रज़ेंटेशन का समय शामिल नहीं है).
• renderStart: रेंडरिंग साइकल का शुरू होने का समय. इसमें requestAnimationFrame कॉलबैक, स्टाइल और लेआउट का हिसाब लगाने, साइज़ बदलने वाले ऑब्ज़र्वर, और इंटरसेक्शन ऑब्ज़र्वर कॉलबैक शामिल हैं.
• styleAndLayoutStart: स्टाइल और लेआउट के कैलकुलेशन में खर्च की गई समयावधि की शुरुआत.
• firstUIEventTimestamp: इस फ़्रेम के दौरान मैनेज किए जाने वाले पहले यूज़र इंटरफ़ेस (यूआई) इवेंट (माउस/कीबोर्ड वगैरह) का समय.
• blockingDuration: मिलीसेकंड में कुल अवधि, जिसके लिए ऐनिमेशन फ़्रेम, इनपुट या ज़्यादा प्राथमिकता वाले अन्य टास्क की प्रोसेसिंग ब्लॉक कर देगा.

blockingDuration के बारे में जानकारी

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

उदाहरण के लिए, अगर किसी लंबे ऐनिमेशन फ़्रेम को 55 मिलीसेकंड और 65 मिलीसेकंड के दो टास्क के बाद 20 मिलीसेकंड में रेंडर किया गया था, तो duration करीब 140 मिलीसेकंड होगा. साथ ही, blockingDuration (55 - 50) + (65 + 20 - 50) = 40 मिलीसेकंड होगा. 140 मिलीसेकंड के इस ऐनिमेशन फ़्रेम के दौरान, 40 मिलीसेकंड के लिए फ़्रेम को इनपुट मैनेज करने से ब्लॉक किया गया था.

आपको duration देखना है या blockingDuration पर

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

इसलिए, अगर लंबे ऐनिमेशन फ़्रेम कम या शून्य blockingDuration हैं, तो भी इनपुट के हिसाब से उन्हें रिस्पॉन्स मिलना चाहिए. इसलिए, लंबे टास्क को बांटकर blockingDuration को कम करना या हटाना, रिस्पॉन्सिवनेस को बेहतर बनाने के लिए ज़रूरी है. इसे INP से मेज़र किया जाता है.

हालांकि, blockingDuration के बावजूद, बहुत ज़्यादा लंबे ऐनिमेशन फ़्रेम से पता चलता है कि यूज़र इंटरफ़ेस (यूआई) के अपडेट में देरी हो रही है. इसलिए, इनसे यूज़र इंटरफ़ेस (यूआई) के आसानी से काम करने की सुविधा पर असर पड़ सकता है. साथ ही, स्क्रोल करने या ऐनिमेशन के लिए, यूज़र इंटरफ़ेस (यूआई) में लैग की समस्या आ सकती है. भले ही, INP के हिसाब से, इनसे रिस्पॉन्सिवनेस पर ज़्यादा असर न पड़ता हो. इस इलाके की समस्याओं को समझने के लिए, duration को देखें. हालांकि, इन्हें ऑप्टिमाइज़ करना थोड़ा मुश्किल हो सकता है, क्योंकि काम के अलग-अलग हिस्सों को बांटकर इसे हल नहीं किया जा सकता. इसके बजाय, आपको काम कम करना होगा.

फ़्रेम टाइम

ऊपर बताए गए टाइमस्टैंप की मदद से, लंबे ऐनिमेशन फ़्रेम को टाइमिंग में बांटा जा सकता है:

समस्या शुरू होने का समय	कैलकुलेशन
प्रारंभ समय	startTime
समाप्ति समय	startTime + duration
काम करने की अवधि	renderStart ? renderStart - startTime : duration
रेंडर होने में लगने वाला समय	renderStart ? (startTime + duration) - renderStart: 0
रेंडर: लेआउट से पहले का समय	styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0
रेंडर: स्टाइल और लेआउट की अवधि	styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0

बेहतर स्क्रिप्ट एट्रिब्यूशन

long-animation-frame एंट्री टाइप में, हर उस स्क्रिप्ट के एट्रिब्यूशन डेटा का बेहतर डेटा शामिल होता है जिसने लंबे ऐनिमेशन फ़्रेम (पांच मिलीसेकंड से ज़्यादा लंबी स्क्रिप्ट के लिए) में योगदान दिया है.

अहम जानकारी:

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

Long Tasks API की तरह ही, यह एट्रिब्यूशन एंट्री की एक कतार में उपलब्ध कराया जाएगा. इनमें से हर एंट्री में यह जानकारी होती है:

• 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: एक ही ऑरिजिन वाली विंडो का रेफ़रंस.

अहम जानकारी:

ऑरिजिन ट्रायल के दौरान, Chrome 122 तक इनमें से कुछ एंट्री थोड़ी अलग थीं:

• एपीआई में desiredExecutionStart और desiredRenderStart मौजूद थे. हालांकि, एंट्री को आसान बनाने के लिए इन्हें हटा दिया गया है, क्योंकि ये बुनियादी तौर पर सोच से ज़्यादा काम के नहीं थे.
• invoker और invokerType की जगह name और type का इस्तेमाल किया गया था.
• sourceLocation का इस्तेमाल, sourceURL, sourceFunctionName, और sourceCharPosition को मिलाकर बनाई गई वैल्यू के तौर पर किया गया था,

ऑरिजिन ट्रायल का इस्तेमाल करने वाले Chrome ब्राउज़र के साथ काम करना जारी रखने के लिए, आपके पास सुविधा का पता लगाने (उदाहरण के लिए, "invoker" in PerformanceScriptTiming.prototype का इस्तेमाल करके) या फ़ॉलबैक (invoker = script.invoker || script.name) शामिल करने का विकल्प है.

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

अहम जानकारी:

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

कुछ मामलों में सोर्स एंट्री नहीं दी जा सकतीं. इनमें no-cors cross-origin स्क्रिप्ट या उपयोगकर्ता कोड में कॉलबैक तय न होना शामिल है.

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 DevTools और Lighthouse जैसे टूल, समस्याओं का पता लगाने और उन्हें फिर से बनाने के लिए काम के होते हैं. हालांकि, ये प्रयोगशाला में इस्तेमाल होने वाले टूल हैं. इनसे उपयोगकर्ता अनुभव के उन अहम पहलुओं के बारे में पता नहीं चलता जिन्हें सिर्फ़ फ़ील्ड डेटा से पता चलता है.

Long Animation Frames API को फ़ील्ड में इस्तेमाल करने के लिए डिज़ाइन किया गया है, ताकि उपयोगकर्ता इंटरैक्शन के लिए ज़रूरी संदर्भ डेटा इकट्ठा किया जा सके. यह ऐसा डेटा है जिसे Long Tasks API इकट्ठा नहीं कर सकता. इससे आपको बातचीत के दौरान होने वाली उन समस्याओं को पहचानने और उन्हें फिर से समझने में मदद मिलती है जिनके बारे में आपको पहले पता नहीं चल पाता था.

लंबी अवधि के ऐनिमेशन फ़्रेम का पता लगाने वाली सुविधा के लिए, Long Animation Frames API की सहायता

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

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

सबसे लंबे आईएनपी इंटरैक्शन का लिंक

Long Animation Frames API का सबसे आम इस्तेमाल, इंटरैक्शन से अगले पेज के पेंट में लगने वाला समय (आईएनपी) से जुड़ी समस्याओं का पता लगाने और उन्हें ठीक करने में मदद करना है. यह Chrome टीम की ओर से इस एपीआई को डेवलप करने की मुख्य वजहों में से एक थी. अच्छा आईएनपी वह है जहां फ़्रेम को पेंट किए जाने तक सभी इंटरैक्शन का, इंटरैक्शन के बाद 200 मिलीसेकंड या उससे कम में जवाब दिया जाता है. साथ ही, लंबा ऐनिमेशन फ़्रेम एपीआई, 50 मि॰से॰ या उससे ज़्यादा समय लेने वाले सभी फ़्रेम को मेज़र करता है. इसलिए, सबसे समस्या वाले आईएनपी में LoAF का डेटा शामिल होना चाहिए, ताकि आप इंटरैक्शन का पता लगा सकें.

"INP LoAF" एक ऐसा LoAF है जिसमें INP इंटरैक्शन शामिल होता है. इसकी जानकारी नीचे दिए गए डायग्राम में दी गई है:

किसी पेज में कई LoAF हो सकते हैं. इनमें से एक, आईएनपी इंटरैक्शन से जुड़ा होता है.

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

किसी पेज में कई LoAF हो सकते हैं. इनमें से एक, आईएनपी इंटरैक्शन से जुड़ा होता है.

ऐसा भी हो सकता है कि कुछ मामलों में, यह दो से ज़्यादा LoAF में हो.

INP इंटरैक्शन से जुड़े LoAF का डेटा रिकॉर्ड करने से, आपको INP इंटरैक्शन के बारे में ज़्यादा जानकारी मिलती है. इससे, आपको समस्या का पता लगाने में मदद मिलती है. इससे इनपुट में देरी को समझने में मदद मिलती है. इससे यह समझने में मदद मिलती है कि उस फ़्रेम में कौनसी दूसरी स्क्रिप्ट चल रही थीं.

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

INP एंट्री को उससे जुड़ी LoAF एंट्री या एंट्री से लिंक करने के लिए कोई सीधा एपीआई नहीं है. हालांकि, कोड में ऐसा किया जा सकता है. इसके लिए, हर एंट्री के शुरू और खत्म होने के समय की तुलना करें. WhyNp की उदाहरण स्क्रिप्ट देखें. web-vitals लाइब्रेरी में, v4 से INP एट्रिब्यूशन इंटरफ़ेस की longAnimationFramesEntries प्रॉपर्टी में इंटरसेक्शन वाले सभी LoAF शामिल हैं.

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

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

Analytics एंडपॉइंट पर ज़्यादा लंबे ऐनिमेशन डेटा की रिपोर्ट दें

सिर्फ़ आईएनपी के LoAF को देखने का एक नुकसान यह है कि आपको सुधार के लिए अन्य संभावित क्षेत्रों की जानकारी नहीं मिल सकती. इनसे आने वाले समय में आईएनपी से जुड़ी समस्याएं हो सकती हैं. इस वजह से, ऐसा लग सकता है कि आप आईएनपी से जुड़ी समस्या को ठीक करने के लिए आगे बढ़ रहे हैं. इस समस्या में बहुत बड़े सुधार की उम्मीद है. हालांकि, अगली सबसे धीमी बातचीत का पता लगाना, उससे कुछ ही बेहतर है. इसलिए, आपकी आईएनपी में ज़्यादा सुधार नहीं होगा.

इसलिए, सिर्फ़ INP LoAF को देखने के बजाय, पेज के लाइफ़टाइम के दौरान सभी LoAF को ध्यान में रखा जा सकता है:

सभी LoAF को देखकर, आने वाले समय में आईएनपी से जुड़ी समस्याओं की पहचान की जा सकती है.

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

लंबे ऐनिमेशन फ़्रेम के डेटा की संख्या कम करने के लिए, सुझाए गए कुछ पैटर्न में ये शामिल हैं:

• इंटरैक्शन के साथ लंबे ऐनिमेशन फ़्रेम देखना
• लंबे ऐनिमेशन फ़्रेम को देखें, जिनमें ब्लॉक करने की अवधि ज़्यादा है
• यूज़र इंटरफ़ेस (यूआई) के अहम अपडेट के दौरान, ऐनिमेशन के लंबे फ़्रेम देखें, ताकि यूज़र इंटरफ़ेस को बेहतर बनाया जा सके
• ऐनिमेशन के सबसे लंबे फ़्रेम देखना
• लंबे ऐनिमेशन फ़्रेम में सामान्य पैटर्न की पहचान करना

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

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

इंटरैक्शन के साथ लंबे एनिमेशन फ़्रेम देखना

सिर्फ़ INP के लंबे ऐनिमेशन फ़्रेम के अलावा अहम जानकारी पाने के लिए, ज़्यादा blockingDuration वाले इंटरैक्शन वाले सभी LoAF देखे जा सकते हैं. इंटरैक्शन की पहचान firstUIEventTimestamp वैल्यू की मौजूदगी से की जा सकती है.

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

नीचे दिया गया कोड, उन सभी LoAF एंट्री को लॉग करता है जिनमें blockingDuration 100 मिलीसेकंड से ज़्यादा है और फ़्रेम के दौरान कोई इंटरैक्शन हुआ है. यहां 100 को चुना गया है, क्योंकि यह 200 मिलीसेकंड की "अच्छा" आईएनपी थ्रेशोल्ड से कम है. अपनी ज़रूरतों के हिसाब से, ज़्यादा या कम वैल्यू चुनी जा सकती है.

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

लंबे ऐनिमेशन फ़्रेम देखें, जिनमें ब्लॉक करने की अवधि ज़्यादा हो

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

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

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

आसानी से काम करने के लिए, यूज़र इंटरफ़ेस (यूआई) के ज़रूरी अपडेट के दौरान लंबे ऐनिमेशन फ़्रेम देखें

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

इससे काफ़ी शोर हो सकता है, इसलिए हो सकता है कि आप इनकी माप को इस तरह के पैटर्न के साथ मुख्य बिंदुओं तक सीमित करना चाहें:

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  if (measureImportantUIupdate) {
    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 });

async function doUIUpdatesWithMeasurements() {
  measureImportantUIupdate = true;
  await doUIUpdates();
  measureImportantUIupdate = false;
}

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

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

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

सही समय पर (आम तौर पर, visibilitychange इवेंट पर) बीकन वापस लें. स्थानीय जांच के लिए, console.table का इस्तेमाल समय-समय पर किया जा सकता है:

console.table(longestBlockingLoAFs);

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

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

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

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

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 जैसे कुछ टूल, कम लेवल की ट्रैकिंग की जानकारी का इस्तेमाल करके, इस डेटा का ज़्यादातर हिस्सा इकट्ठा कर पाते हैं. हालांकि, इस हाई लेवल वाले एपीआई की मदद से, दूसरे टूल भी इस डेटा को ऐक्सेस कर सकते हैं.

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

performance.measure() एपीआई का इस्तेमाल करके, DevTools में लंबे ऐनिमेशन फ़्रेम दिखाए जा सकते हैं. इसके बाद, ये फ़्रेम परफ़ॉर्मेंस ट्रेस में DevTools उपयोगकर्ता टाइमिंग ट्रैक में दिखाए जाते हैं. इससे आपको यह पता चलता है कि परफ़ॉर्मेंस को बेहतर बनाने के लिए आपको कहां फ़ोकस करना है. DevTools Extensibility API का इस्तेमाल करके इन्हें उनके अपने ट्रैक में भी दिखाया जा सकता है:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
      detail: {
        devtools: {
          dataType: "track-entry",
          track: "Long animation frames",
          trackGroup: "Performance Timeline",
          color: "tertiary-dark",
          tooltipText: 'LoAF'
        }
      }
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

DevTools में लंबा ऐनिमेशन फ़्रेम डेटा दिखाया जा रहा है.

आने वाले समय में, लंबी अवधि के ऐनिमेशन फ़्रेम को DevTools में शामिल किया जा सकता है. हालांकि, इस बीच, पिछले कोड स्निपेट की मदद से, उन्हें वहां दिखाया जा सकता है.

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

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

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

अब यह हर INP कॉलबैक और हर इंटरैक्शन के लिए, लंबे ऐनिमेशन फ़्रेम का डेटा भी दिखाता है:

वेब Vitals एक्सटेंशन कंसोल, लॉगिंग के ज़रिए LoAF डेटा दिखाता है.

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

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

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

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

क्यों न सिर्फ़ लंबी अवधि के टास्क एपीआई को बढ़ाया या दोहराया जा सकता है?

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

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

मेरे पास स्क्रिप्ट एंट्री क्यों नहीं हैं?

इससे पता चलता है कि लंबा ऐनिमेशन फ़्रेम, JavaScript की वजह से नहीं, बल्कि ज़्यादा रेंडरिंग की वजह से था.

ऐसा तब भी हो सकता है, जब लंबा ऐनिमेशन फ़्रेम JavaScript की वजह से हो, लेकिन पहले जैसा बताया गया है, निजता की अलग-अलग वजहों से स्क्रिप्ट का एट्रिब्यूशन नहीं दिया जा सकता. खास तौर पर, ऐसा तब होता है, जब JavaScript का मालिकाना हक पेज के पास न हो.

मेरे पास स्क्रिप्ट एंट्री हैं, लेकिन सोर्स की जानकारी नहीं है या सीमित जानकारी है, ऐसा क्यों है?

ऐसा कई वजहों से हो सकता है. इनमें इस बात की जानकारी देने के लिए सही सोर्स न होना शामिल है.

no-cors cross-origin स्क्रिप्ट के लिए भी स्क्रिप्ट की जानकारी सीमित रहेगी. हालांकि, इसे ठीक करने के लिए, सीओआरएस का इस्तेमाल करके उन स्क्रिप्ट को फ़ेच किया जा सकता है. इसके लिए, <script> कॉल में crossOrigin = "anonymous" जोड़ें.

उदाहरण के लिए, पेज में जोड़ने के लिए डिफ़ॉल्ट 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 -->

GTM के लिए पूरी एट्रिब्यूशन जानकारी देने की अनुमति देने के लिए, j.crossOrigin = "anonymous" जोड़ने के लिए बेहतर किया जा सकता है

क्या यह Long Tasks API की जगह लेगा?

हमारा मानना है कि लंबे समय तक चलने वाले टास्क को मेज़र करने के लिए, Long Animation Frames API बेहतर और ज़्यादा बेहतर एपीआई है. हालांकि, फ़िलहाल Long Tasks API को बंद करने का कोई प्लान नहीं है.

सुझाव, राय या शिकायत करना

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

नतीजा

Long Animation Frames API एक नया और दिलचस्प एपीआई है. इसमें, Long Tasks API की तुलना में कई संभावित फ़ायदे हैं.

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

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

स्वीकार की गई

Unsplash पर Henry Be की थंबनेल इमेज.