लैब में धीमे इंटरैक्शन का मैन्युअल रूप से विश्लेषण करें

मैन्युअल टेस्टिंग की मदद से, इंटरैक्शन में लगने वाले समय की समस्या को ठीक करने और उसे फिर से बनाने के लिए, अपने फ़ील्ड डेटा को लैब में ले जाने का तरीका जानें.

Jeremy Wagner

पब्लिश किए जाने की तारीख: 9 मई, 2023

पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को ऑप्टिमाइज़ करने में सबसे मुश्किल काम यह पता लगाना है कि आईएनपी खराब क्यों हो रहा है. इसकी कई वजहें हो सकती हैं. जैसे, तीसरे पक्ष की स्क्रिप्ट जो मुख्य थ्रेड पर कई टास्क शेड्यूल करती हैं, बड़े DOM साइज़, महंगे इवेंट कॉलबैक, और दूसरी गड़बड़ियां.

आईएनपी को बेहतर बनाना मुश्किल हो सकता है. सबसे पहले, आपको यह जानना होगा कि किसी पेज के आईएनपी के लिए कौनसे इंटरैक्शन ज़िम्मेदार होते हैं. अगर आपको नहीं पता कि आपकी वेबसाइट पर, उपयोगकर्ताओं के हिसाब से कौनसे इंटरैक्शन सबसे धीमे होते हैं, तो फ़ील्ड में धीमे इंटरैक्शन ढूंढना लेख पढ़ें. जब आपको गाइड करने के लिए फ़ील्ड डेटा मिल जाता है, तब लैब टूल में उन इंटरैक्शन की मैन्युअल तरीके से जांच की जा सकती है. इससे यह पता लगाया जा सकता है कि ये इंटरैक्शन धीमे क्यों हो रहे हैं.

अगर आपके पास फ़ील्ड डेटा नहीं है, तो क्या होगा?

फ़ील्ड डेटा का होना बहुत ज़रूरी है, क्योंकि इससे यह पता लगाने में लगने वाला आपका समय बचता है कि कौनसे इंटरैक्शन ऑप्टिमाइज़ करने हैं. हालांकि, ऐसा हो सकता है कि आपके पास फ़ील्ड डेटा न हो. अगर आपकी स्थिति इसी तरह की है, तो अब भी ऐसे इंटरैक्शन ढूंढे जा सकते हैं जिनसे परफ़ॉर्मेंस को बेहतर बनाया जा सके. हालांकि, इसके लिए थोड़ी ज़्यादा मेहनत और अलग तरीके की ज़रूरत होगी.

कुल ब्लॉकिंग समय (टीबीटी) एक लैब मेट्रिक है. इससे, पेज लोड होने के दौरान उसके रिस्पॉन्सिव होने का आकलन किया जाता है. साथ ही, यह आईएनपी से जुड़ी होती है. अगर आपके पेज का टीबीटी ज़्यादा है, तो हो सकता है कि पेज लोड होने के दौरान, उपयोगकर्ता के इंटरैक्शन के लिए आपका पेज बहुत ज़्यादा रिस्पॉन्सिव न हो.

अपने पेज के टीबीटी का पता लगाने के लिए, लाइटहाउस का इस्तेमाल किया जा सकता है. अगर किसी पेज का टीबीटी ज़्यादा है, तो हो सकता है कि पेज लोड होने के दौरान मुख्य थ्रेड बहुत व्यस्त हो. इससे इस बात पर भी असर पड़ सकता है कि पेज के लाइफ़साइकल के दौरान, पेज कितना सही तरीके से काम करेगा.

पेज लोड होने के बाद, धीमे इंटरैक्शन का पता लगाने के लिए, आपको अन्य तरह के डेटा की ज़रूरत पड़ सकती है. जैसे, सामान्य यूज़र फ़्लो जिसे आपने वेबसाइट के आंकड़ों में पहले ही पहचान लिया हो. उदाहरण के लिए, अगर आप किसी ई-कॉमर्स वेबसाइट पर काम करते हैं, तो सामान्य उपयोगकर्ता फ़्लो में वे कार्रवाइयां शामिल होंगी जो उपयोगकर्ता ऑनलाइन शॉपिंग कार्ट में आइटम जोड़ते और चेकआउट करते समय करते हैं.

आपके पास फ़ील्ड डेटा हो या न हो, अगला चरण मैन्युअल तरीके से किए गए इंटरैक्शन की जांच करना और उन्हें फिर से दिखाना है. ऐसा इसलिए, क्योंकि धीमे इंटरैक्शन को पूरा करने के बाद ही इसे ठीक किया जा सकता है.

लैब में धीमे इंटरैक्शन फिर से करना

मैन्युअल टेस्टिंग की मदद से, लैब में धीमे इंटरैक्शन को दोहराने के कई तरीके हैं. हालांकि, यहां एक फ़्रेमवर्क दिया गया है जिसे आज़माया जा सकता है.

DevTools के परफ़ॉर्मेंस पैनल की लाइव मेट्रिक

DevTools की परफ़ॉर्मेंस प्रोफ़ाइलर की मदद से, धीमे इंटरैक्शन का पता लगाया जा सकता है. हालांकि, जब आपको यह पता नहीं होता कि कौनसे इंटरैक्शन में समस्या है, तो धीमे इंटरैक्शन की पहचान करने में समय लग सकता है.

हालांकि, परफ़ॉर्मेंस पैनल को पहली बार खोलने पर, आपको लाइव मेट्रिक व्यू दिखेगा. इसका इस्तेमाल, परफ़ॉर्मेंस प्रोफ़ाइलर के ज़्यादा जानकारी वाले सेक्शन पर जाने से पहले, कई इंटरैक्शन को तुरंत आज़माने के लिए किया जा सकता है. इससे, आपको समस्या वाले इंटरैक्शन का पता चलता है. इंटरैक्ट करने पर, गड़बड़ी का डेटा इंटरैक्शन लॉग में दिखेगा. इसमें आईएनपी इंटरैक्शन को हाइलाइट किया जाएगा. फ़ेज़ के ब्रेकडाउन पाने के लिए, इन इंटरैक्शन को बढ़ाया जा सकता है:

वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी देने वाला एक्सटेंशन, धीमे इंटरैक्शन की पहचान करने में मदद करता है. साथ ही, INP को डीबग करने में भी मदद करने के लिए कुछ जानकारी देता है. हालांकि, धीमे इंटरैक्शन का पता लगाने के लिए, आपको परफ़ॉर्मेंस प्रोफ़ाइलर का इस्तेमाल करना पड़ सकता है. ऐसा इसलिए, क्योंकि यह आपको ज़्यादा जानकारी वाला डेटा देता है. इस डेटा की मदद से, आपको अपनी वेबसाइट के प्रोडक्शन कोड में जाकर, धीमे इंटरैक्शन की वजहें पता लगानी होंगी.

कोई ट्रेस रिकॉर्ड करना

धीमे इंटरैक्शन का पता लगाने और उससे जुड़ी समस्या हल करने के लिए, Chrome की परफ़ॉर्मेंस प्रोफ़ाइलर का इस्तेमाल करने का सुझाव दिया जाता है. Chrome के परफ़ॉर्मेंस प्रोफ़ाइलर में किसी इंटरैक्शन की प्रोफ़ाइल बनाने के लिए, यह तरीका अपनाएं:

1. वह पेज खोलें जिसकी आपको जांच करनी है.
2. Chrome DevTools खोलें और परफ़ॉर्मेंस पैनल पर जाएं.
3. ट्रैकिंग शुरू करने के लिए, पैनल के ऊपर बाईं ओर मौजूद रिकॉर्ड करें बटन पर क्लिक करें.
4. वह इंटरैक्शन करें जिसकी समस्या हल करनी है.
5. ट्रैकिंग बंद करने के लिए, रिकॉर्ड करें बटन पर फिर से क्लिक करें.

जब प्रोफ़ाइलर में जानकारी भर जाती है, तो सबसे पहले प्रोफ़ाइलर में सबसे ऊपर मौजूद गतिविधि की खास जानकारी देखें. गतिविधि की खास जानकारी में, सबसे ऊपर लाल बार दिखते हैं. ये ऐसे हिस्से होते हैं जहां रिकॉर्डिंग में लंबे समय तक कोई टास्क किया गया है. इससे, समस्या वाले हिस्सों पर तुरंत ज़ूम इन किया जा सकता है.

गतिविधि की खास जानकारी में जाकर, किसी इलाके को खींचकर चुनकर, समस्या वाले इलाकों पर तुरंत फ़ोकस किया जा सकता है. टाइमलाइन को छोटा करने और उससे जुड़ी गतिविधि को अनदेखा करने के लिए, प्रोफ़ाइलर में ब्रेडक्रंब की सुविधा का इस्तेमाल किया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है.

इंटरैक्शन होने की जगह पर फ़ोकस करने के बाद, इंटरैक्शन ट्रैक की मदद से, इंटरैक्शन और उसके नीचे मौजूद मुख्य थ्रेड ट्रैक में हुई गतिविधि को अलाइन किया जा सकता है:

इंटरैक्शन ट्रैक में इंटरैक्शन पर कर्सर घुमाकर, इस बारे में ज़्यादा जानकारी पाई जा सकती है कि इंटरैक्शन का कौनसा हिस्सा सबसे लंबा था:

इंटरैक्शन के स्ट्रिप वाले हिस्से से पता चलता है कि इंटरैक्शन में 200 मिलीसेकंड से ज़्यादा समय कब लगा. यह किसी पेज के आईएनपी के लिए "अच्छा" थ्रेशोल्ड की ऊपरी सीमा होती है. इंटरैक्शन के ये हिस्से शामिल किए जाते हैं:

1. इनपुट में देरी—इसे बाईं ओर मौजूद व्हिस्कर में दिखाया जाता है.
2. प्रोसेसिंग में लगने वाला समय—इसे बाईं और दाईं विस्कर के बीच के सॉलिड ब्लॉक से दिखाया जाता है.
3. प्रज़ेंटेशन में लगा समय—इसे दाईं ओर मौजूद व्हिसकर से दिखाया जाता है.

अब आपको उन समस्याओं के बारे में ज़्यादा जानकारी चाहिए जिनकी वजह से इंटरैक्शन की दर कम है. इस बारे में इस गाइड में आगे बताया गया है.

यह कैसे पता लगाएं कि इंटरैक्शन का कौनसा हिस्सा धीमा है

इंटरैक्शन में तीन हिस्से होते हैं: इनपुट में लगने वाला समय, प्रोसेस होने में लगने वाला समय, और प्रज़ेंटेशन में लगने वाला समय. किसी पेज के आईएनपी को कम करने के लिए, इंटरैक्शन को ऑप्टिमाइज़ करने का तरीका इस बात पर निर्भर करता है कि पेज के किस हिस्से में सबसे ज़्यादा समय लग रहा है.

इनपुट में लंबी देरी की पहचान करने का तरीका

इनपुट में देरी होने पर, इंटरैक्शन में लगने वाला समय ज़्यादा हो सकता है. इनपुट डिले, इंटरैक्शन का पहला हिस्सा होता है. यह वह समयावधि होती है जब ऑपरेटिंग सिस्टम को उपयोगकर्ता की कार्रवाई पहली बार मिलती है और ब्राउज़र उस इंटरैक्शन के पहले इवेंट हैंडलर कॉलबैक को प्रोसेस करना शुरू कर देता है.

Chrome के परफ़ॉर्मेंस प्रोफ़ाइलर में इनपुट देरी की पहचान करने के लिए, इंटरैक्शन ट्रैक में इंटरैक्शन को ढूंढा जा सकता है. बाईं ओर मौजूद व्हिसकर की लंबाई से, इंटरैक्शन के इनपुट में लगने वाले समय का पता चलता है. परफ़ॉर्मेंस प्रोफ़ाइलर में इंटरैक्शन पर कर्सर घुमाकर, टूलटिप में सटीक वैल्यू देखी जा सकती है.

इनपुट में लगने वाला समय कभी शून्य नहीं हो सकता. हालांकि, आपके पास यह कंट्रोल करने का विकल्प होता है कि इनपुट में लगने वाला समय कितना हो. इसके लिए, यह पता लगाना ज़रूरी है कि मुख्य थ्रेड पर कोई ऐसा काम तो नहीं चल रहा है जिसकी वजह से आपके कॉलबैक सही समय पर नहीं चल पा रहे हैं.

ऊपर दिए गए डेटा में, जब उपयोगकर्ता पेज से इंटरैक्ट करने की कोशिश कर रहा होता है, तब तीसरे पक्ष की स्क्रिप्ट का टास्क चल रहा होता है. इससे, इनपुट में देरी बढ़ जाती है. इनपुट में लगने वाले ज़्यादा समय से, इंटरैक्शन में लगने वाले समय पर असर पड़ता है. इसलिए, इसका असर पेज के आईएनपी पर पड़ सकता है.

प्रोसेस में लगने वाले लंबे समय की पहचान करने का तरीका

इवेंट कॉलबैक, इनपुट में लगने वाले समय के तुरंत बाद शुरू होते हैं. इन्हें पूरा होने में लगने वाले समय को प्रोसेसिंग की अवधि कहा जाता है. अगर इवेंट कॉलबैक बहुत देर तक चलते हैं, तो वे ब्राउज़र को अगला फ़्रेम दिखाने में देरी करते हैं. साथ ही, किसी इंटरैक्शन के कुल इंतज़ार में काफ़ी बढ़ोतरी कर सकते हैं. प्रोसेसिंग में लगने वाला लंबा समय, पहले पक्ष या तीसरे पक्ष के ऐसे JavaScript के इस्तेमाल की वजह से हो सकता है जिसे प्रोसेस करने में ज़्यादा समय लगता है. कुछ मामलों में, दोनों की वजह से भी ऐसा हो सकता है. परफ़ॉर्मेंस प्रोफ़ाइलर में, इसे इंटरैक्शन ट्रैक में इंटरैक्शन के ठोस हिस्से से दिखाया जाता है.

किसी खास इंटरैक्शन के लिए, ट्रैक में इन चीज़ों को देखकर, ज़्यादा समय लेने वाले इवेंट कॉलबैक का पता लगाया जा सकता है:

1. यह तय करें कि इवेंट कॉलबैक से जुड़ा टास्क, लंबा टास्क है या नहीं. लैब की सेटिंग में लंबे टास्क देखने के लिए, आपको परफ़ॉर्मेंस पैनल में सीपीयू थ्रॉटलिंग चालू करनी पड़ सकती है. इसके अलावा, कम लेवल वाले Android डिवाइस को मिड-टीयर Android डिवाइस से कनेक्ट करना पड़ सकता है और रिमोट डीबगिंग का इस्तेमाल करना पड़ सकता है.
2. अगर इवेंट कॉलबैक चलाने वाला टास्क लंबा है, तो कॉल स्टैक में इवेंट हैंडलर एंट्री ढूंढें. उदाहरण के लिए, इवेंट: क्लिक जैसे नाम वाली एंट्री. इन एंट्री के ऊपरी दाएं कोने में लाल रंग का त्रिकोण होता है.

किसी इंटरैक्शन को प्रोसेस होने में लगने वाले समय को कम करने के लिए, इनमें से कोई एक तरीका आज़माएं:

1. कम से कम काम करें. क्या महंगे इवेंट कॉलबैक में होने वाली हर चीज़ ज़रूरी है? अगर ऐसा नहीं है, तो अगर हो सके, तो उस कोड को पूरी तरह हटा दें या अगर ऐसा नहीं किया जा सकता, तो उसे बाद में एक्ज़ीक्यूट करें. मदद पाने के लिए, फ़्रेमवर्क की सुविधाओं का भी फ़ायदा लिया जा सकता है. उदाहरण के लिए, React की मेमोज़ेशन सुविधा अगर किसी कॉम्पोनेंट को रेंडर करने के ग़ैर-ज़रूरी काम को छोड़ देती है, तो उसके प्रॉप में कोई बदलाव नहीं होता है.
2. इवेंट कॉलबैक में, रेंडर न करने की प्रोसेस को कुछ समय बाद टालें. मुख्य थ्रेड को सबमिट करके, लंबे टास्क को छोटे-छोटे टास्क में बांटा जा सकता है. जब भी आप मुख्य थ्रेड पर जाते हैं, तो मौजूदा टास्क खत्म हो जाता है और बचे हुए काम को अलग टास्क में बांट दिया जाता है. इससे रेंडरर को, इवेंट कॉलबैक में पहले किए गए यूज़र इंटरफ़ेस के अपडेट को प्रोसेस करने का मौका मिलता है. अगर React का इस्तेमाल किया जा रहा है, तो इसकी ट्रांज़िशन सुविधा से यह काम किया जा सकता है.

इन रणनीतियों से, आपको इवेंट कॉलबैक को ऑप्टिमाइज़ करने में मदद मिल सकती है, ताकि उन्हें चलने में कम समय लगे.

प्रज़ेंटेशन में देरी की पहचान करने का तरीका

खराब आईएनपी की सिर्फ़ इन वजहों से ही नहीं होती है: इनपुट में लगने वाला ज़्यादा समय और प्रोसेसिंग में लगने वाला ज़्यादा समय. कभी-कभी इवेंट कॉलबैक कोड की कम संख्या के रिस्पॉन्स में, रेंडरिंग से जुड़े अपडेट महंगे हो सकते हैं. किसी इंटरैक्शन का नतीजा दिखाने के लिए, ब्राउज़र को यूज़र इंटरफ़ेस में विज़ुअल अपडेट रेंडर करने में लगने वाले समय को प्रज़ेंटेशन में देरी कहा जाता है.

रेंडरिंग के काम में, आम तौर पर स्टाइल का फिर से हिसाब लगाना, लेआउट, पेंट, और कंपोजिट जैसे टास्क शामिल होते हैं. इन्हें प्रोफ़ाइलर के फ़्लेम चार्ट में बैंगनी और हरे रंग के ब्लॉक से दिखाया जाता है. प्रज़ेंटेशन में लगने वाला कुल समय, इंटरैक्शन ट्रैक में इंटरैक्शन के दाएं व्हिस्कर से दिखाया जाता है.

इंटरैक्शन में लगने वाले ज़्यादा समय की सभी संभावित वजहों में से, प्रज़ेंटेशन में लगने वाले समय की समस्या को हल करना और ठीक करना सबसे मुश्किल हो सकता है. रेंडरिंग में ज़्यादा समय लगने की ये वजहें हो सकती हैं:

• बड़े साइज़ के DOM. पेज के डीओएम के साइज़ के साथ-साथ, पेज के प्रज़ेंटेशन को अपडेट करने के लिए ज़रूरी रेंडरिंग का काम भी अक्सर बढ़ जाता है. ज़्यादा जानकारी के लिए, बड़े डीओएम साइज़ से इंटरैक्टिविटी पर क्या असर पड़ता है और इसके लिए क्या किया जा सकता है लेख पढ़ें.
• हर हाल में होने वाले रीफ़्लो. ऐसा तब होता है, जब JavaScript में एलिमेंट की स्टाइल में बदलाव किए जाते हैं और फिर उस काम के नतीजों के बारे में तुरंत क्वेरी की जाती है. इसका नतीजा यह होता है कि कुछ भी करने से पहले ब्राउज़र को लेआउट का काम करना होता है, ताकि ब्राउज़र अपडेट की गई स्टाइल दिखा सके. ज़्यादा जानकारी और फ़ोर्स्ड रीफ़्लो से बचने के बारे में सलाह पाने के लिए, बड़े और जटिल लेआउट और लेआउट थ्रैशिंग से बचना लेख पढ़ें.
• requestAnimationFrame कॉलबैक में बहुत ज़्यादा या ग़ैर-ज़रूरी काम. requestAnimationFrame() कॉलबैक, इवेंट लूप के रेंडरिंग फ़ेज़ के दौरान चलाए जाते हैं. साथ ही, अगला फ़्रेम दिखाए जाने से पहले, इन्हें पूरा करना ज़रूरी होता है. अगर requestAnimationFrame() का इस्तेमाल ऐसे काम के लिए किया जा रहा है जिसमें यूज़र इंटरफ़ेस में कोई बदलाव नहीं किया गया है, तो ध्यान रखें कि इसकी वजह से अगले फ़्रेम में देरी हो रही है.
• ResizeObserver कॉलबैक. ये कॉलबैक, रेंडरिंग से पहले चलते हैं. अगर इनमें ज़्यादा काम होता है, तो अगले फ़्रेम को दिखाने में देरी हो सकती है. इवेंट कॉलबैक की तरह ही, अगले फ़्रेम के लिए ज़रूरी न होने वाले लॉजिक को बाद के लिए छोड़ दें.

अगर धीमे इंटरैक्शन को दोबारा नहीं चलाया जा सकता, तो क्या करें?

अगर आपके फ़ील्ड डेटा से पता चलता है कि कोई इंटरैक्शन धीमा है, लेकिन लैब में मैन्युअल तरीके से समस्या को दोहराया नहीं जा सकता, तो क्या करें? ऐसा होने की कुछ वजहें हो सकती हैं. हालांकि, इसकी एक खास वजह यह है कि टेस्ट इंटरैक्शन के दौरान आपकी स्थितियां, आपके हार्डवेयर और नेटवर्क कनेक्शन पर निर्भर करती हैं. हो सकता है कि आपके पास तेज़ इंटरनेट कनेक्शन वाला डिवाइस हो, लेकिन इसका मतलब यह नहीं है कि आपके उपयोगकर्ताओं के पास भी ऐसा ही डिवाइस हो. अगर यह समस्या आपके लिए सही है, तो इनमें से कोई एक तरीका आज़माएं:

1. अगर आपके पास कोई Android डिवाइस है, तो रिमोट डीबगिंग का इस्तेमाल करके, अपनी होस्ट मशीन पर Chrome DevTools का कोई इंस्टेंस खोलें. इसके बाद, उस पर धीमे इंटरैक्शन की समस्या को दोबारा देखें. मोबाइल डिवाइस अक्सर लैपटॉप या डेस्कटॉप मशीनों की तरह तेज़ नहीं होते हैं, इसलिए इन डिवाइसों पर धीमे इंटरैक्शन अधिक आसानी से देखे जा सकते हैं.
2. अगर आपके पास कोई फ़िज़िकल डिवाइस नहीं है, तो Chrome DevTools में सीपीयू थ्रॉटलिंग की सुविधा चालू करें.
3. ऐसा हो सकता है कि आपने पेज पर इंटरैक्ट करने से पहले, पेज के लोड होने का इंतज़ार किया हो, लेकिन आपके उपयोगकर्ताओं ने ऐसा न किया हो. अगर आपके पास तेज़ इंटरनेट कनेक्शन है, तो नेटवर्क थ्रॉटलिंग की सुविधा चालू करके, नेटवर्क की धीमी स्पीड को सिम्युलेट करें. इसके बाद, पेज पेंटी होने के तुरंत बाद उससे इंटरैक्ट करें. आपको ऐसा करना चाहिए, क्योंकि स्टार्टअप के दौरान मुख्य थ्रेड अक्सर सबसे व्यस्त होती है. इस दौरान टेस्टिंग करने से पता चल सकता है कि आपके उपयोगकर्ताओं को क्या समस्या आ रही है.

आईएनपी से जुड़ी समस्या हल करने की प्रोसेस बार-बार इस्तेमाल होती है

यह पता लगाना कि इंटरैक्शन में लगने वाले ज़्यादा समय की वजह से, INP खराब क्यों हो रहा है, बहुत मुश्किल काम है. हालांकि, अगर आपको इसकी वजहें पता चल जाती हैं, तो इसका मतलब है कि आपने आधी समस्या हल कर ली है. खराब आईएनपी की समस्या हल करने के लिए, किसी व्यवस्थित तरीके का इस्तेमाल करें. इससे, आपको पता चलेगा कि समस्या किस वजह से हो रही है और उसे जल्दी ठीक किया जा सकता है. समीक्षा करने के लिए:

• धीमे इंटरैक्शन का पता लगाने के लिए, फ़ील्ड डेटा का इस्तेमाल करें.
• लैब में, समस्या वाले फ़ील्ड इंटरैक्शन की मैन्युअल तौर पर जांच करें. इससे यह पता चलेगा कि उन्हें दोबारा बनाया जा सकता है या नहीं.
• पता लगाएं कि इसकी वजह, इनपुट में हुई देरी, इवेंट कॉलबैक की ज़्यादा लागत या रेंडरिंग में हुई ज़्यादा लागत है या नहीं.
• दोहराएं.

इनमें से आखिरी बात सबसे अहम है. पेज की परफ़ॉर्मेंस को बेहतर बनाने के लिए किए जाने वाले दूसरे कामों की तरह ही, आईएनपी में भी समस्या का हल करना और उसे बेहतर बनाना एक जटिल प्रक्रिया है. किसी एक इंटरैक्शन को ठीक करने के बाद, अगले इंटरैक्शन पर जाएं. ऐसा तब तक करें, जब तक आपको नतीजे न दिखने लगें.