2012-03-04 18 views
32

मैंने पहले similar question से पूछा है, लेकिन मैंने कभी भी अपना मुद्दा बिल्कुल स्पष्ट नहीं किया है, या कम से कम मुझे लगता है कि यह एक प्रासंगिक सवाल है कि इसे लाने और यह देखने के लायक है कि कोई भी कुछ अंतर्दृष्टिपूर्ण विचार दे सकता है या नहीं।jQuery क्यों है। यह इतनी धीमी गति से अनुशंसित है?

jQuery का उपयोग करते समय, हम में से कई jQuery.ready फ़ंक्शन का उपयोग init निष्पादित करने के लिए करते हैं जब डोम लोड हो जाता है। यह jQuery का उपयोग कर वेब पेज पर डीओएम मैनिपुलेशन प्रोग्राम जोड़ने का डी-फैक्टो मानक तरीका बन गया है। एक संबंधित घटना natively कुछ ब्राउज़र मौजूद है, लेकिन jQuery अन्य आईई संस्करणों जैसे अन्य ब्राउज़रों में इसे अनुकरण करता है। उदाहरण:

<head> 
<script> 
    var init = function() { alert('hello world'); }; 
    $.ready(init); 
</script> 

अब, हमारे सभी परीक्षण दिखाते हैं कि यह घटना काफी धीमी हो सकती है। यह window.onload जितना धीमा नहीं है, लेकिन यह अभी भी निष्पादन से पहले लगभग 100 एमएस देरी है। यदि एफएफ 200-300 एमएस तक हो सकता है, खासकर रीफ्रेश पर।

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

<head> 
<script> 
    var init = function() { alert('hello world'); }; 
</script> 
</head> 
<body> 
<!-- some HTML --> 
<script>init();</script> 
</body> 

एक साधारण परीक्षण पेज:

अब अगर हम यह भी शरीर टैग को बंद करने से पहले एक स्क्रिप्ट टैग में एक init समारोह जगह है, यह बहुत तेजी से, आमतौर पर लगभग आधा समय है लेकिन कभी कभी भी तेजी से निष्पादित किया जाएगा जो मतभेद साबित करता है: http://jsbin.com/aqifon/10

मेरा मतलब है, हम मुश्किल चयनकर्ताओं के बारे में बात नहीं कर रहे हैं क्योंकि कुछ "अनुकूलन पुलिस" प्रभावी चयनकर्ताओं का उपयोग करने के लिए प्रोत्साहित करते हैं। हम कुछ प्रमुख देरी के बारे में बात कर रहे हैं जब डोम मैनिपुलेशन ऑनलोड करते हैं। एफएफ में इस उदाहरण को आजमाकर, डोमरेडी कभी-कभी 100 गुना धीमी (300ms बनाम 2ms) से अधिक हो सकती है।

अब मेरे प्रश्न पर:jQuery.ready का उपयोग करने की अनुशंसा क्यों की जाती है जब यह स्पष्ट रूप से अन्य विकल्पों को धीमा कर देता है? और jQuery.ready का उपयोग कर बॉडी बनाम बंद करने से पहले init पर कॉल करने की क्या कमी है? यह domReady का उपयोग करने के लिए तर्कसंगत रूप से अधिक "सुरक्षित" है, लेकिन दूसरे संदर्भ की तुलना में यह किस संदर्भ में अधिक सुरक्षित है? (मैं document.write और स्थगित स्क्रिप्ट जैसे सामान सोच रहा हूं) हमने कई क्लाइंट साइटों पर लगभग 5 वर्षों के लिए BODY तरीके का उपयोग किया है, और हम कभी भी किसी भी समस्या में भाग नहीं लेते हैं। यह बहुत तेज़ है।

मैं भी सोच रहा हूं, क्योंकि जेएसपीरफ़ के बारे में बहुत अधिक फ़ज़ है और प्रति 10000 निष्पादन के कुछ एमएस के लिए चयनकर्ताओं को अनुकूलित करने के लिए, इस बारे में ज्यादा बात नहीं है? यह मूल रूप से उपयोगकर्ता के सामने पहली देरी है, और यह प्रत्येक पृष्ठ लोड पर 50-100 एमएस टुकड़ा करने के लिए काफी सरल लगता है ...

उत्तर

8

पहला बिंदु करने के लिए:

नहीं, <body> बंद करने से पहले आप init बुला में कोई नुकसान है। जैसा कि आपने देखा है कि $.ready() पर निर्भर करता है और यह सभी ब्राउज़रों के साथ भी काम करेगा (यहां तक ​​कि आईई पर भी)।

  1. $.ready() यह आसान डेवलपर्स सही क्रम में सामान करने के लिए बनाता है:

    अब, वहाँ तथापि कारणों $.ready() है, जो अपने मामले में वे शायद लागू नहीं है का उपयोग कर रहे हैं। विशेष रूप से, महत्वपूर्ण बात यह है कि डीओएम तत्वों को संदर्भित नहीं करना है जिन्हें लोड नहीं किया गया है। हालांकि यह काफी आसान है, कई डेवलपर्स अभी भी इसे भ्रमित कर रहे हैं। $.ready() एक धीमी गति के बावजूद कोई ब्रेनर नहीं है।

  2. आप में कई स्क्रिप्ट्स हैं जिन्हें init() की आवश्यकता है, यह आपके शरीर के अंत में मैन्युअल रूप से के लिए आसान/सुविधाजनक नहीं है। इन अनुच्छेदों के बारे में अनुशासन और ज्ञान की आवश्यकता है। विशेष रूप से आप अक्सर jQuery पर निर्भर पुस्तकालयों में $.ready() देखेंगे, क्योंकि यह चीजों को काम करता है इससे कोई फर्क नहीं पड़ता कि डेवलपर्स libs को लोड करने के लिए किस तरह उपयोग करेंगे।
  3. असीमित मॉड्यूल परिभाषा के साथ (उदाहरण के लिए require.js) अपने जावास्क्रिप्ट को लोड करने के तरीके के रूप में लोकप्रिय हो रहा है, <body/> विधि का अंत गारंटी नहीं है।
6

एक फायदा यह होगा कि आप पृष्ठ में कहीं भी कोड डाल सकते हैं । हमारे मामले में, हम अपने सीएमएस में एक टेम्पलेटिंग सिस्टम का उपयोग करते हैं जो पृष्ठ को अलग-अलग हिस्सों (जटिलता के आधार पर) के लिए लगभग 10 - 30 टेम्पलेट्स से एक साथ जोड़ता है।

चूंकि आप चाहते हैं कि टेम्पलेट्स किसी भी पेज पर काम करने के लिए उपयोग करें, आपको इसमें आवश्यक जावास्क्रिप्ट शामिल करने की आवश्यकता है। उन मामलों के लिए, ready() फ़ंक्शन एक वास्तविक जीवन बचतकर्ता है।

+3

हाँ, इस तर्क को 'सुविधा' लेबल किया जा सकता है और यह काफी उचित है। आप शायद अपने टेम्पलेट सिलाई के अंत में jQuery.ready बाइंडिंग को ट्रिगर कर सकते हैं ... – David

2

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

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

आपने संभावित अपवाद के रूप में document.write() का उल्लेख किया है, लेकिन आप दस्तावेज़ से पहले या शरीर के अंत में इसे कॉल नहीं करना चाहते हैं क्योंकि किसी भी तरह से पूरा पृष्ठ पहले ही पार्स कर दिया गया है।

+0

बस स्पष्ट होने के लिए: मैं दस्तावेज़ के अंत में स्क्रिप्ट डालने के बारे में बात नहीं कर रहा हूं (जैसे याहू प्रचार करता है), मैं बात कर रहा हूं शरीर को बंद करने से पहले स्क्रिप्ट के प्रारंभिकरण के बारे में (हालांकि पूरे ओवरलोड समस्या मूल रूप से चली जाती है यदि आप दस्तावेज़ के अंत में अपनी स्क्रिप्ट भी डालते हैं)। – David

0

क्योंकि यह domReady और window.load धीमा बनाता है।

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

संबंधित मुद्दे