🥗 🖤 🖇️ त्वरण instagram.com। भाग २ 👂 ⚜️ 🎮

आज हम आपके ध्यान में instagram.com ऑप्टिमाइज़ेशन को समर्पित एक श्रृंखला से दूसरी सामग्री का अनुवाद लाते हैं। यहां हम ग्राफकॉल प्रश्नों के शुरुआती निष्पादन के लिए तंत्र को बेहतर बनाने और क्लाइंट को HTML डेटा प्रसारित करने की दक्षता बढ़ाने पर ध्यान केंद्रित करेंगे।

→ पहले सांस के साथ पढ़ें

प्रगतिशील HTML डाउनलोड तकनीक का उपयोग करके क्लाइंट के लिए सर्वर द्वारा आरंभ किया गया डेटा सबमिशन

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

अनुरोध का प्रारंभिक निष्पादन ध्यान देने योग्य देरी से शुरू होता है

सिद्धांत रूप में, इस तरह के एक ग्राफक्यूएल क्वेरी की शुरुआत आदर्श रूप से उस क्षण को देखती है जब संबंधित पेज को लोड करने का अनुरोध सर्वर पर भेजा गया था। लेकिन सर्वर से कम से कम कुछ HTML कोड प्राप्त करने से पहले ही ब्राउज़र को कुछ डाउनलोड करना कैसे शुरू करें? इसका उत्तर सर्वर की पहल पर संसाधन को ब्राउज़र में भेजना है। ऐसा लग सकता है कि इस तरह के तंत्र को लागू करने के लिए, आपको HTTP / 2 सर्वर पुश जैसी किसी चीज़ की आवश्यकता होगी। लेकिन, वास्तव में, एक बहुत पुरानी तकनीक है (जो अक्सर भूल जाती है) जो आपको क्लाइंट और सर्वर के बीच बातचीत की एक समान योजना को लागू करने की अनुमति देती है। इस तकनीक को सार्वभौमिक ब्राउज़र समर्थन की विशेषता है, इसके क्रियान्वयन के लिए HTTP / 2 सर्वर पुश को लागू करने के लिए विशिष्ट बुनियादी ढांचे में तल्लीन करने की आवश्यकता नहीं है। फेसबुक 2010 से इस तकनीक का उपयोग कर रहा है ( बिगपाइप के बारे में पढ़ें ), और ईबे जैसी अन्य साइटों पर, यह विभिन्न रूपों में भी आवेदन पाता है। लेकिन ऐसा लगता है कि एकल-पृष्ठ अनुप्रयोगों के जावास्क्रिप्ट डेवलपर्स मूल रूप से या तो इस तकनीक की उपेक्षा करते हैं या बस इसका उपयोग नहीं करते हैं। यह HTML को उत्तरोत्तर लोड करने के बारे में है। इस तकनीक को विभिन्न नामों से जाना जाता है: "प्रारंभिक फ्लश", "हेड फ्लशिंग", "प्रगतिशील HTML"। यह दो तंत्रों के संयोजन के लिए धन्यवाद काम करता है:

पहले HTTP chunked हस्तांतरण एन्कोडिंग है।
दूसरा ब्राउज़र में HTML का प्रगतिशील प्रतिपादन है।

HTTP / 1.1 में chunked स्थानांतरण एन्कोडिंग तंत्र दिखाई दिया। यह आपको HTTP प्रतिक्रियाओं को कई छोटे भागों में विभाजित करने की अनुमति देता है जो स्ट्रीमिंग मोड में ब्राउज़र को प्रेषित होते हैं। ब्राउज़र इन भागों को "उपवास" करता है क्योंकि वे आते हैं, उनसे पूर्ण प्रतिक्रिया कोड बनाते हैं। यद्यपि यह दृष्टिकोण सर्वर पर पेज बनाने के तरीके में महत्वपूर्ण बदलाव के लिए प्रदान करता है, अधिकांश भाषाओं और रूपरेखाओं में समान उत्तर देने की क्षमता होती है, जो भागों में टूट जाते हैं। इंस्टाग्राम वेब फ्रंटेज Django का उपयोग करते हैं, इसलिए हम StreamingHttpResponse ऑब्जेक्ट का उपयोग करते हैं। इस तरह के तंत्र का उपयोग करने का कारण यह फायदेमंद हो सकता है कि यह पृष्ठ के HTML सामग्री को स्ट्रीमिंग मोड में ब्राउज़र में भेजने की अनुमति देता है क्योंकि पृष्ठ के अलग-अलग हिस्से तैयार होने के बजाय, पूर्ण पृष्ठ कोड के तैयार होने की प्रतीक्षा कर रहे हैं। इसका अर्थ है कि हम अनुरोध प्राप्त करने के तुरंत बाद ब्राउज़र के पृष्ठ शीर्षक को तुरंत फ्लश कर सकते हैं (इसलिए शब्द "शुरुआती फ्लश")। हैडर की तैयारी के लिए विशेष रूप से बड़े सर्वर संसाधनों की आवश्यकता नहीं होती है। यह ब्राउज़र को लिपियों और शैलियों को लोड करना शुरू करने की अनुमति देता है, तब भी जब सर्वर शेष पृष्ठ के लिए गतिशील डेटा बनाने में व्यस्त होता है। आइए एक नज़र डालते हैं कि इस तकनीक का क्या प्रभाव पड़ता है। यह वह है जो एक सामान्य पृष्ठ लोड की तरह दिखता है।

प्रारंभिक फ्लश तकनीक का उपयोग नहीं किया जाता है: संसाधन लोडिंग तब तक शुरू नहीं होती है जब तक कि पेज HTML पूरी तरह से लोड नहीं हो जाता है

लेकिन अगर सर्वर रिक्वेस्ट मिलने पर क्या होता है, तो तुरंत पेज टाइटल को ब्राउजर में भेज देता है।

प्रारंभिक फ्लश तकनीक का उपयोग किया जाता है: ब्राउज़र में HTML टैग डंप होने के तुरंत बाद संसाधन लोड होना शुरू हो जाते हैं

इसके अलावा, हम क्लाइंट को डेटा भेजने के लिए भागों में HTTP संदेश भेजने के तंत्र का उपयोग कर सकते हैं क्योंकि वे तैयार हैं। सर्वर पर प्रदान किए जाने वाले अनुप्रयोगों के मामले में, यह डेटा HTML कोड के रूप में प्रस्तुत किया जा सकता है। लेकिन अगर हम instagram.com जैसे सिंगल-पेज एप्लिकेशन के बारे में बात कर रहे हैं, तो सर्वर क्लाइंट के लिए JSON डेटा जैसे कुछ भी प्रसारित कर सकता है। यह कैसे काम करता है, इस पर एक नज़र डालने के लिए, आइए एकल-पृष्ठ एप्लिकेशन शुरू करने के सबसे सरल उदाहरण पर एक नज़र डालते हैं।

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

किसी पेज को उस स्थिति में लोड करने की प्रक्रिया जहां ब्राउज़र स्वतंत्र रूप से सर्वर से हर उस चीज का अनुरोध करता है जिसकी उसे जरूरत है

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

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

 <script type="text/javascript">  //      API,       ,  //     ,       ,    //        window.__data = {    '/my/api/path': {        waiting: [],    }  };  window.__dataLoaded = function(path, data) {    const cacheEntry = window.__data[path];    if (cacheEntry) {      cacheEntry.data = data;      for (var i = 0;i < cacheEntry.waiting.length; ++i) {        cacheEntry.waiting[i].resolve(cacheEntry.data);      }      cacheEntry.waiting = [];    }  }; </script>

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

 <script type="text/javascript">  window.__dataLoaded('/my/api/path', {    // JSON- API,      ,     //    JSON-...  }); </script>

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

 function queryAPI(path) {  const cacheEntry = window.__data[path];  if (!cacheEntry) {    //   XHR-  API    return fetch(path);  } else if (cacheEntry.data) {    //          return Promise.resolve(cacheEntry.data);  } else {    //       ,    //            //       const waiting = {};    cacheEntry.waiting.push(waiting);    return new Promise((resolve) => {      waiting.resolve = resolve;    });  } }

यह सब इस तथ्य की ओर जाता है कि पृष्ठ को लोड करने की प्रक्रिया निम्न आरेख के समान होती है।

पृष्ठ को उस स्थिति में लोड करने की प्रक्रिया जहां ब्राउज़र क्लाइंट के लिए डेटा तैयार करने में सक्रिय रूप से शामिल होता है

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

इस अनुकूलन का हमारे सिस्टम पर बहुत सकारात्मक प्रभाव पड़ा है। इसलिए, डेस्कटॉप ब्राउज़रों में, पृष्ठ लोडिंग पहले की तुलना में 14% तेजी से पूरा करना शुरू हुआ। और मोबाइल ब्राउज़र में (मोबाइल नेटवर्क में अधिक देरी के कारण) पेज 23% तेजी से लोड होने लगा।

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

त्वरण instagram.com। भाग २

प्रगतिशील HTML डाउनलोड तकनीक का उपयोग करके क्लाइंट के लिए सर्वर द्वारा आरंभ किया गया डेटा सबमिशन

More articles: