Lighthouse का इस्तेमाल करके, वेबसाइट की परफ़ॉर्मेंस की जानकारी को ऑप्टिमाइज़ करना

Chrome के वेब टूल की मदद से, उपयोगकर्ता अनुभव को बेहतर बनाने के अवसर ढूंढना.

Addy Osmani

पब्लिश होने की तारीख: 11 मई, 2021

आज हम Lighthouse, PageSpeed, और DevTools में मौजूद टूल की नई सुविधाओं के बारे में बात करेंगे. इनसे आपको यह पता लगाने में मदद मिलेगी कि Web Vitals के हिसाब से, आपकी साइट की परफ़ॉर्मेंस को कैसे बेहतर बनाया जा सकता है.

इन टूल के बारे में फिर से जानकारी देने के लिए, हम आपको बता दें कि Lighthouse एक ओपन-सोर्स टूल है. यह वेब पेजों की क्वालिटी को बेहतर बनाने के लिए, अपने-आप काम करता है. यह आपको डीबग करने वाले टूल के Chrome DevTools सुइट में मिल सकता है. इसे किसी भी वेब पेज पर चलाया जा सकता है. भले ही, वह सार्वजनिक हो या उसकी पुष्टि करने की ज़रूरत हो. Lighthouse को PageSpeed Insights, CI, और WebPageTest में भी ढूंढा जा सकता है.

Lighthouse 7.x में नई सुविधाएं शामिल हैं. जैसे, एलिमेंट के स्क्रीनशॉट. इनकी मदद से, यूज़र इंटरफ़ेस के उन हिस्सों को आसानी से देखा जा सकता है जो उपयोगकर्ता अनुभव की मेट्रिक पर असर डालते हैं. उदाहरण के लिए, कौनसे नोड लेआउट शिफ़्ट में योगदान दे रहे हैं.

हमने PageSpeed Insights पर एलिमेंट के स्क्रीनशॉट की सुविधा भी जोड़ी है. इससे पेजों की परफ़ॉर्मेंस की जांच के दौरान, समस्याओं का पता लगाना ज़्यादा आसान हो गया है.

Core Web Vitals को मेज़र करना

Lighthouse, Core Web Vitals मेट्रिक को सिंथेटिक तरीके से मेज़र कर सकता है. इनमें सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय, लेआउट शिफ़्ट होने में लगने वाला समय, और पेज रिस्पॉन्स बंद रहने का कुल समय (क्लिक के बाद रिस्पॉन्स में लगने वाले समय के लिए लैब प्रॉक्सी) शामिल है. इन मेट्रिक से, पेज के लोड होने, लेआउट के स्टेबल होने, और इंटरैक्शन के लिए तैयार होने की जानकारी मिलती है. Core Web Vitals के भविष्य में हाइलाइट की गई, साइट का पहला एलिमेंट लोड होने में लगने वाला समय जैसी अन्य मेट्रिक भी मौजूद हैं.

Lighthouse रिपोर्ट के "मेट्रिक" सेक्शन में, इन मेट्रिक के लैब वर्शन शामिल होते हैं. इस रिपोर्ट का इस्तेमाल, उपयोगकर्ता अनुभव के उन पहलुओं की खास जानकारी देखने के लिए किया जा सकता है जिन पर आपको ध्यान देने की ज़रूरत है.

फ़ील्ड मेट्रिक, जैसे कि Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट या आरयूएम में मिलने वाली मेट्रिक में यह सीमा नहीं होती. साथ ही, ये लैब डेटा के लिए एक अहम पूरक हैं, क्योंकि इनसे असल उपयोगकर्ताओं के अनुभव का पता चलता है. फ़ील्ड डेटा से, आपको लैब में मिलने वाली डाइग्नोस्टिक जानकारी नहीं मिल सकती. इसलिए, दोनों को साथ में इस्तेमाल करना चाहिए.

Web Vitals को बेहतर बनाने के तरीके जानना

सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय से जुड़े एलिमेंट की पहचान करें

एलसीपी, पेज लोड होने के अनुभव का आकलन करता है. यह मेट्रिक, पेज लोड होने के दौरान उस समय के बारे में बताती है जब मुख्य या "सबसे बड़ा" कॉन्टेंट लोड हो जाता है और उपयोगकर्ता को दिखने लगता है.

Lighthouse में "सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय" ऑडिट होता है. इससे यह पता चलता है कि सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय क्या था. एलिमेंट पर कर्सर घुमाने से, वह मुख्य ब्राउज़र विंडो में हाइलाइट हो जाएगा.

अगर यह एलिमेंट कोई इमेज है, तो यह जानकारी एक काम का संकेत है कि आपको इस इमेज की लोडिंग को ऑप्टिमाइज़ करना चाहिए. Lighthouse में इमेज ऑप्टिमाइज़ेशन से जुड़े कई ऑडिट शामिल हैं. इनसे आपको यह समझने में मदद मिलती है कि आपकी इमेज को बेहतर तरीके से कंप्रेस किया जा सकता है या नहीं, उनका साइज़ बदला जा सकता है या नहीं या उन्हें ज़्यादा बेहतर और आधुनिक इमेज फ़ॉर्मैट में डिलीवर किया जा सकता है या नहीं.

एनी सुलिवन का एलसीपी बुकमार्कलेट भी आपके काम आ सकता है. इससे सिर्फ़ एक क्लिक में, लाल रंग के रेक्टैंगल वाले एलसीपी एलिमेंट की तुरंत पहचान की जा सकती है.

एलसीपी को बेहतर बनाने के लिए, देर से खोजी गई इमेज को पहले से लोड करें

सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय को कम करने के लिए, अपनी ज़रूरी हीरो इमेज को प्रीलोड करें. ऐसा तब करें, जब ब्राउज़र को उन्हें खोजने में ज़्यादा समय लग रहा हो. इमेज को खोजने लायक बनाने से पहले, JavaScript बंडल को लोड करना ज़रूरी है. ऐसा न करने पर, इमेज को खोजने में देरी हो सकती है.

एलसीपी इमेज को पहले से लोड करने के बारे में हमसे कुछ सामान्य सवाल पूछे जाते हैं. इनके बारे में भी कम शब्दों में बताना ज़रूरी है.

क्या रिस्पॉन्सिव इमेज को पहले से लोड किया जा सकता है? हां टैप करें. मान लें कि हमारे पास रिस्पॉन्सिव हीरो इमेज है, जैसा कि यहां srcset और sizes का इस्तेमाल करके बताया गया है:

<img src="lighthouse.jpg"
          srcset="lighthouse_400px.jpg 400w,
                  lighthouse_800px.jpg 800w,
                  lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">

link एट्रिब्यूट में जोड़े गए imagesrcset और imagesizes एट्रिब्यूट की मदद से, हम srcset और sizes के इस्तेमाल किए गए इमेज चुनने के लॉजिक का इस्तेमाल करके, रिस्पॉन्सिव इमेज को पहले से लोड कर सकते हैं:

<link rel="preload" as="image" href="lighthouse.jpg"
           imagesrcset="lighthouse_400px.jpg 400w,
                        lighthouse_800px.jpg 800w,
                        lighthouse_1600px.jpg 1600w"
imagesizes="50vw">

अगर एलसीपी इमेज को सीएसएस बैकग्राउंड के ज़रिए तय किया गया है, तो क्या ऑडिट में प्रीलोड के अवसरों को भी हाइलाइट किया जाएगा? हां.

अगर किसी इमेज को एलसीपी इमेज के तौर पर फ़्लैग किया गया है, तो उसे वॉटरफ़ॉल डेप्थ में तीन या उससे ज़्यादा बार खोजे जाने पर, उसे एलसीपी इमेज माना जा सकता है. भले ही, उसे सीएसएस बैकग्राउंड या <img> के ज़रिए फ़्लैग किया गया हो.

ऑफ़स्क्रीन इमेज के लिए लेज़ी लोडिंग का इस्तेमाल करना और एलसीपी के लिए इसका इस्तेमाल न करना

ऐसी ऑफ़स्क्रीन इमेज जो उपयोगकर्ता के शुरुआती अनुभव के लिए ज़रूरी नहीं हैं उन्हें लेज़ी-लोड किया जा सकता है. यह एक ऐसी तकनीक है जो किसी इमेज को तब तक डाउनलोड नहीं करती, जब तक कोई उपयोगकर्ता उसे स्क्रोल करके उसके पास नहीं पहुंच जाता. इससे ज़रूरी ऐसेट के लिए नेटवर्क की समस्या कम हो सकती है. साथ ही, कुछ मामलों में एलसीपी को बेहतर बनाया जा सकता है. "ऑफ़स्क्रीन इमेज को कुछ समय के लिए रोकना" ऑडिट से इसमें मदद मिल सकती है:

पेज के ऊपरी हिस्से पर मौजूद ज़रूरी इमेज को लेज़ी लोडिंग के ज़रिए लोड नहीं किया जाना चाहिए. जैसे, सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय से जुड़ी इमेज. ऐसा करने से, एलसीपी इमेज लोड होने में देरी हो सकती है. अगर किसी एलसीपी इमेज को लेज़ी-लोडिंग के ज़रिए गलत तरीके से लोड किया जा रहा है, तो Lighthouse उसे हाइलाइट करेगा. इसके लिए, वह "सबसे बड़े एलिमेंट वाली इमेज को लेज़ी लोडिंग के ज़रिए लोड किया गया है" ऑडिट का इस्तेमाल करेगा:

सीएलएस में योगदान देने वाले एलिमेंट की पहचान करना

लेआउट शिफ़्ट होने में लगने वाला समय (सीएलएस), विज़ुअल स्टैबिलिटी को मेज़र करता है. यह बताता है कि किसी पेज का कॉन्टेंट, विज़ुअल तौर पर कितना शिफ़्ट होता है. Lighthouse में सीएलएस को डीबग करने के लिए, "लेआउट में होने वाले बड़े बदलावों से बचें" नाम का ऑडिट मौजूद है.

इस ऑडिट में उन डीओएम एलिमेंट को हाइलाइट किया जाता है जिनकी वजह से पेज के लेआउट में सबसे ज़्यादा शिफ़्ट होते हैं. बाईं ओर मौजूद एलिमेंट कॉलम में, आपको इन डीओएम एलिमेंट की सूची दिखेगी. वहीं, दाईं ओर आपको सीएलएस में उनके कुल योगदान की जानकारी दिखेगी.

Lighthouse की नई एलिमेंट स्क्रीनशॉट सुविधा की मदद से, हम ऑडिट में नोट किए गए मुख्य एलिमेंट की झलक देख सकते हैं. साथ ही, साफ़ तौर पर देखने के लिए, क्लिक करके ज़ूम भी कर सकते हैं:

पेज लोड होने के बाद होने वाले सीएलएस के लिए, रेक्टैंगल की मदद से लगातार यह विज़ुअलाइज़ करना फ़ायदेमंद हो सकता है कि किन एलिमेंट ने सीएलएस में सबसे ज़्यादा योगदान दिया. यह सुविधा आपको तीसरे पक्ष के टूल में मिलेगी. जैसे, SpeedCurve का वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाला डैशबोर्ड. मुझे Defaced का लेआउट शिफ़्ट GIF जनरेटर इस्तेमाल करना पसंद है. इसकी मदद से:

पूरी साइट पर लेआउट शिफ़्ट की समस्याओं को देखने के लिए, मुझे Search Console की Core Web Vitals रिपोर्ट से काफ़ी मदद मिलती है. इससे मुझे अपनी साइट पर ज़्यादा सीएलएस वाले पेजों के बारे में पता चलता है. इस मामले में, मुझे यह पहचानने में मदद मिलती है कि मुझे टेंप्लेट के किन हिस्सों पर अपना समय बिताना चाहिए:

बिना डाइमेंशन वाली इमेज से सीएलएस की पहचान करना

बिना डाइमेंशन वाली इमेज की वजह से होने वाले लेआउट शिफ़्ट होने में लगने वाले समय को कम करने के लिए, अपनी इमेज और वीडियो एलिमेंट में चौड़ाई और ऊंचाई के साइज़ एट्रिब्यूट शामिल करें. इस तरीके से यह पक्का होता है कि इमेज लोड होने के दौरान, ब्राउज़र दस्तावेज़ में सही जगह तय कर सके.

इमेज के डाइमेंशन और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के बारे में जानने के लिए, इमेज की ऊंचाई और चौड़ाई सेट करना फिर से ज़रूरी हो गया है लेख पढ़ें.

विज्ञापनों की वजह से होने वाले सीएलएस की पहचान करना

Publisher Ads for Lighthouse की मदद से, अपने पेज पर विज्ञापनों के लोड होने के अनुभव को बेहतर बनाया जा सकता है. इसमें लेआउट शिफ़्ट और ज़्यादा समय लेने वाले कामों में योगदान देना शामिल है. इनकी वजह से, उपयोगकर्ताओं के लिए आपके पेज को इस्तेमाल करने में देरी हो सकती है. Lighthouse में, इसे कम्यूनिटी प्लगिन की मदद से चालू किया जा सकता है.

याद रखें कि वेब पर लेआउट शिफ़्ट होने की एक सबसे बड़ी वजह विज्ञापन होते हैं. यह ज़रूरी है कि:

• व्यूपोर्ट के सबसे ऊपर वाले हिस्से के पास, एक जगह पर बने न रहने वाले विज्ञापनों को प्लेस करते समय सावधानी बरतें
• विज्ञापन स्लॉट के लिए, ज़्यादा से ज़्यादा साइज़ रिज़र्व करके, लेआउट में होने वाले बदलावों को कम करें

कंपोज़िट नहीं किए गए ऐनिमेशन से बचें

अगर JavaScript के बड़े टास्क की वजह से मुख्य थ्रेड व्यस्त है, तो कंपोज़िट नहीं किए गए ऐनिमेशन, कम क्षमता वाले डिवाइसों पर खराब क्वालिटी में दिख सकते हैं. इस तरह के ऐनिमेशन से लेआउट शिफ़्ट हो सकते हैं.

अगर Chrome को पता चलता है कि किसी ऐनिमेशन को कंपोज़िट नहीं किया जा सका, तो वह इसकी जानकारी DevTools ट्रेस को देता है. Lighthouse इसे पढ़ता है, जिससे वह यह सूची बना पाता है कि ऐनिमेशन वाले कौनसे एलिमेंट कंपोज़िट नहीं किए गए और इसकी क्या वजह थी. इन्हें नॉन-कंपोज़िटेड ऐनिमेशन से बचें ऑडिट में देखा जा सकता है.

क्लिक के बाद रिस्पॉन्स में लगे समय / पेज रिस्पॉन्स बंद रहने के कुल समय / ज़्यादा समय लेने वाले टास्क को डीबग करना

फ़र्स्ट इनपुट से यह पता चलता है कि किसी उपयोगकर्ता के पहली बार किसी पेज से इंटरैक्ट करने (जैसे, जब वह किसी लिंक पर क्लिक करता है, किसी बटन पर टैप करता है या JavaScript की मदद से काम करने वाले किसी कस्टम कंट्रोल का इस्तेमाल करता है) से लेकर ब्राउज़र से उस इंटरैक्शन के जवाब में इवेंट हैंडलर को प्रोसेस करने तक कितना समय लगता है. लंबे JavaScript टास्क, इस मेट्रिक और इसकी प्रॉक्सी मेट्रिक, पेज रिस्पॉन्स बंद रहने के कुल समय पर असर डाल सकते हैं.

Lighthouse में, मुख्य थ्रेड के लंबे टास्क से बचें ऑडिट शामिल है. इसमें मुख्य थ्रेड पर सबसे लंबे टास्क की सूची होती है. इससे इनपुट डिले में, सबसे खराब योगदान देने वालों की पहचान करने में मदद मिलती है. बाईं ओर मौजूद कॉलम में, उन स्क्रिप्ट के यूआरएल देखे जा सकते हैं जिनकी वजह से मुख्य थ्रेड के टास्क को पूरा होने में ज़्यादा समय लगता है.

दाईं ओर, हमें इन टास्क की अवधि दिखती है. आपको याद दिला दें कि ज़्यादा समय लेने वाले टास्क, ऐसे टास्क होते हैं जिन्हें पूरा होने में 50 मिलीसेकंड से ज़्यादा समय लगता है. इससे मुख्य थ्रेड को काफ़ी समय तक ब्लॉक किया जा सकता है, जिससे फ़्रेम रेट या इनपुट के इंतज़ार के समय पर असर पड़ता है.

अगर आपको मॉनिटरिंग के लिए तीसरे पक्ष की सेवाएं इस्तेमाल करनी हैं, तो Calibre का मेन-थ्रेड एक्ज़ीक्यूशन टाइमलाइन विज़ुअल भी काफ़ी अच्छा है. इससे इन लागतों को विज़ुअलाइज़ किया जा सकता है. इसमें पैरंट और चाइल्ड, दोनों टास्क हाइलाइट होते हैं. ये टास्क, इंटरैक्टिविटी पर असर डालने वाले लंबे टास्क में योगदान देते हैं.

Lighthouse में, नेटवर्क के अनुरोधों को ब्लॉक करने से पहले और बाद में होने वाले असर को देखने के लिए, नेटवर्क के अनुरोधों को ब्लॉक करें

Chrome DevTools में नेटवर्क के अनुरोधों को ब्लॉक करने की सुविधा है. इससे यह देखा जा सकता है कि अलग-अलग संसाधनों को हटाने या उनके उपलब्ध न होने पर क्या असर पड़ता है. इससे यह समझने में मदद मिल सकती है कि तीसरे पक्ष के एम्बेड या ट्रैकर जैसी अलग-अलग स्क्रिप्ट की वजह से, पेज रिस्पॉन्स बंद रहने का कुल समय (टीबीटी) और टाइम टू इंटरैक्टिव जैसी मेट्रिक पर क्या असर पड़ता है.

नेटवर्क के अनुरोध को ब्लॉक करने वाला टूल, Lighthouse के साथ भी काम करता है! आइए, किसी साइट के लिए Lighthouse रिपोर्ट पर एक नज़र डालते हैं. परफ़ॉर्मेंस स्कोर 63/100 है और टीबीटी 400 मि॰से॰ है. कोड की जांच करने पर, हमें पता चला कि यह साइट Chrome में इंटरसेक्शन ऑब्ज़र्वर पॉलीफ़िल लोड करती है, जिसकी ज़रूरत नहीं है. चलो, इसे ब्लॉक करते हैं!

DevTools के नेटवर्क पैनल में जाकर, किसी स्क्रिप्ट पर राइट क्लिक करें. इसके बाद, उसे ब्लॉक करने के लिए Block Request URL पर क्लिक करें. यहां हम Intersection Observer polyfill के लिए ऐसा करेंगे.

इसके बाद, हम Lighthouse को फिर से चला सकते हैं. इस बार, हमें परफ़ॉर्मेंस स्कोर में सुधार (70/100) देखने को मिला है. साथ ही, पेज रिस्पॉन्स बंद रहने के कुल समय में भी सुधार (400 मि॰से॰ => 300 मि॰से॰) हुआ है.

तीसरे पक्ष के महंगे एम्बेड को फ़साड से बदलें

पेजों में वीडियो, सोशल मीडिया पोस्ट या विजेट एम्बेड करने के लिए, तीसरे पक्ष के संसाधनों का इस्तेमाल करना आम बात है. डिफ़ॉल्ट रूप से, एम्बेड किए गए ज़्यादातर एलिमेंट तुरंत लोड हो जाते हैं. साथ ही, इनमें भारी पेलोड हो सकते हैं, जिनसे उपयोगकर्ता अनुभव पर बुरा असर पड़ता है. अगर तीसरे पक्ष की स्क्रिप्ट ज़रूरी नहीं है, तो यह समय की बर्बादी है. उदाहरण के लिए, अगर उपयोगकर्ता को इसे देखने से पहले स्क्रोल करना पड़े.

ऐसे विजेट की परफ़ॉर्मेंस को बेहतर बनाने का एक तरीका यह है कि उपयोगकर्ता के इंटरैक्शन पर उन्हें लेज़ी-लोड किया जाए. इसके लिए, विजेट की हल्की झलक (फ़साड) रेंडर की जा सकती है. साथ ही, पूरा वर्शन सिर्फ़ तब लोड किया जा सकता है, जब कोई उपयोगकर्ता उससे इंटरैक्ट करे. Lighthouse में एक ऑडिट होता है, जो तीसरे पक्ष के ऐसे संसाधनों का सुझाव देगा जिन्हें फ़साड की मदद से लेज़ी-लोड किया जा सकता है. जैसे, एम्बेड किए गए YouTube वीडियो.

याद रखें कि Lighthouse, तीसरे पक्ष के उस कोड को हाइलाइट करेगा जो मुख्य थ्रेड को 250 मि॰से॰ से ज़्यादा समय तक ब्लॉक करता है. इससे तीसरे पक्ष की सभी तरह की स्क्रिप्ट (इनमें Google की बनाई गई स्क्रिप्ट भी शामिल हैं) का पता चल सकता है. अगर स्क्रिप्ट को रेंडर करने के लिए स्क्रोल करना ज़रूरी है, तो उन्हें बाद में लोड होने के लिए सेट करना या लेज़ी लोड करना बेहतर हो सकता है.

Core Web Vitals के अलावा अन्य मेट्रिक

Lighthouse और PageSpeed Insights के नए वर्शन, Core Web Vitals को हाइलाइट करने के साथ-साथ, आपको ठोस दिशा-निर्देश भी देते हैं. अगर आपने सोर्स मैप चालू किए हैं, तो इन दिशा-निर्देशों का पालन करके, JavaScript वाले वेब ऐप्लिकेशन के लोड होने की स्पीड को बेहतर बनाया जा सकता है.

इनमें आपके पेज पर JavaScript की लागत को कम करने के लिए, ऑडिट का बढ़ता हुआ कलेक्शन शामिल है. जैसे, पॉलीफ़िल और डुप्लीकेट पर निर्भरता कम करना, जिनकी शायद उपयोगकर्ता अनुभव के लिए ज़रूरत न हो.

Core Web Vitals टूल के बारे में ज़्यादा जानकारी पाने के लिए, Lighthouse टीम के Twitter खाते और DevTools में नया क्या है पर नज़र रखें.