अपनी वेबसाइट के इंटरैक्शन टू नेक्स्ट पेंट को ऑप्टिमाइज़ करने का तरीका जानें.
इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी), वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली स्टैबल मेट्रिक है. इससे यह पता चलता है कि किसी पेज से इंटरैक्ट करने पर वह कितना रिस्पॉन्सिव था. इसके लिए, यह मेट्रिक उन सभी ज़रूरी इंटरैक्शन के इंतज़ार के समय को ट्रैक करती है जो किसी व्यक्ति के पेज पर आने के दौरान होते हैं. आईएनपी की फ़ाइनल वैल्यू से पता चलता है कि किसी व्यक्ति और पेज के बीच सबसे लंबा इंटरैक्शन कितने समय तक चला. इसमें आउटलायर वैल्यू को नज़रअंदाज़ कर दिया जाता है.
उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, यह ज़रूरी है कि वेबसाइटों का 'पेज के रिस्पॉन्स में लगने वाला समय' 200 मिलीसेकंड या उससे कम हो. यह पक्का करने के लिए कि आपके ज़्यादातर उपयोगकर्ताओं के लिए यह टारगेट पूरा हो रहा है, पेज लोड के 75वें प्रतिशत को मेज़र करना एक अच्छा थ्रेशोल्ड है. इसे मोबाइल और डेस्कटॉप डिवाइसों के हिसाब से सेगमेंट में बांटा जाता है.
वेबसाइट के हिसाब से, इंटरैक्शन कम या न के बराबर हो सकते हैं. जैसे, ज़्यादातर टेक्स्ट और इमेज वाले पेज, जिनमें इंटरैक्टिव एलिमेंट कम या न के बराबर हों. इसके अलावा, टेक्स्ट एडिटर या गेम जैसी वेबसाइटों के मामले में, सैकड़ों या हज़ारों इंटरैक्शन हो सकते हैं. दोनों ही मामलों में, ज़्यादा INP होने पर, उपयोगकर्ता अनुभव पर असर पड़ता है.
INP को बेहतर बनाने में समय और मेहनत लगती है. हालांकि, इसका फ़ायदा यह है कि उपयोगकर्ताओं को बेहतर अनुभव मिलता है. इस गाइड में, आईएनपी को बेहतर बनाने का तरीका बताया गया है.
जानें कि खराब INP की वजह क्या है
धीमे इंटरैक्शन को ठीक करने से पहले, आपको यह पता लगाने के लिए डेटा की ज़रूरत होगी कि आपकी वेबसाइट का INP खराब है या उसमें सुधार की ज़रूरत है. यह जानकारी मिलने के बाद, लैब में जाकर इंटरैक्शन में लगने वाले समय का पता लगाया जा सकता है. साथ ही, इस समस्या को हल करने के लिए काम किया जा सकता है.
फ़ील्ड में धीमे इंटरैक्शन ढूंढना
आम तौर पर, INP को ऑप्टिमाइज़ करने की प्रोसेस, फ़ील्ड डेटा से शुरू होगी. रीयल यूज़र मॉनिटरिंग (आरयूएम) की सेवा देने वाली कंपनी का फ़ील्ड डेटा, आपको पेज की आईएनपी वैल्यू के साथ-साथ कॉन्टेक्स्ट डेटा भी देगा. इससे यह पता चलता है कि आईएनपी वैल्यू के लिए कौनसा इंटरैक्शन ज़िम्मेदार था, इंटरैक्शन पेज लोड होने के दौरान हुआ था या उसके बाद, इंटरैक्शन किस तरह का था (क्लिक, कीप्रेस या टैप), और अन्य अहम जानकारी.
अगर फ़ील्ड डेटा पाने के लिए, आरयूएम की सेवा देने वाली किसी कंपनी पर भरोसा नहीं किया जा रहा है, तो INP फ़ील्ड डेटा गाइड में, PageSpeed Insights की मदद से Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) का इस्तेमाल करने का सुझाव दिया गया है. इससे, डेटा में मौजूद गैप को पूरा करने में मदद मिलती है. CrUX, Core Web Vitals प्रोग्राम का आधिकारिक डेटासेट है. इसमें आईएनपी के साथ-साथ, लाखों वेबसाइटों की मेट्रिक की खास जानकारी मिलती है. हालांकि, CrUX अक्सर उस संदर्भ के हिसाब से डेटा नहीं देता जो आपको RUM की सेवा देने वाली कंपनी से मिलता है. इससे आपको समस्याओं का विश्लेषण करने में मदद मिलती है. इसलिए, हमारा सुझाव है कि साइटें जब भी मुमकिन हो, तब RUM प्रोवाइडर का इस्तेमाल करें या CrUX में उपलब्ध जानकारी के साथ-साथ, अपने RUM सलूशन को लागू करें.
लैब में इंटरैक्शन की धीमी स्पीड का पता लगाना
आम तौर पर, फ़ील्ड डेटा मिलने के बाद, आपको लैब में टेस्टिंग शुरू करनी चाहिए. इससे आपको पता चलेगा कि आपके इंटरैक्शन धीमे हैं या नहीं. फ़ील्ड डेटा न होने पर, लैब में धीमे इंटरैक्शन की पहचान करने के लिए कुछ रणनीतियां अपनाई जा सकती हैं. इनमें, सामान्य उपयोगकर्ता फ़्लो को फ़ॉलो करना और इंटरैक्शन की जांच करना शामिल है. साथ ही, पेज लोड होने के दौरान उससे इंटरैक्ट करना भी शामिल है, जब मुख्य थ्रेड अक्सर सबसे व्यस्त होता है. ऐसा इसलिए किया जाता है, ताकि उपयोगकर्ता अनुभव के उस अहम हिस्से के दौरान, इंटरैक्शन की धीमी गति को दिखाया जा सके.
इंटरैक्शन ऑप्टिमाइज़ करना
धीमे इंटरैक्शन की पहचान करने और लैब में मैन्युअल रूप से उसे दोहराने के बाद, अगला चरण उसे ऑप्टिमाइज़ करना है. इंटरैक्शन को तीन चरणों में बांटा जा सकता है:
- इनपुट में लगा समय, जो तब शुरू होता है, जब उपयोगकर्ता पेज से इंटरैक्ट करना शुरू करता है और इंटरैक्शन के लिए इवेंट कॉलबैक चलने लगने पर खत्म होता है.
- प्रोसेसिंग में लगने वाला समय. इसमें, इवेंट कॉलबैक के पूरा होने में लगने वाला समय शामिल होता है.
- प्रज़ेंटेशन में लगने वाला समय. यह वह समय होता है जो ब्राउज़र को अगला फ़्रेम दिखाने में लगता है. इसमें इंटरैक्शन का विज़ुअल नतीजा होता है.
इन तीन चरणों के कुल समय को इंटरैक्शन में लगने वाला कुल समय कहा जाता है. इंटरैक्शन के हर चरण में, इंटरैक्शन के कुल इंतज़ार के समय में कुछ समय लगता है. इसलिए, यह जानना ज़रूरी है कि इंटरैक्शन के हर हिस्से को कैसे ऑप्टिमाइज़ किया जा सकता है, ताकि यह कम से कम समय तक चले.
इनपुट में होने वाली देरी की पहचान करना और उसे कम करना
जब कोई उपयोगकर्ता किसी पेज से इंटरैक्ट करता है, तो उस इंटरैक्शन का पहला हिस्सा इनपुट डिले होता है. पेज पर की जा रही अन्य गतिविधि के आधार पर, इनपुट में लगने वाला समय काफ़ी ज़्यादा हो सकता है. ऐसा मुख्य थ्रेड पर होने वाली गतिविधि की वजह से हो सकता है. जैसे, स्क्रिप्ट लोड होने, पार्स होने, और कंपाइल होने की वजह से. इसके अलावा, फ़ेच हैंडल करने, टाइमर फ़ंक्शन या एक-दूसरे के साथ ओवरलैप होने वाले अन्य इंटरैक्शन की वजह से भी ऐसा हो सकता है.
किसी इंटरैक्शन के इनपुट में देरी होने का सोर्स चाहे जो भी हो, आपको इनपुट में देरी को कम से कम करना होगा, ताकि इंटरैक्शन जल्द से जल्द इवेंट कॉलबैक चला सकें.
स्टार्टअप के दौरान स्क्रिप्ट की जांच और लंबे टास्क के बीच का संबंध
पेज के लाइफ़साइकल में, इंटरैक्शन का अहम हिस्सा स्टार्टअप के दौरान होता है. पेज लोड होने पर, वह शुरुआत में रेंडर होगा. हालांकि, यह याद रखना ज़रूरी है कि पेज के रेंडर होने का मतलब यह नहीं है कि पेज लोड हो गया है. किसी पेज को पूरी तरह से काम करने के लिए ज़रूरी रिसॉर्स के आधार पर, हो सकता है कि उपयोगकर्ता पेज के लोड होने के दौरान ही उससे इंटरैक्ट करने की कोशिश करें.
स्क्रिप्ट का आकलन, पेज लोड होने के दौरान इंटरैक्शन के इनपुट में लगने वाले समय को बढ़ा सकता है. नेटवर्क से JavaScript फ़ाइल फ़ेच करने के बाद, ब्राउज़र को उस JavaScript को चलाने से पहले कुछ और काम करने होते हैं. इनमें, स्क्रिप्ट को पार्स करके यह पक्का करना शामिल है कि उसका सिंटैक्स मान्य है या नहीं. इसके बाद, उसे बाइटकोड में कंपाइल करके उसे चलाया जाता है.
स्क्रिप्ट के साइज़ के आधार पर, इस काम से मुख्य थ्रेड पर लंबे टास्क आ सकते हैं. इससे ब्राउज़र को उपयोगकर्ता के अन्य इंटरैक्शन का जवाब देने में देरी होगी. पेज लोड होने के दौरान, उपयोगकर्ता के इनपुट का जवाब देने के लिए, यह समझना ज़रूरी है कि पेज लोड होने के दौरान लंबे टास्क की संभावना को कम करने के लिए क्या किया जा सकता है, ताकि पेज तेज़ी से लोड हो.
इवेंट कॉलबैक ऑप्टिमाइज़ करना
इनपुट डिले, INP के मेज़रमेंट का सिर्फ़ पहला हिस्सा है. आपको यह भी पक्का करना होगा कि उपयोगकर्ता इंटरैक्शन के जवाब में चलने वाले इवेंट कॉलबैक, जल्द से जल्द पूरे हो जाएं.
मुख्य थ्रेड पर अक्सर नतीजे देते हैं
इवेंट कॉलबैक को ऑप्टिमाइज़ करने के लिए, हमारा सुझाव है कि आप उनमें कम से कम काम करें. हालांकि, हो सकता है कि आपका इंटरैक्शन लॉजिक जटिल हो और आपके पास, एआई के काम को थोड़ा ही कम करने का विकल्प हो.
अगर आपको लगता है कि आपकी वेबसाइट के लिए भी ऐसा है, तो इवेंट कॉलबैक में मौजूद काम को अलग-अलग टास्क में बांटने की कोशिश करें. इससे, एक साथ किए जाने वाले काम को लंबे समय तक चलने वाले टास्क में बदलने से रोका जा सकता है. यह टास्क, मुख्य थ्रेड को ब्लॉक करता है. इससे, अन्य इंटरैक्शन जल्दी शुरू हो जाते हैं, जो मुख्य थ्रेड के इंतज़ार में होते हैं.
setTimeout, टास्क को अलग-अलग करने का एक तरीका है. ऐसा इसलिए, क्योंकि इसमें पास किया गया कॉलबैक, नए टास्क में चलता है. setTimeout का इस्तेमाल अपने-आप किया जा सकता है या ज़्यादा बेहतर नतीजे पाने के लिए, इसका इस्तेमाल किसी अलग फ़ंक्शन में किया जा सकता है.
बिना किसी वजह के बार-बार फ़्रेम छोड़ना, फ़्रेम न छोड़ने से बेहतर है. हालांकि, मुख्य थ्रेड को फ़्रेम छोड़ने का एक और बेहतर तरीका है. इसमें, यूज़र इंटरफ़ेस को अपडेट करने वाले इवेंट कॉलबैक के तुरंत बाद ही फ़्रेम छोड़ा जाता है, ताकि रेंडरिंग लॉजिक जल्दी चल सके.
रेंडरिंग की प्रोसेस जल्दी शुरू करने के लिए, Yield
बेहतर तरीके से फ़्रेम जनरेट करने के लिए, इवेंट कॉलबैक में कोड को स्ट्रक्चर करना ज़रूरी है. इससे, सिर्फ़ उस लॉजिक को चलाया जाता है जो अगले फ़्रेम के लिए विज़ुअल अपडेट लागू करने के लिए ज़रूरी होता है. बाकी सभी कामों को अगले टास्क के लिए टाला जा सकता है. इससे कॉलबैक को आसान और तेज़ बनाया जा सकता है. साथ ही, इवेंट कॉलबैक कोड पर विज़ुअल अपडेट को ब्लॉक करने की अनुमति न देकर, इंटरैक्शन के रेंडरिंग समय को भी बेहतर बनाया जा सकता है.
उदाहरण के लिए, एक ऐसे रिच टेक्स्ट एडिटर की कल्पना करें जो टाइप करते समय टेक्स्ट को फ़ॉर्मैट करता है. साथ ही, आपके लिखे गए टेक्स्ट के हिसाब से यूज़र इंटरफ़ेस (यूआई) के दूसरे पहलुओं को भी अपडेट करता है. जैसे, शब्दों की संख्या, वर्तनी की गड़बड़ियों को हाइलाइट करना, और अन्य अहम विज़ुअल फ़ीडबैक. इसके अलावा, ऐप्लिकेशन को आपके लिखे गए कॉन्टेंट को सेव भी करना पड़ सकता है, ताकि आपके ऐप्लिकेशन से बाहर निकलने और फिर से उस पर वापस आने पर, आपका कोई भी काम न छूटे.
इस उदाहरण में, उपयोगकर्ता के टाइप किए गए वर्णों के जवाब में, ये चार चीज़ें होनी चाहिए. हालांकि, अगला फ़्रेम दिखाने से पहले, सिर्फ़ पहला आइटम पूरा करना ज़रूरी है.
- उपयोगकर्ता ने जो टाइप किया है उससे टेक्स्ट बॉक्स को अपडेट करें और ज़रूरी फ़ॉर्मैटिंग लागू करें.
- यूज़र इंटरफ़ेस (यूआई) के उस हिस्से को अपडेट करें जो मौजूदा शब्दों की संख्या दिखाता है.
- स्पेलिंग की गड़बड़ियों की जांच करने के लिए लॉजिक चलाएं.
- हाल ही में किए गए बदलावों को सेव करें. ये बदलाव, स्थानीय या रिमोट डेटाबेस में सेव किए जा सकते हैं.
ऐसा करने के लिए, कोड कुछ ऐसा दिख सकता है:
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
नीचे दिए गए विज़ुअलाइज़ेशन में दिखाया गया है कि अगले फ़्रेम तक किसी भी ग़ैर-ज़रूरी अपडेट को टालने से, प्रोसेसिंग में लगने वाला समय और इंटरैक्शन में लगने वाला कुल समय कम हो सकता है.
पिछले कोड के उदाहरण में, requestAnimationFrame() कॉल के अंदर setTimeout() का इस्तेमाल करना थोड़ा मुश्किल है. हालांकि, यह एक असरदार तरीका है, जो सभी ब्राउज़र में काम करता है. इससे यह पक्का होता है कि ग़ैर-ज़रूरी कोड, अगले फ़्रेम को ब्लॉक न करे.
लेआउट थ्रैशिंग से बचना
लेआउट थ्रैशिंग—जिसे कभी-कभी फ़ोर्स्ड सिंक्रोनस लेआउट भी कहा जाता है—रेंडरिंग की परफ़ॉर्मेंस से जुड़ी एक समस्या है. इसमें लेआउट सिंक्रोनस तरीके से होता है. यह तब होता है, जब JavaScript में स्टाइल अपडेट की जाती हैं और फिर उन्हें उसी टास्क में पढ़ा जाता है. साथ ही, JavaScript में ऐसी कई प्रॉपर्टी होती हैं जिनकी वजह से लेआउट थ्रैशिंग हो सकती है.
लेआउट थ्रैशिंग, परफ़ॉर्मेंस की समस्या है. ऐसा इसलिए होता है, क्योंकि स्टाइल अपडेट करने के बाद, JavaScript में उन स्टाइल की वैल्यू का तुरंत अनुरोध करने पर, ब्राउज़र को सिंक्रोनस लेआउट का काम करना पड़ता है. हालांकि, इवेंट कॉलबैक के खत्म होने के बाद, ब्राउज़र को असिंक्रोनस तरीके से काम करने का इंतज़ार किया जा सकता था.
प्रज़ेंटेशन में लगने वाले समय को कम करना
किसी इंटरैक्शन मार्क के प्रज़ेंटेशन में लगने वाला समय, इंटरैक्शन के इवेंट कॉलबैक के खत्म होने से लेकर, ब्राउज़र के अगले फ़्रेम को पेंट करने तक का होता है. इस फ़्रेम में, इंटरैक्शन की वजह से हुए विज़ुअल बदलाव दिखते हैं.
डीओएम साइज़ को कम करना
जब किसी पेज का डीओएम छोटा होता है, तो आम तौर पर रेंडरिंग का काम जल्दी पूरा हो जाता है. हालांकि, जब डीओएम का साइज़ बहुत बड़ा हो जाता है, तो डीओएम के साइज़ के बढ़ने के साथ-साथ रेंडर करने का काम भी बढ़ जाता है. रेंडर करने के काम और डीओएम के साइज़ के बीच का संबंध लीनियर नहीं है. हालांकि, छोटे डीओएम की तुलना में बड़े डीओएम को रेंडर करने के लिए ज़्यादा काम करना पड़ता है. बड़ा डीओएम, दो मामलों में समस्या पैदा करता है:
- पेज के शुरुआती रेंडर के दौरान, जब बड़े DOM को पेज की शुरुआती स्थिति को रेंडर करने के लिए ज़्यादा काम करना पड़ता है.
- उपयोगकर्ता के इंटरैक्शन के जवाब में, बड़े डीओएम की वजह से अपडेट को रेंडर करने में काफ़ी समय लग सकता है. इसलिए, ब्राउज़र को अगला फ़्रेम दिखाने में ज़्यादा समय लगता है.
ध्यान रखें कि कुछ मामलों में, बड़े डीओएम को काफ़ी कम नहीं किया जा सकता. डीओएम के साइज़ को कम करने के लिए, कई तरीके अपनाए जा सकते हैं. जैसे, डीओएम को फ़्लैट करना या उपयोगकर्ता के इंटरैक्शन के दौरान डीओएम में जोड़ना, ताकि डीओएम का शुरुआती साइज़ छोटा रहे. हालांकि, ये तकनीकें सिर्फ़ कुछ हद तक ही काम करती हैं.
ऑफ़-स्क्रीन एलिमेंट को धीरे-धीरे रेंडर करने के लिए, content-visibility का इस्तेमाल करना
पेज लोड होने के दौरान और उपयोगकर्ता के इंटरैक्शन के जवाब में, रेंडरिंग के काम को सीमित करने का एक तरीका है कि सीएसएस content-visibility प्रॉपर्टी का इस्तेमाल किया जाए. इससे, एलिमेंट को व्यूपोर्ट के करीब आने पर, उन्हें धीरे-धीरे रेंडर किया जाता है. content-visibility का असरदार तरीके से इस्तेमाल करने के लिए, थोड़ी सी प्रैक्टिस की ज़रूरत पड़ सकती है. हालांकि, यह जांचना ज़रूरी है कि क्या रेंडरिंग में लगने वाला समय कम हो गया है, ताकि आपके पेज का INP बेहतर हो सके.
JavaScript का इस्तेमाल करके एचटीएमएल को रेंडर करते समय, परफ़ॉर्मेंस की लागत के बारे में जानना
जहां एचटीएमएल होता है वहां एचटीएमएल पार्सिंग होती है. ब्राउज़र, एचटीएमएल को DOM में पार्स करने के बाद, उस पर स्टाइल लागू करता है, लेआउट का हिसाब लगाता है, और फिर उस लेआउट को रेंडर करता है. यह एक ऐसी लागत है जिसे टाला नहीं जा सकता. हालांकि, एचटीएमएल को कैसे रेंडर किया जाता है, यह ज़रूरी है.
जब सर्वर एचटीएमएल भेजता है, तो वह ब्राउज़र में स्ट्रीम के तौर पर पहुंचता है. स्ट्रीमिंग का मतलब है कि सर्वर से एचटीएमएल रिस्पॉन्स, अलग-अलग हिस्सों में मिल रहा है. ब्राउज़र, स्ट्रीम को मैनेज करने के तरीके को ऑप्टिमाइज़ करता है. इसके लिए, वह स्ट्रीम के हिस्सों को धीरे-धीरे पार्स करता है और उन्हें थोड़ा-थोड़ा करके रेंडर करता है. यह परफ़ॉर्मेंस ऑप्टिमाइज़ेशन है. इसमें ब्राउज़र, पेज लोड होने के दौरान समय-समय पर और अपने-आप डेटा जनरेट करता है. यह सुविधा आपको बिना किसी शुल्क के मिलती है.
किसी भी वेबसाइट पर पहली बार जाने पर, हमेशा कुछ एचटीएमएल शामिल होता है. आम तौर पर, एचटीएमएल के कम से कम शुरुआती हिस्से के साथ शुरुआत की जाती है. इसके बाद, कॉन्टेंट एरिया को पॉप्युलेट करने के लिए JavaScript का इस्तेमाल किया जाता है. उपयोगकर्ता के इंटरैक्शन की वजह से, उस कॉन्टेंट एरिया में बाद में भी अपडेट होते रहते हैं. इसे आम तौर पर एक पेज के ऐप्लिकेशन (एसपीए) मॉडल कहा जाता है. इस पैटर्न का एक नुकसान यह है कि क्लाइंट पर JavaScript की मदद से एचटीएमएल रेंडर करने पर, आपको उस एचटीएमएल को बनाने के लिए JavaScript प्रोसेसिंग की लागत ही नहीं मिलती, बल्कि ब्राउज़र तब तक नहीं दिखेगा, जब तक वह उस एचटीएमएल को पार्स करके उसे रेंडर नहीं कर लेता.
हालांकि, यह याद रखना ज़रूरी है कि एसपीए नहीं वाली वेबसाइटों में भी इंटरैक्शन के नतीजे के तौर पर, JavaScript की मदद से कुछ हद तक एचटीएमएल रेंडरिंग शामिल होगी. आम तौर पर, यह तब तक ठीक रहता है, जब तक क्लाइंट पर ज़्यादा एचटीएमएल रेंडर नहीं किया जा रहा हो. इससे अगले फ़्रेम को दिखाने में देरी हो सकती है. हालांकि, ब्राउज़र में एचटीएमएल को रेंडर करने के लिए, इस तरीके की परफ़ॉर्मेंस पर पड़ने वाले असर को समझना ज़रूरी है. साथ ही, यह भी समझना ज़रूरी है कि अगर JavaScript की मदद से ज़्यादा एचटीएमएल रेंडर किया जा रहा है, तो यह उपयोगकर्ता के इनपुट पर आपकी वेबसाइट की प्रतिक्रिया पर कैसे असर डाल सकता है.
नतीजा
अपनी साइट के आईएनपी को बेहतर बनाने की प्रोसेस बार-बार इस्तेमाल होती है. फ़ील्ड में किसी इंटरैक्शन की स्पीड ठीक करने पर, आपको अन्य इंटरैक्शन की स्पीड भी धीमी दिख सकती है. ऐसा खास तौर पर तब होता है, जब आपकी वेबसाइट पर इंटरैक्शन की सुविधाएं ज़्यादा होती हैं. ऐसे में, आपको उन इंटरैक्शन को भी ऑप्टिमाइज़ करना होगा.
आईएनपी को बेहतर बनाने के लिए, लगातार कोशिश करना ज़रूरी है. समय के साथ, अपने पेज की रिस्पॉन्सिविटी को इस लेवल पर लाया जा सकता है कि उपयोगकर्ता आपके पेज पर मिलने वाले अनुभव से खुश हों. यह भी हो सकता है कि अपने उपयोगकर्ताओं के लिए नई सुविधाएं डेवलप करते समय, आपको उनके इंटरैक्शन को ऑप्टिमाइज़ करने के लिए, इसी प्रोसेस को दोहराना पड़े. इसमें समय और मेहनत लगती है, लेकिन यह समय और मेहनत बर्बाद नहीं होती.
Unsplash से ली गई हीरो इमेज, जिसे डेविड पिस्नोय ने Unsplash के लाइसेंस के मुताबिक बदला है.