First Input Delay (FID)

Philip Walton

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

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

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

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

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

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

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

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

अच्छा FID स्कोर क्या होता है?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FID को मेज़र करने का तरीका

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

फ़ील्ड टूल

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

JavaScript में FID मेज़र करना

JavaScript में FID को मेज़र करने के लिए, 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 टाइमस्टैंप के बीच के अंतर को लिया जाता है. ज़्यादातर मामलों में यह FID वैल्यू होती है. हालांकि, सभी first-input एंट्री, FID को मेज़र करने के लिए मान्य नहीं होती हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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