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

ट्यूटोरियल का मकसद

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

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

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

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

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

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

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

चरण 1: साइट की जांच करें

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

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

सेट अप करें

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

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

   

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

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

   

3. डेमो के बगल में मौजूद, DevTools खोलें.

   

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

परफ़ॉर्मेंस में कोई भी सुधार करने से पहले, साइट की परफ़ॉर्मेंस का रिकॉर्ड बेसलाइन होता है.

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

   

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

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

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

   

रिपोर्ट की गड़बड़ियां ठीक करना

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

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

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

मेट्रिक

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

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

स्क्रीनशॉट

आगे स्क्रीनशॉट का एक कलेक्शन है. इसमें दिखाया गया है कि पेज कैसा दिखता है.

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

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

किसी ऑपर्च्यूनिटी के बारे में ज़्यादा जानने के लिए, उस पर क्लिक करें.

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

गड़बड़ी की जानकारी

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

पास हो चुके ऑडिट

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

दूसरा चरण: प्रयोग

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

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

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

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

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

नेटवर्क पैनल खोलें और 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 kB में है. इसे नेटवर्क पैनल के सबसे नीचे मौजूद स्टेटस बार पर देखा जा सकता है.

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

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

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

रेंडर ब्लॉक करने वाले संसाधनों को खत्म करें

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

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

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

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

   

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

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

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

   

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

   

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

   

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

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

   

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

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

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

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

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. लाइटहाउस पैनल से पेज को फिर से ऑडिट करें. आपका कुल स्कोर फिर से बेहतर हो जाएगा.

   

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

ज़रूरी रेंडरिंग पाथ उस कोड के बारे में बताता है जो आपको कोई पेज लोड करना होगा. आम तौर पर, पेज लोड होने के दौरान सिर्फ़ ज़रूरी कोड भेजकर और फिर बाकी सब कुछ लेज़ी लोडिंग से, पेज लोड होने की स्पीड बढ़ाई जा सकती है.

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

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

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

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

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

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

   

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

2. फिर से लोड करें पर क्लिक करें. DevTools पेज को फिर से लोड करता है और फिर पेज को लोड करने के लिए की जाने वाली सभी चीज़ों का विज़ुअलाइज़ेशन बनाता है. इस विज़ुअलाइज़ेशन को trace कहा जाएगा.

   

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

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

ट्रेस की जांच करके JavaScript से कम काम करने के तरीके खोजें:

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

   

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

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 की गड़बड़ियों का इस्तेमाल करें.
• हमें @ChromeDevTools पर ट्वीट करें.