Chrome डेवलपर सम्मेलन - परफ़ॉर्मेंस की खास जानकारी

पॉल लुईस

#perfmatters: परफ़ॉर्मेंस निंजा के लिए टूलिंग की तकनीकें

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

स्लाइड

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

#perfmatters: नेटवर्क की परफ़ॉर्मेंस को ऑप्टिमाइज़ करना

आम तौर पर, साइट के कुल पेज लोड होने में 70% समय नेटवर्क और इंतज़ार का समय शामिल होता है. यह एक बड़ा प्रतिशत है, लेकिन इसका मतलब यह भी है कि जो भी सुधार किए जाएंगे, आपके उपयोगकर्ताओं को काफ़ी फ़ायदा होगा. इस बातचीत में, इलिया ने Chrome में हाल ही में किए गए बदलावों के बारे में बताया है. इनसे, कॉन्टेंट लोड होने में लगने वाला समय बेहतर होगा. साथ ही, नेटवर्क में लोड होने की संभावना को कम से कम रखने के लिए, अपने आस-पास कुछ ऐसे बदलाव किए जा सकते हैं.

स्लाइड

  • Chrome M27 में एक नया और बेहतर रिसॉर्स शेड्यूलर है.
  • Chrome M28 ने स्पीडी साइटों को (और भी) तेज़ बना दिया है.
  • Chrome की सामान्य कैश मेमोरी में बदलाव किया गया है.
  • स्पीडी / एचटीटीपी/2.0, ट्रांसफ़र की स्पीड में काफ़ी सुधार करती है. nginx, Apache, और Jetty के लिए मैच्योर SPDY मॉड्यूल उपलब्ध हैं. सिर्फ़ तीन मॉड्यूल हैं.
  • QUIC, यूडीपी पर बना एक नया और एक्सपेरिमेंटल प्रोटोकॉल है. इसमें अभी काफ़ी काम चल रहा है. हालांकि, इस प्रोटोकॉल का इस्तेमाल उपयोगकर्ताओं को ही करना पड़ेगा.

#perfmatters: 60fps लेआउट और रेंडरिंग

अपने प्रोजेक्ट में 60 FPS (फ़्रेम प्रति सेकंड) तक का लक्ष्य, उपयोगकर्ता का जुड़ाव होता है. साथ ही, इसकी सफलता के लिए ज़रूरी है. इस बातचीत में Nat and Tom ने Chrome की रेंडरिंग पाइपलाइन के बारे में बताया है. उन्होंने बताया है कि फ़्रेम ड्रॉप होने की कुछ सामान्य वजहें क्या हैं और उनसे कैसे बचा जा सकता है.

स्लाइड

  • फ़्रेम 16 मि॰से॰ लंबा होता है. इसमें JavaScript, स्टाइल कैलकुलेशन, पेंटिंग, और कंपोज़िटिंग शामिल है.
  • पेंटिंग extremely महंगी है. पेंट स्टॉर्म में, पेंट करने की महंगी चीज़ों को बार-बार दोहराया जाता है.
  • लेयर का इस्तेमाल, पेंट किए गए एलिमेंट को कैश मेमोरी में सेव करने के लिए किया जाता है.
  • इनपुट हैंडलर (टच और माउसव्हील लिसनर) रिस्पॉन्स मिलने की सुविधा को बंद कर सकते हैं. अगर हो सके, तो इनसे बचें. जहां आप उन्हें कम से कम नहीं रख सकते.

#perfmatters: इंस्टैंट मोबाइल वेब ऐप्लिकेशन

क्रिटिकल रेंडरिंग पाथ ऐसी किसी भी चीज़ (JavaScript, एचटीएमएल, सीएसएस, इमेज) को रेफ़र करता है जिसकी ज़रूरत ब्राउज़र को पेज पेंटिंग शुरू करने से पहले होती है. ज़रूरी रेंडरिंग पाथ पर एसेट की डिलीवरी को प्राथमिकता देना ज़रूरी है. खास तौर पर, उन उपयोगकर्ताओं के लिए जो मोबाइल नेटवर्क पर स्मार्टफ़ोन जैसे नेटवर्क सीमित डिवाइस इस्तेमाल कर रहे हैं. ब्रायन ने बताया कि Google की टीम ने किस तरह PageSpeed Insights वेबसाइट के लिए एसेट की पहचान करने और उन्हें प्राथमिकता देने की प्रक्रिया को पूरा किया. इस दौरान, पेज लोड होने में 20 सेकंड से लेकर सिर्फ़ 1 सेकंड तक का समय लगा!

स्लाइड

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