Google IO 2018 में, हमने ऐसे टूल, लाइब्रेरी, और ऑप्टिमाइज़ेशन की तकनीकों के बारे में बताया था जिनकी मदद से वेब की परफ़ॉर्मेंस को आसानी से बेहतर बनाया जा सकता है. यहां हमने The Oodles थिएटर ऐप्लिकेशन का इस्तेमाल करके उनके बारे में जानकारी दी है. साथ ही, हम अनुमानित लोडिंग और नए Guess.js पहल के साथ किए गए प्रयोगों के बारे में भी बात करेंगे.
पिछले एक साल से, हम वेब को ज़्यादा तेज़ और बेहतर बनाने के लिए लगातार काम कर रहे हैं. इससे हमें नए टूल, तरीके, और लाइब्रेरी का पता चला. ये तरीके, हम इस लेख में आपके साथ शेयर करेंगे. पहले हिस्से में, हम आपको ऑप्टिमाइज़ेशन की कुछ तकनीकें बताएंगे. इनका इस्तेमाल हमने Oodles Theater ऐप्लिकेशन को डेवलप करते समय किया था. दूसरे हिस्से में, हम अनुमानित लोडिंग और Guess.js के नए इनिशिएटिव के साथ किए गए अपने प्रयोगों के बारे में बताएंगे.
परफ़ॉर्मेंस की ज़रूरत
इंटरनेट हर साल ज़्यादा से ज़्यादा डेटा का इस्तेमाल करता है. वेब की स्थिति देखने पर हमें पता चलता है कि मोबाइल डिवाइस पर एक मीडियन पेज करीब 1.5 एमबी है, जिसमें से ज़्यादातर JavaScript और इमेज हैं.
वेबसाइटों का साइज़ बढ़ने के साथ-साथ, नेटवर्क में लगने वाला समय, सीपीयू की सीमाएं, रेंडर ब्लॉकिंग पैटर्न या तीसरे पक्ष का ज़रूरत से ज़्यादा कोड जैसी अन्य वजहों से, परफ़ॉर्मेंस से जुड़ी समस्याएं और भी मुश्किल हो जाती हैं.
ज़्यादातर उपयोगकर्ता, अपनी ज़रूरतों के हिसाब से यूज़र एक्सपीरियंस की हैरारकी में, स्पीड को सबसे ऊपर रखते हैं. यह बहुत हैरान करने वाली बात नहीं है, क्योंकि जब तक पेज लोड नहीं हो जाता, तब तक आप वाकई बहुत कुछ नहीं कर सकते. इस पेज से कोई फ़ायदा नहीं मिलता और न ही इसकी खूबसूरती की तारीफ़ की जा सकती है.
हम जानते हैं कि परफ़ॉर्मेंस, उपयोगकर्ताओं के लिए अहम है. हालांकि, यह पता लगाना मुश्किल हो सकता है कि ऑप्टिमाइज़ेशन कहां से शुरू किया जाए. हालांकि, ऐसे टूल मौजूद हैं जिनसे आपको मदद मिल सकती है.
लाइटहाउस - परफ़ॉर्मेंस वर्कफ़्लो के लिए आधार
Lighthouse, Chrome DevTools का एक हिस्सा है. इसकी मदद से, अपनी वेबसाइट की जांच की जा सकती है. साथ ही, इसे बेहतर बनाने के सुझाव भी मिलते हैं.
हमने हाल ही में कई नए परफ़ॉर्मेंस ऑडिट लॉन्च किए हैं. ये ऑडिट, डेवलपमेंट वर्कफ़्लो में रोज़ के काम के होते हैं.
आइए एक व्यावहारिक उदाहरण की मदद से उनका फ़ायदा उठा सकते हैं: Oodles थिएटर ऐप्लिकेशन. यह एक छोटा डेमो वेब ऐप्लिकेशन है, जिसमें आप हमारे कुछ पसंदीदा इंटरैक्टिव Google डूडल आज़मा सकते हैं और एक या दो गेम भी खेल सकते हैं.
ऐप्लिकेशन बनाते समय, हम यह पक्का करना चाहते थे कि यह बेहतर तरीके से काम करे. ऑप्टिमाइज़ेशन का शुरुआती पॉइंट, लाइटहाउस रिपोर्ट था.
Lighthouse रिपोर्ट में, हमारे ऐप्लिकेशन की शुरुआती परफ़ॉर्मेंस बहुत खराब थी. 3G नेटवर्क पर, उपयोगकर्ता को पहली बार काम का पेंट या ऐप्लिकेशन के इंटरैक्टिव होने के लिए 15 सेकंड तक इंतज़ार करना पड़ता था. लाइटहाउस ने हमारी साइट की कई समस्याओं को हाइलाइट किया. साथ ही, 23 का कुल परफ़ॉर्मेंस स्कोर भी इसी बात की पुष्टि करता है.
पेज का साइज़ 3.4 एमबी था - हमें इस साइज़ को कम करना था.
इससे हमें परफ़ॉर्मेंस से जुड़ी पहली चुनौती का सामना करना पड़ा: ऐसी चीज़ें ढूंढना जिन्हें आसानी से हटाया जा सके और इससे उपयोगकर्ताओं के अनुभव पर कोई असर न पड़े.
परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के अवसर
ग़ैर-ज़रूरी संसाधन हटाना
कुछ ऐसी चीज़ें हैं जिन्हें आसानी से हटाया जा सकता है: व्हाइटस्पेस और टिप्पणियां.
Lighthouse, बिना छोटी की गई सीएसएस और JavaScript ऑडिट में इस अवसर को हाइलाइट करता है. हम अपनी बिल्ड प्रोसेस के लिए, webpack का इस्तेमाल कर रहे थे. इसलिए, कम साइज़ में कॉन्टेंट बनाने के लिए, हमने Uglify JS प्लग इन का इस्तेमाल किया.
छोटा करना एक सामान्य काम है. इसलिए, आपको अपनी पसंद की किसी भी बिल्ड प्रोसेस के लिए, पहले से तैयार समाधान मिल सकता है.
उस स्पेस में टेक्स्ट कंप्रेस करने की सुविधा चालू करें भी एक काम का ऑडिट है. बिना कंप्रेस की गई फ़ाइलें भेजने की कोई ज़रूरत नहीं है. साथ ही, इन दिनों ज़्यादातर सीडीएन इस पर काम करते हैं.
हम अपने कोड को होस्ट करने के लिए, Firebase Hosting का इस्तेमाल कर रहे थे. Firebase, डिफ़ॉल्ट रूप से gzipping की सुविधा चालू करता है. इसलिए, अपने कोड को एक अच्छे सीडीएन पर होस्ट करने की वजह से, हमें यह सुविधा बिना किसी शुल्क के मिली.
gzip, कॉन्टेंट को कंप्रेस करने का एक बहुत लोकप्रिय तरीका है. हालांकि, Zopfli और Brotli जैसे दूसरे तरीके भी लोकप्रिय हो रहे हैं. Brotli का इस्तेमाल ज़्यादातर ब्राउज़र में किया जा सकता है. साथ ही, सर्वर पर भेजने से पहले अपनी ऐसेट को पहले से संकुचित करने के लिए, बाइनरी का इस्तेमाल किया जा सकता है.
कैश मेमोरी से जुड़ी बेहतर नीतियों का इस्तेमाल करना
हमारा अगला कदम यह पक्का करना था कि ज़रूरत न होने पर, हम संसाधनों को दो बार न भेजें.
Lighthouse में कैश मेमोरी से जुड़ी खराब नीति के ऑडिट से हमें पता चला कि हम अपनी कैश मेमोरी से जुड़ी रणनीतियों को ऑप्टिमाइज़ कर सकते हैं, ताकि हम इस नीति का पालन कर सकें. हमने अपने सर्वर में, मैक्स-ऐज एक्सपाइरेशन हेडर सेट करके यह पक्का किया है कि उपयोगकर्ता दोबारा आने पर, पहले डाउनलोड किए गए संसाधनों का फिर से इस्तेमाल कर सके.
हमारा सुझाव है कि आप ज़्यादा से ज़्यादा रिसॉर्स को ज़्यादा से ज़्यादा समय तक सुरक्षित तरीके से कैश मेमोरी में सेव करें. साथ ही, अपडेट किए गए रिसॉर्स की फिर से पुष्टि करने के लिए, पुष्टि करने वाले टोकन उपलब्ध कराएं.
इस्तेमाल न किए जा रहे कोड हटाना
अब तक हमने ग़ैर-ज़रूरी डाउनलोड के साफ़ तौर पर दिखने वाले हिस्सों को हटा दिया है. हालांकि, ऐसे हिस्सों का क्या होगा जो साफ़ तौर पर नहीं दिखते? उदाहरण के लिए, इस्तेमाल न किया गया कोड.
कभी-कभी हम अपने ऐप्लिकेशन में ऐसे कोड शामिल कर देते हैं जो वाकई ज़रूरी नहीं होता. ऐसा खास तौर पर तब होता है, जब आपने अपने ऐप्लिकेशन पर लंबे समय तक काम किया हो, आपकी टीम या डिपेंडेंसी बदल गई हों, और कभी-कभी कोई अनाथ लाइब्रेरी रह गई हो. हमारे साथ भी यही हुआ.
शुरुआत में, हम अपने ऐप्लिकेशन का प्रोटोटाइप तुरंत बनाने के लिए, Material Components लाइब्रेरी का इस्तेमाल कर रहे थे. समय के साथ, हमने अपने ऐप्लिकेशन को ज़्यादा पसंद के मुताबिक बनाया और उस लाइब्रेरी को पूरी तरह से भूल गए. सौभाग्य से, कोड कवरेज की जांच से हमें अपने बंडल में इसे फिर से ढूंढने में मदद मिली.
DevTools में, अपने ऐप्लिकेशन के रनटाइम और लोड होने में लगने वाले समय, दोनों के लिए कोड कवरेज के आंकड़े देखे जा सकते हैं. आपको सबसे नीचे दिए गए स्क्रीनशॉट में दो बड़ी लाल स्ट्रिप दिख सकती हैं - हमारे पास 95% से ज़्यादा सीएसएस का इस्तेमाल नहीं किया गया था. साथ ही, JavaScript का भी एक बड़ा हिस्सा इस्तेमाल नहीं किया गया था.
Lighthouse ने इस्तेमाल न किए गए सीएसएस नियमों के ऑडिट में भी इस समस्या का पता लगाया. इससे 400 केबी से ज़्यादा की बचत हो सकती है. इसलिए, हम अपने कोड पर वापस आए और हमने उस लाइब्रेरी के JavaScript और सीएसएस, दोनों हिस्सों को हटा दिया.
इससे हमारे सीएसएस बंडल 20 गुना नीचे आ गए, जो कि दो लाइन तक की छोटी अवधि के लिए काफ़ी अच्छा है.
बेशक, इससे हमारा परफ़ॉर्मेंस स्कोर बेहतर हुआ और टाइम टू इंटरैक्टिव भी पहले से बेहतर हो गया.
हालांकि, इस तरह के बदलावों के बाद, सिर्फ़ अपनी मेट्रिक और स्कोर देखना काफ़ी नहीं है. असल कोड को हटाने में हमेशा जोखिम रहता है. इसलिए, आपको हमेशा संभावित रेग्रेशन पर नज़र रखनी चाहिए.
हमारे कोड का 95% हिस्सा इस्तेमाल नहीं किया गया था - अब भी यह 5% हिस्सा कहीं न कहीं मौजूद है. ऐसा लगता है कि हमारा एक कॉम्पोनेंट अब भी उस लाइब्रेरी के स्टाइल का इस्तेमाल कर रहा था - डूडल स्लाइडर में मौजूद छोटे ऐरो. हालाँकि, यह बहुत छोटा था, इसलिए हम शुरू कर सकते थे और उन स्टाइल को फिर से बटन में मैन्युअल तरीके से शामिल कर सकते थे.
इसलिए, अगर कोड हटाया जाता है, तो पक्का करें कि आपके पास जांच का सही वर्कफ़्लो हो, ताकि आपको विज़ुअल में होने वाले संभावित बदलावों से बचा जा सके.
नेटवर्क पेलोड का साइज़ बहुत ज़्यादा न रखें
हम जानते हैं कि बड़े रिसॉर्स की वजह से, वेब पेज लोड होने में ज़्यादा समय लग सकता है. इनसे हमारे उपयोगकर्ताओं को पैसे चुकाने पड़ सकते हैं और उनके डेटा प्लान पर काफ़ी असर पड़ सकता है. इसलिए, इस बात का ध्यान रखना ज़रूरी है.
Lighthouse को पता चला है कि हमारे कुछ नेटवर्क पेलोड में समस्या है. यह पता लगाने के लिए, बड़े नेटवर्क पेलोड के ऑडिट का इस्तेमाल किया गया.
यहां हमने देखा कि हमारे पास 3 एमबी से भी ज़्यादा का कोड था जिसे शिप किया जा रहा था – जो कि काफ़ी ज़्यादा है, खास तौर पर मोबाइल पर.
इस सूची में सबसे ऊपर, Lighthouse ने हाइलाइट किया कि हमारे पास एक JavaScript वेंडर बंडल था, जिसमें बिना कंप्रेस किए हुए 2 एमबी का कोड था. इस समस्या को webpack ने भी हाइलाइट किया है.
जैसा कि कहा जाता है: सबसे तेज़ अनुरोध वह है जो अभी तक नहीं किया गया.
आम तौर पर, आपको अपने उपयोगकर्ताओं को दिखाए जा रहे हर एसेट की वैल्यू को मेज़र करना चाहिए. साथ ही, उन एसेट की परफ़ॉर्मेंस को मेज़र करना चाहिए और यह तय करना चाहिए कि शुरुआती अनुभव के साथ, उन्हें शिप करना सही है या नहीं. ऐसा इसलिए होता है, क्योंकि कभी-कभी ये ऐसेट स्थगित हो सकती हैं या लेज़ी लोड हो सकती हैं. इसके अलावा, डिवाइस इस्तेमाल न होने के दौरान उन्हें प्रोसेस भी किया जा सकता है.
हमारे मामले में, हमें बहुत सारे JavaScript बंडल से निपटना पड़ा. हालांकि, हमें इस बात की खुशी है कि JavaScript कम्यूनिटी के पास JavaScript बंडल की ऑडिटिंग करने वाले टूल का एक बेहतरीन सेट है.
हमने webpack बंडल ऐनालाइज़र से शुरुआत की, जिससे हमें पता चला कि हम unicode नाम की एक डिपेंडेंसी शामिल कर रहे थे. यह 1.6 एमबी का पार्स किया गया JavaScript था, इसलिए काफ़ी ज़्यादा था.
इसके बाद, हम अपने एडिटर पर गए और विज़ुअल कोड के लिए इंपोर्ट लागत प्लग इन का इस्तेमाल करके, इंपोर्ट किए जा रहे हर मॉड्यूल की लागत को विज़ुअलाइज़ कर पाए. इससे हमें यह पता चला कि कौनसा कॉम्पोनेंट, इस मॉड्यूल का रेफ़रंस देने वाला कोड शामिल कर रहा था.
इसके बाद, हमने एक अन्य टूल BundlePhobia का इस्तेमाल करना शुरू किया. इस टूल की मदद से, किसी भी NPM पैकेज का नाम डाला जा सकता है. इससे, यह देखा जा सकता है कि इसके छोटा और gzip किए गए साइज़ का अनुमान क्या है. हमें अपने इस्तेमाल किए जा रहे स्लग मॉड्यूल के लिए एक अच्छा विकल्प मिला, जिसका साइज़ सिर्फ़ 2.2 केबी था. इसलिए, हमने उसे बदल दिया.
इससे हमारी परफ़ॉर्मेंस पर काफ़ी असर पड़ा. इस बदलाव और JavaScript बंडल के साइज़ को कम करने के अन्य तरीकों को खोजने के बीच, हमने 2.1 एमबी कोड बचाया.
इन बंडल के ज़िप किए गए और छोटा किए गए साइज़ को ध्यान में रखते हुए, हमें कुल 65% सुधार दिखे. हमें पता चला है कि यह प्रोसेस वाकई में काम की है.
इसलिए, आम तौर पर अपनी साइटों और ऐप्लिकेशन में ग़ैर-ज़रूरी डाउनलोड को हटाने की कोशिश करें. अपनी ऐसेट की इन्वेंट्री बनाएं और उनकी परफ़ॉर्मेंस के असर को मेज़र करें. इससे फ़ैसला हो सकता है. इसलिए, पक्का करें कि नियमित तौर पर ऐसेट का ऑडिट किया जा रहा हो.
कोड को अलग-अलग करने की सुविधा की मदद से, JavaScript के बूट-अप में लगने वाले समय को कम करना
बड़े नेटवर्क पेलोड से हमारे ऐप्लिकेशन पर काफ़ी असर पड़ सकता है. हालांकि, एक और चीज़ से भी काफ़ी असर पड़ सकता है. वह चीज़ है JavaScript.
JavaScript आपकी सबसे महंगी एसेट है. अगर मोबाइल पर, JavaScript के बड़े बंडल भेजे जा रहे हैं, तो हो सकता है कि आपके उपयोगकर्ता आपके यूज़र इंटरफ़ेस के कॉम्पोनेंट के साथ जल्दी इंटरैक्ट न कर पाएं. इसका मतलब है कि उपयोगकर्ता यूज़र इंटरफ़ेस (यूआई) पर टैप कर सकते हैं, लेकिन कोई काम की कार्रवाई नहीं हो रही है. इसलिए, यह समझना ज़रूरी है कि JavaScript की कीमत इतनी ज़्यादा क्यों है.
ब्राउज़र, JavaScript को इसी तरह प्रोसेस करता है.
सबसे पहले हमें वह स्क्रिप्ट डाउनलोड करनी होगी, हमारे पास एक JavaScript इंजन है, जिसे बाद में उस कोड को पार्स करना होगा, जिसे उसे कंपाइल करके लागू करना होगा.
अब इन चरणों में, डेस्कटॉप मशीन या लैपटॉप जैसे बेहतर डिवाइसों पर ज़्यादा समय नहीं लगता. हो सकता है कि बेहतर फ़ोन पर भी ऐसा हो. हालांकि, सामान्य मोबाइल फ़ोन पर इस प्रोसेस में पांच से दस गुना ज़्यादा समय लग सकता है. इस वजह से, इंटरैक्टिविटी में देरी होती है. इसलिए, यह ज़रूरी है कि हम इसे कम करने की कोशिश करें.
अपने ऐप्लिकेशन से जुड़ी इन समस्याओं का पता लगाने में आपकी मदद करने के लिए, हमने लाइटहाउस में नया JavaScript बूट-अप टाइम ऑडिट लॉन्च किया है.
वहीं, Oodle ऐप्लिकेशन के मामले में, हमें पता चला कि JavaScript को बूट-अप होने में 1.8 सेकंड लगे. दरअसल, हम अपने सभी रूट और कॉम्पोनेंट को स्टैटिक तौर पर एक बड़े JavaScript बंडल में इंपोर्ट कर रहे थे.
इससे बचने का एक तरीका है कोड को बांटना.
कोड को अलग-अलग हिस्सों में बांटने का मतलब है कि अपने उपयोगकर्ताओं को पूरे पिज़्ज़ा के बराबर JavaScript देने के बजाय, उन्हें ज़रूरत के हिसाब से एक स्लाइस दिया जाए.
कोड को अलग-अलग करने की सुविधा, रूट लेवल या कॉम्पोनेंट लेवल पर लागू की जा सकती है. यह React और React Loadable, Vue.js, Angular, Polymer, Preact, और कई अन्य लाइब्रेरी के साथ बेहतर तरीके से काम करता है.
हमने अपने ऐप्लिकेशन में कोड स्प्लिटिंग को शामिल किया है. साथ ही, हमने स्टैटिक इंपोर्ट से डाइनैमिक इंपोर्ट पर स्विच किया है. इससे, हमें ज़रूरत के हिसाब से कोड को असिंक्रोनस तौर पर लेज़ी लोड करने की सुविधा मिलती है.
इससे हमारे बंडल का साइज़ कम हो गया. साथ ही, JavaScript को बूट अप होने में लगने वाला समय भी कम हो गया. इससे, ऐप्लिकेशन को खोलने में लगने वाला समय 0.78 सेकंड हो गया. इससे, ऐप्लिकेशन 56% तेज़ हो गया.
आम तौर पर, अगर आपको JavaScript का काफ़ी ज़्यादा इस्तेमाल करने वाला अनुभव देना है, तो सिर्फ़ उस उपयोगकर्ता को कोड भेजें जिसकी उन्हें ज़रूरत है.
कोड को अलग-अलग हिस्सों में बांटने जैसे कॉन्सेप्ट का फ़ायदा लें. साथ ही, ट्री शेकिंग जैसे आइडिया एक्सप्लोर करें. अगर webpack का इस्तेमाल किया जा रहा है, तो अपनी लाइब्रेरी के साइज़ को कम करने के कुछ आइडिया पाने के लिए, webpack-libs-optimizations रिपॉज़िटरी देखें.
चित्र अनुकूलित करें
Oodle ऐप्लिकेशन में, हम बहुत सारी इमेज का इस्तेमाल करते हैं. माफ़ करें, Lighthouse को इस बारे में हमारी तुलना में बहुत कम दिलचस्पी थी. दरअसल, हम इमेज से जुड़े तीनों ऑडिट में सफल नहीं रहे.
हमने अपनी इमेज को ऑप्टिमाइज़ करना भूल गए थे. हमने इमेज का साइज़ सही से नहीं तय किया था. साथ ही, हमें इमेज के दूसरे फ़ॉर्मैट का इस्तेमाल करके भी कुछ फ़ायदा मिल सकता था.
हमने अपनी इमेज को ऑप्टिमाइज़ करने से शुरुआत की थी.
एक बार के ऑप्टिमाइज़ेशन राउंड के लिए, ImageOptim या XNConvert जैसे विज़ुअल टूल का इस्तेमाल किया जा सकता है.
imagemin जैसी लाइब्रेरी की मदद से, अपनी बिल्ड प्रोसेस में इमेज ऑप्टिमाइज़ेशन का चरण जोड़ना, ऑटोमेटेड तरीके से काम करने का एक बेहतर तरीका है.
इस तरह, यह पक्का किया जा सकता है कि आने वाले समय में जोड़ी जाने वाली इमेज अपने-आप ऑप्टिमाइज़ हो जाएं. कुछ सीडीएन, जैसे कि Akamai या तीसरे पक्ष के सलूशन, जैसे कि Cloudinary, Fastly या Uploadcare, आपको इमेज ऑप्टिमाइज़ेशन के बेहतरीन समाधान उपलब्ध कराते हैं. इसलिए, अपनी इमेज को उन सेवाओं पर भी आसानी से होस्ट किया जा सकता है.
अगर लागत या इंतज़ार के समय की समस्याओं की वजह से आपको ऐसा नहीं करना है, तो Thumbor या Imageflow जैसे प्रोजेक्ट, खुद ही होस्ट किए गए विकल्प दे सकते हैं.
हमारे बैकग्राउंड PNG को वेबपैक में बड़ा के तौर पर फ़्लैग किया गया था और यह सही था. व्यूपोर्ट के हिसाब से साइज़ करने और ImageOptim के ज़रिए इसे चलाने के बाद, इसका साइज़ 100 केबी हो गया, जो स्वीकार किया जा सकता है.
अपनी साइट पर मौजूद कई इमेज के लिए ऐसा करने से, हमें पेज के कुल वज़न को काफ़ी कम करने में मदद मिली.
ऐनिमेशन वाले कॉन्टेंट के लिए सही फ़ॉर्मैट का इस्तेमाल करना
GIF फ़ॉर्मैट में वीडियो बनाने की सुविधा का इस्तेमाल करने पर, शुल्क काफ़ी ज़्यादा हो सकता है. हैरानी की बात यह है कि GIF फ़ॉर्मैट को शुरू में ऐनिमेशन प्लैटफ़ॉर्म के तौर पर कभी नहीं बनाया गया था. इसलिए, वीडियो के लिए ज़्यादा सही फ़ॉर्मैट का इस्तेमाल करने पर, फ़ाइल के साइज़ में काफ़ी बचत होती है.
Oodle ऐप्लिकेशन में, हम होम पेज पर इंट्रो सीक्वेंस के तौर पर GIF का इस्तेमाल कर रहे थे. Lighthouse के मुताबिक, बेहतर वीडियो फ़ॉर्मैट का इस्तेमाल करके, हम 7 एमबी से ज़्यादा बचा सकते हैं. हमारी क्लिप का वज़न 7.3 एमबी से ज़्यादा है, जो किसी भी वाजिब वेबसाइट के लिए काफ़ी ज़्यादा है, इसलिए हमने इसे दो सोर्स फ़ाइलों के साथ एक वीडियो एलिमेंट में बदल दिया - एक mp4 और WebM ब्राउज़र को और भी ज़्यादा बड़े आकार में.
हमने अपने ऐनिमेशन GIF को mp4 फ़ाइल में बदलने के लिए, FFmpeg टूल का इस्तेमाल किया. WebM फ़ॉर्मैट में, आपको ज़्यादा बचत मिलती है - ImageOptim API आपके लिए ऐसा कन्वर्ज़न कर सकता है.
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
इस कन्वर्ज़न की बदौलत, हम अपने कुल वज़न का 80% से ज़्यादा बचा पाए. इससे, साइज़ करीब 1 एमबी हो गया.
फिर भी, 1 एमबी का डेटा भेजना, इंटरनेट की स्पीड के हिसाब से ज़्यादा है. खास तौर पर, सीमित बैंडविड्थ वाले उपयोगकर्ता के लिए. अच्छी बात यह है कि हम प्रभावी टाइप एपीआई का इस्तेमाल करके पता लगा सकते हैं कि उनकी बैंडविड्थ धीमी है और उन्हें उसका छोटा 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, इनमें से कुछ सुविधाओं का बेहतर तरीके से इस्तेमाल करने के लिए, हमें कैसे मदद करता है.
लाइटहाउस हमें सबसे पहली बात यह बताता है कि किसी भी जगह जाने के लिए बहुत महंगी दोतरफ़ा यात्रा नहीं करनी चाहिए.
Oodle ऐप्लिकेशन के मामले में, हम Google Fonts का ज़्यादा से ज़्यादा इस्तेमाल कर रहे हैं. जब भी पेज में कोई Google फ़ॉन्ट स्टाइलशीट छोड़ी जाएगी, तो वह दो सबडोमेन से जुड़ जाएगी. Lighthouse हमें बता रहा है कि अगर हम उस कनेक्शन को पहले से चालू कर पाते, तो हमें शुरुआती कनेक्शन के समय में 300 मिलीसेकंड तक की बचत हो सकती थी.
लिंक rel preconnect का फ़ायदा उठाकर, हम कनेक्शन में लगने वाले समय को असरदार तरीके से छिपा सकते हैं.
खास तौर पर, Google Fonts जैसी सेवाओं पर, जहां हमारे फ़ॉन्ट फ़ेस की सीएसएस को googleapis.com पर होस्ट किया जाता है और हमारे फ़ॉन्ट संसाधनों को Gstatic पर होस्ट किया जाता है, इसका काफ़ी असर पड़ सकता है. इसलिए, हमने इस ऑप्टिमाइज़ेशन को लागू किया और कुछ सौ मिलीसेकंड बचाए.
लाइटहाउस का सुझाव यह है कि हम मुख्य अनुरोधों को पहले से लोड करते हैं.
<link rel=preload> बहुत असरदार है. इससे ब्राउज़र को पता चलता है कि मौजूदा नेविगेशन के लिए किसी संसाधन की ज़रूरत है. साथ ही, ब्राउज़र जल्द से जल्द रिसॉर्स को फ़ेच करने की कोशिश करता है.
यहां Lighthouse हमें बता रहा है कि हमें अपने मुख्य वेब फ़ॉन्ट के संसाधनों को प्रीलोड करना चाहिए, क्योंकि हम दो वेब फ़ॉन्ट लोड कर रहे हैं.
वेब फ़ॉन्ट को पहले से लोड करने का तरीका यह है - rel=preload तय करने के लिए, as को फ़ॉन्ट के टाइप के साथ पास करें. इसके बाद, आपको उस फ़ॉन्ट के टाइप की जानकारी देनी होगी जिसे लोड करना है, जैसे कि woff2.
इसका आपके पेज पर गहरा असर पड़ सकता है.
आम तौर पर, अगर वेब फ़ॉन्ट आपके पेज के लिए ज़रूरी हैं, तो आम तौर पर लिंक से लोड होने वाले टेक्स्ट का इस्तेमाल किए बिना, ब्राउज़र को सबसे पहले आपका एचटीएमएल फ़ेच करना होता है. इसके लिए, सबसे पहले आपका सीएसएस पार्स करना होता है और बहुत देर बाद वेब फ़ॉन्ट को फ़ेच करना होता है.
लिंक rel preload का इस्तेमाल करने पर, ब्राउज़र आपके एचटीएमएल को पार्स करने के तुरंत बाद, वेब फ़ॉन्ट को फ़ेच करना शुरू कर सकता है. हमारे ऐप्लिकेशन के मामले में, इससे वेब फ़ॉन्ट का इस्तेमाल करके टेक्स्ट को रेंडर करने में लगने वाले समय में एक सेकंड की बचत हुई.
हालांकि, Google Fonts इस्तेमाल करके फ़ॉन्ट को पहले से लोड करने की कोशिश करने का भी एक आसान तरीका है.
हमारी स्टाइलशीट में फ़ॉन्ट फ़ेस पर बताए गए Google फ़ॉन्ट के यूआरएल, फ़ॉन्ट टीम नियमित तौर पर अपडेट करती है. इन यूआरएल की समयसीमा खत्म हो सकती है या इन्हें नियमित अंतराल पर अपडेट किया जा सकता है. इसलिए, अगर आपको फ़ॉन्ट लोड होने के अनुभव पर पूरा कंट्रोल चाहिए, तो हमारे वेब फ़ॉन्ट खुद होस्ट करें. यह बहुत अच्छा हो सकता है, क्योंकि इससे आपको link rel प्रीलोड जैसी चीज़ों का ऐक्सेस मिलता है.
हमारे मामले में, Google वेब फ़ॉन्ट हेल्पर टूल का इस्तेमाल करके, कुछ वेब फ़ॉन्ट को ऑफ़लाइन डाउनलोड किया जा सकता है और उन्हें स्थानीय तौर पर सेट अप किया जा सकता है. इसलिए, इस टूल को आज़माएं.
भले ही, आपने अपने अहम संसाधनों के तौर पर वेब फ़ॉन्ट का इस्तेमाल किया हो या JavaScript का, ब्राउज़र को अपने अहम संसाधनों को जल्द से जल्द डिलीवर करने में मदद करें.
एक्सपेरिमेंट के तौर पर उपलब्ध: प्राथमिकता के सुझाव
आज हम आपके साथ कुछ खास जानकारी शेयर करना चाहते हैं. हम संसाधन के सुझावों और प्रीलोड जैसी सुविधाओं के साथ-साथ, ब्राउज़र की एक नई सुविधा पर काम कर रहे हैं. इसे हम प्राथमिकता के सुझाव कहते हैं.
यह एक नई सुविधा है. इसकी मदद से, ब्राउज़र को यह बताया जा सकता है कि कोई रिसॉर्स कितना ज़रूरी है. यह एक नया एट्रिब्यूट - अहमियत - दिखाता है. इसकी वैल्यू, कम, ज़्यादा या ऑटो होती हैं.
इससे हमें कम ज़रूरी संसाधनों की प्राथमिकता कम करने में मदद मिलती है. जैसे, ग़ैर-ज़रूरी स्टाइल, इमेज या फ़ेच एपीआई कॉल. इससे, टकराव को कम किया जा सकता है. हम ज़्यादा अहम चीज़ों को प्राथमिकता दे सकते हैं, जैसे कि हीरो इमेज.
हमारे Oodle ऐप्लिकेशन के मामले में, इसकी मदद से हमने एक ऐसी जगह को ऑप्टिमाइज़ किया जहां हमने ऐप्लिकेशन को बेहतर बनाया.
हमने अपनी इमेज में लेज़ी लोडिंग की सुविधा जोड़ने से पहले, ब्राउज़र हमारे सभी डूडल के साथ इमेज कैरसेल दिखाता था. साथ ही, ब्राउज़र कैरसेल की शुरुआत में ही सभी इमेज को प्राथमिकता के साथ फ़ेच करता था. माफ़ करें, कैरसेल के बीच में मौजूद इमेज ही उपयोगकर्ता के लिए सबसे ज़्यादा अहम थीं. इसलिए, हमने बैकग्राउंड इमेज की अहमियत को बहुत कम और फ़ोरग्राउंड इमेज की अहमियत को बहुत ज़्यादा पर सेट किया. इससे, धीमे 3G नेटवर्क पर दो सेकंड का असर पड़ा. साथ ही, हम उन इमेज को तेज़ी से फ़ेच और रेंडर कर पाए. इसलिए, यह एक अच्छा अनुभव रहा.
हमें उम्मीद है कि कुछ ही हफ़्तों में, हम इस सुविधा को कैनरी पर उपलब्ध करा देंगे. इसलिए, इस पर नज़र बनाए रखें.
वेब फ़ॉन्ट लोड करने की रणनीति हो
अच्छे डिज़ाइन के लिए टाइपोग्राफ़ी का होना ज़रूरी है. अगर वेब फ़ॉन्ट का इस्तेमाल किया जा रहा है, तो अपने टेक्स्ट की रेंडरिंग को ब्लॉक नहीं करना चाहिए. साथ ही, आपको अपने टेक्स्ट को अदृश्य नहीं दिखाना चाहिए.
हम अब Lighthouse में इस समस्या को हाइलाइट करते हैं. इसके लिए, वेब फ़ॉन्ट लोड होने के दौरान, न दिखने वाले टेक्स्ट से बचें के ऑडिट का इस्तेमाल किया जाता है.
अगर आपने फ़ॉन्ट फ़ेस ब्लॉक का इस्तेमाल करके अपने वेब फ़ॉन्ट लोड किए हैं, तो ब्राउज़र को यह तय करने का विकल्प दिया जाता है कि अगर उस वेब फ़ॉन्ट को फ़ेच करने में ज़्यादा समय लगता है, तो क्या करना चाहिए. कुछ ब्राउज़र, सिस्टम फ़ॉन्ट पर स्विच करने से पहले, इसके लिए तीन सेकंड तक इंतज़ार करेंगे. फ़ॉन्ट डाउनलोड होने के बाद, वे इसे फ़ॉन्ट के तौर पर इस्तेमाल करेंगे.
हम इस तरह के टेक्स्ट से बचने की कोशिश कर रहे हैं. अगर वेब फ़ॉन्ट को ज़्यादा समय लगता, तो इस मामले में हम इस हफ़्ते के क्लासिक डूडल नहीं देख पाते. अच्छी बात यह है कि 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');
}
फ़ॉन्ट डिसप्ले से यह तय करने में मदद मिलती है कि वेब फ़ॉन्ट कैसे रेंडर होंगे या फ़ॉलबैक करेंगे. यह इस बात पर निर्भर करता है कि उन्हें स्वैप करने में कितना समय लगता है.
इस मामले में, हम फ़ॉन्ट डिसप्ले स्वैप का इस्तेमाल कर रहे हैं. स्वैप करने पर, फ़ॉन्ट फ़ेस को ब्लॉक करने के लिए शून्य सेकंड का समय और स्वैप करने के लिए अनलिमिटेड समय मिलता है. इसका मतलब है कि अगर फ़ॉन्ट को लोड होने में थोड़ा समय लगता है, तो ब्राउज़र आपके टेक्स्ट को तुरंत फ़ॉलबैक फ़ॉन्ट के साथ दिखाएगा. और फ़ॉन्ट फ़ेस उपलब्ध होने पर यह इसे बदल देगा.
हमारे ऐप्लिकेशन के लिए, यह सुविधा बहुत अच्छी थी, क्योंकि इससे हमें ऐप्लिकेशन के लॉन्च से पहले ही कुछ अहम टेक्स्ट दिखाने में मदद मिली. साथ ही, वेब फ़ॉन्ट तैयार होने के बाद, उसे ट्रांज़िशन करने में भी मदद मिली.
आम तौर पर, अगर वेब फ़ॉन्ट का इस्तेमाल किया जा रहा है, तो वेब फ़ॉन्ट लोड करने की अच्छी रणनीति अपनाएं. ऐसा ज़्यादातर वेब साइटें करती हैं.
फ़ॉन्ट लोड होने के अनुभव को ऑप्टिमाइज़ करने के लिए, वेब प्लैटफ़ॉर्म की कई सुविधाओं का इस्तेमाल किया जा सकता है. हालांकि, Zach Leatherman का Web Font Recipes repo भी देखें, क्योंकि यह बहुत बढ़िया है.
विज्ञापन दिखाने से रोकने वाली स्क्रिप्ट कम करें
हमारे ऐप्लिकेशन के कुछ ऐसे हिस्से हैं जिन्हें डाउनलोड चेन में पहले से शामिल किया जा सकता है, ताकि उपयोगकर्ताओं को कम से कम कुछ बुनियादी अनुभव पहले ही मिल सके.
Lighthouse की टाइमलाइन स्ट्रिप पर, यह देखा जा सकता है कि शुरुआती कुछ सेकंड के दौरान, जब सभी संसाधन लोड हो रहे होते हैं, तब उपयोगकर्ता को कोई कॉन्टेंट नहीं दिखता.
बाहरी स्टाइलशीट डाउनलोड और प्रोसेस करने की वजह से, रेंडर करने की प्रोसेस आगे नहीं बढ़ पा रही है.
हम कुछ स्टाइल को थोड़ा पहले डिलीवर करके, रेंडरिंग के अपने अहम पाथ को ऑप्टिमाइज़ करने की कोशिश कर सकते हैं.
अगर हम इस शुरुआती रेंडर के लिए ज़रूरी स्टाइल को निकालकर, उन्हें अपने एचटीएमएल में इनलाइन करते हैं, तो ब्राउज़र उन्हें तुरंत रेंडर कर सकता है. इसके लिए, उसे बाहरी स्टाइलशीट के आने का इंतज़ार नहीं करना पड़ता.
हमारे मामले में, हमने बिल्ड के दौरान index.html में अपने अहम कॉन्टेंट को इनलाइन करने के लिए, Critical नाम के NPM मॉड्यूल का इस्तेमाल किया.
इस मॉड्यूल ने हमारे लिए ज़्यादातर काम किया, लेकिन इसे अलग-अलग रूट पर आसानी से काम कराने में थोड़ी मुश्किल हुई.
अगर आपने शुरू से ही ऐप्लिकेशन शेल के आर्किटेक्चर के लिए प्लान नहीं बनाया है, तो इस तरह के पैटर्न को लागू करना मुश्किल हो सकता है. ऐसा तब हो सकता है, जब आपने सावधानी न बरती हो या आपकी साइट का स्ट्रक्चर बहुत जटिल हो.
इसलिए, शुरुआत में ही परफ़ॉर्मेंस से जुड़ी बातों का ध्यान रखना ज़रूरी है. अगर आपने शुरू से ही परफ़ॉर्मेंस के लिए डिज़ाइन नहीं किया है, तो हो सकता है कि आपको बाद में समस्याएं आएं.
आखिर में, हमें इसका फ़ायदा मिला. हमने इसे काम कराने में कामयाबी हासिल की और ऐप्लिकेशन ने कॉन्टेंट को बहुत पहले डिलीवर करना शुरू कर दिया. इससे, फ़र्स्ट मीनिंगफ़ुल पेंट में काफ़ी सुधार हुआ.
नतीजा
यह हमारी साइट पर लागू किए गए परफ़ॉर्मेंस ऑप्टिमाइज़ेशन की एक लंबी सूची थी. आइए, नतीजे पर एक नज़र डालते हैं. ऑप्टिमाइज़ेशन से पहले और बाद में, 3G नेटवर्क पर मौजूद एक मध्यम मोबाइल डिवाइस पर हमारा ऐप्लिकेशन इस तरह लोड हुआ.
Lighthouse परफ़ॉर्मेंस स्कोर 23 से बढ़कर 91 हो गया. स्पीड के मामले में यह काफ़ी अच्छी प्रोग्रेस है. हमने Lighthouse की रिपोर्ट को लगातार देखते रहे और उसमें बताए गए सुझावों को लागू किया. अगर आपको जानना है कि हमने सभी सुधारों को तकनीकी तौर पर किस तरह लागू किया है, तो हमारे रेपो पर जाएं. खास तौर पर, इस प्लैटफ़ॉर्म पर हुए पीआर से जुड़े दस्तावेज़.
परफ़ॉर्मेंस का अनुमान - डेटा के आधार पर उपयोगकर्ता अनुभव
हमारा मानना है कि मशीन लर्निंग की मदद से, आने वाले समय में कई क्षेत्रों में बेहतर काम किए जा सकते हैं. हमें उम्मीद है कि आने वाले समय में, हम इसी तरह के और प्रयोग करेंगे. हमारा सुझाव है कि असल डेटा से लोगों को बेहतर अनुभव मिलने में मदद मिलेगी.
फ़िलहाल, हम उपयोगकर्ता की ज़रूरतों के हिसाब से कई फ़ैसले लेते हैं. जैसे, उपयोगकर्ता को क्या चाहिए या उसकी क्या ज़रूरत है. इसलिए, हम यह तय करते हैं कि कौनसी जानकारी को पहले से फ़ेच, लोड या कैश मेमोरी में सेव किया जाए. अगर हमारा अनुमान सही होता है, तो हम कुछ संसाधनों को प्राथमिकता दे पाते हैं. हालांकि, पूरी वेबसाइट के लिए ऐसा करना काफ़ी मुश्किल है.
हमारे पास आज भी डेटा उपलब्ध है, ताकि हम अपने ऑप्टिमाइज़ेशन को बेहतर तरीके से बता सकें. Google Analytics Reporting API का इस्तेमाल करके, हम अपनी साइट पर सबसे ज़्यादा देखे गए अगले पेज और किसी भी यूआरएल के लिए, साइट छोड़ने वाले लोगों के प्रतिशत को देख सकते हैं. इससे, हमें यह तय करने में मदद मिलती है कि किन संसाधनों को प्राथमिकता दी जानी चाहिए.
अगर हम इसे एक अच्छे प्रॉबबिलिटी मॉडल के साथ जोड़ते हैं, तो हम बहुत ज़्यादा प्रीफ़ेच करने वाले कॉन्टेंट को जोड़कर अपने उपयोगकर्ताओं का डेटा बर्बाद होने से रोकते हैं. हम Google Analytics के इस डेटा का फ़ायदा ले सकते हैं. साथ ही, इन मॉडल को लागू करने के लिए, मशीन लर्निंग और मार्कोव चेन या न्यूरल नेटवर्क जैसे मॉडल का इस्तेमाल कर सकते हैं.
इन प्रयोगों को आसान बनाने के लिए, हमें एक नई पहल का एलान करते हुए खुशी हो रही है. इसे हम Guess.js कह रहे हैं.
Guess.js एक ऐसा प्रोजेक्ट है जो वेब के लिए, डेटा-ड्रिवन उपयोगकर्ता अनुभव पर फ़ोकस करता है. हमें उम्मीद है कि इससे, वेब की परफ़ॉर्मेंस को बेहतर बनाने के लिए डेटा का इस्तेमाल करने के बारे में जानकारी मिलेगी. यह पूरी तरह से ओपन सोर्स है और फ़िलहाल GitHub पर उपलब्ध है. इसे ओपन सोर्स कम्यूनिटी के साथ मिलकर बनाया गया था. इसमें Minko Gechev, Gatsby के Kyle Matthews, Katie Hempenius, और कई अन्य लोगों की मदद ली गई थी.
Guess.js को आज़माएं और हमें बताएं कि आपको यह कैसा लगा.
खास जानकारी
स्कोर और मेट्रिक, वेब की स्पीड को बेहतर बनाने में मददगार होते हैं. हालांकि, ये सिर्फ़ एक तरीका हैं, न कि लक्ष्य.
हम सभी ने कभी न कभी, किसी पेज को लोड होने में लगने वाले समय को महसूस किया है. हालांकि, अब हमारे पास अपने उपयोगकर्ताओं को बेहतर अनुभव देने का मौका है.
प्रदर्शन में सुधार करना एक यात्रा है. कई छोटे बदलावों से, आपको ज़्यादा फ़ायदे मिल सकते हैं. सही ऑप्टिमाइज़ेशन टूल का इस्तेमाल करके और लाइटहाउस रिपोर्ट पर नज़र रखकर, उपयोगकर्ताओं को बेहतर अनुभव दिया जा सकता है.
इसके लिए खास तौर पर धन्यवाद: वार्ड पीटर्स, मिंको गेचेव, कायल मैथ्यूज़, केटी हेम्पेनियस, डॉम फ़ैरोलिनो, योव वाइस, सूसी लू, युसुके उत्सुनोमिया, टॉम अंकर्स, लाइटहाउस, और Google डूडल.