वर्तमान में हम Google CDN से jQuery और jQueryUI (और jQueryUI CSS) पुस्तकालयों को खींच रहे हैं। मुझे यह पसंद है क्योंकि मैं कॉल कर सकता हूं google.load("jquery", "1");
और नवीनतम jQuery 1.xx का उपयोग किया जाएगा।
अब मुझे सुरक्षा के कारण स्थानीय स्तर पर पुस्तकालयों को खींचना है।
मुझे उन्हें स्थानीय रूप से खींचने में खुशी हो रही है लेकिन मैं सोच रहा हूं कि बाहर देखने के कुछ अन्य लाभ और नुकसान क्या हैं?
जवाबों:
सीडीएन पर उनके होने का मुख्य लाभ यह है कि फाइलों को आपकी स्वयं की वेबसाइट से डाउनलोड की गई फाइलों के समानांतर डाउनलोड किया जा सकता है। यह हर पृष्ठ पर विलंबता को कम करता है। तो, इसका दूसरा पहलू स्थानीय स्तर पर बढ़ाई गई विलंबता है । इसका मुख्य कारण यह है कि ब्राउज़र उन कनेक्शनों की संख्या में सीमित हैं जो वे एक ही समय में एक ही वेब डोमेन पर बना सकते हैं। IE6 में यह एक ही डोमेन के 2 समवर्ती कनेक्शन के लिए डिफ़ॉल्ट था - IE की सभी खुली खिड़कियों के बीच साझा किया गया !! IE8 + में यह सुधार हुआ, 6 के लिए डिफ़ॉल्ट, जो एफएफ / क्रोम के साथ इनलाइन है, लेकिन फिर भी, यदि आपके पास बहुत सारी छवियां हैं और आप स्प्राइट का उपयोग नहीं कर रहे हैं, तो आप भारी विलंबता का अनुभव करेंगे।
CDN का उपयोग करके, मैं हमेशा नवीनतम संस्करण प्राप्त करने के बजाय लाइब्रेरी संस्करण को स्पष्ट रूप से सेट करूँगा । यह आपके कोड को तोड़ने वाले नए संस्करणों के जोखिम को कम करता है। JQuery के साथ बहुत संभव नहीं है, लेकिन संभव है।
सीडीएन का उपयोग करने का अन्य मुख्य लाभ आपकी साइट पर ट्रैफ़िक कम हो गया है । यदि आप प्रति जीबी का भुगतान करते हैं या आप सीमित संसाधनों के साथ एक वर्चुअल सर्वर पर हैं, तो आप पा सकते हैं कि समग्र सामग्री का प्रदर्शन बढ़ जाता है और जब आप किसी सार्वजनिक सीडीएन से अपनी कुछ सामग्री निकालते हैं तो होस्टिंग लागत में कमी आती है।
सुनिश्चित करें कि आप @Xaver द्वारा इस प्रश्न का अन्य उत्तर भी पढ़ें। यह बहुत अच्छी ट्रिक है
मैं हमेशा Google से CDN (सामग्री वितरण नेटवर्क) का उपयोग करता हूं। लेकिन सिर्फ मामले में यह ऑफ़लाइन है:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>!window.jQuery && document.write('<script src="jquery-1.4.2.min.js"><\/script>')</script>
यदि आवश्यक हो तो Google CDN का jQuery और स्थानीय में कमबैक करें
संपादित करें : यदि आपको IE6 का समर्थन करने की आवश्यकता नहीं है और आपकी साइट में आंशिक https उपयोग है तो आप http को भी हटा सकते हैं:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
!window.jQuery...) की व्याख्या करने से पहले व्याख्या की जाएगी? <script>टैग को अतुल्यकालिक रूप से संसाधित किया जाता है, है ना?
<script>टैग को समकालिक रूप से संसाधित किया जाता है! दूसरी पंक्ति पर jQuery पहले से ही लोड होना चाहिए, लेकिन अगर हम इसे स्थानीय रूप से लोड करने के लिए कुछ JS इंजेक्षन नहीं करते हैं तो बस। document.writeअगर jQuery पहले से मौजूद है क्रियान्वित किया जा कभी नहीं होगा।
दूसरों ने लाभ को कवर किया है। नुकसान:
यदि आप केवल अपने स्वयं के सर्वर से सामग्री शामिल करते हैं, तो वह एक सर्वर है जिसे चलाने के लिए आवश्यक है- और फ़ायरवॉल द्वारा अवरुद्ध नहीं किया जाता है- जैसे कि आपकी साइट को काम करने के लिए। किसी थर्ड पार्टी से स्क्रिप्ट खींचें और अब वह दो सर्वर हैं जिन्हें आपकी साइट पर काम करने के लिए चलाने और अनब्लॉक करने की आवश्यकता है।
आपके द्वारा खींची <script>गई कोई भी साइट आपकी साइट पर उपयोगकर्ता के अनुभव को पूरी तरह से नियंत्रित कर सकती है। यदि Google बुराई महसूस कर रहा था, तो वे आपके keypresses में प्रवेश करने के लिए jQuery की अपनी कॉपी में कुछ डाल सकते थे, उस पेज से व्यक्तिगत जानकारी चुरा सकते थे जिस पर आप उनके वेब ट्रैकिंग डेटाबेस में टाई करते हैं, आपको "I love Google!" हर रूप, और इसी तरह की टिप्पणियाँ।
Google शायद ऐसा करने वाला नहीं है, लेकिन यह एक ऐसा कारक है जो आपके नियंत्रण से बाहर है, और निश्चित रूप से अन्य स्क्रिप्ट-होस्टिंग सेवाओं के बारे में चिंता करने के लिए कुछ है। मालवेयर लोडर्स के साथ आँकड़े स्क्रिप्ट के साथ छेड़छाड़ किए जाने से पहले की घटनाएं हुई हैं।
तीसरे पक्ष की किसी भी स्क्रिप्ट को शामिल करने से पहले - आपकी साइट के एक पृष्ठ पर भी- आपको उस होस्टनाम पर दिखाई देने वाली सभी उपयोगकर्ता-सुलभ कार्यक्षमता (वेब-फ़ेसिंग व्यवस्थापक कार्यों सहित) पर 100% भरोसा करना चाहिए।
Google CDN:
स्थानीय रूप से:
if a new version breaks your existing plugins or site, you'll know about it possibly too lateआप सीडीएन लिंक में संस्करण को निर्दिष्ट कर सकते हैं, जिससे बचने के लिए।
लाभ: (विशेष रूप से Google की CDN के लिए)
वस्तुतः हर तरह से आप इसे देखते हैं, Google की सीडीएन का उपयोग करना अच्छी बात है।
प्रदर्शन में सुधार किया जाएगा (यद्यपि आपकी साइट वास्तव में व्यस्त है), और आपके सर्वरों को प्रसारित करने के लिए डेटा की मात्रा कम हो जाएगी (हालांकि jQuery डाउनलोड करने के लिए एक बड़े पैमाने पर नहीं है), आदि।
यदि आप Google पर भरोसा नहीं करते हैं तो इसका एकमात्र कारण आप इसका उपयोग नहीं करना चाहेंगे। इसका उपयोग करके, आप Google को आपकी साइट की ट्रैफ़िक प्रोफ़ाइल में जानकारी की एक अतिरिक्त विंडो दे रहे हैं, जिसमें उन URL का ज्ञान भी शामिल है जिन्हें आप अन्यथा सार्वजनिक नहीं कर सकते हैं (जैसे आपकी साइट के सुरक्षित क्षेत्र)।
यदि आप सुरक्षा के बारे में पागल हैं तो यह आपको उन्हें इस्तेमाल न करने के लिए राजी करने के लिए पर्याप्त हो सकता है (आखिरकार, इसे स्वयं होस्ट करना आपकी साइट को क्रॉल करने के लिए बिल्कुल धीमा नहीं करने वाला है), लेकिन सामान्य तौर पर अधिकांश लोग व्यावहारिक दृष्टिकोण को देखते हैं Google को अपनी साइट के बारे में पहले से ही पता है कि इसे जोड़ने से बहुत फर्क नहीं पड़ेगा।
संभवतः मैं आजकल अल्पमत में हूं, लेकिन मैं कहूंगा कि आप CDN का उपयोग नहीं करना चाहते हैं जब तक कि आपको वास्तव में आवश्यकता न हो। इसका उपयोग शुरू करने के लिए महत्वपूर्ण कारक हैं:
लेकिन ... मुद्दा यह है कि ये बिंदु वास्तव में दुनिया की 90% वेबसाइटों पर लागू नहीं हैं। मुझे यकीन है कि आप दुनिया भर के लाखों ऑनलाइन उपयोगकर्ताओं के साथ फेसबुक नहीं हैं, आप पोर्नहब नहीं हैं जिसमें सैकड़ों जीबी प्रति सेकंड ट्रांसफर किए जाते हैं।
यदि आपकी वेबसाइट आपके शहर / देश के उपयोगकर्ताओं को लक्षित है और आपके पास मौजूद उपयोगकर्ताओं के लिए एक सर्वर की क्षमता पर्याप्त है - तो आप कभी भी CDN क्यों चाहते हैं? यह आपके शहर में आपके उपयोगकर्ताओं के लिए और स्थानीय स्तर पर आपके मुख्य सर्वर से सब कुछ लाने के लिए सरल है।
यह सामान्य रूप से सीडीएन के बारे में अधिक था, अब मुझे jQuery या किसी अन्य पुस्तकालय के बारे में वास्तविक प्रश्न के करीब होने दें।
यदि आप चाहते हैं कि आपकी वेबसाइट एक वर्ष से अधिक समय तक रखरखाव के बिना सुलभ और काम पर रहे, तो हम कहते हैं - इसे स्थानीय स्तर पर रखें। आजकल लाइब्रेरियों को एक पागल टेम्पो में अपडेट किया जा रहा है जिसे आप शायद फॉलो नहीं करना चाहते हैं। और पुराने संस्करणों को अंततः हटा दिया जा रहा है। इसके अलावा, पूरी लाइब्रेरी मर सकती है (शायद jQuery के लिए लागू नहीं है)।
मेरे हाल के अनुभव से - मैंने TinyMCE को उस वेबसाइट पर अपडेट किया जिसे मैं 3.xx (दिनांक 2012) से 5.xx (दिनांकित स्प्रिंग 2019) तक बनाए रखता हूं। यह वेबसाइट तर्क के इस हिस्से में बिना किसी रखरखाव के 7 (सात!) वर्षों के लिए काम कर रही थी। तब कोई "मिनिमाइजिंग" कॉन्सेप्ट वापस नहीं आया था और सीडीएन अब आम नहीं थे। लेकिन भले ही वे आम होंगे - आप कभी नहीं जानते कि अब से 3-5-10 वर्षों में क्या होगा। आमतौर पर आप चाहते हैं कि आपकी वेबसाइट बिना इसे बनाए रखते हुए भी जिंदा रहे, क्या आप नहीं? हालाँकि अगर आप आज सीडीएन से jQuery खींचते हैं, तो यह लिंक 5 साल में टूट सकता है (और, शायद, होगा)।
CDN और स्थानीय संस्करण के साथ समाधान के रूप में @Xaver ने सुझाव दिया कि एक अच्छा समझौता हो सकता है। लेकिन ... शायद सीडीएन लिंक से छुटकारा मिल जाए? ;)