PageSpeed Insights टूल किसी पेज का विश्लेषण करता है. इससे यह पता चलता है कि वह पेज, मोबाइल नेटवर्क पर किसी पेज को एक सेकंड से भी कम समय में रेंडर करने के लिए, हमारे सुझावों का पालन करता है या नहीं. रिसर्च से पता चला है कि एक सेकंड से ज़्यादा देरी करने पर, उपयोगकर्ता को अपने सोचने-समझने में रुकावट होगी और उन्हें खराब अनुभव मिलेगा. हमारा मकसद, उपयोगकर्ता को पेज से जोड़े रखना और बेहतरीन अनुभव देना है. भले ही, डिवाइस या नेटवर्क किसी भी तरह का हो.
एक सेकंड के बजट को पूरा करना आसान नहीं है. हमारे लिए अच्छी बात यह है कि इस बजट में पूरा पेज रेंडर नहीं करना पड़ता. हमें ऊपर दिए गए फ़ोल्ड (ATF) कॉन्टेंट को एक सेकंड के अंदर डिलीवर और रेंडर करना होगा. इससे उपयोगकर्ता, पेज पर जल्द से जल्द इंटरैक्ट कर पाएगा. जब उपयोगकर्ता कॉन्टेंट के पहले पेज को समझ रहा हो, तब बाकी के पेज को धीरे-धीरे बैकग्राउंड में दिखाया जा सकता है.
ज़्यादा इंतज़ार वाले मोबाइल नेटवर्क पर काम करना
मोबाइल डिवाइसों पर एक सेकंड के एटीएफ़ मापदंड को पूरा करना, कुछ अनोखी चुनौतियों का सामना करना पड़ता है, जो अन्य नेटवर्क पर मौजूद नहीं हैं. ऐसा हो सकता है कि उपयोगकर्ता आपकी साइट को अलग-अलग 2G, 3G, और 4G नेटवर्क से ऐक्सेस कर रहे हों. नेटवर्क के इंतज़ार का समय, वायर वाले कनेक्शन की तुलना में काफ़ी ज़्यादा होता है. यह ATF कॉन्टेंट को रेंडर करने के लिए, हमारे 1000 मिलीसेकंड के बजट का एक बड़ा हिस्सा इस्तेमाल करता है.
दुनिया भर में 4G नेटवर्क टाइप सबसे ज़्यादा है. इसलिए, आपको उम्मीद करनी चाहिए कि ज़्यादातर उपयोगकर्ता आपके पेज को 4G नेटवर्क पर ऐक्सेस करेंगे. इस वजह से, हमें यह मानकर चलना होगा कि हर नेटवर्क अनुरोध में औसतन 100 मिलीसेकंड लग सकते हैं.
इस बात को ध्यान में रखते हुए, आइए अब पीछे की ओर काम करते हैं. अगर हम किसी ब्राउज़र और सर्वर के बीच बातचीत का सामान्य क्रम देखें, तो नेटवर्क ओवरहेड में उस समय का 300 मि॰से॰ पहले ही इस्तेमाल किया जा चुका है: होस्टनेम (जैसे कि google.com) का किसी आईपी पते से समाधान करने के लिए डीएनएस लुकअप, टीसीपी हैंडशेक करने के लिए नेटवर्क राउंडट्रिप, और एक वैकल्पिक TLS कनेक्शन. इससे हमें 700 मिलीसेकंड हो जाते हैं.
एक सेकंड के बाद रेंडर होने का अनुभव दें
नेटवर्क के इंतज़ार के समय को घटाने के बाद, हमारे पास अपने बजट में सिर्फ़ 700 मिलीसेकंड बचे हैं. हमें अभी इस पर बहुत काम करना बाकी है: सर्वर को रिस्पॉन्स रेंडर करना होगा, क्लाइंट-साइड ऐप्लिकेशन कोड लागू होना चाहिए, और ब्राउज़र को कॉन्टेंट का लेआउट बनाकर उसे रेंडर करना होगा. इस बात को ध्यान में रखते हुए, नीचे दिए गए मानदंडों से हमें बजट के अंदर बने रहने में मदद मिलनी चाहिए:
- (1) सर्वर को प्रतिक्रिया रेंडर करनी होगी (< 200 ms)
- सर्वर से रिस्पॉन्स मिलने में लगने वाला समय, वह समय होता है जो सर्वर को शुरुआती एचटीएमएल कोड दिखाने में लगता है. इस वजह से, नेटवर्क ट्रांसपोर्ट में लगने वाला समय कम होता है. हमारे पास बहुत कम समय है, इसलिए इस समय को कम से कम 200 मिलीसेकंड में और खास तौर पर इससे भी कम रखा जाना चाहिए!
- (2) रीडायरेक्ट की संख्या कम से कम होनी चाहिए
- ज़्यादा एचटीटीपी रीडायरेक्ट, एक या दो अतिरिक्त नेटवर्क राउंडट्रिप (अगर अतिरिक्त डीएनएस लुकअप की ज़रूरत हो तो दो) जोड़ सकते हैं. इससे 4G नेटवर्क पर सैकड़ों मिलीसेकंड अतिरिक्त इंतज़ार का समय लगता है. इस वजह से, हम वेबमास्टर को सलाह देते हैं कि इस संख्या को कम से कम रखें और रीडायरेक्ट को पूरी तरह खत्म कर दें - यह एचटीएमएल दस्तावेज़ के लिए खास तौर पर ज़रूरी है (जहां संभव हो, “m dot” रीडायरेक्ट से बचें).
- (3) पहले रेंडर के लिए राउंडट्रिप की संख्या कम से कम होनी चाहिए
-
टीसीपी, कनेक्शन की क्षमता का अनुमान कैसे लगाता है (जैसे कि टीसीपी स्लो स्टार्ट), इस वजह से नया टीसीपी कनेक्शन, क्लाइंट और सर्वर के बीच उपलब्ध पूरी बैंडविड्थ का तुरंत इस्तेमाल नहीं कर सकता. इस वजह से, सर्वर पहली राउंडट्रिप में नए कनेक्शन पर करीब 10 टीसीपी पैकेट (~14 केबी) भेज सकता है. इसके बाद, सर्वर को तब तक इंतज़ार करना होगा, जब तक क्लाइंट इस डेटा को स्वीकार नहीं करता. इसके बाद ही, वह ज़्यादा डेटा भेजने वाली विंडो को बढ़ा सकता है और ज़्यादा डेटा डिलीवर कर सकता है.
यह भी ध्यान रखें कि 10 पैकेट (IW10) की सीमा, टीसीपी स्टैंडर्ड में हाल ही में किया गया अपडेट है: इस बदलाव का फ़ायदा पाने के लिए, आपको पक्का करना होगा कि आपका सर्वर नए वर्शन में अपग्रेड किया गया हो. ऐसा न करने पर, यह सीमा 3-4 पैकेट की हो सकती है!
टीसीपी के इस व्यवहार की वजह से, अपने कॉन्टेंट को ऑप्टिमाइज़ करना ज़रूरी है, ताकि पेज का पहला रेंडर पूरा करने के लिए, ज़रूरी डेटा डिलीवर करने के लिए ज़रूरी राउंडट्रिप की संख्या कम से कम रखी जा सके. आम तौर पर, ATF का कॉन्टेंट 98 केबी से कम होना चाहिए. इससे ब्राउज़र, सिर्फ़ तीन राउंडट्रिप के बाद पेज को पेंट कर पाता है. इससे, सर्वर को रिस्पॉन्स मिलने में लगने वाले समय और क्लाइंट रेंडरिंग के लिए काफ़ी समय मिल जाता है.
- (4) पेज के ऊपरी हिस्से के कॉन्टेंट में बाहरी JavaScript और सीएसएस को ब्लॉक करने से बचें
-
इससे पहले कि ब्राउज़र, उपयोगकर्ता को कोई पेज रेंडर कर सके, उसे पेज को पार्स करना पड़ता है. अगर पार्स करते समय, इसे नॉन-एसिंक्रोनस या बाहरी स्क्रिप्ट को ब्लॉक करने वाली स्क्रिप्ट मिलती है, तो संसाधन को रोकना और डाउनलोड करना ज़रूरी है. हर बार ऐसा करने पर, नेटवर्क के साथ दोतरफ़ा यात्रा को जोड़ा जाता है. इससे पेज को पहली बार रेंडर होने में ज़्यादा समय लगता है.
नतीजे के तौर पर, पेज के ऊपरी हिस्से को रेंडर करने के लिए ज़रूरी JavaScript और सीएसएस को इनलाइन किया जाना चाहिए. साथ ही, पेज में अतिरिक्त फ़ंक्शन जोड़ने के लिए ज़रूरी JavaScript या सीएसएस को ATF कॉन्टेंट डिलीवर होने के बाद लोड किया जाना चाहिए.
- (5) ब्राउज़र लेआउट और रेंडरिंग के लिए समय रिज़र्व करें (200 मि॰से॰)
- एचटीएमएल, सीएसएस, और JavaScript को लागू करने में समय और क्लाइंट के संसाधन लगते हैं! मोबाइल डिवाइस की गति और पेज की जटिलता के आधार पर, इस प्रक्रिया में सैकड़ों मिलीसेकंड लग सकते हैं. हमारा सुझाव है कि ब्राउज़र ओवरहेड के लिए 200 मिलीसेकंड रिज़र्व रखें.
- (6) JavaScript के चलने और रेंडरिंग के समय को ऑप्टिमाइज़ करना
- जटिल स्क्रिप्ट और काम न करने वाले कोड को लागू करने में दस से सैकड़ों मिलीसेकंड लग सकते हैं - अपने कोड की प्रोफ़ाइल बनाने और उसे ऑप्टिमाइज़ करने के लिए, ब्राउज़र में पहले से मौजूद डेवलपर टूल का इस्तेमाल करें. शानदार परिचय के लिए, Chrome डेवलपर टूल के लिए हमारा इंटरैक्टिव कोर्स देखें.
अक्सर पूछे जाने वाले सवाल
- मैं JavaScript लाइब्रेरी का इस्तेमाल कर रहा/रही हूं, जैसे कि JQuery, कोई सलाह?
- JQuery जैसी कई JavaScript लाइब्रेरी का इस्तेमाल, पेज को बेहतर बनाने के लिए किया जाता है, ताकि इसमें ज़्यादा इंटरैक्टिविटी, ऐनिमेशन, और दूसरे इफ़ेक्ट जोड़े जा सकें. हालांकि, एटीएफ़ कॉन्टेंट रेंडर होने के बाद, इनमें से कई गतिविधियों को सुरक्षित तरीके से जोड़ा जा सकता है. पेज के लोड होने तक ऐसे JavaScript को लागू करने और लोड करने की प्रक्रिया की जांच करें.
- मैं पेज बनाने के लिए, JavaScript फ़्रेमवर्क का इस्तेमाल कर रहा/रही हूं. क्या कोई सलाह है?
- अगर पेज के कॉन्टेंट को क्लाइंट-साइड JavaScript की मदद से बनाया गया है, तो नेटवर्क के एक हिस्से से दूसरे हिस्से में जाने से बचने के लिए, आपको काम के JavaScript मॉड्यूल को इनलाइन करने की जांच करनी चाहिए. इसी तरह, सर्वर साइड रेंडरिंग का इस्तेमाल करने से, पहले पेज के लोड होने की परफ़ॉर्मेंस बेहतर हो सकती है: सर्वर पर JS टेंप्लेट रेंडर करें और नतीजों को एचटीएमएल में इनलाइन करें. इसके बाद, ऐप्लिकेशन लोड होने पर क्लाइंट-साइड टेंप्लेट का इस्तेमाल करें.
- मैं अपने पेज पर मौजूद ज़रूरी सीएसएस की पहचान कैसे करूं?
- Chrome डेवलपर टूल में, ऑडिट पैनल खोलें और वेब पेज की परफ़ॉर्मेंस रिपोर्ट चलाएं. इसके बाद, जनरेट की गई रिपोर्ट में जाकर, इस्तेमाल नहीं किए गए सीएसएस नियमों को हटाएं की जानकारी देखें. इसके अलावा, यह जानने के लिए तीसरे पक्ष के किसी अन्य टूल या स्क्रिप्ट का इस्तेमाल करें कि हर पेज पर कौनसे सीएसएस सिलेक्टर लागू किए गए हैं.
- क्या ये सबसे सही तरीके ऑटोमेटेड हो सकते हैं?
- बिलकुल. ऐसे कई व्यावसायिक और ओपन-सोर्स वेब परफ़ॉर्मेंस ऑप्टिमाइज़ेशन (डब्ल्यूपीओ) प्रॉडक्ट हैं जो ऊपर दी गई कुछ या सभी शर्तों को पूरा करने में आपकी मदद कर सकते हैं. ओपन सोर्स समाधानों के लिए, PageSpeed ऑप्टिमाइज़ेशन टूल पर एक नज़र डालें.
- मैं इन शर्तों को पूरा करने के लिए अपने सर्वर को कैसे ट्यून करूं?
-
सबसे पहले, पक्का करें कि आपके सर्वर पर, ऑपरेटिंग सिस्टम का अप-टू-डेट वर्शन इस्तेमाल किया जा रहा हो. बढ़े हुए शुरुआती टीसीपी कंजेशन विंडो साइज़ (IW10) का फ़ायदा पाने के लिए, आपको Linux कर्नेल 2.6.39 के बाद के वर्शन की ज़रूरत होगी. अन्य ऑपरेटिंग सिस्टम के लिए, दस्तावेज़ देखें.
सर्वर के रिस्पॉन्स टाइम को ऑप्टिमाइज़ करने के लिए, अपना कोड इस्तेमाल करें या ऐप्लिकेशन मॉनिटरिंग की सुविधा का इस्तेमाल करके, बॉटलनेक की पहचान करें. उदाहरण के लिए, स्क्रिप्टिंग रनटाइम, डेटाबेस कॉल, आरपीसी अनुरोध, रेंडरिंग वगैरह. इसका मकसद एचटीएमएल रिस्पॉन्स को 200 मिलीसेकंड में रेंडर करना होता है. - कॉन्टेंट की सुरक्षा के बारे में नीति क्या है?
- अगर आपने सीएसपी का इस्तेमाल किया है, तो आपको अपनी डिफ़ॉल्ट नीति अपडेट करनी पड़ सकती है.
सबसे पहले, एचटीएमएल एलिमेंट पर इनलाइन सीएसएस एट्रिब्यूट(जैसे,< p style=...>) का इस्तेमाल करने से बचना चाहिए. ऐसा इसलिए होता है, क्योंकि अक्सर इनसे ग़ैर-ज़रूरी कोड डुप्लीकेट होते हैं. साथ ही, इन्हें सीएसपी के साथ डिफ़ॉल्ट रूप से ब्लॉक कर दिया जाता है ("style-src" पर "असुरक्षित इनलाइन" की मदद से बंद किया गया). अगर सीएसपी चालू है, तो डिफ़ॉल्ट रूप से सभी इनलाइन स्क्रिप्ट टैग ब्लॉक हो जाएंगे. अगर आपके पास इनलाइन JavaScript है, तो आपको सीएसपी नीति को अपडेट करना होगा. इसके लिए, स्क्रिप्ट हैश या नॉन्स का इस्तेमाल किया जा सकता है या सभी इनलाइन स्क्रिप्ट को चलाने के लिए, “unsafe-inline” का इस्तेमाल किया जा सकता है. अगर आपके पास इनलाइन स्टाइल हैं, तो आपको स्टाइल हैश या नॉन्स इस्तेमाल करने के लिए सीएसपी नीति को अपडेट करना होगा. इसके अलावा, सभी इनलाइन स्टाइल ब्लॉक को प्रोसेस करने के लिए, "unsafe-inline" का इस्तेमाल किया जा सकता है.
क्या आपको और सवाल पूछने हैं? कृपया pagespeed-insights-discuss पर जाकर, हमारे डिस्कशन ग्रुप में हमसे पूछें और सुझाव/राय दें या शिकायत करें.
सुझाव/राय दें या शिकायत करें
क्या इस पेज से कोई मदद मिली?