First Input Delay (FID)

Philip Walton

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

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

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

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

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

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

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

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

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

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

एफ़आईडी की जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह समय उपयोगकर्ता के लिए अहम है और अनुभव पर असर नहीं डालता, फिर भी इसे इस मेट्रिक में शामिल नहीं किया जाता, क्योंकि ऐसा करने से डेवलपर को ऐसे तरीकों को जोड़ने के लिए बढ़ावा मिल सकता है जिनसे अनुभव और भी खराब हो जाए. इसका मतलब है कि वे अपने इवेंट हैंडलर लॉजिक को इवेंट से जुड़े टास्क से अलग करने के लिए, एसिंक्रोनस कॉलबैक (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 ग्रुप में दिया जा सकता है.