आपकी AI-निर्मित ऐप धीमी क्यों लगती है (जबकि असल में नहीं है): प्रतीक्षा समय का भ्रम

आपकी ऐप 1.2 सेकंड में डेटा फेच करती है। एक इंसान 100 मिलीसेकंड को महसूस कर सकता है। आप इंसानी अनुभूति से 12 गुना तेज़ हैं, फिर भी यह धीमी लगती है। क्यों?

Perceived latency — यानी ऐप इस्तेमाल करने वाले को वह कितनी धीमी लगती है — का असल लोड टाइम से बहुत कम लेना-देना है। असल मायने यह रखता है कि इंतज़ार के दौरान यूज़र को यह समझ आ रहा है या नहीं कि हो क्या रहा है। धीमा और तेज़ झूठ हैं; फीडबैक ही असली चीज़ है।

मेरी ऐप तेज़ होने पर भी धीमी क्यों लगती है?

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

1. इंतज़ार के दौरान कोई फीडबैक नहीं।

एक फ़ॉर्म सबमिट होता है। बटन इनऐक्टिव हो जाता है (यह आम प्रैक्टिस है, डबल-क्लिक रोकती है)। इसके अलावा कुछ नहीं होता। एक सेकंड बीतता है। दो सेकंड। यूज़र को पता नहीं चलता कि यह प्रोसेस हो रहा है, अटक गया है, इंटरनेट चला गया है, या क्रैश हो गया है। दो सेकंड की खामोशी के बाद इंसान का दिमाग़ टैब बंद करने के बारे में सोचने लगता है।

यही वजह है कि 1.2 सेकंड — जो एक असली कंप्यूटेशन के लिए वाजिब समय है — भी धीमा महसूस होता है। यूज़र की बेचैनी उस खामोशी को भर देती है।

2. खाली स्क्रीनें।

एक पेज लोड होता है। हेडलाइन रेंडर हो जाती है। फिर 800ms तक कुछ नहीं होता जबकि ऐप उसके नीचे की लिस्ट फेच कर रही होती है। पेज टूटा हुआ दिखता है — अधूरा लेआउट, कोई प्लेसहोल्डर नहीं, बस… लोडिंग। 800ms का इंतज़ार 5 सेकंड के अहसास वाले पॉज़ में बदल जाता है, क्योंकि यूज़र की नज़र अधूरेपन को नाकामी के तौर पर देखती है।

3. प्रोग्रेस का कोई अंदाज़ा नहीं।

एक लंबा ऑपरेशन शुरू होता है। “Loading…” दिखता है। फिर? क्या यह 10% पर है या 90% पर? क्या यूज़र के पास कॉफ़ी पीने का समय है या यह तीन सेकंड में खत्म हो जाएगा? प्रोग्रेस के न दिखने से बेचैनी पैदा होती है। तेज़ + रहस्यमय = धीमा + पारदर्शी से भी ज़्यादा धीमा महसूस होता है।

धीमी लगने वाली ऐप को कैसे ठीक करें?

ऊपर बताए गए तीन कारणों के लिए तीन उपाय हैं: यूज़र के एक्शन लेते ही उसी पल फीडबैक दिखाएँ, डेटा लोड होने तक खाली जगह को प्लेसहोल्डर से भरें, और जिस भी काम में कुछ सेकंड से ज़्यादा लगे उसमें असली प्रोग्रेस दिखाएँ।

उपाय 1 — तुरंत कुछ दिखाएँ

फेच करने से पहले एक लोडिंग स्टेट लगाएँ। एक स्केलेटन स्क्रीन, एक स्पिनर, एक “thinking…” मैसेज। कुछ भी जो यह कहे “मुझे आपका टैप मिल गया, मैं काम पर लगा हूँ।”

उदाहरण: एक बुकिंग फ़ॉर्म सबमिट होता है। तुरंत बटन का टेक्स्ट बदलकर “Checking availability…” हो जाता है और एक छोटा-सा स्पिनर दिखता है। तभी फेच शुरू होता है। यूज़र को अपने एक्शन का जवाब तुरंत दिखता है, भले ही असली काम में 1.2 सेकंड लगें। यह फौरी फीडबैक ही इंतज़ार को छोटा महसूस कराता है।

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

टेस्ट करें: अपने फ़ोन पर वह एक्शन ट्रिगर करें। फीडबैक 100ms के अंदर दिखना चाहिए। अगर लोडिंग स्टेट आने से पहले 500ms की खामोशी दिखे, तो यूज़र इसका दोष ऐप को देगा।

उपाय 2 — खाली जगह को भरें

“Loading…” लिखे कोने वाली सफ़ेद स्क्रीन की जगह, आने वाली चीज़ की शक्ल दिखाएँ।

असली कहानी: एक वेडिंग प्लानर की बुकिंग ऐप उपलब्ध तारीख़ों की लिस्ट फेच कर रही थी। खाली पेज दिखाने की बजाय, प्लेसहोल्डर रो दिखाएँ — पाँच ग्रे रेक्टेंगल, जहाँ तारीख़ें आनी हैं। जब असली तारीख़ें लोड हो जाएँ, तो वे उनकी जगह ले लें। यूज़र का दिमाग़ इसे “instant” महसूस करता है, क्योंकि पेज कभी अधूरा दिखा ही नहीं।

बिल्डर से कहें: असली डेटा फेच करने से पहले लिस्ट या टेबल का एक प्लेसहोल्डर (स्केलेटन) वर्ज़न जोड़ें। डेटा आने पर, स्केलेटन को असली कंटेंट से बदल दें। हाँ, यह एक और चीज़ है जो बनानी पड़ेगी। लेकिन यह इसके लायक है क्योंकि यह अनुभूत इंतज़ार का समय आधा कर देती है।

टेस्ट करें: पेज को धीमे कनेक्शन (मोबाइल, 4G पर थ्रॉटल्ड) पर लोड करें। आपको खाली पेज दिखता है या कोई शक्ल? शक्ल जीतती है।

उपाय 3 — प्रोग्रेस दिखाएँ

तीन सेकंड से लंबे ऑपरेशन के लिए दिखाएँ कि आप कहाँ तक पहुँचे हैं।

असली कहानी: एक फ़ॉर्म 500 रो का डेटा स्प्रेडशीट में एक्सपोर्ट करता है। इसमें 4 सेकंड लगते हैं। प्रोग्रेस के बिना: “Exporting…” (15 सेकंड जैसा महसूस होता है, यूज़र कैंसिल कर देता है)। प्रोग्रेस के साथ: “Exporting row 127 of 500” (हर 200ms में अपडेट होता है, असली काम वही रहने पर भी 2 सेकंड जैसा महसूस होता है)।

ईमानदार पेच: अगर आपको सच में नहीं पता कि इसमें कितना समय लगेगा, तो प्रोग्रेस बार को नकली मत बनाइए। एक नकली बार जो 67% पर अटक जाए, वह ईमानदार “working” फीडबैक से भी ज़्यादा भरोसा तोड़ता है। असली प्रोग्रेस (अगर आप इसकी गणना कर सकते हैं) हमेशा नकली प्रोग्रेस से बेहतर होता है।

बिल्डर से कहें: 2 सेकंड से लंबे किसी भी ऑपरेशन के लिए, प्रोग्रेस अपडेट भेजें। फ़ाइल अपलोड के लिए, दिखाएँ कि कितने MB भेजे जा चुके हैं। लिस्ट फेच के लिए, दिखाएँ “loaded 50 items, fetching more…”। भले ही आपको कुल संख्या न पता हो, यह जानना कि कुछ हो रहा है धारणा बदल देता है।

टेस्ट करें: अपना नेटवर्क धीमा करके 3G पर लाएँ और इसे देखें। क्या यह अटका हुआ महसूस होता है या आगे बढ़ता हुआ?

---

अपनी ऐप का धीमापन कैसे टेस्ट करें?

Stranger Test चलाएँ: अपनी ऐप किसी और के फ़ोन पर लोड करें, उन्हें बिना आपकी मदद के मुख्य एक्शन टैप करने दें, और पूछें कि यह तेज़ लगी या धीमी।

अगर वे धीमी कहें, तो तीन चीज़ें जाँचें:

1. क्या उन्हें 100ms के भीतर फीडबैक दिखा? (टेक्स्ट बदलना, स्पिनर, स्टेट में बदलाव)
2. क्या इंतज़ार के दौरान उन्हें पेज की शक्ल दिखी? (स्केलेटन, प्लेसहोल्डर, कुछ भी)
3. क्या उन्हें पता था कि यह कहाँ तक पहुँच चुका है? (3 सेकंड से लंबे इंतज़ार के लिए)

अगर इनमें से किसी का जवाब “नहीं” है, तो पहले वही एक चीज़ ठीक करें।

---

रफ़्तार कोई नंबर नहीं है। बिना किसी फीडबैक वाली 1.2 सेकंड की API कॉल, हर आधे सेकंड में प्रोग्रेस दिखाने वाले 3 सेकंड के ऑपरेशन से ज़्यादा धीमी लगती है। फ़र्क़ ऐप में नहीं है — वह ऐप और उसे इस्तेमाल करने वाले इंसान के बीच की बातचीत में है।

फीडबैक ठीक कीजिए। जब लोगों को समझ आ जाता है कि हो क्या रहा है, तो वे धीमेपन का दोष देना बंद कर देते हैं।