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, Unminified CSS & JavaScript audit में इस अवसर को हाइलाइट करता है. हम अपनी बिल्ड प्रोसेस के लिए webpack का इस्तेमाल कर रहे थे. इसलिए, फ़ाइल को छोटा करने के लिए हमने Uglify JS प्लगिन का इस्तेमाल किया.
कोड छोटा करना एक सामान्य टास्क है. इसलिए, आपको अपनी बिल्ड प्रोसेस के लिए, पहले से तैयार समाधान मिल सकता है.
उस स्पेस में एक और काम का ऑडिट, टेक्स्ट कंप्रेस करने की सुविधा चालू करें है. बिना कंप्रेस की गई फ़ाइलें भेजने की कोई वजह नहीं है. साथ ही, आजकल ज़्यादातर सीडीएन इस सुविधा के साथ काम करते हैं.
हम अपने कोड को होस्ट करने के लिए Firebase Hosting का इस्तेमाल कर रहे थे. Firebase में gzipping की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इसलिए, हमने अपने कोड को एक सही सीडीएन पर होस्ट करके, इस सुविधा का इस्तेमाल बिना किसी शुल्क के किया.
gzip, कंप्रेस करने का एक बहुत ही लोकप्रिय तरीका है. हालांकि, Zopfli और Brotli जैसे अन्य तरीके भी लोकप्रिय हो रहे हैं. Brotli को ज़्यादातर ब्राउज़र पर इस्तेमाल किया जा सकता है. साथ ही, सर्वर पर ऐसेट भेजने से पहले, उन्हें पहले से कंप्रेस करने के लिए बाइनरी का इस्तेमाल किया जा सकता है.
कैश मेमोरी से जुड़ी बेहतर नीतियों का इस्तेमाल करना
हमारा अगला कदम यह पक्का करना था कि हम बिना किसी वजह के संसाधनों को दो बार न भेजें.
Lighthouse में कैश मेमोरी को मैनेज करने से जुड़ी नीति सही तरीके से लागू नहीं की गई है ऑडिट से हमें पता चला कि हम कैश मेमोरी को मैनेज करने से जुड़ी रणनीतियों को ऑप्टिमाइज़ कर सकते हैं, ताकि हम ठीक वैसा ही कर सकें. हमने अपने सर्वर में max-age expiration हेडर सेट किया है. इससे यह पक्का होता है कि बार-बार विज़िट करने पर, उपयोगकर्ता उन संसाधनों का फिर से इस्तेमाल कर सकता है जिन्हें उसने पहले डाउनलोड किया था.
हमारा सुझाव है कि आप ज़्यादा से ज़्यादा संसाधनों को सुरक्षित तरीके से कैश करें. साथ ही, उन्हें लंबे समय तक कैश में रखें. इसके अलावा, अपडेट किए गए संसाधनों को फिर से मान्य करने के लिए, पुष्टि करने वाले टोकन उपलब्ध कराएं.
इस्तेमाल न होने वाले कोड हटा दें
अब तक हमने ग़ैर-ज़रूरी डाउनलोड के मुख्य हिस्से हटा दिए हैं, लेकिन कम ज़रूरी हिस्सों का क्या होगा? उदाहरण के लिए, इस्तेमाल न किया गया कोड.
कभी-कभी हम अपने ऐप्लिकेशन में ऐसा कोड शामिल करते हैं जिसकी ज़रूरत नहीं होती. ऐसा खास तौर पर तब होता है, जब किसी ऐप्लिकेशन पर लंबे समय तक काम किया जाता है, आपकी टीम या आपकी डिपेंडेंसी बदल जाती हैं. साथ ही, कभी-कभी कोई अनाथ लाइब्रेरी पीछे छूट जाती है. हमारे साथ भी ऐसा ही हुआ.
शुरुआत में, हमने अपने ऐप्लिकेशन का प्रोटोटाइप जल्दी बनाने के लिए, Material Components लाइब्रेरी का इस्तेमाल किया था. समय के साथ, हमने अपने ऐप्लिकेशन को ज़्यादा कस्टम लुक और फ़ील दिया. इस वजह से, हम उस लाइब्रेरी के बारे में पूरी तरह से भूल गए. अच्छी बात यह है कि कोड कवरेज की जांच से, हमें अपने बंडल में इसे फिर से ढूंढने में मदद मिली.
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 है. इसलिए, यह काफ़ी ज़्यादा है.
इसके बाद, हमने अपने एडिटर पर जाकर, Visual Studio Code के लिए इंपोर्ट कॉस्ट प्लगिन का इस्तेमाल किया. इससे हमें इंपोर्ट किए जा रहे हर मॉड्यूल की लागत को विज़ुअलाइज़ करने में मदद मिली. इससे हमें यह पता चला कि कौनसे कॉम्पोनेंट में ऐसा कोड शामिल है जो इस मॉड्यूल को रेफ़रंस कर रहा है.
इसके बाद, हमने BundlePhobia नाम के दूसरे टूल का इस्तेमाल किया. यह एक टूल है. इसकी मदद से, किसी भी NPM पैकेज का नाम डाला जा सकता है. साथ ही, यह देखा जा सकता है कि उसका छोटा किया गया और gzip किया गया साइज़ कितना है. हमें स्लग मॉड्यूल का एक अच्छा विकल्प मिला है. इसका साइज़ सिर्फ़ 2.2 केबी है. इसलिए, हमने इसका इस्तेमाल शुरू कर दिया है.
इससे हमारी परफ़ॉर्मेंस पर काफ़ी असर पड़ा. इस बदलाव और JavaScript बंडल के साइज़ को कम करने के अन्य अवसरों का पता लगाने के बीच, हमने 2.1 एमबी का कोड सेव किया.
इन बंडलों के कंप्रेस किए गए और छोटे किए गए साइज़ को ध्यान में रखने पर, हमें कुल मिलाकर 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-libs-optimizations रिपॉज़िटरी देखें. इसमें कुछ आइडिया दिए गए हैं. इनकी मदद से, अगर webpack का इस्तेमाल किया जा रहा है, तो अपनी लाइब्रेरी का साइज़ कम किया जा सकता है.
चित्र अनुकूलित करें
Oodle ऐप्लिकेशन में, हम कई इमेज इस्तेमाल कर रहे हैं. माफ़ करें, लेकिन Lighthouse को यह सुविधा उतनी पसंद नहीं आई जितनी हमें आई. असल में, हम इमेज से जुड़ी तीनों ऑडिट में फ़ेल हो गए.
हम अपनी इमेज को ऑप्टिमाइज़ करना भूल गए थे. हमने उन्हें सही साइज़ में नहीं रखा था. साथ ही, हमें इमेज के अन्य फ़ॉर्मैट का इस्तेमाल करने से भी कुछ फ़ायदा मिल सकता था.
हमने अपनी इमेज को ऑप्टिमाइज़ करना शुरू किया.
एक बार ऑप्टिमाइज़ करने के लिए, ImageOptim या XNConvert जैसे विज़ुअल टूल का इस्तेमाल किया जा सकता है.
इमेज ऑप्टिमाइज़ेशन की प्रोसेस को ज़्यादा ऑटोमेट करने के लिए, अपनी बिल्ड प्रोसेस में इमेज ऑप्टिमाइज़ेशन का चरण जोड़ें. इसके लिए, imagemin जैसी लाइब्रेरी का इस्तेमाल करें.
इससे यह पक्का किया जा सकता है कि आने वाले समय में जोड़ी गई इमेज अपने-आप ऑप्टिमाइज़ हो जाएं. कुछ सीडीएन, जैसे कि Akamai या तीसरे पक्ष के समाधान, जैसे कि Cloudinary, Fastly या Uploadcare, आपको इमेज ऑप्टिमाइज़ करने के बेहतर समाधान उपलब्ध कराते हैं. इसलिए, उन सेवाओं पर अपनी इमेज आसानी से होस्ट की जा सकती हैं.
अगर आपको लागत या इंतज़ार के समय से जुड़ी समस्याओं की वजह से ऐसा नहीं करना है, तो Thumbor या Imageflow जैसे प्रोजेक्ट, खुद होस्ट किए गए विकल्प उपलब्ध कराते हैं.
webpack में, हमारी बैकग्राउंड पीएनजी को बड़ी फ़ाइल के तौर पर फ़्लैग किया गया था. यह सही था. व्यूपोर्ट के हिसाब से इसका साइज़ सही करने और इसे 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, 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"/>
Lazysizes एक स्मार्ट लाइब्रेरी है. यह न सिर्फ़ एलिमेंट की दिखने की स्थिति में होने वाले बदलावों को ट्रैक करती है, बल्कि उपयोगकर्ता के बेहतर अनुभव के लिए, व्यू के आस-पास मौजूद एलिमेंट को पहले से ही प्रीफ़ेच भी करती है.
यह IntersectionObserver को इंटिग्रेट करने का विकल्प भी देता है. इससे आपको बहुत कम समय में, विज्ञापन दिखने से जुड़ी जानकारी मिल जाती है.
इस बदलाव के बाद, हमारी इमेज को मांग पर फ़ेच किया जा रहा है. अगर आपको इस विषय के बारे में ज़्यादा जानकारी चाहिए, तो images.guide पर जाएं. यह एक बहुत ही उपयोगी और पूरी जानकारी देने वाला संसाधन है.
ब्राउज़र को ज़रूरी संसाधन पहले डिलीवर करने में मदद करता है
ब्राउज़र को भेजे गए हर बाइट का महत्व एक जैसा नहीं होता. ब्राउज़र को इस बारे में पता होता है. कई ब्राउज़र में, यह तय करने के लिए ह्यूरिस्टिक्स होते हैं कि उन्हें सबसे पहले क्या फ़ेच करना चाहिए. इसलिए, कभी-कभी वे इमेज या स्क्रिप्ट से पहले सीएसएस फ़ेच करते हैं.
पेज के लेखक के तौर पर, हम ब्राउज़र को यह बता सकते हैं कि हमारे लिए कौनसी चीज़ ज़्यादा ज़रूरी है. अच्छी बात यह है कि पिछले कुछ सालों में, ब्राउज़र वेंडर ने इस काम में हमारी मदद करने के लिए कई सुविधाएं जोड़ी हैं. जैसे, संसाधन के बारे में जानकारी देने वाले निर्देश, जैसे कि link rel=preconnect, preload या prefetch.
वेब प्लैटफ़ॉर्म पर लाई गई इन सुविधाओं से, ब्राउज़र को सही समय पर सही चीज़ें फ़ेच करने में मदद मिलती है. साथ ही, ये स्क्रिप्ट का इस्तेमाल करके किए जाने वाले कस्टम लोडिंग और लॉजिक पर आधारित कुछ तरीकों से ज़्यादा असरदार हो सकती हैं.
आइए, देखते हैं कि Lighthouse हमें इन सुविधाओं को बेहतर तरीके से इस्तेमाल करने के लिए कैसे गाइड करता है.
Lighthouse हमें सबसे पहले यह सलाह देता है कि किसी भी ऑरिजिन पर कई बार राउंड ट्रिप करने से बचें.
Oodle ऐप्लिकेशन के मामले में, हम Google Fonts का बड़े पैमाने पर इस्तेमाल कर रहे हैं. जब भी अपने पेज में Google फ़ॉन्ट की स्टाइलशीट जोड़ी जाती है, तो यह दो सबडोमेन से कनेक्ट हो जाती है. Lighthouse हमें बता रहा है कि अगर हम उस कनेक्शन को वार्म अप कर पाते हैं, तो हम शुरुआती कनेक्शन के समय में 300 मिलीसेकंड तक की बचत कर सकते हैं.
लिंक rel preconnect का फ़ायदा उठाकर, हम कनेक्शन में लगने वाले समय को छिपा सकते हैं.
खास तौर पर, Google Fonts जैसे प्लैटफ़ॉर्म पर इसका काफ़ी असर पड़ सकता है. यहां हमारे फ़ॉन्ट फ़ेस की सीएसएस, googleapis.com पर होस्ट की जाती है. साथ ही, हमारे फ़ॉन्ट के संसाधन Gstatic पर होस्ट किए जाते हैं. इसलिए, हमने इस ऑप्टिमाइज़ेशन को लागू किया और कुछ सौ मिलीसेकंड कम कर दिए.
Lighthouse का अगला सुझाव यह है कि हम मुख्य अनुरोधों को प्रीलोड करें.
<link rel=preload> एक बहुत ही असरदार टैग है. यह ब्राउज़र को बताता है कि मौजूदा नेविगेशन के लिए किसी संसाधन की ज़रूरत है. साथ ही, यह ब्राउज़र को उस संसाधन को जल्द से जल्द फ़ेच करने के लिए कहता है.
अब Lighthouse हमें बता रहा है कि हमें अपने मुख्य वेब फ़ॉन्ट संसाधनों को प्रीलोड करना चाहिए, क्योंकि हम दो वेब फ़ॉन्ट लोड कर रहे हैं.
वेब फ़ॉन्ट में प्रीलोडिंग इस तरह दिखती है - rel=preload तय करके, as में फ़ॉन्ट का टाइप पास किया जाता है. इसके बाद, आपको उस फ़ॉन्ट का टाइप तय करना होता है जिसे लोड करना है. जैसे, woff2.
इससे आपके पेज पर काफ़ी असर पड़ सकता है.
आम तौर पर, लिंक rel preload का इस्तेमाल किए बिना, अगर वेब फ़ॉन्ट आपके पेज के लिए ज़रूरी हैं, तो ब्राउज़र को सबसे पहले आपके एचटीएमएल को फ़ेच करना होगा. इसके बाद, उसे आपके सीएसएस को पार्स करना होगा. इसके बाद, वह आपके वेब फ़ॉन्ट को फ़ेच करेगा.
लिंक rel प्रीलोड का इस्तेमाल करने पर, ब्राउज़र आपके एचटीएमएल को पार्स करने के तुरंत बाद, उन वेब फ़ॉन्ट को फ़ेच करना शुरू कर सकता है. हमारे ऐप्लिकेशन के मामले में, इससे हमें वेब फ़ॉन्ट का इस्तेमाल करके टेक्स्ट रेंडर करने में लगने वाले समय में एक सेकंड की बचत हुई.
अगर Google Fonts का इस्तेमाल करके फ़ॉन्ट को पहले से लोड करने की कोशिश की जाती है, तो यह इतना आसान नहीं है. इसमें एक समस्या है.
Google फ़ॉन्ट के जिन यूआरएल को हम अपनी स्टाइलशीट में फ़ॉन्ट फ़ेस के तौर पर तय करते हैं उन्हें फ़ॉन्ट टीम, नियमित तौर पर अपडेट करती है. ये यूआरएल खत्म हो सकते हैं या इन्हें नियमित तौर पर अपडेट किया जा सकता है. इसलिए, हमारा सुझाव है कि अगर आपको फ़ॉन्ट लोड करने की प्रोसेस पर पूरा कंट्रोल चाहिए, तो अपने वेब फ़ॉन्ट को खुद होस्ट करें. यह बहुत अच्छा हो सकता है, क्योंकि इससे आपको लिंक rel प्रीलोड जैसी चीज़ों का ऐक्सेस मिलता है.
हमें Google Web Fonts Helper टूल बहुत मददगार लगा. इसकी मदद से, हमने कुछ वेब फ़ॉन्ट को ऑफ़लाइन किया और उन्हें स्थानीय तौर पर सेट अप किया. इसलिए, इस टूल को आज़माएं.
चाहे वेब फ़ॉन्ट का इस्तेमाल क्रिटिकल रिसॉर्स के तौर पर किया जा रहा हो या JavaScript का, ब्राउज़र को क्रिटिकल रिसॉर्स जल्द से जल्द डिलीवर करने में मदद करें.
एक्सपेरिमेंट के तौर पर: प्राथमिकता के बारे में जानकारी देने वाले हिंट
आज हमें आपके साथ कुछ खास शेयर करना है. हम ब्राउज़र के लिए, एक्सपेरिमेंट के तौर पर एक नई सुविधा पर काम कर रहे हैं. इसे प्राथमिकता के बारे में जानकारी देने वाली सुविधा कहा जाता है. इसके अलावा, हम संसाधन के बारे में जानकारी देने वाली सुविधा और प्रीलोड जैसी सुविधाओं पर भी काम कर रहे हैं.
यह एक नई सुविधा है. इसकी मदद से, ब्राउज़र को यह बताया जा सकता है कि कोई संसाधन कितना ज़रूरी है. यह एक नया एट्रिब्यूट - अहमियत - दिखाता है. इसकी वैल्यू कम, ज़्यादा या अपने-आप सेट होने वाली होती है.
इससे हमें कम ज़रूरी संसाधनों की प्राथमिकता कम करने में मदद मिलती है. जैसे, गैर-ज़रूरी स्टाइल, इमेज या फ़ेच एपीआई कॉल. इससे विवाद कम करने में मदद मिलती है. हम ज़्यादा ज़रूरी चीज़ों को भी प्राथमिकता दे सकते हैं. जैसे, हमारी हीरो इमेज.
हमारे 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 नाम के NPM मॉड्यूल का इस्तेमाल किया है. इससे हमें बिल्ड स्टेप के दौरान, index.html में ज़रूरी कॉन्टेंट को इनलाइन करने में मदद मिली.
इस मॉड्यूल ने हमारे लिए ज़्यादातर काम कर दिया था. हालांकि, अलग-अलग रास्तों पर इसे आसानी से लागू करना अब भी थोड़ा मुश्किल था.
अगर आपने ध्यान नहीं दिया या आपकी साइट का स्ट्रक्चर बहुत जटिल है, तो इस तरह के पैटर्न को लागू करना बहुत मुश्किल हो सकता है. ऐसा तब होगा, जब आपने शुरू से ही ऐप्लिकेशन शेल आर्किटेक्चर को लागू करने का प्लान नहीं बनाया होगा.
इसलिए, परफ़ॉर्मेंस से जुड़ी बातों पर शुरुआत में ही ध्यान देना बहुत ज़रूरी है. अगर आपने शुरुआत से ही परफ़ॉर्मेंस को ध्यान में रखकर डिज़ाइन नहीं किया है, तो बाद में ऐसा करने पर आपको समस्याएं आ सकती हैं.
आखिरकार, हमें इसका फ़ायदा मिला. हमने इसे काम करने लायक बना दिया और ऐप्लिकेशन ने बहुत पहले ही कॉन्टेंट डिलीवर करना शुरू कर दिया. इससे, फ़र्स्ट मीनिंगफ़ुल पेंट टाइम में काफ़ी सुधार हुआ.
नतीजा
यह हमारी साइट पर लागू किए गए परफ़ॉर्मेंस ऑप्टिमाइज़ेशन की लंबी सूची थी. आइए, नतीजे पर एक नज़र डालते हैं. यह इमेज दिखाती है कि ऑप्टिमाइज़ेशन से पहले और बाद में, 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 को आज़माएं और हमें बताएं कि आपको यह कैसा लगा.
खास जानकारी
स्कोर और मेट्रिक, वेब की स्पीड को बेहतर बनाने में मददगार होती हैं. हालांकि, ये सिर्फ़ साधन हैं, लक्ष्य नहीं.
हम सभी ने कभी न कभी, पेज लोड होने में समय लगने की समस्या का सामना किया है. हालांकि, अब हमारे पास अपने उपयोगकर्ताओं को बेहतर अनुभव देने का मौका है. इससे पेज बहुत तेज़ी से लोड होंगे.
परफ़ॉर्मेंस को बेहतर बनाना एक लंबी प्रोसेस है. छोटे-छोटे कई बदलावों से, बड़े फ़ायदे मिल सकते हैं. सही ऑप्टिमाइज़ेशन टूल का इस्तेमाल करके और Lighthouse की रिपोर्ट पर नज़र रखकर, अपने उपयोगकर्ताओं को बेहतर और ज़्यादा समावेशी अनुभव दिया जा सकता है.
इन लोगों का हम दिल से शुक्रिया अदा करते हैं: वार्ड पीटर्स, मिंको गेचेव, काइल मैथ्यूज़, केटी हेम्पिनियस, डोम फ़ारोलिनो, योआव वेइस, सूज़ी लू, युसुके उत्सुनोमिया, टॉम ऐंकर्स, लाइटहाउस, और Google डूडल.