नेक्स्ट पेंट के इंटरैक्शन को मेज़र करना (आईएनपी)

1. परिचय

यह एक इंटरैक्टिव कोडलैब है. इसमें web-vitals लाइब्रेरी का इस्तेमाल करके, पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को मेज़र करने का तरीका बताया गया है.

ज़रूरी शर्तें

• एचटीएमएल और JavaScript डेवलपमेंट की जानकारी.
• सुझाया गया तरीका: web.dev पर INP मेट्रिक से जुड़ा दस्तावेज़ पढ़ें.

आपको क्या-क्या सीखने को मिलेगा

• अपने पेज में web-vitals लाइब्रेरी जोड़ने और उसके एट्रिब्यूशन डेटा का इस्तेमाल करने का तरीका.
• एट्रिब्यूशन डेटा का इस्तेमाल करके, यह पता लगाएं कि आईएनपी को कहां और कैसे बेहतर बनाया जा सकता है.

आपको इनकी ज़रूरत होगी

• ऐसा कंप्यूटर जिसमें GitHub से कोड क्लोन करने और npm कमांड चलाने की सुविधा हो.
• टेक्स्ट एडिटर.
• सभी इंटरैक्शन मेज़रमेंट के काम करने के लिए, Chrome का नया वर्शन.

2. सेट अप करें

कोड पाना और उसे चलाना

यह कोड, web-vitals-codelabs रिपॉज़िटरी में मौजूद है.

1. अपने टर्मिनल में रेपो को क्लोन करें: git clone https://github.com/GoogleChromeLabs/web-vitals-codelabs.git.
2. क्लोन की गई डायरेक्ट्री में जाएं: cd web-vitals-codelabs/measuring-inp.
3. डिपेंडेंसी इंस्टॉल करें: npm ci.
4. वेब सर्वर शुरू करें: npm run start.
5. अपने ब्राउज़र में http://localhost:8080/ पर जाएं.

पेज को आज़माएँ

इस कोडलैब में, Gastropodicon (घोंघे की शारीरिक बनावट के बारे में जानकारी देने वाली लोकप्रिय साइट) का इस्तेमाल किया गया है. इससे INP से जुड़ी संभावित समस्याओं के बारे में पता लगाया जा सकता है.

पेज के साथ इंटरैक्ट करके देखें. इससे आपको पता चलेगा कि कौनसे इंटरैक्शन धीमे हैं.

3. Chrome DevTools का इस्तेमाल शुरू करना

ज़्यादा टूल > डेवलपर टूल मेन्यू से DevTools खोलें. इसके लिए, पेज पर राइट क्लिक करके जांच करें को चुनें या कीबोर्ड शॉर्टकट का इस्तेमाल करें.

इस कोडलैब में, हम परफ़ॉर्मेंस पैनल और कंसोल, दोनों का इस्तेमाल करेंगे. DevTools में सबसे ऊपर मौजूद टैब में जाकर, इनके बीच कभी भी स्विच किया जा सकता है.

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

4. web-vitals इंस्टॉल करना

web-vitals एक JavaScript लाइब्रेरी है. इसका इस्तेमाल, उपयोगकर्ताओं को मिलने वाले अनुभव के आधार पर Web Vitals मेट्रिक को मेज़र करने के लिए किया जाता है. इन वैल्यू को कैप्चर करने के लिए, लाइब्रेरी का इस्तेमाल किया जा सकता है. इसके बाद, इन्हें Analytics के एंडपॉइंट पर भेजा जा सकता है, ताकि बाद में इनका विश्लेषण किया जा सके. इससे हमें यह पता लगाने में मदद मिलती है कि धीमे इंटरैक्शन कब और कहां होते हैं.

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

यह कोडलैब, npm से इंस्टॉल होगा और स्क्रिप्ट को सीधे तौर पर लोड करेगा, ताकि किसी खास बिल्ड प्रोसेस में न जाना पड़े.

web-vitals के दो वर्शन उपलब्ध हैं:

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

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

npm install -D web-vitals चलाकर, web-vitals को प्रोजेक्ट के devDependencies में जोड़ें

पेज में web-vitals जोड़ने के लिए:

स्क्रिप्ट के एट्रिब्यूशन वर्शन को index.html के सबसे नीचे जोड़ें और नतीजों को कंसोल में लॉग करें:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log);
</script>

इसे आज़माएं

कंसोल खुला रखकर, पेज के साथ फिर से इंटरैक्ट करने की कोशिश करें. पेज पर क्लिक करने पर, कुछ भी लॉग नहीं होता!

आईएनपी को किसी पेज के पूरे लाइफ़साइकल के दौरान मेज़र किया जाता है. इसलिए, डिफ़ॉल्ट रूप से web-vitals, उपयोगकर्ता के पेज छोड़ने या बंद करने तक आईएनपी की रिपोर्ट नहीं करता. यह Analytics जैसे टूल के लिए बीकन भेजने का सबसे सही तरीका है. हालांकि, इंटरैक्टिव तरीके से डीबग करने के लिए यह तरीका सही नहीं है.

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

स्क्रिप्ट में विकल्प जोड़कर, पेज से फिर से इंटरैक्ट करने की कोशिश करें:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log, {reportAllChanges: true});
</script>

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

5. एट्रिब्यूशन में क्या-क्या शामिल होता है?

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

कई पेजों पर ऐसी स्क्रिप्ट होती हैं जिनके लिए, उपयोगकर्ता की ओर से कुकी स्वीकार किए जाने पर, कुकी को सिंक्रोनस तरीके से ट्रिगर करना ज़रूरी होता है. इससे क्लिक करने पर, इंटरैक्शन धीरे-धीरे होता है. यहां भी ऐसा ही होता है.

(डेमो) कुकी स्वीकार करने के लिए, हां पर क्लिक करें. अब DevTools कंसोल में लॉग किए गए INP डेटा को देखें.

यह टॉप-लेवल की जानकारी, वेब-वाइटल के स्टैंडर्ड और एट्रिब्यूशन, दोनों वर्शन में उपलब्ध है:

{
  name: 'INP',
  value: 344,
  rating: 'needs-improvement',
  entries: [...],
  id: 'v4-1715732159298-8028729544485',
  navigationType: 'reload',
  attribution: {...},
}

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

हालांकि, इस दौरान क्या हो रहा है, यह जानने के लिए हमें attribution प्रॉपर्टी में सबसे ज़्यादा दिलचस्पी है. एट्रिब्यूशन डेटा बनाने के लिए, web-vitals यह पता लगाता है कि कौनसा लॉन्ग ऐनिमेशन फ़्रेम (एलओएएफ़), क्लिक इवेंट के साथ ओवरलैप होता है. इसके बाद, LoAF इस बारे में ज़्यादा जानकारी दे सकता है कि उस फ़्रेम के दौरान कितना समय खर्च हुआ. इसमें स्क्रिप्ट चलाने से लेकर, requestAnimationFrame कॉलबैक, स्टाइल, और लेआउट में खर्च हुआ समय शामिल है.

ज़्यादा जानकारी देखने के लिए, attribution प्रॉपर्टी को बड़ा करें. डेटा ज़्यादा बेहतर होता है.

attribution: {
  interactionTargetElement: Element,
  interactionTarget: '#confirm',
  interactionType: 'pointer',

  inputDelay: 27,
  processingDuration: 295.6,
  presentationDelay: 21.4,

  processedEventEntries: [...],
  longAnimationFrameEntries: [...],
}

सबसे पहले, यह जानकारी होती है कि किस आइटम के साथ इंटरैक्ट किया गया:

• interactionTargetElement: उस एलिमेंट का लाइव रेफ़रंस जिसके साथ इंटरैक्ट किया गया था. हालांकि, ऐसा तब होता है, जब एलिमेंट को डीओएम से न हटाया गया हो.
• interactionTarget: पेज में मौजूद एलिमेंट को ढूंढने के लिए सिलेक्टर.

इसके बाद, समय को बड़े लेवल पर बांटा गया है:

• inputDelay: यह वह समय होता है जब उपयोगकर्ता ने इंटरैक्शन शुरू किया था. उदाहरण के लिए, माउस पर क्लिक किया था. साथ ही, यह वह समय होता है जब उस इंटरैक्शन के लिए इवेंट लिसनर ने काम करना शुरू किया था. इस मामले में, सीपीयू थ्रॉटलिंग चालू होने के बावजूद, इनपुट में सिर्फ़ 27 मिलीसेकंड की देरी हुई.
• processingDuration: इवेंट लिसनर को पूरा होने में लगने वाला समय. अक्सर, पेजों पर एक इवेंट के लिए कई लिसनर होते हैं. उदाहरण के लिए, pointerdown, pointerup, और click. अगर ये सभी एक ही ऐनिमेशन फ़्रेम में चलते हैं, तो इन्हें इस समय में शामिल कर दिया जाएगा. इस मामले में, प्रोसेस होने में 295.6 मिलीसेकंड लगते हैं. यह INP का ज़्यादातर समय होता है.
• presentationDelay: इवेंट लिसनर के पूरा होने से लेकर ब्राउज़र के अगले फ़्रेम को पेंट करने तक का समय. इस मामले में, 21.4 मिलीसेकंड.

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

ज़्यादा जानकारी के लिए, टॉप-लेवल INP entries ऐरे में सिर्फ़ एक इवेंट के मुकाबले, processedEventEntries में पांच इवेंट शामिल हैं. इन दोनों में क्या अंतर है?

processedEventEntries: [
  {
    name: 'mouseover',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {
    name: 'mousedown',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {name: 'mousedown', ...},
  {name: 'mouseup', ...},
  {name: 'click', ...},
],

सबसे ऊपर वाली एंट्री, the INP इवेंट है. इस मामले में, यह क्लिक है. एट्रिब्यूशन processedEventEntries, वे सभी इवेंट हैं जिन्हें एक ही फ़्रेम के दौरान प्रोसेस किया गया था. ध्यान दें कि इसमें क्लिक इवेंट के अलावा, mouseover और mousedown जैसे अन्य इवेंट भी शामिल हैं. अगर ये अन्य इवेंट भी धीमे थे, तो इनके बारे में जानना ज़रूरी हो सकता है. ऐसा इसलिए, क्योंकि इन सभी इवेंट की वजह से पेज धीमे रिस्पॉन्स कर रहा था.

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

longAnimationFrameEntries

LoAF एंट्री को बड़ा करना:

longAnimationFrameEntries: [{
  name: 'long-animation-frame',
  startTime: 1823,
  duration: 319,

  renderStart: 2139.5,
  styleAndLayoutStart: 2139.7,
  firstUIEventTimestamp: 1801.6,
  blockingDuration: 268,

  scripts: [{...}]
}],

यहां कई काम की वैल्यू मौजूद हैं. जैसे, स्टाइलिंग में बिताए गए समय की जानकारी. Long Animation Frames API के बारे में लेख में, इन प्रॉपर्टी के बारे में ज़्यादा जानकारी दी गई है. फ़िलहाल, हमारा मुख्य फ़ोकस scripts प्रॉपर्टी पर है. इसमें ऐसी एंट्री होती हैं जो लंबे समय तक चलने वाले फ़्रेम के लिए ज़िम्मेदार स्क्रिप्ट के बारे में जानकारी देती हैं:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 1828.6,
  executionStart: 1828.6,
  duration: 294,

  sourceURL: 'http://localhost:8080/third-party/cmp.js',
  sourceFunctionName: '',
  sourceCharPosition: 1144
}]

इस मामले में, हम बता सकते हैं कि ज़्यादातर समय एक ही event-listener में बिताया गया. इसे BUTTON#confirm.onclick पर शुरू किया गया था. हम स्क्रिप्ट के सोर्स यूआरएल और उस वर्ण की पोज़िशन को भी देख सकते हैं जहां फ़ंक्शन को तय किया गया था!

सीखने लायक अहम बातें

इस एट्रिब्यूशन डेटा से, इस मामले के बारे में क्या पता लगाया जा सकता है?

• यह इंटरैक्शन, button#confirm एलिमेंट पर क्लिक करने से ट्रिगर हुआ था. यह एलिमेंट, attribution.interactionTarget और स्क्रिप्ट एट्रिब्यूशन एंट्री की invoker प्रॉपर्टी से मिला था.
• ज़्यादातर समय, इवेंट लिसनर को एक्ज़ीक्यूट करने में लगा. यह समय, attribution.processingDuration की तुलना में कुल मेट्रिक value से ज़्यादा है.
• इवेंट लिसनर के धीमे कोड की शुरुआत, third-party/cmp.js में तय किए गए क्लिक लिसनर (scripts.sourceURL से) से होती है.

हमें यह जानने के लिए इतना डेटा काफ़ी है कि हमें कहां ऑप्टिमाइज़ेशन करने की ज़रूरत है!

6. एक से ज़्यादा इवेंट लिसनर

पेज को रीफ़्रेश करें, ताकि DevTools कंसोल साफ़ हो जाए और कुकी के लिए सहमति लेने से जुड़ा इंटरैक्शन, सबसे लंबा इंटरैक्शन न रहे.

खोज बॉक्स में टाइप करना शुरू करें. एट्रिब्यूशन डेटा से क्या पता चलता है? आपको क्या लगता है कि क्या हो रहा है?

एट्रिब्यूशन डेटा

सबसे पहले, डेमो को टेस्ट करने के एक उदाहरण की खास जानकारी:

{
  name: 'INP',
  value: 1072,
  rating: 'poor',
  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'keyboard',

    inputDelay: 3.3,
    processingDuration: 1060.6,
    presentationDelay: 8.1,

    processedEventEntries: [...],
    longAnimationFrameEntries: [...],
  }
}

यह input#search-terms एलिमेंट के साथ कीबोर्ड इंटरैक्शन से मिली आईएनपी की खराब वैल्यू है. इसमें सीपीयू थ्रॉटलिंग चालू है. ज़्यादातर समय, यानी कि कुल 1072 मिलीसेकंड में से 1061 मिलीसेकंड, प्रोसेसिंग में लगा.

हालांकि, scripts की एंट्री ज़्यादा दिलचस्प हैं.

लेआउट थ्रैशिंग

scripts ऐरे की पहली एंट्री से हमें कुछ अहम जानकारी मिलती है:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 4875.6,
  executionStart: 4875.6,
  duration: 497,
  forcedStyleAndLayoutDuration: 388,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'handleSearch',
  sourceCharPosition: 940
},
...]

प्रोसेसिंग में लगने वाला ज़्यादातर समय, स्क्रिप्ट को एक्ज़ीक्यूट करने के दौरान लगता है. यह एक input लिसनर है (इनवोकर INPUT#search-terms.oninput है). फ़ंक्शन का नाम (handleSearch) दिया गया है. साथ ही, index.js सोर्स फ़ाइल में वर्ण की पोज़िशन भी दी गई है.

हालांकि, एक नई प्रॉपर्टी है: forcedStyleAndLayoutDuration. यह स्क्रिप्ट को शुरू करने में लगा समय है. इस दौरान, ब्राउज़र को पेज का लेआउट फिर से तय करना पड़ा. दूसरे शब्दों में कहें, तो इस इवेंट लिसनर को एक्ज़ीक्यूट करने में लगे कुल समय का 78% समय लेआउट थ्रैशिंग में लगा. यानी, 497 मिलीसेकंड में से 388 मिलीसेकंड.

इस समस्या को ठीक करना सबसे ज़रूरी है.

बार-बार सुनने वाले लोग

अगली दो स्क्रिप्ट एंट्री में, अलग-अलग तौर पर कुछ खास नहीं है:

scripts: [...,
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5375.3,
  executionStart: 5375.3,
  duration: 124,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526,
},
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5673.9,
  executionStart: 5673.9,
  duration: 95,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526
}]

दोनों एंट्री keyup लिसनर हैं, जो एक के बाद एक काम करती हैं. लिसनर, एनॉनिमस फ़ंक्शन होते हैं. इसलिए, sourceFunctionName प्रॉपर्टी में कुछ भी रिपोर्ट नहीं किया जाता. हालांकि, हमारे पास अब भी सोर्स फ़ाइल और कैरेक्टर की पोज़िशन होती है. इसलिए, हम यह पता लगा सकते हैं कि कोड कहां है.

हालांकि, दोनों एक ही सोर्स फ़ाइल और वर्ण की पोज़िशन से हैं.

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

इस समस्या की वजह से, इवेंट लिसनर को पूरा होने में ज़्यादा समय लगता है. साथ ही, इनपुट इवेंट की संख्या भी बढ़ जाती है. इससे इंटरैक्शन धीमा हो जाता है.

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

7. इनपुट में देरी

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

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

डेमो पेज में एक सीक्रेट सुविधा है. अगर पेज पर सबसे ऊपर मौजूद घोंघे के लोगो पर क्लिक किया जाता है, तो वह ऐनिमेशन करने लगेगा. साथ ही, मुख्य थ्रेड पर JavaScript का कुछ मुश्किल काम करने लगेगा.

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

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

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

यहां खोज बॉक्स पर फ़ोकस करने के दौरान, स्नेल बाउंस के एट्रिब्यूशन का उदाहरण दिया गया है:

{
  name: 'INP',
  value: 728,
  rating: 'poor',

  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'pointer',

    inputDelay: 702.3,
    processingDuration: 4.9,
    presentationDelay: 20.8,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 2064.8,
      duration: 790,

      renderStart: 2065,
      styleAndLayoutStart: 2854.2,
      firstUIEventTimestamp: 0,
      blockingDuration: 740,

      scripts: [{...}]
    }]
  }
}

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

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

LoAF स्क्रिप्ट की ये एंट्री, आपकी मदद कर सकती हैं:

scripts: [{
  name: 'script',
  invoker: 'SPAN.onanimationiteration',
  invokerType: 'event-listener',

  startTime: 2065,
  executionStart: 2065,
  duration: 788,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'cryptodaphneCoinHandler',
  sourceCharPosition: 1831
}]

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

इससे हमें यह पता चलता है कि इंटरैक्शन प्रोसेसिंग में देरी करने वाले फ़ंक्शन को कैसे ट्रिगर किया गया (animationiteration लिसनर के ज़रिए), इसके लिए कौनसा फ़ंक्शन ज़िम्मेदार था, और यह हमारी सोर्स फ़ाइलों में कहां मौजूद था.

8. प्रज़ेंटेशन में देरी: जब कोई अपडेट पेंट नहीं होता है

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

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

यह प्रोसेस कैसे काम करती है?

{
  name: 'INP',
  value: 376,
  rating: 'needs-improvement',
  delta: 352,

  attribution: {
    interactionTarget: '#sidenav-button>svg',
    interactionType: 'pointer',

    inputDelay: 12.8,
    processingDuration: 14.7,
    presentationDelay: 348.5,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 651,
      duration: 365,

      renderStart: 673.2,
      styleAndLayoutStart: 1004.3,
      firstUIEventTimestamp: 138.6,
      blockingDuration: 315,

      scripts: [{...}]
    }]
  }
}

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

scripts: [{
  entryType: 'script',
  invoker: 'FrameRequestCallback',
  invokerType: 'user-callback',

  startTime: 673.8,
  executionStart: 673.8,
  duration: 330,

  sourceURL: 'http://localhost:8080/js/side-nav.js',
  sourceFunctionName: '',
  sourceCharPosition: 1193,
}]

scripts कलेक्शन में मौजूद एक एंट्री से पता चलता है कि FrameRequestCallback से user-callback में समय बिताया गया है. इस बार, प्रज़ेंटेशन में देरी requestAnimationFrame कॉलबैक की वजह से हो रही है.

9. नतीजा

फ़ील्ड डेटा को एग्रीगेट करना

यह ध्यान रखना ज़रूरी है कि एक पेज लोड से, INP एट्रिब्यूशन की एक एंट्री देखने पर यह सब आसान हो जाता है. फ़ील्ड डेटा के आधार पर INP को डीबग करने के लिए, इस डेटा को कैसे इकट्ठा किया जा सकता है? काम की ज़्यादा जानकारी होने की वजह से, इसे समझना मुश्किल हो जाता है.

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

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

इसी तरह, scripts एंट्री के sourceURL पाथ में फ़ाइल-आधारित हैश हो सकते हैं. इससे उन्हें एक साथ जोड़ना मुश्किल हो जाता है. हालांकि, डेटा को वापस बीकन करने से पहले, अपनी जानी-पहचानी बिल्ड प्रोसेस के आधार पर हैश हटाए जा सकते हैं.

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

हर जगह क्रेडिट देना!

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

अब किसी भी साइट पर आईएनपी एट्रिब्यूशन डेटा का इस्तेमाल किया जा सकता है!

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

const script = document.createElement('script');
script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';
script.onload = function () {
  webVitals.onINP(console.log, {reportAllChanges: true});
};
document.head.appendChild(script);

ज़्यादा जानें

• web.dev: पेज के रिस्पॉन्स में लगने वाला समय
• web.dev: फ़ील्ड में धीमे इंटरैक्शन ढूंढना
• web.dev: पेज के रिस्पॉन्स में लगने वाले समय को ऑप्टिमाइज़ करना
• आईएनपी कोडलैब के बारे में जानकारी