होस्ट की गई स्क्रिप्ट के पेशेवरों और विपक्षों [बंद]


12

मैंने देखा है कि कुछ डेवलपर्स अपने पुस्तकालयों को जोड़ने के लिए होस्टेड स्क्रिप्ट का उपयोग करते हैं।

cdn.jquerytools.org एक उदाहरण है।

मैंने लोगों को यह भी देखा है कि एक होस्टेड स्क्रिप्ट लिंक को हाईजैक कर लिया गया है।

वास्तविकता में होस्ट की गई स्क्रिप्ट का उपयोग करना कितना सुरक्षित है? क्या स्क्रिप्ट स्वचालित रूप से अपडेट की जाती हैं? उदाहरण के लिए, यदि jQuery 5 6 में जाता है तो क्या मुझे स्वचालित रूप से संस्करण 6 मिलेगा या क्या मुझे अपना लिंक अपडेट करने की आवश्यकता है?

मैं यह भी देखता हूं कि होस्टिंग के लिए Google के पास इन स्क्रिप्ट सेटअप का एक बड़ा सेट है।

पक्ष और विपक्ष क्या होते हैं?

जवाबों:


11

पेशेवरों

  • आपकी स्क्रिप्ट तेज़ी से लोड होती हैं । यदि आपके पास संसाधनों की एक बहुतायत है जो एक ही डोमेन से लोड करने की आवश्यकता है, तो आपका ब्राउज़र आमतौर पर इसे टाल देगा ताकि आपके पास केवल एक ही मेजबान के समानांतर अनुरोधों का एक मुट्ठी भर हो। इसलिए यदि आप सोलह अलग-अलग लिपियों, कई छवियों, और कई सीएसएस दस्तावेजों को लोड कर रहे हैं तो कतार लगने वाली है क्योंकि प्रत्येक संसाधन लोड होने की प्रतीक्षा करता है। (निश्चित रूप से अपने सीएसएस और जावास्क्रिप्ट फ़ाइलों को संक्षिप्त रूप में देखें - केवल दो स्क्रिप्ट संसाधनों को लोड करना काफी तेज होगा)।
  • यदि आप उन संसाधनों को एक अलग डोमेन में बंद कर देते हैं, हालांकि, आपके ब्राउज़र को उस सर्वर से अतिरिक्त कनेक्शन खोलने में कोई समस्या नहीं होगी, जिसका अर्थ है कि अधिक संसाधन समवर्ती रूप से लोड किए जाते हैं जिसके परिणामस्वरूप पृष्ठ तेजी से निष्पादित होते हैं। आप अपने पेज लोडिंग का एक अलग सर्वर हैंडल भी दे रहे हैं, जो आपके सर्वर के लिए अच्छा है जो संभवतः कई स्क्रिप्ट-निष्पादन अनुरोधों पर काम कर रहा है जैसा कि यह है।
  • इसके अतिरिक्त, ये CDN सर्वर (सामग्री विचलन नेटवर्क) CDN के रूप में संचालित करने के लिए कॉन्फ़िगर किए गए हैं । वे आम तौर पर खाना पकाने वाले (छोटे पैकेट के आकार के लिए) होते हैं और एक बेहद हल्के सर्वर के साथ स्थापित किए जाते हैं जो खुद को पूरी तरह से इस्तेमाल किए जाने वाले संसाधनों और कैशिंग के साथ पूरी तरह से चिंतित करता है और दिन-प्रतिदिन उठाने के साथ इतना नहीं है कि एक दलदल जैसा कुछ हो Apache सर्वर प्रदर्शन करेगा।
  • Google या अकामी जैसे सीडीएन का उपयोग करने के साथ-साथ अन्य लाभ भी हैं - Google के पास विशेष रूप से दुनिया भर में सर्वर हैं और इसके राउटिंग सिस्टम स्मार्ट हैं जो निकटतम भौगोलिक प्रतिलिपि के साथ एक संसाधन के लिए अनुरोध करने के लिए पर्याप्त हैं। आपका सर्वर रूस में व्लादिमीर के लिए jQuery.js की सेवा करने की कोशिश कर रहा हो सकता है - Google के पास शायद व्लादिमीर से सड़क के नीचे एक ही संसाधन है, घटती हुई विलंबता।
  • इसके अलावा, चूंकि बहुत सी वेबसाइट पहले से ही इन सीडीएन का उपयोग करती हैं, इसलिए इस बात की बहुत अधिक संभावना है कि आप जिस संसाधन की सेवा कर रहे हैं, वह उपयोगकर्ता द्वारा पहले ही कैश कर दिया गया है। आपके सर्वर से jQuery.js और Google के सर्वर से jQuery.js को एक ही फ़ाइल के रूप में नहीं माना जाता है, भले ही वे बिल्कुल समान हों - यदि आप Google से लोड करते हैं, तो यह पिछली साइट से कैश्ड प्रतिलिपि का उपयोग करने में सक्षम होगा उपयोगकर्ता का दौरा किया।
  • फ़ाइलें स्वयं नहीं बदलेंगी, विशेष रूप से जावास्क्रिप्ट संसाधनों जैसे स्क्रिप्ट संसाधनों के लिए। यदि एक नया संस्करण सामने आता है, तो Google पुराने संस्करण (चाहे वह कितना भी खराब क्यों न हो) को विशेष रूप से होस्ट करता रहेगा ताकि CDN सामान्य रूप से काम करता रहे और किसी भी खराब अनुरोध को पूरा न करे। यही कारण है कि किसी भी CDN फ़ाइल को उपयुक्त संस्करण संख्या के साथ भरा जाता है।

विपक्ष

  1. आपके CDN के उपलब्ध नहीं होने की संभावना है। हालाँकि, संभावना यह है कि आपकी साइट के पतले होने की संभावना कम है। Google और अकामी जैसे बड़े CDN में असफलता की कई परतें हैं।
  2. यदि आपके पास अपने सर्वर से लोड करने के लिए केवल एक या दो संसाधन हैं, तो नया कनेक्शन बनाना संभव नहीं है।
  3. आपके द्वारा सेवा की जा रही फ़ाइल पर किसी भी प्रकार का नियंत्रण नहीं है, इसलिए jQuery के अपने कस्टम संस्करण का उपयोग करके या जो कुछ भी आप लोड करने का प्रयास कर रहे हैं, जब तक आप अपने स्वयं के सीडीएन के लिए भुगतान नहीं कर रहे हैं।

सुरक्षा

मैं इस एल स्टैक पोस्ट और इस विषय के Googling की एक अच्छी राशि की सिफारिश करूंगा । प्रत्येक सीडीएन अलग होगा, हालांकि संक्षेप में मुझे लगता है कि यह एक मामूली चिंता होगी।


1

अभी तक जिस किसी का उल्लेख नहीं किया गया है वह Google के लिए एक और ट्रैकिंग विकल्प है। वे इन सभी सेवाओं को बिना किसी कारण के किसी भी कीमत पर नहीं दे रहे हैं। AdSense और Analytics काफी पर्याप्त हैं और कम से कम उन्हें फ़िल्टर किया जा सकता है। मेरी किताब में यह एक बड़ा मामला है।


0

पेशेवरों:

  • आपको फ़ाइलों की सेवा से संबंधित बैंडविड्थ के लिए भुगतान करने की आवश्यकता नहीं है और आम तौर पर

विपक्ष:

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

CDN का उपयोग करने के अन्य लाभ हैं, लेकिन वे सीधे 3rd स्क्रिप्ट होस्टिंग सेवा का उपयोग करने से संबंधित नहीं हैं।


0

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

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

उस प्रभाव के लिए, यदि हम सभी CDN का उपयोग करते हैं और सर्वोत्तम प्रथाओं को नियोजित करते हैं, तो हम उपयोगकर्ता को अतिरिक्त ~ 10-50KB प्राप्त करने से बचा सकते हैं, जब वे शुरू में हमारे URL तक पहुँचते हैं और उन्हें अपने पृष्ठों को तेज़ी से लोड करने की अनुमति देते हैं।

मैं दो कारणों से सीडीएन का उपयोग करने की दृढ़ता से सलाह दूंगा: उल्लेखित जारोड का उल्लेख वहाँ है, सच है, लेकिन पूरी तरह से महत्वहीन है और यदि आपके पहले से ही आपके स्रोतों को एक ही दस्तावेज़ में बाँध रहा है, तो आप सभी को पुनः कहने के लिए मजबूर करेंगे, कह सकते हैं, अनुशंसा के स्थिर jQuery के हिस्से दस्तावेज़ (~ 33KBs) हर बार जब आप बंडल किए गए संसाधनों में से एक को अपडेट करते हैं।

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


-2

यह मत करो

व्यक्तिगत रूप से, मैं तीसरे पक्ष द्वारा होस्ट की गई स्क्रिप्ट पर भरोसा नहीं करूंगा। यदि आप अन्य लोगों की स्क्रिप्ट का लाभ उठाते हैं तो आप उनकी दया पर हैं। विचार करने के लिए कई चीजें हैं:

  1. यदि उनकी साइट नीचे जाती है तो आपका पेज टाइम आउट या एरर आउट हो सकता है।
  2. यदि वे व्यवसाय से बाहर जाते हैं और होस्टिंग बंद कर देते हैं तो आपने वह सारी कार्यक्षमता खो दी है
  3. अगर वे हैक हो जाते हैं, तो आप हैक भी हो सकते हैं।
  4. क्रॉस-साइट स्क्रिप्टिंग SSL प्रमाणपत्र के साथ कहर खेल सकती है
  5. पृष्ठ लोड समय नाटकीय रूप से बढ़ सकता है
  6. यदि इंटरफ़ेस बदलता है, तो आपको सभी फ़ंक्शन कॉल को संशोधित करने की आवश्यकता है

आपकी अपनी साइट पर कोड होस्ट करना सुरक्षित है, मुझ पर विश्वास करें। आपको केवल एक बार बर्न करने की आवश्यकता है और आपके पास 250 वेबसाइटें हैं जिन्हें आपने बनाया है और होस्ट मजाकिया अभिनय करना शुरू कर रहे हैं क्योंकि आपने तीसरे भाग की होस्ट की गई स्क्रिप्ट पर काम करना बंद कर दिया है।


1
मुझे लगता है कि यदि आप एक बड़े, विश्वसनीय CDN का उपयोग करते हैं, तो संभवतः आप अपनी कई चिंताओं का सामना नहीं करेंगे। 1.) मुझे उम्मीद है कि Google का CDN बहुत अच्छा अपटाइम होगा, 2.) मैं Google को किसी भी समय जल्द ही व्यापार से बाहर नहीं जाता देख रहा हूँ, 3.) यह प्रशंसनीय है, लेकिन फिर से मैं बहुत तेज़ पैचिंग / फिक्सिंग की उम्मीद करूंगा, 4 ।) मैं किसी भी मुद्दे को नहीं देखा है, 5.) अगर यह एक सम्मानजनक सीडीएन है, तो पृष्ठ लोड वास्तव में तेजी से होना चाहिए जो आप स्वयं की सेवा कर सकते हैं (पाइपलाइनिंग, मल्टी-साइट कैशिंग और कुकलेस डोमेन के बीच), 6.) jQuery की तरह मुख्य संस्करण लिबास एक मुद्दा नहीं होना चाहिए।
19'11

1
... इसके अलावा, कुछ भी नहीं है जो आपको अपनी खुद की कमबैक स्क्रिप्ट को लागू करने से रोकना चाहिए, दूरस्थ CDN को विफल होना चाहिए।
स्क्यूलिफ

इनमें से कोई भी कारण जो केप कॉड गनी सूचीबद्ध हैं, वे Google जैसे आधुनिक सीडीएन या कई अन्य बड़े सीडीएन प्रदाताओं के साथ वैध चिंताएं हैं।
जारोड नेटल्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.