परफ़ॉर्मेंस मेट्रिक्स का भविष्य और नए मानक: परफ़ॉर्मेंस मापने की अगली पीढ़ी की तैयारी

परफ़ॉर्मेंस मेट्रिक्स बदलती रहती हैं। Core Web Vitals 2020 में आए थे। उन्होंने पुरानी मेट्रिक्स (FCP, FID) की जगह ली। पाँच साल बाद नई मेट्रिक्स Core Web Vitals की जगह ले लेंगी।

आगे की मेट्रिक्स ये मापेंगी: AI लोडिंग (AI फ़ीचर को जवाब देने में कितना समय लगता है), रियल-टाइम रिस्पॉन्स (स्ट्रीमिंग जवाब दिखने में कितना समय लगता है), यूज़र को महसूस होने वाली परफ़ॉर्मेंस (पेज कैसा लगता है, सिर्फ़ तकनीकी मेट्रिक्स नहीं)।

अभी का सवाल: आगे की मेट्रिक्स क्या होंगी यह जाने बिना हम तैयारी कैसे करें। जवाब: वह मापें जो आपके बिज़नेस के लिए मायने रखता है। Core Web Vitals आम यूज़र एक्सपीरियंस मापते हैं। कस्टम मेट्रिक्स बिज़नेस के ख़ास नतीजे मापती हैं। अपने मेज़रमेंट सिस्टम में लचीलापन रखकर भविष्य की तैयारी करें।

मेट्रिक्स का बदलाव ट्रैक करना

Core Web Vitals अभी का मानक हैं। लेकिन वे हमेशा के लिए नहीं हैं।

टाइमलाइन:

• 2020: Core Web Vitals आए (LCP, CLS, FID)
• 2022: FID की जगह INP आया (रिस्पॉन्स मेट्रिक और बेहतर की गई)
• 2024: अगली मेट्रिक्स पर चर्चा (इंटरैक्शन वेट टाइम, स्ट्रीमिंग रिस्पॉन्स टाइम)
• भविष्य: नई मेट्रिक्स आएँगी

पैटर्न: जैसे टेक्नोलॉजी बदलती है, मेट्रिक्स बदलती हैं। जब पेज इंटरैक्टिव हुए, तो इंटरैक्टिव मेट्रिक्स (INP) ज़रूरी हो गईं। जैसे-जैसे AI इंटीग्रेशन आम होगा, AI रिस्पॉन्स टाइम एक ज़रूरी मेट्रिक बन सकता है।

सीख: सिद्धांतों पर ध्यान दें (यूज़र को पेज तेज़, रिस्पॉन्सिव और स्थिर लगे), मेट्रिक्स पर नहीं। मेट्रिक्स बदलने पर भी सिद्धांत वही रहते हैं।

AI और रियल-टाइम परफ़ॉर्मेंस

AI फ़ीचर आम होते जा रहे हैं। वेबसाइट का चैटबॉट जवाब देने में दो सेकंड लेता है। यूज़र इससे तेज़ की उम्मीद करता है।

उभरती मेट्रिक: AI रिस्पॉन्स टाइम (यूज़र के सवाल से AI के जवाब के पहले टोकन तक का समय)।

उदाहरण: सपोर्ट पेज पर कस्टमर सर्विस चैटबॉट। यूज़र सवाल पूछता है। चैटबॉट पहला रिस्पॉन्स टोकन लौटाने में दो सेकंड लेता है। यूज़र को लगता है: चैटबॉट धीमा है, जवाब नहीं देता।

ऑप्टिमाइज़ेशन: स्ट्रीमिंग रिस्पॉन्स। पहला टोकन पाँच सौ मिलीसेकंड में लौटाएँ, बाकी जवाब स्ट्रीम करें। पूरा जवाब दो सेकंड ले तब भी यूज़र को जवाब तुरंत मिला लगता है।

आगे की मेट्रिक: पहले टोकन तक का समय (TTF) मापें, कुल रिस्पॉन्स टाइम नहीं। पाँच सौ मिलीसेकंड से कम TTF अच्छा है।

असली उदाहरण: AI असिस्टेंट वाला SaaS।

यूज़र का मौजूदा अनुभव:

• यूज़र असिस्टेंट आइकन पर क्लिक करता है
• असिस्टेंट को दिखने में डेढ़ सेकंड लगते हैं
• यूज़र इंतज़ार करता है, धीमापन महसूस करता है
• चैट का अनुभव धीमा लगता है

आगे का ऑप्टिमाइज़ेशन:

• यूज़र असिस्टेंट आइकन पर क्लिक करता है
• आइकन तुरंत एनिमेट होता है (तुरंत फ़ीडबैक, सौ मिलीसेकंड)
• चैट विंडो खुलती है (दो सौ मिलीसेकंड)
• AI का पहला जवाब दिखता है (पाँच सौ मिलीसेकंड)
• बाकी AI जवाब स्ट्रीम होता है (एक से दो सेकंड)

यूज़र को लगता है: जवाब तुरंत मिला (एनिमेशन और विंडो खुलना तुरंत दिखता है)।

एज कंप्यूटिंग और बँटी हुई परफ़ॉर्मेंस

एज कंप्यूटिंग कंप्यूटेशन को यूज़र्स के पास ले आती है। सर्वर न्यूयॉर्क से लॉस एंजेलिस के एज पर चला गया। TTFB में बहुत सुधार होता है।

आगे: कंप्यूटेशन एज पर होगा। HTML जनरेशन एज पर होगा। JavaScript एक्ज़ीक्यूशन एज पर होगा। डेटाबेस क्वेरी एज तक बाँटी जाएँगी।

मेट्रिक्स पर असर: TTFB नगण्य हो जाता है (नेटवर्क लेटेंसी लगभग शून्य)। LCP रेंडरिंग पर निर्भर करता है, सर्वर रिस्पॉन्स पर नहीं।

आगे का ऑप्टिमाइज़ेशन फ़ोकस: रेंडरिंग परफ़ॉर्मेंस, सर्वर रिस्पॉन्स परफ़ॉर्मेंस नहीं।

उदाहरण: आगे का एज-आधारित होमपेज।

मौजूदा स्थिति:

• TTFB: दो सौ मिलीसेकंड (सर्वर न्यूयॉर्क में, यूज़र लॉस एंजेलिस में)
• LCP: दो सेकंड (LCP = TTFB + रेंडरिंग टाइम)

आगे की स्थिति (एज कंप्यूटिंग):

• TTFB: बीस मिलीसेकंड (सर्वर लॉस एंजेलिस एज पर)
• LCP: 1.5 सेकंड (रुकावट रेंडरिंग टाइम है, सर्वर रिस्पॉन्स नहीं)

ऑप्टिमाइज़ेशन: रेंडरिंग परफ़ॉर्मेंस सुधारना (CSS, JavaScript) सर्वर रिस्पॉन्स सुधारने से ज़्यादा ज़रूरी हो जाता है।

यूज़र को महसूस होने वाली परफ़ॉर्मेंस और व्यक्तिगत मेट्रिक्स

वस्तुनिष्ठ मेट्रिक्स: LCP दो सेकंड है (मापा जा सकता है, वस्तुनिष्ठ)।

व्यक्तिगत मेट्रिक्स: पेज रिस्पॉन्सिव लगता है (व्यक्तिगत, महसूस किया गया)।

रिसर्च बताती है: जो पेज रिस्पॉन्सिव लगता है, उसकी तकनीकी मेट्रिक्स धीमे लगने वाले पेज जैसी हो सकती हैं। फ़र्क एनिमेशन, विज़ुअल फ़ीडबैक और लोडिंग के अहसास का होता है।

आगे की मेट्रिक: महसूस हुआ रिस्पॉन्स। सिर्फ़ तकनीकी मेट्रिक नहीं, यूज़र की धारणा मापें।

उदाहरण: एक जैसे LCP (दो सेकंड) वाले दो पेज।

पेज एक: तुरंत खाली पेज पर लोड होता है, फिर दो सेकंड पर कंटेंट दिखता है। यूज़र को धीमापन लगता है।

पेज दो: तुरंत स्केलेटन स्क्रीन दिखाता है (दो सौ मिलीसेकंड), दो सेकंड तक धीरे-धीरे कंटेंट भरता है। यूज़र को तेज़ लगता है (स्केलेटन स्क्रीन से तेज़ लोड का अहसास बनता है)।

तकनीकी मेट्रिक्स (LCP): दोनों के लिए वही (दो सेकंड)।

यूज़र की धारणा: पेज दो तेज़ लगता है।

आगे की मेट्रिक: यूज़र परसेप्शन स्कोर (तकनीकी मेट्रिक्स के साथ व्यक्तिगत अनुभव भी मापें)।

स्ट्रीमिंग और प्रोग्रेसिव रेंडरिंग

मौजूदा तरीका: पूरा पेज रेंडर करें, क्लाइंट को भेजें। क्लाइंट पेज रेंडर करता है। पेज इंटरैक्टिव होता है।

स्ट्रीमिंग तरीका: पेज के हिस्से रेंडर होते ही भेजें। क्लाइंट हिस्से पाकर धीरे-धीरे रेंडर करता है। पूरा लोड होने से पहले पेज आंशिक रूप से इंटरैक्टिव होता है।

असर: जो पेज पूरा लोड होने में दो सेकंड लेता है, वह स्ट्रीमिंग से 0.5 सेकंड में इंटरैक्टिव हो सकता है।

आगे की मेट्रिक: टाइम टू इंटरैक्टिव (TTI)। यूज़र पेज से इंटरैक्ट कर सके, इसमें कितना समय लगता है।

उदाहरण: सुझावों वाला प्रोडक्ट पेज।

मौजूदा तरीका:

• HTML लोड होता है (0.5 सेकंड)
• CSS लोड होती है (0.3 सेकंड)
• JavaScript लोड होती है (0.5 सेकंड)
• सुझावों के लिए API कॉल (एक सेकंड)
• पेज 2.3 सेकंड पर इंटरैक्टिव होता है

स्ट्रीमिंग तरीका:

• HTML स्ट्रीम होता है (0.1 सेकंड) - पेज का ढाँचा दिखता है
• CSS स्ट्रीम होती है (0.2 सेकंड) - पेज स्टाइल हो जाता है
• JavaScript स्ट्रीम होती है (0.3 सेकंड) - पेज इंटरैक्टिव हो जाता है
• सुझावों के लिए API कॉल बैकग्राउंड में चलती रहती है
• पेज 0.5 सेकंड पर इंटरैक्टिव होता है
• सुझाव एक सेकंड पर और उसके बाद दिखते हैं

यूज़र 0.5 सेकंड पर इंटरैक्ट कर सकता है (कार्ट में डालना, बटन क्लिक करना)। पूरा कंटेंट एक सेकंड पर और उसके बाद दिखता है।

आगे की मेट्रिक (TTI): 0.5 सेकंड (2.3 सेकंड से)। यूज़र की धारणा में बहुत बड़ा सुधार।

अक्सर पूछे जाने वाले सवाल