तृतीय-पक्ष संसाधनों की स्व-होस्टिंग: अच्छा, बुरा, बुरा

हाल के वर्षों में, फ्रंट-एंड प्रोजेक्ट्स के अनुकूलन के लिए अधिक से अधिक प्लेटफ़ॉर्म स्वतंत्र-होस्टिंग या थर्ड-पार्टी संसाधनों की भविष्यवाणी के अवसर प्रदान करते हैं। अकामाई आपको स्व-निर्मित URL के लिए विशिष्ट पैरामीटर सेट करने की अनुमति देता है। Cloudflare में Edge Workers तकनीक है। फास्टरज़ाइन पृष्ठों पर URL को फिर से लिख सकता है ताकि वे साइट के मुख्य डोमेन पर स्थित तृतीय-पक्ष संसाधनों की ओर इशारा करें।



यदि आप जानते हैं कि आपके प्रोजेक्ट में उपयोग की जाने वाली तृतीय-पक्ष सेवाएँ अक्सर बदलती नहीं हैं, और यह कि ग्राहकों को उनके वितरण की प्रक्रिया में सुधार किया जा सकता है, तो आप शायद ऐसी सेवाओं के बारे में सोचें। इस दृष्टिकोण के साथ, आप इन संसाधनों को उपयोगकर्ताओं के करीब ला सकते हैं और क्लाइंट की तरफ उनके कैशिंग पर अधिक नियंत्रण प्राप्त कर सकते हैं। इसके अलावा, यह आपको उपयोगकर्ताओं को तृतीय-पक्ष सेवा की "गिरावट" या उसके प्रदर्शन के खराब होने से होने वाली परेशानियों से बचाने की अनुमति देता है।

गुड: उत्पादकता में वृद्धि

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


तृतीय-पक्ष संसाधन बाहरी स्रोतों से डाउनलोड किए जाते हैं ( यहाँ से लिए गए हैं )


तृतीय-पक्ष संसाधन शेष साइट सामग्री के रूप में उसी स्थान पर संग्रहीत हैं ( यहाँ से लिया गया है )

स्थिति को इस तथ्य से भी बेहतर किया जाता है कि ब्राउज़र मल्टीप्लेक्सिंग और HTTP / 2 कनेक्शन डेटा को प्राथमिकता देने की क्षमताओं का उपयोग करेगा, जो पहले से ही मुख्य डोमेन के साथ स्थापित है।

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

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

यदि आप अपने दम पर तीसरे पक्ष के संसाधनों की मेजबानी करते हैं, तो आप यह नियंत्रित कर सकते हैं कि ये संसाधन ग्राहक को कैसे दिए जाएं। अर्थात्, हम निम्नलिखित के बारे में बात कर रहे हैं:

• आप यह सुनिश्चित कर सकते हैं कि डेटा कम्प्रेशन एल्गोरिथ्म जो प्रत्येक ब्राउज़र के लिए सबसे उपयुक्त है (Brotli / gzip) लागू है।
• आप संसाधनों के कैशिंग समय को बढ़ा सकते हैं, जो आमतौर पर सबसे प्रसिद्ध प्रदाताओं के लिए बहुत बड़े नहीं होते हैं (उदाहरण के लिए, जीए टैग के लिए संबंधित मूल्य 30 मिनट पर सेट होता है)।

आप किसी संसाधन के लिए TTL का विस्तार भी कर सकते हैं, उदाहरण के लिए, अपने कैशिंग प्रबंधन रणनीति (URL हैश, संस्करण, और इसी तरह) में उपयुक्त सामग्रियों को शामिल करके एक साल तक। हम इस बारे में नीचे बात करेंगे।

Third तृतीय-पक्ष सेवाओं के संचालन में रुकावट या उनके वियोग से सुरक्षा

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

यह पता लगाने के लिए कि आपकी साइट किसी बाहरी सेवा की दुर्गमता की स्थिति में कैसे काम करती है, आप webpagetest.org पर SPOF सेक्शन का उपयोग कर सकते हैं।


SPOF webpagetest.org पर अनुभाग

▍ ब्राउज़रों के साथ कैशिंग मुद्दों के बारे में कैसे? (संकेत: यह एक मिथक है)

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

मान लीजिए कि हमारे पास कई अलग-अलग साइटें हैं: website1.com, website2.com, website3.com। ये सभी साइटें jQuery लाइब्रेरी का उपयोग करती हैं। हम इसे सीडीएन का उपयोग करके उनसे जोड़ते हैं, उदाहरण के लिए googleapis.com। आप ब्राउज़र को एक बार लाइब्रेरी को डाउनलोड करने और कैश करने की उम्मीद कर सकते हैं, और फिर तीनों साइटों के साथ काम करते समय इसका उपयोग कर सकते हैं। यह नेटवर्क पर लोड को कम कर सकता है। शायद यह कहीं न कहीं पैसे बचाएगा और संसाधन उत्पादकता में सुधार करने में मदद करेगा। व्यावहारिक दृष्टिकोण से, सब कुछ अलग दिखता है। उदाहरण के लिए, सफारी इंटेलिजेंट ट्रैकिंग प्रिवेंशन नामक एक सुविधा को लागू करता है: कैश दस्तावेज़ के स्रोत और एक तृतीय-पक्ष संसाधन के स्रोत के आधार पर दोहरी कुंजी का उपयोग करता है। यहाँ इस विषय पर एक अच्छा लेख है।

पुराने याहू और फेसबुक अनुसंधान, साथ ही पॉल कैल्वानो द्वारा हाल ही में किए गए शोध से पता चलता है कि संसाधन ब्राउज़र कैश में तब तक संग्रहीत नहीं होते हैं जब तक हम उम्मीद कर सकते हैं: “हमारे अपने और तीसरे पक्ष के परियोजना संसाधनों के कैशिंग समय के बीच एक गंभीर अंतर है। यह सीएसएस और वेब फोंट के बारे में है। अर्थात्, अपने स्वयं के फोंट के 95% का कैशिंग शब्द एक सप्ताह से अधिक है, जबकि तीसरे पक्ष के फोंट के 50% का कैशिंग शब्द एक सप्ताह से कम है! यह वेब डेवलपर्स को स्वयं-होस्ट फ़ॉन्ट फ़ाइलों का एक अच्छा कारण देता है! "

नतीजतन, यदि आप अन्य लोगों की सामग्रियों की मेजबानी करते हैं, तो आप ब्राउज़र कैशिंग के कारण प्रदर्शन की समस्याओं को नोटिस नहीं करेंगे।

अब जब हमने तीसरे पक्ष के संसाधनों की स्वयं-मेजबानी की ताकत की जांच की है, तो आइए इस बारे में बात करें कि इस दृष्टिकोण के अच्छे कार्यान्वयन को एक बुरे से कैसे अलग किया जाए।

बुरा: शैतान विवरण में है

अपने स्वयं के डोमेन पर तृतीय-पक्ष संसाधनों को ले जाना ऐसे संसाधनों के सही कैशिंग की परवाह किए बिना स्वचालित रूप से प्रदर्शन नहीं किया जा सकता है।

यहां मुख्य मुद्दों में से एक कैशिंग समय है। उदाहरण के लिए, संस्करण की जानकारी इस तरह से तीसरे पक्ष के स्क्रिप्ट नामों में शामिल है: jquery-3.4.1.js । भविष्य में ऐसी कोई फ़ाइल नहीं बदलेगी, परिणामस्वरूप, इसके कैशिंग में कोई समस्या नहीं होगी।

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

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

Delivery ग्राहकों के लिए सामग्री का अनुकूली वितरण

इसके अलावा, जब हम कैशिंग के बारे में बात करते हैं, तो हमें इस तथ्य को भी ध्यान में रखना चाहिए कि सीडीएन पर उपयोग की जाने वाली कैशिंग सेटिंग्स कुछ तृतीय-पक्ष संसाधनों के लिए उपयुक्त नहीं हो सकती हैं। उदाहरण के लिए, ऐसे संसाधन उपयोगकर्ता एजेंट सूँघने की तकनीक, अनुकूली सेवा का उपयोग कर सकते हैं, ताकि इन ब्राउज़रों के लिए विशेष रूप से अनुकूलित सामग्री के विशिष्ट ब्राउज़र संस्करण प्रदान किए जा सकें। ये प्रौद्योगिकियां, ब्राउज़र की क्षमताओं का पता लगाने के लिए, नियमित अभिव्यक्तियों पर या User-Agent HTTP हेडर के बारे में जानकारी एकत्र करने वाले डेटाबेस पर निर्भर करती हैं। यह जानने के लिए कि वे किस ब्राउज़र के साथ काम कर रहे हैं, वे इसके लिए डिज़ाइन की गई सामग्री देते हैं।

यहां आप दो सेवाओं को याद कर सकते हैं। पहला है googlefonts.com। दूसरा है पॉलीफिल.आईओ। Google फ़ॉन्ट्स सेवा, एक निश्चित संसाधन के लिए, ब्राउज़र की क्षमताओं के आधार पर विभिन्न CSS कोड ( unicode-range का उपयोग करके woff2 संसाधनों के लिंक देते हुए) unicode-range ।

यहां विभिन्न ब्राउज़रों से किए गए Google फ़ॉन्ट्स प्रश्नों के एक जोड़े के परिणाम हैं।


क्रोम फ़ॉन्ट्स क्वेरी परिणाम


IE10 से बना Google फ़ॉन्ट्स क्वेरी परिणाम

Polyfill.io ब्राउज़र को केवल उन्हीं पॉलीफ़िलों को देता है जिनकी उसे ज़रूरत होती है। यह प्रदर्शन कारणों से किया जाता है।

उदाहरण के लिए, विभिन्न ब्राउज़रों से निम्न अनुरोध चलाने पर क्या होता है, इस पर एक नज़र डालें: https://polyfill.io/v3/polyfill.js?features=default

IE10 से किए गए इस तरह के अनुरोध के जवाब में, 34 केबी डेटा आएगा। और क्रोम से बनाया गया, इसका उत्तर खाली होगा।

गुस्से में: कुछ गोपनीयता विचार

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

यदि आपका CDN सिस्टम सही तरीके से कॉन्फ़िगर नहीं किया गया है, तो यह आपके डोमेन से तृतीय-पक्ष सेवा को कुकीज़ भेजना समाप्त कर सकता है। यदि CDN स्तर पर उचित फ़िल्टरिंग का आयोजन नहीं किया जाता है, तो आपका सत्र कुकीज़, जिसे सामान्य परिस्थितियों में जावास्क्रिप्ट में इस्तेमाल नहीं किया जा सकता है ( httponly विशेषता के साथ), एक बाहरी होस्ट को भेजा जा सकता है।

यह ठीक वैसा ही हो सकता है जैसा कि यूलरियन या क्राइटो जैसे ट्रैकर्स के साथ हो सकता है। तृतीय-पक्ष ट्रैकर कुकीज़ में एक विशिष्ट पहचानकर्ता सेट कर सकते हैं। यदि वे साइटों की सामग्रियों का हिस्सा थे, तो वे विभिन्न वेब संसाधनों के साथ उपयोगकर्ता के काम के दौरान अपने विवेक पर पहचानकर्ता को पढ़ सकते थे।

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

हालांकि यह अनुशंसा नहीं की जाती है कि वेबसाइट की कुकी सभी उप-डोमेन (उदाहरण के लिए, * .website.com) तक पहुंच योग्य हों, कई साइटें ऐसा करती हैं। इस मामले में, इस तरह के कुकीज़ स्वचालित रूप से प्रच्छन्न तीसरे पक्ष के ट्रैकर को भेजे जाते हैं। परिणामस्वरूप, अब आप किसी भी गोपनीयता के बारे में बात नहीं कर सकते।

इसके अलावा, क्लाइंट-हिंट्स HTTP हेडर के साथ भी यही बात होती है, जो केवल मुख्य डोमेन को भेजे जाते हैं, क्योंकि उनका उपयोग उपयोगकर्ता के डिजिटल फिंगरप्रिंट बनाने के लिए किया जा सकता है। कृपया सुनिश्चित करें कि आप जिस CDN सेवा का उपयोग कर रहे हैं, वह ऐसे हेडर को सही तरीके से फ़िल्टर करती है।

परिणाम

यदि आप जल्द ही तृतीय-पक्ष संसाधनों की स्वतंत्र मेजबानी करने जा रहे हैं - तो मैं आपको कुछ सुझाव दूंगा:

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

प्रिय पाठकों! क्या आप अपने सर्वर पर अन्य लोगों की सामग्री पोस्ट करते हैं जो आपकी परियोजनाओं के लिए बेहद महत्वपूर्ण हैं?