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