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