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

bookmark_border संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

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

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

एचटीएमएल रिस्पॉन्स को कैश मेमोरी में सेव करना

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

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

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

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

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

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

सर्वर से जवाब मिलने में लगने वाले समय का आकलन करना

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

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

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

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

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

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

संपीड़न

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

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

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

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

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

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

अपने ज्ञान को परखें

अगला लेख: क्रिटिकल पाथ को समझना

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