एचटीएमएल की परफ़ॉर्मेंस से जुड़ी सामान्य बातें

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

एचटीएमएल के लिए शुरुआती अनुरोध कई चरणों से गुज़रता है, जिनमें से हर एक में कुछ समय लगता है. हर चरण पर बिताए गए समय को कम करने से, आपको फ़र्स्ट बाइट (टीटीएफ़बी) का समय ज़्यादा मिलता है. हालांकि, टीटीएफ़बी वह मेट्रिक नहीं है जिस पर आपको पेज के लोड होने की रफ़्तार पर ध्यान देना चाहिए, लेकिन ज़्यादा टीटीएफ़बी की वजह से, सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) और फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) जैसी मेट्रिक के लिए तय किए गए "अच्छे" थ्रेशोल्ड तक पहुंचना मुश्किल हो जाता है.

रीडायरेक्‍ट छोटे करें

जब किसी संसाधन का अनुरोध किया जाता है, तो सर्वर स्थायी रीडायरेक्ट (301 Moved Permanently रिस्पॉन्स) या कुछ समय के लिए (302 Found रिस्पॉन्स) वाले रीडायरेक्ट के ज़रिए जवाब दे सकता है.

रीडायरेक्ट, पेज लोड होने की स्पीड को कम करते हैं. ऐसा इसलिए, क्योंकि रिसॉर्स को पाने के लिए ब्राउज़र को नई जगह पर एक अतिरिक्त एचटीटीपी अनुरोध करना पड़ता है. रीडायरेक्ट दो तरह के होते हैं:

1. एक ही ऑरिजिन वाले रीडायरेक्ट, जो पूरी तरह से आपके ऑरिजिन में होते हैं. इस तरह के रीडायरेक्ट पूरी तरह से आपके कंट्रोल में होते हैं, क्योंकि इन्हें मैनेज करने का तर्क पूरी तरह से आपके वेब सर्वर पर होता है.
2. क्रॉस-ऑरिजिन रीडायरेक्ट, जो किसी दूसरे ऑरिजिन से शुरू किए जाते हैं. आम तौर पर, इस तरह के रीडायरेक्ट आपके कंट्रोल से बाहर होते हैं.

क्रॉस-ऑरिजिन रीडायरेक्ट का इस्तेमाल अक्सर विज्ञापनों, यूआरएल को छोटा करने की सेवाओं, और तीसरे पक्ष की अन्य सेवाओं में किया जाता है. हालांकि, क्रॉस-ऑरिजिन रीडायरेक्ट आपके कंट्रोल से बाहर होते हैं, फिर भी हो सकता है कि आप कई बार रीडायरेक्ट करने से बचें.

एचटीएमएल में मौजूद जवाबों को कैश मेमोरी में सेव करें

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

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

अगर किसी पेज का एचटीएमएल कॉन्टेंट किसी भी तरीके से अपने हिसाब से बनाया गया है, जैसे कि पुष्टि करने वाले उपयोगकर्ता के लिए, तो हो सकता है कि आप कॉन्टेंट को कैश मेमोरी में सेव न करना चाहें. ऐसा, कई तरह की समस्याओं की वजह से किया जाना चाहिए. इनमें सुरक्षित और नयापन शामिल है. अगर किसी एचटीएमएल रिस्पॉन्स को उपयोगकर्ता के ब्राउज़र ने कैश मेमोरी में सेव किया है, तो आप कैश मेमोरी को अमान्य नहीं कर पाएंगे. ऐसे मामलों में, एचटीएमएल को कैश मेमोरी में सेव करने से बचना बेहतर होता है.

एचटीएमएल को कैश मेमोरी में सेव करने के लिए, ETag या Last-Modified रिस्पॉन्स हेडर का इस्तेमाल करना सबसे सही तरीका हो सकता है. ETag—इसे इकाई टैग भी कहा जाता है—हेडर ऐसा आइडेंटिफ़ायर होता है जो अनुरोध किए गए संसाधन की खास तौर पर जानकारी देता है. आम तौर पर, इसके लिए संसाधन के कॉन्टेंट के हैश का इस्तेमाल किया जाता है:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

संसाधन में जब भी बदलाव होगा, ETag की नई वैल्यू जनरेट होगी. इसके बाद में, ब्राउज़र If-None-Match अनुरोध के हेडर के ज़रिए ETag वैल्यू भेजता है. अगर सर्वर पर मौजूद ETag, ब्राउज़र के भेजे गए रिस्पॉन्स से मेल खाता है, तो सर्वर 304 Not Modified रिस्पॉन्स के साथ जवाब देता है. साथ ही, ब्राउज़र कैश मेमोरी के रिसॉर्स का इस्तेमाल करता है. हालांकि, इसकी वजह से नेटवर्क इंतज़ार करना पड़ता है, लेकिन 304 Not Modified रिस्पॉन्स, पूरे एचटीएमएल रिसॉर्स की तुलना में बहुत कम कम होता है.

हालांकि, किसी संसाधन के अपडेट होने की फिर से पुष्टि करने में शामिल होने वाले नेटवर्क के इंतज़ार के समय में भी समस्या बनी रहती है. वेब डेवलपमेंट के कई दूसरे पहलुओं की तरह, कारोबार से जुड़ी चीज़ें करना और समझौता करना ज़रूरी है. यह पता लगाना आप पर निर्भर करता है कि इस तरह से एचटीएमएल को कैश मेमोरी में सेव करने की अतिरिक्त कोशिश करना सही है या नहीं या सुरक्षित रहना ही अच्छा है कि एचटीएमएल कॉन्टेंट को कैश मेमोरी में सेव करने से बिलकुल भी परेशान न हों.

सर्वर के रिस्पॉन्स में लगने वाले समय को मेज़र करना

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

अगर उपयोगकर्ताओं को फ़ील्ड में TTFB की समस्या आ रही है, तो Server-Timing रिस्पॉन्स हेडर का इस्तेमाल करके यह जानकारी दिखाई जा सकती है कि सर्वर पर कहां समय बिताया गया:

Server-Timing: auth;dur=55.5, db;dur=220

Server-Timing हेडर की वैल्यू में एक से ज़्यादा मेट्रिक शामिल हो सकती हैं. साथ ही, हर एक के लिए अवधि तय की जा सकती है. इसके बाद, इस डेटा को नेविगेशन टाइमिंग एपीआई का इस्तेमाल करके फ़ील्ड में मौजूद उपयोगकर्ताओं से इकट्ठा किया जा सकता है. साथ ही, इसका विश्लेषण करके यह पता लगाया जा सकता है कि क्या उपयोगकर्ताओं को कोई समस्या आ रही है. पिछले कोड स्निपेट में, रिस्पॉन्स हेडर में दो टाइमिंग शामिल हैं:

• किसी उपयोगकर्ता (auth) की पुष्टि करने में लगने वाला समय, जिसमें 55.5 मिलीसेकंड लगे.
• डेटाबेस ऐक्सेस समय (db), जिसमें 220 मिलीसेकंड लगे.

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

संपीड़न

एचटीएमएल, JavaScript, सीएसएस, और SVG इमेज जैसे टेक्स्ट-आधारित रिस्पॉन्स को नेटवर्क पर अपना ट्रांसफ़र साइज़ कम करने के लिए कंप्रेस किया जाना चाहिए. इससे वे ज़्यादा तेज़ी से डाउनलोड कर सकेंगे. सबसे ज़्यादा इस्तेमाल किए जाने वाले कंप्रेशन एल्गोरिदम, gzip और Bromli हैं. Brotli में gzip की तुलना में करीब 15% से 20% सुधार होता है.

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

1. जहां हो सके वहां Brotli का इस्तेमाल करें. जैसा कि पहले बताया गया है, Brotli में gzip की तुलना में काफ़ी सुधार होता है. साथ ही, Browtli सभी बड़े ब्राउज़र में काम करता है. जहां भी हो सके, तब Brotli का इस्तेमाल करें, लेकिन अगर लेगसी ब्राउज़र पर बहुत ज़्यादा उपयोगकर्ता आपकी वेबसाइट का इस्तेमाल करते हैं, तो पक्का करें कि gzip को फ़ॉलबैक के तौर पर इस्तेमाल किया जाता है. ऐसा इसलिए, क्योंकि कंप्रेस करना बिलकुल न होने से बेहतर है.
2. फ़ाइल का साइज़ मायने रखता है. बहुत छोटे संसाधन—1 केबी से कम को भी कंप्रेस नहीं करते हैं या कभी-कभी पूरी तरह से भी कंप्रेस नहीं करते हैं. किसी भी तरह के डेटा कंप्रेस करने का असर, बड़ी मात्रा में डेटा के होने पर निर्भर करता है. इस डेटा के साथ कंप्रेस किए गए बिट का पता लगाने के लिए, कंप्रेस किया गया एल्गोरिदम काम करता है. फ़ाइल जितनी बड़ी होगी, उसे बेहतर तरीके से कंप्रेस किया जा सकेगा. हालांकि, कंप्रेस करने का काम बहुत बड़ा नहीं होगा. बड़े रिसॉर्स—जैसे कि JavaScript और सीएसएस—जैसे कि ब्राउज़र को पार्स करने और आकलन करने में काफ़ी ज़्यादा समय लगता है. यह ब्राउज़र के डीकंप्रेस्ड होने पर, उनमें बहुत ज़्यादा बदलाव हो सकता है, क्योंकि किसी भी बदलाव की वजह से अलग फ़ाइल हैश हो सकता है.
3. डाइनैमिक बनाम स्टैटिक कंप्रेशन के बारे में जानें. किसी रिसॉर्स को कंप्रेस कब किया जाना चाहिए, इसे लेकर डाइनैमिक और स्टैटिक कंप्रेस करते समय अलग-अलग तरीके हैं. डाइनैमिक कंप्रेशन, अनुरोध के समय संसाधन को कंप्रेस कर देता है. इसके अलावा, कभी-कभी हर बार भी उसका अनुरोध किया जाता है. वहीं दूसरी ओर, स्टैटिक कंप्रेशन से पहले से मौजूद फ़ाइलों को कंप्रेस कर दिया जाता है. इसके लिए, अनुरोध के समय को कंप्रेस करने की ज़रूरत नहीं होती. स्टैटिक कंप्रेशन की सुविधा से, कंप्रेशन में लगने वाले इंतज़ार के समय को हटा दिया जाता है. इससे डाइनैमिक कंप्रेशन की स्थिति में, सर्वर पर रिस्पॉन्स टाइम बढ़ सकता है. JavaScript, सीएसएस, और SVG इमेज जैसे स्टैटिक रिसॉर्स को डाइनैमिक तरीके से कंप्रेस किया जाना चाहिए. वहीं, एचटीएमएल संसाधन खास तौर पर, अगर पुष्टि किए गए उपयोगकर्ताओं के लिए डाइनैमिक तौर पर जनरेट किए जाते हैं, तो उन्हें डाइनैमिक तरीके से कंप्रेस किया जाना चाहिए.

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

कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन)

कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) कई तरह के सर्वर का नेटवर्क होता है. यह आपके मूल सर्वर से रिसॉर्स को कैश मेमोरी में सेव करता है. साथ ही, यह उन्हें ऐसे किनारे वाले सर्वर से उपलब्ध कराता है जो आपके उपयोगकर्ताओं के सबसे नज़दीक होते हैं. उपयोगकर्ताओं के साथ फ़िज़िकल तौर पर नज़दीक रहने से, दोतरफ़ा यात्रा के समय (आरटीटी) को कम किया जाता है. वहीं, एचटीटीपी/2 या एचटीटीपी/3, कैश मेमोरी, और कंप्रेस करने जैसे ऑप्टिमाइज़ेशन की मदद से सीडीएन, कॉन्टेंट को आपके मूल सर्वर से फ़ेच किए जाने की तुलना में ज़्यादा तेज़ी से दिखा पाता है. सीडीएन का इस्तेमाल करने से कुछ मामलों में आपकी वेबसाइट का टीटीएफ़बी काफ़ी बेहतर हो सकता है.

देखें कि आपको कितना ज्ञान है

अगला लेख: अहम पाथ को समझना

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