100k पंक्तियों वाली तेज़ डैशबोर्ड सूची: सबसे पहले क्या करें

डेटा बढ़ने पर लिस्ट स्क्रीन धीमी क्यों हो जाती है

एक लिस्ट स्क्रीन आम तौर पर तब तक ठीक लगती है जब तक कि वह अचानक नहीं धीमी पड़ने लगती। यूज़र्स छोटे-छोटे रुकाव महसूस करते हैं: स्क्रोल करते समय स्टटर, हर अपडेट के बाद पेज थोड़ी देर के लिए अटकना, फिल्टर में सेकंड लगना, और हर क्लिक पर स्पिनर दिखना। कभी-कभी ब्राउज़र टैब फ्रीज जैसा लगता है क्योंकि UI थ्रेड व्यस्त है।

100k पंक्तियाँ एक सामान्य टर्निंग प्वाइंट हैं क्योंकि यह सिस्टम के हर हिस्से पर एक साथ दबाव डालती हैं। डेटासेट अभी भी DB के लिए सामान्य है, पर इतना बड़ा कि छोटी कुशलताओं की कमी ब्राउज़र और नेटवर्क पर स्पष्ट हो जाती है। अगर आप सब कुछ एक साथ दिखाने की कोशिश करते हैं तो साधारण स्क्रीन भारी पाइपलाइन बन जाती है।

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

काम को चार हिस्सों में बाँटना मदद करता है:

• नेटवर्क: आप कितने बाइट्स भेजते हैं और कितनी बार।
• डेटाबेस: हर रिक्वेस्ट पर आप कितने डेटा को स्कैन, सॉर्ट और एग्रीगेट करते हैं।
• ब्राउज़र रेंडरिंग: आप कितने DOM नोड्स बनाते, मापते और पेंट करते हैं।
• जावास्क्रिप्ट वर्क: आप कितनी बार री-रेंडर करते, कॉलम री-कैल्क करते या परिणाम फिर से कंप्यूट करते हैं।

यदि इनमें से कोई भी महँगा है, तो पूरी स्क्रीन धीमी लगेगी। एक सरल सर्च बॉक्स ही एक ऐसी रिक्वेस्ट ट्रिगर कर सकता है जो 100k रोज़ सॉर्ट करे, हजारों रिकॉर्ड लौटाये, और फिर ब्राउज़र को सब कुछ रेंडर करना पड़े — और इस तरह टाइपिंग लैग होने लगता है।

टीमें जब तेज़ी से internal tools बनाती हैं (विशेषकर चैट-ड्रिवन प्लेटफ़ॉर्म जैसे Koder.ai के साथ), तो लिस्ट स्क्रीन अक्सर वह जगह होती हैं जहाँ असली डेटा वृद्धि "डेमो-डेटासेट पर चलता है" और "हर दिन इंस्टेंट लगता है" के बीच की खाई दिखाती है।

सही प्रदर्शन लक्ष्य चुनें

ऑप्टिमाइज़ करने से पहले तय करें कि इस स्क्रीन के लिए तेज़ी का क्या मतलब है। कई टीमें थ्रूपुट (सब कुछ लोड करना) के पीछे भागती हैं जबकि उपयोगकर्ता ज्यादातर लो लेटेंसी (जल्दी अपडेट दिखना) चाहते हैं। एक लिस्ट तब भी इंस्टेंट महसूस कर सकती है जब वह कभी पूरा 100k नहीं लोड करती, बशर्ते स्क्रोल, सॉर्ट और फिल्टर पर जवाब तेज़ रहे।

व्यवहारिक लक्ष्य "पहली पंक्ति दिखने का समय" रखें, न कि पूरी तरह लोड होने का। जब उपयोगकर्ता जल्दी पहली 20–50 पंक्तियाँ देखते हैं और इंटरैक्शन स्मूद रहते हैं तो पेज पर भरोसा बनता है।

क्या मापें (और क्यों)

हर बार कुछ बदलने पर कुछ छोटे नंबर चुनें जिन्हें आप ट्रैक कर सकें:

• पेज खोलने या फिल्टर बदलने के बाद पहली पंक्ति दिखने तक का समय
• फिल्टर या सॉर्ट के अपडेट दिखने का समय
• रिस्पॉन्स साइज (अनुमानित JSON पेलोड साइज)
• धीमी क्वेरीज़ (खासकर COUNT(*) और चौड़ी SELECTs)
• ब्राउज़र मेन-थ्रेड स्पाइक्स (स्क्रोल स्टटर, टाइपिंग लैग)

ये सामान्य लक्षणों से जुड़ते हैं। अगर स्क्रोल करते समय ब्राउज़र CPU spike करता है तो फ्रंटेंड प्रति-रो बहुत काम कर रहा है। अगर स्पिनर दिखता है पर स्क्रोलिंग ठीक है, तो अक्सर बैकएंड या नेटवर्क समस्या होती है। रिक्वेस्ट तेज़ है पर पेज फ्रीज़ होता है तो आमतौर पर रेंडरिंग या भारी क्लाइंट-साइड प्रोसेसिंग जिम्मेदार होती है।

फ़्रंटेंड बनाम बैकएंड का एक तेज़ परीक्षण

एक सरल प्रयोग करें: UI को वही रखें, पर अस्थायी रूप से बैकएंड को वही फिल्टर वापिस करते हुए केवल 20 पंक्तियाँ लौटाने के लिए सीमित कर दें। अगर यह तेज़ हो जाता है, तो बॉटलनेक लोड साइज या क्वेरी समय है। अगर अभी भी धीमा है, तो रेंडरिंग, फॉर्मैटिंग और प्रति-रो कंपोनेंट्स देखें।

उदा.: एक internal Orders स्क्रीन टाइप करते समय धीमी लगती है। अगर API 5,000 रोज़ लौटाता है और ब्राउज़र हर कीस्ट्रोक पर उन्हें फ़िल्टर करता है तो टाइपिंग लैग करेगा। अगर API 2 सेकंड लेता है क्योंकि अनइंडेक्स्ड फिल्टर पर COUNT क्वेरी है तो पंक्ति बदलने से पहले आपको इंतज़ार दिखेगा। अलग-अलग ठीक करने के तरीके, एक ही यूज़र शिकायत।

फ्रंटेंड बेसिक्स: रेंडरिंग सस्ता रखें

ब्राउज़र अक्सर पहली बॉटलनेक होता है। API तेज़ होने पर भी पेज धीमा महसूस हो सकता है क्योंकि पेज बहुत कुछ पेंट करने की कोशिश कर रहा होता है। पहली नियम सरल है: एक साथ हज़ारों रोज़ DOM में न रेंडर करें।

पूर्ण वर्चुअलाइज़ेशन जोड़ने से पहले भी हर रो को हल्का रखें। नेस्टेड रैपर्स, आइकन, टूलटिप्स और हर सेल में जटिल कंडीशनल स्टाइल्स वाली पंक्ति हर स्क्रोल और हर अपडेट पर महँगी पड़ती है। सरल टेक्स्ट, कुछ छोटे बैज और प्रति-रो एक-दो इंटरैक्टिव एलिमेंट रखें।

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

फॉर्मैटिंग भी एक चुप्पी कर देती है। तिथियाँ, मुद्रा और भारी स्ट्रिंग वर्क कई कोशिकाओं में बार-बार होने पर जोड़ जाते हैं।

एक सरल नियम

यदि कोई मान दिखाई नहीं दे रहा है तो उसे अभी कंप्यूट न करें। महँगे फॉर्मैटिंग परिणामों को कैश करें और मांग पर ही कंप्यूट करें — उदाहरण के लिए जब रो दिखाई दे या उपयोगकर्ता रो खोलता है।

एक तेज़ पास जो अक्सर बड़ा सुधार देता है:

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

उदा.: एक internal Invoices टेबल जो 12 कॉलम में मुद्रा और तिथियाँ फॉर्मैट करता है वह स्क्रोल पर स्टटर करेगा। प्रत्येक चालान के लिए फॉर्मैटेड वैल्यूज़ कैश करना और ऑफ-स्क्रीन रोज़ के लिए काम को देरी से करना इसे लगभग इंस्टेंट बना सकता है, बैकएंड सुधारों से पहले भी।

वर्चुअलाइज़ेशन: 100k रोज़ को स्मूद कैसे स्क्रोल करें

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

वर्चुअलाइज़ेशन उन लंबी सूचियों, चौड़ी तालिकाओं, या भारी रोज़ (अवतार, स्टेटस चिप्स, एक्शन मेनू, टूलटिप्स) के लिए अच्छा है। जब उपयोगकर्ता बहुत स्क्रोल करते हैं और निरंतर व्यू की उम्मीद करते हैं तो यह उपयोगी है।

वर्चुअलाइज़ेशन कहाँ मुश्किल हो जाता है

यह जादू नहीं है। कुछ चीजें अक्सर सरप्राइज़ देती हैं:

• वैरिएबल रो हाइट (लैपिंग टेक्स्ट, एक्सपैंडेबल रोज़) स्मूद स्क्रोल को तोड़ सकते हैं जब तक आप ऊँचाइयों को माप न लें या रोज़ की साइज को सुसंगत न रखें।
• स्टिकी हेडर और स्टिकी कॉलम वर्चुअलाइज़्ड कंटेनर के साथ कॉन्फ्लिक्ट कर सकते हैं अगर लेआउट जटिल CSS पर निर्भर हो।
• कीबोर्ड नेविगेशन (अप/डाउन, पेज अप/डाउन, सेल्स में फोकस) को अतिरिक्त देखभाल की ज़रूरत होती है ताकि फोकस अनमाउंटेड रोज़ पर कूद न जाए।
• बल्क एक्शन्स के लिए स्पष्ट नियम चाहिए: दिख रही रोज़ का चयन करें, फिल्टर के पार चयन करें, या पूरे डेटासेट में चयन करें?

सबसे सरल तरीका उबाऊ है: फिक्स्ड रो हाइट, अनुमानित कॉलम, और प्रति-रो बहुत अधिक इंटरैक्टिव विजेट न रखें।

वर्चुअलाइज़ेशन और पेजिनेशन (यूज़र को भ्रमित किए बिना)

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

एक व्यवहारिक पैटर्न है कि आप सामान्य पेज साइज फेच करें (अक्सर 100–500 रोज़), उस पेज के भीतर वर्चुअलाइज़ करें, और पेजों के बीच जाने के स्पष्ट नियंत्रण दें। अगर आप इन्फिनिट स्क्रोल उपयोग करते हैं तो एक दृश्यमान "Loaded X of Y" संकेत जोड़ें ताकि उपयोगकर्ता समझ सकें वे अभी सब कुछ नहीं देख रहे।

तेज़ बने रहने के लिए पेजिनेशन विकल्प

यदि आपको ऐसी लिस्ट स्क्रीन चाहिए जो डेटा बढ़ने पर भी उपयोगी रहे, तो पेजिनेशन आमतौर पर सबसे सुरक्षित डिफ़ॉल्ट है। यह अनुमानित है, एडमिन वर्कफ़्लो के लिए अच्छा काम करता है (रिव्यू, संपादित, अप्रूव), और आम जरूरतों का समर्थन करता है जैसे "इन फिल्टर के साथ पेज 3 एक्सपोर्ट करें" बिना सरप्राइज़ के। कई टीमें फancier स्क्रोलिंग आज़माने के बाद फिर पेजिनेशन पर लौट आती हैं।

इन्फिनिट स्क्रोल कैज़ुअल ब्राउज़िंग के लिए अच्छा लग सकता है, पर इसके छिपे हुए खर्च होते हैं। लोग अपनी जगह खो देते हैं, बैक बटन अक्सर उन्हें उसी स्पॉट पर नहीं लाता, और लंबे सेशन में अधिक रोज़ लोड होने से मेमोरी बढ़ सकती है। एक मिडल ग्राउंड है Load more बटन जो अभी भी पेजेस का उपयोग करता है ताकि उपयोगकर्ता ओरिएंटेड रहें।

ऑफ़सेट बनाम कीसेट पेजिनेशन

ऑफ़सेट पेजिनेशन क्लासिक page=10&size=50 तरीका है। सरल है, पर बड़े टेबल्स पर धीमा हो सकता है क्योंकि डेटाबेस को बाद के पेज तक पहुँचने के लिए कई रोज़ स्किप करने पड़ सकते हैं। साथ ही नए रोज़ के आने पर आइटम पेजों के बीच शिफ्ट कर सकते हैं।

कीसेट पेजिनेशन (अकसर कर्सर पेजिनेशन कहा जाता है) "अंतिम देखी गई आइटम के बाद के अगले 50 रोज़" माँगता है, आमतौर पर id या created_at का उपयोग करके। यह अक्सर तेज़ रहता है क्योंकि इसमें बहुत स्किप करने का काम नहीं होता।

एक व्यवहारिक नियम:

• छोटे लिस्ट्स, स्थिर डेटासेट और जब आपको किसी सटीक पेज नंबर पर जाना हो तो ऑफ़सेट का उपयोग करें।
• बहुत बड़े लिस्ट्स, बार-बार inserts, और Next/Previous नेविगेशन के लिए keyset का उपयोग करें।

हर बार कीमत चुकाए बिना टोटल दिखाना

यूज़र्स टोटल देखना पसंद करते हैं, पर "मैचिंग रोज़ की पूरी गिनती" भारी फिल्टर के साथ महँगी हो सकती है। विकल्पों में शामिल हैं: लोकप्रिय फिल्टर्स के लिए काउंट कैश करना, पेज लोड होने के बाद बैकग्राउंड में काउंट अपडेट करना, या अनुमानित काउंट दिखाना (उदा. "10,000+")।

उदा.: एक internal Orders स्क्रीन keyset पेजिनेशन से तुरंत परिणाम दिखा सकती है, फिर उपयोगकर्ता जब फिल्टर बदलना बंद करे तो सही कुल का मान भर दे।

अगर आप Koder.ai में बना रहे हैं, तो पेजिनेशन और काउंट व्यवहार को स्क्रीन स्पेसिफ़िकेशन का हिस्सा जल्दी रखें ताकि जनरेटेड बैकएंड क्वेरीज़ और UI स्टेट बाद में एक-दूसरे से टकराएँ नहीं।

ऐसा फिल्टर और सर्च जो इंस्टेंट लगे

अधिकांश लिस्ट स्क्रीन इसलिए धीमी लगती हैं क्योंकि वे बेहद खुली रहती हैं: सब कुछ लोड करें, फिर उपयोगकर्ता को संकुचित करने के लिए कहें। इसे उल्टा करें। उपयोगी डिफ़ॉल्ट्स के साथ शुरू करें जो छोटी, उपयोगी सेट लौटाते हैं (उदा.: Last 7 days, My items, Status: Open), और All time को एक स्पष्ट विकल्प बनाएं।

टेक्स्ट सर्च एक और सामान्य जाल है। अगर आप हर कीस्ट्रोक पर क्वेरी चलाते हैं तो रिक्वेस्ट्स की बैकलॉग बनती है और UI झिलमिलाने लगता है। सर्च इनपुट को डिबाउंस करें ताकि आप केवल तब क्वेरी करें जब उपयोगकर्ता थोड़ी देर रुका हो, और नई रिक्वेस्ट आने पर पुरानी रिक्वेस्ट रद्द करें। सरल नियम: अगर उपयोगकर्ता अभी टाइप कर रहा है तो सर्वर को तब तक मत हिट करें।

फ़िल्टर तभी तेज़ महसूस करते हैं जब वे स्पष्ट भी हों। टेबल के ऊपर फिल्टर चिप्स दिखाएँ ताकि उपयोगकर्ता देख सकें क्या सक्रिय है और एक क्लिक में निकाल सकें। चिप लेबल्स मानव-रीडबल रखें, कच्चे फ़ील्ड नाम नहीं (उदा. Owner: Sam बजाय owner_id=42)। जब कोई कहता है "मेरे परिणाम गायब हो गए," तो आमतौर पर इसका कारण एक अदृश्य फ़िल्टर होता है।

बड़े लिस्ट्स को उत्तरदायी रखने वाले पैटर्न बिना UI जटिल किए:

• डिफ़ॉल्ट रूप से संकुचित फ़िल्टर और छोटा तारीख़ रेंज रखें
• टेक्स्ट सर्च को डिबाउंस करें और इन-फ्लाइट रिक्वेस्ट रद्द करें
• फिल्टर चिप्स और Clear all कार्रवाई दिखाएँ
• सामान्य जॉब्स के लिए सहेजे गए व्यूज़ ऑफ़र करें
• महँगे फिल्टर्स को तब तक गेट करें जब तक कम से कम एक संकुचित फ़िल्टर सेट न हो

सहेजे गए व्यूज़ शांत हीरो होते हैं। हर बार उपयोगकर्ता को परफेक्ट एक-ऑफ़ फिल्टर बनाने की बजाय, उन्हें कुछ प्रीसेट दें जो असल वर्कफ़्लो से मेल खाते हों। एक ऑप्स टीम शायद Failed payments today और High-value customers के बीच स्विच करेगी — ये एक क्लिक से समझ में आ जाते हैं और बैकएंड पर तेज रखने में आसान रहते हैं।

अगर आप Koder.ai जैसे चैट-ड्रिवन बिल्डर में internal टूल बना रहे हैं, तो फिल्टर्स को प्रोडक्ट फ़्लो का हिस्सा मानें, न कि बाद में जोड़ा गया। सबसे सामान्य सवालों से शुरू करें, फिर डिफ़ॉल्ट व्यू और सहेजे गए व्यूज़ उन पर डिज़ाइन करें।

क्वेरी शेपिंग: कम मांगें, कम कंप्यूट करें

लिस्ट स्क्रीन अक्सर डिटेल पेज जैसा डेटा नहीं चाहती। अगर आपका API हर चीज़ वापस करता है तो आप दो बार भुगतान करते हैं: डेटाबेस अधिक काम करता है और ब्राउज़र को अनावश्यक चीज़ें रिसीव और रेंडर करनी पड़ती हैं। क्वेरी शेपिंग उस आदत का नाम है जिसमें आप केवल वही मांगते हैं जो लिस्ट को अभी चाहिए।

शुरुआत में केवल उन कॉलम्स को लौटाएँ जो हर रो रेंडर करने के लिए चाहिए। अधिकांश डैशबोर्ड्स के लिए वह id, कुछ लेबल, एक स्टेटस, एक ओनर और टाइमस्टैम्प्स होते हैं। बड़ा टेक्स्ट, JSON ब्लॉब और कम्प्यूटेड फ़ील्ड तब तक रुक सकते हैं जब उपयोगकर्ता रो खोलता है।

पहली पेंट के लिए भारी जॉइन से बचें। जॉइन ठीक हैं जब वे इंडेक्स पर हिट करते हैं और छोटे परिणाम लौटाते हैं, पर जब आप कई तालिकाओं को जॉइन करते हैं और फिर जॉइन किए गए डेटा पर सॉर्ट या फ़िल्टर करते हैं तो वे महँगे हो जाते हैं। सरल पैटर्न: सूची को एक टेबल से तेज़ी से फ़ेच करें, फिर संबंधित विवरण ऑन-डिमांड लोड करें (या केवल दिखाई देने वाली रोज़ के लिए बैच-लोड़)।

सॉर्ट विकल्प सीमित रखें और इंडेक्स्ड कॉलम पर सॉर्ट होने दें। "किसी भी चीज़ से सॉर्ट" उपयोगी लग सकता है पर अक्सर बड़े डेटासेट पर धीमी सॉर्ट्स को मजबूर कर देता है। कुछ पूर्वानुमेय विकल्प जैसे created_at, updated_at, या status रखें और सुनिश्चित करें कि वे कॉलम इंडेक्स्ड हों।

सावधान रहें सर्वर-साइड एग्रीगेशन के साथ। बड़े फ़िल्टर्ड सेट पर COUNT(*), चौड़े कॉलम पर DISTINCT, या टोटल पेजेज़ की गणना आपके रिस्पॉन्स समय को हावी कर सकती है।

व्यवहारिक तरीका:

• लिस्ट रिस्पॉन्स को 5–10 फ़ील्ड तक आकार दें
• रो विवरण केवल तब फ़ेच करें जब रो खोली जाए
• 2–4 सॉर्ट विकल्प दें, सभी इंडेक्स द्वारा समर्थित
• COUNT और DISTINCT को वैकल्पिक समझें; जहां संभव हो कैश या अनुमान लगाएँ

अगर आप Koder.ai पर internal tools बना रहे हैं, तो planning मोड में हल्की लिस्ट क्वेरी को डिटेल क्वेरी से अलग परिभाषित करें ताकि UI डेटा बढ़ने पर भी तेज़ रहे।

बड़ी तालिकाओं के लिए डेटाबेस टैक्टिक्स

यदि आप ऐसी लिस्ट स्क्रीन चाहते हैं जो 100k रोज़ पर भी तेज़ रहे, तो डेटाबेस को हर रिक्वेस्ट पर कम काम करना होगा। अधिकांश स्लो लिस्ट "बहुत डेटा" नहीं हैं; वे गलत डेटा एक्सेस पैटर्न हैं।

शुरुआत उन इंडेक्स से करें जो आपके उपयोगकर्ता असल में उपयोग करते हैं। अगर आपकी लिस्ट सामान्यतः status से फ़िल्टर और created_at से सॉर्ट होती है तो आप ऐसा इंडेक्स चाहते हैं जो दोनों को सहारा दे। अन्यथा डेटाबेस अपेक्षित से कहीं अधिक रोज़ स्कैन कर सकता है और फिर उन्हें सॉर्ट कर सकता है, जो तेजी से महँगा हो जाता है।

अक्सर सबसे बड़े लाभ देने वाले फिक्स:

• सामान्य फ़िल्टर + सॉर्ट को मिरर करने वाले कंपोजिट इंडेक्स जोड़ें (उदा. tenant_id, status, created_at).
• गहरी OFFSET पेजों के बजाय keyset (cursor) पेजिनेशन पसंद करें। OFFSET DB से कई रोज़ स्किप करवा देता है।
• कुल गिनती को वैकल्पिक समझें। सटीक टोटल बड़े फ़िल्टर्ड सेट पर धीमा हो सकता है। गिनती को कैश करें, प्रीकम्प्यूट करें, या "10,000+" जैसा दिखाएँ।
• रोज़ को पतला रखें। लिस्ट के लिए बड़े टेक्स्ट फ़ील्ड, JSON ब्लॉब या नेस्टेड ऑब्जेक्ट्स को सेलेक्ट न करें।
• क्वेरीज़ को आकार दें ताकि केवल वही लौटे जो UI रेंडर करता है: कुछ कॉलम और नेक्स्ट-पेज कर्सर।

सरल उदाहरण: एक internal Orders टेबल जो ग्राहक नाम, स्टेटस, राशि और तारीख दिखाती है। लिस्ट व्यू के लिए हर संबंधित तालिका नहीं जॉइन करें और पूरे ऑर्डर नोट्स को न खींचें। केवल टेबल में उपयोग होने वाले कॉलम वापस करें और बाकी को उपयोगकर्ता के क्लिक पर अलग रिक्वेस्ट से लोड करें।

अगर आप Koder.ai जैसे प्लेटफ़ॉर्म से बना रहे हैं, तब भी यह मानसिकता रखें भले ही UI चैट से जनरेट हो। सुनिश्चित करें कि जनरेटेड API endpoints कर्सर पेजिनेशन और चयनात्मक फ़ील्ड्स को सपोर्ट करें ताकि डेटाबेस वर्क डेटा बढ़ने पर भी पूर्वानुमेय रहे।

मौजूदा लिस्ट स्क्रीन तेज़ करने के लिए चरण-दर-चरण योजना

यदि आज लिस्ट पेज धीमा लग रहा है, तो सब कुछ री-राइट करके शुरू न करें। पहले सामान्य उपयोग का मार्ग लॉक करें, फिर उसी पथ को ऑप्टिमाइज़ करें।

एक व्यवहारिक पाँच-चरण योजना

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

2. ऐसा पेजिंग स्टाइल चुनें जो आपकी उपयोगिता से मेल खाता हो। अगर उपयोगकर्ता आम तौर पर पहले कुछ पेज्स देखते हैं तो क्लासिक पेजिनेशन ठीक है। अगर लोग गहराई में कूदते हैं (पेज 200+) या आपको हर दूरी पर स्थिर प्रदर्शन चाहिए तो keyset पेजिनेशन चुनें (एक स्थिर सॉर्ट जैसे created_at + id पर आधारित)।

3. टेबल बॉडी के लिए वर्चुअलाइज़ेशन जोड़ें। भले ही बैकएंड तेज़ हो, ब्राउज़र तब भी कई रोज़ रेंडर करने में फंस सकता है।

4. सर्च और फिल्टर्स को इंस्टेंट महसूस कराएँ। टाइपिंग को डिबाउंस करें ताकि हर कीस्ट्रोक पर रिक्वेस्ट न जाये। फिल्टर स्टेट को URL या एक साझा स्टेट स्टोर में रखें ताकि रिफ्रेश, बैक बटन और व्यू शेयरिंग भरोसेमंद काम करें। अंतिम सफल परिणाम को कैश करें ताकि टेबल खाली न झलके।

5. मापें, फिर क्वेरीज़ और इंडेक्स ट्यून करें। सर्वर टाइम, DB टाइम, पेलोड साइज और रेंडर टाइम लॉग करें। फिर क्वेरी ट्रिम करें: केवल वही कॉलम सेलेक्ट करें जो आप दिखाते हैं, फ़िल्टर जल्दी लागू करें, और अपने डिफ़ॉल्ट फ़िल्टर + सॉर्ट के अनुरूप इंडेक्स जोड़ें।

उदा.: एक internal support डैशबोर्ड जिसमें 100k टिकट्स हों। डिफ़ॉल्ट करें Open, मेरी टीम को असाइन, नवीनतम के अनुसार सॉर्ट, छह कॉलम दिखाएँ, और केवल ticket id, subject, assignee, status, और timestamps फेच करें। keyset पेजिनेशन और वर्चुअलाइज़ेशन के साथ आप DB और UI दोनों को पूर्वानुमेय रख सकते हैं।

अगर आप Koder.ai में बना रहे हैं, यह योजना iterate-and-check वर्कफ़्लो के अनुकूल है: व्यू समायोजित करें, स्क्रोल और सर्च टेस्ट करें, फिर क्वेरी ट्यून करें जब तक पेज स्नैपी न रहे।

लिस्ट्स को रेंगने पर मजबूर करने वाली आम गलतियाँ

सबसे तेज़ तरीका जिससे लिस्ट स्क्रीन टूट जाती है वह है 100k रोज़ को सामान्य पेज डेटा की तरह मानना। ज्यादातर धीमे डैशबोर्ड्स में कुछ अनुमानित फँसे हुए ट्रैप होते हैं।

एक बड़ा ट्रैप है सब कुछ रेंडर करना और CSS से उसे छुपा देना। भले ही दिखने वाली मात्र 50 रोज़ हों, ब्राउज़र 100k DOM नोड्स बनाकर, उन्हें मापकर और स्क्रोल पर repaint करके भुगतान कर चुका होता है। लंबे सूचियों के लिए केवल वही रेंडर करें जो उपयोगकर्ता देख सकता है (वर्चुअलाइज़ेशन) और रो कंपोनेंट्स को सरल रखें।

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

एक और आम समस्या है पूर्ण रिकॉर्ड फेच करना जबकि लिस्ट केवल सार चाहिए। एक लिस्ट रो आमतौर पर 5–12 फ़ील्ड चाहता है, न कि पूरा ऑब्जेक्ट, न ही लंबे विवरण और न ही संबंधित डेटा। अतिरिक्त डेटा खींचने से DB वर्क, नेटवर्क समय और फ्रंटेंड पार्सिंग सब बढ़ जाते हैं।

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

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

त्वरित गट-चेक:

• अगर आप अनंत तक स्क्रोल कर सकते हैं बिना लोड किए, तो आप शायद बहुत ज्यादा रेंडर कर रहे हैं।
• अगर सर्च में टाइपिंग लैग है, तो आपकी क्वेरी स्कैन कर रही होगी।
• अगर लिस्ट API बड़ा JSON लौटाती है तो आप ओवरफेच कर रहे हैं।
• अगर एक्सपोर्ट पेज हैंग करता है तो काम गलत जगह हो रहा है।
• अगर हर सॉर्ट धीमा है तो इंडेक्सिंग और सॉर्ट विकल्पों की ज़रूरत है।

त्वरित चेकलिस्ट और अगले कदम

लिस्ट प्रदर्शन को एक प्रोडक्ट फीचर की तरह ट्रीट करें, न कि एक बार की ट्यूनिंग। एक लिस्ट स्क्रीन तभी तेज़ है जब वास्तविक लोग असली डेटा पर स्क्रोल, फिल्टर और सॉर्ट करें और उसे तेज़ महसूस करें।

इस चेकलिस्ट का प्रयोग यह सुनिश्चित करने के लिए करें कि आपने सही चीज़ें ठीक कीं:

• पहली पेंट तेज़ है: पेज छोटा पेलोड लोड करता है और पहली पंक्तियाँ तुरंत दिखती हैं।
• स्क्रोल स्मूद रहता है: वर्चुअलाइज़ेशन ऑन है, ब्राउज़र CPU spike नहीं कर रहा, और रो हाइट पूर्वानुमेय है।
• फिल्टर्स उत्तरदायी हैं: टाइपिंग या चयन पर परिणाम जल्दी अपडेट होते हैं, और फिल्टर्स पेजिनेशन या रिफ्रेश पर रिसेट नहीं होते।
• सॉर्टिंग समझदारी से है: केवल इंडेक्स्ड या प्रीकम्प्यूटेड फील्ड्स पर सॉर्ट की अनुमति है और पेजों में सॉर्ट ऑर्डर सुसंगत है।
• रिक्वेस्ट्स आकारित हैं: API केवल वे कॉलम लौटाता है जो आप दिखाते हैं, साथ में स्थिर IDs और कर्सर, पूरी ऑब्जेक्ट्स नहीं।

एक साधारण रियलिटी चेक: लिस्ट खोलें, 10 सेकंड तक स्क्रोल करें, फिर एक सामान्य फिल्टर लागू करें (जैसे Status: Open)। अगर UI फ्रीज़ हो जाये तो समस्या अक्सर रेंडरिंग (बहुत सारे DOM रोज़) या किसी भारी क्लाइंट-साइड ट्रांसफ़ॉर्म (सॉर्टिंग, ग्रूपिंग, फॉर्मैटिंग) की वजह से होती है जो हर अपडेट पर हो रहा है।

अगले कदम, क्रम में ताकि आप फिक्सेस के बीच उछलें नहीं:

1. एक यूज़र फ्लो को एंड-टू-एंड मापें (लोड, स्क्रोल, फिल्टर, सॉर्ट) और लक्ष्य समय लिखें।
2. वर्चुअलाइज़ेशन चालू करें और कोशिकाओं में महंगी फॉर्मैटिंग को सीमित करें (तिथियाँ, मुद्रा, अवतार)।
3. फ़िल्टरिंग और सॉर्टिंग को सर्वर पर ले जाएँ, और विकल्पों को तेज़ रखा जा सके ऐसी सीमाएँ लगाएँ।
4. अपनी क्वेरीज़ और पेलोड्स को कड़ा करें, फिर फिर से मापें।

अगर आप यह Koder.ai (koder.ai) के साथ बनाते हैं, तो Planning Mode से शुरू करें: सटीक लिस्ट कॉलम, फिल्टर फ़ील्ड और API रिस्पॉन्स शेप पहले परिभाषित करें। फिर स्नैपशॉट और रोलबैक के साथ इटरेट करें जब कोई एक्सपेरिमेंट स्क्रीन धीमी कर दे।