वेब पर रेंडर करना

Addy Osmani

Jason Miller

पब्लिश होने की तारीख: 6 फ़रवरी, 2019, पिछली बार अपडेट किए जाने की तारीख: 5 जनवरी, 2026

वेब डेवलपर को यह तय करना होता है कि उन्हें अपने ऐप्लिकेशन में लॉजिक और रेंडरिंग को कहां लागू करना है. यह मुश्किल हो सकता है, क्योंकि वेबसाइट बनाने के कई तरीके हैं.

इस स्पेस के बारे में हमारी समझ, Chrome में हमारे काम से मिली है. इसमें हमने पिछले कुछ सालों में बड़ी साइटों से बात की है. आम तौर पर, हम डेवलपर को सलाह देते हैं कि वे पूरी तरह से रीहाइड्रेशन करने के बजाय, सर्वर साइड रेंडरिंग या स्टैटिक रेंडरिंग का इस्तेमाल करें.

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

शब्दावली

सबसे पहले, हम कुछ ऐसी शब्दावली के बारे में बताएंगे जिनका इस्तेमाल हम करेंगे.

रेंडरिंग

सर्वर-साइड रेंडरिंग (एसएसआर)

क्लाइंट को JavaScript के बजाय एचटीएमएल भेजने के लिए, सर्वर पर ऐप्लिकेशन को रेंडर करना.

क्लाइंट-साइड रेंडरिंग (सीएसआर)

ब्राउज़र में किसी ऐप्लिकेशन को रेंडर करना. इसके लिए, JavaScript का इस्तेमाल करके डीओएम में बदलाव करना.

प्रीरेंडरिंग

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

हाइड्रेशन

सर्वर से रेंडर किए गए एचटीएमएल में, ऐप्लिकेशन की स्थिति और इंटरैक्टिविटी जोड़ने के लिए, क्लाइंट-साइड स्क्रिप्ट चलाना. हाइड्रेशन यह मानकर चलता है कि डीओएम में कोई बदलाव नहीं होता.

शरीर में पानी की कमी पूरी करना

आम तौर पर, रीहाइड्रेशन का इस्तेमाल हाइड्रेशन के तौर पर किया जाता है. हालांकि, रीहाइड्रेशन का मतलब है कि डीओएम को नई स्थिति के साथ नियमित तौर पर अपडेट करना. इसमें शुरुआती हाइड्रेशन के बाद की स्थिति भी शामिल है.

परफ़ॉर्मेंस

टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी)

किसी लिंक पर क्लिक करने और नए पेज पर कॉन्टेंट की पहली बाइट लोड होने के बीच का समय.

साइट का पहला एलिमेंट लोड होने में लगने वाला समय (एफ़सीपी)

वह समय जब अनुरोध किया गया कॉन्टेंट (लेख का मुख्य हिस्सा वगैरह) दिखने लगता है.

पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)

यह एक ऐसी मेट्रिक है जिससे यह पता चलता है कि कोई पेज, उपयोगकर्ता के इनपुट का जवाब लगातार तेज़ी से देता है या नहीं.

पेज रिस्पॉन्स बंद रहने का कुल समय (टीबीटी)

आईएनपी के लिए प्रॉक्सी मेट्रिक इससे यह पता चलता है कि पेज लोड होने के दौरान, मुख्य थ्रेड कितनी देर तक ब्लॉक रहा.

सर्वर-साइड रेंडरिंग

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

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

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

सर्वर-साइड रेंडरिंग के साथ एफ़सीपी और टीटीआई.

सर्वर-साइड रेंडरिंग की मदद से, उपयोगकर्ताओं को आपकी साइट का इस्तेमाल करने से पहले, सीपीयू से जुड़ी JavaScript के चलने का इंतज़ार नहीं करना पड़ता. अगर तीसरे पक्ष की JavaScript का इस्तेमाल करना ज़रूरी है, तो सर्वर-साइड रेंडरिंग का इस्तेमाल करके, पहले पक्ष की JavaScript की लागत को कम किया जा सकता है. इससे आपको बाकी चीज़ों के लिए ज़्यादा बजट मिल सकता है. हालांकि, इस तरीके में एक संभावित समस्या है: सर्वर पर पेज जनरेट करने में समय लगता है. इससे आपके पेज का टीटीएफ़बी बढ़ सकता है.

आपके ऐप्लिकेशन के लिए सर्वर-साइड रेंडरिंग काफ़ी है या नहीं, यह काफ़ी हद तक इस बात पर निर्भर करता है कि आपको किस तरह का अनुभव देना है. सर्वर-साइड रेंडरिंग और क्लाइंट-साइड रेंडरिंग के सही इस्तेमाल को लेकर लंबे समय से बहस चल रही है. हालांकि, आपके पास कुछ पेजों के लिए सर्वर-साइड रेंडरिंग का इस्तेमाल करने और कुछ के लिए न करने का विकल्प हमेशा होता है. कुछ साइटों ने हाइब्रिड रेंडरिंग की तकनीकों को अपनाया है और उन्हें सफलता मिली है. उदाहरण के लिए, Netflix अपने लैंडिंग पेजों को सर्वर-साइड रेंडर करता है. ये पेज ज़्यादातर स्टैटिक होते हैं. वहीं, इंटरैक्शन-हैवी पेजों के लिए JavaScript को prefetching करता है. इससे, क्लाइंट-साइड रेंडर किए गए इन हैवी पेजों को तेज़ी से लोड होने में मदद मिलती है.

कई आधुनिक फ़्रेमवर्क, लाइब्रेरी, और आर्किटेक्चर की मदद से, एक ही ऐप्लिकेशन को क्लाइंट और सर्वर, दोनों पर रेंडर किया जा सकता है. सर्वर-साइड रेंडरिंग के लिए, इन तकनीकों का इस्तेमाल किया जा सकता है. हालांकि, ऐसे आर्किटेक्चर जहां रेंडरिंग, सर्वर और क्लाइंट, दोनों पर होती है, वे अपने-आप में एक अलग तरह का समाधान हैं. इनकी परफ़ॉर्मेंस की विशेषताएं और समझौते बहुत अलग होते हैं. React का इस्तेमाल करने वाले लोग, सर्वर-साइड रेंडरिंग के लिए सर्वर DOM API या उन पर आधारित समाधानों का इस्तेमाल कर सकते हैं. जैसे, Next.js. Vue का इस्तेमाल करने वाले लोग, Vue की सर्वर साइड रेंडरिंग गाइड या Nuxt का इस्तेमाल कर सकते हैं. Angular में Universal है.

हालांकि, सबसे लोकप्रिय समाधानों में किसी न किसी तरह के हाइड्रेशन का इस्तेमाल किया जाता है. इसलिए, इस बात का ध्यान रखें कि आपका टूल किस तरह के तरीके इस्तेमाल करता है.

स्टैटिक रेंडरिंग

स्टैटिक रेंडरिंग बिल्ड टाइम के दौरान होती है. इस तरीके से, एफ़सीपी तेज़ी से होता है. साथ ही, टीबीटी और आईएनपी भी कम होता है. हालांकि, इसके लिए आपको अपने पेजों पर क्लाइंट-साइड JavaScript की संख्या सीमित करनी होगी. सर्वर-साइड रेंडरिंग के उलट, इसमें टीटीएफ़बी लगातार तेज़ रहता है. ऐसा इसलिए होता है, क्योंकि किसी पेज के एचटीएमएल को सर्वर पर डाइनैमिक तौर पर जनरेट करने की ज़रूरत नहीं होती. आम तौर पर, स्टैटिक रेंडरिंग का मतलब है कि हर यूआरएल के लिए, पहले से ही एक अलग एचटीएमएल फ़ाइल बनाना. पहले से जनरेट किए गए एचटीएमएल रिस्पॉन्स की मदद से, स्टैटिक रेंडर को कई सीडीएन पर डिप्लॉय किया जा सकता है. इससे करीबी संचय का फ़ायदा मिलता है.

स्टैटिक रेंडरिंग के साथ एफ़सीपी और टीटीआई.

स्टैटिक रेंडरिंग के लिए, कई तरह के समाधान उपलब्ध हैं. Gatsby जैसे टूल इस तरह से डिज़ाइन किए गए हैं कि डेवलपर को लगे कि उनका ऐप्लिकेशन डाइनैमिक तरीके से रेंडर हो रहा है, न कि बिल्ड स्टेप के तौर पर जनरेट हो रहा है. 11ty, Jekyll, और Metalsmith जैसे स्टैटिक साइट जनरेशन टूल, स्टैटिक नेचर को अपनाते हैं. इससे टेंप्लेट पर आधारित ज़्यादा बेहतर तरीका मिलता है.

ध्यान दें: Next.js या Nuxt जैसे लोकप्रिय फ़्रेमवर्क के ऐब्स्ट्रैक्शन, स्टैटिक रेंडरिंग और सर्वर-साइड रेंडरिंग, दोनों की सुविधा देते हैं. इससे डेवलपर, ज़रूरी शर्तें पूरी करने वाले पेजों के लिए स्टैटिक रेंडरिंग का विकल्प चुन सकते हैं. इसके अलावा, वे उन पेजों के लिए सर्वर-साइड रेंडरिंग का इस्तेमाल कर सकते हैं जिन्हें किसी अनुरोध के जवाब में डाइनैमिक तौर पर जनरेट करना ज़रूरी है.

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

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 लाइब्रेरी, पॉलीफ़िल, और तीसरे पक्ष के कोड जोड़ने से, यह काम और भी मुश्किल हो जाता है. ये सभी प्रोसेसिंग पावर के लिए मुकाबला करते हैं. साथ ही, पेज के कॉन्टेंट को रेंडर करने से पहले, इन्हें प्रोसेस करना ज़रूरी होता है.

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

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

रीहाइड्रेशन में, सर्वर-साइड और क्लाइंट-साइड रेंडरिंग को एक साथ इस्तेमाल किया जाता है

हाइड्रेशन एक ऐसा तरीका है जो क्लाइंट-साइड और सर्वर-साइड, दोनों तरह की रेंडरिंग करके, इनके बीच के अंतर को कम करता है. नेविगेशन के अनुरोध, जैसे कि पूरे पेज को लोड या फिर से लोड करना, एक सर्वर मैनेज करता है. यह सर्वर, ऐप्लिकेशन को एचटीएमएल में रेंडर करता है. इसके बाद, रेंडरिंग के लिए इस्तेमाल की जाने वाली JavaScript और डेटा को नतीजे वाले दस्तावेज़ में एम्बेड किया जाता है. अगर इसे ध्यान से किया जाए, तो सर्वर-साइड रेंडरिंग की तरह ही तेज़ी से एफ़सीपी हासिल किया जा सकता है. इसके बाद, क्लाइंट पर फिर से रेंडर करके "पिक अप" किया जा सकता है.

यह एक असरदार तरीका है, लेकिन इससे परफ़ॉर्मेंस में काफ़ी गिरावट आ सकती है.

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

रीहाइड्रेशन की समस्या: एक ऐप्लिकेशन की कीमत में दो ऐप्लिकेशन

क्लाइंट-साइड JavaScript, सर्वर के छोड़े गए काम को सटीक तरीके से पूरा कर सके, इसके लिए सर्वर-साइड रेंडरिंग के ज़्यादातर समाधान, यूज़र इंटरफ़ेस (यूआई) के डेटा डिपेंडेंसी से मिले रिस्पॉन्स को दस्तावेज़ में स्क्रिप्ट टैग के तौर पर क्रम से लगाते हैं. ऐसा इसलिए किया जाता है, ताकि सर्वर ने जिस एचटीएमएल के साथ डेटा रेंडर किया है उसके लिए फिर से अनुरोध न करना पड़े. इसकी वजह से, एचटीएमएल का डुप्लीकेट कॉन्टेंट बन जाता है. साथ ही, रीहाइड्रेशन की वजह से इंटरैक्टिविटी में देरी होने के अलावा, अन्य समस्याएं भी हो सकती हैं.

एचटीएमएल दस्तावेज़, जिसमें सीरियलाइज़ किया गया यूज़र इंटरफ़ेस (यूआई), इनलाइन डेटा, और bundle.js स्क्रिप्ट शामिल है.

सर्वर, नेविगेशन के अनुरोध के जवाब में ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) की जानकारी दिखाता है. हालांकि, यह उस यूआई को बनाने के लिए इस्तेमाल किया गया सोर्स डेटा और यूआई के लागू होने की पूरी कॉपी भी दिखाता है. इसके बाद, यह क्लाइंट पर बूट होता है. यूज़र इंटरफ़ेस (यूआई) तब तक इंटरैक्टिव नहीं होता, जब तक bundle.js लोड और लागू नहीं हो जाता.

सर्वर-साइड रेंडरिंग और रीहाइड्रेशन का इस्तेमाल करने वाली असली वेबसाइटों से इकट्ठा की गई परफ़ॉर्मेंस मेट्रिक से पता चलता है कि यह शायद ही कभी सबसे अच्छा विकल्प होता है. इसकी सबसे अहम वजह यह है कि जब कोई पेज तैयार दिखता है, लेकिन उसकी कोई भी इंटरैक्टिव सुविधा काम नहीं करती, तो इससे उपयोगकर्ता अनुभव पर असर पड़ता है.

टीटीआई पर क्लाइंट-साइड रेंडरिंग के खराब असर.

रीहाइड्रेशन के साथ सर्वर-साइड रेंडरिंग का इस्तेमाल करने से, इस समस्या को हल किया जा सकता है. कम समय में, ज़्यादा कैश मेमोरी में सेव किए जा सकने वाले कॉन्टेंट के लिए, सिर्फ़ सर्वर-साइड रेंडरिंग का इस्तेमाल करने से टीटीएफ़बी को कम किया जा सकता है. इससे प्रीरेंडरिंग जैसे नतीजे मिलते हैं. आने वाले समय में इस तकनीक को ज़्यादा कारगर बनाने के लिए, रीहाइड्रेशन की प्रोसेस को इंक्रीमेंटल, प्रोग्रेसिव या पार्शियल तरीके से किया जा सकता है.

सर्वर साइड रेंडरिंग को स्ट्रीम करना और प्रोग्रेसिव तरीके से रीहाइड्रेट करना

पिछले कुछ सालों में, सर्वर-साइड रेंडरिंग में कई बदलाव हुए हैं.

स्ट्रीमिंग सर्वर-साइड रेंडरिंग की मदद से, एचटीएमएल को अलग-अलग हिस्सों में भेजा जा सकता है. इससे ब्राउज़र, एचटीएमएल को धीरे-धीरे रेंडर कर सकता है. इससे आपके उपयोगकर्ताओं को मार्कअप तेज़ी से मिल सकता है. साथ ही, आपके एफ़सीपी की स्पीड बढ़ सकती है. React में, renderToPipeableStream() में एसिंक्रोनस स्ट्रीम, सिंक्रोनस renderToString() की तुलना में बैकप्रेशर को बेहतर तरीके से मैनेज करती हैं.

प्रोग्रेसिव रीहाइड्रेशन पर भी विचार किया जा सकता है (React ने इसे लागू किया है). इस तरीके से, सर्वर पर रेंडर किए गए ऐप्लिकेशन के अलग-अलग हिस्सों को समय के साथ "बूट अप" किया जाता है. यह तरीका, पूरे ऐप्लिकेशन को एक साथ शुरू करने के मौजूदा सामान्य तरीके से अलग है. इससे पेजों को इंटरैक्टिव बनाने के लिए ज़रूरी JavaScript की संख्या कम की जा सकती है. ऐसा इसलिए, क्योंकि इससे पेज के कम प्राथमिकता वाले हिस्सों को क्लाइंट-साइड पर अपग्रेड करने में देरी की जा सकती है, ताकि मुख्य थ्रेड को ब्लॉक होने से रोका जा सके. इससे उपयोगकर्ता के इंटरैक्शन शुरू करने के बाद, उपयोगकर्ता के इंटरैक्शन जल्दी हो पाते हैं.

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

पार्शियल रीहाइड्रेशन

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

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

ट्राइसोमॉर्फ़िक रेंडरिंग

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

ट्राइसोमॉर्फ़िक रेंडरिंग, जिसमें ब्राउज़र और सर्विस वर्कर को सर्वर के साथ कम्यूनिकेट करते हुए दिखाया गया है.

एसईओ से जुड़ी ज़रूरी बातें

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

नतीजा

रेंडरिंग का तरीका तय करते समय, यह मेज़र करें और समझें कि आपकी रुकावटें क्या हैं. देखें कि क्या स्टैटिक रेंडरिंग या सर्वर-साइड रेंडरिंग से आपको ज़्यादातर फ़ायदे मिल सकते हैं. इंटरैक्टिव अनुभव देने के लिए, कम से कम JavaScript के साथ ज़्यादातर एचटीएमएल का इस्तेमाल करना ठीक है. यहां एक इन्फ़ोग्राफ़िक दिया गया है, जिसमें सर्वर-क्लाइंट स्पेक्ट्रम को दिखाया गया है:

रेंडरिंग के विकल्प और उनसे जुड़ी समस्याएं.

क्रेडिट

समीक्षा करने और प्रेरणा देने के लिए सभी को धन्यवाद:

जेफ़्री पॉस्निक, हुसैन जिरदेह, शुभी पनिक्कर, क्रिस हैरेलसन, और सेबेस्टियन मार्कबागे.