मुझे इनलाइन बनाम बाहरी जावास्क्रिप्ट का उपयोग कब करना चाहिए?


129

मैं जानना चाहूंगा कि मुझे बाहरी स्क्रिप्ट को कब शामिल करना चाहिए या प्रदर्शन और रखरखाव में आसानी के मामले में उन्हें html कोड के साथ इनलाइन लिखना चाहिए।

इसके लिए सामान्य अभ्यास क्या है?

वास्तविक-विश्व-परिदृश्य - मेरे पास कई html पृष्ठ हैं, जिन्हें क्लाइंट-साइड फ़ॉर्म सत्यापन की आवश्यकता है। इसके लिए मैं एक jQuery प्लगइन का उपयोग करता हूं जिसे मैं इन सभी पृष्ठों पर शामिल करता हूं। लेकिन सवाल यह है कि क्या मैं:

  • कोड के बिट्स लिखें जो इस स्क्रिप्ट इनलाइन को कॉन्फ़िगर करते हैं?
  • एक फ़ाइल में सभी बिट्स को शामिल करें जो इन सभी HTML पृष्ठों के बीच है?
  • एक अलग बाहरी फ़ाइल में प्रत्येक को शामिल करें, प्रत्येक HTML पृष्ठ के लिए?

धन्यवाद।

जवाबों:


114

जिस समय यह उत्तर मूल रूप से पोस्ट किया गया था (2008), नियम सरल था: सभी स्क्रिप्ट बाहरी होनी चाहिए। रखरखाव और प्रदर्शन दोनों के लिए।

(प्रदर्शन क्यों? क्योंकि यदि कोड अलग है, तो इसे ब्राउज़रों द्वारा आसानी से कैश किया जा सकता है।)

जावास्क्रिप्ट एचटीएमएल कोड में नहीं है और यदि इसमें विशेष अक्षर (जैसे ) हैं <, तो >यह समस्याएँ भी पैदा करता है।

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


6
@ निक: ज्यादातर समस्याओं को दूर किया जा सकता है। बेहतर है कि उन्हें पहली बार में उत्पन्न न किया जाए।
कोनराड रुडोल्फ

17
कभी-कभी आपको इनलाइन करते समय बेहतर प्रदर्शन मिलता है। Google.com के स्रोत को देखें । वे जानते हैं कि वे क्या कर रहे हैं।
कॉलम

13
@callum Google का 99.999999% वेबसाइटों से अलग उपयोग का मामला है। बेशक वे बेहद सावधानी से और यहां तक ​​कि सबसे छोटे अंतर को मापते हैं। लेकिन सिर्फ इसलिए कि उन्होंने पाया कि उनके विशेष उपयोग के मामले में, इनलाइनिंग बेहतर काम करती है (शायद इसलिए कि स्क्रिप्ट बहुत बार बदलती है;) इसका मतलब यह नहीं है कि हम उससे एक सामान्य नियम प्राप्त कर सकते हैं, या यहां तक ​​कि हमें "पारंपरिक" की अवहेलना करनी चाहिए। नियम (स्क्रिप्ट को बाहरी बनाने के लिए)।
कोनराड रुडोल्फ

8
@KonradRudolph - सहमत, कोई भी सामान्य नियम Google के दृष्टिकोण से प्राप्त नहीं किया जाना चाहिए। मैं सिर्फ यह कह रहा हूं कि यह संकेत है कि यह आपके जवाब में नियम पर सवाल उठाने के लायक हो सकता है । वैसे भी, मुझे लगता है कि इसका कारण यह है कि Google HTTP अनुरोधों को कम करता है, और इससे 0.000001% से अधिक साइटों को लाभ हो सकता है। बैंडविड्थ अधिक हो रही है लेकिन गोल यात्रा के समय समान हैं। पूरे सीरियल HTTP रिक्वेस्ट को हटाना कभी-कभी बाहरी जेएस के कैशिंग लाभ से बेहतर होता है। आपके जेएस के पाठ्यक्रम के आकार पर निर्भर करता है।
कॉलम

5
@callum हालांकि यह सच है, कैशिंग के बारे में बात अभी भी बनी हुई है और महत्वपूर्ण है। राउंडट्रिप्स को कम करना केवल तभी महत्वपूर्ण है जब आपके आगंतुक वापस नहीं आते (और फिर आपको इसे बनाने के लिए पर्याप्त पृष्ठ हिट नहीं मिलेगा) या यदि आपकी सामग्री इतनी बार बदलती है कि स्क्रिप्ट फ़ाइलों को कैशिंग करने से कोई लाभ नहीं है।
कोनराड रूडोल्फ

31

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

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


5
यह मेरी चिंताओं में से एक है। कोड की कुछ पंक्तियों के लिए एक अलग HTTP अनुरोध होने से यह बेकार लगता है।
Dan Burzo

आप शायद अपने कोड के लिए एक नमूना विन्यास पोस्ट कर सकते हैं? IMO यदि यह 300 वर्णों के अंतर्गत है और बिल्कुल पृष्ठ-विशिष्ट है, तो इसे इनलाइन करें
होर्स्ट गुटमैन

यह शीर्ष उत्तर imo
sgarcia.dev

@ ध्यान रखें कि अलग अनुरोध केवल पहली बार होता है। यदि आप अपने उपयोगकर्ताओं को पृष्ठ को एक से अधिक बार लोड करने की उम्मीद करते हैं, तो बाहरी (कुछ पंक्तियों के लिए भी) स्पष्ट रूप से n = 2 + पृष्ठ लोड के तार पर उन कुछ पंक्तियों के लिए बाइट्स की प्रतीक्षा करने की तुलना में तेज़ है।
जिंगलेथुला

@HorstGutmann कैसे बनाए रखने के साथ फ़ाइल बाहरी सहायता करता है? जब भी संभव हो मैं व्यक्तिगत रूप से बाहरी जेएस को पसंद करता हूं, लेकिन क्या कुछ उद्देश्य है जो इसे बनाए रखना आसान बनाता है?
jinglesthula

21

जावास्क्रिप्ट प्रदर्शन वाह्य नियमों में से एक है: http://developer.yahoo.com/performance/rules.html#external

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


1
मुझे लगता है कि याहू सभी जावास्क्रिप्ट को एक HTTP कॉल में जोड़ने की भी सलाह देता है - इसका मतलब यह नहीं है कि स्क्रिप्ट सभी को विकास के दौरान एक ही फाइल में होना चाहिए
पॉल शैनन

इसके अलावा, जैसा कि ऊपर उल्लेख किया गया है, HTTP / 2 "1 कॉल" अभ्यास को भी बदलता है।
jinglesthula

19

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

सर्वश्रेष्ठ प्रदर्शन पाने के लिए, आपको पृष्ठों को दो-चरण वाले रॉकेट के रूप में सोचना होगा। ये दो चरण मोटे तौर पर <head>और <body>चरणों के अनुरूप हैं, लेकिन इनकी बजाय <static>और के रूप में सोचते हैं <dynamic>। स्थैतिक भाग मूल रूप से एक स्ट्रिंग स्थिरांक है जो आप प्रतिक्रिया पाइप को जितना संभव हो उतना तेजी से नीचे धकेलते हैं। यह थोड़ा मुश्किल हो सकता है यदि आप कुकीज़ को सेट करने वाले बहुत सारे मिडलवेयर का उपयोग करते हैं (इनको http सामग्री भेजने से पहले सेट करने की आवश्यकता होती है), लेकिन सिद्धांत रूप में यह प्रतिक्रिया बफर को फ्लश कर रहा है, उम्मीद है कि कुछ टेम्प्लेटिंग कोड (रेजर, php, ph) में कूदने से पहले आदि) सर्वर पर। यह मुश्किल लग सकता है, लेकिन फिर मैं इसे गलत समझा रहा हूं, क्योंकि यह तुच्छ के पास है। जैसा कि आप अनुमान लगा सकते हैं, इस स्थिर हिस्से में सभी जावास्क्रिप्ट सम्मिलित और इनवॉइस होने चाहिए। यह कुछ इस तरह दिखेगा

<!DOCTYPE html>
     <html>
         <head>
             <script>/*...inlined jquery, angular, your code*/</script>
             <style>/* ditto css */</style>
         </head>
         <body>
             <!-- inline all your templates, if applicable -->
             <script type='template-mime' id='1'></script>
             <script type='template-mime' id='2'></script>
             <script type='template-mime' id='3'></script>

चूँकि इस हिस्से को तार के नीचे भेजने के लिए आपके बगल में कुछ भी खर्च नहीं होता है, आप उम्मीद कर सकते हैं कि क्लाइंट को आपके सर्वर से कनेक्ट होने के बाद यह लगभग 5ms + लेटेंसी के आसपास मिलना शुरू हो जाएगा। मान लिया जाए कि सर्वर यथोचित रूप से बंद है यह विलंबता 20ms से 60ms के बीच हो सकती है। ब्राउजर मिलते ही इस सेक्शन को प्रोसेस करना शुरू कर देगा और प्रोसेसिंग टाइम आमतौर पर फैक्टर 20 या उससे अधिक के ट्रांसफर टाइम पर हावी हो जाएगा, जो कि अब आपके <dynamic>हिस्से के सर्वर-साइड प्रोसेसिंग के लिए एमॉर्टाइज्ड विंडो है ।

ब्राउज़र के लिए लगभग 50ms लगते हैं (क्रोम, बाकी शायद 20% धीमी) इनलाइन jquery + सिग्नलर + कोणीय + एनजी + चेतन + एनजी टच + एनजी मार्गों + लॉश को संसाधित करने के लिए। यह अपने आप में बहुत अद्भुत है। अधिकांश वेब ऐप में उन सभी लोकप्रिय पुस्तकालयों की तुलना में कम कोड होते हैं, लेकिन मान लें कि आपके पास बस उतना ही है, इसलिए हम क्लाइंट पर विलंबता + 100ms प्रसंस्करण जीतेंगे (यह विलंबता जीत दूसरे ट्रांसफर चंक से आती है)। जब तक दूसरा हिस्सा आता है, हमने सभी js कोड और टेम्प्लेट संसाधित कर लिए हैं और हम डोम ट्रांसफॉर्म को निष्पादित करना शुरू कर सकते हैं।

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

मैं एसपीए ऐप्स के अनुकूलन के साथ बहुत काम करता हूं। लोगों के लिए यह सोचना आम है कि डेटा वॉल्यूम एक बड़ी बात है, जबकि सत्यता में, और निष्पादन अक्सर हावी होता है। जिन सूचीबद्ध पुस्तकालयों को मैंने सूचीबद्ध किया है उनमें 300kb तक का डेटा है, और यह सिर्फ 68 kb gzipped है, या 200 मी 2 मी 3 जी / 4 जी फोन पर डाउनलोड होता है, जो बिल्कुल विलंबता है कि यह एक ही फोन पर ले जाएगा यदि यह जांचने के लिए कि क्या समान डेटा था इसके कैश में पहले से ही, भले ही यह प्रॉक्सी कैश किया गया हो, क्योंकि मोबाइल विलंबता कर (फोन-टू-टॉवर-विलंबता) अभी भी लागू होता है। इस बीच, डेस्कटॉप कनेक्शन जिनके पास पहले-पहले विलंबता कम होती है, उनमें आमतौर पर उच्च बैंडविड्थ होता है।

संक्षेप में, अभी (2014), यह सभी लिपियों, शैलियों और टेम्पलेट्स को इनलाइन करने के लिए सबसे अच्छा है।

EDIT (MAY 2016)

जेएस अनुप्रयोगों के बढ़ने के लिए जारी है, और मेरे कुछ पेलोड अब 3+ मेगाबाइट की न्यूनतम कोड तक ढेर हो गए हैं, यह स्पष्ट हो रहा है कि बहुत कम से कम सामान्य पुस्तकालयों में अब इनलेट नहीं होना चाहिए।


मुझे वह नहीं मिला जो अब <गतिशील> भाग भाग के सर्वर-साइड प्रसंस्करण के लिए आपकी amortized विंडो है - सर्वर कभी भी इसकी आवश्यकता होती है जो प्रक्रिया करता है और उसके बाद पूरे प्रदान किए गए html (सिर + शरीर), क्या अन्य सर्वर प्रसंस्करण कार्य करता है उसके बाद की जरूरत है?
बोर्नटूकोड

@BornToCode क्लाइंट को कुछ करने के लिए एक ही समय में सर्वर साइड में कुछ करने का विचार है। क्योंकि क्लाइंट लाइब्रेरीज़ की व्याख्या करने की आवश्यकता है - सर्वर पर किसी भी गणना करने से पहले उस प्रक्रिया को शुरू करना बेहतर है । परिशोधन विंडो जेएस को संसाधित करने में क्लाइंट को समय लगता है। आपको वह खिड़की मुफ्त में मिलती है, अगर आप 2-चरण वाले रॉकेट की परिक्रमा करते हैं।
ग्लोनो


9

वास्तव में, इनलाइन जावास्क्रिप्ट का उपयोग करने के लिए एक बहुत ही ठोस मामला है। यदि js काफी छोटा है (एक-लाइनर), तो मैं दो कारकों के कारण जावास्क्रिप्ट इनलाइन को प्राथमिकता देता हूं:

  • स्थानीयता । कुछ जावास्क्रिप्ट के व्यवहार को मान्य करने के लिए बाहरी फ़ाइल को नेविगेट करने की कोई आवश्यकता नहीं है
  • AJAX । यदि आप AJAX के माध्यम से पृष्ठ के कुछ खंड को ताज़ा कर रहे हैं, तो आप उस अनुभाग के लिए अपने सभी DOM हैंडलर्स (onclick, आदि) खो सकते हैं , यह इस बात पर निर्भर करता है कि आपने उन्हें कैसे बांधा है। उदाहरण के लिए, jQueryआप का उपयोग करके liveया तो delegateइसे दरकिनार करने के लिए या विधियों का उपयोग किया जा सकता है , लेकिन मुझे लगता है कि अगर js काफी छोटा है तो इसे केवल इनलाइन लगाना बेहतर है।

5

सामग्री सुरक्षा नीति (CSP) में आसानी से परिवर्तन के लिए आपको बाहरी स्क्रिप्ट का उपयोग करने का एक और कारण होना चाहिए । CSP डिफॉल्ट्स को सभी इनलाइन स्क्रिप्ट के लिए मना करती है, जिससे आपकी साइट XSS हमलों के लिए अधिक प्रतिरोधी हो जाती है।


4

मैं आवश्यक कोड पर एक नज़र डालूँगा और इसे आवश्यकतानुसार कई अलग-अलग फ़ाइलों में विभाजित करूँगा। प्रत्येक js फ़ाइल केवल फ़ंक्शन आदि जैसे एक "तार्किक सेट" को धारण करेगी। सभी संबंधित कार्यों के लिए एक फ़ाइल।

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


4

इनलाइन javascipt के लिए केवल एक ही बचाव की पेशकश की जा सकती है कि .net MVC के साथ दृढ़ता से टाइप किए गए विचारों का उपयोग करते समय आप c # चर मध्य जावास्क्रिप्ट को संदर्भित कर सकते हैं जो मैंने उपयोगी पाया है।


3

तीन विचार:

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

2

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


2

जावास्क्रिप्ट बाहरी रखने के बिंदु पर:

ASP.NET 3.5SP1 ने हाल ही में एक समग्र स्क्रिप्ट संसाधन बनाने के लिए कार्यक्षमता पेश की (एक में js फ़ाइलों का एक गुच्छा मर्ज करें)। इसका एक और लाभ यह है कि जब वेबसर्वर कम्प्रेशन चालू होता है, तो किसी एक बड़ी फ़ाइल को डाउनलोड करने से बेहतर कम्प्रेशन रेश्यो होगा, फिर कई छोटी फाइलें (साथ ही कम http ओवरहेड, राउंडट्रिप आदि ...)। मुझे लगता है कि यह प्रारंभिक पृष्ठ लोड पर सहेजता है, फिर ऊपर बताए अनुसार ब्राउज़र कैशिंग किक करता है।

ASP.NET एक तरफ, यह पेंचकस अधिक विस्तार से लाभ की व्याख्या करता है: http://www.asp.net/learn/3.5-SP1/video-296.aspx


2

बाहरी लिपियों का एक और छिपा हुआ लाभ यह है कि आप उन्हें आसानी से jslint जैसे सिंटैक्स चेकर के माध्यम से चला सकते हैं । यह आपको बहुत दिल टूटने, मुश्किल से खोजने, IE6 बग से बचा सकता है।


1

आपके परिदृश्य में ऐसा लगता है कि पृष्ठों के बीच साझा की गई एक फ़ाइल में बाहरी सामान लिखना आपके लिए अच्छा होगा। मैं ऊपर कही गई हर बात से सहमत हूं।


1

शुरुआती प्रोटोटाइप के दौरान, तेज पुनरावृत्ति के लाभ के लिए अपने कोड को इनलाइन रखें, लेकिन जब तक आप उत्पादन तक नहीं पहुंच जाते, तब तक इसे सभी बाहरी बनाना सुनिश्चित करें।

मैं यह कहने का साहस भी कर सकता हूं कि यदि आप अपने सभी जावास्क्रिप्ट को बाहरी रूप से नहीं रख सकते हैं, तो आपके हाथों के नीचे एक खराब डिजाइन है, और आपको अपने डेटा और स्क्रिप्ट को फिर से भरना चाहिए।


1

Google ने इसे पृष्ठ रैंकिंग मापों में लोड समय शामिल किया है, यदि आप बहुत अधिक इनलाइन करते हैं, तो मकड़ियों को आपके पृष्ठ को क्रॉल करने में अधिक समय लगेगा, यह आपकी पृष्ठ रैंकिंग को प्रभावित कर सकता है यदि आपको बहुत अधिक शामिल करना है। किसी भी स्थिति में विभिन्न रणनीतियों का आपकी रैंकिंग पर प्रभाव पड़ सकता है।


1

अच्छी तरह से मुझे लगता है कि आपको सिंगल पेज वेबसाइट बनाते समय इनलाइन का उपयोग करना चाहिए क्योंकि स्क्रिप्ट को कई पेजों पर साझा करने की आवश्यकता नहीं होगी


-3

हमेशा बाहरी Js का उपयोग करने की कोशिश करें क्योंकि इनलाइन js को बनाए रखना हमेशा मुश्किल होता है।

इसके अलावा, यह पेशेवर रूप से आवश्यक है कि आप बाहरी js का उपयोग करें क्योंकि अधिकांश डेवलपर बाहरी रूप से js का उपयोग करने की सलाह देते हैं।

मैं खुद बाहरी जेएस का उपयोग करता हूं।


2
व्यावसायिक रूप से आवश्यक? क्यों? कौन कहता है?
सियाह
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.