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

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

Jeremy Wagner

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

इस गाइड में, आपको यह जानने का तरीका मिलेगा कि Chrome User Experience Report (CrUX) से मिले फ़ील्ड डेटा का इस्तेमाल करके, अपनी वेबसाइट के आईएनपी का तुरंत आकलन कैसे करें. इससे आपको यह पता चलेगा कि आपकी वेबसाइट में आईएनपी से जुड़ी समस्याएं हैं या नहीं. इसके बाद, आपको web-vitals JavaScript लाइब्रेरी के एट्रिब्यूशन बिल्ड का इस्तेमाल करने का तरीका बताया जाएगा. साथ ही, Long Animation Frames API (LoAF) से मिलने वाली नई अहम जानकारी का इस्तेमाल करके, अपनी वेबसाइट पर धीमी इंटरैक्शन के लिए फ़ील्ड डेटा इकट्ठा करने और उसकी व्याख्या करने का तरीका बताया जाएगा.

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

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

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

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

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

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

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

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

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

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 के मुकाबले ज़्यादा जानकारी नहीं मिलती. ऐसे में, web-vitals लाइब्रेरी का एट्रिब्यूशन बिल्ड काम आता है.

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

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

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

onINP(({name, value, rating, attribution}) => {
  console.log(name);         // 'INP'
  console.log(value);        // 56
  console.log(rating);       // 'good'
  console.log(attribution);  // Attribution data object
});

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

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

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

web-vitals लाइब्रेरी के वर्शन 4 से, आपको समस्या वाली इंटरैक्शन के बारे में ज़्यादा जानकारी मिल सकती है. इसके लिए, यह लाइब्रेरी INP के फ़ेज़ के ब्रेकडाउन (इनपुट में देरी, प्रोसेसिंग में लगने वाला समय, और प्रज़ेंटेशन में देरी) और Long Animation Frames API (LoAF) के साथ डेटा उपलब्ध कराती है.

Long Animation Frames API (LoAF)

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

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

इस सारी जानकारी से, आपको यह पता चल सकता है कि इंटरैक्शन धीमा क्यों है. हालांकि, 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.toSorted((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 डेटा का इस्तेमाल करके, ज़्यादा प्रोसेसिंग अवधि वाली वैल्यू के साथ इंटरैक्शन की सटीक वजह का पता लगाया जा सकता है. जैसे:

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

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

इनपुट में ज़्यादा समय लगना

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

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

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

प्रज़ेंटेशन में ज़्यादा देरी होना

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

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

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

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

स्टाइल और लेआउट पर ज़्यादा खर्च करना

प्रेज़ेंटेशन में ज़्यादा समय लगने की वजह से, स्टाइल को फिर से कैलकुलेट करने और लेआउट को ठीक करने में ज़्यादा समय लग सकता है. इसकी कई वजहें हो सकती हैं. जैसे, जटिल सीएसएस सेलेक्टर और बड़े DOM साइज़. वेब-vitals लाइब्रेरी में 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.toSorted((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 से आपको यह नहीं पता चलेगा कि किसी फ़्रेम के लिए स्टाइल और लेआउट का काम कितने समय तक चला. हालांकि, इससे आपको यह पता चलेगा कि यह काम कब शुरू हुआ. इस शुरुआती टाइमस्टैंप की मदद से, LoAF के अन्य डेटा का इस्तेमाल करके, उस काम की सही अवधि का हिसाब लगाया जा सकता है. इसके लिए, फ़्रेम के खत्म होने का समय तय करें. इसके बाद, स्टाइल और लेआउट के काम के शुरुआती टाइमस्टैंप को उस समय से घटाएं.

लंबे समय तक चलने वाले requestAnimationFrame कॉलबैक

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

अगर इन कॉलबैक में किया गया काम मुश्किल है, तो इन्हें पूरा होने में काफ़ी समय लग सकता है. अगर आपको लगता है कि requestAnimationFrame के साथ काम करने की वजह से, प्रज़ेंटेशन में देरी की वैल्यू ज़्यादा हैं, तो इन स्थितियों का पता लगाने के लिए, web-vitals लाइब्रेरी से मिले 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.toSorted((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 कॉलबैक में लगता है, तो पक्का करें कि इन कॉलबैक में किया जा रहा काम सिर्फ़ यूज़र इंटरफ़ेस में अपडेट करने से जुड़ा हो. DOM में बदलाव न करने या स्टाइल अपडेट न करने वाले किसी भी अन्य काम से, अगले फ़्रेम को रेंडर होने में बेवजह देरी होगी. इसलिए, सावधान रहें!

नतीजा

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

Unsplash से ली गई हीरो इमेज. इसे Federico Respini ने बनाया है.