फ़ील्ड में धीमे इंटरैक्शन का पता लगाना

अपनी वेबसाइट के फ़ील्ड डेटा में, धीमे इंटरैक्शन का पता लगाने का तरीका जानें. इससे आपको इसके 'इंटरैक्शन टू नेक्स्ट पेंट' के इंटरैक्शन को बेहतर बनाने के मौके मिल सकते हैं.

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

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

अपनी वेबसाइट के आईएनपी का आकलन करने के लिए, CrUX से शुरुआत करें

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

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

• PageSpeed Insights का इस्तेमाल करके, अलग-अलग पेज और पूरे ऑरिजिन.
• पेजों के टाइप. उदाहरण के लिए, कई ई-कॉमर्स वेबसाइटों में प्रॉडक्ट की जानकारी वाला पेज और प्रॉडक्ट लिस्टिंग पेज टाइप होते हैं. Search Console में, यूनीक पेज टाइप के लिए CrUX डेटा देखा जा सकता है.

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

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

web-vitals JavaScript लाइब्रेरी की मदद से फ़ील्ड का डेटा इकट्ठा करें

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

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

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  console.log(name);    // 'INP'
  console.log(value);   // 512
  console.log(rating);  // 'poor'
});

अपने उपयोगकर्ताओं से मिलने वाले फ़ील्ड डेटा का विश्लेषण करने के लिए, आपको इस डेटा को कहीं भेजना होगा:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  // Prepare JSON to be sent for collection. Note that
  // you can add anything else you'd want to collect here:
  const body = JSON.stringify({name, value, rating});

  // Use `sendBeacon` to send data to an analytics endpoint.
  // For Google Analytics, see https://github.com/GoogleChrome/web-vitals#send-the-results-to-google-analytics.
  navigator.sendBeacon('/analytics', body);
});

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

वेब-वाइटल लाइब्रेरी के एट्रिब्यूशन बिल्ड का इस्तेमाल करना

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

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, rating, attribution}) => {
  console.log(name);         // 'INP'
  console.log(value);        // 512
  console.log(rating);       // 'poor'
  console.dir(attribution);  // Attribution data
});

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

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

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

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

लॉन्ग ऐनिमेशन फ़्रेम एपीआई (LoAF)

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

वेब ज़रूरी जानकारी वाली लाइब्रेरी का एट्रिब्यूशन बिल्ड, attribution ऑब्जेक्ट की longAnimationFrameEntries कुंजी में एलओएएफ़ एंट्री का कलेक्शन दिखाता है. नीचे दी गई टेबल में डेटा के कुछ अहम हिस्से दिए गए हैं, जो हर LoAF एंट्री में मौजूद होते हैं:

इस पूरी जानकारी से आपको इस बारे में काफ़ी जानकारी मिल सकती है कि किस वजह से इंटरैक्शन धीमा हो जाता है—लेकिन एलओएएफ़ एंट्री में दिखने वाली scripts अरे में आपको खास तौर पर दिलचस्पी होनी चाहिए:

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

धीमे इंटरैक्शन की आम वजहों को मापें और पहचान करें

इस गाइड में बताया गया है कि इस जानकारी का इस्तेमाल किस तरह किया जा सकता है. अब आपको web-vitals लाइब्रेरी में दिखने वाले LoAF डेटा को इस्तेमाल करने के तरीके के बारे में जानकारी मिलेगी. इसकी मदद से, धीमे इंटरैक्शन की कुछ वजहों का पता लगाया जा सकता है.

लंबी प्रोसेसिंग अवधि

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

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5
});

आम तौर पर, यह माना जाता है कि धीमे इंटरैक्शन की मुख्य वजह यह है कि आपके इवेंट हैंडलर कोड को चलने में बहुत ज़्यादा समय लगा. हालांकि, हमेशा ऐसा नहीं होता! इसी समस्या की पुष्टि होने के बाद, LoAF के डेटा को ज़्यादा बारीकी से देखा जा सकता है:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5

  // Get the longest script from LoAF covering `processingDuration`:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Get attribution for the long-running event handler:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

जैसा कि पिछले कोड स्निपेट में देखा जा सकता है, LoAF डेटा के साथ काम करके, प्रोसेस होने की ज़्यादा अवधि वाली वैल्यू वाले इंटरैक्शन की सटीक वजह को ट्रैक किया जा सकता है. इसमें ये भी शामिल हैं:

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

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

इनपुट में ज़्यादा देरी

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

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536
});

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

क्या यह पेज लोड होने के दौरान था?

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

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Invoker types can describe if script eval blocked the main thread:
    const {invokerType} = script;    // 'classic-script' | 'module-script'
    const {sourceLocation} = script; // 'https://example.com/app.js'
  }
});

अगर इस डेटा को फ़ील्ड में रिकॉर्ड किया जाता है और आपको 'classic-script' या 'module-script' के ज़्यादा इनपुट में देरी और शुरू करने वाले टाइप दिखते हैं, तो यह कहना सही है कि आपकी साइट की स्क्रिप्ट को आकलन करने में ज़्यादा समय लग रहा है. साथ ही, यह मुख्य थ्रेड को काफ़ी देर तक ब्लॉक कर रही है जिससे इंटरैक्शन में देरी हो रही है. अपनी स्क्रिप्ट को छोटे-छोटे बंडल में बांटकर, ब्लॉक करने के इस समय को कम किया जा सकता है. इस्तेमाल न होने वाले कोड को बाद में लोड करने के लिए कुछ समय के लिए रोका जा सकता है. साथ ही, इस्तेमाल न होने वाले कोड के लिए अपनी साइट को ऑडिट किया जा सकता है, जिसे पूरी तरह से हटाया जा सकता है.

क्या यह पेज लोड होने के बाद था?

आम तौर पर, पेज लोड होने के दौरान इनपुट में देरी होती है. हालांकि, ऐसा भी हो सकता है कि पेज लोड होने के बाद, बिलकुल अलग वजह हो. पेज लोड होने के बाद, इनपुट में देरी की सामान्य वजहें हो सकती हैं. जैसे, setInterval से पहले किए गए कॉल की वजह से समय-समय पर चलने वाला कोड या ऐसे इवेंट कॉलबैक जो पहले से चलने के लिए सूची में थे और जो अब भी प्रोसेस हो रहे हैं.

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  if (script) {
    const {invokerType} = script;        // 'user-callback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

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

• 'user-callback' से पता चलता है कि ब्लॉक करने का टास्क setInterval, setTimeout या requestAnimationFrame ने भी किया था.
• 'event-listener' से पता चलता है कि ब्लॉक करने का टास्क पहले के किसी इनपुट से लिया गया था, जिसे सूची में रखा गया था और अब भी प्रोसेस किया जा रहा है.
• 'resolve-promise' और 'reject-promise' का मतलब है कि ब्लॉक किया गया टास्क, कुछ एसिंक्रोनस काम से किया गया था. इसे पहले बंद किया गया था. साथ ही, जब उपयोगकर्ता ने पेज से इंटरैक्ट करने की कोशिश की, तब इंटरैक्शन में देरी हुई. इस वजह से, टास्क को रिज़ॉल्व या अस्वीकार किया गया.

किसी भी मामले में, स्क्रिप्ट एट्रिब्यूशन डेटा से आपको यह पता चलेगा कि कहां से ढूंढना शुरू करना है और इनपुट में देरी आपके कोड की वजह से हुई या किसी तीसरे पक्ष की स्क्रिप्ट की वजह से.

प्रज़ेंटेशन में देरी

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

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691
});

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

महँगे स्टाइल और लेआउट के काम

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

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  // Get necessary timings:
  const {startTime} = loaf; // 2120.5
  const {duration} = loaf;  // 1002

  // Figure out the ending timestamp of the frame (approximate):
  const endTime = startTime + duration; // 3122.5

  // Get the start timestamp of the frame's style/layout work:
  const {styleAndLayoutStart} = loaf; // 3011.17692309

  // Calculate the total style/layout duration:
  const styleLayoutDuration = endTime - styleAndLayoutStart; // 111.32307691

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running style and layout operation:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

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

लंबे समय से चल रहे requestAnimationFrame कॉलबैक

प्रज़ेंटेशन में देरी होने की एक वजह यह भी हो सकती है कि requestAnimationFrame कॉलबैक में बहुत ज़्यादा काम किया गया हो. इस कॉलबैक का कॉन्टेंट, इवेंट हैंडलर के पूरा होने के बाद ही लागू होता है. हालांकि, यह स्टाइल रीकैलकुलेशन और लेआउट के काम करने से पहले लागू होती है.

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

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 543.1999999880791

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  // Get the render start time and when style and layout began:
  const {renderStart} = loaf;         // 2489
  const {styleAndLayoutStart} = loaf; // 2989.5999999940395

  // Calculate the `requestAnimationFrame` callback's duration:
  const rafDuration = styleAndLayoutStart - renderStart; // 500.59999999403954

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running requestAnimationFrame callback:
    const {invokerType} = script;        // 'user-callback'
    const {invoker} = script;            // 'FrameRequestCallback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

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

नतीजा

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

Unsplash की हीरो इमेज, इसे फ़ेदेरिको रेस्पिनी ने बनाया है.