27 नव॰ 2025·8 मिनट
100k पंक्तियों वाली तेज़ डैशबोर्ड सूची: सबसे पहले क्या करें
पेजिनेशन, वर्चुअलाइज़ेशन, स्मार्ट फिल्टर और बेहतर क्वेरियों का उपयोग कर 100k पंक्तियों वाली डैशबोर्ड सूचियों को तेज़ बनाने के तरीके सीखें ताकि internal tools त्वरित रहें।
पेजिनेशन, वर्चुअलाइज़ेशन, स्मार्ट फिल्टर और बेहतर क्वेरियों का उपयोग कर 100k पंक्तियों वाली डैशबोर्ड सूचियों को तेज़ बनाने के तरीके सीखें ताकि internal tools त्वरित रहें।
एक लिस्ट स्क्रीन आम तौर पर तब तक ठीक लगती है जब तक कि वह अचानक नहीं धीमी पड़ने लगती। यूज़र्स छोटे-छोटे रुकाव महसूस करते हैं: स्क्रोल करते समय स्टटर, हर अपडेट के बाद पेज थोड़ी देर के लिए अटकना, फिल्टर में सेकंड लगना, और हर क्लिक पर स्पिनर दिखना। कभी-कभी ब्राउज़र टैब फ्रीज जैसा लगता है क्योंकि UI थ्रेड व्यस्त है।
100k पंक्तियाँ एक सामान्य टर्निंग प्वाइंट हैं क्योंकि यह सिस्टम के हर हिस्से पर एक साथ दबाव डालती हैं। डेटासेट अभी भी DB के लिए सामान्य है, पर इतना बड़ा कि छोटी कुशलताओं की कमी ब्राउज़र और नेटवर्क पर स्पष्ट हो जाती है। अगर आप सब कुछ एक साथ दिखाने की कोशिश करते हैं तो साधारण स्क्रीन भारी पाइपलाइन बन जाती है।
लक्ष्य सभी रोज़ रेंडर करना नहीं है। लक्ष्य किसी को जल्दी से जो चाहिए वह ढूँढने में मदद करना है: सही 50 रोज़, अगला पेज, या फिल्टर के आधार पर एक संकरी सिलाइस।
काम को चार हिस्सों में बाँटना मदद करता है:
यदि इनमें से कोई भी महँगा है, तो पूरी स्क्रीन धीमी लगेगी। एक सरल सर्च बॉक्स ही एक ऐसी रिक्वेस्ट ट्रिगर कर सकता है जो 100k रोज़ सॉर्ट करे, हजारों रिकॉर्ड लौटाये, और फिर ब्राउज़र को सब कुछ रेंडर करना पड़े — और इस तरह टाइपिंग लैग होने लगता है।
टीमें जब तेज़ी से internal tools बनाती हैं (विशेषकर चैट-ड्रिवन प्लेटफ़ॉर्म जैसे Koder.ai के साथ), तो लिस्ट स्क्रीन अक्सर वह जगह होती हैं जहाँ असली डेटा वृद्धि "डेमो-डेटासेट पर चलता है" और "हर दिन इंस्टेंट लगता है" के बीच की खाई दिखाती है।
ऑप्टिमाइज़ करने से पहले तय करें कि इस स्क्रीन के लिए तेज़ी का क्या मतलब है। कई टीमें थ्रूपुट (सब कुछ लोड करना) के पीछे भागती हैं जबकि उपयोगकर्ता ज्यादातर लो लेटेंसी (जल्दी अपडेट दिखना) चाहते हैं। एक लिस्ट तब भी इंस्टेंट महसूस कर सकती है जब वह कभी पूरा 100k नहीं लोड करती, बशर्ते स्क्रोल, सॉर्ट और फिल्टर पर जवाब तेज़ रहे।
व्यवहारिक लक्ष्य "पहली पंक्ति दिखने का समय" रखें, न कि पूरी तरह लोड होने का। जब उपयोगकर्ता जल्दी पहली 20–50 पंक्तियाँ देखते हैं और इंटरैक्शन स्मूद रहते हैं तो पेज पर भरोसा बनता है।
हर बार कुछ बदलने पर कुछ छोटे नंबर चुनें जिन्हें आप ट्रैक कर सकें:
COUNT(*) और चौड़ी SELECTs)ये सामान्य लक्षणों से जुड़ते हैं। अगर स्क्रोल करते समय ब्राउज़र CPU spike करता है तो फ्रंटेंड प्रति-रो बहुत काम कर रहा है। अगर स्पिनर दिखता है पर स्क्रोलिंग ठीक है, तो अक्सर बैकएंड या नेटवर्क समस्या होती है। रिक्वेस्ट तेज़ है पर पेज फ्रीज़ होता है तो आमतौर पर रेंडरिंग या भारी क्लाइंट-साइड प्रोसेसिंग जिम्मेदार होती है।
एक सरल प्रयोग करें: UI को वही रखें, पर अस्थायी रूप से बैकएंड को वही फिल्टर वापिस करते हुए केवल 20 पंक्तियाँ लौटाने के लिए सीमित कर दें। अगर यह तेज़ हो जाता है, तो बॉटलनेक लोड साइज या क्वेरी समय है। अगर अभी भी धीमा है, तो रेंडरिंग, फॉर्मैटिंग और प्रति-रो कंपोनेंट्स देखें।
उदा.: एक internal Orders स्क्रीन टाइप करते समय धीमी लगती है। अगर API 5,000 रोज़ लौटाता है और ब्राउज़र हर कीस्ट्रोक पर उन्हें फ़िल्टर करता है तो टाइपिंग लैग करेगा। अगर API 2 सेकंड लेता है क्योंकि अनइंडेक्स्ड फिल्टर पर COUNT क्वेरी है तो पंक्ति बदलने से पहले आपको इंतज़ार दिखेगा। अलग-अलग ठीक करने के तरीके, एक ही यूज़र शिकायत।
ब्राउज़र अक्सर पहली बॉटलनेक होता है। API तेज़ होने पर भी पेज धीमा महसूस हो सकता है क्योंकि पेज बहुत कुछ पेंट करने की कोशिश कर रहा होता है। पहली नियम सरल है: एक साथ हज़ारों रोज़ DOM में न रेंडर करें।
पूर्ण वर्चुअलाइज़ेशन जोड़ने से पहले भी हर रो को हल्का रखें। नेस्टेड रैपर्स, आइकन, टूलटिप्स और हर सेल में जटिल कंडीशनल स्टाइल्स वाली पंक्ति हर स्क्रोल और हर अपडेट पर महँगी पड़ती है। सरल टेक्स्ट, कुछ छोटे बैज और प्रति-रो एक-दो इंटरैक्टिव एलिमेंट रखें।
स्थिर रो हाइट जितना छोटा फायदा देती है उतना ही रखिये। जब हर रो की ऊँचाई समान होती है तो ब्राउज़र लेआउट का अनुमान लगा सकता है और स्क्रोल स्मूद रहता है। वैरिएबल-हाइट रोज़ (लैपिंग विवरण, एक्सपैंडेबल नोट्स, बड़े अवतार) अतिरिक्त माप और रिफ्लो ट्रिगर करते हैं। अगर अधिक विवरण चाहिए तो साइड पैनल या एक एक्सपैंडेबल एरिया पर विचार करें, न कि पूरी मल्टी-लाइन रो।
फॉर्मैटिंग भी एक चुप्पी कर देती है। तिथियाँ, मुद्रा और भारी स्ट्रिंग वर्क कई कोशिकाओं में बार-बार होने पर जोड़ जाते हैं।
यदि कोई मान दिखाई नहीं दे रहा है तो उसे अभी कंप्यूट न करें। महँगे फॉर्मैटिंग परिणामों को कैश करें और मांग पर ही कंप्यूट करें — उदाहरण के लिए जब रो दिखाई दे या उपयोगकर्ता रो खोलता है।
एक तेज़ पास जो अक्सर बड़ा सुधार देता है:
उदा.: एक internal Invoices टेबल जो 12 कॉलम में मुद्रा और तिथियाँ फॉर्मैट करता है वह स्क्रोल पर स्टटर करेगा। प्रत्येक चालान के लिए फॉर्मैटेड वैल्यूज़ कैश करना और ऑफ-स्क्रीन रोज़ के लिए काम को देरी से करना इसे लगभग इंस्टेंट बना सकता है, बैकएंड सुधारों से पहले भी।
वर्चुअलाइज़ेशन का मतलब है कि टेबल केवल उन रोज़ को ड्रॉ करता है जो वास्तव में दिख रहे हैं (और ऊपर/नीचे एक छोटा बफ़र)। जैसे-जैसे आप स्क्रोल करते हैं, वही DOM एलिमेंट्स री-यूज़ होते हैं और उनके अंदर का डेटा बदल जाता है। इससे ब्राउज़र को दसियों हजार रोज़ एक साथ पेंट करने नहीं पड़ते।
वर्चुअलाइज़ेशन उन लंबी सूचियों, चौड़ी तालिकाओं, या भारी रोज़ (अवतार, स्टेटस चिप्स, एक्शन मेनू, टूलटिप्स) के लिए अच्छा है। जब उपयोगकर्ता बहुत स्क्रोल करते हैं और निरंतर व्यू की उम्मीद करते हैं तो यह उपयोगी है।
यह जादू नहीं है। कुछ चीजें अक्सर सरप्राइज़ देती हैं:
सबसे सरल तरीका उबाऊ है: फिक्स्ड रो हाइट, अनुमानित कॉलम, और प्रति-रो बहुत अधिक इंटरैक्टिव विजेट न रखें।
आप दोनों मिला सकते हैं: सर्वर से लाने के लिए पेजिनेशन (या कर्सर-आधारित लोड मोर) का उपयोग करें ताकि आप जो फेच करते हैं उसे सीमित रखें, और फेच किए हुए स्लाइस के अंदर रेंडरिंग सस्ती रखने के लिए वर्चुअलाइज़ेशन करें।
एक व्यवहारिक पैटर्न है कि आप सामान्य पेज साइज फेच करें (अक्सर 100–500 रोज़), उस पेज के भीतर वर्चुअलाइज़ करें, और पेजों के बीच जाने के स्पष्ट नियंत्रण दें। अगर आप इन्फिनिट स्क्रोल उपयोग करते हैं तो एक दृश्यमान "Loaded X of Y" संकेत जोड़ें ताकि उपयोगकर्ता समझ सकें वे अभी सब कुछ नहीं देख रहे।
यदि आपको ऐसी लिस्ट स्क्रीन चाहिए जो डेटा बढ़ने पर भी उपयोगी रहे, तो पेजिनेशन आमतौर पर सबसे सुरक्षित डिफ़ॉल्ट है। यह अनुमानित है, एडमिन वर्कफ़्लो के लिए अच्छा काम करता है (रिव्यू, संपादित, अप्रूव), और आम जरूरतों का समर्थन करता है जैसे "इन फिल्टर के साथ पेज 3 एक्सपोर्ट करें" बिना सरप्राइज़ के। कई टीमें फancier स्क्रोलिंग आज़माने के बाद फिर पेजिनेशन पर लौट आती हैं।
इन्फिनिट स्क्रोल कैज़ुअल ब्राउज़िंग के लिए अच्छा लग सकता है, पर इसके छिपे हुए खर्च होते हैं। लोग अपनी जगह खो देते हैं, बैक बटन अक्सर उन्हें उसी स्पॉट पर नहीं लाता, और लंबे सेशन में अधिक रोज़ लोड होने से मेमोरी बढ़ सकती है। एक मिडल ग्राउंड है Load more बटन जो अभी भी पेजेस का उपयोग करता है ताकि उपयोगकर्ता ओरिएंटेड रहें।
ऑफ़सेट पेजिनेशन क्लासिक page=10&size=50 तरीका है। सरल है, पर बड़े टेबल्स पर धीमा हो सकता है क्योंकि डेटाबेस को बाद के पेज तक पहुँचने के लिए कई रोज़ स्किप करने पड़ सकते हैं। साथ ही नए रोज़ के आने पर आइटम पेजों के बीच शिफ्ट कर सकते हैं।
कीसेट पेजिनेशन (अकसर कर्सर पेजिनेशन कहा जाता है) "अंतिम देखी गई आइटम के बाद के अगले 50 रोज़" माँगता है, आमतौर पर id या created_at का उपयोग करके। यह अक्सर तेज़ रहता है क्योंकि इसमें बहुत स्किप करने का काम नहीं होता।
एक व्यवहारिक नियम:
यूज़र्स टोटल देखना पसंद करते हैं, पर "मैचिंग रोज़ की पूरी गिनती" भारी फिल्टर के साथ महँगी हो सकती है। विकल्पों में शामिल हैं: लोकप्रिय फिल्टर्स के लिए काउंट कैश करना, पेज लोड होने के बाद बैकग्राउंड में काउंट अपडेट करना, या अनुमानित काउंट दिखाना (उदा. "10,000+")।
उदा.: एक internal Orders स्क्रीन keyset पेजिनेशन से तुरंत परिणाम दिखा सकती है, फिर उपयोगकर्ता जब फिल्टर बदलना बंद करे तो सही कुल का मान भर दे।
अगर आप Koder.ai में बना रहे हैं, तो पेजिनेशन और काउंट व्यवहार को स्क्रीन स्पेसिफ़िकेशन का हिस्सा जल्दी रखें ताकि जनरेटेड बैकएंड क्वेरीज़ और UI स्टेट बाद में एक-दूसरे से टकराएँ नहीं।
अधिकांश लिस्ट स्क्रीन इसलिए धीमी लगती हैं क्योंकि वे बेहद खुली रहती हैं: सब कुछ लोड करें, फिर उपयोगकर्ता को संकुचित करने के लिए कहें। इसे उल्टा करें। उपयोगी डिफ़ॉल्ट्स के साथ शुरू करें जो छोटी, उपयोगी सेट लौटाते हैं (उदा.: Last 7 days, My items, Status: Open), और All time को एक स्पष्ट विकल्प बनाएं।
टेक्स्ट सर्च एक और सामान्य जाल है। अगर आप हर कीस्ट्रोक पर क्वेरी चलाते हैं तो रिक्वेस्ट्स की बैकलॉग बनती है और UI झिलमिलाने लगता है। सर्च इनपुट को डिबाउंस करें ताकि आप केवल तब क्वेरी करें जब उपयोगकर्ता थोड़ी देर रुका हो, और नई रिक्वेस्ट आने पर पुरानी रिक्वेस्ट रद्द करें। सरल नियम: अगर उपयोगकर्ता अभी टाइप कर रहा है तो सर्वर को तब तक मत हिट करें।
फ़िल्टर तभी तेज़ महसूस करते हैं जब वे स्पष्ट भी हों। टेबल के ऊपर फिल्टर चिप्स दिखाएँ ताकि उपयोगकर्ता देख सकें क्या सक्रिय है और एक क्लिक में निकाल सकें। चिप लेबल्स मानव-रीडबल रखें, कच्चे फ़ील्ड नाम नहीं (उदा. Owner: Sam बजाय owner_id=42)। जब कोई कहता है "मेरे परिणाम गायब हो गए," तो आमतौर पर इसका कारण एक अदृश्य फ़िल्टर होता है।
बड़े लिस्ट्स को उत्तरदायी रखने वाले पैटर्न बिना UI जटिल किए:
सहेजे गए व्यूज़ शांत हीरो होते हैं। हर बार उपयोगकर्ता को परफेक्ट एक-ऑफ़ फिल्टर बनाने की बजाय, उन्हें कुछ प्रीसेट दें जो असल वर्कफ़्लो से मेल खाते हों। एक ऑप्स टीम शायद Failed payments today और High-value customers के बीच स्विच करेगी — ये एक क्लिक से समझ में आ जाते हैं और बैकएंड पर तेज रखने में आसान रहते हैं।
अगर आप Koder.ai जैसे चैट-ड्रिवन बिल्डर में internal टूल बना रहे हैं, तो फिल्टर्स को प्रोडक्ट फ़्लो का हिस्सा मानें, न कि बाद में जोड़ा गया। सबसे सामान्य सवालों से शुरू करें, फिर डिफ़ॉल्ट व्यू और सहेजे गए व्यूज़ उन पर डिज़ाइन करें।
लिस्ट स्क्रीन अक्सर डिटेल पेज जैसा डेटा नहीं चाहती। अगर आपका API हर चीज़ वापस करता है तो आप दो बार भुगतान करते हैं: डेटाबेस अधिक काम करता है और ब्राउज़र को अनावश्यक चीज़ें रिसीव और रेंडर करनी पड़ती हैं। क्वेरी शेपिंग उस आदत का नाम है जिसमें आप केवल वही मांगते हैं जो लिस्ट को अभी चाहिए।
शुरुआत में केवल उन कॉलम्स को लौटाएँ जो हर रो रेंडर करने के लिए चाहिए। अधिकांश डैशबोर्ड्स के लिए वह id, कुछ लेबल, एक स्टेटस, एक ओनर और टाइमस्टैम्प्स होते हैं। बड़ा टेक्स्ट, JSON ब्लॉब और कम्प्यूटेड फ़ील्ड तब तक रुक सकते हैं जब उपयोगकर्ता रो खोलता है।
पहली पेंट के लिए भारी जॉइन से बचें। जॉइन ठीक हैं जब वे इंडेक्स पर हिट करते हैं और छोटे परिणाम लौटाते हैं, पर जब आप कई तालिकाओं को जॉइन करते हैं और फिर जॉइन किए गए डेटा पर सॉर्ट या फ़िल्टर करते हैं तो वे महँगे हो जाते हैं। सरल पैटर्न: सूची को एक टेबल से तेज़ी से फ़ेच करें, फिर संबंधित विवरण ऑन-डिमांड लोड करें (या केवल दिखाई देने वाली रोज़ के लिए बैच-लोड़)।
सॉर्ट विकल्प सीमित रखें और इंडेक्स्ड कॉलम पर सॉर्ट होने दें। "किसी भी चीज़ से सॉर्ट" उपयोगी लग सकता है पर अक्सर बड़े डेटासेट पर धीमी सॉर्ट्स को मजबूर कर देता है। कुछ पूर्वानुमेय विकल्प जैसे created_at, updated_at, या status रखें और सुनिश्चित करें कि वे कॉलम इंडेक्स्ड हों।
सावधान रहें सर्वर-साइड एग्रीगेशन के साथ। बड़े फ़िल्टर्ड सेट पर COUNT(*), चौड़े कॉलम पर DISTINCT, या टोटल पेजेज़ की गणना आपके रिस्पॉन्स समय को हावी कर सकती है।
व्यवहारिक तरीका:
COUNT और DISTINCT को वैकल्पिक समझें; जहां संभव हो कैश या अनुमान लगाएँअगर आप Koder.ai पर internal tools बना रहे हैं, तो planning मोड में हल्की लिस्ट क्वेरी को डिटेल क्वेरी से अलग परिभाषित करें ताकि UI डेटा बढ़ने पर भी तेज़ रहे।
यदि आप ऐसी लिस्ट स्क्रीन चाहते हैं जो 100k रोज़ पर भी तेज़ रहे, तो डेटाबेस को हर रिक्वेस्ट पर कम काम करना होगा। अधिकांश स्लो लिस्ट "बहुत डेटा" नहीं हैं; वे गलत डेटा एक्सेस पैटर्न हैं।
शुरुआत उन इंडेक्स से करें जो आपके उपयोगकर्ता असल में उपयोग करते हैं। अगर आपकी लिस्ट सामान्यतः status से फ़िल्टर और created_at से सॉर्ट होती है तो आप ऐसा इंडेक्स चाहते हैं जो दोनों को सहारा दे। अन्यथा डेटाबेस अपेक्षित से कहीं अधिक रोज़ स्कैन कर सकता है और फिर उन्हें सॉर्ट कर सकता है, जो तेजी से महँगा हो जाता है।
अक्सर सबसे बड़े लाभ देने वाले फिक्स:
tenant_id, status, created_at).OFFSET पेजों के बजाय keyset (cursor) पेजिनेशन पसंद करें। OFFSET DB से कई रोज़ स्किप करवा देता है।सरल उदाहरण: एक internal Orders टेबल जो ग्राहक नाम, स्टेटस, राशि और तारीख दिखाती है। लिस्ट व्यू के लिए हर संबंधित तालिका नहीं जॉइन करें और पूरे ऑर्डर नोट्स को न खींचें। केवल टेबल में उपयोग होने वाले कॉलम वापस करें और बाकी को उपयोगकर्ता के क्लिक पर अलग रिक्वेस्ट से लोड करें।
अगर आप Koder.ai जैसे प्लेटफ़ॉर्म से बना रहे हैं, तब भी यह मानसिकता रखें भले ही UI चैट से जनरेट हो। सुनिश्चित करें कि जनरेटेड API endpoints कर्सर पेजिनेशन और चयनात्मक फ़ील्ड्स को सपोर्ट करें ताकि डेटाबेस वर्क डेटा बढ़ने पर भी पूर्वानुमेय रहे।
यदि आज लिस्ट पेज धीमा लग रहा है, तो सब कुछ री-राइट करके शुरू न करें। पहले सामान्य उपयोग का मार्ग लॉक करें, फिर उसी पथ को ऑप्टिमाइज़ करें।
डिफ़ाइन करें डिफ़ॉल्ट व्यू। डिफ़ॉल्ट फिल्टर, सॉर्ट ऑर्डर और दिखाई देने वाले कॉलम चुनें। लिस्ट तब धीमी होती है जब वे डिफ़ॉल्ट रूप से सब कुछ दिखाने की कोशिश करती हैं।
ऐसा पेजिंग स्टाइल चुनें जो आपकी उपयोगिता से मेल खाता हो। अगर उपयोगकर्ता आम तौर पर पहले कुछ पेज्स देखते हैं तो क्लासिक पेजिनेशन ठीक है। अगर लोग गहराई में कूदते हैं (पेज 200+) या आपको हर दूरी पर स्थिर प्रदर्शन चाहिए तो keyset पेजिनेशन चुनें (एक स्थिर सॉर्ट जैसे created_at + id पर आधारित)।
टेबल बॉडी के लिए वर्चुअलाइज़ेशन जोड़ें। भले ही बैकएंड तेज़ हो, ब्राउज़र तब भी कई रोज़ रेंडर करने में फंस सकता है।
सर्च और फिल्टर्स को इंस्टेंट महसूस कराएँ। टाइपिंग को डिबाउंस करें ताकि हर कीस्ट्रोक पर रिक्वेस्ट न जाये। फिल्टर स्टेट को URL या एक साझा स्टेट स्टोर में रखें ताकि रिफ्रेश, बैक बटन और व्यू शेयरिंग भरोसेमंद काम करें। अंतिम सफल परिणाम को कैश करें ताकि टेबल खाली न झलके।
मापें, फिर क्वेरीज़ और इंडेक्स ट्यून करें। सर्वर टाइम, 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 को धीमे प्लान पर मजबूर करने लगते हैं। सॉर्ट्स को सीमित और इंडेक्स्ड कॉलम पर रखें और डिफ़ॉल्ट सॉर्ट को असल इंडेक्स से मिलाएँ।
त्वरित गट-चेक:
लिस्ट प्रदर्शन को एक प्रोडक्ट फीचर की तरह ट्रीट करें, न कि एक बार की ट्यूनिंग। एक लिस्ट स्क्रीन तभी तेज़ है जब वास्तविक लोग असली डेटा पर स्क्रोल, फिल्टर और सॉर्ट करें और उसे तेज़ महसूस करें।
इस चेकलिस्ट का प्रयोग यह सुनिश्चित करने के लिए करें कि आपने सही चीज़ें ठीक कीं:
एक साधारण रियलिटी चेक: लिस्ट खोलें, 10 सेकंड तक स्क्रोल करें, फिर एक सामान्य फिल्टर लागू करें (जैसे Status: Open)। अगर UI फ्रीज़ हो जाये तो समस्या अक्सर रेंडरिंग (बहुत सारे DOM रोज़) या किसी भारी क्लाइंट-साइड ट्रांसफ़ॉर्म (सॉर्टिंग, ग्रूपिंग, फॉर्मैटिंग) की वजह से होती है जो हर अपडेट पर हो रहा है।
अगले कदम, क्रम में ताकि आप फिक्सेस के बीच उछलें नहीं:
अगर आप यह Koder.ai (koder.ai) के साथ बनाते हैं, तो Planning Mode से शुरू करें: सटीक लिस्ट कॉलम, फिल्टर फ़ील्ड और API रिस्पॉन्स शेप पहले परिभाषित करें। फिर स्नैपशॉट और रोलबैक के साथ इटरेट करें जब कोई एक्सपेरिमेंट स्क्रीन धीमी कर दे।
पहले लक्ष्य को “सब कुछ लोड करना” से बदलकर “पहली उपयोगी पंक्तियाँ जल्दी दिखाना” कर दें। समय का लक्ष्य पहली पंक्ति दिखने तक रखें और सुनिश्चित करें कि फिल्टर, सॉर्ट और स्क्रोलिंग स्मूद हों, भले ही पूरा डेटासेट कभी एक साथ लोड न हो।
नापें: पेज या फिल्टर बदलने पर पहली पंक्ति दिखने तक का समय, फिल्टर/सॉर्ट अपडेट का समय, रिस्पॉन्स पेलोड साइज, धीमी डेटाबेस क्वेरीज़ (खासकर चौड़ी SELECTs और COUNT(*)), और ब्राउज़र मेन-थ्रेड स्पाइक्स। ये मीट्रिक्स यूज़र के अनुभव से सीधे जुड़ते हैं।
API को अस्थायी रूप से केवल 20 पंक्तियाँ लौटने के लिए सीमित करें (उसी फिल्टर और सॉर्ट के साथ)। अगर तेज़ हो जाए तो बॉटलनेक लोड साइज या क्वेरी समय है; अगर अभी भी धीमा रहे तो रेंडरिंग, फॉर्मेटिंग या प्रति-रो क्लाइंट वर्क की जाँच करें।
हज़ारों रोज़ DOM में न माउंट करें, रो कम्पोनेंट्स को सिंपल रखें, और फिक्स्ड रो हाइट पसंद करें। ऑफ-स्क्रीन रोज़ के लिए महंगी फॉर्मैटिंग बाद में या ऑन-डिमांड करें और कैश करें। इन बदलावों से स्क्रोल और इंटरैक्शन पर बड़ा फर्क पड़ता है।
वर्चुअलाइज़ेशन केवल उन रोज़ को रेंडर करता है जो दिख रहे हैं (साथ में छोटा बफ़र)। यह तब अच्छा है जब यूज़र बहुत स्क्रोल करते हैं या रो भारी होते हैं। ध्यान दें कि वेरियेबल रो हाइट, स्टिकी हेडर/कॉलम, और कीबोर्ड नेविगेशन अतिरिक्त काम लाते हैं।
प्रशासनिक वर्कफ़्लो के लिए पेजिनेशन अक्सर सबसे सुरक्षित डिफ़ॉल्ट है क्योंकि यह यूज़र को स्थिति बताता है और सर्वर वर्क को सीमित करता है। इन्फिनिट स्क्रोल कैज़ुअल ब्राउज़िंग के लिए ठीक हो सकता है, पर नेविगेशन और मेमोरी पर दुष्प्रभाव कर सकता है।
ऑफ़सेट (उदा. page=10&size=50) सरल है पर बड़े टेबल्स पर धीमा हो सकता है क्योंकि DB बहुत सारी पंक्तियाँ स्किप कर सकता है। कर्सर (keyset) पेजिनेशन अगले रिकॉर्ड के बाद के 50 रोज़ मांगता है और आमतौर पर हमेशा तेज़ रहता है।
हर कीस्ट्रोक पर सर्वर को मत बताइए। इनपुट को डिबाउंस करें, इन-फ्लाइट रिक्वेस्ट रद्द करें जब नया रिक्वेस्ट आए, और डिफ़ॉल्ट रूप से संकीर्ण फिल्टर (जैसे हाल के 7 दिन, My items) रखें ताकि पहली क्वेरी छोटी और उपयोगी हो।
लिस्ट के लिए केवल वही फ़ील्ड लौटाएँ जो पंक्ति रेंडर के लिए आवश्यक हों — सामान्यतः id, label, status, owner, timestamps। बड़े टेक्स्ट, JSON ब्लॉब और अधिक संबंधी डेटा को डिटेल रिक्वेस्ट पर छोड़ दें ताकि पहली पेंट हल्की रहे।
डिफ़ॉल्ट फ़िल्टर और सॉर्ट के अनुसार इंडेक्स बनाएं — अक्सर एक कंपोजिट इंडेक्स जो फ़िल्टर + सॉर्ट क्रम को सपोर्ट करे (उदा. tenant_id, status, created_at)। सटीक टोटल को वैकल्पिक समझें: कैश करें, प्रीकम्प्यूट करें, या अपेक्षित रूप में दिखाएँ (उदा. "10,000+")।