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