RAIL, उपयोगकर्ता पर आधारित परफ़ॉर्मेंस मॉडल है. यह परफ़ॉर्मेंस के बारे में सोचने के लिए एक स्ट्रक्चर उपलब्ध कराता है. यह मॉडल, उपयोगकर्ता के अनुभव को मुख्य कार्रवाइयों (जैसे, टैप करना, स्क्रोल करना, लोड करना) में बांटता है. साथ ही, हर कार्रवाई के लिए परफ़ॉर्मेंस के लक्ष्य तय करने में आपकी मदद करता है.
आरएआईएल, वेब ऐप्लिकेशन के लाइफ़ साइकल के चार अलग-अलग पहलुओं को दिखाता है: रिस्पॉन्स, ऐनिमेशन, आइडल, और लोड. उपयोगकर्ता, इनमें से हर कॉन्टेक्स्ट के लिए परफ़ॉर्मेंस से जुड़ी अलग-अलग उम्मीदें रखते हैं. इसलिए, परफ़ॉर्मेंस के लक्ष्य, कॉन्टेक्स्ट और उपयोगकर्ता अनुभव से जुड़ी रिसर्च के आधार पर तय किए जाते हैं. इस रिसर्च में यह देखा जाता है कि उपयोगकर्ता, देरी को किस तरह से देखते हैं.
उपयोगकर्ता पर फ़ोकस
परफ़ॉर्मेंस को बेहतर बनाने के लिए, उपयोगकर्ताओं को ध्यान में रखें. नीचे दी गई टेबल में, उन मुख्य मेट्रिक के बारे में बताया गया है जिनसे पता चलता है कि उपयोगकर्ताओं को परफ़ॉर्मेंस में देरी का अनुभव कैसे होता है:
परफ़ॉर्मेंस में देरी के बारे में उपयोगकर्ता की राय| 0 से 16 मिलीसेकंड | उपयोगकर्ता, मोशन को ट्रैक करने में बहुत अच्छे होते हैं. उन्हें ऐसे ऐनिमेशन पसंद नहीं आते जो स्मूद नहीं होते. जब तक हर सेकंड 60 नए फ़्रेम रेंडर होते हैं, तब तक उन्हें ऐनिमेशन स्मूद लगते हैं. इसका मतलब है कि हर फ़्रेम के लिए 16 मि॰से॰ का समय मिलता है. इसमें वह समय भी शामिल है जो ब्राउज़र को स्क्रीन पर नया फ़्रेम दिखाने में लगता है. इस तरह, ऐप्लिकेशन को फ़्रेम बनाने के लिए करीब 10 मि॰से॰ का समय मिलता है. |
| 0 से 100 मि॰से॰ | इस समयावधि के अंदर उपयोगकर्ता की कार्रवाइयों का जवाब दें, ताकि उन्हें लगे कि नतीजा तुरंत मिल रहा है. इससे ज़्यादा समय लगने पर, कार्रवाई और प्रतिक्रिया के बीच का कनेक्शन टूट जाता है. |
| 100 से 1,000 मि॰से॰ | इस विंडो में, टास्क को नैचुरल और लगातार होने वाली प्रोसेस के तौर पर दिखाया जाता है. वेब पर ज़्यादातर उपयोगकर्ताओं के लिए, पेज लोड करना या व्यू बदलना एक टास्क होता है. |
| 1,000 मि॰से॰ या इससे ज़्यादा | अगर पेज लोड होने में 1,000 मिलीसेकंड (एक सेकंड) से ज़्यादा समय लगता है, तो उपयोगकर्ता का ध्यान उस टास्क से हट जाता है जो वह कर रहा होता है. |
| 10,000 मि॰से॰ या इससे ज़्यादा | अगर पेज लोड होने में 10,000 मिलीसेकंड (10 सेकंड) से ज़्यादा समय लगता है, तो उपयोगकर्ता परेशान हो जाते हैं और टास्क को बीच में ही छोड़ देते हैं. ऐसा हो सकता है कि वे बाद में वापस आएं या न आएं. |
लक्ष्य और दिशा-निर्देश
आरएआईएल के संदर्भ में, लक्ष्य और दिशा-निर्देश शब्दों के खास मतलब होते हैं:
लक्ष्य. उपयोगकर्ता अनुभव से जुड़ी मुख्य परफ़ॉर्मेंस मेट्रिक. उदाहरण के लिए, टैप करने के 100 मिलीसेकंड के अंदर पेंट करना. इंसान की सोच में ज़्यादा बदलाव नहीं होता. इसलिए, इन लक्ष्यों में जल्द ही कोई बदलाव होने की संभावना नहीं है.
दिशा-निर्देश. ऐसे सुझाव जो लक्ष्य हासिल करने में आपकी मदद करते हैं. ये सुझाव, मौजूदा हार्डवेयर और इंटरनेट कनेक्शन की स्थितियों के हिसाब से हो सकते हैं. इसलिए, समय के साथ इनमें बदलाव हो सकता है.
रिस्पॉन्स: इवेंट को 50 मि॰से॰ से कम समय में प्रोसेस करना
लक्ष्य: उपयोगकर्ता के इनपुट से शुरू हुए ट्रांज़िशन को 100 मिलीसेकंड के अंदर पूरा करें, ताकि उपयोगकर्ताओं को लगे कि इंटरैक्शन तुरंत हो रहे हैं.
दिशा-निर्देश:
यह पक्का करने के लिए कि 100 मिलीसेकंड के अंदर रिस्पॉन्स दिखे, उपयोगकर्ता के इनपुट इवेंट को 50 मिलीसेकंड के अंदर प्रोसेस करें. यह ज़्यादातर इनपुट पर लागू होता है. जैसे, बटन पर क्लिक करना, फ़ॉर्म कंट्रोल को टॉगल करना या ऐनिमेशन शुरू करना. यह टच करके खींचने या स्क्रोल करने पर लागू नहीं होता.
हालांकि, यह सुनने में अजीब लग सकता है, लेकिन उपयोगकर्ता के इनपुट का तुरंत जवाब देना हमेशा सही नहीं होता. इस 100 मिलीसेकंड की विंडो का इस्तेमाल, ज़्यादा समय लेने वाले अन्य काम करने के लिए किया जा सकता है. हालांकि, ध्यान रखें कि उपयोगकर्ता को ब्लॉक न किया जाए. अगर हो सके, तो बैकग्राउंड में काम करें.
जिन कार्रवाइयों को पूरा होने में 50 मि॰से॰ से ज़्यादा समय लगता है उनके लिए हमेशा सुझाव, राय या शिकायत सबमिट करें.
50 मिलीसेकंड या 100 मिलीसेकंड?
हमारा लक्ष्य, 100 मिलीसेकंड से कम समय में इनपुट का जवाब देना है. इसलिए, हमारा बजट सिर्फ़ 50 मिलीसेकंड क्यों है? ऐसा इसलिए होता है, क्योंकि आम तौर पर इनपुट को हैंडल करने के अलावा, अन्य काम भी किए जा रहे होते हैं. इन कामों में, इनपुट के जवाब के लिए उपलब्ध समय का कुछ हिस्सा खर्च हो जाता है. अगर कोई ऐप्लिकेशन, डिवाइस के इस्तेमाल में न होने के दौरान, सुझाए गए 50 मिलीसेकंड के हिस्सों में काम कर रहा है, तो इसका मतलब है कि इनपुट को 50 मिलीसेकंड तक के लिए सूची में रखा जा सकता है. ऐसा तब होता है, जब इनपुट, काम के उन हिस्सों में से किसी एक के दौरान होता है. इस वजह से, यह माना जा सकता है कि इनपुट को हैंडल करने के लिए, सिर्फ़ 50 मिलीसेकंड का समय बचा है. इस असर को नीचे दिए गए डायग्राम में दिखाया गया है. इसमें दिखाया गया है कि किसी टास्क के दौरान मिले इनपुट को कैसे सूची में रखा जाता है. इससे प्रोसेसिंग के लिए उपलब्ध समय कम हो जाता है:
ऐनिमेशन: 10 मिलीसेकंड में एक फ़्रेम जनरेट करें
लक्ष्य:
ऐनिमेशन के हर फ़्रेम को 10 मि॰से॰ या इससे कम समय में रेंडर करें. तकनीकी तौर पर, हर फ़्रेम के लिए ज़्यादा से ज़्यादा बजट 16 मिलीसेकंड (1000 मिलीसेकंड / 60 फ़्रेम प्रति सेकंड ≈ 16 मिलीसेकंड) होता है. हालांकि, ब्राउज़र को हर फ़्रेम को रेंडर करने के लिए करीब छह मिलीसेकंड की ज़रूरत होती है. इसलिए, हर फ़्रेम के लिए 10 मिलीसेकंड का दिशा-निर्देश दिया गया है.
विज़ुअल स्मूदनेस पर ध्यान दें. फ़्रेम रेट में बदलाव होने पर, उपयोगकर्ताओं को इसका पता चल जाता है.
दिशा-निर्देश:
ऐनिमेशन जैसी मुश्किल चीज़ों के लिए, ज़रूरी है कि जहां हो सके वहां कुछ न करें और जहां ज़रूरी हो वहां कम से कम काम करें. जब भी संभव हो, 100 मिलीसेकंड के रिस्पॉन्स का इस्तेमाल करके, ज़्यादा समय लेने वाले काम का पहले से हिसाब लगाएं. इससे, 60 एफ़पीएस तक पहुंचने की संभावना बढ़ जाती है.
ऐनिमेशन को ऑप्टिमाइज़ करने की अलग-अलग रणनीतियों के लिए, रेंडरिंग की परफ़ॉर्मेंस देखें.
- विज़ुअल ऐनिमेशन, जैसे कि एंट्रेंस और एग्ज़िट, ट्वीन, और लोड होने के इंडिकेटर.
- स्क्रोल किया जा रहा है. इसमें फ़्लिंगिंग भी शामिल है. यह तब होता है, जब उपयोगकर्ता स्क्रोल करना शुरू करता है और फिर छोड़ देता है. इसके बाद, पेज स्क्रोल होता रहता है.
- खींचकर छोड़ा जा रहा है. ऐनिमेशन अक्सर उपयोगकर्ता के इंटरैक्शन के बाद दिखते हैं. जैसे, मैप को पैन करना या ज़ूम करने के लिए पिंच करना.
Idle: Maximize idle time
लक्ष्य: पेज के आइडल टाइम को बढ़ाना, ताकि इस बात की संभावना बढ़ाई जा सके कि पेज, उपयोगकर्ता के इनपुट का जवाब 50 मिलीसेकंड के अंदर दे.
दिशा-निर्देश:
खाली समय का इस्तेमाल, अधूरे कामों को पूरा करने के लिए करें. उदाहरण के लिए, शुरुआती पेज लोड के लिए, कम से कम डेटा लोड करें. इसके बाद, बाकी डेटा लोड करने के लिए, आइडल टाइम का इस्तेमाल करें.
आइडल टाइम के दौरान, 50 मिलीसेकंड या इससे कम समय में काम करें. इससे ज़्यादा समय लेने पर, ऐप्लिकेशन को उपयोगकर्ता के इनपुट का जवाब 50 मिलीसेकंड के अंदर देने में समस्या आ सकती है.
अगर कोई उपयोगकर्ता, पेज के आइडल टाइम के दौरान उससे इंटरैक्ट करता है, तो उपयोगकर्ता के इंटरैक्शन को हमेशा सबसे ज़्यादा प्राथमिकता दी जानी चाहिए. साथ ही, आइडल टाइम के दौरान होने वाले काम को रोक देना चाहिए.
लोड: कॉन्टेंट डिलीवर करना और पांच सेकंड से कम समय में इंटरैक्टिव बनना
जब पेज धीरे-धीरे लोड होते हैं, तो उपयोगकर्ता का ध्यान भटक जाता है और उसे लगता है कि टास्क पूरा नहीं हो पा रहा है. तेज़ी से लोड होने वाली साइटों पर, औसत सेशन ज़्यादा समय तक चलते हैं, बाउंस रेट कम होता है, और विज्ञापन दिखने की दर ज़्यादा होती है.
लक्ष्य:
अपने उपयोगकर्ताओं के डिवाइस और नेटवर्क की क्षमताओं के हिसाब से, तेज़ी से लोड होने की परफ़ॉर्मेंस को ऑप्टिमाइज़ करें. फ़िलहाल, पहली बार लोड होने वाले पेजों के लिए, पेज को लोड करना और धीमे 3G कनेक्शन वाले मिड-रेंज मोबाइल डिवाइसों पर 5 सेकंड या उससे कम समय में इंटरैक्टिव बनाना एक अच्छा टारगेट है.
इसके बाद, पेज लोड होने में दो सेकंड से कम समय लगना चाहिए.
दिशा-निर्देश:
अपनी साइट के लोड होने की परफ़ॉर्मेंस को उन मोबाइल डिवाइसों और इंटरनेट कनेक्शन पर टेस्ट करें जो आपके उपयोगकर्ताओं के बीच आम हैं. अपने उपयोगकर्ताओं के कनेक्शन डिस्ट्रिब्यूशन का पता लगाने के लिए, Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट का इस्तेमाल किया जा सकता है. अगर आपकी साइट के लिए डेटा उपलब्ध नहीं है, तो The Mobile Economy 2019 के मुताबिक, Moto G4 जैसे मिड-रेंज Android फ़ोन और धीमे 3G नेटवर्क (400 मि॰से॰ आरटीटी और 400 केबीपीएस ट्रांसफ़र स्पीड के तौर पर तय किया गया) को दुनिया भर में एक अच्छी बेसलाइन माना जाता है. यह कॉम्बिनेशन WebPageTest पर उपलब्ध है.
ध्यान रखें कि भले ही आपके मोबाइल उपयोगकर्ता का डिवाइस यह दावा करे कि वह 2G, 3G या 4G कनेक्शन पर है, लेकिन असल में पैकेट लॉस और नेटवर्क में अंतर की वजह से, कनेक्शन की असरदार स्पीड अक्सर काफ़ी कम होती है.
पेज के पूरी तरह से लोड होने का एहसास कराने के लिए, आपको पांच सेकंड में सब कुछ लोड करने की ज़रूरत नहीं है. इमेज की लेज़ी लोडिंग, JavaScript बंडल को कोड-स्प्लिट करने, और web.dev पर सुझाए गए अन्य ऑप्टिमाइज़ेशन का इस्तेमाल करें.
आरएआईएल को मेज़र करने के लिए टूल
RAIL मेज़रमेंट को ऑटोमेट करने के लिए, कुछ टूल उपलब्ध हैं. आपको कौनसा तरीका इस्तेमाल करना चाहिए, यह इस बात पर निर्भर करता है कि आपको किस तरह की जानकारी चाहिए और आपको कौनसा वर्कफ़्लो पसंद है.
Chrome DevTools
Chrome DevTools, पेज लोड होने या चलने के दौरान होने वाली हर गतिविधि का बारीकी से विश्लेषण करता है. परफ़ॉर्मेंस पैनल के यूज़र इंटरफ़ेस (यूआई) के बारे में जानने के लिए, रनटाइम परफ़ॉर्मेंस का विश्लेषण करना शुरू करें लेख पढ़ें.
DevTools की ये सुविधाएं खास तौर पर काम की हैं:
कम क्षमता वाले डिवाइस को सिम्युलेट करने के लिए, अपने सीपीयू को थ्रॉटल करें.
नेटवर्क को थ्रॉटल करें, ताकि धीमे कनेक्शन को सिम्युलेट किया जा सके.
मुख्य थ्रेड की गतिविधि देखें, ताकि रिकॉर्डिंग के दौरान मुख्य थ्रेड पर हुए हर इवेंट को देखा जा सके.
मुख्य थ्रेड की गतिविधियों को टेबल में देखें, ताकि गतिविधियों को इस आधार पर क्रम से लगाया जा सके कि किन गतिविधियों में सबसे ज़्यादा समय लगा.
फ़्रेम प्रति सेकंड (एफ़पीएस) का विश्लेषण करें, ताकि यह पता लगाया जा सके कि आपके ऐनिमेशन वाकई बिना किसी रुकावट के चल रहे हैं या नहीं.
परफ़ॉर्मेंस मॉनिटर की मदद से, रीयल-टाइम में सीपीयू के इस्तेमाल, JS हीप साइज़, डीओएम नोड, हर सेकंड लेआउट वगैरह को मॉनिटर करें.
नेटवर्क सेक्शन की मदद से रिकॉर्डिंग करते समय, नेटवर्क के अनुरोधों को विज़ुअलाइज़ करें.
रिकॉर्डिंग के दौरान स्क्रीनशॉट कैप्चर करें, ताकि यह देखा जा सके कि पेज लोड होने या कोई ऐनिमेशन चलने के दौरान, पेज कैसा दिखता था.
इंटरैक्शन देखें: इससे तुरंत पता चलता है कि किसी उपयोगकर्ता के इंटरैक्ट करने के बाद, पेज पर क्या हुआ.
जब भी कोई ऐसा लिसनर ट्रिगर होता है जिससे समस्या हो सकती है, तो पेज को हाइलाइट करके, स्क्रोल करने की परफ़ॉर्मेंस से जुड़ी समस्याओं का रीयल-टाइम में पता लगाएं.
पेंट इवेंट को रीयल-टाइम में देखें, ताकि ऐसे पेंट इवेंट की पहचान की जा सके जो आपके ऐनिमेशन की परफ़ॉर्मेंस को नुकसान पहुंचा सकते हैं.
लाइटहाउस
Lighthouse, Chrome DevTools में PageSpeed Insights पर, Chrome एक्सटेंशन के तौर पर, Node.js मॉड्यूल के तौर पर, और WebPageTest में उपलब्ध है. इसे यूआरएल देने पर, यह धीमे 3G कनेक्शन वाले मिड-रेंज डिवाइस को सिम्युलेट करता है. साथ ही, पेज पर कई ऑडिट चलाता है. इसके बाद, आपको लोड होने की परफ़ॉर्मेंस की रिपोर्ट देता है. साथ ही, इसे बेहतर बनाने के सुझाव भी देता है.
ये ऑडिट खास तौर पर काम के हैं:
जवाब
मैक्सिमम पोटेंशियल फ़र्स्ट इनपुट डिले. यह मेट्रिक, मुख्य थ्रेड के खाली समय के आधार पर यह अनुमान लगाती है कि आपके ऐप्लिकेशन को उपयोगकर्ता के इनपुट का जवाब देने में कितना समय लगेगा.
स्क्रोल करने की परफ़ॉर्मेंस को बेहतर बनाने के लिए, पैसिव लिसनर का इस्तेमाल नहीं किया जाता.
पेज रिस्पॉन्स बंद रहने का कुल समय. इससे पता चलता है कि किसी पेज को उपयोगकर्ता के इनपुट का जवाब देने से कितनी देर तक रोका गया. जैसे, माउस क्लिक, स्क्रीन टैप या कीबोर्ड प्रेस.
टाइम टू इंटरैक्टिव. इससे यह पता चलता है कि कोई उपयोगकर्ता, पेज के सभी एलिमेंट के साथ लगातार कब इंटरैक्ट कर सकता है.
लोड करना
यह पेज और start_url को कंट्रोल करने वाले सर्विस वर्कर को रजिस्टर नहीं करता है. सर्विस वर्कर, उपयोगकर्ता के डिवाइस पर सामान्य रिसॉर्स को कैश मेमोरी में सेव कर सकता है. इससे नेटवर्क पर रिसॉर्स फ़ेच करने में लगने वाला समय कम हो जाता है.
ऑफ़स्क्रीन इमेज को कुछ समय के लिए रोकना. ऑफ़स्क्रीन इमेज को तब तक लोड न करें, जब तक उनकी ज़रूरत न हो.
सही साइज़ वाली इमेज. ऐसी इमेज न दिखाएं जो मोबाइल व्यूपोर्ट में रेंडर किए गए साइज़ से काफ़ी बड़ी हों.
बड़े साइज़ के डीओएम से बचें. पेज को रेंडर करने के लिए ज़रूरी DOM नोड ही भेजें, ताकि नेटवर्क बाइट कम हो सकें.
WebPageTest
WebPageTest, वेब की परफ़ॉर्मेंस से जुड़ा एक टूल है. यह वेब पेजों को ऐक्सेस करने और समय से जुड़ी मेट्रिक इकट्ठा करने के लिए, असल ब्राउज़र का इस्तेमाल करता है. webpagetest.org/easy पर जाकर कोई यूआरएल डालें. इससे आपको Moto G4 डिवाइस पर, पेज के लोड होने की परफ़ॉर्मेंस के बारे में पूरी जानकारी मिलेगी. इस डिवाइस में 3G कनेक्शन की स्पीड कम है. इसे Lighthouse ऑडिट को शामिल करने के लिए भी कॉन्फ़िगर किया जा सकता है.
खास जानकारी
आरएआईएल, वेबसाइट पर उपयोगकर्ता अनुभव को देखने का एक तरीका है. इसमें उपयोगकर्ता अनुभव को अलग-अलग इंटरैक्शन से बनी एक यात्रा के तौर पर देखा जाता है. यह समझें कि उपयोगकर्ता आपकी साइट को किस तरह देखते हैं. इससे आपको परफ़ॉर्मेंस के ऐसे लक्ष्य सेट करने में मदद मिलेगी जिनका उपयोगकर्ता अनुभव पर सबसे ज़्यादा असर पड़ता है.
इस्तेमाल करने वाले पर केंद्रित.
उपयोगकर्ता के इनपुट का जवाब 100 मिलीसेकंड से कम समय में देना.
ऐनिमेशन या स्क्रोल करते समय, 10 मिलीसेकंड से कम समय में फ़्रेम जनरेट करना.
मुख्य थ्रेड के इस्तेमाल में न होने के समय को बढ़ाएं.
इंटरैक्टिव कॉन्टेंट को 5,000 मिलीसेकंड से कम समय में लोड करें.