वेब एप्लिकेशन को गति देना वेबपैक के साथ बनाता है

जैसे-जैसे आपका एप्लिकेशन विकसित और बढ़ता है, इसका निर्माण समय भी बढ़ता है - विकास मोड में फिर से असेंबली के दौरान "ठंड" उत्पादन विधानसभा के दौरान दसियों मिनट। यह पूरी तरह से अस्वीकार्य है। हम डेवलपर्स को बंडल तैयार होने का इंतजार करते समय संदर्भों को बदलना पसंद नहीं करते हैं और जितनी जल्दी हो सके आवेदन से प्रतिक्रिया प्राप्त करना चाहते हैं - आदर्श रूप से आईडीई से ब्राउज़र पर स्विच करते समय।

इसे कैसे प्राप्त किया जाए? बिल्ड टाइम को ऑप्टिमाइज़ करने के लिए हम क्या कर सकते हैं?

यह आलेख वेबपैक पारिस्थितिकी तंत्र में विधानसभा, उनके अनुभव और सुझावों को गति देने के लिए मौजूदा उपकरणों का अवलोकन है।

बंडल आकार और आवेदन के प्रदर्शन का अनुकूलन इस लेख में नहीं माना गया है।

परियोजना, जिसके संदर्भ पाठ में पाए जाते हैं और जिसके बारे में विधानसभा की गति का मापन किया जाता है, जेएस + फ्लो + रिएक्ट + रेडएक्स स्टैक पर लिखा गया एक छोटा सा अनुप्रयोग है जिसमें वेबपैक, बैबेल, पोस्टसीएसएस, सैस, आदि का उपयोग किया जाता है और इसमें लगभग 30 हजार शामिल होते हैं। कोड और 1,500 मॉड्यूल की लाइनें। अप्रैल 2019 तक निर्भरता संस्करण चालू हैं।

अध्ययन विंडोज 10, Node.js 8, 4-कोर प्रोसेसर, 8 जीबी मेमोरी और एसएसडी के साथ एक कंप्यूटर पर किए गए थे।

शब्दावली

• असेंबली प्रोजेक्ट स्रोत फ़ाइलों को संबंधित संपत्तियों के एक सेट में परिवर्तित करने की प्रक्रिया है जो एक साथ एक वेब एप्लिकेशन बनाते हैं।
• देव-मोड - विकल्प mode: 'development' साथ असेंबली mode: 'development' , आमतौर पर वेबपैक-देव-सर्वर और वॉच-मोड का उपयोग करते हुए।
• mode: 'production' -मोड - असेंबली विथ ऑप्शन mode: 'production' , आमतौर पर बंडल ऑप्टिमाइज़ेशन का एक पूरा सेट के साथ।
• वृद्धिशील निर्माण - देव-मोड में: केवल फ़ाइलों को परिवर्तन के साथ पुनर्निर्माण करें।
• "कोल्ड" बिल्ड - खरोंच से निर्माण, बिना किसी कैश के, लेकिन स्थापित निर्भरता के साथ।

कैशिंग

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

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

वेबपैक में कोई निरंतर (डिस्क या अन्य स्टोरेज के लिए सहेजा गया) कैश नहीं है, हालांकि वे इसे संस्करण 5 में जोड़ने का वादा करते हैं । इस बीच, हम निम्नलिखित उपकरणों का उपयोग कर सकते हैं:

- TerserWebpackPlugin सेटिंग्स में कैशिंग

डिफ़ॉल्ट रूप से अक्षम। अकेले भी इसका ध्यान देने योग्य सकारात्मक प्रभाव पड़ता है: 60.7 s → 39 s (-36%), अन्य कैशिंग टूल के साथ अच्छी तरह से चला जाता है।

स्विच करना और उपयोग करना बहुत सरल है:

 optimization: { minimizer: [ new TerserJsPlugin({ terserOptions: { ... }, cache: true }) ] } 

- कैश लोडर

कैश-लोडर को लोडर की किसी भी श्रृंखला में रखा जा सकता है और पिछले लोडर के परिणामों को कैश कर सकता है।

डिफ़ॉल्ट रूप से, यह कैश को प्रोजेक्ट रूट में .cache-लोडर फ़ोल्डर में सहेजता है। लोडर सेटिंग्स में cacheDirectory विकल्प का उपयोग करके, पथ को फिर से परिभाषित किया जा सकता है।

उपयोग उदाहरण:

 { test: /\.js$/, use: [ { loader: 'cache-loader', options: { cacheDirectory: path.resolve( __dirname, 'node_modules/.cache/cache-loader' ), }, }, 'babel-loader' ] } 

सुरक्षित और विश्वसनीय समाधान। यह लगभग किसी भी लोडर के साथ समस्याओं के बिना काम करता है: स्क्रिप्ट (बेबल-लोडर, टीएस-लोडर), शैलियों (एससीएस-, कम-, पोस्टस्कैस-, सीएसएस-लोडर), छवियों और फोंट (छवि-वेबपैक-लोडर, प्रतिक्रिया-एसवीजी) के लिए लोडर, फ़ाइल-लोडर), आदि।

कृपया ध्यान दें:

• स्टाइल-लोडर या MiniCssExtractPlugin.loader के संयोजन में कैश-लोडर का उपयोग करते समय, इसे उनके बाद रखा जाना चाहिए:
  ['style-loader', 'cache-loader', 'css-loader', ...] ।
• केवल श्रमसाध्य गणनाओं के परिणामों को कैशिंग के लिए इस लोडर का उपयोग करने के लिए प्रलेखन की सिफारिशों के विपरीत, यह "लाइटर" लोडरों के लिए एक छोटा लेकिन औसत दर्जे का प्रदर्शन बढ़ा सकता है - आपको प्रयास करने और मापने की आवश्यकता है।

परिणाम:

• देव: ३५.५ s → (कैश-लोडर को सक्षम करें) → ३६.२ एस (+ २%) → (reassembly) → 7.9 एस (-78%)
• ठेस: 60.6 s → (कैश-लोडर सक्षम करें) → 61.5 s (+ 1.5%) → (reassembly) → 30.6 s (-49%) → → (Terser के लिए कैश चालू करें) → 15 4 s (-75%)

- हार्डसोर्सवेबपैक लुगिन

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

 plugins: [ ..., new HardSourceWebpackPlugin() ] 

दस्तावेज़ में उन्नत सेटिंग्स और संभव समस्याओं को हल करने के लिए युक्तियों के साथ उपयोग के उदाहरण हैं। प्लग-इन ऑपरेशन को चालू आधार पर रखने से पहले, विभिन्न स्थितियों और विधानसभा मोड में इसके संचालन का पूरी तरह से परीक्षण करने के लायक है।

परिणाम:

• देव: ३५.५ s → (प्लगइन सक्षम करें) → ३६.५ s (+ ३%) → (reassembly) → 3.7 एस (-90%)
• ठेस: 60.6 s → (प्लगइन चालू करें) → 69.5 s (+ 15%) → (reassembly) → 25 s (-59%) → (टसर के लिए कैश चालू करें) → 10 s (-83%)

पेशेवरों:

• कैश-लोडर के साथ तुलना में, यह फिर से विधानसभा को भी तेज करता है;
• इसे कैश-लोडर के रूप में कॉन्फ़िगरेशन के विभिन्न स्थानों में डुप्लिकेट घोषणाओं की आवश्यकता नहीं है।

विपक्ष:

• कैश-लोडर की तुलना में, यह पहले बिल्ड को अधिक धीमा कर देता है (जब कोई डिस्क कैश नहीं है);
• वृद्धि के समय को थोड़ा बढ़ा सकते हैं;
• वेबपैक-देव-सर्वर का उपयोग करते समय समस्याएं हो सकती हैं और कैश पृथक्करण और अमान्यकरण ( प्रलेखन देखें) के विस्तृत विन्यास की आवश्यकता होती है;
• GitHub पर बग के साथ कुछ मुद्दे ।

- कोलाहल-लोडर सेटिंग में कैशिंग । डिफ़ॉल्ट रूप से अक्षम। प्रभाव कैश-लोडर से कई प्रतिशत अधिक खराब है।

- एस्लिंट-लोडर सेटिंग्स में कैशिंग । डिफ़ॉल्ट रूप से अक्षम। यदि आप इस लोडर का उपयोग करते हैं, तो कैश आपको reassembly के दौरान अपरिवर्तित फ़ाइलों को अस्तर करने में मदद नहीं करेगा।

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

कैशिंग सेट करते समय, निम्नलिखित प्रश्न उत्पन्न हो सकते हैं:

कैशिंग परिणामों को कहाँ संग्रहीत किया जाना चाहिए?

node_modules/.cache/<_>/ आमतौर पर node_modules/.cache/<_>/ निर्देशिका में संग्रहीत किए जाते हैं। अधिकांश उपकरण डिफ़ॉल्ट रूप से इस पथ का उपयोग करते हैं और यदि आप कैश को कहीं और संग्रहीत करना चाहते हैं तो आप इसे ओवरराइड करने की अनुमति देते हैं।

कैश को कब और कैसे अमान्य करना है?

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

विचार करने के लिए कारक:

• निर्भरता और उनके संस्करणों की सूची: package.json, package-lock.json, यार्न .lock, .yarn-अखंडता;
• वेबपैक, बैबेल, पोस्टसीएसएस, ब्राउज़र सूची और अन्य कॉन्फ़िगरेशन फ़ाइलों की सामग्री जो लोडर और प्लगइन्स द्वारा स्पष्ट रूप से या अंतर्निहित रूप से उपयोग की जाती हैं।

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

 "prunecaches": "rimraf ./node_modules/.cache/", "postinstall": "npm run prunecaches", "postuninstall": "npm run prunecaches" 

कैश को खाली करने के लिए कॉन्फ़िगर किया गया नोडबॉन और कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन का पता लगाने पर वेबपैक -देव-सर्वर को पुनरारंभ करना भी मदद करेगा:

 "start": "cross-env NODE_ENV=development nodemon --exec \"webpack-dev-server --config webpack.config.dev.js\"" 

nodemon.json

 { "watch": [ "webpack.config.dev.js", "babel.config.js", "more configs...", ], "events": { "restart": "yarn prunecaches" } } 

क्या मुझे प्रोजेक्ट रिपॉजिटरी में कैश को बचाने की आवश्यकता है?

चूंकि कैश वास्तव में, एक असेंबली आर्टवर्क है, इसलिए रिपॉजिटरी में इसे लागू करना आवश्यक नहीं है। नोड_मॉड्यूल फ़ोल्डर के अंदर कैश का स्थान, जो, एक नियम के रूप में, .ignignore में शामिल है, इसके साथ मदद करेगा।

यह ध्यान देने योग्य है कि अगर कोई कैशिंग सिस्टम था, जो किसी भी परिस्थिति में कैश की वैधता को मज़बूती से निर्धारित कर सकता है, जिसमें Node.js का OS और संस्करण बदलना भी शामिल है, तो कैश को विकास मशीनों या CI के बीच पुन: उपयोग किया जा सकता है, जो बहुत पहले निर्माण के बाद भी समय को काफी कम कर देगा शाखाओं के बीच स्विच करना।

किस बिल्ड मोड में यह मूल्य है और जिसमें यह कैश का उपयोग करने के लायक नहीं है?

यहां कोई निश्चित जवाब नहीं है: यह सब इस बात पर निर्भर करता है कि आप विकास के दौरान कितनी तीव्रता से देव और ठेस-मोड का उपयोग करते हैं और उनके बीच स्विच करते हैं। सामान्य तौर पर, कुछ भी हर जगह कैशिंग को चालू करने से रोकता है, लेकिन याद रखें कि यह आमतौर पर पहले निर्माण को धीमा कर देता है। CI में, आपको हमेशा एक "क्लीन" बिल्ड की आवश्यकता होती है, जिसमें उपयुक्त पर्यावरण चर का उपयोग करके कैशिंग को अक्षम किया जा सकता है।

वेबपैक में कैशिंग के बारे में रोचक सामग्री:

• https://github.com/webpack/webpack/issues/6527 - हार्डवर्कप्लुगिन द्वारा वेबपैक 5 में कैशिंग सिस्टम जोड़ने के लिए विनिर्देश का मसौदा और चर्चा
• https://gist.github.com/mzgoddard/0b42ad50048f407c1f3ac434a874f8e1 - HardSourcePlugin के लेखक ने चर्चा की कि वेबपैक में कैशिंग प्रणाली को कैसे लागू किया जाना चाहिए।
• https://github.com/webpack-contrib/cache-loader/issues/11 - HardSourcePlugin के साथ मिलकर कैश-लोडर का उपयोग करने पर राय
• https://github.com/webpack/webpack/issues/250 - वेबपैक कैशिंग सुविधाओं की चर्चा
• https://github.com/mzgoddard/hard-source-webpack-plugin/issues/251 - AutoDllPlugin के साथ HardSourcePlugin का उपयोग करने पर राय

साथ में चलाना

समानांतरकरण का उपयोग करते हुए, आप सभी उपलब्ध प्रोसेसर कोर का उपयोग करके एक प्रदर्शन को बढ़ावा दे सकते हैं। अंतिम प्रभाव प्रत्येक कार के लिए अलग-अलग होता है।

वैसे, यहां प्रोसेसर कोर की संख्या उपलब्ध करने के लिए एक सरल नोड कोड है। यह नीचे सूचीबद्ध उपकरणों को सेट करते समय काम में आ सकता है):

 const os = require('os'); const cores = os.cpus().length; 

- TerserWebpackPlugin सेटिंग्स में समानांतरकरण

डिफ़ॉल्ट रूप से अक्षम। अपने स्वयं के कैशिंग के साथ-साथ यह आसानी से चालू हो जाता है और विधानसभा को गति देता है।

 optimization: { minimizer: [ new TerserJsPlugin({ terserOptions: { ... }, parallel: true }) ] } 

- थ्रेड-लोडर

थ्रेड-लोडर को लोडरों की एक श्रृंखला में रखा जा सकता है जो भारी गणना करते हैं, जिसके बाद पिछले लोडर Node.js (प्रोसेसर) उपप्रकार पूल का उपयोग करेंगे।

इसमें विकल्पों का एक सेट है जो आपको श्रमिकों के पूल के काम को ठीक करने की अनुमति देता है, हालांकि बुनियादी मूल्य काफी पर्याप्त दिखते हैं। poolTimeout और workers विशेष ध्यान देने योग्य हैं - एक उदाहरण देखें।

इसका उपयोग कैश-लोडर के साथ निम्नानुसार किया जा सकता है (आदेश महत्वपूर्ण है): ['cache-loader', 'thread-loader', 'babel-loader'] । यदि थ्रेड-लोडर के लिए वार्मअप सक्षम है, तो आपको दोहराए जाने वाले असेंबली की स्थिरता की जांच करनी चाहिए जो कैश का उपयोग करते हैं - वेबपैक असेंबली सफलतापूर्वक पूरा होने के बाद प्रक्रिया को पूरा नहीं कर सकता है। इस मामले में, बस वार्मअप बंद कर दें।

यदि आप Sass- शैली संकलन श्रृंखला में थ्रेड-लोडर जोड़ने के बाद बिल्ड हैंग करते हैं, तो यह टिप मदद कर सकती है।

- हैप्पीपैक

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

हैप्पीपैक के पास समझने योग्य कॉन्फ़िगरेशन प्रलेखन है , जो संयोगवश, अपने आप में असामान्य है: यह लोडर कॉन्फ़िगरेशन को प्लग-इन कंस्ट्रक्टर कॉल में स्थानांतरित करने का प्रस्ताव है, और लोडर चेन को स्वयं अपने हैप्पीपैक लोडर के साथ बदल देता है। इस तरह के एक गैर-मानक दृष्टिकोण "टुकड़ों से" कस्टम वेबपैक बनाते समय असुविधा का कारण हो सकता है।

हैप्पीपैक लोडरों की एक सीमित सूची का समर्थन करता है; इस सूची में उपयोग किए जाने वाले मुख्य और सबसे व्यापक रूप से मौजूद हैं, लेकिन एपीआई के संभावित असंगतता के कारण दूसरों के प्रदर्शन की गारंटी नहीं है। अधिक जानकारी परियोजना के मुद्दों में पाई जा सकती है।

गणना से इनकार

किसी भी काम में समय लगता है। कम समय बिताने के लिए, आपको ऐसे काम से बचने की ज़रूरत है जो कम उपयोग के हैं, बाद में स्थगित हो सकते हैं, या इस स्थिति में बिल्कुल भी ज़रूरत नहीं है।

- जितना संभव हो उतने मॉड्यूल के लिए लोडर लागू करें

परीक्षण, बहिष्कृत और संपत्तियों को लोड करने वाले द्वारा प्रसंस्करण प्रक्रिया में मॉड्यूल सहित शर्तों को निर्दिष्ट करता है। बिंदु ऐसे ट्रांसफॉर्मिंग मॉड्यूल से बचना है, जिन्हें इस ट्रांसफॉर्मेशन की जरूरत नहीं है।

एक लोकप्रिय उदाहरण बाबेल के माध्यम से वाष्पीकरण से नोड_मॉड्यूल्स का अपवाद है:

 rules: [ { test: /\.jsx?$/, exclude: /node_modules/, loader: 'babel-loader' } ] 

एक और उदाहरण - नियमित सीएसएस फाइलों को एक पूर्वप्रोसेसर द्वारा संसाधित करने की आवश्यकता नहीं है:

 rules: [ { test: /\.scss$/, use: ['style-loader', 'css-loader', 'sass-loader'] }, { test: /\.css$/, use: ['style-loader', 'css-loader'] } ] 

- देव मोड में बंडल आकार अनुकूलन को सक्षम न करें

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

सलाह जेएस (टसर, यूग्लीफाई , इत्यादि ), सीएसएस (cssnano, ऑप्टिमाइजेशन-सीएसएस-एसेट्स-वेबपैक-प्लगइन), एसवीजी और इमेज (एसवीजीओ, इमेजमिन, इमेज-वेबपैक-लोडर), एचटीएमएल (HTML-minifier, विकल्प) html-webpack-plugin), आदि।

- पॉल मोड और ट्रांसफॉर्मेशन को देव विधा में शामिल न करें

यदि आप babel-preset-env, postcss-preset-env या Autoprefixer का उपयोग करते हैं - तो देव-मोड के लिए एक अलग ब्राउजरलिस्ट कॉन्फ़िगरेशन जोड़ें, जिसमें केवल वे ब्राउज़र शामिल हैं जो आप विकास के दौरान उपयोग करते हैं। सबसे अधिक संभावना है, ये क्रोम या फ़ायरफ़ॉक्स के नवीनतम संस्करण हैं जो पॉलीफ़िल और परिवर्तनों के बिना आधुनिक मानकों का पूरी तरह से समर्थन करते हैं। इससे अनावश्यक काम टालेंगे।

उदाहरण .browserslistrc:

 [production] your supported browsers go here... [development] last 2 Chrome versions last 2 Firefox versions last 1 Safari version 

- स्रोत के नक्शे के उपयोग की समीक्षा करें

सबसे सटीक और पूर्ण स्रोत मानचित्र तैयार करने में काफी समय लगता है (हमारी परियोजना पर - devtool: 'source-map' साथ लगभग 30% निर्माण-निर्माण समय devtool: 'source-map' विकल्प)। इस बारे में सोचें कि क्या आपको प्रोडक्शन असेंबली (स्थानीय स्तर पर और CI में) के सोर्स मैप्स की जरूरत है। यह केवल उन्हें आवश्यक हो सकता है जब आवश्यक हो - उदाहरण के लिए, एक पर्यावरण चर या प्रतिबद्ध पर टैग के आधार पर।

देव मोड में, ज्यादातर मामलों में एक हल्का विकल्प होगा - 'cheap-eval-source-map' या 'cheap-module-eval-source-map' । अधिक विवरण के लिए वेबपैक प्रलेखन देखें।

- टसर में कंप्रेशन स्थापित करें

Terser प्रलेखन के अनुसार (Uglify पर भी यही बात लागू होती है), जब कोड को छोटा किया जाता है, उस समय के भारी हिस्से को mangle और compress विकल्प द्वारा खाया जाता है। उन्हें ठीक से ट्यूनिंग करके, आप बंडल आकार में मामूली वृद्धि की कीमत पर विधानसभा त्वरण प्राप्त कर सकते हैं। वीयू-क्लि के स्रोतों में एक उदाहरण है और स्लैक के एक इंजीनियर का एक और उदाहरण है। हमारी परियोजना में, पहले अवतार में टसर ट्यूनिंग ने बंडल आकार में 2.5 प्रतिशत वृद्धि के बदले विधानसभा समय को लगभग 7% कम कर दिया। चाहे खेल मोमबत्ती के लायक हो आप पर निर्भर है।

- पार्सिंग से बाहरी निर्भरता को बाहर करें

module.noParse और module.noParse resolve.alias का उपयोग करके resolve.alias आप पहले से संकलित संस्करणों के लिए लाइब्रेरी मॉड्यूल के आयात को पुनर्निर्देशित कर सकते हैं और बस समय बर्बाद किए बिना बंडल में सम्मिलित कर सकते हैं। देव-मोड में, यह असेंबली सहित विधानसभा की गति में काफी वृद्धि करनी चाहिए।

एल्गोरिथ्म लगभग निम्नलिखित है:

(1) मॉड्यूल की एक सूची बनाएं जिसे पार्स करते समय छोड़ दिया जाना चाहिए।

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

(2) चयनित मॉड्यूल के लिए, उनके संकलित संस्करणों के लिए पथ लिखें।

निर्भरता को छोड़ देने के बजाय, आपको कलेक्टर को एक विकल्प प्रदान करने की आवश्यकता है, और यह विकल्प पर्यावरण पर निर्भर नहीं होना चाहिए - module.exports लिए कॉल करें। module.exports , require , process , import , आदि। पूर्व-संकलित (जरूरी नहीं कि एकल) फाइल-मॉड्यूल, जो आमतौर पर निर्भरता स्रोतों के अंदर डिस्टर्ब फोल्डर में रहते हैं, इस भूमिका के लिए उपयुक्त हैं। उन्हें खोजने के लिए, आपको node_modules पर जाना होगा। उदाहरण के लिए, axios के लिए, संकलित मॉड्यूल का मार्ग इस तरह दिखता है: node_modules/axios/dist/axios.js ।

(3) वेबपैक कॉन्फ़िगरेशन में, फ़ाइलों के प्रत्यक्ष आयात के साथ निर्भरता के नाम से आयात को बदलने के लिए संकल्प.लियास विकल्प का उपयोग करें, जिसके पथ पिछले चरण में लिखे गए थे।

उदाहरण के लिए:

 { resolve: { alias: { axios: path.resolve( __dirname, 'node_modules/dist/axios.min.js' ), ... } } } 

यहां एक बड़ी खामी है: यदि आपका कोड या आपकी निर्भरता का कोड मानक प्रविष्टि बिंदु (इंडेक्स फाइल, package.json में main क्षेत्र) को संदर्भित नहीं करता है, लेकिन निर्भरता स्रोतों के अंदर एक विशिष्ट फ़ाइल के लिए, या यदि निर्भरता को ईएस-मॉड्यूल के रूप में निर्यात किया जाता है, या यदि हल करने की प्रक्रिया कुछ के साथ हस्तक्षेप कर रही है (उदाहरण के लिए, बैबल-प्लगइन-ट्रांसफॉर्म-आयात), पूरा विचार विफल हो सकता है। बंडल इकट्ठा होगा, लेकिन आवेदन टूट जाएगा।

(4) वेबपैक कॉन्फ़िगरेशन में, नियमित अभिव्यक्ति का उपयोग करते हुए चरण 2 से पथों द्वारा अनुरोध किए गए पार्सिंग पूर्वकंप्लीकृत मॉड्यूल को छोड़ने के लिए मॉड्यूल.नोपर्स विकल्प का उपयोग करें।

उदाहरण के लिए:

 { module: { noParse: [ new RegExp('node_modules/dist/axios.min.js'), ... ] } } 

निचला रेखा: कागज पर, विधि आशाजनक दिखती है, लेकिन नुकसान के साथ एक गैर-तुच्छ सेटअप कार्यान्वयन लागत को कम करता है, और बहुत कम से कम लाभ को कम करता है।

ऑपरेशन के समान सिद्धांत के साथ एक विकल्प externals विकल्पों का उपयोग करना है। इस स्थिति में, आपको HTML फ़ाइल में बाहरी स्क्रिप्ट के लिंक स्वतंत्र रूप से सम्मिलित करने होंगे, और यहां तक ​​कि पैकेज .json के लिए आवश्यक निर्भरता संस्करणों के साथ भी।

- कोड को अलग-अलग बंडल में शायद ही कभी अलग करें और इसे केवल एक बार संकलित करें

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

यह सामान्य शब्दों में इस तरह दिखता है:

1. DLL बनाने के लिए, एक अलग वेबपैक कॉन्फ़िगरेशन बनाया जाता है, आवश्यक मॉड्यूल प्रवेश बिंदुओं के रूप में जुड़े होते हैं।
2. बिल्ड इस कॉन्फ़िगरेशन से शुरू होता है। DllPlugin एक DLL बंडल और मैप नामों और मॉड्यूल पथों के साथ एक प्रकट फ़ाइल बनाता है।
3. DllReferencePlugin को मुख्य असेंबली के कॉन्फ़िगरेशन में जोड़ा जाता है, जिसमें मैनिफ़ेस्ट पास होता है।
4. असेंबली के दौरान DLL में दी गई निर्भरता के आयात को पहले से ही संकलित मॉड्यूल का उपयोग करके प्रकट किया जाता है।

आप यहां लेख में थोड़ा और पढ़ सकते हैं।

इस दृष्टिकोण का उपयोग करने के लिए, आप जल्दी से कई नुकसान पाएंगे:

• DLL असेंबली को मुख्य असेंबली से अलग किया जाता है, और इसे अलग से प्रबंधित करने की आवश्यकता होती है: एक विशेष कॉन्फ़िगरेशन तैयार करें, इसे पुनरारंभ करें हर बार जब एक शाखा स्विच या एक निर्भरता बदलती है।
• चूंकि DLL मुख्य असेंबली की कलाकृतियों से संबंधित नहीं है, इसलिए इसे मैन्युअल रूप से अन्य परिसंपत्तियों के साथ फ़ोल्डर में कॉपी करना होगा और इनमें से एक प्लग इन का उपयोग करके HTML फ़ाइल में शामिल किया जाना चाहिए: 1 , 2 ।
• DLL बंडल में शामिल करने के लिए इच्छित निर्भरता की सूची को मैन्युअल रूप से अद्यतित रखना आवश्यक है।
• सबसे दुखद बात: DLL बंडल पर पेड़-हिलाना लागू नहीं होता है। सिद्धांत रूप में, इसके लिए entryOnly विकल्प का इरादा है, लेकिन वे इसे दस्तावेज़ करना भूल गए।

आप बॉयलरप्लेट से छुटकारा पा सकते हैं और पहली समस्या को हल कर सकते हैं (साथ ही दूसरी, यदि आप html-webpack-plugin v3 का उपयोग करते हैं - यह संस्करण 4 के साथ काम नहीं करता है) AutoDllPlugin का उपयोग कर। हालांकि, यह अभी भी "हुड के तहत" इस्तेमाल किए गए entryOnly लिए entryOnly विकल्प का समर्थन नहीं करता है, और प्लगइन का लेखक आने वाले वेबपैक 5 की रोशनी में अपने दिमाग की उपज का उपयोग करने की सलाह पर संदेह करता है।

अनेक वस्तुओं का संग्रह

अपने सॉफ़्टवेयर और निर्भरता को नियमित रूप से अपडेट करें। Node.js, npm / yarn (webpack, Babel .) . , changelog, issues, , .

PostCSS postcss-preset-env stage, . , stage-3, Custom Properties, stage-4 13%.

Sass (node-sass, sass-loader), Dart Sass ( Sass Dart, JS) fast-sass-loader . , . — dart-sass , node-sass, JS, libsass.

Dart Sass sass-loader . Sass fibers.

CSS-, dev-. - , , , .

एक उदाहरण:

 { loader: 'css-loader', options: { modules: true, localIdentName: isDev ? '[path][name][local]' : '[hash:base64:5]' } } 

, , : .

, - webpack PrefetchPlugin , , — . webpack issues , . ?

1. . CLI- --json , . . , , dev- .
2. - Hints.
3. , “Long module build chains”. , — PrefetchPlugin .
4. PrefetchPlugin. . StackOverflow .

: .

, (TypeScript, Angular .) — !

सूत्रों का कहना है

, , , .

• https://webpack.js.org/guides/build-performance/
• https://survivejs.com/webpack/optimizing/performance/
• https://github.com/webpack/docs/wiki/build-performance
• https://slack.engineering/keep-webpack-fast-a-field-guide-for-better-build-performance-f56a5995e8f1
• https://medium.com/webpack/typescript-webpack-super-pursuit-mode-83cc568dea79
• https://medium.com/ottofellercom/0-100-in-two-seconds-speed-up-webpack-465de691ed4a
• https://medium.com/onfido-tech/speed-up-webpack-ff53c494b89c
• https://blog.box.com/blog/how-we-improved-webpack-build-performance-95
• https://engineering.bitnami.com/articles/optimizing-your-webpack-builds.html
• https://habr.com/ru/company/skbkontur/blog/351080/
• https://habr.com/ru/company/oleg-bunin/blog/433324/
• https://github.com/lcxfs1991/blog/issues/15
• https://github.com/FrendEr/webpack-optimize-example