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