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

हाल के वर्षों में, instagram.com पर बहुत सी नई चीजें सामने आई हैं। बहुत कुछ। उदाहरण के लिए - कहानी कहने के उपकरण, फिल्टर, रचनात्मक उपकरण, सूचनाएं, प्रत्यक्ष संदेश। हालाँकि, जैसे-जैसे परियोजना बढ़ती गई, इस सब ने एक दुःखद पक्ष प्रभाव दिया, जो कि instagram.com के प्रदर्शन में गिरावट आने लगी। पिछले एक साल से इंस्टाग्राम डेवलपमेंट टीम ने इसे ठीक करने के लिए लगातार प्रयास किए हैं। इससे यह तथ्य सामने आया कि इंस्टाग्राम फीड (फीड पेज) का कुल लोडिंग समय लगभग 50% कम हो गया।



आज हम लेखों की एक श्रृंखला से पहली सामग्री का एक अनुवाद प्रकाशित करते हैं जो कि कैसे instagram.com की कहानी को समर्पित किया गया था।

वेब परियोजनाओं के प्रदर्शन के अनुकूलन के बारे में

पिछले एक साल में प्रदर्शन में सुधार (इंस्टाग्राम फीड, प्रदर्शन किया मीट्रिक, एमएस।)

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

छवियों, जावास्क्रिप्ट कोड और सामग्री को लोड करने के बारे में एक कहानी जो प्रश्नों को पूरा करने के लिए आवश्यक है, साथ ही साथ जहां सावधान रहना चाहिए

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

प्रतीक्षा करने के बजाय जब तक कि ब्राउज़र खुद इन संसाधनों को नहीं खोज लेता, हम इसे एक संकेत दे सकते हैं, जिसके बाद यह तुरंत उन्हें डाउनलोड करना शुरू कर सकता है। हमने यह preload HTML विशेषताओं का उपयोग करके किया था। यह कुछ इस तरह दिखता है:

 <link rel="preload" href="my-js-file.js" as="script" type="text/javascript" /> 

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

उदाहरण के लिए, जब FeedPage प्रविष्टि बिंदु के साथ काम करते हैं FeedPage तो हम जानते हैं कि क्लाइंट राउटर अंततः FeedPageContainer.js को डाउनलोड करने का अनुरोध पूरा करेगा। परिणामस्वरूप, हम निम्नलिखित निर्माण को पेज कोड में जोड़ सकते हैं:

 <link rel="preload" href="/static/FeedPageContainer.js" as="script" type="text/javascript" /> 

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

 <link rel="preload" href="/graphql/query?id=12345" as="fetch" type="application/json" /> 

पृष्ठ लोडिंग सुविधाओं में परिवर्तन विशेष रूप से धीमी कनेक्शन पर ध्यान देने योग्य हैं। तेजी से 3 जी कनेक्शन (नीचे पहला वॉटरफॉल चार्ट, जो संसाधन FeedPageContainer.js लोडिंग का उपयोग नहीं किए जाने पर स्थिति को दिखाता है) का अनुकरण करके, हम देख सकते हैं कि लोडिंग FeedPageContainer.js लोड हो FeedPageContainer.js और Consumer.js लोड होने के बाद ही शुरू होने वाले ग्राफक्लाइन क्वेरी को निष्पादित कर रहा है। हालाँकि, उस स्थिति में जहां FeedPageContainer.js का उपयोग किया जाता है, FeedPageContainer.js स्क्रिप्ट को लोड करना और HTML पृष्ठ उपलब्ध होने के तुरंत बाद ग्राफक्लाइन क्वेरी को निष्पादित करना शुरू हो सकता है। इसके अलावा, आलसी लोडिंग तंत्र का उपयोग करने वाली किसी भी छोटी स्क्रिप्ट को डाउनलोड करने के लिए आवश्यक समय कम कर देता है। यहां FeedSidebarContainer.js और ActivityFeedBox.js (जो FeedPageContainer.js पर निर्भर करते हैं) Consumer.js को संसाधित करने के तुरंत बाद लोड करना शुरू करते हैं।


प्रीलोड का उपयोग नहीं किया गया


प्रीलोड का इस्तेमाल किया

प्रीलोड को प्राथमिकता देने के लाभ

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

अधिभार प्राथमिकता मुद्दे

प्री-लोडिंग संसाधनों की समस्या इस तथ्य में निहित है कि यह डेवलपर को संसाधन लोडिंग की प्राथमिकता को प्रभावित करने के लिए अतिरिक्त लाभ देता है। इसका मतलब यह है कि डेवलपर के पास उचित प्राथमिकता के लिए अधिक जिम्मेदारी है। उदाहरण के लिए, ऐसे क्षेत्रों में एक साइट का परीक्षण करते समय जिसमें मोबाइल और वाईफाई नेटवर्क की गति बहुत कम होती है, और जिसमें पैकेट नुकसान का एक बड़ा प्रतिशत देखा जाता है, हमने देखा कि <link rel="preload" as="script"> के प्रसंस्करण के दौरान निष्पादित अनुरोध के <link rel="preload" as="script"> उस अनुरोध की तुलना में एक उच्च प्राथमिकता प्राप्त करता है जिसे क्रियान्वित करते समय महत्वपूर्ण पृष्ठ रेंडरिंग पथों में उपयोग किए जाने वाले जावास्क्रिप्ट बंडलों के <script /> संसाधित किया जाता है। यह समग्र पृष्ठ लोड समय में वृद्धि की ओर जाता है।

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

 <!--   ,    --> <link rel="preload" href="SomeConsumerRoute.js" as="script" /> <link rel="preload" href="..." as="script" /> ... <!-- ,      --> <script src="Common.js" type="text/javascript"></script> <script src="Consumer.js" type="text/javascript"></script> 

उदाहरण के लिए, लॉगआउट पृष्ठ पर, हम SomeConsumerRoute.js को Common.js और Consumer.js लोड करते हैं, और चूंकि प्रीलोड संसाधन उच्च प्राथमिकता के साथ लोड किए जाते हैं, लेकिन उन्हें पार्स नहीं किया जाता है, यह Common.js और Consumer.js पार्सिंग को ब्लॉक Common.js Consumer.js । Chrome डेटा सेवर विकास टीम ने एक समान प्रीलोड समस्या पाई और इस समस्या के उनके समाधान का वर्णन किया । उनके मामले में, हमेशा उन संसाधनों के <script /> टैग के बाद अतुल्यकालिक संसाधनों को लोड करने के लिए निर्माण करने का निर्णय लिया गया था जो इन अतुल्यकालिक संसाधनों का उपयोग करते हैं। हमने सभी स्क्रिप्ट को प्रीलोड करने का निर्णय लिया और कोड में संबंधित कंस्ट्रक्शन को उस क्रम में रखा, जिस क्रम में उनकी आवश्यकता होगी। इससे हमें पृष्ठ के सभी स्क्रिप्ट संसाधनों को यथासंभव जल्दी से लोड करने का अवसर मिलता है। इसमें सिंक्रोनस लोडिंग स्क्रिप्ट के लिए टैग शामिल हैं जिन्हें HTML में तब तक नहीं जोड़ा जा सकता जब तक कि पेज पर विशिष्ट सर्वर डेटा नहीं रखा जाता है। इससे हम स्क्रिप्ट के लोडिंग ऑर्डर को नियंत्रित कर सकते हैं।

यहाँ वह मार्कअप है जो सभी जावास्क्रिप्ट बंडलों को पहले से लोड करता है।

 <!--      --> <link rel="preload" href="Common.js" as="script" /> <link rel="preload" href="Consumer.js" as="script" /> <!--   ,    --> <link rel="preload" href="SomeConsumerRoute.js" as="script" /> ... <!-- ,      --> <script src="Common.js" type="text/javascript"></script> <script src="Consumer.js" type="text/javascript"></script> <script src="SomeConsumerRoute.js" type="text/javascript" async></script> 

छवि प्रीलोड

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

व्यवहार में, यह, कई कारणों से, एक आसान काम नहीं है:

• हमें उन सामग्रियों को डाउनलोड करने की आवश्यकता है जो उपयोगकर्ता को दिखाई नहीं दे रहे हैं, ताकि वे उन सामग्रियों से नेटवर्क और प्रोसेसर संसाधन न लें जो वह देख रहे हैं।
• हम नेटवर्क पर अनावश्यक डेटा प्रसारित नहीं करना चाहेंगे, प्रकाशनों को प्रीलोड करने की बहुत कोशिश कर रहे हैं जो उपयोगकर्ता भी नहीं देख सकता है। लेकिन, दूसरी ओर, यदि हम पर्याप्त मात्रा में सामग्री को प्रीलोड नहीं करते हैं, तो इसका मतलब यह होगा कि उपयोगकर्ता टेप के अंत में "रन" करेगा।
• Instagram.com प्रोजेक्ट को विभिन्न उपकरणों और विभिन्न आकारों की स्क्रीन पर काम करने के लिए डिज़ाइन किया गया है। परिणामस्वरूप, हम टेप में छवियों को <img> की srcset विशेषता का उपयोग करके प्रदर्शित करते हैं। यह विशेषता स्क्रीन के आकार को देखते हुए ब्राउज़र का उपयोग करने की अनुमति देती है, यह तय करने के लिए कि किस छवि संकल्प का उपयोग करना है। इसका मतलब यह है कि हमारे लिए पहले से डाउनलोड की जाने वाली छवियों के समाधान को निर्धारित करना इतना आसान नहीं है। इसके अलावा, उन छवियों को प्रीलोड करने का जोखिम है जो ब्राउज़र उपयोग नहीं करेगा।

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


शुरुआत में और टेप के बीच में, डेटा प्रीलोड कार्य में प्राथमिकता निष्क्रिय होती है, और टेप के अंत में प्राथमिकता अधिक होती है

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

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

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