स्क्रिप्ट को किसी तृतीय-पक्ष साइट से कैसे कनेक्ट करें

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

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



आज जिवोसाइट है:

• दुनिया भर में 250K ग्राहक;
• प्रति दिन 150M विजेट इंप्रेशन;
• प्रति दिन 3.5M संदेश;
• 10M चैट प्रति माह;
• 1M एक साथ कनेक्शन;
• उत्पादन में 250+ सर्वर।

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

प्रवेश बिंदु

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

<script src="https://site.com/file.js"></script> 

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

पहचान

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

विकल्प # 1

 <script async src="https://site.com/file.js?id=123"></script> 

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


लंबे समय तक हमने इस सिद्धांत पर काम किया, लेकिन इस दृष्टिकोण का नुकसान यह है कि सर्वर पर "निष्क्रिय" लोड और सर्वर कैशिंग को लागू करने की आवश्यकता को जोड़ा जाता है।

विकल्प # 2

 <script src="https://site.com/file.js" [async]></script> <script type=”text/javascript”> window.serviceNameId = “123”; // ServiceNameModule.init({id: “123”}); </script> 

Async विशेषता - ब्राउज़र को बताती है कि DOM को बनाने के लिए स्क्रिप्ट को लोड करने के लिए प्रतीक्षा करने की आवश्यकता नहीं है, स्क्रिप्ट को लोड करने के तुरंत बाद निष्पादित किया जाना चाहिए। यह पृष्ठ लोड समय को कम करता है, लेकिन सिक्के का एक फ्लिप पक्ष भी है: स्क्रिप्ट को काम करने के लिए तैयार होने से पहले निष्पादित किया जा सकता है।

सबसे लोकप्रिय कार्यान्वयन में से एक, बड़ी सेवाओं सहित, बस यही करता है, केवल सिंटैक्स अलग है, लेकिन सभी का सार समान है।


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

विकल्प # 3

 <script async src="https://site.com/file.js?id=123"></script> 

पहले विकल्प के समान, फ़ाइल के लिंक में आईडी को स्थानांतरित करें, लेकिन इसे ब्राउज़र में पुनर्प्राप्त करें, और सर्वर पर नहीं। यह उतना सरल नहीं है जितना लगता है, लेकिन यह संभव है। ब्राउज़र API में एक डॉक्यूमेंट होता है। समकालस्क्रिप्ट प्रॉपर्टी, यह एक स्क्रिप्ट की लिंक देता है जो लोड होती है और वर्तमान में ब्राउज़र में चल रही है। यह जानते हुए भी, आप आईडी की गणना कर सकते हैं, इसके लिए आपको document.currentScript.src संपत्ति प्राप्त करने और नियमित रूप से आईडी निकालने की आवश्यकता है।


एक बात है लेकिन: document.currentScript सभी ब्राउज़रों द्वारा समर्थित नहीं है। उन ब्राउज़र के लिए जो इस संपत्ति का समर्थन नहीं करते हैं, हम एक दिलचस्प हैक के साथ आए। File.js कोड में, आप विशेष "नकली" अपवाद को ट्राई / कैच में फेंक सकते हैं, उसके बाद स्क्रिप्ट का URL जिसमें त्रुटि स्टैक में त्रुटि हुई थी, फेंक दिया जाएगा। URL में वह आईडी होगी जो हमें उसी नियमितता के साथ मिलती है।

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

सेटिंग्स

ज्यादातर मामलों में, प्लग-इन स्क्रिप्ट में कोई भी सेटिंग होती है जो काम की उपस्थिति या तर्क के लिए जिम्मेदार होती है। इन सेटिंग्स को प्लग-इन स्क्रिप्ट में "फेंक" दिया जाना चाहिए, इसके लिए दो मौलिक रूप से अलग-अलग दृष्टिकोण हैं।

दृष्टिकोण # १

 <script async src="https://site.com/file.js"></script> <script type=”text/javascript”> window.serviceName = {color: “red”, title: “”, ...}; // ServiceNameModule.init({color: “red”, title: “”, ...}); </script> 

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


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

दृष्टिकोण # 2

 <script async src="https://site.com/file.js?id=123"></script> 

दूसरा दृष्टिकोण यह है कि यदि सेटिंग्स को बदलना आवश्यक है, तो क्लाइंट को सम्मिलित कोड को संशोधित करने की आवश्यकता नहीं है, सभी सेटिंग्स सर्वर पर संग्रहीत हैं। सेटिंग्स को बदलने के लिए, ग्राफिक पैनल पर जाएं, आवश्यक पैरामीटर बदलें और "सहेजें" बटन पर क्लिक करें। उसके बाद, सेटिंग्स स्वचालित रूप से उसकी साइट पर लागू हो जाएगी!


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

पिछड़ी अनुकूलता

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

 .... /script/widget/config/15**90 /script/widget/config/bqZB**rjW5; /script/widget/config/15**94 /script/widget/config/qtfx**xnTi; /script/widget/config/15**95 /script/widget/config/fqmpa**4YX; /script/widget/config/15**97 /script/widget/config/Vr21g**nuT; /script/widget/config/15**98 /script/widget/config/8NXL5**F8E; /script/widget/config/15**00 /script/widget/config/Th2HN**6RJ; .... 

इस विशेषता के कारण, हम सभी रीफैक्टरिंग के लिए एम्बेड कोड की बैकवर्ड संगतता बनाए रखने के लिए मजबूर हैं, जो कि हमारी मेमोरी में लगभग 5 थी।

कोड अलगाव

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

 <script type="text/javascript"> //  mootools.js var JSON = new Hash({ encode: function () {}, decode: function () {} // ... }); //    JSON.parse(json); // Uncaught TypeError: JSON.parse is not a function </script> 

 <style type="text/css"> //      body * { padding: 20px; } form input { display: block; border: 2px solid red; } </style> 

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

ब्लॉक लोडिंग साइट

ऑनलोड घटना - वेब पेज पूरी तरह से लोड होने के बाद होती है, जिसमें चित्र, शैली और बाहरी स्क्रिप्ट शामिल हैं। एक महत्वपूर्ण विशेषता यह है कि ज्यादातर साइटों पर, जेएस लॉजिक, थर्ड-पार्टी स्क्रिप्ट और विज्ञापन इस घटना की घटना पर काम करना शुरू कर देते हैं। सभी जुड़े स्क्रिप्ट के लिए एक बहुत महत्वपूर्ण बिंदु इस घटना पर नकारात्मक प्रभाव को रोकने के लिए है।

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

व्यक्तिगत अनुभव
अतीत में, मैंने एक ऐसी कंपनी के लिए काम किया, जिसकी ऑनलाइन वेबसाइट 100K, ऑनलाइन डेटिंग थी। उन दिनों में, "सामाजिक नेटवर्क पर साझा करें" बटन लोकप्रिय थे। उन्हें साइट पर प्रदर्शित होने के लिए, आपको वांछित सामाजिक नेटवर्क से एक स्क्रिप्ट (एसडीके) कनेक्ट करना होगा। एक दिन, सहकर्मी हमारे पास गए और कहा कि हमारी साइट काम नहीं कर रही थी! हमने निगरानी पर ध्यान दिया, जिसमें सब कुछ सामान्य था, और पहली बार में हमें समझ नहीं आया कि समस्या क्या थी। जब वे गहरी खुदाई करने लगे, तो उन्होंने महसूस किया कि ट्विटर के सीडीएन-सर्वर नीचे पड़े थे, और उनका एसडीके लोड नहीं कर सका, इससे हमें साइट को ~ 1.5 मिनट तक लोड करने से रोक दिया गया। यही है, साइट खोलने के बाद, थोड़ा HTML लोड किया गया था (एसपीए के बाकी) और केवल 1.5 मिनट के बाद ही सब कुछ लोड हो गया था, बहुत अनुरोध टाइमआउट काम किया। हमें तत्काल एक हॉटफिक्स को व्यवस्थित करने और उनकी स्क्रिप्ट को साइट से हटाने की आवश्यकता थी। इस स्थिति को दोहराने के बाद, हमने शेयर ब्लॉक को हटाने का फैसला किया।

सम्मिलित कोड के पहले संस्करणों में, हमने इसे ध्यान में नहीं रखा, और हमारी तरफ से तकनीकी समस्याओं के मामले में, इसे हल्के ढंग से रखने के लिए, हम अपने ग्राहकों को असुविधा देते हैं, लेकिन समय के साथ हमने इसे ठीक कर दिया।

निर्णय

 <script type='text/javascript'> (function(){ var initCode = function () { // insert script tag }; document.readyState === 'complete' ? initCode() : w.addEventListener('load', initCode, false); })(); </script> 

समाधान सरल है, आपको साइट के पूर्ण लोड की घटना के लिए सदस्यता लेनी होगी और उसके बाद ही स्क्रिप्ट को लोड करना होगा, इसके लिए आपको एम्बेड कोड का उपयोग करने की आवश्यकता है, न कि स्क्रिप्ट टैग की।

गूगल पेजपेड

Habr.com के मोबाइल संस्करण का विश्लेषण

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

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

CDN

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

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



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

दोष सहिष्णुता

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

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


प्रत्येक संस्करण के लिए विजेट डाउनलोड की कुल संख्या

त्रुटि संग्रह
जावास्क्रिप्ट एक बहुत ही विशिष्ट भाषा है, और गलती करना आसान है। इसके अलावा, आधुनिक वेब पर ब्राउज़रों का चिड़ियाघर बहुत बड़ा है; नवीनतम क्रोम में क्या काम करता है यह एक तथ्य नहीं है जो सफारी या फ़ायरफ़ॉक्स में काम करेगा। इसलिए, ब्राउज़र से त्रुटि संग्रह को कॉन्फ़िगर करना और समय में स्पाइक्स का जवाब देना बहुत महत्वपूर्ण है। यदि आपका कोड एक iframe में काम करता है, तो आप इसे वैश्विक window.onerror हैंडलर को ट्रैक करके कर सकते हैं और, त्रुटि के मामले में, सर्वर को डेटा भेजें। यदि कोड iframe के बाहर काम करता है, तो त्रुटि संग्रह को लागू करना बहुत मुश्किल है।


सभी साइटों और ब्राउज़रों से त्रुटियों की कुल संख्या


विशिष्ट त्रुटि जानकारी

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

मैनुअल मोड में, यह बस काम करता था: एसएमएस ने प्रशासकों को यह कहते हुए प्राप्त किया कि सीडीएन नीचे था, उन्होंने कुछ हेरफेर किए, जिसके बाद विजेट ने एप्लिकेशन सर्वर से लोड करना शुरू कर दिया। यह 5 मिनट से 2 घंटे तक कहीं भी ले सकता है।

स्वचालित वापसी को लागू करने के लिए, आपको किसी तरह यह पता लगाने की आवश्यकता है कि स्क्रिप्ट ने लोड करना शुरू कर दिया है, लेकिन यह उतना आसान नहीं है जितना लगता है। ब्राउज़र स्क्रिप्ट टैग लोडिंग के मध्यवर्ती राज्यों की निगरानी करने की क्षमता प्रदान नहीं करता है, जैसे कि XMLHttpRequest में onprogress घटना, लेकिन स्क्रिप्ट लोड होने और निष्पादित होने पर केवल घटना की रिपोर्ट करता है। स्वीकार्य समय के लिए यह पता लगाना भी असंभव है कि सर्वर वर्तमान में अनुपलब्ध है, अनुरोध समय समाप्त होने के बाद एकमात्र ऑनरोर घटना 1 मिनट से अधिक समय तक समाप्त हो जाती है। एक मिनट में, आगंतुक पहले ही पृष्ठ छोड़ सकता है, लेकिन स्क्रिप्ट लोड नहीं होगी।

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


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

लोडर

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


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

थर्ड पार्टी सर्विसेज

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

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

समाधान सरल है, सर्वर ने GoogleBot के डेटा को अनदेखा करना शुरू कर दिया।

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

इस तथ्य के कारण वेब ब्राउज़र में मोबाइल उपयोगकर्ता सत्रों को देखने के दौरान, विजेट का डेस्कटॉप संस्करण रिकॉर्डिंग पर खुल गया, हालांकि वास्तव में, उपयोगकर्ताओं ने मोबाइल संस्करण खोला। हमारे ग्राहकों ने सोचा कि यह था, और हमें शिकायतों के साथ बमबारी की। , , , , .

, , , .

, . , . , , NodeJS , 270 - , .

, !