आपकी AI से बनी app धीमी क्यों लगती है (और इसके बारे में क्या करें)

आपकी AI से बनी app चलती है। buttons जहां जाने चाहिए वहीं जाते हैं, screens ठीक से बैठती हैं, data save होता है। पर कुछ खटकता है। pages load होने में एक पल ज़्यादा लेते हैं। पचास items की एक list एक सेकंड के लिए अटक जाती है। “save” पर क्लिक करने पर आपको इंतज़ार करना पड़ता है, फिर थोड़ा और इंतज़ार, फिर सोचना पड़ता है कि कहीं दोबारा क्लिक न करना पड़े। कुछ टूटा नहीं है — बस यह धीमी लगती है।

अगर आप एक गैर-तकनीकी founder हैं जो किसी AI app builder से शिप कर रहे हैं, तो यह सबसे आम “मुझे नहीं पता क्या ग़लत है” वाले पलों में से एक है। अच्छी ख़बर यह है कि 80% धीमी AI से बनी apps उन्हीं चंद वजहों से धीमी होती हैं। इनमें से किसी के लिए आपको यह सीखने की ज़रूरत नहीं कि databases कैसे काम करते हैं। इन सबके ऐसे उपाय हैं जो आप अपने AI builder से आसान अंग्रेज़ी में करवा सकते हैं।

यह पोस्ट वही cheat sheet है।

“धीमा” आमतौर पर चार चीज़ें क्यों होती हैं

जब users कहते हैं कि कोई app धीमी लगती है, तो उनका मतलब लगभग कभी “server कमज़ोर है” नहीं होता। उनका मतलब इन चार में से एक होता है:

1. पहला paint धीमा है — वो एक link पर क्लिक करते हैं और कुछ भी दिखने से पहले दो सेकंड एक ख़ाली screen घूरते हैं।
2. एक लंबी list सुस्त है — scroll करना, filter करना, या “मेरे सारे projects” load करना Instagram scroll करने से ज़्यादा वक़्त लेता है।
3. एक action बहुत वक़्त लेता है बिना यह बताए कि हो क्या रहा है — वो “save” या “send” क्लिक करते हैं और दिखने में कुछ जवाब नहीं देता।
4. database से बहुत सारे सवाल पूछे जा रहे हैं — जो pages कई जगहों से data दिखाते हैं, वो हर टुकड़े को अलग-अलग लाते हैं और इंतज़ार के समय को एक के ऊपर एक जोड़ देते हैं।

बस इतना ही। लगभग हर धीमी AI से बनी app जो मैंने देखी है, उन्हीं चार वजहों में से एक से धीमी है। हर एक को कैसे पहचानें और अपने builder से इसके बारे में क्या करवाएं, यह रहा।

धीमेपन की वजह #1: पहला paint

यह कैसा दिखता है: आप अपनी app के एक link पर क्लिक करते हैं, URL bar का loading पूरा हो जाता है, पर कुछ भी दिखने से पहले page एक-दो सेकंड के लिए सफ़ेद रहता है।

इसकी वजह आमतौर पर: app आपको कुछ भी दिखाने से पहले JavaScript का हर वो टुकड़ा load कर रही है जिसकी उसे ज़रूरत पड़ सकती है। AI app builders उदारता से bundle करते हैं — किसी चीज़ को शामिल करना उसे छूट जाने देने से बेहतर — और आप जितने ज़्यादा features जोड़ते हैं, वो bundle उतना बड़ा होता जाता है।

अपने AI builder से क्या मांगें: “पहला page load धीमा लगता है। क्या तुम JavaScript bundles को route के हिसाब से बांट सकते हो ताकि home page को पूरा admin section download न करना पड़े?” या, और आसान तरीके से: “उन routes के लिए lazy loading जोड़ो जो home page नहीं हैं।” ज़्यादातर आधुनिक frameworks इसे एक-दो लाइन के config में support करते हैं। AI को पता है कैसे — आपको बस मांगना है।

साथ-ही-साथ: “क्या landing page पर कोई बड़ी images हैं जिन्हें हम optimize कर सकें?” एक 4 MB का hero photo महसूस होने वाली speed को किसी भी code समस्या से ज़्यादा डुबो देगा।

धीमेपन की वजह #2: लंबी list

यह कैसा दिखता है: आपके पास एक list है — projects, contacts, posts, कुछ भी — और एक बार वो चालीस-पचास items से आगे बढ़ती है, तो scroll करना अटकता है या filter करना एक साफ़ झटका लेता है।

इसकी वजह आमतौर पर: app हर एक item को एक साथ page पर render कर रही है, उन्हें भी जिन्हें आप देख नहीं सकते। दस items के साथ यह ठीक है। पांच सौ के साथ, browser दम तोड़ देता है।

अपने AI builder से क्या मांगें: “items ज़्यादा होने पर projects list धीमी हो जाती है। क्या हम pagination जोड़ सकते हैं, या list को virtualize कर सकते हैं ताकि सिर्फ़ दिखने वाली rows render हों?” Pagination (“हर page पर 20 दिखाओ, next/previous buttons के साथ”) सबसे आसान उपाय है। Virtualization (“user के scroll करते वक़्त सिर्फ़ वही render करो जो screen पर है”) ज़्यादा चिकना लगता है पर थोड़ा ज़्यादा काम है। दोनों में से कोई भी ठीक है।

अगर list में search या filtering भी है: “क्या search का filter browser के बजाय server पर हो सकता है?” Server-side filtering का मतलब है कि browser के पास कभी सिर्फ़ मेल खाती rows होती हैं, पूरा dataset नहीं।

धीमेपन की वजह #3: ख़ामोश इंतज़ार

यह कैसा दिखता है: आप “save” या “send” या “generate” क्लिक करते हैं। दिखने में कुछ नहीं होता। दो सेकंड बाद, screen अपडेट होती है और आपको एहसास होता है कि वो पूरे वक़्त काम कर रही थी।

इसकी वजह आमतौर पर: app असली काम कर रही है — database में save कर रही है, किसी API को call कर रही है — पर AI builder ने कोई loading state नहीं जोड़ी। तो आपके नज़रिए से, क्लिक ने कुछ नहीं किया।

यह असल में कोई performance समस्या है ही नहीं। यह एक महसूस होने वाली performance समस्या है, और वो अक्सर असली वालों से ज़्यादा तकलीफ़देह होती हैं। बिना किसी feedback के 200-मिलीसेकंड का action, spinner वाले 2-सेकंड के action से ज़्यादा धीमा महसूस होता है, क्योंकि user का दिमाग़ अंधेरे में होता है।

अपने AI builder से क्या मांगें: “हर उस बटन पर एक loading state जोड़ो जो कोई action चलाता है। जब वो काम कर रहा हो तो एक spinner या ‘Saving…’ text दिखाओ, और बटन को disable कर दो ताकि users दो बार क्लिक न कर सकें।” यह किसी भी app में सबसे ज़्यादा ROI वाला performance उपाय है और इसमें लगभग कुछ ख़र्च नहीं होता।

साथ-ही-साथ: “जिन actions के नतीजे हमें पहले से पता हैं, उनके लिए क्या हम UI को optimistic तरीके से अपडेट कर सकते हैं — बदलाव फ़ौरन दिखाओ और अगर server अस्वीकार कर दे तो उसे वापस ले लो?” Optimistic updates ही वजह हैं कि social apps पर “like” बटन तब भी फ़ौरन महसूस होता है जब आपके फ़ोन का network बेहद ख़राब हो।

धीमेपन की वजह #4: बातूनी database

यह कैसा दिखता है: एक page जो items की एक list दिखाता है, हर एक के साथ अतिरिक्त जानकारी — जैसे projects की एक list जिसमें हर project में tasks की संख्या हो — एक सादी list से कहीं ज़्यादा वक़्त load होने में लेता है।

इसकी वजह आमतौर पर: page projects को एक query में load कर रहा है, फिर हर project के लिए task count को एक अलग query में load कर रहा है। दस projects? ग्यारह queries। सौ projects? एक सौ एक। इसे “N+1 query” कहते हैं, और यह AI से बनी apps में सबसे आम database performance bug है क्योंकि AI ऐसे code के लिए optimize कर रहा होता है जो साफ़-साफ़ पढ़ा जाए, ऐसे code के लिए नहीं जो असरदार ढंग से चले।

अपने AI builder से क्या मांगें: “यह page हर item के लिए एक query बना रहा है। क्या हम सारा जुड़ा हुआ data एक ही query में ला सकते हैं — एक join या एक aggregate?” आपको इनमें से किसी भी शब्द का मतलब जानने की ज़रूरत नहीं। AI को है। उसे धीमा page दिखाना और कहना “मुझे लगता है इसमें एक N+1 समस्या है” आमतौर पर काफ़ी होता है।

आप किसी भी टूल के बिना N+1 समस्याएं पहचान सकते हैं: page खोलिए, गिनिए कि उसे कितना वक़्त लगता है, फिर नीचे की list में दस गुना ज़्यादा items जोड़ दीजिए। अगर page अब दस गुना धीमा है, तो आपके पास एक N+1 है। अगर वो बस ज़रा सा धीमा है, तो नहीं है।

समय से पहले optimization के बारे में एक बात

एक जाल जिसमें नए builders फंसते हैं: किसी के app इस्तेमाल करने से पहले ही हर page को तेज़ बनाने की कोशिश करना। मत कीजिए।

Performance वाले काम की एक असली लागत होती है। ऐसी list में pagination जोड़ना जिसमें कभी बीस rows ही होंगी, बर्बाद की गई मेहनत है। ऐसे page को optimize करना जो दिन में दो बार load होता है, बर्बाद की गई मेहनत है। तीन users वाले internal tool के लिए bundles बांटना, बर्बाद की गई मेहनत है। किसी धीमे page को ठीक करने का सही वक़्त वो है जब आप page, action, और उस इंसान का नाम बता सकें जो इससे चिढ़ गया था।

तो पहले इसे सामान्य तरीके से बनाइए। शिप कीजिए। देखिए कि इसका इस्तेमाल कैसे होता है। जब किसी असली इंसान को कुछ धीमा लगे — आपको भी — तो लक्षण को ऊपर की चार श्रेणियों में से एक से मिलाइए और उसी ख़ास उपाय को मांगिए। आपको एक तेज़ app मिलेगी, बिना किसी ऐसे infrastructure पर एक हफ़्ता खपाए जिसे आपके users कभी देखेंगे ही नहीं।

अपने AI builder से speed के बारे में कैसे बात करें

एक तरीका जो काम करता है: उपाय नहीं, लक्षण बताइए। AI आपके अंदाज़े से कहीं बेहतर है सही उपाय चुनने में, बशर्ते उसे पता हो कि असल में ग़लत क्या है।

कॉपी करने लायक अच्छे prompts:

• “जब मैं settings page खोलता हूं, तो कुछ भी दिखने से पहले एक सेकंड की देरी होती है। क्या हम पता लगा सकते हैं कि पहले render को क्या रोक रहा है?”
• “dashboard, home page से ज़्यादा वक़्त load होने में लेता है, जबकि वो कम data दिखाता है। क्या हम देख सकते हैं कि वो अपना data कैसे ला रहा है?”
• “जब मैं profile page पर ‘save changes’ क्लिक करता हूं, तो दो सेकंड तक कुछ नहीं होता। एक loading state जोड़ो और पक्का करो कि बटन को दो बार क्लिक न किया जा सके।”
• “इस list को 500 नकली items के साथ test करो और मुझे बताओ कि धीमापन कहां है।”

आख़िरी वाले को कम आंका जाता है। AI से test data जनरेट करवाना और उससे ख़ुद page आज़मवाना उन सबसे काम की चीज़ों में से एक है जो आप कर सकते हैं। वो अक्सर आपके users से पहले धीमी जगहें ढूंढ लेगा — और उसी जवाब में उपाय भी सुझाएगा।

AI से बनी apps में speed किसी जादू के बारे में नहीं है। यह जानने के बारे में है कि आपकी समस्या चार में से किस ख़ाने में आती है, और साफ़ शब्दों में सही उपाय मांगने के बारे में। यह कीजिए, और “धीमी लगती है” चंद छोटे, सटीक बदलावों के साथ “ठीक लगती है” बन जाता है — किसी नए सिरे से लिखने के बिना।