14 अग॰ 2025·8 मिनट
वेब प्रदर्शन पर कंपाइलर दृष्टिकोण: Rich Harris की राय
कम्पाइलर-फर्स्ट विचारों पर व्यावहारिक दृष्टि: रनटाइम-भारी फ्रेमवर्क्स और कम्पाइल-टाइम आउटपुट के बीच तुलना, और एक सरल निर्णय ढाँचा जो टीमों को तेज़ी से आगे बढ़ने में मदद करे।
कम्पाइलर-फर्स्ट विचारों पर व्यावहारिक दृष्टि: रनटाइम-भारी फ्रेमवर्क्स और कम्पाइल-टाइम आउटपुट के बीच तुलना, और एक सरल निर्णय ढाँचा जो टीमों को तेज़ी से आगे बढ़ने में मदद करे।
उपयोगकर्ता आमतौर पर प्रदर्शन को तकनीकी शब्दों में नहीं बताते। वे कहते हैं कि ऐप भारी महसूस होता है। पेज कुछ देर के लिए कुछ भी नहीं दिखाते, बटन देर से रिस्पॉन्ड करते हैं, और साधारण क्रियाएँ जैसे मेन्यू खोलना, सर्च बॉक्स में टाइप करना या टैब बदलना फिरकी लेती हैं।
लक्षण परिचित हैं: धीमा पहला लोड (खाली या आधा बना UI), लेग्गी इंटरैक्शन (क्लिक्स जो थोड़ी देर बाद लगते हैं, जिटरिंग स्क्रॉलिंग), और उन क्रियाओं के बाद लंबे स्पिनर जो तुरन्त महसूस होने चाहिए थे, जैसे फॉर्म सेव करना या सूची फ़िल्टर करना।
इनमें से कई समस्याएँ रनटाइम लागत की वजह से होती हैं। सीधे शब्दों में, यह वह काम है जो पेज लोड होने के बाद ब्राउज़र को ऐप को उपयोगी बनाने के लिए करना पड़ता है: और JavaScript डाउनलोड करना, उसे पार्स और चलाना, UI बनाना, हैंडलर अटैच करना, और हर अपडेट पर अतिरिक्त काम करना। तेज़ डिवाइसेज़ पर भी, ब्राउज़र में कितना JavaScript आप भेज सकते हैं इसकी एक सीमा है—उससे अधिक होने पर एक्सपीरियंस स्लो हो जाता है।
परफॉर्मेंस की समस्याएँ अक्सर बाद में दिखती हैं। शुरू में ऐप छोटा होता है: कुछ स्क्रीन, हल्का डेटा, सरल UI। फिर प्रोडक्ट बढ़ता है। मार्केटिंग ट्रैकर्स जोड़ती है, डिज़ाइन रिचर कंपोनेंट्स जोड़ता है, टीमें स्टेट, फीचर, डिपेंडेंसी और पर्सनलाइज़ेशन जोड़ती हैं। हर बदलाव खुद में अनहेल्फुल लग सकता है, लेकिन कुल काम जमा हो जाता है।
इसीलिए टीमें कंपाइलर-फर्स्ट परफॉर्मेंस विचारों पर ध्यान देना शुरू करती हैं। उद्देश्य आम तौर पर परफेक्ट स्कोर नहीं होता। बल्कि यह है कि बिना ऐप हर महीने धीमा हुए लगातार शिप करते रहें।
अधिकांश फ्रंटएंड फ्रेमवर्क आपको दो काम करने में मदद करते हैं: ऐप बनाना, और UI को डेटा के साथ सिंक में रखना। मुख्य अंतर यह है कि दूसरा भाग कब होता है।
रनटाइम-हेवी फ्रेमवर्क में, अधिक काम पेज लोड के बाद ब्राउज़र में होता है। आप एक जनरल-परपज़ रनटाइम भेजते हैं जो कई मामलों को हैंडल कर सके: चेंजेज ट्रैक करना, क्या अपडेट होना चाहिए तय करना, और उन अपडेट्स को लागू करना। यह लचीलापन विकास के लिए अच्छा हो सकता है, पर अक्सर इसका मतलब है कि UI तैयार होने से पहले अधिक JavaScript डाउनलोड, पार्स और एग्जीक्यूट करना पड़ता है।
कम्पाइल-टाइम ऑप्टिमाइज़ेशन के साथ, वह काम बिल्ड स्टेप में शिफ्ट हो जाता है। बड़े सेट ऑफ़ नियम भेजने के बजाय, बिल्ड-टूल आपके कंपोनेंट्स का विश्लेषण करता है और ज्यादा डायरेक्ट, ऐप-विशिष्ट कोड जेनरेट करता है।
एक उपयोगी माइंड-मॉडल:
अधिकांश असली प्रोडक्ट्स बीच में कहीं होते हैं। कंपाइलर-फर्स्ट अप्रोच अभी भी कुछ रनटाइम कोड भेजती है (रूटिंग, डेटा फ़ेचिंग, एनिमेशन, एरर हैंडलिंग)। रनटाइम-हेवी फ्रेमवर्क भी क्लाइंट वर्क कम करने के लिए बिल्ड-टाइम तकनीकों पर निर्भर होते हैं (मिनिफिकेशन, कोड-स्प्लिटिंग, सर्वर रेंडरिंग)। व्यावहारिक सवाल यह नहीं है कि कौन सा कैंप "सही" है, बल्कि कौन सा मिश्रण आपके प्रोडक्ट के अनुरूप है।
Rich Harris कम्पाइलर-फर्स्ट फ्रंटएंड सोच के सबसे स्पष्ट वॉइस में से हैं। उनका तर्क सरल है: अधिक काम पहले कर लें ताकि उपयोगकर्ताओं को कम कोड डाउनलोड करना पड़े और ब्राउज़र को कम काम करना पड़े।
प्रेरणा व्यावहारिक है। कई रनटाइम-हेवी फ्रेमवर्क एक जनरल-परपज़ इंजन भेजते हैं: कंपोनेंट लॉजिक, रिएक्टिविटी, डिफ्फ़िंग, शेड्यूलिंग और हेल्पर्स जो हर संभावित ऐप के लिए काम करने चाहिए। वह लचीलापन बाइट्स और CPU की लागत आता है। यहां तक कि जब आपका UI छोटा होता है, तब भी आप बड़े रनटाइम के लिए भुगतान कर सकते हैं।
कम्पाइलर अप्रोच मॉडल को उलट देता है। बिल्ड टाइम के दौरान, कंपाइलर आपके वास्तविक कंपोनेंट्स को देखता है और उनके लिए आवश्यक विशिष्ट DOM अपडेट कोड जेनरेट करता है। अगर कोई लेबल कभी बदलता ही नहीं, तो वह साधारण HTML बन जाता है। अगर सिर्फ़ एक वैल्यू बदलती है, तो केवल उसी वैल्यू के अपडेट पाथ को एमीट किया जाता है। जनरल UI मशीन भेजने की बजाय, आप अपने प्रोडक्ट के लिए टेलर्ड आउटपुट भेजते हैं।
आम तौर पर इसका सरल परिणाम मिलता है: उपयोगकर्ताओं को कम फ्रेमवर्क कोड भेजा जाता है, और हर इंटरैक्शन पर कम काम होता है। यह फर्क खासकर लो-एंड डिवाइसेज़ पर जल्दी दिखाई देता है, जहाँ अतिरिक्त रनटाइम ओवरहेड तुरंत दिखायी देता है।
ट्रेडऑफ अभी भी मायने रखते हैं:
एक व्यावहारिक नियम: अगर आपका UI ज्यादातर बिल्ड टाइम पर ज्ञात है, तो एक कंपाइलर तंग आउटपुट जेनरेट कर सकता है। अगर आपका UI अत्यधिक डायनामिक या प्लगइन-आधारित है, तो एक भारी रनटाइम आसान हो सकता है।
कम्पाइल-टाइम ऑप्टिमाइज़ेशन यह बदल देता है कि काम कहाँ होता है। बिल्ड के दौरान अधिक निर्णय लिए जाते हैं और ब्राउज़र के लिए कम काम बचता है।
एक दिखाई देने वाला नतीजा कम JavaScript शिप होना है। छोटे बंडल नेटवर्क समय, पार्सिंग समय और उस देरी को घटाते हैं जब तक पेज टैप या क्लिक पर रिस्पॉन्ड कर सके। मिड-रेंज फ़ोनों पर यह कई टीमों की अपेक्षा से अधिक मायने रखता है।
कम्पाइलर अधिक डायरेक्ट DOM अपडेट भी जेनरेट कर सकता है। जब बिल्ड स्टेप किसी कंपोनेंट की संरचना देख सकता है, तो वह ऐसा अपडेट कोड बना सकता है जो केवल उन्हीं DOM नोड्स को छूता है जो वास्तव में बदलते हैं, हर इंटरैक्शन पर कई परतों के बजाय। यह अक्सर लिस्ट्स, टेबल्स और फॉर्म्स में बार-बार होने वाले अपडेट्स को तेज़ महसूस करवा सकता है।
बिल्ड-टाइम एनालिसिस ट्री-शेकिंग और डेड-कोड रिमूवल को भी मजबूत कर सकती है। इसका भुगतान केवल छोटे फाइल नहीं है—यह ब्राउज़र को कम कोड पथ लोड और एग्जीक्यूट करने देता है।
हाइड्रेशन भी एक ऐसा क्षेत्र है जहाँ बिल्ड-टाइम विकल्प मदद कर सकते हैं। हाइड्रेशन वह स्टेप है जहाँ सर्वर-रेंडर की हुई पेज इंटरैक्टिव बनती है—इवेंट हैंडलर अटैच करना और ब्राउज़र में पर्याप्त स्टेट फिर से बनाना। अगर बिल्ड बता सके कि किस हिस्से को इंटरैक्टिव होना है और किसे नहीं, तो आप फर्स्ट-लोड काम घटा सकते हैं।
साइड-इफेक्ट के रूप में, कम्पाइलेशन अक्सर CSS स्कोपिंग में भी सुधार लाती है। बिल्ड क्लास नेम री-राइट कर सकता है, अनयूज़्ड स्टाइल्स हटा सकता है, और क्रॉस-कॉम्पोनेंट स्टाइल लीक को घटा सकता है। इससे UI के बढ़ने पर आश्चर्यजनक लागतें कम होती हैं।
एक डैशबोर्ड की कल्पना करें जिसमें फ़िल्टर्स और बड़ी डेटा टेबल है। एक कंपाइलर-फर्स्ट अप्रोच प्रारम्भिक लोड को हल्का रख सकती है, फ़िल्टर क्लिक के बाद केवल उन सेल्स को अपडेट कर सकती है जो बदले, और उन पेज हिस्सों को हाइड्रेट करने से बच सकती है जो कभी इंटरैक्टिव नहीं बनते।
एक बड़ा रनटाइम अपने आप में खराब नहीं है। यह अक्सर लचीलापन खरीदता है: रनटाइम में निर्णय लेने वाले पैटर्न, बहुत सारे थर्ड-पार्टी कंपोनेंट्स, और वर्षों में परखा हुआ वर्कफ़्लो।
रनटाइम-हेवी फ्रेमवर्क तब चमकते हैं जब UI नियम अक्सर बदलते हों। अगर आपको जटिल रूटिंग, नेस्टेड लेआउट, रिच फॉर्म्स और गहरा स्टेट मॉडल चाहिए, तो एक परिपक्व रनटाइम सुरक्षा जाल जैसा महसूस हो सकता है।
रनटाइम मदद करता है जब आप चाहते हैं कि फ्रेमवर्क रनटाइम के दौरान बहुत कुछ हैंडल करे, सिर्फ बिल्ड के दौरान नहीं। इससे टीमें दिन-प्रतिदिन तेज़ी से काम कर सकती हैं, भले ही यह ओवरहेड बढ़ा दे।
सामान्य जितने फ़ायदे हैं: बड़ा इकोसिस्टम, स्टेट व डेटा फ़ेचिंग के परिचित पैटर्न, मजबूत डेवलपर टूल्स, आसान प्लगइन-शैली विस्तार, और हायरिंग के समय स्मूद ऑनबोर्डिंग।
टीम की परिचितता एक वास्तविक लागत और लाभ दोनों है। एक थोड़ा धीमा फ्रेमवर्क जिसे आपकी टीम आत्मविश्वास से शिप कर सकती है, उस तेज़ तरीक़े से बेहतर हो सकता है जो रूटीन बदलने, कड़ी अनुशासन या कस्टम टूलिंग की मांग करता हो।
कई "धीरे ऐप" की शिकायतें फ्रेमवर्क रनटाइम की वजह से नहीं होतीं। अगर आपका पेज धीमे API, भारी इमेजेस, बहुत सारे फ़ॉन्ट्स, या थर्ड-पार्टी स्क्रिप्ट्स का इंतजार कर रहा है, तो फ्रेमवर्क बदलने से मूल समस्या नहीं सुधरेगी।
एक आंतरिक एडमिन डैशबोर्ड, जो लॉगिन के पीछे है, अक्सर बड़े रनटाइम के साथ भी ठीक-ठीक महसूस होता है, क्योंकि उपयोगकर्ता मजबूत डिवाइसेज़ पर होते हैं और काम बैकएंड क्वेरीज व टेबल्स से नियंत्रित होता है।
शुरूआत में "पर्याप्त तेज़" सही लक्ष्य हो सकता है। अगर आप अभी भी प्रोडक्ट वैल्यू सिद्ध कर रहे हैं, तो इटरेशन स्पीड बनाए रखें, बुनियादी बजट सेट करें, और तभी कंपाइलर-फर्स्ट जटिलता अपनाएँ जब आपके पास प्रमाण हो कि यह मायने रखता है।
इटरेशन स्पीड समय-से-फीडबैक है: कोई स्क्रीन बदलकर, उसे चलाकर, टूट-फूट देखकर और ठीक करने में कितना जल्दी सक्षम है। जो टीमें इस लूप को छोटा रखती हैं वे अधिक बार शिप करती हैं और तेज़ी से सीखती हैं। इसलिए रनटाइम-हेवी फ्रेमवर्क शुरुआती चरण में उत्पादक लग सकते हैं: परिचित पैटर्न, तेज़ नतीजे, और built-in व्यवहार।
जब परफॉर्मेंस का काम बहुत जल्दी या बहुत व्यापक तरीके से किया जाता है तो वह उस लूप को धीमा कर देता है। अगर हर PR माइक्रो-ऑप्टिमाइज़ेशन बहस बन जाए, तो टीम रिस्क लेना बंद कर देती है। अगर आप प्रोडक्ट जानते बिना जटिल पाइपलाइन बना लेते हैं, लोग टूलिंग पर लड़ते रहेंगे बजाय उपयोगकर्ताओं से बात किए।
चाल यह है कि यह तय करें कि "पर्याप्त अच्छा" क्या है और उसी बॉक्स के अंदर इटरेट करें। एक परफॉर्मेंस बजट आपको वह बॉक्स देता है। यह परफेक्ट स्कोर का पीछा नहीं है—यह ऐसी सीमाएँ हैं जो एक्सपीरियंस की रक्षा करती हैं और साथ ही डेवलपमेंट को चलते रहने देती हैं।
एक व्यावहारिक बजट में शामिल हो सकता है:
अगर आप परफॉर्मेंस की अनदेखी करते हैं तो आमतौर पर बाद में कीमत चुकानी पड़ती है। एक बार प्रोडक्ट बढ़ गया, तो सुस्ती आर्किटेक्चर फैसलों से जुड़ जाती है, सिर्फ़ छोटी ट्यूनिंग से नहीं। बाद में री-राइट का मतलब फीचर्स फ्रीज़ करना, टीम का री-ट्रेन करना, और कामकाज तोड़ना हो सकता है।
कम्पाइलर-फर्स्ट टूलिंग इस ट्रेडऑफ़ को बदल सकती है। आप शायद थोड़ी लंबी बिल्ड स्वीकार कर लें, पर हर डिवाइस और प्रत्येक विज़िट पर किए जाने वाले काम को कम कर दें।
बजट को प्रोडक्ट के प्रमाण मिलने पर फिर से देखें। शुरू में, बुनियादी चीजों की रक्षा करें। जैसे-जैसे ट्रैफ़िक और राजस्व बढ़े, बजट कड़ा करें और उन जगहों में निवेश करें जहाँ बदलाव असली मेट्रिक्स पर असर डालते हों, न कि सिर्फ़ आत्मसंतुष्टि पर।
परफॉर्मेंस बहस तब गड़बड़ हो जाती है जब कोई यह तय नहीं करता कि "तेज़" का मतलब क्या है। कुछ छोटे मैट्रिक्स चुनें, उन्हें लिखें, और साझा स्कोरबोर्ड की तरह रखें।
एक सरल स्टार्टर्स सेट:
प्रतिनिधि डिवाइसेज़ पर मापें, केवल डेवलपमेंट लैपटॉप पर नहीं। तेज़ CPU, वार्म कैश और लोकल सर्वर वे देरी छुपा सकते हैं जो मिड-रेंज फोन और सामान्य मोबाइल डेटा पर दिखती हैं।
इसे यथार्थ पर रखें: दो या तीन डिवाइसेज़ चुनें जो असली उपयोगकर्ताओं से मेल खाते हों और हर बार एक ही फ्लो चलाएँ (होम स्क्रीन, लॉगिन, एक सामान्य टास्क)। लगातार वही करें।
फ्रेमवर्क बदलने से पहले एक बेसलाइन पकड़ें। आज के बिल्ड का नंबर रिकॉर्ड करें और उन्हीं फ्लोज़ के खिलाफ मापें—यह आपका "पहले" फोटो होगा।
एक सिंगल लैब स्कोर से परफॉर्मेंस को जज न करें। लैब टूल मदद करते हैं, पर वे गलत चीज़ों को पुरस्कृत कर सकते हैं (उत्कृष्ट पहला लोड) जबकि उपयोगकर्ताओं की शिकायतों (जंकी मेन्यू, धीमा टाइपिंग, पहले स्क्रीन के बाद की देरी) को मिस कर देते हैं।
जब नंबर बिगड़ें, अनुमान न लगाएँ। जो शिप हुआ उसे चेक करें, क्या रेंडरिंग ब्लॉक कर रहा था, और समय कहाँ गया: नेटवर्क, JavaScript, या API।
फ्रेमवर्क और रेंडरिंग निर्णयों को शांति से, दोहराने योग्य तरीके से लेने के लिए उन्हें प्रोडक्ट निर्णय की तरह ट्रीट करें। लक्ष्य सर्वश्रेष्ठ तकनीक नहीं है—यह प्रदर्शन और आपकी टीम की ज़रूरत वाली गति के बीच सही संतुलन है।
एक थिन-स्लाइस में गंदगी भी शामिल होनी चाहिए: असली डेटा, ऑथ, और आपका सबसे धीमा स्क्रीन।
यदि आप उस थिन-स्लाइस का जल्दी प्रोटोटाइप बनाना चाहते हैं, तो Koder.ai (koder.ai) आपको चैट के ज़रिये वेब, बैकएंड और मोबाइल ऐप फ्लोज़ बनाने और स्रोत कोड एक्सपोर्ट करने देता है। यह आपको असली रूट जल्दी टेस्ट करने में मदद कर सकता है और एक्सपेरिमेंट्स को स्नैपशॉट/रोलबैक के साथ रिवर्सिबल रखता है।
निर्णय को सादा भाषा में डॉक्युमेंट करें, साथ में यह भी कि किस परिस्थिति में आप इसे फिर से देखने का विचार करेंगे (ट्रैफ़िक बढ़ना, मोबाइल शेयर, SEO लक्ष्य)। इससे टीम बदलने पर भी निर्णय टिकाऊ रहता है।
टीमें तब गलत कर देती हैं जब वे आज जो देख सकती हैं वही ऑप्टिमाइज़ करती हैं, न कि तीन महीने में उपयोगकर्ता क्या महसूस करेंगे।
एक गलती है पहले सप्ताह में ओवर-ऑप्टिमाइज़ करना। टीम ऐसी पेज की मिलीसेकंड्स बचाने में दिन बिता देती है जो अभी भी रोज़ बदल रहा है, जबकि असली समस्या यह है कि उपयोगकर्ताओं के पास सही फीचर ही नहीं है। शुरू में सीखने को तेज़ करें। गहराई से परफॉर्मेंस काम तब करें जब रूट्स और कंपोनेंट्स स्थिर हों।
एक और गलती बंडल ग्रोथ की अनदेखी करना होता है। 200 KB पर सब ठीक लगता है, फिर कुछ "छोटी" ऐडिशन्स के बाद आप मेगाबाइट्स भेज रहे होते हैं। एक साधारण आदत मदद करती है: समय के साथ बंडल साइज ट्रैक करें और अचानक उछालों को बग समझें।
टीमें क्लाइंट-ओनली रेंडरिंग को हर जगह डिफ़ॉल्ट कर देती हैं, भले कुछ रूट्स ज्यादातर स्टैटिक हों (प्राइसिंग पेजेस, डॉक-शैली कंटेंट, ऑनबोर्डिंग)। उन पेजेज़ को अक्सर डिवाइस पर कम काम करके डिलीवर किया जा सकता है।
एक शांत किलर है बिना माप के बड़ी UI लाइब्रेरी जोड़ना केवल सहूलियत के लिए। सहूलियत मान्य है—बस यह स्पष्ट रखें कि आप अतिरिक्त JavaScript, अतिरिक्त CSS, और मिड-रेंज फ़ोनों पर धीमी इंटरैक्शन्स के बदले क्या भुगतान कर रहे हैं।
अंत में, बिना स्पष्ट सीमाओं के अप्रोच मिलाने से डिबग करना कठिन ऐप बनते हैं। अगर ऐप का आधा हिस्सा कंपाइलर-जेनरेटेड अपडेट्स पर निर्भर है और दूसरा हिस्सा रनटाइम जादू पर, तो आपको अस्पष्ट नियम और भ्रमित विफलताएँ मिलेंगी।
कुछ गार्डरेइल्स जो असली टीमों में काम करते हैं:
कल्पना करें एक 3-व्यक्ति टीम SaaS बना रही है जो शेड्यूलिंग और बिलिंग के लिए है। इसके दो मुख हैं: सार्वजनिक मार्केटिंग साइट (लैंडिंग पेज, प्राइसिंग, डॉक्स) और प्रमाणीकृत डैशबोर्ड (कैलेंडर, इनवॉइस, रिपोर्ट्स, सेटिंग्स)।
रनटाइम-फर्स्ट पथ में, वे तेज़ UI बदलावों के कारण रनटाइम-हेवी सेटअप चुनते हैं। डैशबोर्ड एक बड़ा क्लाइंट-साइड ऐप बन जाता है, रीयूज़ेबल कंपोनेंट्स, एक स्टेट लाइब्रेरी, और रिच इंटरैक्शन्स के साथ। इटरेशन तेज़ है। समय के साथ, मिड-रेंज फ़ोनों पर पहला लोड भारी लगने लगता है।
कम्पाइलर-फर्स्ट पथ में, वे ऐसा फ्रेमवर्क चुनते हैं जो बिल्ड टाइम पर अधिक काम भेजे ताकि क्लाइंट JavaScript कम हो। आम फ्लोज जैसे डैशबोर्ड खोलना, टैब बदलना, और सर्च तेज़ महसूस होते हैं। ट्रेडऑफ़ यह है कि टीम को पैटर्न और टूलिंग के बारे में अधिक विचारशील होना पड़ता है, और कुछ आसान रनटाइम ट्रिक्स उतनी सहजता से ड्रॉप-इन नहीं होते।
परिवर्तन का ट्रिगर शायद स्वाद नहीं होता—अक्सर यह वास्तविकता का दबाव होता है: धीमे पेज साइनअप्स को चोट पहुंचाते हैं, ज़्यादा उपयोगकर्ता लो-एंड डिवाइसेज़ पर आते हैं, एंटरप्राइज़ खरीदार पूर्वानुमान योग्य बजट माँगते हैं, या सपोर्ट टिकट असली नेटवर्क्स पर सुस्ती का जिक्र करते हैं।
हाइब्रिड विकल्प अक्सर जीतता है। मार्केटिंग पेजेस को हल्का रखें (सर्वर-रेंडर या ज्यादातर स्टैटिक, कम क्लाइंट कोड) और डैशबोर्ड में अधिक रनटाइम स्वीकार करें जहाँ इंटरएक्टिविटी उसके लिए भुगतान करती है।
निर्णय स्टेप्स का उपयोग करते हुए: वे महत्वपूर्ण यात्राओं का नाम लेते हैं (साइनअप, पहली इनवॉइस, साप्ताहिक रिपोर्टिंग), उन्हें मिड-रेंज फोन पर मापते हैं, बजट सेट करते हैं, और हाइब्रिड चुनते हैं। पब्लिक पेजेस और साझा कंपोनेंट्स के लिए कम्पाइलर-फर्स्ट डिफ़ॉल्ट, और रनटाइम-हेवी केवल वहाँ जहाँ यह स्पष्ट रूप से प्रयोगात्मक गति बढ़ाता है।
इन विचारों को वास्तविक बनाने का सबसे आसान तरीका एक छोटा साप्ताहिक लूप है।
15-मिनट का स्कैन शुरू करें: क्या बंडल साइज ऊपर जा रहा है, कौन से रूट्स धीमे लगते हैं, उन रूट्स पर सबसे बड़े UI पीस कौन से हैं (टेबल्स, चार्ट्स, एडिटर्स), और कौनसी डिपेंडेंसीज़ सबसे ज़्यादा योगदान दे रही हैं। फिर एक ऐसा बॉटलनेक चुनें जिसे आप बिना स्टैक री-राइट किए फिक्स कर सकें।
इस हफ़्ते के लिए छोटा रखें:
फ़ैसलों को reversible रखने के लिए, रूट्स और फीचर्स के बीच स्पष्ट सीमाएँ बनायें। ऐसे मॉड्यूल पसंद करें जिन्हें बाद में बदला जा सके (चार्ट्स, रिच टेक्स्ट एडिटर्स, एनालिटिक्स SDK) बिना पूरे ऐप को छुए।
अधिकतर समय यह केवल नेटवर्क की वजह से नहीं होता—यह रनटाइम लागत है: ब्राउज़र को JavaScript डाउनलोड, पार्स और एग्जीक्यूट करना होता है, UI बनानी होती है, और हर अपडेट पर अतिरिक्त काम करना होता है.
इसलिए जब JavaScript वर्कलोड बड़ा हो जाता है तो ऐप "भारी" महसूस हो सकता है, भले ही आपका लैपटॉप तेज़ हो।
इनका लक्ष्य समान है (क्लाइंट पर कम काम), लेकिन तरीका अलग है.
इसका मतलब है कि फ्रेमवर्क बिल्ड-टाइम पर आपके कंपोनेंट्स का विश्लेषण कर सकता है और सामान्य UI इंजन भेजने के बजाय आपके ऐप के लिए टेलर्ड कोड आउटपुट करता है.
व्यवहार में इसका फ़ायदा छोटे बंडल और इंटरैक्शन्स (क्लिक, टाइपिंग, स्क्रॉलिंग) के दौरान कम CPU काम होता है।
शुरू करने के लिए:
हर बार एक ही यूजर फ्लो को मापें ताकि बिल्ड्स की तुलना विश्वसनीय हो।
हाँ—पर पहले पता करें समय कहाँ जा रहा है: नेटवर्क, बड़े इमेजेस, फ़ॉन्ट्स, थर्ड-पार्टी स्क्रिप्ट्स या JavaScript CPU.
फ्रेमवर्क बदलना एक उपाय है, पर यह हर समस्या का समाधान नहीं है; पहले बॉटलनेक्स की पहचान करें।
जब आपको फ्लेक्सिबिलिटी और तेज़ इटरेशन चाहिए तब runtime-heavy बेहतर होता है:
अगर रनटाइम आपका बॉटलनेक नहीं है, तो इसकी सहूलियत थोड़ा अतिरिक्त बाइट्स खर्च करने लायक हो सकती है।
सरल डिफ़ॉल्ट:
सबसे अच्छा अक्सर हाइब्रिड होता है—सीमाएँ लिखें ताकि ऐप भ्रमित न हो।
ऐसा बजट चुनें जो यूजर फील को बचाये बिना शिपिंग रोकने वाला न हो। उदाहरण:
बजट गार्डरेल हैं, परफेक्ट स्कोर की जंग नहीं।
हाइड्रेशन वह काम है जहाँ सर्वर-रेंडर की हुई पेज को इंटरएक्टिव बनाने के लिए इवेंट हैंडलर्स अटैच किए जाते हैं और ब्राउज़र में पर्याप्त स्टेट फिर से बनायी जाती है.
अगर आप बहुत ज़्यादा हाइड्रेट करते हैं तो पहली लोड धीमी लग सकती है, भले ही HTML जल्दी दिखे। बिल्ड-टाइम टूलिंग यह घटा सकती है अगर वह बता दे कि किस हिस्से को इंटरैक्टिव होना जरूरी है।
एक अच्छा “थिन-स्लाइस” इसमें रियल-वर्ल्ड जटिलता शामिल होनी चाहिए:
प्रोटोटाइप करते समय Koder.ai आपको चैट के ज़रिये वेब + बैकएंड फ्लो बनाने और सोर्स एक्सपोर्ट करने में मदद कर सकता है, ताकि आप बिना पूरी रीराइट किए माप और तुलना कर सकें।