वेब ऐप्लिकेशन को तेज़ी से लोड करने की तकनीक, यहां तक कि फ़ीचर फ़ोन पर भी लोड होती है

प्री-रेंडरर को लागू करने के कई तरीके हैं. PROXX में, हमने Puppeteer का इस्तेमाल किया है. यह Chrome को बिना किसी यूज़र इंटरफ़ेस के शुरू करता है. साथ ही, Node API की मदद से उस इंस्टेंस को रिमोट से कंट्रोल करने की सुविधा देता है. हम इसका इस्तेमाल अपने मार्कअप और JavaScript को इंजेक्ट करने के लिए करते हैं. इसके बाद, DOM को एचटीएमएल की स्ट्रिंग के तौर पर पढ़ते हैं. हम सीएसएस मॉड्यूल का इस्तेमाल कर रहे हैं. इसलिए, हमें उन स्टाइल की सीएसएस इनलाइन करने की सुविधा मिलती है जिनकी हमें ज़रूरत होती है. इसके लिए, हमसे कोई शुल्क नहीं लिया जाता.

  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setContent(rawIndexHTML);
  await page.evaluate(codeToRun);
  const renderedHTML = await page.content();
  browser.close();
  await writeFile("index.html", renderedHTML);

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

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

इनलाइन करना

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

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

इस समस्या को हल करने के लिए, एचटीटीपी/2 पुश को मूल रूप से बनाया गया था. ऐप्लिकेशन डेवलपर को पता होता है कि कुछ रिसॉर्स की ज़रूरत है और वह उन्हें डाउनलोड करने के लिए पुश कर सकता है. जब क्लाइंट को पता चलता है कि उसे अतिरिक्त संसाधनों को फ़ेच करना है, तब वे पहले से ही ब्राउज़र के कैश मेमोरी में मौजूद होते हैं. एचटीटीपी/2 पुश को सही तरीके से लागू करना बहुत मुश्किल है. इसलिए, इसे इस्तेमाल करने का सुझाव नहीं दिया जाता. HTTP/3 को स्टैंडर्ड बनाने के दौरान, इस समस्या पर फिर से विचार किया जाएगा. फ़िलहाल, सबसे आसान तरीका यह है कि सभी ज़रूरी रिसॉर्स को इनलाइन किया जाए. हालांकि, इससे कैश मेमोरी का इस्तेमाल कम हो जाता है.

सीएसएस मॉड्यूल और Puppeteer पर आधारित प्री-रेंडरर की मदद से, हमारी ज़रूरी सीएसएस पहले से ही इनलाइन है. JavaScript के लिए, हमें अपने ज़रूरी मॉड्यूल और उनकी डिपेंडेंसी को इनलाइन करना होगा. इस्तेमाल किए जा रहे बंडलर के आधार पर, इस टास्क की मुश्किल अलग-अलग हो सकती है.

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

कोड को ज़्यादा से ज़्यादा हिस्सों में बांटना

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

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

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

हमने PROXX में एक lazy.js फ़ाइल बनाई है, जो स्टैटिक तौर पर वह सब कुछ इंपोर्ट करती है जिसकी हमें ज़रूरत नहीं है. इसके बाद, हम अपनी मुख्य फ़ाइल में lazy.js को डाइनैमिक तौर पर इंपोर्ट कर सकते हैं. हालांकि, हमारे कुछ Preact कॉम्पोनेंट lazy.js में आ गए, जो थोड़ी समस्या थी, क्योंकि Preact, बिना किसी खास सेटअप के, धीरे-धीरे लोड होने वाले कॉम्पोनेंट को मैनेज नहीं कर सकता. इस वजह से, हमने एक छोटा deferred कॉम्पोनेंट रैपर लिखा है. इससे, हमें असली कॉम्पोनेंट लोड होने तक प्लेसहोल्डर रेंडर करने की सुविधा मिलती है.

export default function deferred(componentPromise) {
  return class Deferred extends Component {
    constructor(props) {
      super(props);
      this.state = {
        LoadedComponent: undefined
      };
      componentPromise.then(component => {
        this.setState({ LoadedComponent: component });
      });
    }

    render({ loaded, loading }, { LoadedComponent }) {
      if (LoadedComponent) {
        return loaded(LoadedComponent);
      }
      return loading();
    }
  };
}

इस सुविधा के साथ, हम अपने render() फ़ंक्शन में किसी कॉम्पोनेंट के Promise का इस्तेमाल कर सकते हैं. उदाहरण के लिए, ऐनिमेशन वाली बैकग्राउंड इमेज को रेंडर करने वाले <Nebula> कॉम्पोनेंट को, कॉम्पोनेंट लोड होने के दौरान खाली <div> से बदल दिया जाएगा. कॉम्पोनेंट लोड होने और इस्तेमाल के लिए तैयार होने के बाद, <div> को असल कॉम्पोनेंट से बदल दिया जाएगा.

const NebulaDeferred = deferred(
  import("/components/nebula").then(m => m.default)
);

return (
  // ...
  <NebulaDeferred
    loading={() => <div />}
    loaded={Nebula => <Nebula />}
  />
);

इन सभी बदलावों के बाद, हमने अपने index.html को सिर्फ़ 20 केबी कर दिया. यह साइज़, ओरिजनल साइज़ के आधे से भी कम है. इसका एफ़एमपी और टीटीआई पर क्या असर पड़ता है? WebPageTest से पता चलेगा!

हमारे FMP और TTI में सिर्फ़ 100 मिलीसेकंड का अंतर है, क्योंकि यह सिर्फ़ इनलाइन किए गए JavaScript को पार्स और लागू करने का मामला है. 2G पर सिर्फ़ 5.4 सेकंड के बाद, ऐप्लिकेशन पूरी तरह से इंटरैक्टिव हो जाता है. कम ज़रूरी अन्य सभी मॉड्यूल, बैकग्राउंड में लोड किए जाते हैं.

ज़्यादा चालाकी

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

नतीजा

मेज़र करना ज़रूरी है. हमारा सुझाव है कि ऑप्टिमाइज़ेशन लागू करने से पहले, हमेशा मेज़रमेंट करें, ताकि आप उन समस्याओं पर समय बर्बाद न करें जो असल में मौजूद नहीं हैं. इसके अलावा, 3G कनेक्शन वाले असल डिवाइसों पर या WebPageTest पर मेज़रमेंट किए जाने चाहिए. अगर कोई असल डिवाइस उपलब्ध नहीं है, तो WebPageTest पर मेज़रमेंट करें.

फ़िल्मस्ट्रिप से यह जानकारी मिल सकती है कि उपयोगकर्ता को आपका ऐप्लिकेशन लोड होने में कैसा लगा. वॉटरफ़ॉल से यह पता चल सकता है कि लोड होने में लगने वाले लंबे समय की वजह कौनसे संसाधन हैं. यहां उन चीज़ों की चेकलिस्ट दी गई है जिन्हें करके, लोड होने की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है:

• एक कनेक्शन से ज़्यादा से ज़्यादा ऐसेट डिलीवर करें.
• पहले से लोड करें या ऐसे इनलाइन संसाधन जो पहले रेंडर और इंटरैक्टिविटी के लिए ज़रूरी हैं.
• ऐप्लिकेशन को पहले से रेंडर करके, लोड होने में लगने वाले समय को कम करें.
• इंटरैक्टिविटी के लिए ज़रूरी कोड की संख्या कम करने के लिए, ज़्यादा कोड स्प्लिटिंग का इस्तेमाल करें.

दूसरे हिस्से के लिए हमारे साथ बने रहें. इसमें हम कम रैम वाले डिवाइसों पर, रनटाइम की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के तरीके के बारे में बात करेंगे.