👥 ⏲️ 🍋 जावास्क्रिप्ट मूल्य २०१ 201 👏🏾 🥓 ❄️

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

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

सामान्य प्रावधान

इस रिपोर्ट पर एक नज़र डालें, जो विभिन्न उपकरणों के लिए सीएनएन के जावास्क्रिप्ट कोड को संसाधित करने के लिए आवश्यक समय को प्रदर्शित करता है। यह WebPageTest.org परियोजना के माध्यम से लिए गए मापों के आधार पर बनाया गया है ( यहां इस रिपोर्ट के स्रोत डेटा के साथ एक तालिका है, वॉलमार्ट वेबसाइट पर भी डेटा है)।

विभिन्न उपकरणों के लिए cnn.com JS कोड को संसाधित करने में लगने वाला समय

जैसा कि आप देख सकते हैं, एक उच्च अंत फोन (iPhone 8) लगभग 4 सेकंड में JS कोड को संसाधित करने के कार्य के साथ आता है। इसी समस्या को हल करने के लिए एक मिड-रेंज फोन (Moto G4) को लगभग 13 सेकंड का समय चाहिए। एक बजट, एक आधुनिक उपकरण, जैसे कि अल्काटेल 1 एक्स, के बारे में 36 सेकंड लगते हैं।

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

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

आधुनिक वेब प्रोजेक्ट और जावास्क्रिप्ट के अत्यधिक उपयोग की समस्या

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

यह वही है जो एक ब्राउज़र को लगता है, जो फाइलों से भर गया है

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

जावास्क्रिप्ट साइट का सबसे कठिन हिस्सा है

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

एक औसत पृष्ठ, जिसमें 350 KB का संपीडित JS कोड मोबाइल डिवाइस पर लगभग 15 सेकंड में संवादात्मक हो जाता है

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

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

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

4 जी नेटवर्क की उपलब्धता और डेटा दर

हमने ऊपर कहा है कि 350 KB की मिनिफाइज्ड और कंप्रेस्ड जेएस कोड को डाउनलोड करने और पार्स करने में एक निश्चित समय लगता है। हालांकि, यदि आप लोकप्रिय साइटों को देखते हैं, तो यह पता चला है कि वे उपयोगकर्ताओं को बहुत अधिक कोड भेजते हैं। नीचे दिए गए आंकड़े में दिखाया गया डेटा यहां से लिया गया है । वे विभिन्न प्रसिद्ध वेब संसाधनों के अनपैक किए गए जावास्क्रिप्ट बंडलों के आकार हैं, जैसे कि Google शीट्स, अनपैक्ड जेएस-कोड, जो डेस्कटॉप प्लेटफॉर्म पर 5.8 एमबी का है।

विभिन्न संसाधनों के लिए अनपैक्ड जावास्क्रिप्ट असेंबली आकार

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

जावास्क्रिप्ट मुक्त नहीं है

एलेक्स रसेल के अनुसार, जिन साइटों को काम करने के लिए बहुत बड़ी मात्रा में जावास्क्रिप्ट की आवश्यकता होती है, वे केवल उपयोगकर्ताओं की विस्तृत परतों तक पहुंच योग्य नहीं होती हैं। आंकड़ों के मुताबिक, उपयोगकर्ता ऐसे संसाधनों के लोड के लिए इंतजार नहीं करेंगे (और इंतजार नहीं करेंगे)।

क्या आप इसे बर्दाश्त कर सकते हैं?

यदि आपको उपयोगकर्ताओं को बहुत बड़ी मात्रा में JS कोड भेजना है, तो बंडलों को छोटे भागों में तोड़ने के लिए कोड विभाजन तकनीक का उपयोग करने पर विचार करें, या ट्री-शेकिंग एल्गोरिदम का उपयोग करके कोड की मात्रा को कम करें।

आधुनिक साइटों के जेएस बंडलों में अक्सर निम्नलिखित शामिल होते हैं:

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

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

वेब पेज लोड करने की प्रक्रिया प्रोजेक्टर में चलती फिल्म के समान है, जो निम्नलिखित सवालों के जवाब देने वाले तीन प्रमुख चरणों को पकड़ती है:

क्या ऐसा हो रहा है? (यह हो रहा है?)।
इसका क्या उपयोग है? (क्या यह उपयोगी है?)।
क्या इसका उपयोग किया जा सकता है? (क्या यह प्रयोग करने योग्य है?)।

यहां बताया गया है कि इन चरणों की कल्पना कैसे करें, जो बदले में, छोटे "फ्रेम" में विभाजित किए जा सकते हैं, अगर हम फिल्म के साथ सादृश्य जारी रखें।

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

वेब पेज लोड करने की प्रक्रिया

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

इंटरएक्टिव पेज और उनकी समस्याएं

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

उपयोगकर्ता उन पृष्ठों से परेशान होते हैं जो तैयार होने में बहुत लंबा समय लेते हैं

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

यदि उपयोगकर्ता लिंक पर क्लिक करता है या पृष्ठ को स्क्रॉल करता है, तो उसे यह देखने की जरूरत है, कि उसके कार्यों के जवाब में, कुछ होता है। यदि पेज उपयोगकर्ताओं के प्रभाव का जवाब नहीं देता है, तो वे इसे पसंद नहीं करते हैं।

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

लाइटहाउस रिपोर्ट, जिसमें संकेतक शामिल हैं जो पृष्ठ की उपयोगकर्ता की धारणा को दर्शाते हैं

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

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

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

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

उन स्थितियों को कम करने की कोशिश करें जिनमें मुख्य धागा अवरुद्ध हो सकता है। यहां वह सामग्री है जहां आप इस बारे में विवरण पा सकते हैं।

हम देखते हैं कि हम जिन टीमों के साथ काम करते हैं, वे TTI में कई प्रकार की साइटों पर अभिनय करती हैं।

इंटरैक्टिव मोड में दृश्य तत्वों के उत्पादन में देरी करने में जावास्क्रिप्ट सक्षम है

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

टीटीआई और मोबाइल डिवाइस

धीमे 3G इंटरनेट कनेक्शन का उपयोग करते समय news.google.com के लिए TTI दिए गए हैं। यहां आप वह डेटा देख सकते हैं जिसके आधार पर यह आरेख बनाया गया है। माप वेबपेजेस्ट और लाइटहाउस के माध्यम से किए जाते हैं।

News.google.com के लिए टीटीआई

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

यहां हमारे पास एक सवाल है कि टीटीआई क्या होना चाहिए। हमारा मानना है कि आपको कम से कम 5 सेकंड में 3 जी नेटवर्क से जुड़े मध्य-श्रेणी के उपकरणों पर पृष्ठों को अधिक इंटरैक्टिव बनाने का प्रयास करना चाहिए।

यह 5 सेकंड में टीटीआई के लिए प्रयास करने योग्य है

शायद यहां आप कहेंगे कि आपके सभी उपयोगकर्ताओं के पास टॉप-एंड फोन हैं और वे तेज नेटवर्क से जुड़े हैं। हालाँकि, क्या वास्तव में ऐसा है? शायद कोई किसी कैफे में "तेज" वाई-फाई नेटवर्क से जुड़ा है, लेकिन वास्तव में, केवल 2 जी या 3 जी कनेक्शन की गति विशेषता उसके पास उपलब्ध है। उपयोगकर्ताओं की क्षमताओं का आकलन करते हुए, कोई भी उस नेटवर्क तक पहुँचने के लिए विभिन्न प्रकार के उपकरणों और विधियों का उपयोग नहीं कर सकता है।

टीटीआई पर जेएस कोड डाउन होने का प्रभाव

जेएस पेज कोड प्रभावित टीटीआई के आकार को कम करने के कुछ उदाहरण यहां दिए गए हैं।

Pinterest प्रोजेक्ट ने JS बंडलों को 2.5 MB से घटाकर 200 KB से कम कर दिया। अन्तरक्रियाशीलता का समय 23 सेकंड से घटकर 5.6 सेकंड हो गया। कंपनी के राजस्व में 44% की वृद्धि हुई, सदस्यता की संख्या में 753% की वृद्धि हुई, साइट के मोबाइल संस्करण के सक्रिय साप्ताहिक उपयोगकर्ताओं की संख्या में 103% की वृद्धि हुई ।
ऑटोट्रैडर ने जेएस बंडल को 56% तक कम कर दिया , जिसके परिणामस्वरूप टीटीआई में लगभग 50% की कमी आई।
Nikkei.com संसाधन ने JS बंडल के आकार में 43% की कटौती की, जिसने TTI को 14 सेकंड तक सुधारने की अनुमति दी।

ये परिणाम बताते हैं कि साइटों को एक लचीले मोबाइल वातावरण के लिए डिज़ाइन किया जाना चाहिए, और साथ ही यह सुनिश्चित करने का प्रयास करें कि वे जावास्क्रिप्ट कोड के बड़े संस्करणों से बंधे नहीं हैं।

डिजाइनिंग साइट्स एक लचीले मोबाइल वातावरण पर आधारित हैं

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

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

जावास्क्रिप्ट इतना महंगा क्यों है?

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

तो, यह सब इस तथ्य से शुरू होता है कि उपयोगकर्ता उस साइट के URL में प्रवेश करता है जिस पर वह ब्राउज़र के एड्रेस बार में जाना चाहता है।

यह सब ब्राउज़र के एड्रेस बार में एक URL दर्ज करने के साथ शुरू होता है

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

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

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

जावास्क्रिप्ट के साथ काम को गति कैसे दें?

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

जावास्क्रिप्ट गति में लोडिंग, पार्सिंग, संकलन और निष्पादन कोड की गति होती है

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

उपरोक्त प्रक्रियाओं के कुछ आंकड़ों पर विचार करें। यहाँ पर अधिक है कि कैसे V8 , क्रोम में प्रयुक्त जावास्क्रिप्ट इंजन, स्क्रिप्ट वाले समय प्रसंस्करण पृष्ठों को खर्च करता है।

पृष्ठ लोड करते समय V8 में पार्सिंग और संकलन चरणों का 10-30% समय लगता है

लोकप्रिय साइटों के कोड को पार्स करने के लिए आवश्यक समय का प्रतिनिधित्व करने वाले अंशों को नारंगी में हाइलाइट किया गया है। पीला संकलन समय का प्रतिनिधित्व करता है। साथ में, ये दो चरण पृष्ठ JS कोड को संसाधित करने के लिए आवश्यक कुल समय का लगभग 30% लेते हैं। 30% एक गंभीर आंकड़ा है।

Chrome 66 में, V8 बैकग्राउंड थ्रेड में कोड संकलित करता है , जो संकलन समय का 20% तक बचा सकता है। हालांकि, पार्सिंग और संकलन अभी भी बहुत महंगा ऑपरेशन है, इसलिए आप शायद ही कभी एक बड़ी स्क्रिप्ट देखते हैं जो 50 एमएस से कम में निष्पादित होने लगती है। लोड होने के बाद, भले ही इसे बैकग्राउंड थ्रेड में संकलित किया गया हो।

जावास्क्रिप्ट अन्य संसाधनों से कैसे भिन्न है?

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

जावास्क्रिप्ट कोड के 200 KB और एक ही आकार की JPEG फाइल दो अलग-अलग चीजें हैं।

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

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

मोबाइल वेब और डिवाइस विविधता

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

विभिन्न मोबाइल उपकरणों

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

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

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

यहाँ newzoo द्वारा वर्तमान में उपयोग किए गए Android स्मार्टफ़ोन के एक अध्ययन के परिणाम हैं। जैसा कि आप देख सकते हैं, एंड्रॉइड ओएस उपयोग किए गए 75.9% फोन पर स्थापित है, जबकि यह उम्मीद है कि 2018 में उनके लिए एक और 300 मिलियन डिवाइस जोड़े जाएंगे। इनमें से कई नए डिवाइस बजट के अनुकूल होंगे।

2018 में एंड्रॉइड स्मार्टफोन

आइए देखें कि विभिन्न आधुनिक उपकरणों पर जावास्क्रिप्ट को पार्स और संकलित करने में कितना समय लगता है। यहाँ कच्चे डेटा हैं।

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

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

समय के साथ, एंड्रॉइड चलाने वाले फोन सस्ते हो जाते हैं , लेकिन तेज नहीं । आमतौर पर, सस्ते फोन छोटे L2 / L3 कैश के साथ कमजोर प्रोसेसर का उपयोग करते हैं। नतीजतन, यदि आप शीर्ष स्तर के उपकरणों पर ध्यान केंद्रित करते हैं, तो आप औसत उपयोगकर्ता की जरूरतों को पूरी तरह से अनदेखा कर सकते हैं जिनके पास ऐसा उपकरण नहीं है।

आइए एक वास्तविक साइट के साथ उदाहरण के लिए लौटें, जिसे हमने पहले ही छू लिया है। माप WebPageTest का उपयोग करके किए गए थे, यहां स्रोत डेटा है।

विभिन्न उपकरणों के लिए cnn.com JS कोड को संसाधित करने में लगने वाला समय

IPhone 8 पर ( A11 चिप का उपयोग करते हुए), प्रोसेसिंग में मिड-रेंज फोन की तुलना में 9 सेकंड अधिक तेज होता है। हम इस तथ्य के बारे में बात कर रहे हैं कि iPhone 8 पर साइट 9 सेकंड पहले इंटरैक्टिव होगी।

अब जब WebPageTest अल्काटेल 1X का समर्थन करता है (यह फोन यूएसए में लगभग 100 डॉलर में बेचा गया था, तो यह बिक्री के शुरू में बेचा गया था), हम प्रवेश-स्तर और मध्य-श्रेणी के फोन पर cnn.com वेबसाइट की " स्टोरीबोर्ड " देख सकते हैं। अल्काटेल 1 एक्स ने 65 सेकंड में 3 जी नेटवर्क का उपयोग करके साइट को पूरी तरह से लोड किया। यह "धीमा" भी नहीं है। यह बस अस्वीकार्य है।

Alcatel 1X, Moto G gen 1, Moto G4 के साथ cnn.com डाउनलोड करें

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

यह मत मानिए कि सभी उपयोगकर्ता तेज नेटवर्क और शक्तिशाली उपकरणों का उपयोग करते हैं।

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

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

परीक्षण साइटें वास्तविक नेटवर्क से जुड़े वास्तविक उपकरणों पर होती हैं

यदि आपके स्वयं के मिड-रेंज फोन के साथ विकल्प आपको सूट नहीं करता है, तो मोबाइल परीक्षण कॉन्फ़िगरेशन का चयन करते समय WebPageTest प्रोजेक्ट अनुकूलित Moto G4 फोन तक पहुंच प्रदान करता है। वहाँ अन्य विन्यास हैं।

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

अपने दर्शकों को जानें

यह ध्यान दिया जाना चाहिए कि 2 जी नेटवर्क से जुड़े एंट्री-लेवल डिवाइस पर हर साइट को अच्छी तरह से काम नहीं करना चाहिए। , — .

, , Google Analytics → Audience → Mobile → Devices. .

Google Analytics

, . — , , , , .

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );