First Input Delay (FID)

Philip Walton

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सिर्फ़ पहले इनपुट को क्यों ध्यान में रखा जाता है?

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

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

पहले इनपुट के तौर पर किसकी गिनती होती है?

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

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

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

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

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

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

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

सिर्फ़ इनपुट में लगने वाले समय को ही क्यों ध्यान में रखा जाता है?

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

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

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

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

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

फ़ील्ड टूल

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

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

JavaScript में एफ़आईडी को मेज़र करने के लिए, इवेंट टाइमिंग एपीआई का इस्तेमाल किया जा सकता है. यहां दिए गए उदाहरण में, ऐसा 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 एंट्री की जानकारी देने के लिए, सब-फ़्रेम एपीआई का इस्तेमाल कर सकते हैं.

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

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

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

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

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

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

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

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

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

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