वेबपैक का उपयोग करके वेबसाइट सामग्री को अलग करने का सही तरीका खोजना

वेब प्रोजेक्ट सामग्रियों को व्यवस्थित करने का सबसे अच्छा तरीका खोजना एक कठिन काम हो सकता है। उपयोगकर्ताओं के लिए परियोजनाओं, कई प्रौद्योगिकियों और अन्य कारकों के साथ काम करने के लिए कई अलग-अलग परिदृश्य हैं जिन्हें ध्यान में रखना आवश्यक है।

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

सामान्य जानकारी

वेबपैक शब्दावली के अनुसार, दो फ़ाइल साझा करने की रणनीतियाँ हैं। यह बंडल विभाजन और कोड विभाजन है। इन शर्तों का उपयोग करने के लिए लग सकता है, लेकिन वे नहीं हैं।

• बंडल को विभाजित करना कई हिस्सों में बड़े बंडल को तोड़ने की एक तकनीक है, जो छोटी फाइलें हैं। ऐसी फाइलें, किसी भी मामले में, जैसे कि एक बंडल के साथ काम करते समय, साइट के सभी उपयोगकर्ताओं द्वारा डाउनलोड की जाएगी। इस तकनीक की ताकत ब्राउज़र-आधारित कैशिंग तंत्रों के उपयोग में सुधार करना है।
• कोड पृथक्करण एक दृष्टिकोण है जिसमें आवश्यकता के अनुसार कोड को गतिशील रूप से लोड करना शामिल है। यह इस तथ्य की ओर जाता है कि उपयोगकर्ता केवल उस कोड को डाउनलोड करता है जिसे उसे एक निश्चित समय पर साइट के एक निश्चित हिस्से के साथ काम करने की आवश्यकता होती है।

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

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

आइए इस बारे में अधिक विस्तार से बात करते हैं।

बंडलों का अलग होना

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

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

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

जब नियमित आगंतुकों की बात आती है, तो उनके लिए लागू सामग्री अनुकूलन तकनीकों के प्रभाव को मापना मुश्किल हो सकता है। लेकिन हमें बस ऐसे अनुकूलन के परिणामों के बारे में पता होना चाहिए।

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

यहां एक स्क्रिप्ट है जो पिछले पैराग्राफ में दिए गए सामान्य विवरण को फिट करता है:

• ऐलिस सप्ताह में एक बार 10 सप्ताह के लिए हमारी साइट पर जाता है।
• हम सप्ताह में एक बार साइट को अपडेट करते हैं।
• हर हफ्ते, हम उत्पाद सूची पृष्ठ को अपडेट करते हैं।
• इसके अलावा, हमारे पास उत्पाद विवरण के साथ एक पृष्ठ है, लेकिन हम अभी तक इस पर काम नहीं कर रहे हैं।
• पांचवें सप्ताह में, हम प्रोजेक्ट सामग्रियों में एक नया एनपीएम पैकेज जोड़ते हैं।
• आठवें सप्ताह में, हम पहले से ही परियोजना में उपयोग किए जाने वाले एनपीएम पैकेजों में से एक को अपडेट करते हैं।

ऐसे लोग (मेरे जैसे) हैं जो इस तरह के परिदृश्य को यथासंभव यथार्थवादी बनाने की कोशिश करेंगे। लेकिन आपको ऐसा करने की आवश्यकता नहीं है। यहां वास्तविक परिदृश्य वास्तव में मायने नहीं रखता है। ऐसा क्यों है - हम जल्द ही पता लगाएंगे।

▍ प्रारंभिक शर्तें

मान लीजिए कि हमारे जावास्क्रिप्ट पैकेज का कुल आकार काफी 400 Kb है और हम, वर्तमान परिस्थितियों में, यह सब एक ही main.js फ़ाइल के रूप में उपयोगकर्ता को main.js हैं। हमारे पास एक वेबपैक कॉन्फ़िगरेशन है, जो सामान्य शब्दों में, निम्नलिखित के समान है (मैंने उन चीजों को हटा दिया जो हमारी बातचीत के लिए प्रासंगिक नहीं हैं):

 const path = require('path'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash].js', }, }; 

main.js परिणामी main.js फ़ाइल को नाम देता है जब विन्यास में एकल प्रविष्टि होती है।

यदि आपके पास कैश के साथ काम करने का बहुत अच्छा विचार नहीं है, तो ध्यान रखें कि हर बार जब मैं यहां main.js लिखता main.js , तो मेरा वास्तव में main.xMePWxHo.js जैसा कुछ main.xMePWxHo.js । वर्णों का एक क्रेज़ी अनुक्रम एक फ़ाइल की सामग्री का एक हैश है, जिसे कॉन्फ़िगरेशन में contenthash कहा जाता है। इस दृष्टिकोण का उपयोग करके इस तथ्य की ओर जाता है कि, कोड बदलते समय, फ़ाइल नाम भी बदल जाते हैं, जो ब्राउज़र को नई फ़ाइलों को डाउनलोड करने के लिए मजबूर करता है।

उपरोक्त परिदृश्य के अनुसार, जब हम हर हफ्ते साइट कोड में कुछ बदलाव करते हैं, तो पैकेज की contenthash लाइन बदल जाती है। परिणामस्वरूप, साप्ताहिक हमारी साइट पर जाकर, ऐलिस 400 Kb की एक नई फ़ाइल अपलोड करने के लिए मजबूर है।

यदि हम इस फाइल के प्रति साप्ताहिक लोडिंग की साप्ताहिक मात्रा पर डेटा युक्त एक अच्छी टैबलेट (अब तक बेकार परिणाम वाली लाइन) बनाते हैं, तो हमें निम्नलिखित प्राप्त होते हैं।


उपयोगकर्ता द्वारा अपलोड किए गए डेटा की मात्रा

नतीजतन, यह पता चलता है कि उपयोगकर्ता ने 10 सप्ताह में, 4.12 एमबी कोड डाउनलोड किया। इस सूचक को बेहतर बनाया जा सकता है।

Code मुख्य कोड से तीसरे पक्ष के पैकेजों का पृथक्करण

बड़े पैकेज को दो भागों में विभाजित करें। हमारा अपना कोड main.js फ़ाइल में होगा, और main.js फ़ाइल में तृतीय-पक्ष कोड होगा। ऐसा करना आसान है, निम्नलिखित वेबपैक कॉन्फ़िगरेशन हमें इससे मदद करेगा:

 const path = require('path'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash].js', }, optimization: {   splitChunks: {     chunks: 'all',   }, }, }; 

वेबपैक 4 डेवलपर के लिए जीवन को यथासंभव आसान बनाने की कोशिश करता है, इसलिए वह वह सब कुछ करता है जो वह करता है, और उसे बंडलों को भागों में तोड़ने के तरीके के बारे में ठीक से बताने की आवश्यकता नहीं है।

कार्यक्रम के इस तरह के स्वचालित व्यवहार से कुछ प्रसन्नता होती है, जैसे: "ठीक है, इस वेबपैक का आकर्षण क्या है", और भावना के कई सवाल: "यह मेरे बंडलों के साथ क्या किया गया है?"।

किसी भी स्थिति में, कॉन्फ़िगरेशन कॉन्फ़िगरेशन को जोड़ने के लिए optimization.splitChunks.chunks = 'all' । node_modules optimization.splitChunks.chunks = 'all' कॉन्फ़िगरेशन कॉन्फ़िगरेशन को node_modules बताता है कि हमें node_modules से सब कुछ लेने और इसे vendors~main.js में डालने की आवश्यकता vendors~main.js ।

हम बंडल के ऐसे बुनियादी पृथक्करण के बाद, ऐलिस, जो नियमित रूप से हमारी साइट पर साप्ताहिक रूप से आते हैं, हर बार मिलने वाली 200 Kb की main.js फ़ाइल डाउनलोड करेंगे। लेकिन वह केवल तीन बार vendor.js फ़ाइल डाउनलोड करेगा। यह पहले, पांचवें और आठवें सप्ताह में यात्राओं के दौरान होगा। यहाँ एक ही सारणी है, जिसमें भाग्य की इच्छा से, पहले चार सप्ताह में vendor.js main.js और vendor.js के आकार मेल खाते हैं और 200 के बराबर हैं।


उपयोगकर्ता द्वारा अपलोड किए गए डेटा की मात्रा

परिणामस्वरूप, यह पता चलता है कि उपयोगकर्ता द्वारा 10 सप्ताह में डाउनलोड किए गए डेटा की मात्रा 2.64 एमबी थी। अर्थात्, बंडल के अलग होने से पहले की तुलना में, मात्रा 36% कम हो गई थी। कॉन्फ़िगरेशन फ़ाइल में कुछ पंक्तियों को जोड़कर प्राप्त किया गया ऐसा बुरा परिणाम नहीं है। वैसे, आगे पढ़ने से पहले - अपने प्रोजेक्ट में भी ऐसा ही करें। और अगर आपको वेबपैक 3 से 4 में अपग्रेड करने की आवश्यकता है - तो इसे करें और चिंता न करें, क्योंकि यह प्रक्रिया काफी सरल है और अभी भी मुफ्त है।

यह मुझे लगता है कि यहां पर सुधार कुछ हद तक अमूर्त दिखता है, क्योंकि यह 10 सप्ताह से अधिक लंबा है। हालांकि, अगर हम एक वफादार उपयोगकर्ता को भेजे गए डेटा की मात्रा पर विचार करते हैं, तो यह इस मात्रा में 36% की एक ईमानदार कमी है। यह बहुत अच्छा परिणाम है, लेकिन इसमें सुधार किया जा सकता है।

अलग फ़ाइलों में संकुल हाइलाइट करें

vendor.js फ़ाइल मूल main.js के समान समस्या से ग्रस्त है यह इस तथ्य में शामिल है कि इस फ़ाइल में शामिल किसी भी पैकेज को बदलने के लिए एक नियमित उपयोगकर्ता की आवश्यकता होती है ताकि पूरी फ़ाइल को फिर से डाउनलोड किया जा सके।

हम प्रत्येक npm पैकेज के लिए अलग फाइल क्यों नहीं बनाते हैं? ऐसा करना मुश्किल नहीं है, इसलिए हम अपनी react , lodash , lodash , moment , और इसी तरह अलग-अलग फाइलों में विघटित करें। निम्नलिखित वेबपैक कॉन्फ़िगरेशन हमें इसमें मदद करेगा:

 const path = require('path'); const webpack = require('webpack'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), plugins: [   new webpack.HashedModuleIdsPlugin(), //        ], output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash].js', }, optimization: {   runtimeChunk: 'single',   splitChunks: {     chunks: 'all',     maxInitialRequests: Infinity,     minSize: 0,     cacheGroups: {       vendor: {         test: /[\\/]node_modules[\\/]/,         name(module) {           //  ,   node_modules/packageName/not/this/part.js           //  node_modules/packageName           const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];           //  npm- ,   ,           //  URL,        @           return `npm.${packageName.replace('@', '')}`;         },       },     },   }, }, }; 

प्रलेखन में आप यहां उपयोग किए गए निर्माणों का एक उत्कृष्ट विवरण पा सकते हैं, लेकिन मैं अभी भी कुछ चीजों के बारे में बताने के लिए कुछ समय समर्पित करता हूं, क्योंकि मुझे उन्हें सही ढंग से उपयोग करने में बहुत समय लगा।

• वेबपैक के पास काफी उचित मानक इंस्टॉलेशन हैं, जो वास्तव में, इतने उचित नहीं हैं। उदाहरण के लिए, आउटपुट फ़ाइलों की अधिकतम संख्या 3 पर सेट की गई है, न्यूनतम फ़ाइल आकार 30 KB है (अर्थात, छोटी फ़ाइलों को विलय कर दिया जाएगा)। मैंने इसे फिर से परिभाषित किया।
• cacheGroups वह जगह है जहां हम नियमों को सेट करते हैं कि cacheGroups को आउटपुट फ़ाइलों में समूह डेटा कैसे करना चाहिए। मेरा यहां एक समूह है, vendor , जिसका उपयोग node_modules से लोड किए गए किसी भी मॉड्यूल के लिए किया जाएगा। आमतौर पर आउटपुट फ़ाइल का नाम स्ट्रिंग के रूप में दिया जाता है। लेकिन मैंने एक फ़ंक्शन के रूप में name दिया, जिसे प्रत्येक संसाधित फ़ाइल के लिए बुलाया जाएगा। फिर मैं मॉड्यूल पथ से पैकेज का नाम लेता हूं। नतीजतन, हमें प्रत्येक पैकेज के लिए एक फ़ाइल मिलती है। उदाहरण के लिए, npm.react-dom.899sadfhj4.js ।
• पैकेज के नाम, ताकि उन्हें npm में प्रकाशित किया जा सके, URL में उपयोग के लिए उपयुक्त होना चाहिए, इसलिए हमें packageName नामों पर packageName ऑपरेशन करने की आवश्यकता नहीं है। हालाँकि, मैं एक समस्या में भाग गया था कि .NET सर्वर उन फ़ाइलों के साथ काम करने से इंकार कर देता है जिनके नाम में @ प्रतीक होता है (ऐसे नाम पैकेजों के लिए दिए गए नाम की गुंजाइश के साथ उपयोग किए जाते हैं, तथाकथित स्कोप किए गए पैकेज), इसलिए मैं, इसी में कोड का टुकड़ा, मुझे इस तरह के पात्रों से छुटकारा मिलता है।

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

ऐलिस, हमारा नियमित आगंतुक, अभी भी हर हफ्ते 200-किलोबाइट main.js , और पहली बार जब वह साइट पर जाता है, तो उसे 200 Kb का npm पैकेज डाउनलोड करना पड़ता है, लेकिन उसे दो बार एक ही पैकेज डाउनलोड नहीं करना पड़ता है।

नीचे साप्ताहिक डेटा डाउनलोड की मात्रा के बारे में जानकारी के साथ तालिका का एक नया संस्करण है। एक अजीब संयोग से, npm संकुल वाली प्रत्येक फ़ाइल का आकार 20 Kb है।


उपयोगकर्ता द्वारा अपलोड किए गए डेटा की मात्रा

अब 10 सप्ताह में डाउनलोड किए गए डेटा की मात्रा 2.24 एमबी है। इसका मतलब है कि हमने बेस रेट में 44% तक सुधार किया है। परिणाम पहले से ही बहुत सभ्य है, लेकिन यह सवाल उठता है कि क्या ऐसा करना संभव है ताकि 50% से अधिक परिणाम प्राप्त किया जा सके। अगर ऐसा होता है, तो यह बहुत अच्छा होगा।

Ments टुकड़े में आवेदन कोड को विभाजित करना

हम main.js फ़ाइल पर main.js हैं, जिसे दुर्भाग्यपूर्ण ऐलिस को लगातार डाउनलोड करना पड़ता है।

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

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

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

इसके साथ कुछ करने की जरूरत है।

हमने वेबपैक को बताते हुए कई प्रविष्टि बिंदुओं को मैन्युअल रूप से बनाया है, इनमें से प्रत्येक संस्था के लिए एक अलग फ़ाइल बनाने की आवश्यकता है।

 module.exports = { entry: {   main: path.resolve(__dirname, 'src/index.js'),   ProductList: path.resolve(__dirname, 'src/ProductList/ProductList.js'),   ProductPage: path.resolve(__dirname, 'src/ProductPage/ProductPage.js'),   Icon: path.resolve(__dirname, 'src/Icon/Icon.js'), }, output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash:8].js', }, plugins: [   new webpack.HashedModuleIdsPlugin(), //        ], optimization: {   runtimeChunk: 'single',   splitChunks: {     chunks: 'all',     maxInitialRequests: Infinity,     minSize: 0,     cacheGroups: {       vendor: {         test: /[\\/]node_modules[\\/]/,         name(module) {           //  ,   node_modules/packageName/not/this/part.js           //  node_modules/packageName           const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];           //  npm- ,   ,           //  URL,        @           return `npm.${packageName.replace('@', '')}`;         },       },     },   }, }, }; 

इसके अलावा, हार्ड-वर्किंग ProductPage , जो सामान्य है, उसके लिए फाइलें बनाएगा, उदाहरण के लिए, ProductList और ProductPage , यानी कोई डुप्लिकेट कोड नहीं होगा।

हमने अभी जो किया वह एलिस को लगभग हर हफ्ते 50 केबीपी ट्रैफिक को बचाने की अनुमति देगा। कृपया ध्यान दें कि हमने छठे सप्ताह में आइकन विवरण फ़ाइल को संपादित किया है। यहाँ हमारी पारंपरिक तालिका है।


उपयोगकर्ता द्वारा अपलोड किए गए डेटा की मात्रा

अब केवल दस हफ्तों में, केवल 1.815 एमबी डेटा डाउनलोड किया गया है। इसका मतलब है कि ट्रैफ़िक बचत 56% प्रभावशाली थी। हमारे सैद्धांतिक परिदृश्य के अनुसार, एक नियमित उपयोगकर्ता हमेशा बचत के इस स्तर के साथ काम करेगा।

यह सब Webpack कॉन्फ़िगरेशन में किए गए परिवर्तनों के कारण किया जाता है। हमने ऐसे परिणामों को प्राप्त करने के लिए एप्लिकेशन कोड को नहीं बदला।

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

जल्द ही हम कोड पृथक्करण के बारे में बात करना शुरू करेंगे, लेकिन पहले मैं तीन सवालों के जवाब देना चाहूंगा जो आप अभी सोच रहे हैं।

1 प्रश्न संख्या 1। क्या कई अनुरोधों को करने की आवश्यकता साइट को लोड करने की गति को नुकसान नहीं पहुंचाती है?

आप इस प्रश्न का एक सरल संक्षिप्त उत्तर दे सकते हैं: "नहीं, यह नुकसान नहीं पहुंचाता है।" इसी तरह की स्थिति पुराने दिनों में एक समस्या थी, जब HTTP / 1.1 प्रोटोकॉल उपयोग में था, और HTTP / 2 का उपयोग करते समय, यह अब प्रासंगिक नहीं है।

हालांकि, यह ध्यान दिया जाना चाहिए कि 2016 में प्रकाशित इस लेख में, और इस 2015 खान अकादमी लेख में, निष्कर्ष निकाला गया है कि HTTP / 2 का उपयोग करते समय, बहुत सारी फ़ाइलों का उपयोग करके डाउनलोड धीमा कर देता है। लेकिन इन दोनों सामग्रियों में, "बहुत अधिक" का अर्थ है "कई सौ।" इसलिए, यह याद रखने योग्य है कि यदि आपको सैकड़ों फ़ाइलों के साथ काम करना है, तो समानांतर डेटा प्रोसेसिंग पर प्रतिबंध उनकी डाउनलोड गति को प्रभावित कर सकता है।

यदि आप रुचि रखते हैं, तो विंडोज़ 10 पर IE 11 में HTTP / 2 समर्थन उपलब्ध है। इसके अलावा, मैंने पुराने सिस्टम का उपयोग करने वालों के बीच एक व्यापक अध्ययन किया। उन्होंने सर्वसम्मति से कहा कि उनकी वेबसाइट लोडिंग गति विशेष रूप से चिंताजनक नहीं थी।

2 प्रश्न संख्या 2। वेबपैक बंडलों में सहायक कोड होता है। क्या यह सिस्टम पर अतिरिक्त भार पैदा करता है?

हाँ यह है

3 प्रश्न संख्या 3। कई छोटी फ़ाइलों के साथ काम करते समय, उनका संपीड़न स्तर बिगड़ जाता है, है ना?

जी हां, यह भी सच है। वास्तव में, मैं यह कहना चाहूंगा:

• अधिक फ़ाइलों का अर्थ है अधिक वेबपैक सहायक कोड।
• अधिक फ़ाइलों का मतलब कम संपीड़न है।

आइए इसे समझने के लिए कि यह कितना बुरा है।

मैंने अभी एक परीक्षण किया, जिसमें 190 केबीई फ़ाइल से कोड को 19 भागों में तोड़ा गया। इसने ब्राउज़र को भेजे गए डेटा की मात्रा में लगभग 2% जोड़ दिया।

नतीजतन, यह पता चलता है कि साइट पर पहली यात्रा पर, उपयोगकर्ता 2% अधिक डेटा अपलोड करेगा, और बाद की यात्राओं में - 60% कम, और यह बहुत, बहुत लंबे समय तक जारी रहेगा।
तो क्या यह चिंता करने लायक है? नहीं, इसके लायक नहीं है।

जब मैंने 1 फ़ाइल का उपयोग करने वाले सिस्टम और 19 फाइलों के साथ एक सिस्टम की तुलना की, तो मैंने HTTP / 1.1 सहित विभिन्न प्रोटोकॉल का उपयोग करके इसका परीक्षण किया। नीचे दी गई तालिका दृढ़ता से इस विचार का समर्थन करती है कि अधिक फाइलें होने का मतलब बेहतर है।


फायरबेस स्थैतिक होस्टिंग पर होस्ट की गई साइट के 2 संस्करणों के साथ काम करने पर डेटा, जिसका कोड आकार में 190 Kb है, लेकिन, पहले मामले में, इसे 1 फ़ाइल में पैक किया गया है, और दूसरे में इसे 19 में विभाजित किया गया है

3 जी और 4 जी नेटवर्क में काम करते समय, 19 फ़ाइलों वाली साइट को डाउनलोड करने में एक फ़ाइल के साथ साइट डाउनलोड करने की तुलना में 30% कम समय लगता है।

तालिका में प्रस्तुत आंकड़ों में बहुत अधिक शोर है। उदाहरण के लिए, 4 जी (तालिका में रन 2) द्वारा किसी साइट को डाउनलोड करने का एक सत्र 646 एमएस, दूसरा (रन 4) - 1116 एमएस लिया गया, जो 73% लंबा है। इसलिए, एक भावना है कि यह कहना कि HTTP / 2 "30% तेज" है कुछ हद तक बेईमान है।

HTTP / 2 का उपयोग क्या होता है, यह देखने के लिए मैंने यह तालिका बनाई। लेकिन, वास्तव में, केवल एक चीज जो यहां कही जा सकती है, वह यह है कि HTTP / 2 का उपयोग संभवतः पृष्ठ लोडिंग पर विशेष रूप से ध्यान देने योग्य नहीं है।

इस तालिका में अंतिम दो पंक्तियाँ एक वास्तविक आश्चर्य थीं। यहां IE11 और HTTP / 1.1 के साथ विंडोज के नवीनतम संस्करण के लिए परिणाम नहीं हैं। अगर मैंने अग्रिम में परीक्षण के परिणामों की भविष्यवाणी करने की कोशिश की, तो मैं निश्चित रूप से कहूंगा कि इस तरह के कॉन्फ़िगरेशन दूसरों की तुलना में बहुत अधिक धीरे-धीरे सामग्री लोड करेंगे। सच है, यहां बहुत तेज़ नेटवर्क कनेक्शन का उपयोग किया गया था, और मैं, ऐसे परीक्षणों के लिए, शायद कुछ धीमे का उपयोग करना चाहिए।

और अब मैं आपको एक कहानी सुनाता हूँ। बहुत प्राचीन प्रणाली पर अपनी साइट का पता लगाने के लिए, मैंने माइक्रोसॉफ्ट वेबसाइट से विंडोज 7 वर्चुअल मशीन डाउनलोड की। IE8 वहां स्थापित किया गया था, जिसे मैंने IE9 में अपग्रेड करने का निर्णय लिया था। ऐसा करने के लिए, मैं IE 9. डाउनलोड करने के लिए डिज़ाइन किए गए Microsoft पृष्ठ पर गया था लेकिन मैं ऐसा नहीं कर सका।


वो बदकिस्मती ...

वैसे, अगर हम HTTP / 2 के बारे में बात करते हैं, तो मैं ध्यान देना चाहता हूं कि यह प्रोटोकॉल Node.js. में एकीकृत है। यदि आप प्रयोग करना चाहते हैं, तो आप छोटे HTTP / 2 सर्वर का उपयोग कर सकते हैं जो मैंने प्रतिक्रिया कैश, गज़िप और ब्रेटली के समर्थन के साथ लिखा था।

शायद, मैंने सब कुछ कहा जो मैं बंडलों के पृथक्करण की विधि के बारे में चाहता था। मुझे लगता है कि इस दृष्टिकोण का एकमात्र माइनस, जिसका उपयोग करते समय उपयोगकर्ताओं को बहुत सारी फाइलें अपलोड करनी होती हैं, वास्तव में, ऐसा "माइनस" नहीं है।

अब कोड जुदाई के बारे में बात करते हैं।

कोड जुदाई

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

मैं पसंद करता हूं, जब कोड जुदाई की बात आती है, तो 20/20 नियम का उपयोग करने के लिए जिसे मैंने अभी तैयार किया है। यदि साइट का कुछ हिस्सा केवल 20% उपयोगकर्ताओं द्वारा देखा जाता है, और इसकी कार्यक्षमता साइट के जावास्क्रिप्ट कोड के 20% से अधिक द्वारा प्रदान की जाती है, तो इस कोड को केवल अनुरोध पर डाउनलोड किया जाना चाहिए।

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

Not अलग हो या न हो?

इस सवाल का जवाब कैसे खोजना है कि आपको कोड अलगाव की आवश्यकता है या नहीं? मान लीजिए कि आपके पास एक ऑनलाइन स्टोर है, और आप इस बारे में सोच रहे हैं कि क्या ग्राहकों को भुगतान प्राप्त करने के लिए उपयोग किए जाने वाले कोड से अलग होना चाहिए, क्योंकि केवल 30% आगंतुक आपसे कुछ खरीदते हैं।

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

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

तो, आपको पता चला कि खरीद के लिए भुगतान करने के लिए उपयोग किए जाने वाले साइट अनुभाग का एक पूरी तरह से अद्वितीय कोड 7 Kb लगता है। बाकी साइट कोड का आकार 300 Kb है। ऐसी स्थिति में, मैं कई कारणों से कोड पृथक्करण में संलग्न नहीं होगा:

• यदि आप इन 7 Kb को पहले से डाउनलोड करते हैं, तो साइट धीमा नहीं होगी। याद रखें कि फाइलें समानांतर में डाउनलोड की जाती हैं और कोड के 300 Kb और 307 Kb डाउनलोड करने के लिए आवश्यक अंतर को मापने की कोशिश करती हैं।
• यदि आप इस कोड को बाद में डाउनलोड करते हैं, तो उपयोगकर्ता को "पे" बटन पर क्लिक करने के बाद इंतजार करना होगा। और यह वही क्षण है जब आपको यथासंभव आसानी से जाने के लिए सब कुछ चाहिए।
• कोड पृथक्करण के लिए अनुप्रयोग में परिवर्तन की आवश्यकता होती है। कोड में, उन जगहों पर जहां सब कुछ पहले सिंक्रोनस से किया गया था, अतुल्यकालिक तर्क प्रकट होता है। , , , , , .

, , , .

.

▍

, , , .

. , . :

 require('whatwg-fetch'); require('intl'); require('url-polyfill'); require('core-js/web/dom-collections'); require('core-js/es6/map'); require('core-js/es6/string'); require('core-js/es6/array'); require('core-js/es6/object'); 

index.js , :

 import './polyfills'; import React from 'react'; import ReactDOM from 'react-dom'; import App from './App/App'; import './index.css'; const render = () => { ReactDOM.render(<App />, document.getElementById('root')); } render(); // ,      

Webpack , , npm-. 25 , 90% , .

Webpack 4 import() ( import ), :

 import React from 'react'; import ReactDOM from 'react-dom'; import App from './App/App'; import './index.css'; const render = () => { ReactDOM.render(<App />, document.getElementById('root')); } if ( 'fetch' in window && 'Intl' in window && 'URL' in window && 'Map' in window && 'forEach' in NodeList.prototype && 'startsWith' in String.prototype && 'endsWith' in String.prototype && 'includes' in String.prototype && 'includes' in Array.prototype && 'assign' in Object && 'entries' in Object && 'keys' in Object ) { render(); } else { import('./polyfills').then(render); } 

, , , — . — render() . , Webpack npm-, , render() .

, import() Babel dynamic-import . , Webpack, import() , .

, . .

▍ React,

. , , , .

, npm- . , , 100 .

, , URL /admin , <AdminPage> . Webpack , import AdminPage from './AdminPage.js' .

. , , import('./AdminPage.js') , Webpack , .

, .

, , AdminPage , , URL /admin . , :

 import React from 'react'; class AdminPageLoader extends React.PureComponent { constructor(props) {   super(props);   this.state = {     AdminPage: null,   } } componentDidMount() {   import('./AdminPage').then(module => {     this.setState({ AdminPage: module.default });   }); } render() {   const { AdminPage } = this.state;   return AdminPage     ? <AdminPage {...this.props} />     : <div>Loading...</div>; } } export default AdminPageLoader; 

. (, URL /admin ), ./AdminPage.js , .

render() , <AdminPage> , <div>Loading...</div> , <AdminPage> , .

, react-loadable , React .

परिणाम

, , (, , CSS). :

• — .
• , — .

प्रिय पाठकों! ?