ब्राउज़र में संसाधनों को कैसे बचाया जाए और वेब को नहीं तोड़ा जाए। यैंडेक्स रिपोर्ट

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

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

अंत में, वेब इंटरफेस डेवलपर्स सीख सकते हैं कि वेबसाइट के प्रदर्शन के मुद्दों को कैसे पहचाना और हल किया जाए।


- मेरा नाम कोस्त्या है, मैं Yandex.Browser टीम में आंतरिक घटकों के विकास समूह का प्रमुख हूं। ब्राउज़र में, मैं पाँच साल से थोड़ा अधिक समय के लिए अलग-अलग काम कर रहा हूँ: ब्राउज़र में सभी डिकोडिंग से, सभी HTML5 वीडियो से, प्रतिपादन, प्रतिपादन और अन्य समान प्रक्रियाओं के लिए।

पिछले डेढ़ से दो वर्षों से, मैं ब्राउज़र में संसाधनों को बचाने से संबंधित परियोजनाओं में शामिल रहा हूं: सीपीयू, मेमोरी, बैटरी।

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



आप में से कितने लोग अक्सर इस टैब को देखते हैं? सामान्य उपयोगकर्ताओं के मामले में ऐसा ही होता है, जिनके पास कम रैम और पुराने कंप्यूटर होते हैं।



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



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

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



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



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



मुझे लगता है कि कुछ लोग कहेंगे: कोस्त्या, आपने वेब को "तोड़ दिया", कुछ उपयोगकर्ताओं की मदद की, लेकिन कुछ भी होशियार नहीं हुआ। कट्टर जोड़ें! ब्राउज़र पृष्ठ कैसे बनाते हैं?



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

इसके अलावा, प्रत्येक परत को ऐसी टाइलों में विभाजित किया जाता है - 256 द्वारा 256 आयताकार। निरीक्षक में आप कुछ इस तरह देख सकते हैं। एक फ्रेम है जो टाइलों के एक गुच्छा में विभाजित है।





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



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



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



बस इस स्तर पर, कई बहुत सफल अनुकूलन किए गए थे। उदाहरण के लिए, क्रोमियम ने 2017 के आसपास ऐसा अनुकूलन किया।



यदि हमारे पास केवल एक छोटा सा प्रतिपादन है, तो हम केवल इसे करते हैं। तब कर्सर ब्लिंक करता है, और हम केवल कर्सर क्षेत्र को फिर से खोलते हैं, लेकिन इस टाइल का पूरा क्षेत्र नहीं। हम सीपीयू को बहुत बचाते हैं ताकि सब कुछ दोबारा न हो।



यह मेमोरी को बचाने में भी मदद करता है। यहाँ क्या समस्या है? पूरे सफेद आयत। कल्पना कीजिए कि यह 256 से 256 बनावट, पिक्सेल प्रति चार बाइट्स होगा। यद्यपि ऐसा लगता है कि इस क्षेत्र को सिर्फ पांच संख्याओं के साथ कूटबद्ध किया जा सकता है: निर्देशांक, चौड़ाई, ऊंचाई और रंग।



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

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



एक छोटी आयत, एक टाइल है। टाइल के बीच में बहुत कम सामग्री है। हम इसे चुनते हैं और - केवल इसके तहत - बनावट। बाकी सब कुछ भी कई क्षेत्रों में विभाजित है, जिसे हम वीडियो कार्ड के बारे में बात कर रहे हैं: बस इस आकार में सफेद रंग में आकर्षित करें।



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



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

अधिक कट्टर! उन्होंने यहां थोड़ी मेमोरी को सहेजा, उन्होंने वेब को "तोड़ दिया" - वेब को आगे "ब्रेक" क्यों नहीं किया?

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



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

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



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

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



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



हम Yandex.Browser में कुछ साल पहले सोचा था: एक जटिल कार्डिनल दृष्टिकोण का उपयोग क्यों नहीं करते। उन्होंने उसे हाइबरनेट कहा।



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



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



उदाहरण के लिए, एक नमूने पर विचार करें। यहाँ हम ऑनलोड होने की प्रतीक्षा करते हैं, और DOM ट्री में एक नया div एलिमेंट जोड़ते हैं। ब्राउज़र के लिए, यह कुछ इस तरह दिखता है।



स्वाभाविक रूप से, एक डोम ट्री है, इसमें कुछ फ़ील्ड्स, संबंधित ऑब्जेक्ट्स हैं, और ऐसी एक इकाई है।



V8 में, प्रत्येक नोड की स्थिति को संग्रहीत किया जाता है, और ये नोड्स बाइंडरों की एक परत के माध्यम से ब्लिंक ऑब्जेक्ट से जुड़े होते हैं। हमने क्या किया है? हमने V8 से धारावाहिक को लिया, पूरे V8 राज्य को क्रमबद्ध किया, ब्लिंक में सभी संबंधित वस्तुओं को पाया, साथ ही साथ पूरे धारावाहिक पेड़ को बचाने वाले धारावाहिकों को लिखा, इसे क्रमबद्ध करें, फिर डिस्क पर लिखें, संपीड़ित और एन्क्रिप्ट किया गया। और हमने ब्राउज़र को ऐसे स्नैपशॉट से पुनर्प्राप्त करने के लिए सिखाया। यही है, जब उपयोगकर्ता ऐसे टैब पर जाता है, तो हम इसका विस्तार करते हैं, इसे डिक्रिप्ट करते हैं और इसे उपयोगकर्ता को दिखाते हैं, इसे पूरी तरह से पुनर्स्थापित करते हैं। ( हाइबरनेट के बारे में एक अलग पोस्ट - लगभग।)

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

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

पहले आपको यह समझने की ज़रूरत है कि क्या मेमोरी समस्याएं हैं।



कुछ लक्षण हैं: या तो साइट को नीचा दिखाना शुरू होता है, या लुप्त होती दिखाई देता है। आमतौर पर इसका मतलब यह है कि कचरा संग्रहकर्ता को ट्रिगर किया जाता है, पूरी दुनिया जमी है और कुछ भी नहीं खींचा जा रहा है। या कि साइट बस लगातार धीमा हो जाती है - ऐसा भी होता है।

यदि कोई समस्या है तो आपको समझने की आवश्यकता है। हम देखते हैं कि जेएस मेमोरी के साथ क्या होता है।



यदि यह आगे और पीछे कूदता है या लगातार बढ़ता है, तो यह एक अच्छा लक्षण नहीं है। या लगातार बढ़ रहा है।



इस मामले में, आप हमेशा DevTools के माध्यम से एक स्नैपशॉट ले सकते हैं। क्या किसी ने भी JS में लीक से परेशान किया है? यदि कोई नहीं जानता है, तो जेएस में यह एक रिसाव बनाने के लिए काफी संभव है।



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



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



आप टाइमलाइन पर मेमोरी एलोकेशन भी देख सकते हैं। यदि आपके पास व्यवस्थित निर्वहन है और कभी भी सफाई नहीं होती है, तो यह भी एक बुरा संकेत है, मुझे लगता है कि हर कोई इसे समझता है।



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



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

यहां सही दृष्टिकोण है कि आपका कॉलबैक केवल तभी कॉल करेगा जब ब्राउज़र को इस पृष्ठ को खींचने की आवश्यकता होगी।



मैं आपको यह भी याद दिलाना चाहता हूं कि यदि ब्राउज़र प्रति सेकंड 60 फ्रेम खींचना चाहता है, तो इसका मतलब है कि प्रत्येक फ्रेम के लिए इसे लगभग 16 एमएस की आवश्यकता है।



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



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



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



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

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

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

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

यहाँ मैंने विभिन्न उपयोगी लिंक एक साथ रखे हैं:

• Yandex ब्राउज़र में हाइबरनेट करें
• क्रोम में टैब त्यागना
• पृष्ठ जीवनचक्र एपीआई
• माप मॉडल के साथ प्रदर्शन को मापें
• Yandex.Browser में ऊर्जा की बचत
• स्टीम हार्डवेयर आँकड़े
• फ़ायरफ़ॉक्स पब्लिक डेटा रिपोर्ट