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