हम सभी जानते हैं कि परफ़ॉर्मेंस कितनी अहम है. हालांकि, जब हम परफ़ॉर्मेंस और वेबसाइटों को "तेज़" बनाने के बारे में बात करते हैं, तो हमारा क्या मतलब होता है?
असल में, परफ़ॉर्मेंस की तुलना की जाती है:
- हो सकता है कि एक उपयोगकर्ता के लिए साइट की स्पीड तेज़ हो, लेकिन दूसरे उपयोगकर्ता के लिए धीमी हो. ऐसा, तेज़ नेटवर्क और बेहतर डिवाइस का इस्तेमाल करने वाले उपयोगकर्ता के मुकाबले, धीमे नेटवर्क और कम सुविधा वाले डिवाइस का इस्तेमाल करने वाले उपयोगकर्ता के लिए हो सकता है.
- दो साइटें एक ही समय में लोड हो सकती हैं. इसके बावजूद, किसी साइट को लोड होने में ज़्यादा समय लग सकता है और किसी साइट को कम समय. ऐसा तब होता है, जब कोई साइट पूरा कॉन्टेंट लोड होने का इंतज़ार करने के बजाय, कॉन्टेंट को धीरे-धीरे लोड करती है.
- ऐसा हो सकता है कि साइट जल्दी लोड हो, लेकिन उपयोगकर्ता के इंटरैक्शन का जवाब देना धीरे-धीरे शुरू करे या जवाब ही न दे.
परफ़ॉर्मेंस के बारे में बात करते समय, सटीक जानकारी देना ज़रूरी है. साथ ही, मेट्रिक के हिसाब से परफ़ॉर्मेंस के बारे में बताना भी ज़रूरी है. ऐसी ज़रूरी शर्तें जिनकी संख्या का आकलन किया जा सकता है. हालांकि, यह पक्का करना भी ज़रूरी है कि मेज़र की जा रही मेट्रिक काम की हों.
मेट्रिक तय करना
अब तक, वेब परफ़ॉर्मेंस को load
इवेंट से मेज़र किया जाता रहा है. हालांकि, load
किसी पेज के लाइफ़साइकल में एक अहम पॉइंट है, लेकिन यह ज़रूरी नहीं है कि वह पॉइंट, उपयोगकर्ता के लिए अहम हो.
उदाहरण के लिए, कोई सर्वर तुरंत "लोड" होने वाले कम से कम पेज के साथ जवाब दे सकता है. हालांकि, इसके बाद load
इवेंट ट्रिगर होने के कुछ सेकंड बाद तक, पेज पर कॉन्टेंट फ़ेच करने या कुछ भी दिखाने से रोका जा सकता है. तकनीकी तौर पर, इस तरह के पेज को लोड होने में कम समय लगता है. हालांकि, यह समय इस बात से मेल नहीं खाता कि उपयोगकर्ता को पेज लोड होने में कितना समय लगता है.
पिछले कुछ सालों से, Chrome की टीम के सदस्य W3C वेब परफ़ॉर्मेंस वर्किंग ग्रुप के साथ मिलकर, नए एपीआई और मेट्रिक के एक सेट को स्टैंडर्ड बनाने पर काम कर रहे हैं. इनकी मदद से, यह ज़्यादा सटीक तरीके से मेज़र किया जा सकता है कि उपयोगकर्ताओं को किसी वेब पेज की परफ़ॉर्मेंस कैसी लगती है.
यह पक्का करने के लिए कि मेट्रिक, उपयोगकर्ताओं के लिए काम की हों, हम उन्हें कुछ अहम सवालों के हिसाब से तैयार करते हैं:
क्या ऐसा हो रहा है? | क्या नेविगेशन शुरू हो गया? क्या सर्वर ने जवाब दिया है? |
क्या यह काम का है? | क्या ज़रूरत के मुताबिक कॉन्टेंट रेंडर किया गया है, ताकि उपयोगकर्ता उससे जुड़ सकें? |
क्या इसे इस्तेमाल किया जा सकता है? | क्या उपयोगकर्ता पेज से इंटरैक्ट कर सकते हैं या वह व्यस्त है? |
क्या यह दिलचस्प है? | क्या इंटरैक्शन आसान और स्वाभाविक हैं और बिना किसी रुकावट के होते हैं? |
मेट्रिक को कैसे मेज़र किया जाता है
परफ़ॉर्मेंस मेट्रिक को आम तौर पर इनमें से किसी एक तरीके से मेज़र किया जाता है:
- लैब में: टूल का इस्तेमाल करके, एक जैसी और कंट्रोल की गई स्थिति में पेज लोड होने की प्रक्रिया को सिम्युलेट करना
- फ़ील्ड में: असल उपयोगकर्ताओं के पेज को लोड करने और उससे इंटरैक्ट करने पर
इनमें से कोई भी विकल्प, ज़रूरी नहीं है कि दूसरे से बेहतर या खराब हो—असल में, आम तौर पर अच्छी परफ़ॉर्मेंस के लिए, दोनों का इस्तेमाल करना चाहिए.
लैब में
नई सुविधाएं बनाते समय, लैब में परफ़ॉर्मेंस की जांच करना ज़रूरी है. प्रोडक्शन में सुविधाएं रिलीज़ होने से पहले, असली उपयोगकर्ताओं पर उनकी परफ़ॉर्मेंस की विशेषताओं को मेज़र करना असंभव है. इसलिए, सुविधा रिलीज़ होने से पहले, लैब में उनकी जांच करना, परफ़ॉर्मेंस में गिरावट को रोकने का सबसे अच्छा तरीका है.
फ़ील्ड में
दूसरी ओर, लैब में टेस्टिंग, परफ़ॉर्मेंस का एक अच्छा तरीका है. हालांकि, इससे यह ज़रूरी नहीं है कि असली उपयोगकर्ताओं को आपकी साइट का अनुभव कैसा मिले.
उपयोगकर्ता के डिवाइस की क्षमताओं और नेटवर्क की स्थिति के आधार पर, किसी साइट की परफ़ॉर्मेंस काफ़ी अलग-अलग हो सकती है. यह इस बात पर भी निर्भर करता है कि उपयोगकर्ता पेज से इंटरैक्ट कर रहा है या नहीं (या कैसे).
पेज लोड होने में लगने वाला समय भी हमेशा एक जैसा नहीं होता. उदाहरण के लिए, उपयोगकर्ताओं के हिसाब से कॉन्टेंट या विज्ञापन लोड करने वाली साइटों की परफ़ॉर्मेंस, हर उपयोगकर्ता के लिए अलग-अलग हो सकती है. लैब टेस्ट में इन फ़र्क़ों का पता नहीं चलता.
यह जानने का एक ही तरीका है कि आपकी साइट, उपयोगकर्ताओं के लिए कैसा परफ़ॉर्म करती है. इसके लिए, आपको यह देखना होगा कि उपयोगकर्ताओं के साइट लोड करने और उससे इंटरैक्ट करने के दौरान, साइट की परफ़ॉर्मेंस कैसी है. आम तौर पर, इस तरह के मेज़रमेंट को असल उपयोगकर्ता निगरानी (RUM) कहा जाता है.
मेट्रिक के टाइप
उपयोगकर्ताओं की परफ़ॉर्मेंस के बारे में समझने के लिए, कई अन्य तरह की मेट्रिक भी काम की होती हैं.
- लोड होने में लगने वाला अनुमानित समय: इससे पता चलता है कि कोई पेज कितनी तेज़ी से लोड होता है और स्क्रीन पर अपने सभी विज़ुअल एलिमेंट को कितनी तेज़ी से रेंडर करता है.
- लोड होने में लगने वाला समय: यह मेट्रिक बताती है कि कोई पेज कितनी तेज़ी से लोड होता है और ज़रूरी JavaScript कोड को कितनी तेज़ी से लागू करता है, ताकि कॉम्पोनेंट, उपयोगकर्ता इंटरैक्शन का तुरंत जवाब दे सकें
- रनटाइम रिस्पॉन्सिवनेस: पेज लोड होने के बाद, उपयोगकर्ता के इंटरैक्शन का जवाब देने में पेज को कितना समय लगता है.
- विज़ुअल स्टेबिलिटी: क्या पेज पर मौजूद एलिमेंट इस तरह से शिफ़्ट होते हैं कि उपयोगकर्ताओं को अचानक से यह महसूस हो कि पेज का स्ट्रक्चर बदल गया है और वे पेज पर इंटरैक्ट नहीं कर पा रहे हैं?
- सुचारू तरीके से काम करना: क्या ट्रांज़िशन और ऐनिमेशन एक ही फ़्रेम रेट पर रेंडर होते हैं और एक स्टेटस से दूसरे स्टेटस में आसानी से फ़्लो करते हैं?
परफ़ॉर्मेंस की इन सभी मेट्रिक को देखते हुए, हमें उम्मीद है कि आपको यह समझ आ गया होगा कि किसी पेज की परफ़ॉर्मेंस की सभी विशेषताओं को कैप्चर करने के लिए, कोई एक मेट्रिक काफ़ी नहीं है.
मेज़र करने के लिए ज़रूरी मेट्रिक
- फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी): यह मेट्रिक, पेज लोड होने की शुरुआत से लेकर, स्क्रीन पर उसके कॉन्टेंट को रेंडर करने में लगने वाले समय को मापती है. (lab, field)
- सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी): यह मेट्रिक, पेज लोड होने की शुरुआत से लेकर, स्क्रीन पर सबसे बड़े टेक्स्ट ब्लॉक या इमेज एलिमेंट को रेंडर करने में लगने वाले समय को मापती है. (lab, field)
- पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी): यह मेट्रिक, पेज पर किए गए हर टैप, क्लिक या कीबोर्ड इंटरैक्शन के इंतज़ार के समय को मेज़र करती है. साथ ही, इंटरैक्शन की संख्या के आधार पर, पेज के सबसे खराब इंटरैक्शन इंतज़ार के समय (या सबसे ज़्यादा के करीब) को एक वैल्यू के तौर पर चुनती है. इससे पेज के रिस्पॉन्सिवनेस के बारे में पता चलता है. (lab, field)
- ब्लॉक होने का कुल समय (टीबीटी): यह मेट्रिक, FCP और TTI के बीच के कुल समय को मापती है, जहां मुख्य थ्रेड को इनपुट का रिस्पॉन्स देने से रोकने के लिए काफ़ी समय तक ब्लॉक किया गया था. (lab)
- कुल लेआउट शिफ़्ट (सीएलएस): यह मेट्रिक, पेज के लोड होने के दौरान और उसके लाइफ़साइकल स्टेटस के 'छिपा हुआ' में बदलने के बीच होने वाले सभी अनचाहे लेआउट शिफ़्ट के कुल स्कोर को मेज़र करती है. (lab, field)
- टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी): यह मेज़र करता है कि नेटवर्क को किसी रिसॉर्स के पहले बाइट के साथ, उपयोगकर्ता के अनुरोध का जवाब देने में कितना समय लगता है. (lab, field)
कुछ मामलों में, छूटे हुए इलाकों को कवर करने के लिए नई मेट्रिक शुरू की जाएंगी. हालांकि, अन्य मामलों में सबसे अच्छी मेट्रिक, खास तौर पर आपकी साइट के हिसाब से बनाई जाती हैं.
कस्टम मेट्रिक
ऊपर बताई गई परफ़ॉर्मेंस मेट्रिक, वेब पर मौजूद ज़्यादातर साइटों की परफ़ॉर्मेंस की खास बातों को सामान्य तौर पर समझने के लिए अच्छी हैं. ये मेट्रिक, साइटों के लिए मेट्रिक का एक सामान्य सेट होने के लिहाज़ से भी अच्छी हैं, ताकि वे अपनी परफ़ॉर्मेंस की तुलना अपने प्रतिस्पर्धियों से कर सकें.
हालांकि, ऐसा हो सकता है कि कोई साइट किसी तरह से यूनीक हो और उसकी परफ़ॉर्मेंस की पूरी जानकारी पाने के लिए, अन्य मेट्रिक की ज़रूरत पड़े. उदाहरण के लिए, एलसीपी मेट्रिक का मकसद यह मेज़र करना है कि पेज का मुख्य कॉन्टेंट कब लोड हो जाता है. हालांकि, ऐसे मामले हो सकते हैं जहां सबसे बड़ा एलिमेंट, पेज के मुख्य कॉन्टेंट का हिस्सा न हो. ऐसे में, हो सकता है कि एलसीपी काम का न हो.
ऐसे मामलों को हल करने के लिए, वेब परफ़ॉर्मेंस वर्किंग ग्रुप ने लोअर-लेवल एपीआई को भी स्टैंडर्ड किया है. ये एपीआई, अपनी कस्टम मेट्रिक लागू करने के लिए काम के हो सकते हैं:
- User Timing API
- Long Tasks API
- Long Animation Frames API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- सर्वर पर रिस्पॉन्स तैयार करने में लगने वाला समय
अपनी साइट की परफ़ॉर्मेंस की खास विशेषताओं को मेज़र करने के लिए, इन एपीआई का इस्तेमाल करने का तरीका जानने के लिए, कस्टम मेट्रिक से जुड़ी गाइड देखें.