स्क्रिप्ट इवैलुएशन और लंबे टास्क

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

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

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

स्क्रिप्ट का आकलन करने की सुविधा क्या है?

अगर आपने ऐसे ऐप्लिकेशन की प्रोफ़ाइल बनाई है जिसमें बहुत सारी JavaScript शामिल हैं, तो आपको ऐसे लंबे टास्क दिख सकते हैं जिनमें स्क्रिप्ट का आकलन करें को समस्या की वजह बताया गया है.

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

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

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

स्क्रिप्ट और उनका आकलन करने वाले टास्क के बीच संबंध

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

<script> एलिमेंट की मदद से लोड की गई स्क्रिप्ट

स्क्रिप्ट का आकलन करने के लिए भेजे गए टास्क की संख्या, आम तौर पर किसी पेज पर मौजूद <script> एलिमेंट की संख्या से जुड़ी होती है. हर <script> एलिमेंट, अनुरोध की गई स्क्रिप्ट का आकलन करने के लिए एक टास्क शुरू करता है, ताकि उसे पार्स, कंपाइल, और एक्ज़ीक्यूट किया जा सके. Chromium वाले ब्राउज़र, Safari, और Firefox के लिए ऐसा होता है.

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

JavaScript के बड़े-बड़े हिस्सों को लोड करने से बचें. इससे स्क्रिप्ट के आकलन के काम को बांटा जा सकता है. साथ ही, ज़्यादा <script> एलिमेंट का इस्तेमाल करके, अलग-अलग छोटी स्क्रिप्ट लोड की जा सकती हैं.

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

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

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

<script> एलिमेंट और type=module एट्रिब्यूट का इस्तेमाल करके लोड की गई स्क्रिप्ट

अब ब्राउज़र में ES मॉड्यूल को नेटिव तौर पर लोड किया जा सकता है. इसके लिए, <script> एलिमेंट पर type=module एट्रिब्यूट का इस्तेमाल करें. स्क्रिप्ट लोड करने के इस तरीके से, डेवलपर को कुछ फ़ायदे मिलते हैं. जैसे, प्रोडक्शन के लिए कोड को बदलने की ज़रूरत नहीं होती. खास तौर पर, जब इसका इस्तेमाल इंपोर्ट मैप के साथ किया जाता है. हालांकि, इस तरह से स्क्रिप्ट लोड करने पर, ऐसे टास्क शेड्यूल किए जाते हैं जो ब्राउज़र के हिसाब से अलग-अलग होते हैं.

Chromium पर आधारित ब्राउज़र

Chrome या उससे मिलते-जुलते ब्राउज़र में, type=module एट्रिब्यूट का इस्तेमाल करके ES मॉड्यूल लोड करने से, अलग-अलग तरह के टास्क जनरेट होते हैं. ये टास्क, type=module का इस्तेमाल न करने पर दिखने वाले टास्क से अलग होते हैं. उदाहरण के लिए, हर मॉड्यूल स्क्रिप्ट के लिए एक टास्क चलेगा. इसमें मॉड्यूल कंपाइल करें के तौर पर लेबल की गई गतिविधि शामिल होगी.

Chrome DevTools में दिखाए गए, कई टास्क में मॉड्यूल कंपाइल करने का काम.
Chromium पर आधारित ब्राउज़र में मॉड्यूल लोड करने का तरीका. हर मॉड्यूल स्क्रिप्ट, Compile module कॉल को स्पॉन करेगी, ताकि आकलन से पहले उसके कॉन्टेंट को कंपाइल किया जा सके.

मॉड्यूल कंपाइल होने के बाद, उनमें चलने वाला कोई भी कोड, मॉड्यूल का आकलन करें के तौर पर लेबल की गई गतिविधि को शुरू कर देगा.

Chrome DevTools के परफ़ॉर्मेंस पैनल में, मॉड्यूल का तुरंत आकलन दिखाया गया है.
किसी मॉड्यूल में कोड चलने पर, उस मॉड्यूल का आकलन तुरंत किया जाएगा.

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

  • सभी मॉड्यूल कोड, स्ट्रिक्ट मोड में अपने-आप चलता है. इससे JavaScript इंजन को ऑप्टिमाइज़ेशन करने में मदद मिलती है. ऐसा स्ट्रिक्ट मोड के बिना नहीं किया जा सकता.
  • type=module का इस्तेमाल करके लोड की गई स्क्रिप्ट को डिफ़ॉल्ट रूप से डिफ़र किया गया माना जाता है. इस व्यवहार को बदलने के लिए, type=module की मदद से लोड की गई स्क्रिप्ट पर async एट्रिब्यूट का इस्तेमाल किया जा सकता है.

Safari और Firefox

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

डाइनैमिक import() की मदद से लोड की गई स्क्रिप्ट

डाइनैमिक import(), स्क्रिप्ट लोड करने का एक और तरीका है. स्टैटिक import स्टेटमेंट को ES मॉड्यूल के सबसे ऊपर रखना ज़रूरी होता है. हालांकि, डाइनैमिक import() कॉल को स्क्रिप्ट में कहीं भी रखा जा सकता है, ताकि मांग पर JavaScript का कोई हिस्सा लोड किया जा सके. इस तकनीक को कोड स्प्लिटिंग कहा जाता है.

आईएनपी को बेहतर बनाने के लिए, डाइनैमिक import() के दो फ़ायदे हैं:

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

डाइनैमिक import() कॉल, सभी मुख्य ब्राउज़र इंजन में एक जैसा काम करते हैं: स्क्रिप्ट के आकलन से जुड़े टास्क की संख्या, डाइनैमिक तौर पर इंपोर्ट किए गए मॉड्यूल की संख्या के बराबर होगी.

वेब वर्कर में लोड की गई स्क्रिप्ट

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

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

ट्रेड-ऑफ़ और ध्यान रखने वाली बातें

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

कंप्रेशन की क्षमता

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

बंडलर, आपकी वेबसाइट की स्क्रिप्ट के आउटपुट साइज़ को मैनेज करने के लिए सबसे सही टूल हैं:

  • webpack के मामले में, इसका SplitChunksPlugin प्लगिन आपकी मदद कर सकता है. ऐसेट के साइज़ मैनेज करने के लिए सेट किए जा सकने वाले विकल्पों के बारे में जानने के लिए, SplitChunksPlugin दस्तावेज़ पढ़ें.
  • Rollup और esbuild जैसे अन्य बंडलर के लिए, अपने कोड में डाइनैमिक import() कॉल का इस्तेमाल करके, स्क्रिप्ट फ़ाइल के साइज़ मैनेज किए जा सकते हैं. ये बंडलर और webpack, डाइनैमिक तरीके से इंपोर्ट की गई ऐसेट को अपने-आप अलग फ़ाइल में बदल देंगे. इससे, शुरुआती बंडल का साइज़ बड़ा नहीं होगा.

कैश मेमोरी में सेव पेजों को 'अमान्य' मार्क करना

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

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

नेस्ट किए गए मॉड्यूल और लोड होने की परफ़ॉर्मेंस

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

// a.js
import {b} from './b.js';

// b.js
import {c} from './c.js';

अगर आपके ES मॉड्यूल एक साथ बंडल नहीं किए गए हैं, तो ऊपर दिए गए कोड से नेटवर्क अनुरोध की एक चेन बनती है: जब <script> एलिमेंट से a.js का अनुरोध किया जाता है, तो b.js के लिए एक और नेटवर्क अनुरोध भेजा जाता है. इसके बाद, c.js के लिए एक और अनुरोध भेजा जाता है. इससे बचने के लिए, बंडलर का इस्तेमाल किया जा सकता है. हालांकि, यह पक्का करें कि आपने अपने बंडलर को स्क्रिप्ट को अलग-अलग हिस्सों में बांटने के लिए कॉन्फ़िगर किया हो, ताकि स्क्रिप्ट के आकलन का काम अलग-अलग हो सके.

अगर आपको बंडलर का इस्तेमाल नहीं करना है, तो नेस्ट किए गए मॉड्यूल कॉल से बचने का एक और तरीका है. इसके लिए, modulepreload रिसॉर्स हिंट का इस्तेमाल करें. इससे नेटवर्क अनुरोधों की चेन से बचने के लिए, ES मॉड्यूल को पहले से लोड किया जा सकेगा.

नतीजा

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

बड़ी स्क्रिप्ट की समीक्षा करने के टास्क को छोटे-छोटे हिस्सों में बांटने के लिए, यहां कुछ तरीके दिए गए हैं:

  • type=module एट्रिब्यूट के बिना <script> एलिमेंट का इस्तेमाल करके स्क्रिप्ट लोड करते समय, बहुत बड़ी स्क्रिप्ट लोड करने से बचें. ऐसा इसलिए, क्योंकि ये स्क्रिप्ट, संसाधन का ज़्यादा इस्तेमाल करने वाले स्क्रिप्ट के आकलन वाले टास्क शुरू कर देंगी. इससे मुख्य थ्रेड ब्लॉक हो जाएगी. इस काम को बांटने के लिए, अपनी स्क्रिप्ट को ज़्यादा <script> एलिमेंट में फैलाएं.
  • ब्राउज़र में ES मॉड्यूल को नेटिव तौर पर लोड करने के लिए, type=module एट्रिब्यूट का इस्तेमाल करने से, हर मॉड्यूल स्क्रिप्ट के लिए अलग-अलग टास्क शुरू हो जाएंगे.
  • डाइनैमिक import() कॉल का इस्तेमाल करके, अपने शुरुआती बंडलों का साइज़ कम करें. यह बंडलर में भी काम करता है, क्योंकि बंडलर, डाइनैमिक तौर पर इंपोर्ट किए गए हर मॉड्यूल को "स्प्लिट पॉइंट" के तौर पर ट्रीट करेगा. इससे, डाइनैमिक तौर पर इंपोर्ट किए गए हर मॉड्यूल के लिए एक अलग स्क्रिप्ट जनरेट होगी.
  • कंप्रेशन की क्षमता और कैश मेमोरी को अमान्य करने जैसे फ़ायदों और नुकसानों का आकलन करना न भूलें. बड़ी स्क्रिप्ट को बेहतर तरीके से कंप्रेस किया जा सकेगा. हालांकि, कम टास्क में स्क्रिप्ट का आकलन करने में ज़्यादा समय लगेगा. साथ ही, इससे ब्राउज़र की कैश मेमोरी अमान्य हो जाएगी. इससे कैश मेमोरी की कुल क्षमता कम हो जाएगी.
  • अगर बंडलिंग के बिना नेटिव तौर पर ES मॉड्यूल का इस्तेमाल किया जा रहा है, तो स्टार्टअप के दौरान उन्हें लोड करने की प्रोसेस को ऑप्टिमाइज़ करने के लिए, modulepreload रिसॉर्स हिंट का इस्तेमाल करें.
  • हमेशा की तरह, कम से कम JavaScript शिप करें.

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