एचटीएमएल और इंटरैक्टिविटी की क्लाइंट-साइड रेंडरिंग

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

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

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

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

ब्राउज़र, सर्वर से मिले एचटीएमएल को कैसे रेंडर करता है

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

  1. ब्राउज़र, दिए गए यूआरएल के लिए नेविगेशन अनुरोध भेजता है.
  2. सर्वर, एचटीएमएल के साथ कई हिस्सों में जवाब देता है.

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

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

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

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

ब्राउज़र, JavaScript से मिले एचटीएमएल को कैसे रेंडर करता है

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

क्लाइंट-साइड रेंडरिंग, ज़्यादा सीमित मामलों में नॉन-एसपीए में भी हो सकती है. ऐसा तब होता है, जब एचटीएमएल को JavaScript के ज़रिए डाइनैमिक तौर पर डीओएम में जोड़ा जाता है.

JavaScript की मदद से एचटीएमएल बनाने या डीओएम में जोड़ने के कुछ सामान्य तरीके यहां दिए गए हैं:

  1. innerHTML प्रॉपर्टी की मदद से, किसी मौजूदा एलिमेंट के कॉन्टेंट को स्ट्रिंग के ज़रिए सेट किया जा सकता है. इसे ब्राउज़र, डीओएम में पार्स करता है.
  2. document.createElement का तरीका आपको ब्राउज़र के एचटीएमएल को पार्स किए बिना डीओएम में जोड़ने के लिए नए एलिमेंट बनाने की सुविधा देता है.
  3. document.write का तरीका आपको दस्तावेज़ में एचटीएमएल लिखने की सुविधा देता है. साथ ही, ब्राउज़र इसे पार्स करता है, जैसा कि #1 में किया गया है. हालांकि, कई वजहों से, document.write का इस्तेमाल करने की सलाह बिलकुल नहीं दी जाती है.
Chrome DevTools के परफ़ॉर्मेंस पैनल में विज़ुअलाइज़ किया गया, JavaScript की मदद से एचटीएमएल को पार्स करने का स्क्रीनशॉट. यह एक लंबे टास्क में होता है, जो मुख्य थ्रेड को ब्लॉक करता है.
Chrome DevTools के परफ़ॉर्मेंस पैनल में दिखाए गए तरीके से, क्लाइंट पर JavaScript के ज़रिए एचटीएमएल को पार्स और रेंडर करना. इसे पार्स और रेंडर करने में जो टास्क होते हैं उन्हें अलग-अलग हिस्सों में नहीं बांटा जाता. इस वजह से, एक लंबा टास्क बन जाता है, जो मुख्य थ्रेड को ब्लॉक करता है.

क्लाइंट-साइड JavaScript का इस्तेमाल करके, एचटीएमएल/DOM बनाने के नतीजे अहम हो सकते हैं:

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

क्लाइंट-साइड रेंडरिंग की परफ़ॉर्मेंस पर पड़ने वाले असर के बारे में क्या किया जा सकता है

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

वजह जो भी हो, यहां कुछ ऐसी वजहें बताई गई हैं जिनका इस्तेमाल करके, समस्याओं को ठीक करने में मदद मिल सकती है.

सर्वर से ज़्यादा से ज़्यादा एचटीएमएल उपलब्ध कराएं

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

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

  • React के लिए, आपको सर्वर डीओएम एपीआई का इस्तेमाल करना होगा, ताकि सर्वर पर एचटीएमएल रेंडर किया जा सके. हालांकि, ध्यान रखें: सर्वर साइड रेंडरिंग के लिए आम तौर पर इस्तेमाल होने वाले तरीके में सिंक्रोनस अप्रोच का इस्तेमाल होता है. इस वजह से, टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) के साथ-साथ फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) और एलसीपी जैसी बाद की मेट्रिक में ज़्यादा समय लग सकता है. जहां भी हो सके, पक्का करें कि Node.js या अन्य JavaScript रनटाइम के लिए स्ट्रीमिंग एपीआई का इस्तेमाल किया जा रहा है, ताकि सर्वर जल्द से जल्द ब्राउज़र पर एचटीएमएल को स्ट्रीम करना शुरू कर सके. Next.js—प्रतिक्रिया पर आधारित फ़्रेमवर्क—डिफ़ॉल्ट रूप से कई सबसे सही तरीके देता है. यह सर्वर पर एचटीएमएल को अपने-आप रेंडर करने के अलावा, उन पेजों के लिए भी स्टैटिक रूप से एचटीएमएल जनरेट कर सकता है जो उपयोगकर्ता के कॉन्टेक्स्ट के आधार पर नहीं बदलते. जैसे, पुष्टि करने की सुविधा.
  • Vue डिफ़ॉल्ट तौर पर, क्लाइंट-साइड रेंडरिंग की सुविधा इस्तेमाल करता है. हालांकि, React की तरह ही Vue भी सर्वर पर आपके कॉम्पोनेंट के एचटीएमएल को रेंडर कर सकता है. जहां भी मुमकिन हो, इन सर्वर-साइड एपीआई का फ़ायदा लें या सबसे सही तरीकों को आसानी से लागू करने के लिए, अपने Vue प्रोजेक्ट के लिए बड़े लेवल के ऐब्स्ट्रैक्टेशन का इस्तेमाल करें.
  • Svelte डिफ़ॉल्ट रूप से सर्वर पर एचटीएमएल को रेंडर करता है—हालांकि, अगर आपके कॉम्पोनेंट कोड को ब्राउज़र के लिए खास नेमस्पेस (उदाहरण के लिए, window) के ऐक्सेस की ज़रूरत है, तो हो सकता है कि आप सर्वर पर उस कॉम्पोनेंट के एचटीएमएल को रेंडर न कर पाएं. जहां भी मुमकिन हो, अलग-अलग तरीके ढूंढें, ताकि क्लाइंट-साइड रेंडरिंग की वजह से बेवजह की क्लाइंट-साइड रेंडरिंग न हो. SvelteKit- Svelte को Next.js के तौर पर प्रतिक्रिया देना है. यह आपके Svelte प्रोजेक्ट में कई सबसे सही तरीके एम्बेड करता है, ताकि आप सिर्फ़ Svelte का इस्तेमाल करने वाले प्रोजेक्ट में आने वाली दिक्कतों से बच सकें.

क्लाइंट पर बनाए गए डीओएम नोड की संख्या सीमित करें

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

स्ट्रीमिंग सर्विस वर्कर आर्किटेक्चर के बारे में सोचें

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

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

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

नतीजा

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

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

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

Unsplash की हीरो इमेज, मइक जोनिट्ज़ ने बनाई है.