वेब डेवलपर को यह फ़ैसला लेना होता है कि अपने ऐप्लिकेशन में लॉजिक और रेंडरिंग को कहां लागू करना है. यह मुश्किल हो सकता है, क्योंकि वेबसाइट बनाने के कई तरीके हैं.
इस स्पेस के बारे में हमारी समझ, Chrome में पिछले कुछ सालों से बड़ी साइटों के साथ बातचीत करने के हमारे काम से मिली है. आम तौर पर, हम डेवलपर को पूरी तरह से फिर से हाइड्रेट करने के बजाय, सर्वर साइड रेंडरिंग या स्टैटिक रेंडरिंग का इस्तेमाल करने का सुझाव देते हैं.
यह फ़ैसला लेते समय, हमें उन आर्किटेक्चर को बेहतर तरीके से समझना होगा जिनमें से हमें किसी एक को चुनना है. इसके लिए, हमें हर तरीके के बारे में अच्छी तरह से जानना होगा. साथ ही, इनके बारे में बात करते समय, एक जैसी शब्दावली का इस्तेमाल करना होगा. रेंडर करने के तरीकों के बीच के अंतर से, पेज की परफ़ॉर्मेंस के हिसाब से, वेब पर रेंडर करने के फ़ायदे और नुकसान के बारे में पता चलता है.
शब्दावली
सबसे पहले, हम कुछ शब्दों की परिभाषा देते हैं जिनका इस्तेमाल हम करेंगे.
रेंडरिंग
- सर्वर साइड रेंडरिंग (एसएसआर)
- क्लाइंट को JavaScript के बजाय एचटीएमएल भेजने के लिए, सर्वर पर ऐप्लिकेशन को रेंडर करना.
- क्लाइंट-साइड रेंडरिंग (सीएसआर)
- DOM में बदलाव करने के लिए, JavaScript का इस्तेमाल करके ब्राउज़र में ऐप्लिकेशन को रेंडर करना.
- शरीर में पानी की कमी पूरी करना
- क्लाइंट पर JavaScript व्यू को "बूट अप" करना, ताकि वे सर्वर से रेंडर किए गए एचटीएमएल के डीओएम ट्री और डेटा का फिर से इस्तेमाल कर सकें.
- प्रीरेंडरिंग
- बिल्ड के समय क्लाइंट-साइड ऐप्लिकेशन को चलाना, ताकि उसकी शुरुआती स्थिति को स्टैटिक एचटीएमएल के तौर पर कैप्चर किया जा सके.
परफ़ॉर्मेंस
- टाइम टू फ़र्स्ट बाइट (TTFB)
- किसी लिंक पर क्लिक करने और नए पेज पर कॉन्टेंट के पहले बाइट के लोड होने के बीच का समय.
- फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी)
- अनुरोध किया गया कॉन्टेंट (लेख का मुख्य हिस्सा वगैरह) दिखने में लगने वाला समय.
- पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)
- यह एक मेट्रिक है, जिससे यह पता चलता है कि कोई पेज, उपयोगकर्ता के इनपुट का जवाब तुरंत देता है या नहीं.
- टोटल ब्लॉकिंग टाइम (टीबीटी)
- INP के लिए एक प्रॉक्सी मेट्रिक, जो यह हिसाब लगाती है कि पेज लोड होने के दौरान मुख्य थ्रेड कितनी देर तक ब्लॉक रहा.
सर्वर साइड रेंडरिंग
सर्वर-साइड रेंडरिंग, नेविगेशन के जवाब में सर्वर पर किसी पेज के लिए पूरा एचटीएमएल जनरेट करती है. इससे क्लाइंट पर डेटा फ़ेच करने और टेंप्लेट बनाने के लिए, अतिरिक्त राउंड ट्रिप से बचा जा सकता है. ऐसा इसलिए होता है, क्योंकि ब्राउज़र को जवाब मिलने से पहले रेंडरर उन्हें मैनेज कर लेता है.
सर्वर साइड रेंडरिंग की मदद से, आम तौर पर तेज़ी से एफ़सीपी मिलता है. सर्वर पर पेज लॉजिक और रेंडरिंग करने से, क्लाइंट को बहुत सारा JavaScript भेजने से बचा जा सकता है. इससे पेज के टीबीटी को कम करने में मदद मिलती है. साथ ही, इससे आईएनपी भी कम हो सकता है, क्योंकि पेज लोड होने के दौरान मुख्य थ्रेड को अक्सर ब्लॉक नहीं किया जाता. जब मुख्य थ्रेड को कम बार ब्लॉक किया जाता है, तो उपयोगकर्ता इंटरैक्शन के जल्दी चलने के ज़्यादा अवसर होते हैं. ऐसा इसलिए होता है, क्योंकि सर्वर साइड रेंडरिंग की मदद से, उपयोगकर्ता के ब्राउज़र पर सिर्फ़ टेक्स्ट और लिंक भेजे जाते हैं. यह तरीका, अलग-अलग डिवाइस और नेटवर्क की स्थितियों के लिए बेहतर तरीके से काम कर सकता है. साथ ही, इससे ब्राउज़र को ऑप्टिमाइज़ करने के दिलचस्प तरीके भी मिलते हैं. जैसे, दस्तावेज़ को स्ट्रीम करके पार्स करना.
सर्वर-साइड रेंडरिंग की मदद से, उपयोगकर्ताओं को आपकी साइट इस्तेमाल करने से पहले, सीपीयू पर काम करने वाले JavaScript के चलने का इंतज़ार नहीं करना पड़ता. तीसरे पक्ष की JS का इस्तेमाल करने से बचने के लिए, सर्वर-साइड रेंडरिंग का इस्तेमाल करें. इससे, पहले पक्ष की JavaScript लागत कम करने के साथ-साथ, बाकी चीज़ों के लिए ज़्यादा बजट मिल सकता है. हालांकि, इस तरीके का एक नुकसान भी है: सर्वर पर पेज जनरेट करने में समय लगता है. इससे आपके पेज का टीटीएफ़बी (पेज लोड होने में लगने वाला समय) बढ़ सकता है.
आपके ऐप्लिकेशन के लिए सर्वर साइड रेंडरिंग काफ़ी है या नहीं, यह इस बात पर निर्भर करता है कि आपने किस तरह का अनुभव बनाने के लिए इसे बनाया है. सर्वर साइड रेंडरिंग और क्लाइंट साइड रेंडरिंग के सही इस्तेमाल को लेकर, लंबे समय से बहस चल रही है. हालांकि, आपके पास कुछ पेजों के लिए सर्वर साइड रेंडरिंग का इस्तेमाल करने और कुछ के लिए नहीं करने का विकल्प हमेशा होता है. कुछ साइटों ने हाइब्रिड रेंडरिंग तकनीकों को अपनाकर सफलता हासिल की है. उदाहरण के लिए, Netflix अपने अपेक्षाकृत स्टैटिक लैंडिंग पेजों को सर्वर से रेंडर करता है. साथ ही, इंटरैक्शन वाले ज़्यादा पेजों के लिए JS को prefetching करता है. इससे, क्लाइंट से रेंडर किए जाने वाले इन ज़्यादा पेजों को तेज़ी से लोड होने में मदद मिलती है.
कई आधुनिक फ़्रेमवर्क, लाइब्रेरी, और आर्किटेक्चर की मदद से, क्लाइंट और सर्वर, दोनों पर एक ही ऐप्लिकेशन को रेंडर किया जा सकता है. इन तकनीकों का इस्तेमाल, सर्वर-साइड रेंडरिंग के लिए किया जा सकता है. हालांकि, ऐसे आर्किटेक्चर जिनमें रेंडरिंग, सर्वर और क्लाइंट, दोनों पर होती है वे अपनी तरह के समाधान हैं. इनकी परफ़ॉर्मेंस की विशेषताएं और ट्रेड-ऑफ़ एक-दूसरे से काफ़ी अलग होते हैं. React के उपयोगकर्ता, सर्वर साइड रेंडरिंग के लिए, सर्वर डीओएम एपीआई या उन पर आधारित समाधानों का इस्तेमाल कर सकते हैं. जैसे, Next.js. Vue के उपयोगकर्ता, Vue की सर्वर साइड रेंडरिंग गाइड या Nuxt का इस्तेमाल कर सकते हैं. Angular में यूनिवर्सल है. हालांकि, ज़्यादातर लोकप्रिय समाधानों में हाइड्रेशन का इस्तेमाल किया जाता है. इसलिए, अपने टूल के इस्तेमाल के तरीकों के बारे में ज़रूर जानें.
स्टैटिक रेंडरिंग
स्टैटिक रेंडरिंग, बिडिंग के समय होती है. इस तरीके से, फ़र्स्ट कॉन्टेंट लोड होने में लगने वाला समय कम होता है. साथ ही, टीबीटी और आईएनपी भी कम होता है. हालांकि, इसके लिए ज़रूरी है कि आप अपने पेजों पर क्लाइंट-साइड JS की संख्या सीमित रखें. सर्वर-साइड रेंडरिंग के मुकाबले, यह लगातार तेज़ टीटीएफ़बी भी हासिल करता है. ऐसा इसलिए होता है, क्योंकि किसी पेज के लिए एचटीएमएल को सर्वर पर डाइनैमिक तौर पर जनरेट करने की ज़रूरत नहीं होती. आम तौर पर, स्टैटिक रेंडरिंग का मतलब है कि हर यूआरएल के लिए, समय से पहले एक अलग एचटीएमएल फ़ाइल तैयार करना. पहले से जनरेट किए गए एचटीएमएल रिस्पॉन्स की मदद से, एज कैश मेमोरी का फ़ायदा पाने के लिए, एक से ज़्यादा सीडीएन पर स्टैटिक रेंडर डिप्लॉय किए जा सकते हैं.
स्टैटिक रेंडरिंग के लिए कई तरह के समाधान उपलब्ध हैं. Gatsby जैसे टूल, डेवलपर को यह अहसास दिलाने के लिए डिज़ाइन किए गए हैं कि उनके ऐप्लिकेशन को डाइनैमिक तौर पर रेंडर किया जा रहा है, न कि बिल्ड के चरण के तौर पर जनरेट किया जा रहा है. 11ty, Jekyll, और Metalsmith जैसे स्टैटिक साइट जनरेशन टूल, टेंप्लेट पर आधारित तरीके का इस्तेमाल करके, स्टैटिक साइट जनरेट करते हैं.
स्टैटिक रेंडरिंग की एक समस्या यह है कि इसे हर संभावित यूआरएल के लिए अलग-अलग एचटीएमएल फ़ाइलें जनरेट करनी पड़ती हैं. अगर आपको पहले से यह पता नहीं है कि वे यूआरएल क्या होंगे, तो ऐसा करना मुश्किल हो सकता है. इसके अलावा, जिन साइटों पर यूनीक पेजों की संख्या ज़्यादा होती है उनके लिए भी ऐसा करना मुश्किल हो सकता है.
React का इस्तेमाल करने वाले लोग, Gatsby, Next.js स्टैटिक एक्सपोर्ट या Navi के बारे में जानते होंगे. इनकी मदद से, कॉम्पोनेंट से पेज बनाना आसान हो जाता है. हालांकि, स्टैटिक रेंडरिंग और पहले से रेंडर करने की सुविधा अलग-अलग तरीके से काम करती है: स्टैटिक तौर पर रेंडर किए गए पेज, क्लाइंट-साइड JavaScript को ज़्यादा चलाए बिना इंटरैक्टिव होते हैं. वहीं, पहले से रेंडर करने की सुविधा, एक पेज वाले ऐप्लिकेशन के एफ़सीपी को बेहतर बनाती है. पेजों को असल में इंटरैक्टिव बनाने के लिए, उन्हें क्लाइंट पर बूट करना ज़रूरी होता है.
अगर आपको नहीं पता कि कोई दिया गया समाधान स्टैटिक रेंडरिंग है या पहले से रेंडर किया गया पेज, तो JavaScript को बंद करके उस पेज को लोड करें जिसकी आपको जांच करनी है. स्टैटिक तौर पर रेंडर किए गए पेजों के लिए, ज़्यादातर इंटरैक्टिव सुविधाएं अब भी JavaScript के बिना काम करती हैं. पहले से रेंडर किए गए पेजों में अब भी कुछ बुनियादी सुविधाएं हो सकती हैं. जैसे, JavaScript बंद होने पर लिंक. हालांकि, पेज का ज़्यादातर हिस्सा काम नहीं करता.
एक और काम का टेस्ट यह है कि Chrome DevTools में नेटवर्क थ्रॉटलिंग का इस्तेमाल करें और देखें कि पेज इंटरैक्टिव होने से पहले, कितना JavaScript डाउनलोड होता है. आम तौर पर, इंटरैक्टिव बनाने के लिए, पेज को पहले से रेंडर करने की प्रोसेस में ज़्यादा JavaScript की ज़रूरत होती है. यह JavaScript, स्टैटिक रेंडरिंग में इस्तेमाल किए जाने वाले प्रगतिशील बेहतर बनाने के तरीके से ज़्यादा जटिल होता है.
सर्वर साइड रेंडरिंग बनाम स्टैटिक रेंडरिंग
सर्वर-साइड रेंडरिंग हर काम के लिए सबसे अच्छा तरीका नहीं है. इसकी डाइनैमिक प्रकृति की वजह से, कंप्यूट के लिए ज़्यादा खर्च हो सकता है. सर्वर-साइड रेंडरिंग के कई समाधान, जल्दी फ़्लश नहीं होते, टीटीएफ़बी में देरी करते हैं या भेजे जा रहे डेटा को दोगुना कर देते हैं. उदाहरण के लिए, क्लाइंट पर JavaScript का इस्तेमाल करके इनलाइन किए गए स्टेटस. React में,
renderToString() धीमा हो सकता है, क्योंकि यह सिंक्रोनस और सिंगल-थ्रेड वाला है.
नए React सर्वर DOM API, स्ट्रीमिंग की सुविधा देते हैं. इसकी मदद से, एचटीएमएल रिस्पॉन्स का शुरुआती हिस्सा ब्राउज़र को जल्दी मिल सकता है, जबकि बाकी हिस्सा सर्वर पर जनरेट किया जा रहा होता है.
सर्वर-साइड रेंडरिंग को "ठीक" तरीके से इस्तेमाल करने के लिए, कॉम्पोनेंट को कैश मेमोरी में सेव करने, मेमोरी खर्च को मैनेज करने, मेमोइज़ेशन तकनीकों का इस्तेमाल करने, और दूसरी समस्याओं के लिए समाधान ढूंढना या बनाना पड़ सकता है. अक्सर, एक ही ऐप्लिकेशन को दो बार प्रोसेस किया जाता है या फिर उसे दोबारा बनाया जाता है. पहला प्रोसेस क्लाइंट पर और दूसरा सर्वर पर. सर्वर साइड रेंडरिंग की मदद से, कॉन्टेंट को जल्दी दिखाने से, ज़रूरी नहीं है कि आपका काम कम हो जाए. अगर क्लाइंट पर सर्वर से जनरेट किया गया एचटीएमएल रिस्पॉन्स आने के बाद, आपको क्लाइंट पर काफ़ी काम करना है, तो भी आपकी वेबसाइट के लिए टीबीटी और आईएनपी ज़्यादा हो सकते हैं.
सर्वर साइड रेंडरिंग की मदद से, हर यूआरएल के लिए मांग पर एचटीएमएल जनरेट किया जाता है. हालांकि, यह स्टैटिक रेंडर किए गए कॉन्टेंट को दिखाने की तुलना में धीमा हो सकता है. अगर आपके पास ज़्यादा समय है, तो सर्वर साइड रेंडरिंग और एचटीएमएल कैश मेमोरी की मदद से, सर्वर के रेंडर होने में लगने वाले समय को काफ़ी कम किया जा सकता है. सर्वर साइड रेंडरिंग की सबसे बड़ी खासियत यह है कि इससे ज़्यादा "लाइव" डेटा खींचा जा सकता है और स्टैटिक रेंडरिंग की तुलना में, अनुरोधों के ज़्यादा सेट का जवाब दिया जा सकता है. जिन पेजों को उपयोगकर्ताओं के हिसाब से बनाने की ज़रूरत होती है वे ऐसे अनुरोध के उदाहरण हैं जो स्टैटिक रेंडरिंग के साथ ठीक से काम नहीं करते.
PWA बनाते समय, सर्वर साइड रेंडरिंग से भी दिलचस्प फ़ैसले लिए जा सकते हैं: क्या पूरे पेज के लिए सेवा वर्कर कैश मेमोरी का इस्तेमाल करना बेहतर है या सिर्फ़ कॉन्टेंट के अलग-अलग हिस्सों को सर्वर साइड रेंडर करना?
क्लाइंट-साइड रेंडरिंग
क्लाइंट-साइड रेंडरिंग का मतलब है, JavaScript की मदद से पेजों को सीधे ब्राउज़र में रेंडर करना. पूरा लॉजिक, डेटा फ़ेच करने की प्रोसेस, टेंप्लेट, और रूटिंग, सर्वर के बजाय क्लाइंट पर मैनेज की जाती है. इसका असर यह होता है कि सर्वर से उपयोगकर्ता के डिवाइस पर ज़्यादा डेटा भेजा जाता है. साथ ही, इसके कुछ नुकसान भी होते हैं.
मोबाइल डिवाइसों के लिए, क्लाइंट-साइड रेंडरिंग को तेज़ी से बनाना और उसे तेज़ी से चलाना मुश्किल हो सकता है.
JavaScript के बजट को कम रखने और ज़्यादा से ज़्यादा राउंड-ट्रिप में वैल्यू डिलीवर करने के लिए, थोड़ा काम करें. इससे क्लाइंट-साइड रेंडरिंग की परफ़ॉर्मेंस, पूरी तरह से सर्वर-साइड रेंडरिंग की परफ़ॉर्मेंस जैसी हो जाएगी. <link rel=preload> का इस्तेमाल करके ज़रूरी स्क्रिप्ट और डेटा डिलीवर करके, पार्स करने वाले टूल को तेज़ी से काम करने के लिए कहा जा सकता है. साथ ही, हमारा सुझाव है कि PRPL जैसे पैटर्न का इस्तेमाल करें, ताकि शुरुआती और बाद के नेविगेशन तुरंत दिखें.
क्लाइंट-साइड रेंडरिंग की मुख्य समस्या यह है कि ऐप्लिकेशन के बड़े होने के साथ-साथ, ज़रूरी JavaScript की संख्या भी बढ़ती जाती है. इससे पेज के आईएनपी पर असर पड़ सकता है. नई JavaScript लाइब्रेरी, polyfills, और तीसरे पक्ष के कोड को जोड़ने पर, यह प्रोसेस और भी मुश्किल हो जाती है. ये प्रोसेसिंग पावर के लिए एक-दूसरे से प्रतिस्पर्धा करती हैं और अक्सर पेज के कॉन्टेंट के रेंडर होने से पहले, इन्हें प्रोसेस करना ज़रूरी होता है.
क्लाइंट-साइड रेंडरिंग का इस्तेमाल करने वाले और बड़े JavaScript बंडल पर निर्भर रहने वाले अनुभवों के लिए, पेज लोड होने के दौरान टीबीटी और आईएनपी को कम करने के लिए, ज़्यादा कोड-स्प्लिटिंग का इस्तेमाल करना चाहिए. साथ ही, उपयोगकर्ता को सिर्फ़ ज़रूरत के हिसाब से और ज़रूरत पड़ने पर JavaScript दिखाने के लिए, लेज़ी-लोडिंग JavaScript का इस्तेमाल करना चाहिए. जिन अनुभवों में इंटरैक्टिविटी कम या बिलकुल नहीं है उनके लिए, सर्वर-साइड रेंडरिंग से इन समस्याओं को हल करने का बेहतर तरीका मिल सकता है.
एक पेज वाले ऐप्लिकेशन बनाने वाले लोगों के लिए, ज़्यादातर पेजों के साथ शेयर किए गए यूज़र इंटरफ़ेस के मुख्य हिस्सों की पहचान करने से, ऐप्लिकेशन शेल कैश मेमोरी तकनीक को लागू किया जा सकता है. सर्विस वर्कर के साथ मिलकर, इससे बार-बार आने पर पेज की परफ़ॉर्मेंस काफ़ी बेहतर हो सकती है. इसकी वजह यह है कि पेज, CacheStorage से अपने ऐप्लिकेशन शेल एचटीएमएल और डिपेंडेंसी को बहुत तेज़ी से लोड कर सकता है.
रीहाइड्रेशन में, सर्वर साइड और क्लाइंट साइड, दोनों तरह की रेंडरिंग शामिल होती है
फिर से हाइड्रेट करना एक ऐसा तरीका है जिससे क्लाइंट-साइड और सर्वर-साइड, दोनों रेंडरिंग के बीच के समझौते को आसान बनाया जा सकता है. पूरे पेज को लोड करने या फिर से लोड करने जैसे नेविगेशन रिक्वेस्ट को एक सर्वर मैनेज करता है. यह सर्वर, ऐप्लिकेशन को एचटीएमएल में रेंडर करता है. इसके बाद, रेंडरिंग के लिए इस्तेमाल किए गए JavaScript और डेटा को, नतीजे के तौर पर मिलने वाले दस्तावेज़ में एम्बेड कर दिया जाता है. ध्यान से करने पर, इससे सर्वर-साइड रेंडरिंग की तरह ही तेज़ एफ़सीपी मिलता है. इसके बाद, क्लाइंट पर फिर से रेंडर करके "पिक अप" किया जाता है. यह एक असरदार तरीका है, लेकिन इससे परफ़ॉर्मेंस पर काफ़ी असर पड़ सकता है.
रीहाइड्रेशन के साथ सर्वर-साइड रेंडरिंग की मुख्य समस्या यह है कि इससे टीबीटी और आईएनपी पर काफ़ी बुरा असर पड़ सकता है. भले ही, इससे एफ़सीपी बेहतर हो. सर्वर-साइड रेंडर किए गए पेज, लोड होने और इंटरैक्टिव होने के तौर पर दिख सकते हैं. हालांकि, ये तब तक इनपुट का जवाब नहीं दे सकते, जब तक कि कॉम्पोनेंट के लिए क्लाइंट-साइड स्क्रिप्ट को चलाया नहीं जाता और इवेंट हैंडलर अटैच नहीं किए जाते. मोबाइल पर, इसमें कई मिनट लग सकते हैं. इससे उपयोगकर्ता को परेशानी हो सकती है.
ऐप्लिकेशन को फिर से इंस्टॉल करने से जुड़ी समस्या: दो ऐप्लिकेशन की कीमत में एक ऐप्लिकेशन
क्लाइंट-साइड JavaScript, सर्वर के छोड़े गए हिस्से को सटीक तरीके से "पिक अप" कर सके, इसके लिए ज़्यादातर सर्वर-साइड रेंडरिंग सलूशन, यूज़र इंटरफ़ेस (यूआई) के डेटा डिपेंडेंसी से मिले रिस्पॉन्स को दस्तावेज़ में स्क्रिप्ट टैग के तौर पर सीरियलाइज़ करते हैं. ऐसा, सर्वर से उस डेटा का फिर से अनुरोध किए बिना किया जाता है जिसकी मदद से सर्वर ने एचटीएमएल रेंडर किया था. इस वजह से, बहुत सारे एचटीएमएल डुप्लीकेट हो जाते हैं. इसलिए, रीहाइड्रेशन से इंटरैक्टिविटी में देरी होने के अलावा और भी समस्याएं हो सकती हैं.
सर्वर, नेविगेशन अनुरोध के जवाब में ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) की जानकारी दिखा रहा है. हालांकि, वह उस यूआई को कॉम्पोज़ करने के लिए इस्तेमाल किए गए सोर्स डेटा और यूआई के लागू होने की पूरी कॉपी भी दिखा रहा है. यह कॉपी, क्लाइंट पर बूट होती है. यूज़र इंटरफ़ेस (यूआई) तब तक इंटरैक्टिव नहीं होता, जब तक bundle.js लोड और एक्सीक्यूट नहीं हो जाता.
सर्वर-साइड रेंडरिंग और फिर से हाइड्रेट करने की सुविधा का इस्तेमाल करके, असल वेबसाइटों से इकट्ठा की गई परफ़ॉर्मेंस मेट्रिक से पता चलता है कि यह शायद ही सबसे अच्छा विकल्प हो. सबसे अहम वजह यह है कि इससे उपयोगकर्ता अनुभव पर असर पड़ता है. ऐसा तब होता है, जब पेज तैयार दिखता है, लेकिन उसकी कोई भी इंटरैक्टिव सुविधा काम नहीं करती.
हालांकि, रीहाइड्रेशन के साथ सर्वर साइड रेंडरिंग की उम्मीद है. कम समय में, ज़्यादा कैश मेमोरी में सेव किए जा सकने वाले कॉन्टेंट के लिए सिर्फ़ सर्वर साइड रेंडरिंग का इस्तेमाल करके, TTFB को कम किया जा सकता है. इससे, पहले से रेंडर करने की सुविधा के जैसे ही नतीजे मिलते हैं. आने वाले समय में, इस तकनीक को और बेहतर बनाने के लिए, धीरे-धीरे, धीरे-धीरे या कुछ हद तक फिर से नमी बढ़ाना अहम हो सकता है.
सर्वर साइड रेंडरिंग की सुविधा का इस्तेमाल करके स्ट्रीम करना और धीरे-धीरे फिर से हाइड्रेट करना
पिछले कुछ सालों में, सर्वर-साइड रेंडरिंग में कई बदलाव हुए हैं.
स्ट्रीमिंग सर्वर-साइड रेंडरिंग की मदद से, एचटीएमएल को ऐसे हिस्सों में भेजा जा सकता है जिन्हें ब्राउज़र, मिलने के साथ-साथ रेंडर कर सकता है. इससे आपके उपयोगकर्ताओं को मार्कअप तेज़ी से मिल सकता है. इससे आपके एफ़सीपी में भी तेज़ी आती है. React में, renderToPipeableStream() में एसिंक्रोनस स्ट्रीम होने का मतलब है कि बैकप्रेशर को अच्छी तरह से मैनेज किया जाता है. यह renderToString() में सिंक्रोनस स्ट्रीम होने के मुकाबले है.
प्रोग्रेसिव रीहाइड्रेशन का भी ध्यान रखना चाहिए. React ने इसे लागू किया है. इस तरीके से, सर्वर पर रेंडर किए गए ऐप्लिकेशन के अलग-अलग हिस्सों को समय के साथ "बूट अप" किया जाता है. आम तौर पर, पूरे ऐप्लिकेशन को एक साथ शुरू किया जाता है. इससे, पेजों को इंटरैक्टिव बनाने के लिए ज़रूरी JavaScript की संख्या को कम करने में मदद मिल सकती है. इसकी वजह यह है कि इससे पेज के कम प्राथमिकता वाले हिस्सों को क्लाइंट-साइड अपग्रेड करने की प्रोसेस को कुछ समय के लिए रोका जा सकता है. इससे, मुख्य थ्रेड को ब्लॉक होने से रोका जा सकता है. साथ ही, उपयोगकर्ता के इंटरैक्शन शुरू करने के तुरंत बाद, उन्हें इंटरैक्ट करने की सुविधा मिल जाती है.
प्रोग्रेसिव रीहाइड्रेशन की मदद से, सर्वर-साइड रेंडरिंग के दौरान रीहाइड्रेशन से जुड़ी सबसे आम समस्याओं से भी बचा जा सकता है: सर्वर से रेंडर किया गया डीओएम ट्री, नष्ट हो जाता है और फिर तुरंत फिर से बनाया जाता है. ऐसा अक्सर इसलिए होता है, क्योंकि शुरुआती एसिंक्रोनस क्लाइंट-साइड रेंडर के लिए ज़रूरी डेटा पूरी तरह से तैयार नहीं होता. अक्सर ऐसा Promise के साथ होता है, जो अब तक हल नहीं हुआ है.
शरीर में पानी की कमी को कुछ हद तक पूरा करना
आंशिक रूप से डेटा को फिर से हाइड्रेट करना मुश्किल साबित हुआ है. यह तरीका, धीरे-धीरे फिर से हाइड्रेट करने की सुविधा का ही एक हिस्सा है. यह पेज के अलग-अलग हिस्सों (कॉम्पोनेंट, व्यू या ट्री) का विश्लेषण करता है. साथ ही, उन हिस्सों की पहचान करता है जिनमें इंटरैक्टिविटी कम है या कोई इंटरैक्टिविटी नहीं है. इनमें से ज़्यादातर स्टैटिक हिस्सों के लिए, उनसे जुड़े JavaScript कोड को इनर्ट रेफ़रंस और सजावटी सुविधाओं में बदल दिया जाता है. इससे, क्लाइंट-साइड फ़ुटप्रिंट को करीब-करीब शून्य कर दिया जाता है.
कुछ हद तक हाइड्रेट करने के तरीके में भी समस्याएं आती हैं. इससे कैश मेमोरी में सेव करने से जुड़ी कुछ दिलचस्प समस्याएं आती हैं. साथ ही, क्लाइंट-साइड नेविगेशन का मतलब है कि हम यह नहीं मान सकते कि ऐप्लिकेशन के इनऐक्टिव हिस्सों के लिए, सर्वर से रेंडर किया गया एचटीएमएल, पूरे पेज के लोड होने के बिना उपलब्ध है.
ट्राइसोर्फ़ॉर्मिक रेंडरिंग
अगर आपके पास सेवा वर्कर का विकल्प है, तो ट्रिसोर्फ़िक रेंडरिंग का इस्तेमाल करें. यह एक ऐसी तकनीक है जिसकी मदद से, शुरुआती या बिना JavaScript वाले नेविगेशन के लिए, स्ट्रीमिंग सर्वर-साइड रेंडरिंग का इस्तेमाल किया जा सकता है. इसके बाद, इंस्टॉल होने के बाद, नेविगेशन के लिए एचटीएमएल को रेंडर करने की ज़िम्मेदारी, आपके सेवा वर्कर की हो जाती है. इससे कैश मेमोरी में सेव किए गए कॉम्पोनेंट और टेंप्लेट अप-टू-डेट रखे जा सकते हैं. साथ ही, एक ही सेशन में नए व्यू रेंडर करने के लिए, एसपीए स्टाइल नेविगेशन चालू किए जा सकते हैं. यह तरीका तब सबसे अच्छा काम करता है, जब सर्वर, क्लाइंट पेज, और सेवा वर्कर के बीच एक ही टेंप्लेट और रूटिंग कोड शेयर किया जा सकता है.
एसईओ से जुड़ी बातें
वेब रेंडरिंग की रणनीति चुनते समय, टीमें अक्सर एसईओ के असर को ध्यान में रखती हैं. सर्वर साइड रेंडरिंग, "पूरी तरह से दिखने वाला" अनुभव देने के लिए एक लोकप्रिय विकल्प है. क्रॉलर इसका विश्लेषण कर सकते हैं. क्रॉलर JavaScript को समझ सकते हैं, लेकिन अक्सर उन्हें रेंडर करने के तरीके में सीमाएं होती हैं. क्लाइंट-साइड रेंडरिंग काम कर सकती है, लेकिन इसके लिए अक्सर ज़्यादा जांच और अतिरिक्त लागत की ज़रूरत होती है. अगर आपका आर्किटेक्चर क्लाइंट-साइड JavaScript पर ज़्यादा निर्भर करता है, तो हाल ही में, डाइनैमिक रेंडरिंग भी एक ऐसा विकल्प बन गया है जिस पर विचार किया जा सकता है.
अगर आपको कोई संदेह है, तो मोबाइल फ़्रेंडली जांच टूल का इस्तेमाल करके यह जांचा जा सकता है कि आपने जो तरीका चुना है वह आपकी उम्मीद के मुताबिक काम कर रहा है या नहीं. इसमें, विज़ुअल की मदद से यह जानकारी दी जाती है कि Google के क्रॉलर को कोई पेज कैसा दिखता है. साथ ही, JavaScript लागू होने के बाद, उसे जो सीरियलाइज़ किया गया एचटीएमएल कॉन्टेंट मिलता है और रेंडर करने के दौरान मिलने वाली गड़बड़ियां भी दिखती हैं.
नतीजा
रेंडरिंग के तरीके का फ़ैसला लेते समय, अपनी समस्याओं को मेज़र करें और समझें कि वे क्या हैं. देखें कि क्या स्टैटिक रेंडरिंग या सर्वर साइड रेंडरिंग की मदद से, आपको ज़्यादातर काम हो सकता है. इंटरैक्टिव अनुभव पाने के लिए, ज़्यादातर एचटीएमएल को कम से कम JavaScript के साथ शिप करना ठीक है. यहां एक आसान इन्फ़ोग्राफ़िक दिया गया है, जिसमें सर्वर-क्लाइंट स्पेक्ट्रम दिखाया गया है:
क्रेडिट
समीक्षा करने और हमें प्रेरणा देने के लिए सभी का धन्यवाद:
जेफ़री पॉस्निक, हौसेन डीरडे, शुभी पैंकर, क्रिस हर्रलसन, और सबास्तियन मार्कबागे