सेवन ब्रांचेस में विफल आईएनपी को कोड की उस पंक्ति तक ट्रेस करें

लाल INP स्कोर तब तक परफॉर्मेंस की समस्या नहीं है जब तक आपको यह पता न चल जाए कि तीन चरणों में से कौन सा चरण समय बर्बाद कर रहा है। ज़्यादातर टीमें इस चरण को छोड़ देती हैं, कैशिंग प्लगइन खरीद लेती हैं या स्क्रिप्ट को टाल देती हैं, और फिर भी 75वें परसेंटाइल में कोई बदलाव नहीं होता। यह गाइड एक निर्णय वृक्ष की तरह है जिसे हम इस्तेमाल करते हैं: सात शाखाएँ जो आपको Chrome UX रिपोर्ट के खराब प्रदर्शन से लेकर ज़िम्मेदार विशिष्ट हैंडलर, स्क्रिप्ट या थर्ड-पार्टी टैग तक ले जाती हैं, और हर शाखा पर एक निर्धारित सीमा होती है। यह फ्रंट-एंड लीड्स और ग्रोथ टीमों के लिए लिखी गई है जिनके पास कन्वर्ज़न नंबर और लाइटहाउस स्कोर दोनों होते हैं।

यह अंतर वास्तविक है। 2025 वेब पंचांग में, 77% मोबाइल स्रोतों का INP अच्छा था। डेस्कटॉप पर 97% के मुकाबले, और केवल मोबाइल स्रोतों में से 48% ने तीनों कोर वेब विटल्स को पास कर लिया। (HTTP संग्रहमोबाइल पर अभी भी जो समस्या बनी हुई है, वह मुख्य रूप से इंटरैक्शन लेटेंसी है, और इसका निदान काफी हद तक संभव है।

आईएनपी किन चीजों का मापन करता है, और किन चीजों को वह चुपचाप अनदेखा करता है

नेक्स्ट पेंट के साथ इंटरैक्शन प्रति पृष्ठ विज़िट पर एक इंटरैक्शन विलंबता की रिपोर्ट करता है, 75th प्रतिशत आपके मूल स्थान के पार। अच्छा है 200 एमएस या उससे कम200 मिलीसेकंड से 500 मिलीसेकंड तक के समय में सुधार की आवश्यकता है, जबकि 500 ​​मिलीसेकंड से ऊपर का समय खराब माना जाता है।वेब.देवउस परिभाषा के बारे में तीन बातें इसे डीबग करने के तरीके को बदल देती हैं:

• केवल क्लिक, टैप और की-प्रेस ही मायने रखते हैं। होवर करना, ज़ूम करना और स्क्रॉलिंग को मापा नहीं जाता हैइसलिए, एक खराब स्क्रॉलिंग से पेज टूटा हुआ महसूस हो सकता है जबकि आईएनपी हरा रहता है।
• कई अंतःक्रियाओं वाले पृष्ठों पर, आईएनपी प्रत्येक 50 में से एक उच्चतम इंटरैक्शन को अनदेखा करता हैइसलिए, कोई दुर्लभ और विनाशकारी घटना उच्च-सहभागिता वाले पृष्ठ पर छिपी रह सकती है और कम-सहभागिता वाले पृष्ठ पर सामने आ सकती है।
• प्रत्येक अंतःक्रिया विभाजित हो जाती है इनपुट विलंब (आपके हैंडलर चलने से पहले), प्रसंस्करण अवधि (आपके हैंडलर चल रहे हैं) और प्रस्तुति में देरी (आपके हैंडलर के बाद, फ्रेम पेंट से पहले)। इंजीनियरिंग समस्याओं के रूप में इन तीनों में लगभग कुछ भी समान नहीं है (वेब.देव).

अंतिम बिंदु ही पूरी विधि है। आप "INP" को डीबग नहीं कर रहे हैं। आप तीन चरणों में से किसी एक को डीबग कर रहे हैं, और प्रत्येक चरण का समाधान अलग-अलग है।

शाखा 0: कोड में बदलाव करने से पहले संख्या की वास्तविकता की पुष्टि करें

PageSpeed ​​Insights खोलें और फ़ील्ड सेक्शन पढ़ें, लैब स्कोर नहीं। लैब टूल्स INP को माप नहीं सकते, क्योंकि INP के लिए किसी वास्तविक उपयोगकर्ता द्वारा कुछ दबाने की आवश्यकता होती है। यदि स्रोत में कोई फ़ील्ड डेटा नहीं है, तो आपको ट्रैफ़िक की समस्या है, प्रदर्शन की नहीं, और नीचे दी गई कोई भी बात अभी लागू नहीं होती। फिर मोबाइल और डेस्कटॉप का डेटा अलग-अलग लें — वैश्विक स्तर पर 2025 में इनमें 20 प्रतिशत अंकों का अंतर था। यदि मोबाइल का स्कोर लाल है और डेस्कटॉप का स्कोर हरा है, तो अपने लैपटॉप पर परीक्षण बंद कर दें।

शाखा 1: क्या धीमी प्रतिक्रिया लोडिंग के दौरान हो रही है या उसके बाद?

क्षेत्र को उपकरणों से सुसज्जित करें web-vitals एट्रिब्यूशन बिल्ड। चार पंक्तियों में आपको डेटा मिल जाएगा:

import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});

पढ़ना attribution.loadState सबसे पहले। यदि अधिकांश खराब अंतःक्रियाओं में लोड स्थिति होती है लोड हो रहा है or डोम-इंटरएक्टिवयदि उपयोगकर्ता आपके स्क्रिप्ट के मूल्यांकन के दौरान ही टैप कर रहे हैं, तो यह एक डिलीवरी समस्या है, जिसे बंडल और टैग मैनेजर में ठीक किया जा सकता है, हैंडलर में नहीं। यदि खराब इंटरैक्शन पूरी तरह से लोड किए गए पृष्ठों पर फैले हुए हैं, तो ब्रांच 2 पर जाएं।

शाखा 2: समय का स्वामित्व किस उपभाग के पास है?

लॉग इन inputDelay, processingDuration और presentationDelay प्रत्येक नमूने के लिए। हमारा कार्य नियम: एक उपभाग अंतःक्रिया का स्वामी तब होता है जब वह इसके लिए जिम्मेदार होता है। कुल आईएनपी के 50% से अधिकयदि कोई भी 50% से अधिक नहीं होता है, तो पहले इसे इनपुट-विलंब का मामला मानें - आमतौर पर मुख्य थ्रेड में व्याप्त भीड़ ही अन्य दो समस्याओं को और खराब करती है।

शाखा 3: स्क्रिप्ट का नाम दें

एट्रिब्यूशन बिल्ड में प्रत्येक आईएनपी सैंपल के साथ लॉन्ग एनिमेशन फ्रेम प्रविष्टियाँ शामिल होती हैं। attribution.longestScript यह आपको उस इंटरेक्शन में सबसे खराब स्क्रिप्ट के लिए इनवोकर, फ़ंक्शन और सोर्स फ़ाइल देता है; totalScriptDuration यह 5 मिलीसेकंड से अधिक समय में सब कुछ एकत्रित करता है। यहीं पर "रिएक्ट धीमा है" जैसा अस्पष्ट कथन एक फ़ाइल पथ में बदल जाता है। इनवोकर प्रकार की जाँच करें: classic-script or module-script लोड-टाइम मूल्यांकन पर ध्यान केंद्रित करते हुए user-callback or event-listener लोड होने के बाद चलने वाली किसी चीज़ की ओर इशारा करता है — एक ऑब्ज़र्वर, एक टाइमर, एक एनालिटिक्स लिसनर (वेब.देव).

शाखा 4: क्या यह आपकी है या किसी तीसरे पक्ष की?

अपनी स्क्रिप्ट के स्रोत के आधार पर एट्रिब्यूशन को क्रमबद्ध करें। टैग मैनेजर, सहमति प्लेटफ़ॉर्म, सेशन रिकॉर्डिंग टूल और चैट विजेट वैश्विक लिसनर इंस्टॉल करते हैं जो हर क्लिक पर आपके लिसनर से पहले चलते हैं। यदि आपके सबसे खराब नमूनों में से एक चौथाई से अधिक में किसी तृतीय-पक्ष स्रोत का उल्लेख मिलता है, तो इसका समाधान तकनीकी से पहले व्यावसायिक है: टैग का दायरा कम करें, इसे इंटरैक्शन पर लोड करें, या इसे सर्वर-साइड पर ले जाएं। चैट विजेट द्वारा खर्च किए जाने वाले 40 मिलीसेकंड के समय को वापस पाने के लिए अपने हैंडलर को रिफैक्टर न करें।

शाखा 5: इसे प्रयोगशाला में पुन: प्रस्तुत करें, फिर फ्रेम को ठीक करें

चयनकर्ता को बाहर निकालें attribution.interactionTargetअपने फील्ड डिवाइस के अनुसार सीपीयू थ्रॉटलिंग को सेट करके क्रोम डेवलपर टूल्स खोलें और इंटरैक्शन रिकॉर्ड करें। किसी ऐसे टास्क की तलाश करें जो इससे अधिक समय तक चले। 50 एमएस, दीर्घ-कार्य सीमा (वेब.देव), और इसे उपज द्वारा विभाजित करें।

जहाज scheduler.yield() फ़ॉलबैक के साथ। क्रोम और एज इसे 129 से और फ़ायरफ़ॉक्स इसे 142 से सपोर्ट करते हैं, लेकिन Safari डेस्कटॉप या iOS पर ऐसा नहीं करता है।और एमडीएन इसे बेसलाइन के बजाय सीमित उपलब्धता के रूप में चिह्नित करता है (एमडीएन, क्या में उपयोग कर सकता हूँ). iOS उपयोगकर्ताओं की बड़ी संख्या वाले तुर्की या खाड़ी दर्शकों के लिए, setTimeout फ़ॉलबैक वैकल्पिक नहीं है।

शाखा 6: उस बाज़ार का आकलन करें जिसमें आप वास्तव में अपना सामान बेचते हैं।

वैश्विक CrUX औसत उस बाजार को छुपाते हैं जो आपको भुगतान करता है। CrUX BigQuery डेटासेट देश-वार तालिकाएँ प्रकाशित करता है। chrome-ux-report.country_tr.YYYYMM तुर्की के लिए, किसी भी दो-अक्षर वाले देश कोड के लिए समान पैटर्न - मासिक रूप से अपडेट किया जाता है, जिसमें डिवाइस फॉर्म फैक्टर और प्रभावी कनेक्शन प्रकार आयाम के रूप में होते हैं (डेवलपर्स के लिए क्रोम). सार्वजनिक CrUX API देश को उजागर नहीं करता है, इसलिए यह स्लाइस केवल BigQuery के लिए है।

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

शाखा 7: साबित करें कि इसने कुछ स्थानांतरित किया है

इस सुधार को प्रयोग के तौर पर लें, इसे लागू न करें। ट्रेंडियोलएक तुर्की बाज़ार ने 963 मिलीसेकंड के मोबाइल आईएनपी का पता लगाया, जो एक रिएक्ट कंपोनेंट के अंदर इंटरसेक्शनऑब्जर्वर कॉलबैक के कारण होने वाले 700-900 मिलीसेकंड लंबे कार्य से संबंधित था, और स्टेट अपडेट को स्थगित कर दिया। scheduler.yield()और छह महीनों में 75वें प्रतिशत INP को लगभग 1,400 मिलीसेकंड से घटाकर लगभग 650 मिलीसेकंड कर दिया। इसके A/B परीक्षण से पता चला कि... प्रति सत्र लिस्टिंग से उत्पाद विवरण तक क्लिक-थ्रू में 1% की वृद्धि (वेब.देव). redBus लेज़ी-लोड इंटरैक्शन का समय 870–900 मिलीसेकंड से घटाकर 350–370 मिलीसेकंड कर दिया, टेक्स्ट-इनपुट इंटरैक्शन में 72% सुधार किया और एक रिपोर्ट दी कुल बिक्री में 7% की वृद्धि (वेब.देव).

ध्यान दें कि पैमाना ईमानदार है: 1%, न कि 40%। और यही हमें एक ऐसे आंकड़े की ओर ले जाता है जिसे सुधारने की आवश्यकता है।

8.4% के आंकड़े पर एक चेतावनी देना आवश्यक है।

इस क्षेत्र में सबसे अधिक उद्धृत आंकड़ा यह है कि मोबाइल स्पीड में 0.1 सेकंड का सुधार खुदरा बिक्री में 8.4% और यात्रा में 10.1% की वृद्धि करता है। यह एक वास्तविक अध्ययन से आया है - 55 और डेलॉइट द्वारा गूगल के लिए प्रायोजित, 37 ब्रांड, 30 मिलियन से अधिक सत्र।वेब.देवलेकिन इसने पेज लोड समय और सर्वर विलंबता जैसे लोड मेट्रिक्स को मापा। आईएनपी नहींयह डेटा 2019 के अंत के 30 दिनों का है; और इसमें कोई नियंत्रण समूह नहीं था, इसलिए यह एक प्रेक्षित सहसंबंध है, न कि कारण-कार्य संबंध। इसका उपयोग बजट संबंधी चर्चा शुरू करने के लिए करें, न कि किसी इंटरैक्शन-लेटेंसी फिक्स पर प्रतिफल का पूर्वानुमान लगाने के लिए।

[आंतरिक डेटा की आवश्यकता: स्विटास के पृष्ठ 75 आईएनपी से पहले/बाद के आंकड़े और ग्राहक के साथ किए गए कार्य से रूपांतरण अंतर, ताकि सार्वजनिक केस स्टडी को प्रत्यक्ष साक्ष्य से बदला जा सके।]

यह निर्णय वृक्ष कहाँ विफल हो जाता है

• कम यातायात वाले मूल स्थान। कम डेटा रेंज के मामले में 75वां पर्सेंटाइल शोर होता है। प्रति टेम्पलेट प्रति सप्ताह लगभग 1,000 से कम इंटरैक्शन होने पर, लैब में प्रोफाइलिंग करें और यह स्वीकार करें कि आप CrUX में जीत को सत्यापित नहीं कर सकते।
• Safari और Firefox के उपयोगकर्ता अदृश्य हैं। CrUX केवल Chrome पर चलता है। यदि आपकी आय का एक बड़ा हिस्सा iOS Safari से आता है, तो आपका INP डेटा उस आबादी का वर्णन करता है जिसका आप पूरी तरह से आकलन नहीं कर रहे हैं।
• स्क्रॉल जंक इस विषय के दायरे से बाहर है। INP स्क्रॉलिंग को अनदेखा करता है, इसलिए यह ट्री कभी भी अनंत-स्क्रॉल लिस्टिंग में समस्या का पता नहीं लगा पाएगा जो देखने में खराब लगती है लेकिन परीक्षण में सही पाई जाती है।
• यह डिज़ाइन संबंधी खामियों को नहीं, बल्कि विलंबता को खोजता है। एक भ्रामक फ़िल्टर पैनल पर 180 मिलीसेकंड का इंटरैक्शन एक यूएक्स समस्या है जिसे यह ट्री नहीं देख सकता।

सामान्य प्रश्न

क्या INP और First Input Delay एक ही चीज़ हैं?
नहीं। FID ने केवल पहले इंटरैक्शन के हैंडलर चलने से पहले की देरी को मापा। INP पूरे विज़िट के दौरान एक प्रतिनिधि इंटरैक्शन की पूरी लेटेंसी को कवर करता है, जिसमें हैंडलर का निष्पादन और उसके बाद की पेंटिंग भी शामिल है।

मेरा लाइटहाउस स्कोर ठीक क्यों दिख रहा है जबकि आईएनपी लाल रंग का है?
लाइटहाउस एक प्रयोगशाला उपकरण है और यह INP को माप नहीं सकता: इसमें कोई वास्तविक उपयोगकर्ता कुछ भी नहीं दबाता है। टोटल ब्लॉकिंग टाइम जैसे प्रॉक्सी इसके साथ थोड़ा बहुत संबंध स्थापित करते हैं। इसके बजाय पेजस्पीड इनसाइट्स के फील्ड सेक्शन को पढ़ें।

CrUX में यह समस्या ठीक होने में कितना समय लगेगा?
CrUX 28 दिनों की रोलिंग विंडो पर रिपोर्ट करता है, और BigQuery टेबल मासिक रूप से प्रकाशित होती हैं। लगभग चार सप्ताह बाद आंशिक सिग्नल और दो मासिक रिलीज़ के बाद एक स्पष्ट रीड की उम्मीद करें।

क्या मैं फ्रेमवर्क को छुए बिना INP की समस्या को ठीक कर सकता हूँ?
अक्सर हां। ट्रेंडीओल का समाधान रिएक्ट 16.9 पर एक कॉलबैक के अंदर यील्ड का उपयोग करना था, बिना अपग्रेड किए। तृतीय-पक्ष टैग को स्थगित करना भी फ्रेमवर्क-स्वतंत्र है।

क्या सहमति बैनर आईएनपी को प्रभावित करता है?
ऐसा दो तरीकों से हो सकता है: बैनर की अपनी स्क्रिप्ट लोड होने के दौरान मुख्य थ्रेड के लिए प्रतिस्पर्धा करती है, और सहमति का निर्णय अक्सर तुरंत बाद टैग लोडिंग में तेजी लाता है। सहमति के बाद पहली बातचीत को अलग से मापें।

क्या मुझे RUM वेंडर की आवश्यकता है, या वेब-वाइटल्स लाइब्रेरी ही पर्याप्त है?
एट्रिब्यूशन बिल्ड और एक बीकन एंडपॉइंट इस ट्री को चलाने के लिए पर्याप्त हैं। विक्रेता बेहतर एट्रिब्यूशन डेटा नहीं, बल्कि रिटेंशन, सेगमेंटेशन और डैशबोर्ड खरीदते हैं।

क्या मुझे INP को SEO के लिए ऑप्टिमाइज़ करना चाहिए या कन्वर्ज़न के लिए?
रूपांतरण का निर्णय लें। कोर वेब विटल्स एक रैंकिंग सिग्नल हैं, लेकिन प्रलेखित व्यावसायिक उदाहरण — ट्रेंडीओल में 1%, रेडबस में 7% — परस्पर क्रिया की गुणवत्ता पर ऐसे प्रभाव हैं जो अपने आप में किए गए कार्य को उचित ठहराते हैं।

इसे अपने लिस्टिंग पेज पर चलाएं

अपने सबसे अधिक ट्रैफ़िक वाले टेम्पलेट को लें, उसमें एट्रिब्यूशन बिल्ड जोड़ें, और शाखा 0 से 7 तक क्रम से आगे बढ़ें। यदि आप चाहें कि ट्री को आपके अपने फ़ील्ड डेटा के आधार पर चलाया जाए, जिसमें देश का विवरण और प्रयोग डिज़ाइन शामिल हो, तो हमारा वेब प्रदर्शन टीम यह ठीक यही कार्य करता है।

सूत्रों का कहना है

• नेक्स्ट पेंट (INP) के साथ इंटरैक्शन — web.dev
• अगले पेंट के साथ इंटरैक्शन को अनुकूलित करें — web.dev
• फ़ील्ड में धीमी गति से होने वाली बातचीत का पता लगाएं — web.dev
• लंबे कार्यों को अनुकूलित करें — web.dev
• प्रदर्शन — वेब पंचांग 2025, HTTP संग्रह
• ट्रेंडीओल ने आईएनपी को 50% तक कैसे कम किया — web.dev
• redBus ने INP में सुधार कैसे किया और बिक्री में 7% की वृद्धि कैसे की — web.dev
• मिलीसेकंड लाखों में फर्क ला सकते हैं — web.dev / 55 / Deloitte
• CrUX ऑन BigQuery — डेवलपर्स के लिए क्रोम
• शेड्यूलर: यील्ड() — एमडीएन
• शेड्यूलर एपीआई: उपज - caniuse
• वेब-विटल्स जावास्क्रिप्ट लाइब्रेरी — GoogleChrome/web-vitals