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

खास जानकारी

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

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

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

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

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

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

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

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

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

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

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

परिचय

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

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

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

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

सेट अप करें

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

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. साइट के नए बिल्ड को डिप्लॉय करने के लिए, Glitch का इंतज़ार करें. सबसे नीचे बाएं कोने में, खुश चेहरे वाला इमोजी दिखने का मतलब है कि डिप्लॉयमेंट पूरा हो गया है.

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

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

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

   

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

   

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

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

   

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

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, पेज को फिर से लोड करता है. इसके बाद, पेज को लोड करने के लिए किए गए सभी कामों का विज़ुअलाइज़ेशन दिखाता है. इस विज़ुअलाइज़ेशन को ट्रेस कहा जाएगा.

   

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

खास जानकारी सेक्शन में पीले रंग की एक दीवार दिखने का मतलब है कि सीपीयू, स्क्रिप्टिंग गतिविधि में पूरी तरह से व्यस्त था. इससे पता चलता है कि 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. this.mineBitcoin(1500) को किए गए कॉल के बारे में constructor में टिप्पणी करें.
3. नए बिल्ड के डिप्लॉय होने का इंतज़ार करें.
4. पेज का फिर से ऑडिट करें.

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

असल दुनिया में मुख्य थ्रेड में कम काम करना

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

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

खास जानकारी

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

अगले चरण

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

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