लाइटहाउस: वेबसाइट की स्पीड ऑप्टिमाइज़ करें

ट्यूटोरियल का लक्ष्य

इस ट्यूटोरियल में, Chrome DevTools को इस्तेमाल करने का तरीका बताया गया है. इससे वेबसाइटों को तेज़ी से लोड करने के तरीके ढूंढे जा सकते हैं.

इस ट्यूटोरियल को पढ़ें या इसका वीडियो वर्शन देखें:

ज़रूरी शर्तें

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

आपको लोड परफ़ॉर्मेंस के बारे में कुछ भी जानने की ज़रूरत नहीं है.

शुरुआती जानकारी

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

पहला चरण: साइट का ऑडिट करना

जब भी आप किसी साइट के लोड होने की परफ़ॉर्मेंस को बेहतर बनाना चाहें, तो हमेशा ऑडिट से शुरुआत करें. ऑडिट में दो ज़रूरी सुविधाएं हैं:

• यह बाद के बदलावों को मेज़र करने के लिए एक बेसलाइन बनाता है.
• इसमें आपको कार्रवाई करने के लिए सलाह मिलती है और पता चलता है कि किन बदलावों का सबसे ज़्यादा असर होगा.

सेट अप करें

सबसे पहले, आपको Tony की वेबसाइट के लिए काम करने का नया माहौल सेट अप करना होगा, ताकि आप बाद में उसमें बदलाव कर सकें:

1. glitch पर वेबसाइट का प्रोजेक्ट रीमिक्स करें. आपका नया प्रोजेक्ट एक टैब में खुलेगा. इस टैब को एडिटर टैब कहा जाएगा.

   

   प्रोजेक्ट का नाम tony से बदलकर, रैंडम तरीके से जनरेट किया गया नाम हो जाता है. अब आपके पास कोड की अपनी बदलाव करने लायक कॉपी है. बाद में, आपको इस कोड में बदलाव करने होंगे.

2. एडिटर टैब के सबसे नीचे, झलक देखें > नई विंडो में झलक देखें पर क्लिक करें. डेमो नए टैब में खुलता है. इस टैब को डेमो टैब कहा जाएगा. साइट को लोड होने में कुछ समय लग सकता है.

   

3. डेमो के बगल में DevTools खोलें.

   

बेसलाइन तय करें

बेसलाइन में यह दिखता है कि परफ़ॉर्मेंस में सुधार करने से पहले, आपकी साइट की परफ़ॉर्मेंस कैसी रही.

1. Lighthouse पैनल खोलें. यह double_arrow ज़्यादा पैनल के पीछे दिख सकता है.

   

2. अपनी लाइटहाउस रिपोर्ट की कॉन्फ़िगरेशन सेटिंग को स्क्रीनशॉट में दी गई सेटिंग के हिसाब से सेट करें. यहां अलग-अलग विकल्पों की जानकारी दी गई है:

   • check_box स्टोरेज खाली करें. इस चेकबॉक्स को चालू करने से, हर ऑडिट से पहले पेज से जुड़ा सारा स्टोरेज मिट जाता है. अगर आपको यह ऑडिट करना है कि आपकी साइट पर पहली बार आने वाले लोगों को कैसा अनुभव मिलता है, तो इस सेटिंग को चालू रखें. 'दोबारा विज़िट' का अनुभव लेने के लिए, इस सेटिंग को बंद करें.
   • check_box JS सैंपलिंग चालू करें. यह विकल्प, डिफ़ॉल्ट रूप से बंद होता है. यह सुविधा चालू होने पर, यह परफ़ॉर्मेंस ट्रेस में ज़्यादा जानकारी वाले JavaScript कॉल स्टैक जोड़ देती है. हालांकि, इससे रिपोर्ट जनरेट होने की प्रोसेस धीमी हो सकती है. यह ट्रेस, Lighthouse रिपोर्ट जनरेट होने के बाद, more_vert टूल मेन्यू > थ्रॉटल नहीं किया गया ट्रेस देखें में उपलब्ध है.
   • सिम्युलेटेड थ्रॉटलिंग (डिफ़ॉल्ट) arrow_drop_down. यह विकल्प, मोबाइल डिवाइस पर ब्राउज़ करने की सामान्य स्थितियों को सिम्युलेट करता है. इसे "सिम्युलेटेड" कहा जाता है, क्योंकि ऑडिटिंग की प्रोसेस के दौरान लाइटहाउस असल में थ्रॉटल नहीं करता. इसके बजाय, यह सिर्फ़ अनुमान लगाता है कि मोबाइल स्थितियों में पेज को लोड होने में कितना समय लगेगा. वहीं दूसरी ओर, DevTools थ्रॉटलिंग (ऐडवांस) सेटिंग असल में आपके सीपीयू और नेटवर्क को थ्रॉटल कर देती है. इससे, आपको लंबी ऑडिटिंग प्रोसेस को पूरा करना पड़ता है.
   • मोड > radio_button_checked नेविगेशन (डिफ़ॉल्ट). यह मोड, लोड होने वाले एक पेज का विश्लेषण करता है. इसी काम के लिए, इस ट्यूटोरियल की ज़रूरत पड़ती है. ज़्यादा जानकारी के लिए, तीन मोड देखें.
   • डिवाइस > radio_button_checked मोबाइल. मोबाइल विकल्प, उपयोगकर्ता एजेंट स्ट्रिंग को बदलता है और मोबाइल व्यूपोर्ट को सिम्युलेट करता है. डेस्कटॉप विकल्प सिर्फ़ मोबाइल बदलावों को बंद कर देता है.
   • कैटगरी > check_box परफ़ॉर्मेंस. चालू की गई एक कैटगरी की मदद से, लाइटहाउस सिर्फ़ संबंधित ऑडिट सेट के साथ रिपोर्ट जनरेट करता है. अगर आपको उन कैटगरी के सुझाव देखना है, तो उन्हें चालू रखें. काम की कैटगरी को बंद करने से, ऑडिट की प्रोसेस ज़्यादा तेज़ हो जाती है.

3. पेज लोड का विश्लेषण करें पर क्लिक करें. 10 से 30 सेकंड के बाद, Lighthouse पैनल आपको साइट की परफ़ॉर्मेंस की रिपोर्ट दिखाता है.

   

रिपोर्ट की गड़बड़ियों को मैनेज करना

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

अपनी रिपोर्ट को समझना

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

मेट्रिक

नीचे स्क्रोल करते हुए मेट्रिक सेक्शन पर जाएं और व्यू बड़ा करें पर क्लिक करें. किसी मेट्रिक का दस्तावेज़ पढ़ने के लिए, ज़्यादा जानें... पर क्लिक करें.

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

स्क्रीनशॉट

आगे है स्क्रीनशॉट का एक कलेक्शन, जो आपको दिखाता है कि पेज लोड होने पर कैसा दिखता था.

गेम का प्रदर्शन बेहतर करने के मौके

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

किसी अवसर के बारे में ज़्यादा जानने के लिए, उस पर क्लिक करें.

कोई अवसर क्यों ज़रूरी है, इस बारे में दस्तावेज़ और उसे ठीक करने के तरीके से जुड़े खास सुझावों को देखने के लिए ज़्यादा जानें... पर क्लिक करें.

डाइग्नोस्टिक्स

गड़बड़ी की जानकारी सेक्शन में, उन चीज़ों के बारे में ज़्यादा जानकारी मिलती है जो पेज के लोड होने में लगने वाले समय पर असर डालती हैं.

पास किए गए ऑडिट

पास हुए ऑडिट सेक्शन से पता चलता है कि साइट की परफ़ॉर्मेंस कैसी है. सेक्शन को बड़ा करने के लिए क्लिक करें.

चरण 2: प्रयोग

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

टेक्स्ट कंप्रेस करने की सुविधा चालू करें

आपकी रिपोर्ट के मुताबिक, पेज की परफ़ॉर्मेंस को बेहतर बनाने के मुख्य अवसरों में से एक है, टेक्स्ट कंप्रेस करने की सुविधा को चालू करना.

जब टेक्स्ट फ़ाइल को नेटवर्क पर भेजने से पहले उसके साइज़ को कम या कंप्रेस किया जाता है, तो इसे टेक्स्ट कंप्रेशन कहा जाता है. यह किसी फ़ोल्डर का साइज़ कम करने के लिए, उसे ईमेल करने से पहले उसे ज़िप करने का तरीका है.

कंप्रेस करने की सुविधा चालू करने से पहले, मैन्युअल रूप से यह देखने के कुछ तरीके दिए गए हैं कि टेक्स्ट रिसॉर्स को कंप्रेस किया गया है या नहीं.

नेटवर्क पैनल खोलें और settings सेटिंग > check_box अनुरोध वाली बड़ी लाइनों का इस्तेमाल करें पर सही का निशान लगाएं.

हर साइज़ सेल में दो वैल्यू दिखती हैं. सबसे ऊपर दी गई वैल्यू, डाउनलोड किए गए संसाधन का साइज़ है. सबसे नीचे मौजूद वैल्यू, कंप्रेस न किए गए रिसॉर्स का साइज़ होती है. अगर दोनों वैल्यू एक जैसी हैं, तो नेटवर्क पर भेजे जाने पर, रिसॉर्स को कंप्रेस नहीं किया जाता. इस उदाहरण में, bundle.js के लिए टॉप और बॉटम वैल्यू, दोनों 1.4 MB हैं.

किसी संसाधन के एचटीटीपी हेडर की जांच करके भी कंप्रेस की गई फ़ाइल की जांच की जा सकती है:

1. bundle.js पर क्लिक करें और हेडर टैब खोलें.

   

2. content-encoding हेडर के लिए, रिस्पॉन्स हेडर सेक्शन खोजें. आपको यह भी नहीं दिखना चाहिए, इसका मतलब है कि bundle.js को कंप्रेस नहीं किया गया था. जब किसी संसाधन को कंप्रेस किया जाता है, तो यह हेडर आम तौर पर gzip, deflate या br पर सेट होता है. इन वैल्यू की जानकारी के लिए, निर्देश देखें.

यह काफ़ी जानकारी हो सकती है. कुछ बदलाव करने का समय आ गया है! कोड की कुछ लाइनें जोड़कर, टेक्स्ट कंप्रेस करने की सुविधा चालू करें:

1. एडिटर टैब में, server.js खोलें और ये दो (हाइलाइट की गई) लाइनें जोड़ें:

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. app.use(compression()) को app.use(express.static('build')) से पहले लगाना पक्का करें.

   

3. साइट के नए बिल्ड को डिप्लॉय करने के लिए, Glitch का इंतज़ार करें. सबसे नीचे बाएं कोने में एक खुश इमोजी का मतलब है कि डिप्लॉयमेंट पूरा हो गया है.

मैन्युअल रूप से जांचने के लिए कि कंप्रेशन काम कर रहा है, पहले से सीखे गए वर्कफ़्लो का इस्तेमाल करें:

1. डेमो टैब पर वापस जाएं और पेज को फिर से लोड करें.

   साइज़ कॉलम में अब bundle.js जैसे टेक्स्ट रिसॉर्स के लिए, दो अलग-अलग वैल्यू दिखने चाहिए. bundle.js के लिए 269 KB का सबसे ऊपर का मान, नेटवर्क पर भेजी गई फ़ाइल का साइज़ है. साथ ही, 1.4 MB का निचला मान, कंप्रेस न की गई फ़ाइल का साइज़ है.

   

2. bundle.js के रिस्पॉन्स हेडर सेक्शन में अब content-encoding: gzip हेडर शामिल होना चाहिए.

   

पेज की लोड परफ़ॉर्मेंस पर, टेक्स्ट कंप्रेशन के असर को मापने के लिए, पेज पर फिर से लाइटहाउस रिपोर्ट चलाएं:

1. लाइटहाउस पैनल खोलें और सबसे ऊपर मौजूद ऐक्शन बार में, ऑडिट करें... पर क्लिक करें.

   

2. सेटिंग को पहले की तरह ही रहने दें और पेज लोड का विश्लेषण करें पर क्लिक करें.

   

बहुत बढ़िया! ऐसा लगता है कि यह प्रोग्रेस है. आपका कुल परफ़ॉर्मेंस स्कोर बढ़ गया होगा, इसका मतलब है कि साइट तेज़ी से बढ़ रही है.

असल दुनिया में टेक्स्ट को कंप्रेस करने की सुविधा

ज़्यादातर सर्वर में कंप्रेस करने की सुविधा को चालू करने के लिए इस तरह के आसान सुधार होते हैं! टेक्स्ट को कंप्रेस करने के लिए इस्तेमाल किए जाने वाले सर्वर को कॉन्फ़िगर करने का तरीका खोजें.

इमेज का साइज़ बदलें

आपकी नई रिपोर्ट के मुताबिक, इमेज को सही तरीके से साइज़ देना एक और बड़ा मौका है.

इमेज का साइज़ बदलने से, इमेज की फ़ाइल का साइज़ कम हो जाता है. इससे उन्हें लोड होने में कम समय लगता है. अगर उपयोगकर्ता आपके मोबाइल डिवाइस की स्क्रीन पर 500 पिक्सल चौड़ी स्क्रीन देख रहा है, तो 1500 पिक्सल चौड़ी इमेज भेजने का कोई मतलब नहीं है. जहां तक हो सके, ज़्यादा से ज़्यादा 500 पिक्सल चौड़ी इमेज ही भेजना.

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

   

2. एडिटर टैब पर वापस जाकर, src/model.js खोलें.

3. const dir = 'big' को const dir = 'small' से बदलें. इस डायरेक्ट्री में उन इमेज की कॉपी हैं जिनका साइज़ बदला गया है.

4. पेज को फिर से ऑडिट करके देखें कि इस बदलाव से लोड परफ़ॉर्मेंस पर क्या असर पड़ता है.

   

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

असल दुनिया में इमेज का साइज़ बदलना

किसी छोटे ऐप्लिकेशन के लिए, इस तरह एक बार साइज़ बदलना काफ़ी हो सकता है. लेकिन एक बड़े ऐप्लिकेशन के लिए, बेशक यह बढ़ाने लायक नहीं है. बड़े ऐप्लिकेशन में इमेज मैनेज करने के लिए, यहां कुछ रणनीतियां दी गई हैं:

• बिल्ड प्रोसेस के दौरान इमेज का साइज़ बदलें.
• बिल्ड प्रोसेस के दौरान, हर इमेज के कई साइज़ बनाएं और फिर अपने कोड में srcset का इस्तेमाल करें. रनटाइम के दौरान, ब्राउज़र यह चुनने का ध्यान रखता है कि जिस डिवाइस पर वह चल रहा है उसके लिए सबसे सही साइज़ कौनसा है. मिलते-जुलते साइज़ की इमेज देखें.
• ऐसी सीडीएन का इस्तेमाल करें जो इमेज का अनुरोध करने पर, उसका साइज़ डाइनैमिक तौर पर बदलने की सुविधा देती हो.
• कम से कम हर इमेज को ऑप्टिमाइज़ करें. इससे अक्सर भारी बचत हो सकती है. ऑप्टिमाइज़ेशन तब होता है, जब इमेज को किसी ऐसे प्रोग्राम के ज़रिए चलाया जाता है जो इमेज फ़ाइल का साइज़ कम कर देता है. ज़्यादा सलाह पाने के लिए, ज़रूरी इमेज ऑप्टिमाइज़ेशन देखें.

रेंडर ब्लॉक करने वाले संसाधनों को हटाएं

आपकी हाल की रिपोर्ट के मुताबिक, रेंडर ब्लॉक करने वाले संसाधनों को हटाना अब एक बड़ा मौका है.

रेंडर करने से रोकने वाला रिसॉर्स, एक बाहरी JavaScript या सीएसएस फ़ाइल होती है. ब्राउज़र को पेज दिखाने से पहले, इसे डाउनलोड, पार्स, और एक्ज़ीक्यूट करना होता है. इसका मकसद सिर्फ़ मुख्य सीएसएस और JavaScript कोड को चलाना है, जो पेज को ठीक से दिखाने के लिए ज़रूरी है.

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

1. ब्लॉक किए जा रहे संसाधनों को देखने के लिए, रेंडर ब्लॉक करने वाले संसाधनों को हटाएं पर क्लिक करें: lodash.js और jquery.js.

   

2. अपने ऑपरेटिंग सिस्टम के हिसाब से, Command मेन्यू खोलने के लिए इन्हें दबाएं:

   • Mac पर, Command+Shift+P
   • Windows, Linux या ChromeOS पर, Control+Shift+P

3. Coverage टाइप करें और कवरेज दिखाएं को चुनें.

   

   कवरेज टैब, ड्रॉर में खुलता है.

   

4. फिर से लोड करें पर क्लिक करें. कवरेज टैब से यह जानकारी मिलती है कि पेज लोड होने के दौरान, bundle.js, jquery.js, और lodash.js में कितने कोड एक्ज़ीक्यूट किए जा रहे हैं.

   

   इस स्क्रीनशॉट में बताया गया है कि jQuery और Lodash फ़ाइलों का करीब 74% और 30% हिस्सा इस्तेमाल नहीं किया जाता है.

5. jquery.js लाइन पर क्लिक करें. DevTools फ़ाइल को सोर्स पैनल में खोलता है. अगर कोड के बगल में एक हरा बार मौजूद है, तो उस कोड वाली लाइन को लागू किया गया था. कोड की लाइन के बगल में मौजूद लाल रंग के बार का मतलब है कि उसे एक्ज़ीक्यूट नहीं किया गया. साथ ही, पेज लोड करते समय इसकी ज़रूरत नहीं होती.

   

6. jQuery कोड में थोड़ा स्क्रोल करें. कुछ लाइनें जिन पर "शुरू हो गई" किया जाता है वे असल में सिर्फ़ टिप्पणियाँ होती हैं. इस कोड को मिनीफ़ायर की मदद से चलाया जा रहा है, जो टिप्पणियों को हटा देता है. यह फ़ाइल का साइज़ कम करने का एक और तरीका है.

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

क्या इस पेज को लोड करने के लिए, jquery.js और lodash.js फ़ाइलों की ज़रूरत है? अनुरोध ब्लॉक करें टैब से आपको पता चल सकता है कि संसाधन उपलब्ध न होने पर क्या होता है.

1. नेटवर्क टैब पर क्लिक करें और Command मेन्यू को दोबारा खोलें.

2. blocking टाइप करें. इसके बाद, अनुरोध पर रोक लगाने वाला मैसेज दिखाएं को चुनें. ऐसा करने पर, ब्लॉक करने का अनुरोध करें टैब खुल जाएगा.

   

3. पैटर्न जोड़ें पर क्लिक करें. इसके बाद, टेक्स्ट बॉक्स में /libs/* टाइप करें और पुष्टि करने के लिए, Enter दबाएं.

   

4. पेज को फिर से लोड करें. jQuery और Lodash के अनुरोध लाल रंग के होते हैं, जिसका मतलब है कि उन्हें ब्लॉक कर दिया गया था. पेज अब भी लोड हो रहा है और इंटरैक्टिव है. इसलिए, ऐसा लगता है कि इन संसाधनों की ज़रूरत नहीं है!

   

5. /libs/* ब्लॉक करने का पैटर्न मिटाने के लिए, सभी पैटर्न हटाएं पर क्लिक करें.

आम तौर पर, अनुरोध ब्लॉक करें टैब की मदद से, यह देखा जा सकता है कि किसी संसाधन के उपलब्ध न होने पर, आपका पेज कैसे काम करता है.

अब, कोड से इन फ़ाइलों के रेफ़रंस हटाएं और पेज का फिर से ऑडिट करें:

1. एडिटर टैब पर वापस जाकर, template.html खोलें.

2. इससे जुड़े <script> टैग मिटाएं:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. साइट के फिर से बनने और फिर से डिप्लॉय होने तक इंतज़ार करें.

4. Lighthouse पैनल से पेज को फिर से ऑडिट करें. आपके कुल स्कोर में फिर से सुधार हो गया होगा.

   

असल दुनिया में क्रिटिकल रेंडरिंग पाथ को ऑप्टिमाइज़ करना

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

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

मुख्य थ्रेड पर कम काम करें

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

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

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

1. परफ़ॉर्मेंस > सेटिंग कैप्चर करें खोलें. इसके बाद, नेटवर्क को धीमे 3G और सीपीयू को 6x धीमा पर सेट करें.

   

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

2. फिर से लोड करें पर क्लिक करें. DevTools पेज को फिर से लोड करता है. इसके बाद, यह एक विज़ुअलाइज़ेशन दिखाता है कि पेज को लोड करने के लिए इसे क्या करना था. इस विज़ुअलाइज़ेशन को trace कहा जाएगा.

   

ट्रेस, गतिविधि को समय के हिसाब से बाईं से दाईं ओर दिखाता है. सबसे ऊपर मौजूद FPS, CPU, और NET चार्ट, आपको फ़्रेम प्रति सेकंड, सीपीयू गतिविधि, और नेटवर्क पर की गई गतिविधि की खास जानकारी देते हैं.

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

JavaScript की मदद से कम काम करने के तरीके जानने के लिए, ट्रेस की जांच करें:

1. समय सेक्शन पर क्लिक करके, इसे बड़ा करें.

   

   React के User Timing मेट्रिक का इस्तेमाल करके पता चलता है कि टोनी का ऐप्लिकेशन, React के डेवलपमेंट मोड का इस्तेमाल कर रहा है. React के प्रोडक्शन मोड पर स्विच करने से कुछ आसान नतीजे मिल सकते हैं.

2. उस सेक्शन को छोटा करने के लिए, समय पर दोबारा क्लिक करें.

3. मुख्य सेक्शन ब्राउज़ करें. इस सेक्शन में, मुख्य थ्रेड की गतिविधि का क्रम के हिसाब से लॉग दिखता है. वह लॉग, बाईं से दाईं ओर होता है. Y-ऐक्सिस (ऊपर से नीचे) दिखाता है कि इवेंट क्यों हुए.

   

   इस उदाहरण में, Evaluate Script इवेंट की वजह से (anonymous) फ़ंक्शन लागू हुआ और __webpack__require__ लागू हुआ और ./src/index.jsx फ़ंक्शन लागू हुआ.

4. मुख्य सेक्शन में नीचे तक स्क्रोल करें. जब किसी फ़्रेमवर्क का इस्तेमाल किया जाता है, तो सबसे ऊपर होने वाली ज़्यादातर गतिविधि, फ़्रेमवर्क की वजह से होती है. आम तौर पर, इस पर आपका कंट्रोल नहीं होता. आम तौर पर, आपके ऐप्लिकेशन की वजह से हुई गतिविधि की जानकारी सबसे नीचे दिखती है.

   

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

5. सबसे नीचे मौजूद बॉटम-अप टैब खोलें. यह टैब दिखाता है कि किन गतिविधियों में सबसे ज़्यादा समय लगा. अगर आपको सबसे नीचे सेक्शन में कुछ भी दिखाई नहीं देता है, तो मुख्य सेक्शन के लेबल पर क्लिक करें.

   

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

   सेल्फ़ टाइम कॉलम में आपको यह दिखता है कि हर गतिविधि में कितना समय सीधे तौर पर बिताया गया. इस मामले में, मुख्य थ्रेड में लगने वाले समय का 82% हिस्सा mineBitcoin फ़ंक्शन पर खर्च हुआ.

यह देखा जा सकता है कि प्रोडक्शन मोड का इस्तेमाल करने और JavaScript गतिविधि को कम करने से पेज तेज़ी से लोड होता है या नहीं. प्रोडक्शन मोड का इस्तेमाल शुरू करें:

1. एडिटर टैब में, webpack.config.js खोलें.
2. "mode":"development" को "mode":"production" में बदलें.
3. नए बिल्ड के डिप्लॉय होने तक इंतज़ार करें.

4. पेज को फिर से ऑडिट करें.

   

mineBitcoin से किए गए कॉल को हटाकर JavaScript गतिविधि को कम करें:

1. एडिटर टैब में, src/App.jsx खोलें.
2. constructor में, this.mineBitcoin(1500) को किए गए कॉल के बारे में टिप्पणी करें.
3. नए बिल्ड के डिप्लॉय होने तक इंतज़ार करें.
4. पेज को फिर से ऑडिट करें.

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

मुख्य थ्रेड पर कम काम करना

आम तौर पर, परफ़ॉर्मेंस पैनल की मदद से यह समझा जा सकता है कि आपकी साइट लोड होने पर किस तरह की गतिविधि करती है. साथ ही, यह ग़ैर-ज़रूरी गतिविधि को हटाने के तरीके भी ढूंढता है.

अगर आपको कोई ऐसा तरीका पसंद है जो console.log() जैसा लगता है, तो User Timing एपीआई की मदद से अपने ऐप्लिकेशन के लाइफ़साइकल के कुछ चरणों को मनचाहे तरीके से मार्क अप किया जा सकता है. इससे, यह ट्रैक किया जा सकता है कि हर चरण में कितना समय लगता है.

खास जानकारी

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

अगले चरण

अपनी साइट पर ऑडिट चलाएं! अगर आपको अपनी रिपोर्ट को समझने या अपने लोड की परफ़ॉर्मेंस को बेहतर बनाने के तरीके खोजने में मदद चाहिए, तो DevTools समुदाय से मदद पाने के सभी तरीके देखें:

• developer.chrome.com के रिपॉज़िटरी में जाकर इस दस्तावेज़ में मौजूद गड़बड़ियों को फ़ाइल करें.
• Chromium की गड़बड़ियां पर, DevTools पर गड़बड़ी की रिपोर्ट सबमिट करें.
• मेलिंग सूची में सुविधाओं और बदलावों पर चर्चा करें. कृपया सहायता से जुड़े सवालों के जवाब पाने के लिए ईमेल पाने वाले लोगों की सूची का इस्तेमाल न करें. इसके बजाय, Stack Overflow का इस्तेमाल करें.
• Stack Overflow पर DevTools का इस्तेमाल करने के तरीके के बारे में सामान्य सहायता पाएं. गड़बड़ी के अनुरोध दर्ज करने के लिए, हमेशा Chromium Bugs का इस्तेमाल करें.
• हमें @ChromeDevTools पर ट्वीट करें.