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

खास जानकारी

अपनी वेबसाइट का पूरा ऑडिट करने के लिए, Lighthouse पैनल का इस्तेमाल करें. Lighthouse पैनल एक रिपोर्ट जनरेट करता है. इससे आपको अपनी वेबसाइट के बारे में इन चीज़ों की अहम जानकारी मिलती है:

• परफ़ॉर्मेंस
• सुलभता
• सबसे सही तरीके
• एसईओ

... और कई अन्य मेट्रिक.

इस ट्यूटोरियल की मदद से, Chrome DevTools में Lighthouse का इस्तेमाल शुरू किया जा सकता है.

Lighthouse आपकी वेबसाइट की क्वालिटी को बेहतर बनाने के अन्य तरीकों के बारे में ज़्यादा जानने के लिए, Lighthouse के दस्तावेज़ देखें.

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

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

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

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

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

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

परिचय

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

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

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

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

सेट अप करें

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

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

   

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

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

   

3. डेमो के साथ DevTools खोलें.

   

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

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

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

   

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

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

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

   

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

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

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

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

मेट्रिक

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

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

स्क्रीनशॉट

यहां कुछ स्क्रीनशॉट दिए गए हैं. इनसे पता चलता है कि पेज लोड होने के दौरान कैसा दिख रहा था.

अवसर

इसके बाद, अवसर सेक्शन दिखता है. इसमें, इस पेज के लोड होने की परफ़ॉर्मेंस को बेहतर बनाने के बारे में खास सुझाव मिलते हैं.

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

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

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

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

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

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

दूसरा चरण: एक्सपेरिमेंट

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

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

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

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

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

नेटवर्क पैनल खोलें और 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(express.static('build')) से पहले app.use(compression()) डालना न भूलें.

   

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

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

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

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

   

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

   

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

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

   

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

   

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

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

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

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

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

इमेज का साइज़ कम करने से, इमेज की फ़ाइल का साइज़ भी कम हो जाता है. इससे, इमेज लोड होने में लगने वाला समय कम हो जाता है. अगर आपका उपयोगकर्ता, 500 पिक्सल चौड़ी मोबाइल डिवाइस स्क्रीन पर आपकी इमेज देख रहा है, तो 1,500 पिक्सल चौड़ी इमेज भेजने का कोई मतलब नहीं है. आम तौर पर, ज़्यादा से ज़्यादा 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. अपने ऑपरेटिंग सिस्टम के हिसाब से, कमांड मेन्यू खोलने के लिए ये बटन दबाएं:

   • 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. नेटवर्क टैब पर क्लिक करें और कमांड मेन्यू को फिर से खोलें.

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 और सीपीयू को 6 गुना धीमा पर सेट करें.

   

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

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

   

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

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

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

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

   

   React में उपयोगकर्ता के इंतज़ार का समय मेज़र करने के कई तरीके हैं. ऐसा लगता है कि टोनी का ऐप्लिकेशन, 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() जैसा तरीका पसंद है, तो उपयोगकर्ता के समय एपीआई की मदद से, अपने ऐप्लिकेशन के लाइफ़साइकल के कुछ चरणों को मनमुताबिक मार्क किया जा सकता है. इससे यह ट्रैक किया जा सकता है कि हर चरण में कितना समय लगता है.

खास जानकारी

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

अगले चरण

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

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