बेहतर रिस्पॉन्सिबिलिटी मेट्रिक की ओर

जवाब मिलने में लगने वाले समय को मेज़र करने के बारे में हमारे विचार जानें और उसके बारे में हमें सुझाव/राय दें या शिकायत करें.

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

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

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

इस पोस्ट में दो मुख्य विषय शामिल होंगे:

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

फ़र्स्ट इनपुट डिले क्या है?

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

• click
• keydown
• mousedown
• pointerdown (सिर्फ़ अगर pointerup के बाद आता है)

इस डायग्राम में, एफ़आईडी दिखाया गया है:

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

हमने एफ़आईडी को क्यों चुना?

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

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

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

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

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

फ़ील्ड में टीटीआई को मापने के बारे में जानकारी

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

हम किन सुधारों पर विचार कर रहे हैं?

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

हम चाहते हैं कि नई मेट्रिक:

1. सभी उपयोगकर्ता के इनपुट का जवाब देने की क्षमता पर ध्यान दें (सिर्फ़ पहले वाले इनपुट पर ही नहीं)
2. हर इवेंट का पूरा समय कैप्चर करें (न कि सिर्फ़ देरी का).
3. एक ही लॉजिकल उपयोगकर्ता इंटरैक्शन के हिस्से के रूप में होने वाले इवेंट को एक साथ ग्रुप करें. साथ ही, यह तय करें कि इंटरैक्शन की इंतज़ार का समय, उसके सभी इवेंट की सबसे ज़्यादा अवधि के रूप में तय होता है.
4. किसी पेज पर होने वाली सभी इंटरैक्शन की पूरी लाइफ़साइकल के दौरान उन सभी इंटरैक्शन का कुल स्कोर बनाएं.

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

इवेंट की पूरी अवधि कैप्चर करें

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

किसी घटना के लाइफ़साइकल के कई चरण होते हैं, जैसा कि इस डायग्राम में दिखाया गया है:

किसी इनपुट को प्रोसेस करने के लिए, Chrome यह तरीका अपनाता है:

1. उपयोगकर्ता से इनपुट मिलता है. इस समय यह इवेंट का timeStamp होता है.
2. ब्राउज़र, हिट जांच करके यह तय करता है कि कोई इवेंट किस एचटीएमएल फ़्रेम (मुख्य फ़्रेम या कुछ iframe) से जुड़ा है. इसके बाद ब्राउज़र, इवेंट को उस एचटीएमएल फ़्रेम की सही रेंडरर प्रोसेस को भेजता है.
3. रेंडरर को इवेंट मिलता है और उसे सूची में जोड़ दिया जाता है, ताकि रेंडर करने के लिए उपलब्ध होने पर वह उसे प्रोसेस कर सके.
4. रेंडरर, इवेंट के हैंडलर को चलाकर उसे प्रोसेस करता है. ये हैंडलर अतिरिक्त एसिंक्रोनस काम की सूची बना सकते हैं, जैसे कि setTimeout और फ़ेच, जो इनपुट हैंडलिंग का हिस्सा हैं. लेकिन इस स्थिति में, सिंक्रोनस काम पूरा हो जाता है.
5. स्क्रीन पर एक फ़्रेम पेंट किया जाता है, जो इवेंट हैंडलर को चलाने का नतीजा दिखाता है. ध्यान रखें कि इवेंट हैंडलर की सूची में शामिल एसिंक्रोनस टास्क अब भी पूरे नहीं किए गए हो सकते हैं.

ऊपर दिए गए चरणों (1) और (3) के बीच के समय, इवेंट की देरी से जुड़े डेटा को एफ़आईडी मापता है.

ऊपर दिए गए चरणों (1) और (5) के बीच का समय, किसी इवेंट की अवधि है. हमारी नई मेट्रिक, यह मेज़र करेगी.

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

एसिंक्रोनस टास्क के बारे में जानकारी

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

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

इवेंट को इंटरैक्शन में ग्रुप करना

मेट्रिक मेज़रमेंट को देर से से अवधि तक बढ़ाना अच्छा है. हालांकि, इससे मेट्रिक में एक अहम अंतर दिखता है: यह अलग-अलग इवेंट पर फ़ोकस करता है, न कि पेज के साथ इंटरैक्ट करने वाले उपयोगकर्ता अनुभव पर.

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

इंटरैक्शन के प्रकार

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

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

हर इंटरैक्शन टाइप के लिए डीओएम इवेंट.

इंटरैक्शन	शुरू / खत्म	डेस्कटॉप इवेंट	मोबाइल इवेंट
कीबोर्ड	बटन दबाया गया	keydown	keydown
		keypress	keypress
	डिजिटल बटन रिलीज़ किया गया	keyup	keyup
टैप करें या खींचें	शुरू करें या खींचें और छोड़ें पर टैप करें	pointerdown	pointerdown
		mousedown	touchstart
	एंड पर टैप करें या खींचें और छोड़ें	pointerup	pointerup
		mouseup	touchend
		click	mousedown
			mouseup
			click
स्क्रोल करें	लागू नहीं

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

शुरू और खत्म होने के बारे में नोट

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

कीबोर्ड

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

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

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

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

ध्यान दें: keypress इवेंट अब काम नहीं करता. इसे keydown इवेंट वाले टास्क में ही फ़ायर किया जाना चाहिए, ताकि इसकी अवधि हमेशा keydown के साथ ओवरलैप हो.

बार-बार एक ही बटन दबाने पर नोट

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

टैप करें

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

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

हम इन सभी इवेंट के लिए इवेंट की अवधि शामिल करना चाहते हैं, लेकिन इनमें से कई इवेंट पूरी तरह से ओवरलैप करते हैं. इसलिए, पूरे इंटरैक्शन को कवर करने के लिए, हमें सिर्फ़ pointerdown, pointerup, और click को मेज़र करना होगा.

क्या हम सिर्फ़ pointerdown और pointerup तक सीमित कर सकते हैं?

सबसे पहले, यह हो सकता है कि pointerdown और pointerup इवेंट का इस्तेमाल किया जाए. साथ ही, यह मान लिया जाए कि इवेंट में वे सभी अवधि शामिल हैं जिनमें हमारी दिलचस्पी है. अफ़सोस की बात यह है कि ऐसा नहीं है, क्योंकि इस एज केस में बताया गया है. इस साइट को मोबाइल पर या मोबाइल एम्युलेशन का इस्तेमाल करके खोलें. इसके बाद, उस जगह पर टैप करें जहां "मुझे क्लिक करें" लिखा हो. यह साइट, ब्राउज़र पर टैप करने में देरी को ट्रिगर करती है. यह देखा जा सकता है कि pointerdown, pointerup, और touchend को तेज़ी से भेजा जाता है. वहीं, mousedown, mouseup, और click को डिस्पैच किए जाने से पहले देरी का इंतज़ार किया जाता है. इसका मतलब है कि अगर हम सिर्फ़ pointerdown और pointerup को देखेंगे, तो हम सिंथेटिक इवेंट के कुल समय को नहीं देख पाएंगे. यह समय, ब्राउज़र के टैप होने में लगने वाले समय की वजह से ज़्यादा होता है. इसलिए, इसे शामिल किया जाना चाहिए. इसलिए, हमें पूरे इंटरैक्शन को कवर करने के लिए, pointerdown, pointerup, और click को मेज़र करना चाहिए.

खींचें और छोड़ें

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

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

स्क्रोल करना

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

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

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

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

किसी इंटरैक्शन की इंतज़ार का समय कैसे तय करें?

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

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

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

इस तरीके के फ़ायदे और नुकसान हैं. हम आपके सुझाव, शिकायत या राय पर काम कर सकते हैं:

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

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

प्रति पेज सभी इंटरैक्शन एग्रीगेट करें

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

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

यह एग्रीगेशन करने के लिए, हमें दो सवालों को हल करना होगा:

1. हम किन संख्याओं को इकट्ठा करने की कोशिश करते हैं?
2. हम इन आंकड़ों को कैसे इकट्ठा करते हैं?

हम कई विकल्प एक्सप्लोर कर रहे हैं और उनका आकलन कर रहे हैं. हम इस एग्रीगेशन पर आपके विचारों का स्वागत करते हैं.

एक विकल्प यह है कि आप किसी इंटरैक्शन की इंतज़ार के समय के लिए बजट तय करें. यह इंतज़ार के समय (स्क्रोल, कीबोर्ड, टैप या ड्रैग) पर निर्भर करता है. उदाहरण के लिए, अगर टैप के लिए बजट 100 मि॰से॰ और टैप करने का इंतज़ार का समय 150 मि॰से॰ है, तो उस इंटरैक्शन के लिए बजट की कुल रकम 50 मि॰से॰ होगी. इसके बाद, हम पेज में किसी भी उपयोगकर्ता इंटरैक्शन के लिए, तय बजट से ज़्यादा से ज़्यादा इंतज़ार के समय का पता लगा सकते हैं.

दूसरा विकल्प यह है कि पूरे पेज के दौरान इंटरैक्शन की औसत या मीडियन इंतज़ार के समय का हिसाब लगाया जाए. इसलिए अगर हमारे पास 80, 90, और 100 मि॰से॰ की इंतज़ार का समय होता है, तो पेज लोड होने में लगने वाला औसत समय 90 मि॰से॰ होगा. इंटरैक्शन के टाइप के आधार पर, हम अलग-अलग उम्मीदों के हिसाब से, औसत या मीडियन "बजट से ज़्यादा" पर भी विचार कर सकते हैं.

यह वेब परफ़ॉर्मेंस एपीआई पर कैसा दिखता है?

इवेंट के समय में क्या कमी है?

माफ़ करें, इस पोस्ट में दिए गए सभी आइडिया, Event Timing API का इस्तेमाल करके कैप्चर नहीं किए जा सकते. खास तौर पर, एपीआई के साथ किसी उपयोगकर्ता के इंटरैक्शन से जुड़े इवेंट के बारे में जानने का कोई आसान तरीका नहीं है. ऐसा करने के लिए, हमने एपीआई में interactionID जोड़ने का सुझाव दिया है.

Event Timing API की एक और कमी यह है कि स्क्रोल इंटरैक्शन को मेज़र करने का कोई तरीका नहीं है. इसलिए, हम इन मेज़रमेंट को चालू करने पर काम कर रहे हैं (Event Timing या किसी अलग एपीआई की मदद से).

अभी क्या किया जा सकता है?

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

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

सुझाव/राय दें या शिकायत करें

इन आइडिया के बारे में आपकी क्या राय है, यह बताने के लिए [e-mail] पर ईमेल करें!