Lighthouse अपने-आप काम करने वाला टूल है. इसे आपकी साइट की क्वालिटी को बेहतर बनाने के लिए इस्तेमाल किया जाता है. इसे यूआरएल दिया जाता है. इसके बाद, यह पेज की परफ़ॉर्मेंस को बेहतर बनाने, पेजों को ज़्यादा ऐक्सेस करने लायक बनाने, सबसे सही तरीकों का पालन करने वगैरह के बारे में सुझावों की सूची दिखाता है. इसे Chrome DevTools के तौर पर, Chrome एक्सटेंशन के तौर पर या नोड मॉड्यूल के तौर पर चलाया जा सकता है. यह लगातार इंटिग्रेशन करने में मदद करता है.
कुछ समय से, Lighthouse ने पेज लोड की परफ़ॉर्मेंस को बेहतर बनाने के लिए कई सुझाव दिए हैं. जैसे, टेक्स्ट को कंप्रेस करने की सुविधा चालू करना या रेंडर ब्लॉक करने वाली स्क्रिप्ट को कम करना. Lighthouse टीम लगातार नए ऑडिट भेजती है, ताकि आपको अपनी साइट को तेज़ बनाने के लिए और ज़्यादा काम की सलाह दी जा सके. यह पोस्ट उपयोगी परफ़ॉर्मेंस ऑडिट का राउंडअप है, जिनके बारे में आपको शायद जानकारी नहीं है, जैसे:
- मुख्य थ्रेड के काम का ब्रेकडाउन
- मुख्य अनुरोध पहले से लोड करने की सुविधा
- JavaScript के चालू होने में ज़्यादा समय लग रहा है
- पेज रीडायरेक्ट से बचा जाता है
- इस्तेमाल नहीं किया गया JavaScript
- स्टैटिक ऐसेट के लिए, कैश मेमोरी से जुड़ी नीति का इस्तेमाल नहीं किया जा सकता
- किसी भी जगह जाने के लिए, एक से ज़्यादा दोतरफ़ा यात्रा करने से बचें
- ऐनिमेट किए गए कॉन्टेंट के लिए वीडियो फ़ॉर्मैट इस्तेमाल करना
- वेबफ़ॉन्ट लोड होने के दौरान, सभी टेक्स्ट दिखते रहते हैं
- सामान्य सीएसएस और JavaScript
- सीएसएस के ऐसे नियम जो इस्तेमाल नहीं किए गए हैं
मुख्य थ्रेड के काम का ब्रेकडाउन
अगर आपने कभी भी DevTools में परफ़ॉर्मेंस पैनल का इस्तेमाल किया है, तो आपको यह जानकारी मिल सकती है कि किसी पेज को लोड करने में, सीपीयू समय में कितना समय लगा. यह आपके लिए काफ़ी मुश्किल काम हो सकता है. हमें यह बताते हुए खुशी हो रही है कि मुख्य थ्रेड के काम का ब्रेकडाउन ऑडिट के ज़रिए, अब यह जानकारी आसानी से और आसानी से उपलब्ध है.
इस नई डाइग्नोस्टिक्स से पता चलता है कि पेज लोड होने के दौरान कितनी और किस तरह की गतिविधि होती है. इससे लेआउट, स्क्रिप्ट की परफ़ॉर्मेंस, पार्स करने, और अन्य गतिविधि से जुड़ी लोडिंग परफ़ॉर्मेंस की समस्याओं को हैंडल करने में मदद मिलती है.
मुख्य अनुरोधों को पहले से लोड करें
जब ब्राउज़र, रिसॉर्स को इकट्ठा करते हैं, तो वे ऐसा इसलिए करते हैं, क्योंकि उन्हें दस्तावेज़ और उसके सबरिसॉर्स में उनके रेफ़रंस
मिल जाते हैं. इस स्थिति में कई बार खराब नतीजे मिल सकते हैं, क्योंकि कुछ ज़रूरी रिसॉर्स, पेज लोड होने की प्रोसेस में देर से मिलते हैं. अच्छी बात यह है कि rel=preload
डेवलपर को यह बताने में मदद करता है कि कौनसे संसाधन जल्द से जल्द फ़ेच किए जाएं.
इसके लिए, ज़रूरी है कि डेवलपर उन ब्राउज़र को सुझाव दें जो नीति का पालन करते हों. पहले से लोड किए जाने वाले मुख्य अनुरोध के नए ऑडिट से, डेवलपर को यह पता चलता है कि rel=preload से पहले लोड किए जाने से किन संसाधनों को फ़ायदा मिल सकता है.
यह बहुत ज़रूरी है कि आप rel=preload के साथ और इसके बिना, परफ़ॉर्मेंस में होने वाले बदलावों की जांच और उनकी तुलना करें. इससे, लोड होने की परफ़ॉर्मेंस पर असर पड़ सकता है और ऐसा हो सकता है कि आप इसकी उम्मीद न करें. उदाहरण के लिए, किसी बड़ी इमेज को पहले से लोड करने से शुरुआती रेंडर में देरी हो सकती है, लेकिन
समस्या यह है कि पहले से लोड की गई इमेज, लेआउट में जल्दी दिखेगी.
हमेशा पक्का करें कि आपको मिलने वाले नतीजे खुश हैं!
JavaScript चालू करने का समय ज़्यादा है
बहुत ज़्यादा JavaScript लोड होने पर, पेज काम नहीं कर सकता. ऐसा इसलिए होता है, क्योंकि ब्राउज़र उसे पार्स, कंपाइल, और एक्ज़ीक्यूट करता है. तीसरे पक्ष की स्क्रिप्ट और विज्ञापन, स्क्रिप्ट से जुड़ी बहुत ज़्यादा गतिविधि का एक खास सोर्स हैं. इनकी वजह से, बेहतरीन डिवाइस भी ठीक से काम नहीं करते. JavaScript के चालू होने में लगने वाला समय ज़्यादा है ऑडिट से पता चलता है कि किसी पेज पर मौजूद हर स्क्रिप्ट, सीपीयू का कितना इस्तेमाल करती है. साथ ही, उसका यूआरएल भी बताता है:
इस ऑडिट को चलाते समय, नेटवर्क पैनल में तीसरे पक्ष के बैज को चालू किया जा सकता है. साथ ही, तीसरे पक्ष के स्क्रिप्ट संसाधनों की पहचान करने के लिए, सूची को फ़िल्टर किया जा सकता है. इस ऑडिट से मिले डेटा की मदद से, आपको JavaScript से जुड़ी ज़्यादा गतिविधि वाले उन सोर्स का पता लगाने में मदद मिलेगी जो पेजों को स्नैप से बदलकर लेगिंग में बदल देते हैं. अपने ऐप्लिकेशन की खास स्क्रिप्ट के लिए, अपनी साइट के हर पेज पर JavaScript की संख्या को सीमित करने के लिए, कोड स्प्लिट करने और ट्री शेकिंग जैसी तकनीकों का इस्तेमाल किया जा सकता है.
पेज रीडायरेक्ट से बचें
कभी-कभी जब कोई ब्राउज़र यूआरएल के लिए अनुरोध करता है, तो सर्वर 300-लेवल वाले स्टेटस कोड के साथ जवाब दे सकता है. इससे ब्राउज़र किसी दूसरे यूआरएल पर रीडायरेक्ट हो जाता है. रीडायरेक्ट, एसईओ और सुविधा के लिए ज़रूरी होते हैं. हालांकि, इनसे अनुरोधों में इंतज़ार का समय बढ़ जाता है. खास तौर पर, ऐसा तब होता है, जब वे किसी दूसरे ऑरिजिन पर रीडायरेक्ट करते हैं. इससे अतिरिक्त डीएनएस लुकअप और कनेक्शन/TLS बातचीत में लगने वाला समय लग सकता है.
आपकी साइट के लैंडिंग पेजों के लिए, रीडायरेक्ट का होना ज़रूरी नहीं है. इंतज़ार का समय कम करने और पेज लोड होने की परफ़ॉर्मेंस को बेहतर बनाने के लिए, लाइटहाउस अब पेज रीडायरेक्ट से बचने का ऑडिट ऑफ़र करता है. इससे आपको पता चलता है कि कोई नेविगेशन कब किसी रीडायरेक्ट को ट्रिगर करता है.
ध्यान दें कि इस ऑडिट को Lighthouse के DevTools वर्शन में ट्रिगर करना मुश्किल है, क्योंकि यह पेज के पता बार में मौजूदा यूआरएल का विश्लेषण करता है, जो सभी रीडायरेक्ट के रिज़ॉल्यूशन को दिखाता है. आपको यह ऑडिट, नोड सीएलआई में अपने-आप दिख सकता है.
इस्तेमाल नहीं किया गया JavaScript
JavaScript से भरे ऐप्लिकेशन में डेड कोड एक गंभीर समस्या हो सकती है. हालांकि, इसे लागू करने का कोई शुल्क नहीं लिया जाता, क्योंकि इसे कभी लागू नहीं किया गया है. हालांकि, इसके कुछ अनचाहे असर भी होते हैं. मृत कोड को अब भी डाउनलोड किया जाता है, पार्स किया जाता है, और ब्राउज़र से कंपाइल किया जाता है. इससे, साइट लोड होने की परफ़ॉर्मेंस और JavaScript के चालू होने में लगने वाले समय पर असर पड़ता है. DevTools के कवरेज पैनल की तरह ही, इस्तेमाल नहीं किया गया JavaScript ऑडिट से यह पता चलता है कि JavaScript को मौजूदा पेज से डाउनलोड किया गया है, लेकिन इसका कभी इस्तेमाल नहीं किया गया.
इस ऑडिट की मदद से, अपने ऐप्लिकेशन में काम न करने वाले कोड की पहचान की जा सकती है. साथ ही, लोड होने की परफ़ॉर्मेंस को बेहतर बनाने और सिस्टम के रिसॉर्स इस्तेमाल को कम करने के लिए, उसे हटाया जा सकता है. पेशेवर सलाह: इस जानकारी को ढूंढने के लिए, Chrome के DevTools में कोड कवरेज पैनल का भी इस्तेमाल किया जा सकता है!
स्टैटिक ऐसेट के लिए, कैश मेमोरी से जुड़ी ऐसी नीति का इस्तेमाल करता है जो ठीक से काम नहीं करती
परफ़ॉर्मेंस से जुड़ी ज़्यादातर सलाह, वेबसाइट पर पहली बार आने वाले उपयोगकर्ताओं के लिए वेबसाइट की स्पीड बढ़ाने पर ज़ोर देती है. हालांकि, लौटने वाले उपयोगकर्ताओं के लोड होने की परफ़ॉर्मेंस को बेहतर बनाने के लिए, कैश मेमोरी में डेटा सेव करना भी ज़रूरी है. 'स्टैटिक ऐसेट के इस्तेमाल से जुड़ी कैश मेमोरी की नीति' ऑडिट, नेटवर्क रिसॉर्स के लिए कैश मेमोरी में सेव किए गए हेडर की जांच करता है. साथ ही, यह बताता है कि स्टैटिक रिसॉर्स के लिए कैश मेमोरी की नीतियां ठीक नहीं हैं.
इस ऑडिट की मदद से, कैश मेमोरी की मौजूदा नीति में समस्याओं को आसानी से ढूंढा जा सकता है और उन्हें ठीक किया जा सकता है. इससे लौटने वाले उपयोगकर्ताओं की परफ़ॉर्मेंस बहुत बेहतर होगी और वे इस अतिरिक्त प्रक्रिया की सराहना करेंगे!
किसी भी यात्रा की शुरुआत की जगहों को एक से ज़्यादा दोतरफ़ा यात्रा करने से बचें
जब ब्राउज़र किसी सर्वर से रिसॉर्स फ़ेच करते हैं, तो डीएनएस लुकअप करने और सर्वर से कनेक्ट होने में काफ़ी समय लग सकता है.
rel=preconnect, डेवलपर को इस इंतज़ार के समय को मास्क करने की अनुमति देता है. इसके लिए, वह ब्राउज़र के सही समय पर कनेक्ट होने से पहले, अन्य सर्वर से कनेक्ट करता है. एक से ज़्यादा जगहों की लागत से बचें
किसी भी शुरुआत की जगह पर दोतरफ़ा यात्रा ऑडिट से आपको
इस टूल को इस्तेमाल करने के अवसर खोजने में मदद मिलेगी
rel=preconnect!
rel=preconnect के लिए, ऑरिजिन की सूची का सुझाव दिया जाता है.जब क्रॉस-ऑरिजिन ऐसेट के लिए इंतज़ार का समय कम हो जाता है, तब उपयोगकर्ताओं को लगेगा कि चीज़ें
थोड़ी तेज़ी से हो रही हैं. इस नए लाइटहाउस ऑडिट से, आपको ऐसा करने के लिए rel=preconnect का इस्तेमाल करने के नए अवसरों के बारे में पता चलेगा.
ऐनिमेशन वाले कॉन्टेंट के लिए वीडियो फ़ॉर्मैट इस्तेमाल करें
ऐनिमेटेड GIF बड़ी होते हैं, जो अक्सर कम से कम कई सौ किलोबाइट प्रति सेकंड होते हैं, अगर डेटा कई मेगाबाइट नहीं होता. अगर आपको परफ़ॉर्मेंस लोड करने में कोई परेशानी नहीं है, तो इन GIF को वीडियो में बदलें. अच्छी बात यह है कि ऐनिमेट किए गए कॉन्टेंट के लिए वीडियो फ़ॉर्मैट इस्तेमाल करें ऑडिट में मदद मिलेगी.
अगर आपकी साइट पर 100 केबी से ज़्यादा का GIF है, तो यह ऑडिट उन्हें अपने-आप फ़्लैग करेगा. साथ ही, आपको उन्हें वीडियो में बदलने और एम्बेड करने के तरीके के बारे में जानकारी देगा. Imgu जैसी साइटों ने अपने GIF को वीडियो में बदलकर, लोडिंग की परफ़ॉर्मेंस को काफ़ी बेहतर बनाया है. इसके अलावा, अगर आपकी साइट सीमित बैंडविड्थ वाले होस्टिंग प्लान पर है, तो लागत की संभावित बचत ही आपको मना करने के लिए काफ़ी होगी!
वेब फ़ॉन्ट लोड होने के दौरान सभी टेक्स्ट दिखता रहता है
जब हम पेजों के लिए वेब फ़ॉन्ट लोड करते हैं, तो ब्राउज़र अक्सर ग्लोब पर न दिखने वाले टेक्स्ट को तब तक रेंडर करते हैं, जब तक कि फ़ॉन्ट लोड नहीं हो जाता. फ़्लैश ऑफ़ इनविज़िबल टेक्स्ट (एफ़ओआईटी) के नाम से जानी जाने वाली इस घटना का डिज़ाइन, आपके लिए बेहतर हो सकता है, लेकिन यह असल में एक समस्या है. रेंडर होने से रोके गए टेक्स्ट को तब तक नहीं पढ़ा जा सकता, जब तक वह रेंडर न हो जाए और दिखने लगे. ज़्यादा इंतज़ार और/या ज़्यादा बैंडविड्थ वाले कनेक्शन होने पर, इसका मतलब है कि आपके उपयोगकर्ता अनुभव का एक मुख्य हिस्सा मौजूद नहीं है. यह परफ़ॉर्मेंस से जुड़ी एक तरह की समस्या हो सकती है, जो समझ नहीं आती कि पेज सही कॉन्टेंट को उतनी तेज़ी से रेंडर नहीं कर रहा है जितनी जल्दी वह कर सकता है. अच्छी बात यह है कि वेब फ़ॉन्ट लोड होने के दौरान, सभी टेक्स्ट हमेशा दिखते रहें ऑडिट की मदद से, अपनी साइट पर इस समस्या को ठीक करने के अवसर खोजे जा सकते हैं!
अगर Lighthouse को आपके ऐप्लिकेशन में ऐसे वेब फ़ॉन्ट मिलते हैं जिसकी वजह से टेक्स्ट रेंडर होने में देरी हो रही है, तो इसके कुछ संभावित उपाय हैं. font-display सीएसएस प्रॉपर्टी और/या फ़ॉन्ट लोडिंग एपीआई की मदद से, टेक्स्ट रेंडरिंग को कंट्रोल किया जा सकता है.
अगर आपको इस बारे में ज़्यादा जानकारी चाहिए, तो फ़ॉन्ट लोड करने की रणनीतियों के लिए एक कॉम्प्रिहेंसिव गाइड पढ़ें. यह ज़ैक लेदरमैन की बेहतरीन गाइड है.
यह फ़ॉन्ट को सही तरीके से लोड करने के लिए एक बेहतरीन संसाधन है.
कम की गई सीएसएस और JavaScript
छोटा-बड़ा करना का सुझाव दिया जाता है, क्योंकि वेब परफ़ॉर्मेंस एक अहम चीज़ है. साथ ही, यह भी अच्छे होने की वजह है. इससे टेक्स्ट-आधारित संसाधनों का साइज़ काफ़ी कम हो जाता है, जो लोड होने के परफ़ॉर्मेंस के लिए अच्छा है. हालांकि, इस ऑप्टिमाइज़ेशन को नज़रअंदाज़ करना आसान है खास तौर पर, जब बिल्ड प्रोसेस में आप ऐसा नहीं कर पाते. Minify CSS और Minify JavaScript ऑडिट की मदद से, मौजूदा पेज पर मौजूद कम जानकारी वाले रिसॉर्स की एक सूची बनाई जाएगी. इसके बाद, इन फ़ाइलों को मैन्युअल तरीके से छोटा किया जा सकता है या इनके लिए अपने बिल्ड सिस्टम में बढ़ोतरी की जा सकती है.
इस्तेमाल न किए गए सीएसएस नियम
साइट के दांत में थोड़ी ज़्यादा लंबाई होने पर, रीफ़ैक्टरिंग से बचा हुआ डेटा मिलना शुरू हो जाता है. इस्तेमाल न किए गए सीएसएस नियमों के रूप में भी ऐसा ही एक सोर्स होता है. ये नियम अब साइट के काम करने के लिए ज़रूरी नहीं हैं. हालांकि, ये अब भी बैंडविथ का इस्तेमाल कर रहे हैं. आपकी सुविधा के लिए, इस्तेमाल नहीं किए गए सीएसएस के नियम ऑडिट से पता चलता है कि पेज पर किन सीएसएस रिसॉर्स में इस्तेमाल नहीं किया गया सीएसएस है.
अगर लाइटहाउस को पेज पर इस्तेमाल नहीं किया गया सीएसएस दिखता है, तो उसे हटाने के तरीके मौजूद हैं. UnCSS एक ऐसी सुविधा है जो आपके लिए यह काम अपने-आप कर देती है (हालांकि, इसका इस्तेमाल सावधानी से किया जाना चाहिए). DevTools में कोड कवरेज पैनल का इस्तेमाल करना, ज़्यादा मैन्युअल तरीके से किया जाता है. हालांकि, ध्यान रखें कि एक पेज पर इस्तेमाल न किए गए सीएसएस की ज़रूरत दूसरे पेज पर भी हो सकती है. दूसरा तरीका यह है कि आप अपने सीएसएस को टेंप्लेट के हिसाब से ऐसी फ़ाइलों में बांटें जिन्हें ज़रूरत के हिसाब से ही लोड किया जाता है. आप चाहे जो भी करने का फ़ैसला करें, Lighthouse यह आपको बताएगा कि क्या आपकी सीएसएस का इस्तेमाल थोड़ा और होने वाला है.
Lighthouse को आज़माएं!
अगर आप इन नए ऑडिट को लेकर उत्साहित हैं, तो लाइटहाउस को अपडेट करें और इन्हें आज़माएं!
- Lighthouse Chrome एक्सटेंशन अपने-आप अपडेट हो जाना चाहिए. हालांकि, इसे
chrome://extensionsकी मदद से मैन्युअल तरीके से अपडेट किया जा सकता है. - DevTools में, ऑडिट पैनल में लाइटहाउस चलाए जा सकते हैं. Chrome हर छह हफ़्तों में नए वर्शन में अपडेट होता है. इसलिए, हो सकता है कि कुछ नए ऑडिट उपलब्ध न हों. अगर आपको सबसे नए ऑडिट का इस्तेमाल नहीं करना है, तो Chrome कैनरी डाउनलोड करके नया Chrome कोड चलाया जा सकता है.
- नोड इस्तेमाल करने वालों के लिए:
npm update lighthouseचलाएं या अगर आपने दुनिया भर में लाइटहाउस इंस्टॉल किया है, तोnpm update lighthouse -gचलाएं.
उनके कीमती सुझावों के लिए कायस बास्क, पैट्रिक हल्स, एडी उस्मानी, और विनामरता सिंगाल का विशेष धन्यवाद. इससे इस लेख की क्वालिटी में काफ़ी सुधार हुआ.