इंतज़ार किसी को पसंद नहीं होगा. अगर किसी वेबसाइट को लोड होने में तीन सेकंड से ज़्यादा लगते हैं, तो 50% से ज़्यादा उपयोगकर्ता उसे छोड़ देते हैं.
बड़े JavaScript पेलोड भेजने से आपकी साइट की स्पीड पर बहुत ज़्यादा असर पड़ता है. आपके ऐप्लिकेशन का पहला पेज लोड होते ही, अपने उपयोगकर्ता को पूरा JavaScript भेजने के बजाय, अपने बंडल को कई हिस्सों में बांट लें और शुरुआत में ही ज़रूरी जानकारी भेजें.
कोड को अलग-अलग बांटने से क्यों फ़ायदा होता है?
कोड को अलग-अलग हिस्सों में बांटने की तकनीक, ऐप्लिकेशन खुलने में लगने वाले समय को कम करने की कोशिश करती है. जब हम स्टार्टअप पर कम JavaScript भेजते हैं, तो हम इस ज़रूरी अवधि के दौरान मुख्य थ्रेड के काम को कम करके, ऐप्लिकेशन को इंटरैक्टिव तेज़ी से बना सकते हैं.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने पर, शुरू होने पर डाउनलोड किए गए JavaScript पेलोड कम करने से, फ़र्स्ट इनपुट डिले (एफ़आईडी) और इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) का बेहतर समय मिलेगा. इसकी वजह यह है कि मुख्य थ्रेड को खाली करके, ऐप्लिकेशन JavaScript पार्स, कंपाइल, और एक्ज़ीक्यूशन से जुड़ी स्टार्टअप लागत को कम करके उपयोगकर्ता के इनपुट का ज़्यादा तेज़ी से जवाब दे पाता है.
आपकी वेबसाइट के स्ट्रक्चर के आधार पर—खास तौर पर, अगर आपकी वेबसाइट क्लाइंट-साइड रेंडरिंग पर बहुत ज़्यादा निर्भर करती है, तो मार्कअप को रेंडर करने के लिए ज़िम्मेदार JavaScript पेलोड का साइज़ कम करने से, सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) में सुधार हो सकता है. ऐसा तब हो सकता है, जब क्लाइंट-साइड मार्कअप पूरा होने तक, ब्राउज़र को एलसीपी रिसॉर्स खोजने में देरी हो या जब मुख्य थ्रेड बहुत ज़्यादा व्यस्त हो और उस एलसीपी एलिमेंट को रेंडर नहीं कर पा रहा हो. दोनों ही स्थितियों में, पेज का एलसीपी समय ज़्यादा हो सकता है.
दूरी मापें
जब किसी पेज पर सभी JavaScript को चलाने में बहुत ज़्यादा समय लगता है, तो लाइटहाउस ऑडिट पूरा नहीं कर पाता है.
JavaScript बंडल को इस तरह से बांटें कि उपयोगकर्ता के ऐप्लिकेशन लोड होने पर, सिर्फ़ शुरुआती रूट के लिए ज़रूरी कोड भेजा जा सके. इससे स्क्रिप्ट की वह मात्रा कम हो जाती है जिसे पार्स और कंपाइल करने की ज़रूरत होती है. इससे पेज लोड होने की अवधि कम हो जाती है.
webpack, Parcel, और Rollup जैसे लोकप्रिय मॉड्यूल बंडलर की मदद से, डाइनैमिक इंपोर्ट का इस्तेमाल करके अपने बंडल अलग किए जा सकते हैं.
उदाहरण के लिए, नीचे दिया गया कोड स्निपेट देखें जो फ़ॉर्म सबमिट करने पर ट्रिगर होने वाले someFunction तरीके का उदाहरण दिखाता है.
import moduleA from "library";
form.addEventListener("submit", e => {
e.preventDefault();
someFunction();
});
const someFunction = () => {
// uses moduleA
}
यहां someFunction किसी खास लाइब्रेरी से इंपोर्ट किए गए मॉड्यूल का इस्तेमाल करता है. अगर इस मॉड्यूल का इस्तेमाल कहीं और नहीं किया जा रहा है, तो कोड ब्लॉक में बदलाव करके डाइनैमिक इंपोर्ट का इस्तेमाल किया जा सकता है, ताकि इसे सिर्फ़ तब फ़ेच किया जा सके, जब उपयोगकर्ता ने फ़ॉर्म सबमिट किया हो.
form.addEventListener("submit", e => {
e.preventDefault();
import('library.moduleA')
.then(module => module.default) // using the default export
.then(() => someFunction())
.catch(handleError());
});
const someFunction = () => {
// uses moduleA
}
मॉड्यूल बनाने वाला कोड, शुरुआती बंडल में शामिल नहीं होता. हालांकि, अब यह लेज़ी लोड होता है. इसके अलावा, यह उपयोगकर्ता को सिर्फ़ तब उपलब्ध कराया जाता है, जब फ़ॉर्म सबमिट करने के बाद उसकी ज़रूरत होती है. पेज की परफ़ॉर्मेंस को और बेहतर बनाने के लिए, ज़रूरी हिस्सों को पहले से लोड करें, ताकि उन्हें प्राथमिकता के साथ फ़ेच किया जा सके.
हालांकि, पिछला कोड स्निपेट एक सामान्य उदाहरण है, लेकिन बड़े ऐप्लिकेशन में तीसरे पक्ष की डिपेंडेंसी लेज़ी लोडिंग का आम पैटर्न नहीं है. आम तौर पर, तीसरे पक्ष की डिपेंडेंसी एक अलग वेंडर बंडल में बंटी होती हैं, जिसे कैश मेमोरी में सेव किया जा सकता है. ऐसा इसलिए, क्योंकि ये बार-बार अपडेट नहीं होते. इस बारे में ज़्यादा जानें कि SplitChunksPlugin से ऐसा करने में कैसे मदद मिल सकती है.
क्लाइंट-साइड फ़्रेमवर्क का इस्तेमाल करते समय, रूट या कॉम्पोनेंट लेवल पर छोटे-छोटे हिस्सों में बांटा जा सकता है. इससे, अपने ऐप्लिकेशन के अलग-अलग हिस्सों को लेज़ी लोड करने में आसानी होती है. वेबपैक का इस्तेमाल करने वाले कई लोकप्रिय फ़्रेमवर्क, खुद कॉन्फ़िगरेशन के बजाय लेज़ी लोडिंग को आसान बनाने के लिए ऐब्स्ट्रैक्टेशन उपलब्ध कराते हैं.