हुड टर्बो पेज के तहत: वेबपेज का आर्किटेक्चर फास्ट डाउनलोड टेक्नोलॉजी

नमस्ते, मेरा नाम Stas Makeev है। यैंडेक्स में, मैं टर्बो पृष्ठों के लिए प्रौद्योगिकी के विकास का नेतृत्व करता हूं, जो धीमी गति से कनेक्शन के साथ सामग्री का तेजी से लोडिंग भी प्रदान करता है। आज मैं Habr के पाठकों को हमारे प्रोजेक्ट की वास्तुकला के बारे में थोड़ा बताऊंगा।

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

रूसी मोबाइल नेटवर्क में औसत डाउनलोड गति 16.26 Mbit / s है - यह एक बहुत अच्छा संकेतक है। लेकिन कनेक्शन की गति असमान है, हम अभी भी एक धीमे इंटरनेट कनेक्शन के साथ सामना कर रहे हैं - 3 जी, 2 जी, एज। निश्चित रूप से आप ऐसी स्थिति में थे जहां एक कैफे या शॉपिंग सेंटर में, सड़क पर या किसी देश के घर में, सामान्य उच्च गति बहुत कम हो जाती है: दसियों सेकंड के लिए साइट लोड होती हैं, या इससे भी अधिक समय तक।

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

टर्बो पेज कैसे काम करते हैं

साइट स्वामी Yandex.Webmaster में RSS फ़ीड पंजीकृत करता है। फ़ीड टर्बो पृष्ठ सामग्री प्रणाली में प्रवेश करता है, जो हर कुछ मिनटों में अपडेट लेता है। भारी सामग्री - मुख्य रूप से चित्र और वीडियो - हम कैश करते हैं और एक सीडीएन में बाहर करते हैं। आरएसएस के अलावा, सामग्री को एपीआई और ऑटोपरर के माध्यम से प्रेषित किया जा सकता है।

टर्बो पृष्ठों की कैश्ड छवियों की मात्रा 100 Tb के करीब पहुंच रही है

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

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

जब आप किसी ब्राउज़र में URL खोलते हैं तो क्या होता है?

जब उपयोगकर्ता टर्बो पृष्ठ पर जाता है, तो निम्नलिखित कुछ ऐसा होता है जैसे "हुड के नीचे":



HTTP एडेप्टर उपयोगकर्ता के HTTP अनुरोध को संसाधित करता है और AppHost और रिपोर्ट-रेंडरर में वांछित ग्राफ के लिए अनुरोध करता है।

AppHost एक विशेष घटक है जो एक निर्भरता ग्राफ के रूप में वर्णित स्रोतों के नेटवर्क इंटरैक्शन को एन्क्रिप्ट करता है। इस ग्राफ पर टॉपोलॉजिकल सॉर्टिंग के क्रम में सूत्रों से पूछताछ की जाती है; सभी व्यावसायिक तर्क उनमें और ग्राफ विन्यास में सिल दिए जाते हैं। विशेष रूप से, ग्राफ स्तर पर, केवी-स्टोरेज को प्रदूषित किया जाता है और एक डेटा अनुरोध तीसरे पक्ष के एपीआई को भेजा जाता है।

रिपोर्ट-रेंडरर नोड.जेएस में लिखा गया एक एप्लिकेशन है जो जेएसएन इनपुट को स्वीकार करता है, जेएस में लिखे गए टेम्प्लेट निष्पादित करता है, और एक स्ट्रिंग लौटाता है।

यह सब लगभग तुरंत होता है।

डाउनलोड गति को क्या प्रभावित करता है?

हम गति के सभी पहलुओं पर काम कर रहे हैं: एचटीटीपी / 2 को बैलेंसर पर लागू करने और एसएलजी को मैन्युअल रूप से अनुकूलित करने के लिए टीएलएस हैंडशेक का अनुकूलन करने से। इस मामले में, आपको यह समझने की आवश्यकता है कि अंतिम उपयोगकर्ता की गति क्या है।

टीम के अंदर, हम अनुरोध प्रसंस्करण के तीन चरणों को अलग करते हैं: सर्वर, नेटवर्क और क्लाइंट।

सर्वर

इसमें वह सब कुछ शामिल है जो डेटा केंद्रों में होता है: उस पल से जब एचटीएमएल पेज की पीढ़ी के लिए HTTP अनुरोध हमारे सर्वर पर आता है, जो सीधे क्लाइंट को भेजा जाता है।

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

सर्वर समय में स्रोत निर्भरता ग्राफ के कोने और प्रत्येक कोने के ऑपरेटिंग समय के बीच नेटवर्क इंटरैक्शन होते हैं। लेकिन हम यैंडेक्स डेटा केंद्रों के नेटवर्क बुनियादी ढांचे की सुविधाओं पर ध्यान केंद्रित नहीं करेंगे - वे एक अलग पोस्ट के लायक हैं।

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

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

इस स्तर पर मुख्य मीट्रिक:

• टेम्पलेट समय;
• सारांश पृष्ठ का आकार;
• स्थिर फ़ाइलों का आकार।

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

एक नियम के रूप में, कोड का एक संयुक्त विश्लेषण है और अनुकूलन के तरीकों की खोज करता है।

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

हमारे पास कई "अनुरोध टोकरी" हैं जो हमें टर्बो पृष्ठों के अधिकांश ट्रैफ़िक को कवर करने की अनुमति देते हैं।

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


TurboFan पर स्विच करने के बाद सर्वर टेम्प्लेटिंग समय कम हो गया

नेटवर्क

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

यहाँ हम क्या करते हैं।

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

प्रेषित डेटा का आकार डाउनलोड गति को बहुत प्रभावित कर सकता है, इसलिए हम केवल वही भेजने की कोशिश करते हैं जो वर्तमान पृष्ठ को सबसे कुशल तरीके से चाहिए।

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

हम साइट स्वामियों से एक विशेष सीडीएन में चित्र अपलोड करते हैं, जो छवि प्रतिपादन के लिए अनुकूलित है। हम छवि को पहले sRGB में परिवर्तित करके छवि के exif और color प्रोफाइल को क्रॉप करते हैं। बिट दर प्रति चैनल 8 बिट तक कम हो जाती है, संपीड़न स्तर 85 पर सेट होता है। लैंसजोस फिल्टर का उपयोग आकार बदलने के लिए किया जाता है।

हम अलग-अलग स्क्रीन आकारों के संयोजन के लिए प्रत्येक चित्र के दर्जनों विकल्प बनाते हैं, पिक्सेल घनत्व (रेटिना डिस्प्ले) को ध्यान में रखते हुए। और निश्चित रूप से, हम स्वचालित रूप से वेबपी प्रारूप में छवियों को एन्कोड करते हैं, यदि ब्राउज़र द्वारा समर्थित है।
यदि ब्राउज़र इसका समर्थन करता है, तो पाठ प्रारूप (HTML, जावास्क्रिप्ट, CSS) gzip / zopfli और ब्रेटली का उपयोग करके संपीड़ित किए जाते हैं।

यह महत्वपूर्ण है कि सर्वर से उपयोगकर्ताओं की दूरस्थता के बारे में न भूलें। टर्बो पृष्ठों का उपयोग कई क्षेत्रों में किया जाता है, और सामग्री किसी भी हो सकती है। इसलिए हम समझौता नहीं करते हैं और यहां तक ​​कि सबसे दूरदराज के क्षेत्रों में भी विलंबता को कम करने के लिए हम सीडीएन का उपयोग करते हैं, जो लगातार विस्तार कर रहा है।

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

ग्राहक

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

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

सामग्री चित्र, एम्बेड और विज्ञापन तुरंत लोड नहीं किए जाते हैं, लेकिन जब वे पृष्ठ को पढ़ते हैं, जब वे उपयोगकर्ता के देखने के क्षेत्र के करीब पहुंच जाते हैं।

जावास्क्रिप्ट आंशिक रूप से HTML में एम्बेडेड है, और अन्य सभी स्क्रिप्ट अलग HTTP अनुरोधों के साथ अंत में भरी हुई हैं। आरंभ करने के लिए महत्वपूर्ण लिपियों, त्रुटियों और मैट्रिक्स संग्रह, साथ ही साथ जो घटक अक्सर पृष्ठ पर नहीं पाए जाते हैं वे पृष्ठ में एम्बेडेड होते हैं।

हम RUM पृष्ठ लोड मैट्रिक्स एकत्र करते हैं। सबसे महत्वपूर्ण: पहली बाइट तक का समय, पहली ड्राइंग और अंतःक्रियाशीलता की शुरुआत, जब सभी लिपियों ने आरंभीकरण पूरा कर लिया है और उपयोगकर्ता पृष्ठ का उपयोग कर सकता है।

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

इसलिए हमने अभिन्न गति मीट्रिक तैयार की:
max (firstContentfulPaint, firstImageLoadTime, timeToVisible) — timeToClick

जहां:

• timeToClick - पूर्ण क्लिक समय जिसने टर्बो पृष्ठ का प्रदर्शन किया। यह खोज परिणाम पृष्ठ या Yandex.Zen में एक कार्ड पर एक स्निपेट पर एक क्लिक हो सकता है।
• FirstImageLoadTime - पहली स्क्रीन में पहली सामग्री छवि का पूर्ण लोड समय।
• समय-अदृश्य - पूर्ण समय पृष्ठ दृश्य स्थिति में चला जाता है। यह उन मामलों के लिए सही है जब पृष्ठ को पृष्ठभूमि में लोड किया गया है।

और एक उपयोगकर्ता अनुभव मीट्रिक प्राप्त किया:

• अगर स्क्रीन का 2/3 एक ऐसी छवि के कब्जे में है जिसे अभी तक लोड नहीं किया गया है, तो FirstContentfulPaint मीट्रिक की अखंडता संदिग्ध है;
• लिंक पर बहुत सारे ईवेंट हैंडलर हैं, नॉनज़रो टाइम लोड करने वाले पेज की वास्तविक शुरुआत और क्लिक के बीच, पास हो सकता है, जिसे मैं समझना चाहूंगा।

हम लगातार तकनीक विकसित कर रहे हैं ताकि साइटें अधिक आगंतुकों को आकर्षित करें। अब एक टर्बो पेज एक नियमित मोबाइल संस्करण की तुलना में औसतन 15 गुना तेजी से लोड होता है। हजारों साइटें टर्बो का उपयोग करती हैं, और उनकी कुल यात्राओं की संख्या 12 बिलियन से अधिक है।

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

टर्बो पेज तकनीक के कौन से घटक आप भविष्य में अधिक विस्तृत तकनीकी सामग्री पढ़ना चाहेंगे? आप किस अनुभव में रूचि लेंगे? हम प्रतिक्रिया और विचारों का भी स्वागत करेंगे। धन्यवाद!