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

खास जानकारी

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

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

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

नीचे दिए गए ट्यूटोरियल से, Chrome DevTools में Lighthouse का इस्तेमाल शुरू करने में मदद मिलेगी.

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

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

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

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

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

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

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

परिचय

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

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

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

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

सेट अप करें

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

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

   

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

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

   

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

   

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

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

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

   

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

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

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

   

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

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

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

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

मेट्रिक

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

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

स्क्रीनशॉट

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

अवसर

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

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

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

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

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

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

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

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

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

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

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

   

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

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

खास जानकारी

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

अगले चरण

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

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