अपनी होस्टिंग पर स्थिर संसाधनों को संग्रहीत करें

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

मैं किस बारे में बात कर रहा हूँ?

डेवलपर्स के लिए स्थैतिक संपत्ति के लिंक पर क्लिक करना एक सामान्य बात है, जैसे लाइब्रेरी या प्लगइन्स, जो साइटों और सीडीएन संसाधनों पर स्थित हैं। एक क्लासिक उदाहरण jQuery है।

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

(पहले, लाभों पर विचार करें)।

• यह सुविधाजनक है। यह फ़ाइलों को जोड़ने के लिए बहुत कम प्रयास की आवश्यकता है। HTML कोड की लाइन कॉपी करें, और आप काम कर रहे हैं। आसानी से।
• हमें सीडीएन तक पहुंच प्राप्त है। code.jquery.com को StackPath द्वारा आपूर्ति की जाती है, यह एक CDN है। इस संसाधन की सामग्री से जुड़कर, हमें CDN- गुणवत्ता वितरण, निःशुल्क मिलता है।
• उपयोगकर्ता फ़ाइलें पहले से ही कैश की जा सकती हैं। यदि website-a.com लिंक को। Jquery.com/jquery-3.3.1.slim.min.js से जोड़ता है और उपयोगकर्ता यहाँ से website-b.com पर जाता है, जो code.jquery.com/jquery-3.3 से भी लिंक करता है । .1.slim.min.js , तो उपयोगकर्ता के पास यह फ़ाइल कैश में होगी।

जोखिम: स्पीड ड्रॉप और विफलता

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

यदि आपके पास तृतीय-पक्ष संसाधनों पर होस्ट किए गए CSS या सिंक्रोनस जेएस को रेंडर-ब्लॉक करना है, तो आगे बढ़ें और उन्हें तुरंत अपने स्वयं के बुनियादी ढांचे में स्थानांतरित करें। तीसरे पक्ष के सर्वर पर छोड़ दी जाने वाली महत्वपूर्ण संपत्ति बहुत मूल्यवान है।

जोखिम: सेवा की समाप्ति

यह बहुत कम सामान्य घटना है, लेकिन क्या होगा यदि प्रदाता यह निर्णय लेता है कि उसे सेवा बंद करने की आवश्यकता है? यह ठीक वैसा ही है जैसा कि रावजीत ने अक्टूबर 2018 में किया था, अब तक (लेखन के समय), GitHub कोड पर एक क्रूड खोज अभी भी सेवा को एक मिलियन से अधिक लिंक प्रदान करती है, जो वर्तमान में बंद हो रही है, और लगभग 20,000 मौजूदा साइटें जारी हैं इसे देखें।

जोखिम: सुरक्षा कमजोरियाँ

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

उस नुकसान की कल्पना करें जो किसी को हो सकता है यदि कोई प्रदाता जैसे कि code.jquery.com पर नियंत्रण प्राप्त कर सकता है और समझौता या दुर्भावनापूर्ण सामग्री वितरित करना शुरू कर सकता है। इसके बारे में सोचना डरावना है!

सबस्रोइट इंटीग्रिटी

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

<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js" integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8=" crossorigin="anonymous"></script> 

एक बार फिर, यदि आपको निश्चित रूप से स्थिर सामग्री को तृतीय-पक्ष संसाधन से कनेक्ट करने की आवश्यकता है, तो सुनिश्चित करें कि SRI सक्रिय है। आप स्वयं SRI कनेक्ट कर सकते हैं।

रेकिंग: नेटवर्क वार्ता

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

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

ये चार फाइलें तीन अलग-अलग संसाधनों पर स्थित हैं, यानी हमें तीन टीसीपी कनेक्शन खोलने की जरूरत है। कितना खर्च होता है? खैर, काफी तेज़ कनेक्शन के साथ, इन स्थिर फ़ाइलों की सामग्री 311ms, या 1.65x धीमी है जब आपकी अपनी होस्टिंग पर रखते हैं।

स्थैतिक संपत्ति की सेवा के लिए तीन अलग-अलग स्रोतों से संपर्क करके, हम सामूहिक रूप से नेटवर्क अनुमोदन के लिए अनावश्यक 805ms खो देते हैं।

ठीक है, यह इतना डरावना नहीं है, लेकिन ट्रेनलाइन, मेरे क्लाइंट ने पाया कि जब देरी 300ms कम हो गई थी, तो आगंतुकों ने प्रति वर्ष अतिरिक्त 8 मिलियन पाउंड का भुगतान किया। यह 8 मिलियन कमाने का एक बहुत ही आसान तरीका है।

बस अपने संसाधनों को आपके डोमेन पर ले जाकर, हम अतिरिक्त कनेक्शन की लागत को पूरी तरह से समाप्त कर देते हैं।

एक धीमी कनेक्शन के लिए, एक लंबी देरी के साथ, कहानी बहुत खराब है। 3 जी के लिए, तृतीय-पक्ष संस्करण 1.765 की तुलना में धीमा आता है। मुझे लगा कि यह हमारी साइट को तेज़ बनाने के लिए है।

जब एक बड़ी देरी से जुड़ते हैं, तो कुल नेटवर्क लागत राक्षसी 5.037 होती है। पूरी तरह से क्या बचा जा सकता है।

फ़ाइलों को अपने स्वयं के बुनियादी ढांचे में ले जाने से डाउनलोड समय 5.4 से 3.6 तक कम हो जाता है।

यदि यह आपके स्थैतिक संसाधनों की मेजबानी करने का एक अच्छा कारण नहीं है, तो मुझे नहीं पता कि और क्या लाना है।

प्रीकनेक्ट

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

रेकिंग: प्राथमिकता का नुकसान

दूसरा रेकनिंग प्रोटोकॉल स्तर पर अनुकूलन के रूप में आता है, जिसे हम तब याद करते हैं जब हम सामग्री को डोमेन में विभाजित करते हैं। यदि आप HTTP / 2 का उपयोग करते हैं, तो क्या किया जाना चाहिए, आपको प्राथमिकता प्राप्त करने की सुविधा मिलती है।

समान टीसीपी कनेक्शन के साथ सभी प्रवाह (इसलिए संसाधन) प्राथमिकता बनाए रखते हैं, और ब्राउज़र और सर्वर इन सभी प्राथमिकता वाले प्रवाह की निर्भरता वृक्ष के निर्माण के लिए मिलकर काम करते हैं, ताकि हम महत्वपूर्ण संसाधनों को तेजी से वापस कर सकें और संभवतः कम महत्वपूर्ण लोगों की डिलीवरी में देरी हो।

नोट। तकनीकी रूप से, HTTP / 2 कनेक्शन के विलय के कारण, विभिन्न डोमेन में एक दूसरे के संबंध में अनुरोधों को प्राथमिकता दी जा सकती है, जब तक वे एक ही आईपी पते को साझा नहीं करते हैं।

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

एक होस्टिंग पर सभी सामग्री की मेजबानी करके, हम एक अधिक जटिल निर्भरता पेड़ का निर्माण कर सकते हैं। प्रत्येक धागे की अपनी आईडी होती है, क्योंकि वे एक ही पेड़ से संबंधित होते हैं। यदि हम एक डोमेन से अधिक से अधिक सामग्री प्रदान करते हैं, तो हम HTTP / 2 को अपना काम करने दे सकते हैं और तेजी से प्रतिक्रिया की उम्मीद में संपत्ति को पूरी तरह से प्राथमिकता दे सकते हैं।

कैशिंग

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

हालांकि, यह हमेशा मामला नहीं होता है, और स्वतंत्र रूप से अपने संसाधनों को रखकर, आप बहुत अधिक व्यक्तिगत कैशिंग रणनीतियों को विकसित कर सकते हैं।

मिथक: क्रॉस-डोमेन कैशिंग

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

दुर्भाग्य से, इन दावों का समर्थन करने के लिए कोई प्रकाशित साक्ष्य नहीं है: विश्वास करने का कोई कारण नहीं है कि यह सच है। इसके विपरीत, पॉल कैल्वानो के हालिया अध्ययन से संकेत मिलता है कि विपरीत सच हो सकता है:

सीएसएस संसाधन कैश और 1 और 3 पार्टी वेब फोंट की उम्र के बीच एक उल्लेखनीय अंतर है। 1-पक्ष के फोंट का 95% 1-पार्टी फोंट की तुलना में 1 सप्ताह से अधिक पुराना है जो 1 सप्ताह से कम पुराना है। यह स्व-होस्ट किए गए वेब फोंट के लिए अच्छे कारण प्रदान करता है।

सामान्य तौर पर, ऐसा लगता है कि तृतीय-पक्ष की सामग्री अपने आप से बदतर है।

इससे भी महत्वपूर्ण बात यह है कि सफारी ने गोपनीयता के दुरुपयोग के बारे में चिंताओं के कारण इस सुविधा को पूरी तरह से अक्षम कर दिया है, इसलिए साझा कैश तकनीक दुनिया भर के 16% उपयोगकर्ताओं के लिए इस लेखन के समय काम नहीं कर सकती है।

संक्षेप में, हालांकि यह सैद्धांतिक रूप से अच्छा है, इस बात का कोई सबूत नहीं है कि क्रॉस-डोमेन कैशिंग किसी तरह कुशल है।

सीडीएन पहुंच

एक स्थिर संसाधन प्रदाता से संपर्क करने का एक और व्यापक लाभ यह है कि यह सीडीएन क्षमताओं के साथ एक शक्तिशाली बुनियादी ढांचे का उपयोग करने की संभावना है: वैश्विक वितरण, स्केलेबिलिटी, कम विलंबता और उच्च उपलब्धता।

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

दूसरे शब्दों में: यदि आपको लगता है कि आपको अपने jQuery के लिए CDN की आवश्यकता है, तो आपको हर चीज के लिए CDN की आवश्यकता होगी।

अपनी मेजबानी पर स्थिर संसाधनों की मेजबानी करें

वास्तव में, आपके स्थैतिक संसाधनों को किसी और के बुनियादी ढांचे में छोड़ने के बहुत कम कारण हैं। संभावित लाभ अक्सर एक मिथक होते हैं, और भले ही नहीं, समझौता बस इसके लायक नहीं हैं। विभिन्न स्रोतों से लोड हो रहा संसाधन बहुत धीमा है। अगले कुछ दिनों में, अपनी परियोजनाओं की ऑडिटिंग में दस मिनट का समय बिताएं और सभी तृतीय-पक्ष स्थैतिक संसाधनों पर नियंत्रण रखें।