First Input Delay (FID)

हम सभी जानते हैं कि पहली बार में एक अच्छा इंप्रेशन बनाना कितना ज़रूरी है. नए लोगों से मिलते समय यह ज़रूरी है और वेब पर अनुभव तैयार करते समय भी यह ज़रूरी है.

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

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

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

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

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

एफ़आईडी क्या है?

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

अच्छा एफ़आईडी स्कोर क्या होता है?

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

एफ़आईडी के बारे में जानकारी

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

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

किसी सामान्य वेब पेज के लोड होने की इन टाइमलाइन पर ध्यान दें:

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

इसकी वजह से, मुख्य थ्रेड कुछ समय के लिए व्यस्त होती है. यह बेज रंग के टास्क ब्लॉक से पता चलता है.

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

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

सोचें कि अगर कोई उपयोगकर्ता सबसे लंबे टास्क की शुरुआत में ही पेज से इंटरैक्ट करने की कोशिश करे, तो क्या होगा:

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

अगर किसी इंटरैक्शन में इवेंट लिसनर नहीं है, तो क्या होगा?

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

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

• टेक्स्ट फ़ील्ड, चेकबॉक्स, और रेडियो बटन (<input>, <textarea>)
• ड्रॉपडाउन (<select>) चुनें
• लिंक (<a>)

सिर्फ़ पहले इनपुट पर विचार क्यों करें?

वैसे तो किसी भी इनपुट में देरी की वजह से उपयोगकर्ता को खराब अनुभव मिल सकता है, लेकिन हमारा सुझाव है कि कुछ वजहों से पहले इनपुट में देरी को मापने का सुझाव दिया जाता है:

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

पहला इनपुट किसे माना जाता है?

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

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

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

अगर कोई उपयोगकर्ता आपकी साइट से कभी इंटरैक्ट न करे, तो क्या होगा?

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

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

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

सिर्फ़ इनपुट में देरी को क्यों ध्यान में रखा जाए?

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

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

हालांकि, एफ़आईडी, इवेंट के इंतज़ार का समय सिर्फ़ "देरी" वाले हिस्से को ही मापता है. हालांकि, जो डेवलपर इवेंट की लाइफ़साइकल को ज़्यादा ट्रैक करना चाहते हैं वे Event Timing API का इस्तेमाल करके ऐसा कर सकते हैं. ज़्यादा जानकारी के लिए, कस्टम मेट्रिक की गाइड देखें.

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

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

फ़ील्ड टूल

• Chrome पर उपयोगकर्ता अनुभव रिपोर्ट
• PageSpeed Insights
• Search Console (वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट)
• web-vitals JavaScript लाइब्रेरी

JavaScript में एफ़आईडी को मेज़र करना

JavaScript में एफ़आईडी को मेज़र करने के लिए, Event Timing API का इस्तेमाल करें. यहां दिए गए उदाहरण में बताया गया है कि ऐसे PerformanceObserver को कैसे बनाएं जो first-input एंट्री को सुनता है और उन्हें कंसोल में लॉग करता है:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

ऊपर दिए गए उदाहरण में, first-input एंट्री की देरी से जुड़ी वैल्यू को, एंट्री के startTime और processingStart टाइमस्टैंप के बीच के डेल्टा के हिसाब से मापा जाता है. ज़्यादातर मामलों में, यह एफ़आईडी वैल्यू होगी. हालांकि, एफ़आईडी को मेज़र करने के लिए सभी first-input एंट्री मान्य नहीं हैं.

नीचे दिए गए सेक्शन में, एपीआई की रिपोर्ट और मेट्रिक की गिनती के तरीके के बीच के अंतर को बताया गया है.

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

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

इन सभी छोटे-मोटे अंतर को याद रखने के बजाय, डेवलपर एफ़आईडी को मेज़र करने के लिए web-vitals JavaScript लाइब्रेरी का इस्तेमाल कर सकते हैं. यह आपके लिए इन अंतरों को हैंडल करती है (जहां मुमकिन हो—ध्यान दें कि iframe की समस्या इसमें शामिल नहीं है):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

JavaScript में एफ़आईडी को मापने के तरीके के पूरे उदाहरण के लिए, आप onFID() के लिए सोर्स कोड देख सकते हैं.

एफ़आईडी डेटा का विश्लेषण करना और उसकी रिपोर्टिंग करना

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

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

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

एफ़आईडी को बेहतर बनाने का तरीका

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

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

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

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

अगर आपके पास इन मेट्रिक के बारे में कोई सुझाव है, तो वेब-वाइट्स-फ़ीडबैक Google ग्रुप में दिया जा सकता है.