Google IO 2018 में, हमने टूल, लाइब्रेरी, और ऑप्टिमाइज़ेशन की तकनीकों का एक राउंडअप पेश किया था. इनसे वेब की परफ़ॉर्मेंस को बेहतर बनाना आसान हो जाता है. यहां हम Oodles Theater ऐप्लिकेशन का इस्तेमाल करके, इनके बारे में बताते हैं. हम अनुमानित लोडिंग और नई Guess.js पहल के साथ किए गए अपने प्रयोगों के बारे में भी बात करते हैं.
पिछले साल, हम यह पता लगाने में काफ़ी व्यस्त रहे कि वेब को ज़्यादा तेज़ और बेहतर परफ़ॉर्म करने वाला कैसे बनाया जाए. इस वजह से, नए टूल, तरीके, और लाइब्रेरी बनाई गईं. हम इस लेख में, इनके बारे में आपको बताना चाहते हैं. पहले हिस्से में, हम आपको ऑप्टिमाइज़ेशन की कुछ ऐसी तकनीकें दिखाएंगे जिनका इस्तेमाल हमने The Oodles Theater ऐप्लिकेशन को डेवलप करते समय किया था. दूसरे हिस्से में, हम प्रेडिक्टिव लोडिंग और नई Guess.js पहल के साथ किए गए अपने प्रयोगों के बारे में बात करेंगे.
परफ़ॉर्मेंस की ज़रूरत
इंटरनेट पर हर साल डेटा का साइज़ बढ़ता जा रहा है. अगर हम वेब की स्थिति देखें, तो हमें पता चलता है कि मोबाइल पर किसी पेज का साइज़ औसतन 1.5 एमबी होता है. इसमें ज़्यादातर JavaScript और इमेज होती हैं.
वेबसाइटों का बढ़ता साइज़ और अन्य फ़ैक्टर, जैसे कि नेटवर्क लेटेंसी, सीपीयू की सीमाएं, रेंडर-ब्लॉकिंग पैटर्न या तीसरे पक्ष का ग़ैर-ज़रूरी कोड, परफ़ॉर्मेंस को बेहतर बनाने में रुकावट डालते हैं.
ज़्यादातर उपयोगकर्ता, स्पीड को उपयोगकर्ता अनुभव की हैरारकी में सबसे ऊपर रखते हैं. यह कोई हैरानी की बात नहीं है, क्योंकि पेज के पूरी तरह लोड होने तक, ज़्यादा कुछ नहीं किया जा सकता. आप पेज से वैल्यू नहीं निकाल सकते, आप इसकी खूबसूरती की तारीफ़ नहीं कर सकते.
हम जानते हैं कि उपयोगकर्ताओं के लिए परफ़ॉर्मेंस मायने रखती है. हालांकि, ऑप्टिमाइज़ेशन की शुरुआत कहां से करनी है, यह पता लगाना एक रहस्य की तरह लग सकता है. अच्छी बात यह है कि ऐसे टूल मौजूद हैं जो इस काम में आपकी मदद कर सकते हैं.
Lighthouse - परफ़ॉर्मेंस वर्कफ़्लो के लिए एक बुनियादी टूल
Lighthouse, Chrome DevTools का हिस्सा है. इसकी मदद से, अपनी वेबसाइट का ऑडिट किया जा सकता है. साथ ही, इसे बेहतर बनाने के बारे में सुझाव भी मिलते हैं.
हमने हाल ही में कई नई परफ़ॉर्मेंस ऑडिट लॉन्च की हैं. ये रोज़ के डेवलपमेंट वर्कफ़्लो में काफ़ी काम आती हैं.
आइए, एक उदाहरण की मदद से जानते हैं कि इनका फ़ायदा कैसे लिया जा सकता है: Oodles Theater ऐप्लिकेशन. यह एक छोटा सा डेमो वेब ऐप्लिकेशन है, जहां हमारे कुछ पसंदीदा इंटरैक्टिव Google डूडल आज़माए जा सकते हैं. साथ ही, एक या दो गेम भी खेले जा सकते हैं.
ऐप्लिकेशन बनाते समय, हम यह पक्का करना चाहते थे कि यह ज़्यादा से ज़्यादा बेहतर तरीके से काम करे. ऑप्टिमाइज़ेशन की शुरुआत, Lighthouse रिपोर्ट से हुई.
Lighthouse रिपोर्ट के मुताबिक, हमारे ऐप्लिकेशन की शुरुआती परफ़ॉर्मेंस काफ़ी खराब थी. 3G नेटवर्क पर, उपयोगकर्ता को फ़र्स्ट मीनिंगफ़ुल पेंट या ऐप्लिकेशन के इंटरैक्टिव होने के लिए, 15 सेकंड तक इंतज़ार करना पड़ता था. Lighthouse ने हमारी साइट की कई समस्याओं को हाइलाइट किया. साथ ही, साइट की परफ़ॉर्मेंस का कुल स्कोर 23 था, जो कि इन समस्याओं की वजह से ही था.
पेज का साइज़ करीब 3.4 एमबी था - हमें इसे कम करने की बहुत ज़रूरत थी.
इससे हमें परफ़ॉर्मेंस से जुड़ी पहली चुनौती मिली: ऐसी चीज़ें ढूंढना जिन्हें हम उपयोगकर्ता अनुभव पर असर डाले बिना आसानी से हटा सकें.
परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के अवसर
ग़ैर-ज़रूरी रिसॉर्स हटाना
कुछ ऐसी चीज़ें हैं जिन्हें सुरक्षित तरीके से हटाया जा सकता है: खाली जगह और टिप्पणियां.
Lighthouse, अनमिनिफ़ाइड सीएसएस और JavaScript ऑडिट में इस अवसर को हाइलाइट करता है. हम अपनी बिल्ड प्रोसेस के लिए webpack का इस्तेमाल कर रहे थे. इसलिए, काट-छांट करने के लिए हमने Uglify JS प्लगिन का इस्तेमाल किया.
काट-छांट करना एक सामान्य टास्क है. इसलिए, आपको अपनी बिल्ड प्रोसेस के लिए, पहले से तैयार समाधान मिल सकता है.
इस स्पेस में एक और काम का ऑडिट, टेक्स्ट कंप्रेस करने की सुविधा चालू करें है. बिना कंप्रेस की गई फ़ाइलें भेजने की कोई वजह नहीं है. साथ ही, ज़्यादातर सीडीएन में आजकल यह सुविधा पहले से मौजूद होती है.
हम अपने कोड को होस्ट करने के लिए Firebase होस्टिंग का इस्तेमाल कर रहे थे. Firebase, डिफ़ॉल्ट रूप से gzipping की सुविधा देता है. इसलिए, अपने कोड को एक सही सीडीएन पर होस्ट करने की वजह से, हमें यह सुविधा बिना किसी शुल्क के मिली.
gzip, कंप्रेस करने का एक बहुत ही लोकप्रिय तरीका है. हालांकि, Zopfli और Brotli जैसे अन्य तरीके भी लोकप्रिय हो रहे हैं. Brotli का इस्तेमाल ज़्यादातर ब्राउज़र में किया जा सकता है. साथ ही, अपनी ऐसेट को सर्वर पर भेजने से पहले, उन्हें कंप्रेस करने के लिए बाइनरी का इस्तेमाल किया जा सकता है.
कैश मेमोरी से जुड़ी बेहतर नीतियों का इस्तेमाल करें
हमारा अगला कदम यह पक्का करना था कि हम ज़रूरत न होने पर, संसाधनों को दो बार न भेजें.
Lighthouse में कैश मेमोरी की खराब नीति की जांच से हमें यह पता चला कि हम कैश मेमोरी की रणनीतियों को ऑप्टिमाइज़ कर सकते हैं, ताकि हम ठीक यही हासिल कर सकें. अपने सर्वर में max-age एक्सपायरेशन हेडर सेट करके, हमने यह पक्का किया कि बार-बार आने वाले उपयोगकर्ता, पहले से डाउनलोड किए गए रिसॉर्स का फिर से इस्तेमाल कर सकें.
आम तौर पर, आपको ज़्यादा से ज़्यादा संसाधनों को लंबे समय तक सुरक्षित तरीके से कैश मेमोरी में सेव करने का लक्ष्य रखना चाहिए. साथ ही, अपडेट किए गए संसाधनों की फिर से पुष्टि करने के लिए, पुष्टि करने वाले टोकन उपलब्ध कराने चाहिए.
इस्तेमाल न होने वाले कोड हटा दें
अब तक हमने ग़ैर-ज़रूरी डाउनलोड के उन हिस्सों को हटाया है जो साफ़ तौर पर दिख रहे थे. हालांकि, उन हिस्सों का क्या जो साफ़ तौर पर नहीं दिख रहे हैं? उदाहरण के लिए, इस्तेमाल न होने वाला कोड.
कभी-कभी हम अपने ऐप्लिकेशन में ऐसा कोड शामिल कर देते हैं जिसकी ज़रूरत नहीं होती. ऐसा खास तौर पर तब होता है, जब आपने अपने ऐप्लिकेशन पर लंबे समय तक काम किया हो, आपकी टीम या डिपेंडेंसी बदल गई हों, और कभी-कभी कोई ऐसी लाइब्रेरी छूट गई हो जिसका इस्तेमाल न किया जा रहा हो. हमारे साथ भी ऐसा ही हुआ.
शुरुआत में, हमने अपने ऐप्लिकेशन का प्रोटोटाइप जल्दी बनाने के लिए, मटीरियल कॉम्पोनेंट लाइब्रेरी का इस्तेमाल किया. समय के साथ, हमने ऐप्लिकेशन को ज़्यादा कस्टम लुक और स्टाइल दिया और उस लाइब्रेरी के बारे में पूरी तरह से भूल गए. खुशकिस्मती से, कोड कवरेज की जांच से हमें अपने बंडल में इसे फिर से ढूंढने में मदद मिली.
DevTools में, कोड कवरेज के आंकड़े देखे जा सकते हैं. ये आंकड़े, आपके ऐप्लिकेशन के रनटाइम और लोड टाइम, दोनों के लिए देखे जा सकते हैं. नीचे दिए गए स्क्रीनशॉट में, आपको दो बड़ी लाल पट्टियां दिख रही होंगी. इनमें से एक पट्टी से पता चलता है कि हमारी सीएसएस का 95% से ज़्यादा हिस्सा इस्तेमाल नहीं किया गया था. वहीं, दूसरी पट्टी से पता चलता है कि JavaScript का भी एक बड़ा हिस्सा इस्तेमाल नहीं किया गया था.
Lighthouse ने इस्तेमाल न किए गए सीएसएस नियमों के ऑडिट में भी इस समस्या का पता लगाया. इससे पता चला कि 400 केबी से ज़्यादा डेटा बचाया जा सकता है. इसलिए, हमने अपने कोड में बदलाव किया और उस लाइब्रेरी से JavaScript और सीएसएस, दोनों को हटा दिया.
इससे हमारा सीएसएस बंडल 20 गुना कम हो गया. यह दो लाइन के छोटे से कमिट के लिए काफ़ी अच्छा है.
इससे हमारी परफ़ॉर्मेंस का स्कोर बढ़ा और टाइम टू इंटरैक्टिव भी बेहतर हुआ.
हालांकि, इस तरह के बदलावों के साथ, सिर्फ़ मेट्रिक और स्कोर की जांच करना काफ़ी नहीं है. असल कोड को हटाने में हमेशा जोखिम होता है. इसलिए, आपको हमेशा संभावित रिग्रेशन पर नज़र रखनी चाहिए.
हमारा 95% कोड इस्तेमाल नहीं किया गया था. हालांकि, 5% कोड अब भी कहीं मौजूद है. ऐसा लगता है कि हमारा एक कॉम्पोनेंट अब भी उस लाइब्रेरी की स्टाइल का इस्तेमाल कर रहा था. यह कॉम्पोनेंट, डूडल स्लाइडर में मौजूद छोटे ऐरो थे. हालांकि, यह बहुत छोटा था, इसलिए हम उन स्टाइल को मैन्युअल तरीके से बटन में वापस शामिल कर सकते थे.
इसलिए, अगर कोड हटाया जाता है, तो पक्का करें कि आपके पास टेस्टिंग का सही वर्कफ़्लो हो, ताकि आपको विज़ुअल रिग्रेशन से बचने में मदद मिल सके.
बहुत ज़्यादा नेटवर्क पेलोड से बचें
हम जानते हैं कि बड़े रिसॉर्स की वजह से, वेब पेज लोड होने में ज़्यादा समय लग सकता है. इनकी वजह से, हमारे उपयोगकर्ताओं को पैसे खर्च करने पड़ सकते हैं. साथ ही, उनके डेटा प्लान पर भी इसका काफ़ी असर पड़ सकता है. इसलिए, इस बात का ध्यान रखना बहुत ज़रूरी है.
Lighthouse ने बहुत ज़्यादा नेटवर्क पेलोड ऑडिट का इस्तेमाल करके, यह पता लगाया कि हमारे कुछ नेटवर्क पेलोड में समस्या थी.
हमने देखा कि हमारे पास 3 एमबी से ज़्यादा का कोड था, जो शिप किया जा रहा था. यह काफ़ी ज़्यादा है, खास तौर पर मोबाइल पर.
इस सूची में सबसे ऊपर, Lighthouse ने हाइलाइट किया कि हमारे पास JavaScript वेंडर बंडल है, जिसमें 2 एमबी का अनकंप्रेस्ड कोड है. webpack ने भी इस समस्या को हाइलाइट किया है.
जैसा कि कहा जाता है: सबसे तेज़ अनुरोध वह होता है जो किया ही नहीं जाता.
आपको अपने उपयोगकर्ताओं को दी जाने वाली हर ऐसेट की वैल्यू को मेज़र करना चाहिए. साथ ही, उन ऐसेट की परफ़ॉर्मेंस को मेज़र करना चाहिए और यह तय करना चाहिए कि क्या उन्हें शुरुआती अनुभव के साथ शिप करना सही है. ऐसा इसलिए, क्योंकि कभी-कभी इन ऐसेट को डेफ़र किया जा सकता है या लेज़ी लोडिंग की जा सकती है या इन्हें आइडल टाइम के दौरान प्रोसेस किया जा सकता है.
हमारे मामले में, हम कई JavaScript बंडल के साथ काम कर रहे हैं. इसलिए, हम खुशकिस्मत थे, क्योंकि JavaScript कम्यूनिटी के पास JavaScript बंडल की जांच करने वाले टूल का एक बेहतरीन सेट है.
हमने webpack bundle analyzer से शुरुआत की. इससे हमें पता चला कि हम unicode नाम की एक डिपेंडेंसी शामिल कर रहे थे. यह 1.6 एमबी की पार्स की गई JavaScript थी, जो कि काफ़ी ज़्यादा थी.
इसके बाद, हम अपने एडिटर पर गए और विज़ुअल कोड के लिए इंपोर्ट कॉस्ट प्लगिन का इस्तेमाल करके, हम इंपोर्ट किए जा रहे हर मॉड्यूल की लागत को देख पाए. इससे हमें यह पता लगाने में मदद मिली कि किस कॉम्पोनेंट में ऐसा कोड शामिल था जो इस मॉड्यूल को रेफ़र कर रहा था.
इसके बाद, हमने दूसरे टूल BundlePhobia का इस्तेमाल किया. यह एक टूल है, जिसकी मदद से किसी भी एनपीएम पैकेज का नाम डाला जा सकता है. साथ ही, यह देखा जा सकता है कि उसके minified और gzipped साइज़ का अनुमान क्या है. हमें स्लग मॉड्यूल का एक अच्छा विकल्प मिला, जिसका साइज़ सिर्फ़ 2.2 केबी था. इसलिए, हमने उसे बदल दिया.
इससे हमारी परफ़ॉर्मेंस पर काफ़ी असर पड़ा. इस बदलाव और JavaScript बंडल के साइज़ को कम करने के अन्य तरीकों को आज़माने के बाद, हमने 2.1 एमबी कोड सेव किया.
इन बंडल के gzip और minified साइज़ को ध्यान में रखने पर, हमें कुल मिलाकर 65% सुधार देखने को मिला. हमें लगा कि इस प्रोसेस को अपनाना वाकई फ़ायदेमंद है.
इसलिए, आम तौर पर अपनी साइटों और ऐप्लिकेशन से ग़ैर-ज़रूरी डाउनलोड हटाएं. अपनी ऐसेट की इन्वेंट्री बनाएं और परफ़ॉर्मेंस पर उनके असर को मेज़र करें. इससे काफ़ी फ़ायदा मिल सकता है. इसलिए, पक्का करें कि अपनी ऐसेट का ऑडिट नियमित तौर पर किया जा रहा हो.
कोड स्प्लिटिंग की मदद से, JavaScript के बूट-अप होने में लगने वाले समय को कम करना
हालांकि, बड़े नेटवर्क पेलोड का हमारे ऐप्लिकेशन पर काफ़ी असर पड़ सकता है. इसके अलावा, एक और चीज़ है जिसका काफ़ी असर पड़ सकता है. वह है JavaScript.
JavaScript आपकी सबसे महंगी ऐसेट है. मोबाइल पर, अगर JavaScript के बड़े बंडल भेजे जा रहे हैं, तो इससे आपके उपयोगकर्ताओं को यूज़र इंटरफ़ेस के कॉम्पोनेंट के साथ इंटरैक्ट करने में देरी हो सकती है. इसका मतलब है कि वे यूज़र इंटरफ़ेस (यूआई) पर टैप कर सकते हैं, लेकिन इससे कुछ नहीं होगा. इसलिए, हमारे लिए यह समझना ज़रूरी है कि JavaScript की वजह से इतना समय क्यों लगता है.
ब्राउज़र, JavaScript को इसी तरह प्रोसेस करता है.
सबसे पहले, हमें उस स्क्रिप्ट को डाउनलोड करना होगा. हमारे पास एक JavaScript इंजन है, जिसे उस कोड को पार्स करना होगा. साथ ही, उसे कंपाइल और एक्ज़ीक्यूट करना होगा.
डेस्कटॉप मशीन, लैपटॉप या महंगे फ़ोन जैसे हाई-एंड डिवाइस पर, इन चरणों को पूरा होने में ज़्यादा समय नहीं लगता. हालांकि, एक सामान्य मोबाइल फ़ोन पर इस प्रोसेस में पांच से दस गुना ज़्यादा समय लग सकता है. इसकी वजह से, इंटरैक्टिविटी में देरी होती है. इसलिए, हमारे लिए यह ज़रूरी है कि हम इसे कम करने की कोशिश करें.
अपने ऐप्लिकेशन में इन समस्याओं का पता लगाने में आपकी मदद करने के लिए, हमने Lighthouse में एक नया 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 जैसे प्रोजेक्ट, खुद होस्ट किए जाने वाले विकल्प उपलब्ध कराते हैं.
Webpack में हमारी बैकग्राउंड 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 एमबी का रिसॉर्स डाउनलोड करना एक बड़ी बात है. खास तौर पर, उस उपयोगकर्ता के लिए जिसके पास सीमित बैंडविड्थ है. खुशकिस्मती से, हम Effective Type API का इस्तेमाल करके यह पता लगा सकते हैं कि वे कम बैंडविड्थ पर हैं. इसके बाद, उन्हें बहुत छोटा JPEG दे सकते हैं.
यह इंटरफ़ेस, दोतरफ़ा यात्रा के समय और डाउनलोड करने की वैल्यू का इस्तेमाल करके, उपयोगकर्ता के नेटवर्क टाइप का अनुमान लगाता है. यह सिर्फ़ एक स्ट्रिंग दिखाता है, जैसे कि slow 2G, 2G, 3G या 4G. इस वैल्यू के आधार पर, अगर उपयोगकर्ता 4G से कम स्पीड वाले नेटवर्क का इस्तेमाल कर रहा है, तो हम वीडियो एलिमेंट को इमेज से बदल सकते हैं.
if (navigator.connection.effectiveType) { ... }
इससे साइट का अनुभव थोड़ा कम हो जाता है. हालांकि, साइट को धीमे कनेक्शन पर भी इस्तेमाल किया जा सकता है.
ऑफ़-स्क्रीन इमेज की लेज़ी-लोडिंग
कैरसेल, स्लाइडर या बहुत लंबे पेज अक्सर इमेज लोड करते हैं. भले ही, उपयोगकर्ता उन्हें पेज पर तुरंत न देख पाए.
लाइटहाउस, ऑफ़-स्क्रीन इमेज ऑडिट में इस व्यवहार को फ़्लैग करेगा. इसे DevTools के नेटवर्क पैनल में भी देखा जा सकता है. अगर आपको पेज पर बहुत सारी इमेज दिख रही हैं, लेकिन उनमें से कुछ ही इमेज दिख रही हैं, तो इसका मतलब है कि आपको उन्हें लेज़ी लोड करने के बारे में सोचना चाहिए.
लेज़ी लोडिंग की सुविधा, ब्राउज़र में नेटिव तौर पर काम नहीं करती. इसलिए, हमें इस सुविधा को जोड़ने के लिए JavaScript का इस्तेमाल करना होगा. हमने Lazysizes लाइब्रेरी का इस्तेमाल करके, Oodle कवर में लेज़ी लोडिंग की सुविधा जोड़ी.
<!-- 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"/>
Lazysizes एक स्मार्ट लाइब्रेरी है, क्योंकि यह न सिर्फ़ एलिमेंट की विज़िबिलिटी में होने वाले बदलावों को ट्रैक करती है, बल्कि उपयोगकर्ता को बेहतर अनुभव देने के लिए, व्यू के आस-पास मौजूद एलिमेंट को भी पहले से फ़ेच करती है.
यह IntersectionObserver के साथ इंटिग्रेशन का विकल्प भी देता है. इससे आपको विज़िबिलिटी लुकअप की बेहतर सुविधा मिलती है.
इस बदलाव के बाद, हमारी इमेज मांग पर फ़ेच की जा रही हैं. अगर आपको इस विषय के बारे में ज़्यादा जानना है, तो images.guide देखें. यह एक बहुत ही आसान और काम का संसाधन है.
ब्राउज़र को ज़रूरी रिसॉर्स जल्दी डिलीवर करने में मदद करना
ब्राउज़र को भेजे जाने वाले हर बाइट की अहमियत एक जैसी नहीं होती. ब्राउज़र को इस बात की जानकारी होती है. कई ब्राउज़र में ह्यूरिस्टिक होते हैं. इनसे यह तय किया जाता है कि उन्हें सबसे पहले क्या फ़ेच करना चाहिए. इसलिए, कभी-कभी वे इमेज या स्क्रिप्ट से पहले सीएसएस फ़ेच करते हैं.
पेज के लेखक के तौर पर, ब्राउज़र को यह बताना कि हमारे लिए असल में क्या ज़रूरी है, मददगार हो सकता है. खुशी की बात है कि पिछले कुछ सालों में, ब्राउज़र वेंडर ने इस काम में हमारी मदद करने के लिए कई सुविधाएं जोड़ी हैं. जैसे, संसाधन के संकेत, जैसे कि link rel=preconnect, preload या prefetch.
वेब प्लैटफ़ॉर्म पर उपलब्ध ये सुविधाएं, ब्राउज़र को सही समय पर सही चीज़ फ़ेच करने में मदद करती हैं. साथ ही, ये स्क्रिप्ट का इस्तेमाल करके किए जाने वाले कुछ कस्टम लोडिंग और लॉजिक पर आधारित तरीकों की तुलना में ज़्यादा असरदार हो सकती हैं.
आइए, देखते हैं कि Lighthouse हमें इनमें से कुछ सुविधाओं को असरदार तरीके से इस्तेमाल करने के लिए, किस तरह गाइड करता है.
Lighthouse हमें सबसे पहले यह बताता है कि किसी भी ऑरिजिन के लिए, बार-बार और महंगे दोतरफ़ा यात्रा से बचना चाहिए.
Oodle ऐप्लिकेशन के मामले में, हम Google Fonts का काफ़ी ज़्यादा इस्तेमाल कर रहे हैं. जब भी अपने पेज पर Google Fonts की स्टाइलशीट जोड़ी जाती है, तो वह ज़्यादा से ज़्यादा दो सबडोमेन से कनेक्ट होती है. Lighthouse हमें बता रहा है कि अगर हम उस कनेक्शन को वॉर्म अप कर सकें, तो हम शुरुआती कनेक्शन के समय में 300 मिलीसेकंड तक बचा सकते हैं.
लिंक rel प्रीकनेक्ट का फ़ायदा उठाकर, हम कनेक्शन की इंतज़ार की अवधि को असरदार तरीके से मास्क कर सकते हैं.
खास तौर पर, Google Fonts जैसी सेवा के लिए, जहां हमारे फ़ॉन्ट फ़ेस की सीएसएस googleapis.com पर होस्ट की जाती है और हमारे फ़ॉन्ट रिसॉर्स Gstatic पर होस्ट किए जाते हैं, इसका काफ़ी असर पड़ सकता है. इसलिए, हमने इस ऑप्टिमाइज़ेशन को लागू किया और कुछ सौ मिलीसेकंड कम कर दिए.
Lighthouse का अगला सुझाव है कि हम मुख्य अनुरोधों को पहले से लोड करें.
<link rel=preload> बहुत असरदार है. यह ब्राउज़र को बताता है कि मौजूदा नेविगेशन के लिए, किसी रिसॉर्स की ज़रूरत है. साथ ही, यह ब्राउज़र को जल्द से जल्द उस रिसॉर्स को फ़ेच करने के लिए कहता है.
यहां Lighthouse हमें बता रहा है कि हमें अपने मुख्य वेब फ़ॉन्ट रिसॉर्स को पहले से लोड करना चाहिए. ऐसा इसलिए, क्योंकि हम दो वेब फ़ॉन्ट लोड कर रहे हैं.
वेब फ़ॉन्ट में पहले से लोड करना कुछ इस तरह दिखता है - rel=preload तय करके, फ़ॉन्ट के टाइप के साथ as को पास किया जाता है. इसके बाद, उस फ़ॉन्ट का टाइप तय किया जाता है जिसे लोड करने की कोशिश की जा रही है, जैसे कि woff2.
इससे आपके पेज पर काफ़ी असर पड़ सकता है.
आम तौर पर, अगर वेब फ़ॉन्ट आपके पेज के लिए ज़रूरी हैं, तो link rel preload का इस्तेमाल किए बिना, ब्राउज़र को सबसे पहले आपका एचटीएमएल फ़ेच करना होगा. इसके बाद, उसे आपकी सीएसएस को पार्स करना होगा. इसके बाद, वह आपके वेब फ़ॉन्ट को फ़ेच करेगा.
लिंक rel प्रीलोड का इस्तेमाल करके, जैसे ही ब्राउज़र आपके एचटीएमएल को पार्स करता है, वह उन वेब फ़ॉन्ट को बहुत पहले ही फ़ेच करना शुरू कर सकता है. हमारे ऐप्लिकेशन के मामले में, इससे हमें अपने वेब फ़ॉन्ट का इस्तेमाल करके टेक्स्ट को रेंडर करने में लगने वाले समय को एक सेकंड कम करने में मदद मिली.
अगर आपको Google Fonts का इस्तेमाल करके फ़ॉन्ट पहले से लोड करने हैं, तो यह इतना आसान नहीं है. इसमें एक समस्या है.
हमारी स्टाइलशीट में, फ़ॉन्ट फ़ेस पर बताए गए Google Font के यूआरएल, कुछ ऐसे होते हैं जिन्हें फ़ॉन्ट टीम नियमित तौर पर अपडेट करती है. ये यूआरएल समयसीमा खत्म होने पर काम करना बंद कर सकते हैं या इन्हें नियमित तौर पर अपडेट किया जा सकता है. इसलिए, अगर आपको फ़ॉन्ट लोड होने की प्रोसेस पर पूरा कंट्रोल चाहिए, तो हमारा सुझाव है कि आप अपने वेब फ़ॉन्ट खुद होस्ट करें. यह बहुत बढ़िया हो सकता है, क्योंकि इससे आपको लिंक rel प्रीलोड जैसी चीज़ों का ऐक्सेस मिलता है.
हमें Google Web Fonts Helper टूल काफ़ी मददगार लगा. इसकी मदद से, हमने कुछ वेब फ़ॉन्ट को ऑफ़लाइन किया और उन्हें स्थानीय तौर पर सेट अप किया. इसलिए, इस टूल को ज़रूर आज़माएं.
चाहे वेब फ़ॉन्ट का इस्तेमाल आपके ज़रूरी संसाधनों के हिस्से के तौर पर किया जा रहा हो या JavaScript के तौर पर, ब्राउज़र को आपके ज़रूरी संसाधनों को जल्द से जल्द डिलीवर करने में मदद करें.
एक्सपेरिमेंटल: प्राथमिकता के संकेत
आज हमारे पास आपके साथ शेयर करने के लिए कुछ खास है. रिसोर्स हिंट और प्रीलोड जैसी सुविधाओं के अलावा, हम ब्राउज़र की एक नई सुविधा पर काम कर रहे हैं. इसे हम प्रायॉरिटी हिंट कहते हैं. फ़िलहाल, यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध है.
यह एक नई सुविधा है. इसकी मदद से, ब्राउज़र को यह बताया जा सकता है कि कोई संसाधन कितना ज़रूरी है. यह एक नया एट्रिब्यूट - importance - दिखाता है. इसकी वैल्यू low, high या auto होती है.
इससे हमें कम ज़रूरी संसाधनों की प्राथमिकता को कम करने में मदद मिलती है. जैसे, कम ज़रूरी स्टाइल, इमेज या फ़ेच एपीआई कॉल, ताकि कॉन्टेंट को लोड होने में कम समय लगे. हम ज़्यादा ज़रूरी चीज़ों को भी प्राथमिकता दे सकते हैं. जैसे, हमारी हीरो इमेज.
Oodle ऐप्लिकेशन के मामले में, इससे हमें एक ऐसी जगह मिली जहां हम ऑप्टिमाइज़ कर सकते थे.
इमेज के लिए लेज़ी लोडिंग की सुविधा जोड़ने से पहले, ब्राउज़र हमारे सभी डूडल वाले इस इमेज कैरसेल को लोड करता था. साथ ही, ब्राउज़र कैरसेल की शुरुआत में ही सभी इमेज को प्राथमिकता के आधार पर फ़ेच करता था. हालांकि, कैरसेल के बीच में मौजूद इमेज, उपयोगकर्ता के लिए सबसे अहम थीं. इसलिए, हमने बैकग्राउंड की इमेज की अहमियत को बहुत कम और फ़ोरग्राउंड की इमेज की अहमियत को बहुत ज़्यादा पर सेट किया. इससे, धीमे 3G नेटवर्क पर दो सेकंड का असर पड़ा. साथ ही, हम उन इमेज को तेज़ी से फ़ेच और रेंडर कर पाए. इसलिए, यह एक अच्छा अनुभव है.
हम कुछ हफ़्तों में इस सुविधा को Canary में उपलब्ध कराने की उम्मीद कर रहे हैं. इसलिए, इस पर नज़र बनाए रखें.
वेब फ़ॉन्ट लोड करने की रणनीति बनाएं
टाइपोग्राफ़ी, अच्छे डिज़ाइन के लिए ज़रूरी है. अगर वेब फ़ॉन्ट का इस्तेमाल किया जा रहा है, तो आपको अपने टेक्स्ट की रेंडरिंग को ब्लॉक नहीं करना चाहिए. साथ ही, आपको अदृश्य टेक्स्ट नहीं दिखाना चाहिए.
अब हम 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 की टाइमलाइन स्ट्रिप पर, आपको दिखेगा कि शुरुआती कुछ सेकंड में, जब सभी रिसॉर्स लोड हो रहे होते हैं, तब उपयोगकर्ता को कोई कॉन्टेंट नहीं दिखता.
बाहरी स्टाइलशीट को डाउनलोड और प्रोसेस करने की वजह से, रेंडर करने की हमारी प्रोसेस आगे नहीं बढ़ पा रही है.
हम कुछ स्टाइल को थोड़ा पहले डिलीवर करके, अपने क्रिटिकल रेंडरिंग पाथ को ऑप्टिमाइज़ करने की कोशिश कर सकते हैं.
अगर हम इस शुरुआती रेंडर के लिए ज़िम्मेदार स्टाइल को एक्सट्रैक्ट करके, उन्हें अपने एचटीएमएल में इनलाइन कर दें, तो ब्राउज़र उन्हें तुरंत रेंडर कर सकता है. इसके लिए, उसे बाहरी स्टाइलशीट के आने का इंतज़ार नहीं करना पड़ता.
हमारे मामले में, हमने Critical नाम के एनपीएम मॉड्यूल का इस्तेमाल किया, ताकि बिल्ड स्टेप के दौरान index.html में अपने ज़रूरी कॉन्टेंट को इनलाइन किया जा सके.
हालांकि, इस मॉड्यूल ने हमारे लिए ज़्यादातर मुश्किल काम किए, लेकिन अलग-अलग रूट पर इसे आसानी से इस्तेमाल करना अब भी थोड़ा मुश्किल था.
अगर आपने सावधानी नहीं बरती या आपकी साइट का स्ट्रक्चर बहुत जटिल है, तो इस तरह के पैटर्न को लागू करना बहुत मुश्किल हो सकता है. ऐसा तब होता है, जब आपने शुरुआत से ही ऐप्लिकेशन शेल आर्किटेक्चर के लिए प्लान न किया हो.
इसलिए, यह ज़रूरी है कि शुरुआत से ही परफ़ॉर्मेंस को ध्यान में रखा जाए. अगर आपने शुरुआत से ही परफ़ॉर्मेंस को ध्यान में रखकर डिज़ाइन नहीं किया है, तो हो सकता है कि आपको बाद में समस्याएं आएं.
आखिर में, हमारा जोखिम भरा फ़ैसला सही साबित हुआ. हम इसे लागू करने में कामयाब रहे और ऐप्लिकेशन ने कॉन्टेंट को पहले से ज़्यादा तेज़ी से डिलीवर करना शुरू कर दिया. इससे हमारे फ़र्स्ट मीनिंगफ़ुल पेंट टाइम में काफ़ी सुधार हुआ.
नतीजा
हमने अपनी साइट की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, कई बदलाव किए. आइए, इसके नतीजे पर एक नज़र डालते हैं. ऑप्टिमाइज़ेशन से पहले और बाद में, 3G नेटवर्क पर मीडियम मोबाइल डिवाइस पर हमारा ऐप्लिकेशन इस तरह लोड हुआ.
लाइटहाउस परफ़ॉर्मेंस स्कोर 23 से बढ़कर 91 हो गया. स्पीड के मामले में, यह काफ़ी अच्छी प्रोग्रेस है. ये सभी बदलाव, Lighthouse रिपोर्ट की लगातार जांच करने और उसका पालन करने की वजह से किए गए. अगर आपको यह देखना है कि हमने तकनीकी तौर पर सभी सुधार कैसे लागू किए, तो बेझिझक हमारी रिपॉज़िटरी पर जाएं. खास तौर पर, वहां मौजूद पीआर देखें.
परफ़ॉर्मेंस का अनुमान - डेटा के आधार पर उपयोगकर्ता अनुभव
हमारा मानना है कि मशीन लर्निंग, आने वाले समय में कई क्षेत्रों में बेहतरीन अवसर उपलब्ध कराएगी. हमें उम्मीद है कि आने वाले समय में, इस आइडिया से ज़्यादा एक्सपेरिमेंट किए जा सकेंगे. असली डेटा से, उपयोगकर्ताओं को बेहतर अनुभव देने में मदद मिल सकती है.
आज हम इस बारे में कई फ़ैसले लेते हैं कि उपयोगकर्ता को क्या चाहिए या क्या नहीं. इसलिए, यह तय करना ज़रूरी है कि किस कॉन्टेंट को पहले से फ़ेच, पहले से लोड या प्री-कैशिंग किया जाए. अगर हमारा अनुमान सही होता है, तो हम कुछ संसाधनों को प्राथमिकता दे पाते हैं. हालांकि, इसे पूरी वेबसाइट पर लागू करना बहुत मुश्किल होता है.
आज हमारे पास ऐसा डेटा उपलब्ध है जिससे हम अपने ऑप्टिमाइज़ेशन को बेहतर बना सकते हैं. Google Analytics Reporting API का इस्तेमाल करके, हम अपनी साइट के किसी भी यूआरएल के लिए, अगले टॉप पेज और साइट छोड़ने वाले उपयोगकर्ताओं के प्रतिशत को देख सकते हैं. इससे हमें यह तय करने में मदद मिलती है कि हमें किन संसाधनों को प्राथमिकता देनी चाहिए.
अगर हम इसे एक अच्छे प्रॉबेबिलिटी मॉडल के साथ जोड़ते हैं, तो हम कॉन्टेंट को ज़रूरत से ज़्यादा प्रीफ़ेच करके, अपने उपयोगकर्ता के डेटा को बर्बाद होने से बचाते हैं. हम Google Analytics के डेटा का फ़ायदा ले सकते हैं. साथ ही, इस तरह के मॉडल लागू करने के लिए, मशीन लर्निंग और मार्कोव चेन या न्यूरल नेटवर्क जैसे मॉडल का इस्तेमाल कर सकते हैं.
इन प्रयोगों को आसान बनाने के लिए, हमें एक नई पहल का एलान करते हुए खुशी हो रही है. इसे हम Guess.js कहते हैं.
Guess.js एक ऐसा प्रोजेक्ट है जो वेब पर डेटा के आधार पर उपयोगकर्ता अनुभव देने पर फ़ोकस करता है. हमें उम्मीद है कि इससे आपको वेब की परफ़ॉर्मेंस को बेहतर बनाने के लिए, डेटा का इस्तेमाल करने और उससे आगे बढ़ने की प्रेरणा मिलेगी. यह पूरी तरह से ओपन सोर्स है और आज से GitHub पर उपलब्ध है. इसे ओपन सोर्स कम्यूनिटी के साथ मिलकर बनाया गया था. इसमें मिंको गेचेव, Gatsby के काइल मैथ्यूज़, केटी हेम्पेनियस, और कई अन्य लोग शामिल थे.
Guess.js को आज़माएं और हमें बताएं कि आपको यह कैसा लगा.
खास जानकारी
स्कोर और मेट्रिक, वेब की स्पीड को बेहतर बनाने में मदद करते हैं. हालांकि, ये सिर्फ़ एक ज़रिया हैं, लक्ष्य नहीं.
हम सभी ने कभी न कभी, पेज लोड होने में लगने वाले समय की समस्या का सामना किया है. हालांकि, अब हमारे पास उपयोगकर्ताओं को बेहतर अनुभव देने का मौका है. इसके लिए, हमें ऐसे पेज बनाने होंगे जो तेज़ी से लोड हों.
परफ़ॉर्मेंस को बेहतर बनाना एक सफ़र है. छोटे-छोटे बदलावों से बड़ा फ़ायदा मिल सकता है. ऑप्टिमाइज़ेशन के सही टूल इस्तेमाल करके और Lighthouse रिपोर्ट पर नज़र रखकर, उपयोगकर्ताओं को बेहतर और ज़्यादा समावेशी अनुभव दिया जा सकता है.
इनका खास तौर पर धन्यवाद: वॉर्ड पीटर्स, मिंको गेचेव, काइल मैथ्यूज़, केटी हेम्पेनियस, डॉम फ़ैरोलिनो, योव वाइस, सूज़ी लू, युसुके उत्सुनोमिया, टॉम एंकर्स, Lighthouse, और Google डूडल.