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

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

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

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

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

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

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

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

कैश एचटीएमएल रिस्पॉन्स

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

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

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

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

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

जब भी संसाधन बदलता है, तब एक नई ETag वैल्यू जनरेट होनी चाहिए. चालू है बाद में अनुरोध करने पर, ब्राउज़र ETag वैल्यू को If-None-Match अनुरोध का हेडर. अगर सर्वर पर 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 मिलीसेकंड लगे.

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

संपीड़न

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

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

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

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

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

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

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

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

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