शुरुआती जानकारी
तेज़ वेब ऐप्लिकेशन एक सफल वेब ऐप्लिकेशन है. डेवलपर के तौर पर आपका काम तब तक नहीं होता, जब तक आप अपने ऐप्लिकेशन की असल और अनुमानित परफ़ॉर्मेंस, दोनों को ऑप्टिमाइज़ न कर दें. न सिर्फ़ उपयोगकर्ताओं को बेहतरीन अनुभव मिले, यह पक्का करना ही सही काम है, बल्कि इसे ऑप्टिमाइज़ करने के लिए कारोबारी और व्यावहारिक वजहें भी हैं. Amazon ने साइट के हर 100 मिलीसेकंड पर बिक्री में 1% की गिरावट देखी और Google ने हर 0.5 सेकंड की देरी (उद्धरण) पर ट्रैफ़िक में 20% की गिरावट को मापा. ये असल संख्याएं हैं, जिनका आपके कारोबार और वेब ऐप्लिकेशन पर असल में असर पड़ता है.
वेब स्पीड बहुत ज़रूरी है. Google ने वेब को तेज़ बनाने के लिए पूरी कोशिश भी की है. अगर आपको अपने ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने की कोई और वजह चाहिए, तो Google ने बताया है कि पेज स्पीड को उनके रैंकिंग एल्गोरिदम में जोड़ दिया गया है.
आपके वेब ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, पब्लिश किए गए कई सबसे सही तरीके हैं. इनमें दो बेहतरीन किताबें शामिल हैं, जैसे कि अच्छी परफ़ॉर्मेंस वाली वेब साइटें और ज़्यादा तेज़ चलने वाली वेब साइटें. परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, सर्वर और क्लाइंट (इमेज की चौड़ाई और ऊंचाई एट्रिब्यूट) की तकनीकों को एंड-टू-एंड रणनीति में शामिल कर दिया जाता है. इन तकनीकों को कैश कंट्रोल के सही हेडर के तौर पर लागू करना और क्लाइंट की इमेज की चौड़ाई और लंबाई से जुड़े एट्रिब्यूट का इस्तेमाल करना शामिल है. इतने सारे सुझावों और तरकीबों के साथ, कभी-कभी यह मापना मुश्किल होता है कि वे सभी असल ज़िंदगी और आपके असली वेब ऐप्लिकेशन पर कैसे मैप करते हैं.
अच्छी बात यह है कि Chrome DevTools (Chrome के सभी इंस्टेंस में शामिल है) एक ऐसा बेहतरीन टूल देता है जो आपके वेब ऐप्लिकेशन की जांच करता है. साथ ही, आपके ऐप्लिकेशन की परफ़ॉर्मेंस बेहतर बनाने और इंतज़ार के समय को कम करने के लिए, आपकी ज़रूरत के मुताबिक सुझाव देता है. इस लेख में ऑडिट पैनल की जानकारी दी गई है, जो बहुत लोकप्रिय YSlow टूल की तरह ही है. साथ ही, यह भी बताया गया है कि इसका इस्तेमाल अपनी वेबसाइट की रफ़्तार बढ़ाने, इंतज़ार का समय कम करने, और उपयोगकर्ता को बेहतर अनुभव देने के लिए कैसे किया जा सकता है.
ध्यान दें कि ऑडिट पैनल टूल सिर्फ़ Chrome में ही उपलब्ध है. हालांकि, हमें उम्मीद है कि अन्य WebKit ब्राउज़र फ़िलहाल इसे इंटिग्रेट करेंगे.
YouTube पर शुरुआत करना
हम यह बताने के लिए कि ऑडिट पैनल, वेब ऐप्लिकेशन प्रदर्शन को बेहतर बनाने के सुझाव कैसे दे सकता है, हम टूल को अपने www.html5rocks.com पर ले जाएंगे. हम अपनी साइट को और भी तेज़ बनाने में सहायता के लिए ऑडिट पैनल का इस्तेमाल करेंगे.
DevTools शुरू करना, Chrome आइकॉन (Chrome विंडो के ऊपर दाईं ओर) का इस्तेमाल करने और टूल > डेवलपर टूल को चुनने जितना ही आसान है.
DevTools का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, कृपया आधिकारिक दस्तावेज़ पढ़ें.
ऑडिट पैनल, मुख्य टूल बटन पैनल में मौजूद है. आपने देखा होगा कि एक बार चुने जाने के बाद, ऑडिट पैनल अब तक आपके वेब ऐप्लिकेशन के विश्लेषण तक नहीं पहुंच पाता है. सभी अनुमानों को धीमा किया जा सकता है, खास तौर पर Gmail जैसे किसी बड़े वेब ऐप्लिकेशन के लिए, इसलिए टूल डिफ़ॉल्ट रूप से बंद हो जाता है.
चलिए, 'रन' बटन पर क्लिक करके इस बारे में ज़्यादा जानें. इससे, वेब ऐप्लिकेशन फिर से लोड हो जाता है और परफ़ॉर्मेंस का आकलन करने की सुविधा चालू हो जाती है. पेज फिर से लोड होने के बाद, आपको नीचे दिए गए स्क्रीनशॉट से मिलते-जुलते सुझावों की सूची दिखेगी.
आपने देखा कि ऑडिट पैनल, सुझावों को गंभीरता के आधार पर अलग-अलग कैटगरी में दिखाता है. इसमें सबसे गंभीर को लाल बिंदु से और मध्यम गंभीरता वाले सुझावों को पीले बिंदु से मार्क किया गया है. यह कलर कोडिंग आपको सुझावों को प्राथमिकता देने में मदद करती है. इसमें सबसे ज़्यादा ज़रूरी (और सबसे बड़े फ़ायदों) पर फ़ोकस किया जाता है.
ऑडिट टूल ने सुझाव के बाद ब्रैकेट में दी गई संख्या का पता लगाया है. उदाहरण के लिए, "ब्राउज़र की कैश मेमोरी का इस्तेमाल करें" के 12 उदाहरण हैं. इससे आपको यह पता चलता है कि सुझाव को कितनी बार लागू किया जा सकता है.
स्पीड से जुड़ी रणनीतियां
जैसा कि पहले बताया गया है, वेब ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, कई जानी-मानी और काफ़ी टेस्ट की गई रणनीतियां हैं. इस लेख में, हम इन सभी के बारे में नहीं बताएंगे. हालांकि, इनके बारे में ज़्यादा जानकारी और अन्य जानकारी आसानी से खोजी जा सकती है. वेब ऐप्लिकेशन ऑप्टिमाइज़ेशन की खास बातों के बारे में ज़्यादा जानने के लिए, वेब ऐप्लिकेशन को ज़्यादा तेज़ बनाने वाले ट्यूटोरियल और ज़्यादा स्केलिंग के इंतज़ार का समय हर जगह पर है और बिक्री पर आपका खर्च आता है, इन संसाधनों से आपको मदद मिल सकती है.
ऑडिट पैनल अपने सुझावों को दो कैटगरी में बांटता है, नेटवर्क यूटिलाइज़ेशन और वेब पेज परफ़ॉर्मेंस.
ऑडिट पैनल के मुताबिक, नेटवर्क इस्तेमाल को बेहतर बनाने के लिए हमें ये काम करने चाहिए:
- ब्राउज़र कैशिंग का फ़ायदा उठाएं
- प्रॉक्सी कैशिंग का फ़ायदा उठाएं
- कुकी का साइज़ कम करें
- बिना कुकी वाले डोमेन से स्टैटिक कॉन्टेंट दिखाना
- इमेज का डाइमेंशन तय करें
वेब पेज की परफ़ॉर्मेंस को बेहतर बनाने के लिए, हमें ये काम करने चाहिए:
- स्टाइल और स्क्रिप्ट का क्रम ऑप्टिमाइज़ करना
- इस्तेमाल नहीं किए गए सीएसएस नियमों को हटाएं
आइए, उन रणनीतियों पर नज़र डालते हैं जिन पर हम htmlrocks.com की परफ़ॉर्मेंस को बेहतर बनाने पर फ़ोकस कर सकते हैं.
ब्राउज़र कैश मेमोरी का फ़ायदा लें
उदाहरण के लिए, सबसे पहले ब्राउज़र की कैश मेमोरी का फ़ायदा लेने के लिए सुझावों के बारे में जानें. खास तौर पर, इसका क्या मतलब है? यूज़र इंटरफ़ेस (यूआई) में इस विकल्प को खोलने पर, हमें नीचे दी गई जानकारी दिखाई गई है:
- नीचे दिए गए रिसॉर्स में, कैश मेमोरी की समयसीमा खत्म होने की तारीख मौजूद नहीं है. जिन रिसॉर्स में ऐक्सेस की समयसीमा खत्म होने की जानकारी नहीं दी जाती है, हो सकता है कि ब्राउज़र उन्हें कैश मेमोरी में सेव न करें.
- कैश मेमोरी में सेव किए जा सकने वाले इन रिसॉर्स को, लंबे समय तक अपडेट रखा जाता है.
- इन रिसॉर्स को कैश मेमोरी में सेव नहीं किया जा सकता. अगर हो सके, तो उन्हें कैश मेमोरी में सेव करने लायक बनाएं.
नेटवर्क के इस्तेमाल को बेहतर बनाने के लिए, संसाधनों को कैश मेमोरी में सेव करना एक शानदार तरीका है. इससे डेवलपर को कम बैंडविड्थ का बिल मिलता है और उपयोगकर्ता को ज़्यादा तेज़ी से जवाब मिलते हैं. माफ़ करें, टूल से आपको यह जानकारी नहीं मिलती कि आपको क्या करना है. इसलिए, हमें सुझावों को ध्यान से देखना होगा. साथ ही, इन सुझावों को लागू करने के लिए, वेब ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के बारे में अपनी जानकारी का इस्तेमाल करना होगा.
कैश मेमोरी में सेव करना
एचटीटीपी कैश मेमोरी के बिना, हम कुछ बुनियादी बातें तय कर सकते हैं. एचटीटीपी प्रोटोकॉल में कैश मेमोरी के निर्देश शामिल होते हैं. इससे सर्वर और क्लाइंट को उस डेटा की मात्रा कम करने की सुविधा मिलती है जिसे वायर पर ट्रांसफ़र करने की ज़रूरत होती है. उदाहरण के लिए, सर्वर, क्लाइंट को एक तय समय के लिए स्थानीय तौर पर रिसॉर्स को सेव करने के लिए कह सकता है. इस तरह, रिसॉर्स के लिए फिर से अनुरोध करने की ज़रूरत नहीं होती. क्लाइंट यह भी पूछ सकता है कि सर्वर का रिसॉर्स, लोकल स्टोरेज में सेव किए गए रिसॉर्स से नया है या नहीं. आम तौर पर, अगर कोई रिसॉर्स स्टैटिक है, तो सर्वर को क्लाइंट को रिसॉर्स को लोकल स्टोरेज में सेव करने के लिए कहना चाहिए. साथ ही, आने वाले समय में सर्वर से रिसॉर्स के लिए पूछने से बचना चाहिए. आप कल्पना कर सकते हैं कि एचटीटीपी कैश मेमोरी के बारे में बहुत ज़्यादा जानकारी मौजूद है. हालांकि, सामान्य थीम है "क्लाइंट को स्थानीय तौर पर स्टोर करके वायर के ज़रिए भेजे जाने वाले डेटा की मात्रा को कम करना".
कैश मेमोरी में सेव नहीं किए जा सकने वाले संसाधनों की समस्या हल करना
आइए, एक सुझाव पर गहराई से नज़र डालते हैं. साथ ही, DevTools के अंदर दिए गए अन्य टूल से, ऑडिट सुझाव को जोड़ने का तरीका जानें. खास तौर पर, "नीचे दिए गए रिसॉर्स साफ़ तौर पर कैश मेमोरी में सेव नहीं किए जा सकते" को ठीक करने का तरीका देखते हैं.
कैशिंग की प्रक्रिया एचटीटीपी प्रोटोकॉल के ज़रिए होती है. इसलिए, हमें एचटीटीपी अनुरोध और http://www.html5rocks.com/ संसाधन के लिए रिस्पॉन्स देखने की ज़रूरत है. मूल अनुरोध, रिस्पॉन्स हेडर, और जानकारी देखने के लिए, बस रिसॉर्स पर क्लिक करें.
इसके बाद आपको और जानकारी के साथ नेटवर्क, संसाधन या स्रोत पैनल (क्लिक किए गए संसाधन के प्रकार के आधार पर) पर ले जाया जाता है. इस मामले में, हमें नेटवर्क पैनल पर ले जाया जाएगा.
हम इस बात की पुष्टि करने की कोशिश कर रहे हैं कि सर्वर ने क्लाइंट को यह बताया है कि "html5rocks.com के होम पेज को कैश मेमोरी में सेव न करें". ऐसा करने के लिए, हम रिस्पॉन्स हेडर देखने के लिए रिसॉर्स पर क्लिक करते हैं, क्योंकि ये सर्वर से भेजे गए हेडर और निर्देश होते हैं.
Cache-Control हेडर.ठीक है, सर्वर ने क्लाइंट को "कैश-कंट्रोल: कोई कैश मेमोरी नहीं" हेडर भेजा है. इस प्रोसेस से, आपने जैसा सोचा है कि इस प्रोसेस से, क्लाइंट को रिसॉर्स की जानकारी मांगने के लिए कहा जाता है. साथ ही, रिसॉर्स को स्थानीय तौर पर कैश मेमोरी में सेव न करने के लिए भी कहा जाता है. खास तौर पर, "नो-कैश मेमोरी" के लिए एचटीटीपी की खास जानकारी में यह जानकारी मिलती है:
"अगर नो-कैश निर्देश किसी फ़ील्ड का नाम नहीं बताता है, तो कैश मेमोरी में सेव किए गए रिस्पॉन्स का इस्तेमाल, ऑरिजिन सर्वर के साथ फिर से पुष्टि किए बिना, बाद के अनुरोध को पूरा करने के लिए नहीं किया जाना चाहिए. यह ऑरिजिन सर्वर को उन कैश मेमोरी से भी कैश मेमोरी में डेटा सेव होने से रोकने की अनुमति देता है जो क्लाइंट के अनुरोधों के पुराने रिस्पॉन्स लौटाने के लिए कॉन्फ़िगर किए गए होते हैं."
ऑडिट पैनल कैश मेमोरी की सुविधा चालू करने का सुझाव देता है, क्योंकि ऐसा न होने पर सर्वर और क्लाइंट ऐसी जानकारी भेज रहे हैं जो ज़रूरी नहीं है.
अब जब हमने ऑडिट के सुझाव की असल वजह की पुष्टि कर ली है, तो हम उसे कैसे ठीक करते हैं? इस मामले में, समाधान में सर्वर साइड कॉन्फ़िगरेशन या कोड शामिल है. अपने सेटअप के आधार पर, वेब सर्वर के कॉन्फ़िगरेशन या वेब ऐप्लिकेशन फ़्रेमवर्क में कॉन्फ़िगरेशन के ज़रिए कैश मेमोरी में सेव करने की सुविधा चालू की जा सकती है. खास तौर पर, आपको किसी भी ऐसे रिसॉर्स के लिए, समयसीमा खत्म होने वाला हेडर और कैश कंट्रोल: निजी को शामिल करना चाहिए. इस फ़ील्ड में, सबसे ज़्यादा उम्र के पैरामीटर का इस्तेमाल किया जाना चाहिए.
सुझाव बस यही हैं, सुझाव
याद रखें कि ऑडिट पैनल सामान्य अनुभव के आधार पर सुधारों का सुझाव दे रहा है. यह आपके खास वेब ऐप्लिकेशन पर, कई सालों के दौरान सीखे गए सबसे सही तरीके लागू कर रहा है. ज़्यादातर सुझाव सही होते हैं और इन्हें ध्यान में रखा जाना चाहिए.
हालांकि, कुछ मामले ऐसे होते हैं जहां सुझाव सही हो सकता है, लेकिन असल में ऐसा नहीं होता. उदाहरण के लिए, अगर आपके पेज में सिर्फ़ एक बड़ी इमेज है, तो ऑडिट पैनल <img> टैग में चौड़ाई और ऊंचाई एट्रिब्यूट जोड़ने का सुझाव देगा. इससे रेंडरिंग इंजन, इमेज को डाउनलोड और जांच किए बिना उसके डाइमेंशन के बारे में जान पाता है. आम तौर पर, यह अच्छी सलाह होती है. हालांकि, अगर पेज पर सिर्फ़ इमेज ही मौजूद है, तो इससे ज़्यादा मदद नहीं मिलेगी.
सुझावों को समझ लेने के बाद उन्हें लागू करना न भूलें. साथ ही, बदलावों से पहले और बाद की परफ़ॉर्मेंस को मेज़र करना न भूलें, ताकि यह पक्का हो सके कि वाकई सुधार आया है.
खास जानकारी
ऑडिट पैनल एक बेहतरीन और इस्तेमाल में आसान टूल है. इसकी मदद से, आपको अपने वेब ऐप्लिकेशन की परफ़ॉर्मेंस को तुरंत ऑप्टिमाइज़ करने का तरीका पता चलेगा. वेब ऐप्लिकेशन का स्पीड एक अहम एट्रिब्यूट है, क्योंकि कई कंपनियों को परफ़ॉर्मेंस और आय या गतिविधि के बीच सीधा संबंध मिला है. अपने ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करना, सिर्फ़ उपयोगकर्ताओं के लिए सही नहीं है, बल्कि अपने कारोबार को आगे बढ़ाने के लिए भी ऐसा करना सही है.