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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्लाइंट-साइड JavaScript की मदद से एचटीएमएल/डीओएम बनाने के नतीजे गंभीर हो सकते हैं:

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

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

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

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

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

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

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

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

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

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

स्ट्रीमिंग सेवा के वर्कर आर्किटेक्चर का इस्तेमाल करना

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

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

कम शब्दों में, स्ट्रीमिंग सेवा वर्कअरकीचर, ब्राउज़र के पहले से मौजूद नेविगेशन लॉजिक को बदल नहीं करता. बल्कि, उसमें जोड़ता है. Workbox की मदद से, ऐसा करने के तरीके के बारे में ज़्यादा जानने के लिए, Streams की मदद से, तेज़ी से काम करने वाले मल्टीपेज ऐप्लिकेशन लेख पढ़ें.

नतीजा

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

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

अगर आपकी वेबसाइट की क्लाइंट-साइड रेंडरिंग को कम से कम किया जा सकता है, तो न सिर्फ़ आपकी वेबसाइट का INP बेहतर होगा, बल्कि LCP, TBT जैसी अन्य मेट्रिक भी बेहतर होंगी. साथ ही, कुछ मामलों में TTFB भी बेहतर हो सकता है.

Unsplash से ली गई हीरो इमेज, जिसे Maik Jonietz ने बनाया है.