Google IO 2018 में, हमने ऐसे टूल, लाइब्रेरी, और ऑप्टिमाइज़ेशन तकनीकों का राउंडअप पेश किया है जिनसे वेब की परफ़ॉर्मेंस को बेहतर बनाना आसान हो जाता है. यहां हमने उन्हें Oodles थिएटर ऐप्लिकेशन का इस्तेमाल करने के बारे में बताया है. इसमें, हम अनुमान के हिसाब से लोड होने की सुविधा और नए Guess.js पहल से जुड़े प्रयोगों के बारे में भी बताएंगे.
हम पिछले साल से यह पता लगाने में काफ़ी व्यस्त हैं कि वेब को तेज़ और बेहतर कैसे बनाया जाए. इससे हमें ऐसे नए टूल, तरीके, और लाइब्रेरी मिली हैं जिनके बारे में हम इस लेख में आपके साथ शेयर करना चाहते हैं. पहले हिस्से में, हम आपको Oodles थिएटर ऐप्लिकेशन को डेवलप करते समय इस्तेमाल की गई ऑप्टिमाइज़ेशन की कुछ तकनीकों के बारे में बताएंगे. दूसरे हिस्से में, हम अनुमानित लोडिंग और नई Guess.js पहल को लेकर किए गए प्रयोगों के बारे में बताएंगे.
परफ़ॉर्मेंस की ज़रूरत
इंटरनेट हर साल भारी और भारी होता जा रहा है. अगर हम वेब की स्थिति की जांच करते हैं, तो हम देख सकते हैं कि मोबाइल पर किसी मीडियन पेज का वज़न करीब 1.5 एमबी है और उसमें से ज़्यादातर JavaScript और इमेज हैं.
नेटवर्क इंतज़ार का समय, सीपीयू की सीमाएं, रेंडर होने के पैटर्न या बेकार तीसरे पक्ष के कोड जैसे दूसरे फ़ैक्टर के साथ-साथ, वेबसाइटों का बढ़ता साइज़, की मुश्किल परफ़ॉर्मेंस की पहेली में योगदान देता है.
ज़्यादातर उपयोगकर्ता, स्पीड को अपनी ज़रूरतों के हिसाब से UX हैरारकी में सबसे ऊपर मानते हैं. यह बहुत हैरानी की बात नहीं है, क्योंकि पेज के लोड होने तक आप बहुत कुछ नहीं कर सकते. आपको पेज से कुछ खास जानकारी नहीं मिल सकती, लेकिन पेज की ख़ूबसूरती को पसंद नहीं किया जा सकता.
हम जानते हैं कि परफ़ॉर्मेंस उपयोगकर्ता के लिए मायने रखती है, लेकिन यह एक ऐसे सीक्रेट खोज जैसा भी लग सकता है जहां से ऑप्टिमाइज़ करना शुरू किया जा सकता है. अच्छी बात यह है कि ऐसे टूल उपलब्ध हैं जो इस काम में आपकी मदद कर सकते हैं.
लाइटहाउस - परफ़ॉर्मेंस वर्कफ़्लो का आधार
Lighthouse, Chrome DevTools का हिस्सा है. इससे आपकी वेबसाइट का ऑडिट किया जा सकता है. साथ ही, वेबसाइट को बेहतर बनाने के सुझाव भी मिलते हैं.
हमने हाल ही में नए परफ़ॉर्मेंस ऑडिट का एक कलेक्शन लॉन्च किया है, जो रोज़मर्रा के डेवलपमेंट वर्कफ़्लो में वाकई काम आता है.
आइए एक व्यावहारिक उदाहरण से जानें कि आप इनका फ़ायदा कैसे उठा सकते हैं: The Oodles ज़रिए थिएटर ऐप्लिकेशन. यह एक छोटा-सा डेमो वेब ऐप्लिकेशन है, जहां आप हमारे कुछ पसंदीदा इंटरैक्टिव Google डूडल आज़मा सकते हैं. साथ ही, एक-दो गेम खेल सकते हैं.
ऐप्लिकेशन बनाते समय, हम यह पक्का करना चाहते थे कि यह ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बना सके. ऑप्टिमाइज़ेशन की शुरुआत लाइटहाउस रिपोर्ट से हुई.
लाइटहाउस रिपोर्ट में हमारे ऐप्लिकेशन की शुरुआती परफ़ॉर्मेंस बहुत खराब थी. 3G नेटवर्क पर, उपयोगकर्ता को पहले सार्थक पेंट के लिए या ऐप्लिकेशन के इंटरैक्टिव होने के लिए 15 सेकंड तक इंतज़ार करना पड़ता है. लाइटहाउस ने हमारी साइट पर कई समस्याओं को हाइलाइट किया है और 23 का कुल परफ़ॉर्मेंस स्कोर ठीक वैसा ही है.
पेज का वज़न 3.4 एमबी है - फ़ैट घटाने की हमारी बेहद ज़रूरत है.
इससे हमारी पहली परफ़ॉर्मेंस को चुनौती मिली: ऐसी चीज़ें खोजें जिन्हें हम पूरे अनुभव पर असर डाले बिना आसानी से हटा सकते हैं.
परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के अवसर
गैर-ज़रूरी संसाधनों को हटाएं
यहां कुछ ऐसी चीज़ें दी गई हैं जिन्हें आसानी से हटाया जा सकता है: खाली सफ़ेद जगह और टिप्पणियां.
लाइटहाउस इस अवसर को अनमिनिफ़ाइड सीएसएस और JavaScript ऑडिट में हाइलाइट करता है. हम बिल्ड प्रोसेस के लिए वेबपैक का इस्तेमाल कर रहे थे. इसलिए, छोटा करने के लिए हमने सिर्फ़ Uglify JS प्लगिन का इस्तेमाल किया.
काट-छांट करना एक आम काम है. इसलिए, किसी भी प्रोसेस का इस्तेमाल करने के लिए, आपको पहले से तैयार समाधान मिल जाना चाहिए.
ऐसे में टेक्स्ट कंप्रेस करने की सुविधा चालू करना भी काम का एक और ऑडिट है. बिना कंप्रेस की गई फ़ाइलें भेजने की कोई वजह नहीं होती. इसलिए, इन दिनों ज़्यादातर सीडीएन बेहतरीन तरीके से काम करते हैं.
हम अपने कोड को होस्ट करने के लिए Firebase होस्टिंग का इस्तेमाल कर रहे थे. Firebase डिफ़ॉल्ट रूप से gzipping की सुविधा चालू करता है. इसलिए, अपने कोड को सही सीडीएन पर होस्ट करने की वजह से, हमें यह सुविधा मुफ़्त में मिली.
gzip की मदद से कंप्रेस करने का तरीका काफ़ी लोकप्रिय है. हालांकि, Zopfli और Bromli जैसे दूसरे तरीकों का भी इस्तेमाल किया जा रहा है. Brotli में ज़्यादातर ब्राउज़र पर काम करता है. साथ ही, अपनी ऐसेट को सर्वर पर भेजने से पहले, उसे पहले से कंप्रेस करने के लिए बाइनरी का इस्तेमाल किया जा सकता है.
कैश मेमोरी की बेहतर नीतियां इस्तेमाल करना
हमारा अगला कदम यह पक्का करना था कि ज़रूरत पड़ने पर हम संसाधनों को दो बार न भेजें.
लाइटहाउस में ठीक से काम न करने वाली कैश मेमोरी की नीति के ऑडिट से हमें यह पता चला कि हम कैश मेमोरी में सेव करने की अपनी रणनीतियों को ऑप्टिमाइज़ कर सकते हैं, ताकि सही नतीजे मिल सकें. हमारे सर्वर में अधिकतम आयु सीमा वाला हेडर सेट करके, हमने यह पक्का किया कि बार-बार विज़िट करने पर उपयोगकर्ता उन संसाधनों का फिर से इस्तेमाल कर सके जिन्हें उन्होंने पहले डाउनलोड किया है.
आम तौर पर, आपको ज़्यादा से ज़्यादा संसाधनों को सुरक्षित तौर पर कैश मेमोरी में सेव करना चाहिए. साथ ही, अपडेट किए गए रिसॉर्स की फिर से पुष्टि करने के लिए, पुष्टि टोकन उपलब्ध कराना चाहिए.
इस्तेमाल न होने वाले कोड हटा दें
अब तक हमने गैर-ज़रूरी डाउनलोड के आसान हिस्सों को हटा दिया है, लेकिन उन हिस्सों का क्या है जो कम साफ़ हैं? उदाहरण के लिए, इस्तेमाल न हुआ कोड.
कभी-कभी हम अपने ऐप्लिकेशन कोड में ऐसे कोड शामिल करते हैं जो वाकई ज़रूरी नहीं होता. ऐसा खास तौर पर तब होता है, जब लंबे समय तक अपने ऐप्लिकेशन पर काम किया जाता है. ऐसे में, आपकी टीम या आपकी डिपेंडेंसी बदल जाती हैं. कभी-कभी कोई अनाथ लाइब्रेरी भी छूट जाती है. ठीक ऐसा ही हमारे साथ हुआ.
शुरुआत में हम अपने ऐप्लिकेशन को तेज़ी से प्रोटोटाइप करने के लिए मटीरियल कॉम्पोनेंट वाली लाइब्रेरी का इस्तेमाल कर रहे थे. समय के साथ हमने गेम को पसंद के मुताबिक बनाया और इसके बारे में पूरी तरह से बात नहीं की. अच्छी बात यह है कि कोड कवरेज की जांच से हमें अपने बंडल में, इसे फिर से खोजने में मदद मिली.
DevTools में अपने कोड कवरेज के आंकड़े, रनटाइम और ऐप्लिकेशन के लोड होने में लगने वाले समय, दोनों के लिए देखे जा सकते हैं. नीचे के स्क्रीनशॉट में आपको लाल रंग की दो बड़ी धारियां दिखेंगी. - हमारे पास से 95% से ज़्यादा सीएसएस का इस्तेमाल नहीं हुआ था. साथ ही, बड़ी संख्या में JavaScript का भी इस्तेमाल हुआ था.
लाइटहाउस ने इस समस्या के बारे में, सीएसएस के इस्तेमाल नहीं किए गए नियमों के ऑडिट में भी समस्या के बारे में बताया था. इससे 400 केबी से ज़्यादा की बचत हुई. इसलिए, हम अपने कोड पर वापस आ गए हैं और हमने उस लाइब्रेरी के JavaScript और सीएसएस, दोनों हिस्सों को हटा दिया है.
इससे हमारा सीएसएस बंडल 20 फ़ोल्ड हो गया, जो दो लाइन वाले छोटे साइज़ के बंडल के लिए काफ़ी अच्छा है.
बेशक, इससे हमारा परफ़ॉर्मेंस स्कोर बढ़ गया और टाइम टू इंटरैक्टिव काफ़ी बेहतर हो गया.
हालांकि, इस तरह के बदलावों से, सिर्फ़ मेट्रिक और स्कोर की जांच करना ही काफ़ी नहीं है. असल कोड को हटाने से कोई जोखिम नहीं होता. इसलिए, आपको हमेशा संभावित रिग्रेशन पर ध्यान देना चाहिए.
हमारे कोड का 95% तक इस्तेमाल नहीं हुआ - फिर भी कहीं न कहीं यह 5% है. साफ़ तौर पर हमारा एक कॉम्पोनेंट अब भी उस लाइब्रेरी की स्टाइल का इस्तेमाल कर रहा था - ये डूडल स्लाइडर में मौजूद छोटे तीर हैं. यह बहुत छोटा था, इसलिए हम आगे बढ़कर, उन स्टाइल को बटन में फिर से जोड़कर मैन्युअल तरीके से लागू कर सकते थे.
इसलिए, अगर कोड हटा दिया जाता है, तो पक्का करें कि आपके पास सही टेस्टिंग वर्कफ़्लो है. इससे संभावित विज़ुअल रिग्रेशन से बचने में आपको मदद मिलती है.
बहुत ज़्यादा नेटवर्क पेलोड से बचें
हम जानते हैं कि ज़्यादा संसाधन होने से वेब पेज लोड होने की स्पीड कम हो सकती है. वे हमारे उपयोगकर्ताओं का पैसा खर्च कर सकती हैं और वे अपने डेटा प्लान पर बड़ा असर डाल सकती हैं, इसलिए इस पर ध्यान रखना ज़रूरी है.
Lighthouse ने एनर्जी नेटवर्क पेलोड ऑडिट का इस्तेमाल करके, हमारे कुछ नेटवर्क पेलोड में समस्या का पता लगाया.
यहां हमने देखा कि हमारे पास 3 एमबी से भी ज़्यादा कीमत का कोड था जिसे शिप किया जा रहा था – जो बहुत ज़्यादा है, खास तौर पर मोबाइल पर.
इस सूची में सबसे ऊपर, Lighthouse ने हाइलाइट किया कि हमारे पास एक ऐसा JavaScript वेंडर बंडल था जो बिना कंप्रेस किए हुए कोड का 2 एमबी था. यह भी वेबपैक से हाइलाइट की गई समस्या है.
जैसा कि कहा गया है: सबसे तेज़ अनुरोध वही होता है जो पूरा नहीं किया जाता.
आम तौर पर, आपको उपयोगकर्ताओं को दिखाई जाने वाली हर एक ऐसेट की वैल्यू का आकलन करना चाहिए. साथ ही, उन ऐसेट की परफ़ॉर्मेंस को मेज़र करना चाहिए और यह तय करना चाहिए कि शुरुआत के अनुभव से प्रॉडक्ट को शिपिंग के लायक बनाना है या नहीं. ऐसा इसलिए है, क्योंकि कभी-कभी इन ऐसेट को स्थगित या लेज़ी लोड या इस्तेमाल में न होने पर प्रोसेस किया जा सकता है.
हमारे मामले में, हम बहुत सारे JavaScript बंडल का इस्तेमाल कर रहे हैं, इसलिए हमारी किस्मत अच्छी थी, क्योंकि JavaScript समुदाय में JavaScript बंडल ऑडिटिंग टूल का एक समृद्ध सेट था.
हमने वेबपैक बंडल ऐनालाइज़र के साथ शुरुआत की थी. इससे हमें पता चला कि हम यूनिकोड नाम की डिपेंडेंसी को शामिल कर रहे हैं, जो पार्स किए गए JavaScript का 1.6 एमबी है.
इसके बाद, हम अपने एडिटर पर गए और विज़ुअल कोड के लिए इंपोर्ट शुल्क प्लग इन का इस्तेमाल करके, इंपोर्ट किए जा रहे हर मॉड्यूल की कीमत का अनुमान लगा पाए. इससे हमें यह पता चला कि इस मॉड्यूल को रेफ़र करने वाले कोड के साथ कौनसा कॉम्पोनेंट शामिल था.
उसके बाद, हमने BundlePhobia नाम के दूसरे टूल पर स्विच कर दिया. यह एक ऐसा टूल है जो आपको किसी भी एनपीएम पैकेज का नाम डालने और असल में यह देखने की सुविधा देता है कि उसका छोटा और gzip किया गया साइज़ कितना हो सकता है. हमें इस्तेमाल किए जा रहे स्लग मॉड्यूल का एक अच्छा विकल्प मिला, जिसका वज़न सिर्फ़ 2.2 केबी था और इसलिए हमने उसे बदल दिया.
इससे हमारी परफ़ॉर्मेंस पर काफ़ी असर पड़ा. इस बदलाव के बीच और अपने JavaScript बंडल के साइज़ को कम करने के दूसरे अवसरों के बारे में जानने के दौरान, हमने 2.1 एमबी कोड की बचत की.
हमने इन बंडल के gzip और कम किए गए साइज़ को शामिल करने के बाद, कुल मिलाकर 65% सुधार देखे हैं. और हमने पाया कि एक प्रक्रिया के तौर पर ऐसा करना वाकई फ़ायदेमंद था.
इसलिए, आम तौर पर अपनी साइटों और ऐप्लिकेशन में गैर-ज़रूरी डाउनलोड को हटाने की कोशिश करें. अपनी एसेट की एक इन्वेंट्री बनाएं और उनके परफ़ॉर्मेंस के असर को मेज़र करें. इससे बहुत ज़्यादा फ़र्क़ पड़ सकता है इसलिए, पक्का करें कि एसेट का नियमित रूप से ऑडिट किया जा रहा हो.
कोड को अलग-अलग करके, JavaScript के चालू होने में लगने वाला समय कम करें
वैसे तो बड़े नेटवर्क पेलोड का हमारे ऐप्लिकेशन पर बड़ा असर हो सकता है, लेकिन एक और चीज़ है जिसका बहुत बड़ा असर हो सकता है और वह है JavaScript.
JavaScript आपकी सबसे महंगी एसेट है. मोबाइल पर, अगर JavaScript के बड़े बंडल भेजे जा रहे हैं, तो आपके उपयोगकर्ताओं के आपके यूज़र इंटरफ़ेस कॉम्पोनेंट से इंटरैक्ट करने में, समय लग सकता है. इसका मतलब है कि वे यूज़र इंटरफ़ेस (यूआई) पर टैप कर सकते हैं. हालांकि, ऐसा करने से कोई फ़ायदा नहीं होगा. इसलिए हमारे लिए यह समझना महत्वपूर्ण है कि JavaScript की कीमत इतनी क्यों है.
ब्राउज़र JavaScript को इस तरह प्रोसेस करता है.
सबसे पहले हमें वह स्क्रिप्ट डाउनलोड करनी होती है, हमारे पास एक JavaScript इंजन होता है जिसे उस कोड को पार्स करना होता है, उसे कंपाइल करके लागू करना होता है.
अब ये चरण ऐसे हैं जिन्हें डेस्कटॉप मशीन या लैपटॉप जैसे महंगे डिवाइस पर बहुत ज़्यादा समय नहीं लगता है, यहां तक कि एक हाई-एंड फ़ोन भी. हालाँकि, मीडियन मोबाइल फ़ोन पर इस प्रोसेस में पाँच से दस गुना ज़्यादा समय लग सकता है. इसी वजह से इंटरैक्टिविटी में देरी होती है, इसलिए यह ज़रूरी है कि हम इसे कम करें.
आपके ऐप्लिकेशन से जुड़ी इन समस्याओं का पता लगाने में आपकी मदद करने के लिए, हमने Lighthouse में एक नया JavaScript बूट-अप टाइम ऑडिट लॉन्च किया है.
Oodle ऐप्लिकेशन के मामले में, इसने हमें बताया कि हमने JavaScript को चालू करने में 1.8 सेकंड का समय बिताया. बात यह थी कि हम अपने सभी रूट और कॉम्पोनेंट को एक ही मोनोलिथिक JavaScript बंडल में इंपोर्ट कर रहे थे.
इसे ठीक करने का एक तरीका यह है कि कोड विभाजन का इस्तेमाल किया जाए.
कोड को अलग-अलग हिस्सों में बांटने का मतलब यह है कि उपयोगकर्ताओं को पिज़्ज़ा की पूरी कीमत देने के बजाय, एक बार में सिर्फ़ एक स्लाइस दिया जाए, तो क्या होगा?
कोड को अलग-अलग लेवल पर बांटा जा सकता है. इन्हें रूट लेवल या कॉम्पोनेंट लेवल पर लागू किया जा सकता है. यह React और React Loadable, Vue.js, Angular, Polymer, Preact, और कई अन्य लाइब्रेरी के साथ बहुत अच्छा काम करता है.
हमने अपने ऐप्लिकेशन में कोड को बांटने को शामिल किया. साथ ही, हमने स्टैटिक इंपोर्ट की जगह डाइनैमिक इंपोर्ट का इस्तेमाल किया. इससे हमें ज़रूरत के हिसाब से, एसिंक्रोनस रूप से लेज़ी लोड कोड की सुविधा मिली.
इसका असर हमारे बंडल का साइज़ कम होने के साथ-साथ, JavaScript के चालू होने का समय भी कम हुआ. इसे इंस्टॉल करने में 0.78 सेकंड लगे, जिससे ऐप्लिकेशन 56% तेज़ हो गया.
आम तौर पर, अगर JavaScript का बहुत ज़्यादा इस्तेमाल करना है, तो सिर्फ़ उन उपयोगकर्ताओं को कोड भेजें जिन्हें उनकी ज़रूरत है.
कोड स्प्लिट करने जैसे कॉन्सेप्ट का फ़ायदा उठाएं, ट्री शेकिंग जैसे आइडिया आज़माएं, और webpack-libs- Optimizations रेपो देखें.
इमेज ऑप्टिमाइज़ करें
Oodle ऐप्लिकेशन में हम काफ़ी इमेज इस्तेमाल कर रहे हैं. माफ़ करें, लाइटहाउस को लेकर हमारी उम्मीद बहुत कम थी. दरअसल, हम इमेज से जुड़े सभी तीन ऑडिट में फ़ेल हो गए थे.
हम अपनी इमेज को ऑप्टिमाइज़ करना भूल गए, हम उनका साइज़ सही तरीके से नहीं लगा पा रहे थे. साथ ही, दूसरे इमेज फ़ॉर्मैट इस्तेमाल करके हमें कुछ फ़ायदा मिल सकता था.
हमने अपनी इमेज को ऑप्टिमाइज़ करने का काम शुरू किया.
एक बार ऑप्टिमाइज़ेशन करने के लिए, ImageOptim या XNConvert जैसे विज़ुअल टूल का इस्तेमाल किया जा सकता है.
एक ज़्यादा ऑटोमेटेड तरीका यह है कि आप अपनी बिल्ड प्रोसेस में imagemin जैसी लाइब्रेरी के साथ इमेज ऑप्टिमाइज़ेशन चरण जोड़ें.
इस तरह, यह पक्का किया जाता है कि आने वाले समय में जोड़ी जाने वाली इमेज अपने-आप ऑप्टिमाइज़ हो जाएं. कुछ सीडीएन, जैसे कि Akamai या तीसरे पक्ष के सलूशन, जैसे कि Cloudinary, फ़ास्टली या अपलोडकेयर में आपको इमेज ऑप्टिमाइज़ेशन से जुड़ी बेहतर सुविधाएं मिलती हैं. इससे उन सेवाओं पर अपनी इमेज को होस्ट भी किया जा सकता है.
अगर आपको शुल्क या इंतज़ार के समय की समस्याओं की वजह से ऐसा नहीं करना है, तो thumbsor या Imageflow जैसे प्रोजेक्ट के लिए, अपने-आप होस्ट किए जाने वाले विकल्प इस्तेमाल किए जा सकते हैं.
वेबपैक में हमारी पृष्ठभूमि PNG को बड़े के रूप में फ़्लैग किया गया था, और बिलकुल सही. व्यूपोर्ट का सही आकार देने और उसे ImageOptim के ज़रिए चलाने के बाद हम 100kb तक पहुंच गए, जो स्वीकार्य है.
अपनी साइट पर कई इमेज के लिए ऐसा करने से, हमें पेज का कुल वज़न बहुत कम करने में मदद मिली.
ऐनिमेशन वाले कॉन्टेंट के लिए सही फ़ॉर्मैट का इस्तेमाल करें
GIF बहुत महंगे हो सकते हैं. हैरानी की बात है कि GIF फ़ॉर्मैट को ऐनिमेशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने की शुरुआत नहीं की गई थी. इसलिए, वीडियो के बेहतर फ़ॉर्मैट पर स्विच करने से, फ़ाइल के साइज़ के हिसाब से काफ़ी बचत होती है.
Oodle ऐप्लिकेशन में, हम होम पेज पर इंट्रो कार्ड में सीक्वेंस के तौर पर GIF का इस्तेमाल कर रहे थे. Lighthouse के मुताबिक, बेहतर वीडियो फ़ॉर्मैट का इस्तेमाल करके हम सात एमबी से भी ज़्यादा की बचत कर सकते हैं. हमारी क्लिप का वज़न 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 एमबी एक बड़ा संसाधन है, खास तौर पर प्रतिबंधित बैंडविड्थ का इस्तेमाल करने वाले उपयोगकर्ता के लिए. अच्छी बात यह है कि हम प्रभावी Type API का इस्तेमाल कर सकते हैं, ताकि यह महसूस किया जा सके कि वे धीमी बैंडविड्थ पर काम करते हैं. इसकी जगह हम उनका JPEG फ़ॉर्मैट इस्तेमाल करते हैं, जो बहुत कम होता है.
यह इंटरफ़ेस, उपयोगकर्ता के नेटवर्क टाइप का अनुमान लगाने के लिए, दोतरफ़ा यात्रा के समय और डाउनिंग वैल्यू का इस्तेमाल करता है. यह सिर्फ़ एक स्ट्रिंग देता है, जो धीमी रफ़्तार से 2G, 2G, 3G या 4G नेटवर्क पर काम करती है. इसलिए, इस वैल्यू के आधार पर अगर उपयोगकर्ता 4G से पहले के वर्शन का इस्तेमाल करता है, तो हम वीडियो एलिमेंट को इमेज से बदल सकते हैं.
if (navigator.connection.effectiveType) { ... }
इससे थोड़ा-बहुत अनुभव मिलता है, लेकिन कम से कम साइट का इस्तेमाल धीमे कनेक्शन पर किया जा सकता है.
ऑफ़-स्क्रीन इमेज की लेज़ी लोडिंग
कैरसेल, स्लाइडर या बहुत लंबे पेज अक्सर इमेज लोड करते हैं, भले ही उपयोगकर्ता उन्हें पेज पर सीधे नहीं देख सकता.
लाइटहाउस इस व्यवहार को ऑफ़-स्क्रीन इमेज ऑडिट में फ़्लैग करेगा और आप इसे 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 जैसे संसाधन से जुड़े सुझाव.
वेब प्लैटफ़ॉर्म पर लाई गई ये क्षमताएं, ब्राउज़र को सही समय पर सही काम करने में मदद करती हैं. साथ ही, ये लॉजिक पर आधारित कस्टम लोडिंग तरीकों की तुलना में थोड़ी ज़्यादा असरदार हो सकती हैं, जो इसके बजाय स्क्रिप्ट का इस्तेमाल करके किए जाते हैं.
आइए, देखते हैं कि लाइटहाउस सिस्टम, इनमें से कुछ सुविधाओं का बेहतर तरीके से इस्तेमाल करने में हमारी मदद कैसे करता है.
लाइटहाउस की सबसे पहली बात यह है कि वह किसी भी जगह पर जाने के लिए कई महंगी दोतरफ़ा यात्रा से बचें.
Oodle ऐप्लिकेशन के मामले में, हम Google फ़ॉन्ट का बहुत ज़्यादा इस्तेमाल कर रहे हैं. जब भी आप अपने पेज में कोई Google फ़ॉन्ट स्टाइलशीट छोड़ेंगे, तो वह दो सबडोमेन से कनेक्ट हो जाएगा. साथ ही, लाइटहाउस हमें बता रहा है कि अगर हम उस कनेक्शन को गर्म कर पाएँ, तो हम शुरुआती कनेक्शन समय में 300 मिलीसेकंड तक कहीं भी की बचत कर सकते हैं.
लिंक rel प्रीकनेक्ट का फ़ायदा उठाकर, हम कनेक्शन के इंतज़ार के समय को असरदार तरीके से मास्क कर सकते हैं.
खासकर Google Fonts जैसे कुछ ऐप्लिकेशन में, जहां हमारे फ़ॉन्ट फ़ेस सीएसएस को googleapis.com पर होस्ट किया जाता है और हमारे फ़ॉन्ट संसाधन Gstatic पर होस्ट किए जाते हैं. इससे काफ़ी असर पड़ सकता है. इसलिए, हमने इस ऑप्टिमाइज़ेशन को लागू किया और कुछ सौ मिलीसेकंड किए.
Lighthouse अगली चीज़ के बारे में सुझाव देता है कि हम मुख्य अनुरोधों को पहले से लोड कर लेते हैं.
<link rel=preload> बहुत असरदार है. यह ब्राउज़र को बताता है कि मौजूदा नेविगेशन के लिए एक रिसॉर्स की ज़रूरत है. साथ ही, यह ब्राउज़र को जल्द से जल्द इसे फ़ेच करने की कोशिश करता है.
अब लाइटहाउस हमें बता रहा है कि हमें अपने मुख्य वेब फ़ॉन्ट संसाधनों को पहले से लोड करके लोड करना चाहिए, क्योंकि हम दो वेब फ़ॉन्ट लोड कर रहे हैं.
वेब फ़ॉन्ट में पहले से लोड करने की प्रोसेस कुछ इस तरह दिखती है - इसमें rel=preload के बारे में बताया गया है. आपको as को फ़ॉन्ट के टाइप के साथ पास करना होता है. इसके बाद, आपको उस फ़ॉन्ट का टाइप तय करना होता है जिसे आपको लोड करने की कोशिश करनी है, जैसे कि woff2.
इसका आपके पेज पर बहुत ज़्यादा असर हो सकता है.
आम तौर पर, अगर लिंक rel प्रीलोड का इस्तेमाल किए बिना वेब फ़ॉन्ट आपके पेज के लिए अहम हैं, तो ब्राउज़र को सबसे पहले आपका एचटीएमएल फ़ेच करना होगा, सीएसएस को पार्स करना होगा, और थोड़ी देर बाद में, आपके वेब फ़ॉन्ट को फ़ेच करना होगा.
लिंक rel प्रीलोड का इस्तेमाल करके, जैसे ही ब्राउज़र आपके एचटीएमएल को पार्स कर देता है, वह पहले ही उन वेब फ़ॉन्ट को फ़ेच करना शुरू कर देता है. हमारे ऐप्लिकेशन के मामले में, इसने हमारे वेब फ़ॉन्ट का इस्तेमाल करके टेक्स्ट रेंडर करने में लगने वाले समय को एक सेकंड के लिए कम किया.
अगर आप Google Fonts का इस्तेमाल करके फ़ॉन्ट को पहले से लोड करने की कोशिश कर रहे हैं, तो यह आसान नहीं है.
हम अपनी स्टाइलशीट में अपने फ़ॉन्ट फ़ेस पर Google फ़ॉन्ट के जिन यूआरएल के बारे में बताते हैं वे कुछ ऐसा है जिसे फ़ॉन्ट की टीम नियमित रूप से अपडेट करती है. इन यूआरएल की समयसीमा खत्म हो सकती है या ये नियमित फ़्रीक्वेंसी पर अपडेट हो सकते हैं. इसलिए, अगर आपको फ़ॉन्ट लोड करने के अपने अनुभव पर पूरा कंट्रोल चाहिए, तो हमारा सुझाव है कि आप अपने वेब फ़ॉन्ट को खुद होस्ट करें. यह बहुत अच्छा हो सकता है, क्योंकि इससे आपको कई चीज़ों का ऐक्सेस मिलता है, जैसे कि लिंक को पहले से लोड करने की सुविधा.
हमारे मामले में, हमने पाया कि 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');
}
फ़ॉन्ट डिसप्ले की मदद से यह तय किया जा सकता है कि वेब फ़ॉन्ट किस तरह रेंडर होंगे या उस पर कम समय में लागू होंगे. यह इस बात पर निर्भर करता है कि उन्हें स्वैप करने में कितना समय लगता है.
इस मामले में, हम फ़ॉन्ट डिसप्ले बदलने के विकल्प का इस्तेमाल कर रहे हैं. स्वैप करने से, फ़ॉन्ट फ़ेस को शून्य सेकंड का ब्लॉक पीरियड और इनफ़ाइनाइट स्वैप पीरियड मिलता है. इसका मतलब है कि अगर फ़ॉन्ट लोड होने में थोड़ा समय लगता है, तो ब्राउज़र, फ़ॉलबैक फ़ॉन्ट के साथ आपके टेक्स्ट को तुरंत ड्रॉ कर देगा. और फ़ॉन्ट फ़ेस उपलब्ध होने पर इसे बदल दिया जाएगा.
हमारे ऐप्लिकेशन के मामले में, यह सबसे अच्छा क्यों था कि इसने हमें कुछ उपयोगी टेक्स्ट को बहुत पहले ही दिखाने और तैयार होने के बाद वेब फ़ॉन्ट पर ट्रांज़िशन करने की अनुमति दे दी.
आम तौर पर, अगर वेब फ़ॉन्ट का इस्तेमाल किया जा रहा है, तो वेब फ़ॉन्ट का एक बड़ा हिस्सा इस्तेमाल करने पर, वेब फ़ॉन्ट लोड करने की बेहतर रणनीति बनाई जा सकती है.
वेब प्लैटफ़ॉर्म की ऐसी कई सुविधाएं हैं जिनका इस्तेमाल करके, फ़ॉन्ट का पेज लोड करने के अनुभव को बेहतर बनाया जा सकता है. हालांकि, ज़ैक लेदरमैन का वेब फ़ॉन्ट रेसिपी रेपो भी देखें, क्योंकि यह वाकई बहुत बढ़िया है.
रेंडर ब्लॉक करने वाली स्क्रिप्ट को कम करें
ऐप्लिकेशन के ऐसे कई हिस्से हैं जिन्हें हम शुरुआत में डाउनलोड चेन में बता सकते थे, ताकि उपयोगकर्ताओं को कम से कम कुछ बुनियादी अनुभव दिया जा सके.
लाइटहाउस टाइमलाइन स्ट्रिप पर आप देख सकते हैं कि सभी संसाधन लोड होने के दौरान इन शुरुआती कुछ सेकंड में, उपयोगकर्ता वास्तव में कोई भी सामग्री नहीं देख सकता.
बाहरी स्टाइलशीट को डाउनलोड और प्रोसेस करने से, हमारी रेंडरिंग प्रोसेस कोई भी प्रोग्रेस नहीं कर पा रही है.
हम कुछ स्टाइल को थोड़ा पहले बनाकर, अपने अहम रेंडरिंग पाथ को ऑप्टिमाइज़ करने की कोशिश कर सकते हैं.
अगर हम इस शुरुआती रेंडर के लिए ज़िम्मेदार स्टाइल को निकालते हैं और उन्हें अपने एचटीएमएल में इनलाइन करते हैं, तो ब्राउज़र बाहरी स्टाइलशीट के आने का इंतज़ार किए बिना उन्हें सीधे रेंडर कर सकता है.
इस मामले में, हमने बिल्ड चरण के दौरान, index.html में मौजूद अपने अहम कॉन्टेंट को इनलाइन करने के लिए, ज़रूरी नाम के एनपीएम मॉड्यूल का इस्तेमाल किया.
हालांकि, इस मॉड्यूल ने हमारा ज़्यादातर काम आसान कर दिया, फिर भी अलग-अलग रास्तों पर इस तरीके को आसानी से काम करना थोड़ा पेचीदा था.
अगर आपने सावधानी बरतनी नहीं है या आपकी साइट की बनावट बहुत जटिल है, तो अगर आपने शुरू से ही ऐप्लिकेशन शेल आर्किटेक्चर के बारे में योजना नहीं बनाई है, तो इस तरह के पैटर्न को लागू करना बहुत मुश्किल हो सकता है.
इसलिए, परफ़ॉर्मेंस पर ध्यान देना बहुत ज़रूरी है. अगर शुरुआत से परफ़ॉर्मेंस के लिए डिज़ाइन तैयार नहीं किया जाता है, तो हो सकता है कि बाद में आपको ऐसा करने में समस्याएं आएं.
आखिर में, हमारा जो जोखिम था उससे हम काम कर पाए और ऐप्लिकेशन ने पहले से ही कॉन्टेंट डिलीवर करना शुरू कर दिया. इससे हमें पहले काम के पेंट करने में काफ़ी मदद मिली.
नतीजा
यह हमारी साइट पर लागू किए गए परफ़ॉर्मेंस ऑप्टिमाइज़ेशन की एक लंबी सूची थी. आइए, नतीजों पर एक नज़र डालें. इसी तरह हमारा ऐप्लिकेशन ऑप्टिमाइज़ेशन से पहले और बाद में, किसी 3G नेटवर्क पर एक मीडियम मोबाइल डिवाइस पर लोड हुआ.
लाइटहाउस परफ़ॉर्मेंस स्कोर 23 से बढ़कर 91 हो गया है. यह स्पीड के हिसाब से काफ़ी अच्छी प्रोग्रेस है. इन सभी बदलावों की वजह से, हमने लाइटहाउस की रिपोर्ट की लगातार जांच की और उसका पालन किया. अगर आपको यह देखना है कि हमने सभी सुधारों को तकनीकी रूप से कैसे लागू किया है, तो हमारे डेटा स्टोर करने की जगह पर नज़र डालें, खास तौर पर उन पीआरओ पर जो इसका इस्तेमाल करती हैं.
अनुमानित परफ़ॉर्मेंस - डेटा पर आधारित उपयोगकर्ता अनुभव
हमारा मानना है कि मशीन लर्निंग कई क्षेत्रों में भविष्य के लिए बहुत ही रोमांचक अवसर है. हमें उम्मीद है कि आने वाले समय में, इस पर और प्रयोग किए जाएंगे. वह यह है कि असली डेटा से, उपयोगकर्ताओं के अनुभव को बेहतर बनाने में मदद मिल सकती है.
आज-कल हम यह तय करते हैं कि लोगों को क्या चाहिए या क्या चाहिए. ऐसे में, हम किस तरह के डेटा को प्रीफ़ेच कर सकते हैं, पहले से लोड कर सकते हैं या पहले से कैश मेमोरी में सेव कर सकते हैं, यह तय करने के लिए हम कई तरह के फ़ैसले लेते हैं. अगर हमें सही लगता है, तो हम कुछ संसाधनों को प्राथमिकता दे पाते हैं लेकिन इसे पूरी वेबसाइट पर लागू करना बहुत मुश्किल होता है.
दरअसल, हमारे पास आज डेटा उपलब्ध है, ताकि हम अपने ऑप्टिमाइज़ेशन को बेहतर तरीके से समझ सकें. Google Analytics reporting API का इस्तेमाल करके, हम अगले सबसे लोकप्रिय पेज पर नज़र डालते हैं और अपनी साइट के किसी भी यूआरएल के प्रतिशत से बाहर निकल सकते हैं. इस तरह, हम इस आधार पर नतीजा निकाल सकते हैं कि हमें किन संसाधनों को प्राथमिकता देनी चाहिए.
अगर हम इसे अच्छे संभावना मॉडल के साथ जोड़ते हैं, तो हम कॉन्टेंट को बार-बार प्रीफ़ेच करके अपने उपयोगकर्ता का डेटा बर्बाद होने से बचाते हैं. हम Google Analytics के उस डेटा का फ़ायदा उठा सकते हैं. साथ ही, इस तरह के मॉडल को लागू करने के लिए, मार्कोव चेन या न्यूरल नेटवर्क जैसे मशीन लर्निंग और मॉडल का इस्तेमाल कर सकते हैं.
इस एक्सपेरिमेंट को आसान बनाने के लिए, हमें एक नई पहल का एलान करते हुए खुशी हो रही है. अब इसका नाम Guess.js है.
Guess.js एक प्रोजेक्ट है, जो वेब के लिए डेटा पर आधारित उपयोगकर्ता अनुभव पर फ़ोकस करता है. हमें उम्मीद है कि इससे वेब की परफ़ॉर्मेंस को बेहतर बनाने के लिए डेटा का इस्तेमाल करने की एक्सप्लोरेशन के लिए प्रेरणा मिलेगी. साथ ही, इससे आगे भी बहुत कुछ होगा. ये सभी ओपन सोर्स ओपन सोर्स हैं और आज GitHub पर उपलब्ध हैं. इसे मिंको गेचेव, गैट्सबी के कायल मैथ्यूज़, केटी हेम्पेनियस, और कई दूसरे लोगों ने ओपन सोर्स कम्यूनिटी के सहयोग से बनाया था.
Guess.js देखें और हमें अपने अनुभव के बारे में बताएं.
खास जानकारी
स्कोर और मेट्रिक से वेब की स्पीड को बेहतर बनाने में मदद मिलती है. हालांकि, ये लक्ष्य तो हैं, इनका मतलब नहीं.
हम सभी को कभी-कभी पेजों के लोड होने में ज़्यादा समय लगने की समस्या का सामना करना पड़ा है. हालांकि, अब हमारे पास उपयोगकर्ताओं को तेज़ी से लोड होने वाले पेजों का ज़्यादा दिलचस्प अनुभव देने का मौका है.
परफ़ॉर्मेंस को बेहतर बनाना बेहद ज़रूरी है. छोटे-छोटे बदलाव करने से, आपको काफ़ी फ़ायदा हो सकता है. सही ऑप्टिमाइज़ेशन टूल का इस्तेमाल करके और Lighthouse रिपोर्ट पर नज़र रखकर, अपने उपयोगकर्ताओं को बेहतर और सभी के लिए बेहतर अनुभव दिया जा सकता है.
इनके खास धन्यवाद के साथ: वॉर्ड पीटर्स, मिंको गेचेव, कायल मैथ्यूज़, केटी हेम्पेनियस, डॉम फ़ैरोलिनो, योव वीस, सूसी लू, युसुके उत्सुनोमिया, टॉम एंकर्स, लाइटहाउस, और Google डूडल.