वेब परफ़ॉर्मेंस को आसान बनाया गया - Google I/O 2018 वर्शन

Google IO 2018 में, हमने ऐसे टूल, लाइब्रेरी, और ऑप्टिमाइज़ेशन की तकनीकों के बारे में बताया था जिनकी मदद से वेब की परफ़ॉर्मेंस को आसानी से बेहतर बनाया जा सकता है. यहां हम Oodles Theater ऐप्लिकेशन का इस्तेमाल करके, इनके बारे में बता रहे हैं. साथ ही, अनुमानित लोडिंग और Guess.js के नए इनिशिएटिव के साथ किए गए प्रयोगों के बारे में भी बताया गया है.

Ewa Gasperowicz

हम पिछले एक साल से, वेब को ज़्यादा तेज़ और बेहतर बनाने के लिए लगातार काम कर रहे हैं. इस वजह से, हमने नए टूल, तरीके, और लाइब्रेरी बनाई हैं. इनके बारे में हम इस लेख में आपको बताना चाहते हैं. पहले हिस्से में, हम आपको ऑप्टिमाइज़ेशन की कुछ तकनीकें बताएंगे. इनका इस्तेमाल हमने Oodles Theater ऐप्लिकेशन को डेवलप करते समय किया था. दूसरे हिस्से में, हम अनुमानित लोडिंग और Guess.js के नए इनिशिएटिव के साथ किए गए अपने प्रयोगों के बारे में बताएंगे.

परफ़ॉर्मेंस की ज़रूरत

इंटरनेट हर साल ज़्यादा से ज़्यादा डेटा का इस्तेमाल करता है. वेब की स्थिति देखने पर पता चलता है कि मोबाइल पर एक औसत पेज का साइज़ करीब 1.5 एमबी होता है. इसमें ज़्यादातर हिस्सा JavaScript और इमेज का होता है.

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

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

यूएक्स हैरारकी पिरामिड
पहला डायग्राम. उपयोगकर्ताओं के लिए स्पीड कितनी अहम है? (Speed Matters, Vol. 3)

हम जानते हैं कि परफ़ॉर्मेंस, उपयोगकर्ताओं के लिए अहम है. हालांकि, यह पता लगाना मुश्किल हो सकता है कि ऑप्टिमाइज़ेशन कहां से शुरू किया जाए. हालांकि, ऐसे टूल मौजूद हैं जिनसे आपको मदद मिल सकती है.

Lighthouse - परफ़ॉर्मेंस वर्कफ़्लो का आधार

Lighthouse, Chrome DevTools का एक हिस्सा है. इसकी मदद से, अपनी वेबसाइट की जांच की जा सकती है. साथ ही, इसे बेहतर बनाने के सुझाव भी मिलते हैं.

हमने हाल ही में कई नए परफ़ॉर्मेंस ऑडिट लॉन्च किए हैं. ये ऑडिट, डेवलपमेंट के रोज़मर्रा के वर्कफ़्लो में काफ़ी काम के हैं.

नए Lighthouse ऑडिट
दूसरी इमेज. नए Lighthouse ऑडिट

आइए, एक उदाहरण के ज़रिए जानें कि इनका फ़ायदा कैसे लिया जा सकता है: Oodles Theater ऐप्लिकेशन. यह एक छोटा डेमो वेब ऐप्लिकेशन है, जिसमें हमारे कुछ पसंदीदा इंटरैक्टिव Google Doodles आज़माए जा सकते हैं. यहां एक या दो गेम भी खेले जा सकते हैं.

ऐप्लिकेशन बनाते समय, हम यह पक्का करना चाहते थे कि इसकी परफ़ॉर्मेंस बेहतरीन हो. ऑप्टिमाइज़ेशन के लिए, लाइटहाउस रिपोर्ट से शुरुआत की गई थी.

Oodles ऐप्लिकेशन के लिए लाइटहाउस रिपोर्ट
तीसरी इमेज. Oodles ऐप्लिकेशन के लिए Lighthouse की रिपोर्ट

Lighthouse रिपोर्ट में, हमारे ऐप्लिकेशन की शुरुआती परफ़ॉर्मेंस बहुत खराब थी. 3G नेटवर्क पर, उपयोगकर्ता को पहली बार काम का पेंट या ऐप्लिकेशन के इंटरैक्टिव होने के लिए 15 सेकंड तक इंतज़ार करना पड़ता था. लाइटहाउस ने हमारी साइट की कई समस्याओं को हाइलाइट किया. साथ ही, 23 का परफ़ॉर्मेंस स्कोर भी इसी बात की पुष्टि करता है.

पेज का साइज़ 3.4 एमबी था - हमें इस साइज़ को कम करना था.

इससे हमें परफ़ॉर्मेंस से जुड़ी पहली चुनौती का सामना करना पड़ा: ऐसी चीज़ें ढूंढना जिन्हें आसानी से हटाया जा सके और इससे उपयोगकर्ताओं के अनुभव पर कोई असर न पड़े.

परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के अवसर

ग़ैर-ज़रूरी संसाधन हटाना

कुछ ऐसी चीज़ें हैं जिन्हें आसानी से हटाया जा सकता है: व्हाइटस्पेस और टिप्पणियां.

छोटा करने से मिलने वाले फ़ायदे
चौथी इमेज. JavaScript और सीएसएस को छोटा और कंप्रेस करना

Lighthouse, बिना छोटी की गई सीएसएस और JavaScript ऑडिट में इस अवसर को हाइलाइट करता है. हम अपनी बिल्ड प्रोसेस के लिए, webpack का इस्तेमाल कर रहे थे. इसलिए, कम साइज़ में फ़ाइल बनाने के लिए, हमने Uglify JS प्लग इन का इस्तेमाल किया.

छोटा करना एक सामान्य काम है. इसलिए, आपको अपनी पसंद की किसी भी बिल्ड प्रोसेस के लिए, पहले से तैयार समाधान मिल सकता है.

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

हम अपने कोड को होस्ट करने के लिए, Firebase Hosting का इस्तेमाल कर रहे थे. Firebase, डिफ़ॉल्ट रूप से gzipping की सुविधा चालू करता है. इसलिए, अपने कोड को एक अच्छे सीडीएन पर होस्ट करने की वजह से, हमें यह सुविधा बिना किसी शुल्क के मिली.

gzip, कॉन्टेंट को कंप्रेस करने का एक बहुत लोकप्रिय तरीका है. हालांकि, Zopfli और Brotli जैसे दूसरे तरीके भी लोकप्रिय हो रहे हैं. Brotli का इस्तेमाल ज़्यादातर ब्राउज़र में किया जा सकता है. साथ ही, सर्वर पर भेजने से पहले अपनी ऐसेट को पहले से कंप्रेस करने के लिए, बाइनरी का इस्तेमाल किया जा सकता है.

कैश मेमोरी से जुड़ी बेहतर नीतियों का इस्तेमाल करना

हमारा अगला कदम यह पक्का करना था कि ज़रूरत न होने पर, हम संसाधन दो बार न भेजें.

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

हमारा सुझाव है कि आप ज़्यादा से ज़्यादा रिसॉर्स को ज़्यादा से ज़्यादा समय तक सुरक्षित तरीके से कैश मेमोरी में सेव करें. साथ ही, अपडेट किए गए रिसॉर्स की फिर से पुष्टि करने के लिए, पुष्टि करने वाले टोकन उपलब्ध कराएं.

इस्तेमाल न किए जा रहे कोड हटाना

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

DevTools में कोड कवरेज
इमेज 5. कोड कवरेज की जांच करना

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

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

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

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

अगर हम एमवीसी अडैप्टर को हटा दें, तो हमारी स्टाइल 10 केबी तक कम हो जाती हैं
इमेज 6. अगर हम एमवीसी अडैप्टर को हटा दें, तो हमारी स्टाइल 10 केबी तक कम हो जाएंगी!

इससे हमारे सीएसएस बंडल का साइज़ 20 गुना कम हो गया. यह कम साइज़ के दो लाइन वाले कमिट के लिए काफ़ी अच्छा है.

इससे, हमारी परफ़ॉर्मेंस का स्कोर बढ़ गया. साथ ही, इंटरैक्टिव होने में लगने वाला समय भी काफ़ी बेहतर हो गया.

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

हमारे कोड का 95% हिस्सा इस्तेमाल नहीं किया गया था - अब भी यह 5% हिस्सा कहीं न कहीं मौजूद है. ऐसा लगता है कि हमारा एक कॉम्पोनेंट अब भी उस लाइब्रेरी के स्टाइल का इस्तेमाल कर रहा था - डूडल स्लाइडर में मौजूद छोटे ऐरो. हालांकि, यह बदलाव इतना छोटा था कि हम बटन में उन स्टाइल को मैन्युअल तरीके से वापस शामिल कर सकते थे.

लाइब्रेरी मौजूद न होने की वजह से बटन काम नहीं कर रहे हैं
इमेज 7. एक कॉम्पोनेंट अब भी हटाई गई लाइब्रेरी का इस्तेमाल कर रहा था

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

नेटवर्क पेलोड का साइज़ बहुत ज़्यादा न रखें

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

Lighthouse को पता चला है कि हमारे कुछ नेटवर्क पेलोड में समस्या है. यह पता लगाने के लिए, बड़े नेटवर्क पेलोड के ऑडिट का इस्तेमाल किया गया.

नेटवर्क के बड़े पेलोड का पता लगाना
इमेज 8. बड़े नेटवर्क पेलोड का पता लगाना

यहां हमने देखा कि हमारे पास 3 एमबी से ज़्यादा का कोड था, जिसे डाउनलोड किया जा रहा था. यह काफ़ी ज़्यादा है, खास तौर पर मोबाइल पर.

इस सूची में सबसे ऊपर, Lighthouse ने हाइलाइट किया कि हमारे पास एक JavaScript वेंडर बंडल था, जिसमें बिना कंप्रेस किए हुए 2 एमबी का कोड था. webpack ने भी इस समस्या को हाइलाइट किया है.

जैसा कि आपने सुना होगा: सबसे तेज़ अनुरोध वह होता है जो नहीं किया जाता.

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

हमारे मामले में, हमें बहुत सारे JavaScript बंडल से निपटना पड़ा. हालांकि, हमें इस बात की खुशी है कि JavaScript कम्यूनिटी के पास JavaScript बंडल की ऑडिटिंग करने वाले टूल का एक बेहतरीन सेट है.

JavaScript बंडल की ऑडिटिंग
इमेज 9. JavaScript बंडल की ऑडिटिंग

हमने webpack बंडल ऐनालाइज़र से शुरुआत की, जिससे हमें पता चला कि हम unicode नाम की एक डिपेंडेंसी शामिल कर रहे थे. यह 1.6 एमबी का पार्स किया गया JavaScript था, इसलिए काफ़ी ज़्यादा था.

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

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

इससे हमारी परफ़ॉर्मेंस पर काफ़ी असर पड़ा. इस बदलाव और अपने JavaScript बंडल के साइज़ को कम करने के अन्य अवसरों को खोजने के बीच, हमने 2.1 एमबी कोड बचाया.

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

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

कोड को अलग-अलग करने की सुविधा की मदद से, JavaScript के बूट-अप में लगने वाले समय को कम करना

बड़े नेटवर्क पेलोड से हमारे ऐप्लिकेशन पर काफ़ी असर पड़ सकता है. हालांकि, एक और चीज़ से भी काफ़ी असर पड़ सकता है. वह चीज़ है JavaScript.

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

ब्राउज़र, JavaScript को इसी तरह प्रोसेस करता है.

JavaScript प्रोसेसिंग
इमेज 10. JavaScript प्रोसेसिंग

सबसे पहले, हमें वह स्क्रिप्ट डाउनलोड करनी होगी. इसके बाद, हमारे पास एक JavaScript इंजन होता है, जिसे उस कोड को पार्स करना होता है, उसे कंपाइल करना होता है, और उसे लागू करना होता है.

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

अपने ऐप्लिकेशन में इन समस्याओं का पता लगाने में आपकी मदद करने के लिए, हमने Lighthouse में एक नया JavaScript बूट-अप टाइम ऑडिट जोड़ा है.

JavaScript को चालू होने में लगने वाला समय
इमेज 11. JavaScript को खुलने में लगने वाले समय का ऑडिट

वहीं, Oodle ऐप्लिकेशन के मामले में, हमें पता चला कि JavaScript को बूट-अप होने में 1.8 सेकंड लगे. दरअसल, हम अपने सभी रूट और कॉम्पोनेंट को स्टैटिक तौर पर एक बड़े JavaScript बंडल में इंपोर्ट कर रहे थे.

इस समस्या को हल करने के लिए, कोड को अलग-अलग हिस्सों में बांटने की तकनीक का इस्तेमाल किया जा सकता है.

कोड को अलग-अलग हिस्सों में बांटना, पिज़्ज़ा की तरह है

कोड को अलग-अलग हिस्सों में बांटने का मतलब है कि अपने उपयोगकर्ताओं को पूरे पिज़्ज़ा के बराबर JavaScript देने के बजाय, उन्हें ज़रूरत के हिसाब से एक स्लाइस दिया जाए.

कोड को अलग-अलग हिस्सों में बांटने की सुविधा, रूट लेवल या कॉम्पोनेंट लेवल पर लागू की जा सकती है. यह React और React Loadable, Vue.js, Angular, Polymer, Preact, और कई अन्य लाइब्रेरी के साथ बेहतर तरीके से काम करता है.

हमने अपने ऐप्लिकेशन में कोड स्प्लिटिंग को शामिल किया है. साथ ही, हमने स्टैटिक इंपोर्ट से डाइनैमिक इंपोर्ट पर स्विच किया है. इससे, हमें ज़रूरत के हिसाब से कोड को असिंक्रोनस तौर पर लेज़ी लोड करने की सुविधा मिलती है.

डाइनैमिक इंपोर्ट की मदद से कोड को अलग-अलग हिस्सों में बांटना
इमेज 13. डाइनैमिक इंपोर्ट की मदद से कोड को अलग-अलग हिस्सों में बांटना

इससे हमारे बंडल का साइज़ कम हो गया. साथ ही, JavaScript को बूट अप होने में लगने वाला समय भी कम हो गया. इसके बाद, यह समय 0.78 सेकंड हो गया. इससे ऐप्लिकेशन 56% तेज़ हो गया.

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

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

चित्र अनुकूलित करें

इमेज लोड होने की परफ़ॉर्मेंस से जुड़ा जोक

हम Oodle ऐप्लिकेशन में कई इमेज का इस्तेमाल कर रहे हैं. माफ़ करें, Lighthouse इस बारे में उतना उत्साहित नहीं था जितना हम थे. असल में, इमेज से जुड़े तीनों ऑडिट में हम फ़ेल हुए हैं.

हमने अपनी इमेज को ऑप्टिमाइज़ करना भूल गए थे. हमने इमेज का साइज़ सही से नहीं तय किया था. साथ ही, हमें इमेज के दूसरे फ़ॉर्मैट का इस्तेमाल करके भी कुछ फ़ायदा मिल सकता था.

इमेज ऑडिट
इमेज 14. Lighthouse की मदद से इमेज का ऑडिट करना

हमने अपनी इमेज को ऑप्टिमाइज़ करने से शुरुआत की.

एक बार के ऑप्टिमाइज़ेशन राउंड के लिए, ImageOptim या XNConvert जैसे विज़ुअल टूल का इस्तेमाल किया जा सकता है.

imagemin जैसी लाइब्रेरी की मदद से, अपनी बिल्ड प्रोसेस में इमेज ऑप्टिमाइज़ेशन का चरण जोड़ना, ऑटोमेटेड तरीके से काम करने का एक बेहतर तरीका है.

इससे, आने वाले समय में जोड़ी गई इमेज अपने-आप ऑप्टिमाइज़ हो जाएंगी. कुछ सीडीएन, जैसे कि Akamai या तीसरे पक्ष के सलूशन, जैसे कि Cloudinary, Fastly या Uploadcare, आपको इमेज ऑप्टिमाइज़ेशन के बेहतरीन सलूशन उपलब्ध कराते हैं. इसलिए, अपनी इमेज को उन सेवाओं पर भी आसानी से होस्ट किया जा सकता है.

अगर आपको लागत या इंतज़ार की अवधि की समस्याओं की वजह से ऐसा नहीं करना है, तो Thumbor या Imageflow जैसे प्रोजेक्ट, खुद को होस्ट करने के विकल्प उपलब्ध कराते हैं.

ऑप्टिमाइज़ेशन से पहले और बाद में
इमेज 15. ऑप्टिमाइज़ेशन से पहले और बाद में

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

अपनी साइट पर मौजूद कई इमेज के लिए ऐसा करने से, हमें पेज के कुल वज़न को काफ़ी कम करने में मदद मिली.

ऐनिमेशन वाले कॉन्टेंट के लिए सही फ़ॉर्मैट का इस्तेमाल करना

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

Oodle ऐप्लिकेशन में, हम होम पेज पर इंट्रो सीक्वेंस के तौर पर GIF का इस्तेमाल कर रहे थे. Lighthouse के मुताबिक, बेहतर वीडियो फ़ॉर्मैट का इस्तेमाल करके, हम 7 एमबी से ज़्यादा बचा सकते हैं. हमारी क्लिप का साइज़ करीब 7.3 एमबी था, जो किसी भी सामान्य वेबसाइट के लिए बहुत ज़्यादा है. इसलिए, हमने इसे एक वीडियो एलिमेंट में बदल दिया है. इसमें दो सोर्स फ़ाइलें हैं - एमपी4 और वेबएम. इससे, ज़्यादा ब्राउज़र पर वीडियो चलाया जा सकता है.

ऐनिमेटेड GIF को वीडियो से बदलना
इमेज 16. ऐनिमेट किए गए GIF को वीडियो से बदलना

हमने अपने ऐनिमेशन GIF को mp4 फ़ाइल में बदलने के लिए, FFmpeg टूल का इस्तेमाल किया. WebM फ़ॉर्मैट में, आपको ज़्यादा बचत मिलती है - ImageOptim API आपके लिए ऐसा कन्वर्ज़न कर सकता है.

ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4

इस कन्वर्ज़न की मदद से, हमने अपने कुल वजन का 80% से ज़्यादा बचा लिया. इससे, साइज़ करीब 1 एमबी हो गया.

फिर भी, 1 एमबी का डेटा भेजना, इंटरनेट की स्पीड के हिसाब से ज़्यादा है. खास तौर पर, सीमित बैंडविड्थ वाले उपयोगकर्ता के लिए. सौभाग्य से, हम Effective Type API का इस्तेमाल करके यह पता लगा पाए कि वे कम बैंडविड्थ का इस्तेमाल कर रहे हैं. इसलिए, हमने उन्हें एक छोटा JPEG दिया.

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

if (navigator.connection.effectiveType) { ... }

इससे, साइट को इस्तेमाल करने का अनुभव थोड़ा कम हो जाता है. हालांकि, कम से कम धीमे इंटरनेट कनेक्शन पर साइट को इस्तेमाल किया जा सकता है.

स्क्रीन पर न दिखने वाली इमेज को लेज़ी-लोड करना

कैरसेल, स्लाइडर या बहुत लंबे पेजों पर अक्सर इमेज लोड होती हैं. हालांकि, उपयोगकर्ता को वे इमेज तुरंत नहीं दिखतीं.

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

ब्राउज़र में, फ़िलहाल लेज़ी लोडिंग की सुविधा काम नहीं करती. इसलिए, हमें इस सुविधा को जोड़ने के लिए JavaScript का इस्तेमाल करना पड़ता है. हमने अपने Oodle कवर में, धीरे-धीरे लोड होने की सुविधा जोड़ने के लिए, Lazysizes लाइब्रेरी का इस्तेमाल किया है.

<!-- Import library -->
import lazysizes from 'lazysizes'  <!-- or -->
<script src="lazysizes.min.js"></script>

<!-- Use it -->

<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
    data-sizes="auto"
    data-src="image2.jpg"
    data-srcset="image1.jpg 300w,
    image2.jpg 600w,
    image3.jpg 900w"/>

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

इस बदलाव के बाद, हमारी इमेज मांग पर फ़ेच की जा रही हैं. अगर आपको इस विषय के बारे में ज़्यादा जानना है, तो images.guide पर जाएं. यह एक बहुत ही आसान और बेहतरीन संसाधन है.

ब्राउज़र को ज़रूरी संसाधनों को जल्द से जल्द डिलीवर करने में मदद करना

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

पेज के लेखक के तौर पर, हमें ब्राउज़र को यह बताना चाहिए कि हमारे लिए कौनसी जानकारी ज़्यादा अहम है. शुक्र है कि पिछले कुछ सालों से ब्राउज़र वेंडर, हमें इस काम में मदद करने के लिए कई सुविधाएं जोड़ रहे हैं. जैसे, link rel=preconnect, preload या prefetch जैसे संसाधन के बारे में अहम जानकारी.

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

आइए देखें कि Lighthouse, इनमें से कुछ सुविधाओं का बेहतर तरीके से इस्तेमाल करने के लिए, हमें कैसे मदद करता है.

Lighthouse सबसे पहले हमें यह बताता है कि किसी भी ऑरिजिन के लिए, कई बार ज़्यादा खर्च वाले राउंड ट्रिप से बचें.

किसी भी ऑरिजिन के लिए, एक से ज़्यादा बार और ज़्यादा किराये के लिए, राउंड ट्रिप से बचें
इमेज 17. किसी भी ऑरिजिन के लिए, एक से ज़्यादा बार और ज़्यादा किराये में यात्रा करने से बचें

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

लिंक rel preconnect का फ़ायदा उठाकर, हम कनेक्शन में लगने वाले समय को असरदार तरीके से छिपा सकते हैं.

खास तौर पर, Google Fonts जैसी सेवाओं पर, जहां हमारे फ़ॉन्ट फ़ेस की सीएसएस को googleapis.com पर होस्ट किया जाता है और हमारे फ़ॉन्ट संसाधनों को Gstatic पर होस्ट किया जाता है, इसका काफ़ी असर पड़ सकता है. इसलिए, हमने इस ऑप्टिमाइज़ेशन को लागू किया और कुछ सौ मिलीसेकंड बचाए.

Lighthouse का अगला सुझाव है कि हम मुख्य अनुरोधों को पहले से लोड करें.

मुख्य अनुरोधों को पहले से लोड करना
इमेज 18. मुख्य अनुरोधों को पहले से लोड करना

<link rel=preload> बहुत ही बेहतरीन है. यह ब्राउज़र को बताता है कि मौजूदा नेविगेशन के हिस्से के तौर पर, किसी रिसॉर्स की ज़रूरत है. साथ ही, यह ब्राउज़र को जल्द से जल्द रिसॉर्स फ़ेच करने की कोशिश करता है.

यहां Lighthouse हमें बता रहा है कि हमें अपने मुख्य वेब फ़ॉन्ट के संसाधनों को प्रीलोड करना चाहिए, क्योंकि हम दो वेब फ़ॉन्ट लोड कर रहे हैं.

वेब फ़ॉन्ट को पहले से लोड करने का तरीका यह है - rel=preload तय करने के बाद, as को फ़ॉन्ट के टाइप के साथ पास करें. इसके बाद, आपको उस फ़ॉन्ट के टाइप की जानकारी देनी होगी जिसे लोड करना है, जैसे कि woff2.

इससे आपके पेज पर काफ़ी असर पड़ सकता है.

संसाधनों को पहले से लोड करने का असर
इमेज 19. संसाधनों को पहले से लोड करने का असर

आम तौर पर, अगर वेब फ़ॉन्ट आपके पेज के लिए ज़रूरी हैं, तो लिंक rel preload का इस्तेमाल किए बिना, ब्राउज़र को सबसे पहले आपका एचटीएमएल फ़ेच करना होगा. इसके बाद, उसे आपकी सीएसएस को पार्स करना होगा और आखिर में, वह आपके वेब फ़ॉन्ट फ़ेच करेगा.

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

Google Fonts का इस्तेमाल करके फ़ॉन्ट को पहले से लोड करने की कोशिश करना, इतना आसान नहीं है. इसमें एक समस्या है.

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

हमारे मामले में, Google वेब फ़ॉन्ट हेल्पर टूल का इस्तेमाल करके, कुछ वेब फ़ॉन्ट को ऑफ़लाइन डाउनलोड किया जा सकता है और उन्हें स्थानीय तौर पर सेट अप किया जा सकता है. इसलिए, इस टूल को आज़माएं.

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

एक्सपेरिमेंट के तौर पर उपलब्ध: प्राथमिकता के सुझाव

आज हम आपके साथ कुछ खास जानकारी शेयर करना चाहते हैं. हम संसाधन के सुझावों और प्रीलोड जैसी सुविधाओं के साथ-साथ, ब्राउज़र की एक नई सुविधा पर काम कर रहे हैं. इसे हम प्राथमिकता के सुझाव कहते हैं.

शुरुआत में दिखने वाले कॉन्टेंट के लिए प्राथमिकता सेट करना
इमेज 20. प्राथमिकता के बारे में सलाह

यह एक नई सुविधा है. इसकी मदद से, ब्राउज़र को यह बताया जा सकता है कि कोई रिसॉर्स कितना ज़रूरी है. यह एक नया एट्रिब्यूट - अहमियत - दिखाता है. इसकी वैल्यू, कम, ज़्यादा या ऑटो होती हैं.

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

हमारे Oodle ऐप्लिकेशन के मामले में, इसकी मदद से हमने एक ऐसी जगह को ऑप्टिमाइज़ किया जहां हमने ऐप्लिकेशन को बेहतर बनाया.

शुरुआत में दिखने वाले कॉन्टेंट के लिए प्राथमिकता सेट करना
इमेज 21. शुरुआत में दिखने वाले कॉन्टेंट के लिए प्राथमिकता सेट करना

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

हमें उम्मीद है कि यह सुविधा कुछ हफ़्तों में Canary पर उपलब्ध हो जाएगी. इसलिए, इस पर नज़र बनाए रखें.

वेब फ़ॉन्ट लोड करने की रणनीति हो

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

हम अब Lighthouse में इस समस्या को हाइलाइट करते हैं. इसके लिए, वेब फ़ॉन्ट लोड होने के दौरान, न दिखने वाले टेक्स्ट से बचें के ऑडिट का इस्तेमाल किया जाता है.

वेब फ़ॉन्ट लोड होने के दौरान, टेक्स्ट को न दिखाने से बचें
इमेज 22. वेब फ़ॉन्ट लोड होने के दौरान, टेक्स्ट को न दिखने से रोकना

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

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

    @font-face {
      font-family: 'Montserrat';
      font-style: normal;
      font-display: swap;
      font-weight: 400;
      src: local('Montserrat Regular'), local('Montserrat-Regular'),
          /* Chrome 26+, Opera 23+, Firefox 39+ */
          url('montserrat-v12-latin-regular.woff2') format('woff2'),
            /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
          url('montserrat-v12-latin-regular.woff') format('woff');
    }

फ़ॉन्ट डिसप्ले से यह तय करने में मदद मिलती है कि वेब फ़ॉन्ट, स्वैप होने में लगने वाले समय के आधार पर कैसे रेंडर होंगे या फ़ॉलबैक करेंगे.

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

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

फ़ॉन्ट डिसप्ले का नतीजा
इमेज 23. फ़ॉन्ट डिसप्ले का नतीजा

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

वेब प्लैटफ़ॉर्म की कई सुविधाओं का इस्तेमाल करके, फ़ॉन्ट लोड होने के अनुभव को ऑप्टिमाइज़ किया जा सकता है. साथ ही, Zach Leatherman का Web Font Recipes repo भी देखें, क्योंकि यह बहुत बढ़िया है.

विज्ञापन दिखाने से रोकने वाली स्क्रिप्ट कम करें

हमारे ऐप्लिकेशन के कुछ ऐसे हिस्से हैं जिन्हें डाउनलोड चेन में पहले से शामिल किया जा सकता है, ताकि उपयोगकर्ताओं को कम से कम कुछ बुनियादी अनुभव पहले ही मिल सके.

Lighthouse की टाइमलाइन स्ट्रिप पर, यह देखा जा सकता है कि शुरुआती कुछ सेकंड के दौरान, जब सभी संसाधन लोड हो रहे होते हैं, तब उपयोगकर्ता को कोई कॉन्टेंट नहीं दिखता.

पेज को रेंडर करने में रुकावट डालने वाली स्टाइलशीट की संख्या कम करना
इमेज 24. रेंडर करने में रुकावट डालने वाली स्टाइलशीट के इस्तेमाल को कम करना

बाहरी स्टाइलशीट डाउनलोड और प्रोसेस करने की वजह से, रेंडर करने की प्रोसेस आगे नहीं बढ़ पा रही है.

हम कुछ स्टाइल को थोड़ा पहले डिलीवर करके, रेंडरिंग के अहम पाथ को ऑप्टिमाइज़ करने की कोशिश कर सकते हैं.

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

हमारे मामले में, हमने बिल्ड के दौरान index.html में अपने अहम कॉन्टेंट को इनलाइन करने के लिए, Critical नाम के NPM मॉड्यूल का इस्तेमाल किया.

इस मॉड्यूल ने ज़्यादातर काम हमारे लिए कर दिया था. हालांकि, अलग-अलग रूट पर इसे आसानी से काम कराने में थोड़ी मुश्किल हुई.

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

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

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

नतीजा

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

Lighthouse परफ़ॉर्मेंस स्कोर 23 से बढ़कर 91 हो गया. स्पीड के मामले में यह काफ़ी अच्छी प्रोग्रेस है. हमने Lighthouse की रिपोर्ट को लगातार देखते रहे और उसमें बताए गए सुझावों को लागू किया. अगर आपको यह जानना है कि हमने तकनीकी तौर पर सभी सुधार कैसे लागू किए, तो हमारे रिपॉज़िटरी पर जाएं. खास तौर पर, वहां मौजूद पीआर पर जाएं.

अनुमानित परफ़ॉर्मेंस - डेटा से मिलने वाले उपयोगकर्ता अनुभव

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

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

हमारे पास आज भी डेटा उपलब्ध है, ताकि हम अपने ऑप्टिमाइज़ेशन को बेहतर तरीके से बता सकें. Google Analytics Reporting API का इस्तेमाल करके, हम अपनी साइट पर सबसे ज़्यादा देखे गए अगले पेज और किसी भी यूआरएल के लिए, साइट छोड़ने वाले लोगों के प्रतिशत को देख सकते हैं. इससे, यह तय करने में मदद मिलती है कि किन संसाधनों को प्राथमिकता दी जानी चाहिए.

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

वेब ऐप्लिकेशन के लिए डेटा-ड्रिवन बंडलिंग
इमेज 25. वेब ऐप्लिकेशन के लिए डेटा-ड्रिवन बंडलिंग

इन प्रयोगों को आसान बनाने के लिए, हमें एक नई पहल का एलान करते हुए खुशी हो रही है. इसे हम Guess.js कह रहे हैं.

Guess.js
इमेज 26. Guess.js

Guess.js एक ऐसा प्रोजेक्ट है जो वेब के लिए, डेटा-ड्रिवन उपयोगकर्ता अनुभव पर फ़ोकस करता है. हमें उम्मीद है कि इससे, वेब की परफ़ॉर्मेंस को बेहतर बनाने के लिए डेटा का इस्तेमाल करने के बारे में जानने में मदद मिलेगी. यह पूरी तरह से ओपन सोर्स है और फ़िलहाल, GitHub पर उपलब्ध है. इसे ओपन सोर्स कम्यूनिटी के साथ मिलकर बनाया गया था. इसमें Minko Gechev, Gatsby के Kyle Matthews, Katie Hempenius, और कई अन्य लोगों की मदद ली गई थी.

Guess.js को आज़माएं और हमें बताएं कि आपको यह कैसा लगा.

खास जानकारी

स्कोर और मेट्रिक, वेब की स्पीड को बेहतर बनाने में मददगार होते हैं. हालांकि, ये सिर्फ़ एक तरीका हैं, न कि लक्ष्य.

हम सभी ने कभी न कभी, किसी पेज को लोड होने में लगने वाले समय को महसूस किया है. हालांकि, अब हमारे पास अपने उपयोगकर्ताओं को बेहतर अनुभव देने का मौका है.

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

खास तौर पर इन लोगों का धन्यवाद: Ward Peeters, Minko Gechev, Kyle Mathews, Katie Hempenius, Dom Farolino, Yoav Weiss, Susie Lu, Yusuke Utsunomiya, Tom Ankers, Lighthouse & Google Doodles.