पूर्ण हाइड्रेशन की समस्या

हाइड्रेशन वह प्रक्रिया है जिसमें रिएक्ट सर्वर द्वारा रेंडर किए गए HTML को लेकर उसमें JavaScript इवेंट लिसनर जोड़ता है। सर्वर प्रारंभिक HTML तेज़ी से भेजता है, फिर ब्राउज़र JavaScript बंडल डाउनलोड करता है और रिएक्ट स्थिर HTML को "हाइड्रेट" करके उसे इंटरैक्टिव बनाता है। हाइड्रेशन पूरा होने तक पृष्ठ इंटरैक्टिव दिखाई देता है, लेकिन वास्तव में इंटरैक्टिव नहीं होता।

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

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

एक विपणन पृष्ठ पर विचार कीजिए: 80% सामग्री स्थिर पाठ, चित्रों और शीर्षकों से बनी है, जो कभी नहीं बदलते। केवल 20% में न्यूज़लेटर फ़ॉर्म या वीडियो प्लेयर जैसे इंटरैक्टिव विजेट होते हैं। फिर भी पारंपरिक SPA हाइड्रेशन पूरे पृष्ठ के 100% हिस्से पर चलता है और स्थिर घटकों को अनावश्यक रूप से संसाधित करता है।

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

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

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

चयनात्मक हाइड्रेशन (Suspense के माध्यम से) रिएक्ट को प्राथमिकता के क्रम में घटकों को हाइड्रेट करने देता है — उपयोगकर्ता की इंटरैक्शन संबंधित घटक का तत्काल हाइड्रेशन शुरू करती है। इससे प्रतिक्रियाशीलता बेहतर होती है, लेकिन यह अब भी एक ही रिएक्ट ट्री के भीतर काम करता है: ट्री के सभी घटक अंततः हाइड्रेट हो जाते हैं।

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

वेब प्रदर्शन टीमों के अध्ययनों से पता चलता है कि JavaScript को पार्स करने और निष्पादित करने में लगने वाला समय मोबाइल उपकरणों पर प्रमुख लागत है। 300kb के JavaScript बंडल को औसत Android फ़ोन पर पार्स करने में 2-3 सेकंड लगते हैं। ब्राउज़र को भेजे जाने वाले JavaScript को कम करने से रिएक्ट के आंतरिक अनुकूलन की तुलना में बहुत अधिक प्रदर्शन लाभ मिलता है।

रिएक्ट अनुप्रयोग में जोड़े गए JavaScript का प्रत्येक किलोबाइट हाइड्रेशन का काम बढ़ाता है। भले ही कोई घटक केवल सजावटी हो, यदि वह रिएक्ट ट्री में है तो हाइड्रेशन में भाग लेता है। यह "हाइड्रेशन कर" अनुप्रयोग के आकार के साथ बढ़ता है और अनुप्रयोगों के बड़े होने पर अच्छे TTI स्कोर बनाए रखना लगातार कठिन बनाता है।

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