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

Barry Pollard

Noam Rosenthal

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

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

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

बैकग्राउंड: लंबा टास्क एपीआई

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

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

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

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

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

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

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

लंबे टास्क एपीआई की कमियां

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

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

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

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

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

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

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

अच्छे रिस्पॉन्स का मतलब है कि कोई पेज, पेज पर हुए इंटरैक्शन के लिए तुरंत जवाब देता है. इसमें उपयोगकर्ता के किसी भी ज़रूरी अपडेट को समय पर पेंट करने की सुविधा शामिल है. साथ ही, इन अपडेट को ब्लॉक होने से बचाने की कोशिश की जाती है. आईएनपी के लिए, हमारा सुझाव है कि 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 के लिए भी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"आईएनपी लोएएफ़" LoAF है, जिसमें आईएनपी इंटरैक्शन शामिल है, जैसा कि इस डायग्राम में दिखाया गया है:

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

कुछ खास मामलों में, ऐसा भी हो सकता है कि यह दो से ज़्यादा बार एलओएफ़ में मौजूद हो.

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

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

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

web-vitals लाइब्रेरी में, v4 की आईएनपी एट्रिब्यूशन इंटरफ़ेस की longAnimationFramesEntries प्रॉपर्टी में, इंटरसेक्ट करने वाले सभी LoAFs शामिल हैं.

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

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

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

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

सिर्फ़ आईएनपी एलओएएफ़ के बारे में बताने के बजाय, पूरे पेज पर सभी एलओएएफ़ को ध्यान में रखें:

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

सुझाए गए कुछ पैटर्न में ये शामिल हैं:

• इंटरैक्शन के साथ लंबे ऐनिमेशन फ़्रेम पर नज़र रखना
• तय सीमा से ज़्यादा समय तक चलने वाले ऐनिमेशन फ़्रेम पर नज़र रखना
• सबसे खराब लंबे ऐनिमेशन फ़्रेम पर नज़र रखें
• लंबे ऐनिमेशन फ़्रेम में सामान्य पैटर्न की पहचान करना

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

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

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

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

यह कोड 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 });

एक तय सीमा से ज़्यादा समय वाले ऐनिमेशन फ़्रेम पर नज़र रखें

दूसरी रणनीति यह होगी कि सभी एलओएएफ़ को मॉनिटर किया जाए और एक तय थ्रेशोल्ड से ज़्यादा खर्च करने वाले बीकन को बाद में विश्लेषण के लिए 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 });

इन रणनीतियों को एक साथ भी जोड़ा जा सकता है. सिर्फ़ 150 मिलीसेकंड से ज़्यादा लंबे इंटरैक्शन वाले 10 सबसे खराब एलओएफ़ को देखें.

सही समय पर (आम तौर पर, visibilitychange इवेंट के दौरान), Analytics पर वापस जाएं. लोकल टेस्टिंग के लिए, समय-समय पर 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});

साथ ही, इस आउटपुट का उदाहरण यह है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सुझाव ज़रूरी है

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

नतीजा

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

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

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

स्वीकार की गई

Unस्प्लैश पर हेनरी बी की थंबनेल इमेज.