पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)

Jeremy Wagner

Barry Pollard

पब्लिश करने की तारीख: 6 मई, 2022, पिछली बार अपडेट करने की तारीख: 9 सितंबर, 2025

Chrome के इस्तेमाल से जुड़े डेटा से पता चलता है कि कोई उपयोगकर्ता, पेज लोड होने के बाद उस पर 90% समय बिताता है. इसलिए, पेज के लाइफ़साइकल के दौरान रिस्पॉन्सिवनेस को ध्यान से मेज़र करना ज़रूरी है. आईएनपी मेट्रिक इसी का आकलन करती है.

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

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

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

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

इस गाइड में बताया गया है कि आईएनपी कैसे काम करता है और इसे कैसे मेज़र किया जाता है. साथ ही, इसे बेहतर बनाने के लिए रिसॉर्स के बारे में भी बताया गया है.

आईएनपी क्या है?

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

इंटरैक्शन, इवेंट हैंडलर का एक ग्रुप होता है. ये सभी इवेंट हैंडलर, उपयोगकर्ता के एक ही जेस्चर के दौरान ट्रिगर होते हैं. उदाहरण के लिए, टचस्क्रीन डिवाइस पर "टैप करें" इंटरैक्शन में कई इवेंट शामिल होते हैं, जैसे कि pointerup, pointerdown, और click. इंटरैक्शन को JavaScript, सीएसएस, ब्राउज़र में मौजूद कंट्रोल (जैसे कि फ़ॉर्म एलिमेंट) या इन सभी के कॉम्बिनेशन से ट्रिगर किया जा सकता है.

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

अच्छा आईएनपी स्कोर क्या होता है?

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

यह पक्का करने के लिए कि उपयोगकर्ताओं को अच्छी प्रतिक्रिया मिल रही है, फ़ील्ड में रिकॉर्ड किए गए पेज लोड के 75वें पर्सेंटाइल को मेज़र करना एक अच्छा थ्रेशोल्ड है. इसे मोबाइल और डेस्कटॉप डिवाइसों के हिसाब से सेगमेंट किया जाता है:

• अगर किसी पेज का आईएनपी 200 मिलीसेकंड या इससे कम है, तो इसका मतलब है कि पेज पर रिस्पॉन्स मिलने में कम समय लग रहा है.
• अगर किसी पेज का आईएनपी 200 मिलीसेकंड से ज़्यादा और 500 मिलीसेकंड से कम या इसके बराबर है, तो इसका मतलब है कि पेज के रिस्पॉन्स को बेहतर बनाने की ज़रूरत है.
• अगर किसी पेज का आईएनपी 500 मिलीसेकंड से ज़्यादा है, तो इसका मतलब है कि वह पेज तेज़ी से रिस्पॉन्स नहीं दे रहा है.

इंटरैक्शन में क्या-क्या शामिल होता है?

इंटरैक्टिविटी के लिए, अक्सर JavaScript का इस्तेमाल किया जाता है. हालांकि, ब्राउज़र ऐसे कंट्रोल के ज़रिए भी इंटरैक्टिविटी उपलब्ध कराते हैं जो JavaScript से नहीं चलते. जैसे, चेकबॉक्स, रेडियो बटन, और सीएसएस से चलने वाले कंट्रोल.

INP के लिए, सिर्फ़ इन इंटरैक्शन टाइप को ट्रैक किया जाता है:

• माउस से क्लिक करना.
• टचस्क्रीन वाले डिवाइस पर टैप करना.
• फ़िज़िकल या ऑनस्क्रीन कीबोर्ड पर कोई बटन दबाना.

इंटरैक्शन, मुख्य दस्तावेज़ में या दस्तावेज़ में एम्बेड किए गए iframe में होते हैं. उदाहरण के लिए, एम्बेड किए गए वीडियो पर 'चलाएं' पर क्लिक करना. असली उपयोगकर्ताओं को यह पता नहीं चलेगा कि iframe में क्या है या क्या नहीं. इसलिए, टॉप लेवल पेज पर उपयोगकर्ता अनुभव का आकलन करने के लिए, iframe में INP की ज़रूरत होती है. JavaScript Web API के पास iframe के कॉन्टेंट का ऐक्सेस नहीं होता. इसलिए, यह CrUX और RUM के बीच अंतर के तौर पर दिख सकता है

इंटरैक्शन में कई इवेंट शामिल हो सकते हैं. उदाहरण के लिए, कीस्ट्रोक में keydown, keypress, और keyup इवेंट शामिल होते हैं. टैप इंटरैक्शन में pointerup और pointerdown इवेंट शामिल होते हैं. इंटरैक्शन के दौरान सबसे ज़्यादा समय तक चलने वाला इवेंट, इंटरैक्शन के कुल इंतज़ार के समय में योगदान देता है.

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

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

आईएनपी, फ़र्स्ट इनपुट डिले (एफ़आईडी) से किस तरह अलग है?

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

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

अगर कोई आईएनपी वैल्यू रिपोर्ट नहीं की जाती है, तो क्या होगा?

ऐसा हो सकता है कि किसी पेज के लिए, आईएनपी की कोई वैल्यू न मिले. ऐसा कई वजहों से हो सकता है. इनमें ये वजहें शामिल हैं:

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

आईएनपी को मेज़र करने का तरीका

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

फ़ील्ड में

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

अगर आपकी वेबसाइट, Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) में शामिल होने की ज़रूरी शर्तें पूरी करती है, तो आपको आईएनपी के लिए फ़ील्ड डेटा PageSpeed Insights में CrUX के ज़रिए (और अन्य Core Web Vitals) तुरंत मिल सकता है. कम से कम, आपको अपनी वेबसाइट के INP की जानकारी ओरिजिन लेवल पर मिल सकती है. हालांकि, कुछ मामलों में आपको यूआरएल लेवल का डेटा भी मिल सकता है.

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

लैब में

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

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

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

JavaScript में INP को मेज़र करना

JavaScript में आईएनपी को मेज़र करने के लिए, आपको सभी इंटरैक्शन के लिए इवेंट टाइमिंग मेज़र करनी होगी. इसके बाद, पेज अनलोड होने पर इन सभी इंटरैक्शन के लिए 98वां पर्सेंटाइल लेना होगा. web vitals JavaScript लाइब्रेरी का सोर्स कोड देखें. इसमें INP के कैलकुलेट होने के तरीके के बारे में बताया गया है.

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

मेट्रिक और एपीआई के बीच अंतर

• event 104 मिलीसेकंड से कम समय वाली एंट्री, परफ़ॉर्मेंस ऑब्ज़र्वर का इस्तेमाल करके डिफ़ॉल्ट रूप से रिपोर्ट नहीं की जाती हैं. durationThreshold पैरामीटर का इस्तेमाल करके परफ़ॉर्मेंस ऑब्ज़र्वर को रजिस्टर करते समय, इस डिफ़ॉल्ट वैल्यू को बदला जा सकता है. हालांकि, इसकी कम से कम वैल्यू 16 मिलीसेकंड होती है. इस वजह से, हमारा सुझाव है कि आप first-input एंट्री को भी देखें. यह भी इवेंट टाइमिंग एंट्री है. हालांकि, इसकी अवधि durationThreshold से कम होने पर भी इसे देखा जा सकता है. इससे यह पक्का करने में मदद मिलती है कि इंटरैक्शन वाले पेजों के लिए, हमेशा कोई न कोई INP वैल्यू रिपोर्ट की जाए.
• तकनीकी तौर पर, पर्सेंटाइल का सटीक हिसाब लगाने के लिए, सभी सैंपल को मेमोरी में सेव रखना ज़रूरी होता है. इसमें ज़्यादा खर्च आ सकता है. हालांकि, सबसे खराब परफ़ॉर्म करने वाले N इंटरैक्शन की छोटी सूची बनाकर, पर्सेंटाइल का अनुमान लगाया जा सकता है. खास तौर पर, p98 जैसे बहुत ज़्यादा पर्सेंटाइल का अनुमान लगाया जा सकता है. आम तौर पर, 10 को चुना जाता है.
• अगर किसी पेज को बैक/फ़ॉरवर्ड कैश मेमोरी से वापस लाया जाता है, तो उसकी आईएनपी वैल्यू को शून्य पर रीसेट कर देना चाहिए. ऐसा इसलिए, क्योंकि उपयोगकर्ता इसे पेज की अलग विज़िट के तौर पर देखते हैं.
• एपीआई, उन इंटरैक्शन के लिए event एंट्री की रिपोर्ट नहीं करता जो iframe में होते हैं. हालांकि, मेट्रिक ऐसा करती है, क्योंकि ये पेज के उपयोगकर्ता अनुभव का हिस्सा होते हैं. यह CrUX और RUM के बीच अंतर के तौर पर दिख सकता है. आईएनपी को सही तरीके से मेज़र करने के लिए, आपको इन पर ध्यान देना चाहिए. सब-फ़्रेम, एपीआई का इस्तेमाल करके पैरंट फ़्रेम को अपनी event-timing एंट्री की जानकारी दे सकते हैं.

इन अपवादों के अलावा, INP को समझना थोड़ा मुश्किल है. ऐसा इसलिए है, क्योंकि यह किसी पेज के पूरे लाइफ़स्पैन को मेज़र करता है:

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

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

इन सभी मामलों को खुद याद रखने और समझने के बजाय, डेवलपर web-vitals JavaScript लाइब्रेरी का इस्तेमाल करके INP को मेज़र कर सकते हैं. इसमें ऊपर बताई गई सभी बातों का ध्यान रखा जाता है. हालांकि, इसमें iframe के मामले को शामिल नहीं किया जाता:

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

आईएनपी को बेहतर बनाने का तरीका

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

बदलावों का लॉग

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

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

अगर आपको इन मेट्रिक के बारे में कोई सुझाव/राय देनी है या शिकायत करनी है, तो web-vitals-feedback Google ग्रुप में जाकर ऐसा करें.

अपने ज्ञान को परखें