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

खास जानकारी

अपनी वेबसाइट का अच्छी तरह से ऑडिट करने के लिए, 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 कॉल स्टैक जोड़ता है. हालांकि, इससे रिपोर्ट जनरेट होने में ज़्यादा समय लग सकता है. Lighthouse रिपोर्ट जनरेट होने के बाद, यह ट्रेस more_vert टूल मेन्यू > बिना थ्रॉटल किए गए ट्रेस देखें में उपलब्ध होता है.
   • सिम्युलेटेड थ्रॉटलिंग (डिफ़ॉल्ट) arrow_drop_down. यह विकल्प, मोबाइल डिवाइस पर ब्राउज़ करने की सामान्य स्थितियों को सिम्युलेट करता है. इसे "सिमुलेट किया गया" इसलिए कहा जाता है, क्योंकि ऑडिट करने की प्रोसेस के दौरान Lighthouse, असल में थ्रॉटल नहीं करता. इसके बजाय, यह सिर्फ़ अनुमान लगाता है कि मोबाइल स्थितियों में पेज को लोड होने में कितना समय लगेगा. वहीं दूसरी ओर, 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. Lighthouse पैनल खोलें और सबसे ऊपर मौजूद ऐक्शन बार में, ऑडिट करें... पर क्लिक करें.

   

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. अपने ऑपरेटिंग सिस्टम के हिसाब से, कमांड मेन्यू खोलने के लिए ये बटन दबाएं:

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

   

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

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

   

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

खास जानकारी सेक्शन में पीले रंग की एक दीवार दिखने का मतलब है कि सीपीयू, स्क्रिप्टिंग गतिविधि में पूरी तरह से व्यस्त था. यह एक संकेत है कि कम 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 Bugs पर जाकर, DevTools में गड़बड़ी की रिपोर्ट दर्ज करें.
• मेल सूची में सुविधाओं और बदलावों के बारे में चर्चा करें. कृपया सहायता से जुड़े सवालों के लिए, ईमेल पाने वाले लोगों की सूची का इस्तेमाल न करें. इसके बजाय, Stack Overflow का इस्तेमाल करें.
• Stack Overflow पर DevTools का इस्तेमाल करने के तरीके के बारे में सामान्य सहायता पाएं. गड़बड़ी के अनुरोध करने के लिए, हमेशा Chromium Bugs का इस्तेमाल करें.
• हमें @ChromeDevTools पर ट्वीट करें.