हम सभी को पता है कि पहली बार में अच्छा इंप्रेशन पाना कितना ज़रूरी है. यह ज़रूरी है और नए लोगों से मिलने के साथ-साथ, यह भी ज़रूरी है कि आप वेब पर.
वेब पर, एक अच्छा पहला इंप्रेशन किसी व्यक्ति के बीच अंतर कर सकता है साथ ही, ऐसे लोग जो कभी आपका ऐप्लिकेशन छोड़ दें या फिर कभी वापस न आएं. सवाल यह है कि अच्छा इंप्रेशन कैसे मिलता है और यह कैसे मेज़र किया जाता है कि किस तरह के इंप्रेशन को संभावित तौर पर अपने उपयोगकर्ताओं से कितना फ़ायदा हो रहा है?
वेब पर, पहला इंप्रेशन कई अलग-अलग रूपों में हो सकता है—हमारे पास किसी साइट के डिज़ाइन और विज़ुअल अपील के पहले इंप्रेशन और इसकी स्पीड और रिस्पॉन्सिवनेस के बारे में इंप्रेशन.
हालांकि, वेब एपीआई की मदद से यह मेज़र करना मुश्किल है कि उपयोगकर्ताओं को किसी साइट का डिज़ाइन कितना पसंद आया, लेकिन इसकी स्पीड और रिस्पॉन्स को मेज़र करना मुश्किल होता है!
उपयोगकर्ताओं को पहली नज़र में ही पता चल जाता है कि आपकी साइट कितनी तेज़ी से लोड होती है फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी). हालांकि, आपकी साइट कितनी तेज़ी से पिक्सल पेंट कर सकती है उस कहानी का सिर्फ़ एक हिस्सा है. साथ ही, यह भी मायने रखता है कि आपकी साइट तब होती है, जब उपयोगकर्ता उन पिक्सल से इंटरैक्ट करने की कोशिश करते हैं!
फ़र्स्ट इनपुट डिले (एफ़आईडी) मेट्रिक की मदद से, आपके उपयोगकर्ता के पहले इंप्रेशन को मेज़र किया जाता है आपकी साइट की इंटरैक्टिविटी और रिस्पॉन्स.
एफ़आईडी क्या है?
एफ़आईडी वह समय मापता है जो उपयोगकर्ता के किसी पेज के साथ पहली बार इंटरैक्ट करने के समय से शुरू होता है. वे किसी लिंक पर क्लिक करते हैं, बटन पर टैप करते हैं या JavaScript से चलने वाले कस्टम कंट्रोल का इस्तेमाल करते हैं) जब तक ब्राउज़र असल में इवेंट हैंडलर को प्रोसेस करना शुरू कर देता है वह भी इन सवालों के जवाब दे सकता है.
एक अच्छा एफ़आईडी स्कोर क्या होता है?
उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, साइटों को पहली बार इनपुट इस्तेमाल करना चाहिए हालांकि, 100 मिलीसेकंड या इससे कम का समय. यह सुनिश्चित करने के लिए कि आप है, तो मेज़र करने के लिए एक अच्छा थ्रेशोल्ड 75वां पर्सेंटाइल है पेज लोड होते हैं. इन्हें मोबाइल और डेस्कटॉप डिवाइस के हिसाब से सेगमेंट में बांटा जाता है.
एफ़आईडी की जानकारी
इवेंट के जवाब देने वाले कोड लिखने वाले डेवलपर के तौर पर, हम अक्सर यह मान लेते हैं कि हमारा कोड को तुरंत चालू कर दिया जाएगा—जैसे ही इवेंट होगा. हालांकि, उपयोगकर्ता होने के नाते, हमें अक्सर इसका उलटा अनुभव हुआ है—इसलिए हमने Google पर एक वेब पेज लोड कर दिया है हमारे फ़ोन के साथ इंटरैक्ट करने की कोशिश की. इसके बाद, जब कुछ भी नहीं हो रहा था, तो हम निराश हो जाते हैं हुआ है.
आम तौर पर, इनपुट में देरी (जैसे, इनपुट लेटेंसी) इसलिए होती है, क्योंकि ब्राउज़र का मुख्य थ्रेड में कोई और काम करने में व्यस्त है. इसलिए, यह उपयोगकर्ता को जवाब नहीं दे सकता. ऐसा होने की एक आम वजह यह है कि ब्राउज़र, पार्स करने और उसे लागू करने में व्यस्त होने की वजह से ऐसा हो सकता है आपके ऐप्लिकेशन से लोड की गई बड़ी JavaScript फ़ाइल. जब वह ऐसा कर रहा है, तो यह नहीं चल सकता क्योंकि JavaScript लोड कर रहा है, इसलिए यह कुछ और.
किसी सामान्य वेब पेज के लोड होने की यह टाइमलाइन देखें:
ऊपर दिए गए विज़ुअलाइज़ेशन में ऐसा पेज दिखाया गया है जिससे नेटवर्क के लिए कई अनुरोध किए जा रहे हैं के लिए उपलब्ध डाउनलोड पूरा हो जाता है—उन्हें मुख्य थ्रेड पर प्रोसेस किया जाता है.
इसकी वजह से, कुछ समय के लिए मुख्य थ्रेड व्यस्त रहती है, जो कि बैज रंग से दिखाया जाता है टास्क ब्लॉक.
आम तौर पर, फ़र्स्ट कॉन्टेंटफ़ुल पेंट के पहले इनपुट में ज़्यादा देरी होती है (एफ़सीपी) और टाइम टू इंटरैक्टिव (टीटीआई), क्योंकि पेज में का कुछ कॉन्टेंट रेंडर किया है, लेकिन यह अभी तक भरोसेमंद नहीं है. उदाहरण के लिए ऐसा कैसे होता है, एफ़सीपी और टीटीआई को टाइमलाइन में जोड़ दिया गया है:
आपने देखा होगा कि साइट पर काफ़ी समय और लंबे समय टास्क), एफ़सीपी और टीटीआई के बीच होने चाहिए, जब कोई उपयोगकर्ता किसी उस दौरान पेज के साथ इंटरैक्ट करते हैं (उदाहरण के लिए, किसी लिंक पर क्लिक करके), तो क्लिक मिलने के बाद, मुख्य थ्रेड के ऐक्सेस होने के बीच की देरी जवाब.
सोचें कि अगर कोई उपयोगकर्ता, सबसे लंबे टास्क की शुरुआत:
चूंकि इनपुट तब होता है जब ब्राउज़र कोई कार्य चलाने के बीच में होता है, जवाब मिलने से पहले, टास्क पूरा होने तक इंतज़ार करना पड़ता है. कॉन्टेंट बनाने इंतज़ार का समय, इस पेज पर इस उपयोगकर्ता के लिए FID मान है.
अगर किसी इंटरैक्शन में इवेंट लिसनर नहीं है, तो क्या होगा?
एफ़आईडी, इनपुट इवेंट के मिलने और मुख्य इवेंट के मिलने के बीच के अंतर को मापता है थ्रेड अगली बार कुछ समय से इस्तेमाल में नहीं है. इसका मतलब है कि एफ़आईडी को इवेंट में भी मेज़र किया जाता है लिसनर को रजिस्टर नहीं किया गया है. इसकी वजह यह है कि लोगों के बहुत सारे इंटरैक्शन होने चाहिए इवेंट लिसनर की ज़रूरत नहीं है, लेकिन मुख्य थ्रेड का कुछ समय तक इस्तेमाल न किए जाने की ज़रूरत है चलाने के लिए.
उदाहरण के लिए, नीचे दिए गए सभी एचटीएमएल एलिमेंट को उपयोगकर्ता को जवाब देने से पहले, मुख्य थ्रेड पर जारी टास्क पूरे करने के लिए इंटरैक्शन:
- टेक्स्ट फ़ील्ड, चेकबॉक्स, और रेडियो बटन (
<input>
,<textarea>
) - ड्रॉपडाउन चुनें (
<select>
) - लिंक (
<a>
)
सिर्फ़ पहले इनपुट के बारे में क्यों सोचें?
किसी इनपुट में देरी होने से, उपयोगकर्ता को खराब अनुभव मिल सकता है. इसलिए, हमने मुख्य तौर पर इन वजहों से, इनपुट में लगने वाले समय को मेज़र करने का सुझाव दिया जाता है:
- पहली इनपुट देरी, आपकी साइट की जवाब देने में मदद मिलती है और पहला इंप्रेशन हमारे प्रॉडक्ट को बेहतर बनाने में मदद करता है. और उस पर भरोसा किया जा सकता है.
- आज वेब पर इंटरैक्ट करने से जुड़ी सबसे बड़ी समस्याएं पेज के दौरान आती हैं लोड होता है. इसलिए, हमारा मानना है कि शुरुआत में, हम साइट के पहले उपयोगकर्ता को बेहतर बनाने पर फ़ोकस करते हैं आपके विज्ञापनों के साथ की जाने वाली बातचीत की वजह से, वेब की इंटरैक्टिविटी.
- साइटों को पहली बार इनपुट में देरी होने की समस्या को कैसे ठीक करना चाहिए, इसके लिए सुझाए गए समाधान यह ज़रूरी नहीं है कि कोड को बांटना, पहले से कम JavaScript लोड करना वगैरह. पेज लोड होने के बाद इनपुट में देरी को ठीक करने के लिए, यही समाधान उपलब्ध हैं. अलग करके इन मेट्रिक की मदद से, हम ज़्यादा सटीक परफ़ॉर्मेंस दे पाएंगे के दिशा-निर्देशों का पालन करें.
पहला इनपुट किसे माना जाता है?
एफ़आईडी एक ऐसी मेट्रिक है जो लोड होने के दौरान किसी पेज के रिस्पॉन्सिव होने का पता लगाती है. इस तरह, यह यह सिर्फ़ क्लिक, टैप, और बटन जैसी अलग-अलग कार्रवाइयों के इनपुट इवेंट पर फ़ोकस करता है दबाता है.
अन्य इंटरैक्शन, जैसे कि स्क्रोल और ज़ूम करना, लगातार होने वाली कार्रवाइयां हैं. अलग-अलग प्रदर्शन प्रतिबंध (साथ ही, ब्राउज़र अक्सर आपके विज्ञापनों से उन्हें अलग थ्रेड पर चलाकर, इंतज़ार का समय छिपाएं).
इसे दूसरे तरीके से समझने के लिए, एफ़आईडी, आरएIL परफ़ॉर्मेंस मॉडल, जबकि स्क्रोल और ज़ूमिंग, 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
इन सभी बारीकियों को याद रखने के बजाय, डेवलपर
इसके लिए, web-vitals
JavaScript लाइब्रेरी का इस्तेमाल करें:
FID को मेज़र करें, जो आपके लिए इन अंतर को हैंडल करता है (जहां मुमकिन हो—ध्यान दें कि इसमें iframe की समस्या शामिल नहीं है):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
आप चाहें तो
onFID()
पढ़ें.
एफ़आईडी डेटा का विश्लेषण करना और उसकी रिपोर्ट बनाना
एफ़आईडी की वैल्यू में अंतर होने की वजह से, यह ज़रूरी है कि एफ़आईडी: वैल्यू के डिस्ट्रिब्यूशन पर ध्यान दिया जाता है और ज़्यादा पर्सेंटाइल पर फ़ोकस किया जाता है.
जबकि की पसंद सभी के लिए पर्सेंटाइल वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के थ्रेशोल्ड 75वें दिन हैं. खास तौर पर, एफ़आईडी के लिए हम अब भी सख्ती से लागू करते हैं हम 95वां–99वां पर्सेंटाइल देखने की सलाह देते हैं, क्योंकि ये खास तौर पर, आपकी साइट पर उपयोगकर्ताओं को सबसे पहले बुरा अनुभव मिलना. और यह होगा वे क्षेत्र दिखा पाएंगे जिनमें सबसे ज़्यादा सुधार की ज़रूरत है.
अगर आप अपनी रिपोर्ट को डिवाइस की कैटगरी या टाइप के हिसाब से सेगमेंट करते हैं, तब भी ऐसा ही होता है. इसके लिए उदाहरण के लिए, डेस्कटॉप और मोबाइल के लिए अलग-अलग रिपोर्ट चलाने पर, एफ़आईडी वैल्यू और डेस्कटॉप इस्तेमाल करने वालों का प्रतिशत, डेस्कटॉप उपयोगकर्ताओं का 95वां–99वां पर्सेंटाइल होना चाहिए. साथ ही, मोबाइल पर आपकी पसंदीदा एफ़आईडी वैल्यू 95 से 99वीं के बीच होनी चाहिए मोबाइल उपयोगकर्ताओं का पर्सेंटाइल.
एफ़आईडी को बेहतर बनाने का तरीका
एफ़आईडी को ऑप्टिमाइज़ करने की पूरी गाइड उपलब्ध है. इसमें, इस मेट्रिक को बेहतर बनाने की तकनीकों का इस्तेमाल किया जा सकता है.
बदलावों का लॉग
कभी-कभी, मेट्रिक को मापने के लिए इस्तेमाल किए जाने वाले एपीआई में गड़बड़ियां मिलती हैं. कभी-कभी खुद मेट्रिक की परिभाषा में गड़बड़ियां मिलती हैं. इस वजह से, कभी-कभी बदलाव करने पड़ते हैं. ये बदलाव आपकी इंटरनल रिपोर्ट और डैशबोर्ड में सुधार या रिग्रेशन के तौर पर दिख सकते हैं.
इसे मैनेज करने में आपकी मदद करने के लिए, इन मेट्रिक को लागू करने या उनकी परिभाषा करने में किए जाने वाले सभी बदलाव, इस बदलाव लॉग में दिखेंगे.
अगर आपको इन मेट्रिक के बारे में कोई सुझाव/राय देनी है या शिकायत करनी है, तो web-fitals-feedback Google ग्रुप पर जाएं.