टाइम टू फ़र्स्ट बाइट मेट्रिक को ऑप्टिमाइज़ करने का तरीका जानें.
पहले बाइट में लगने वाला समय (टीटीएफ़बी), वेब पर पेज की परफ़ॉर्मेंस की बुनियादी मेट्रिक है. यह फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) और सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी) जैसी उपयोगकर्ता अनुभव से जुड़ी अन्य मेट्रिक से पहले आती है. इसका मतलब है कि TTFB की ज़्यादा वैल्यू, इसके बाद की मेट्रिक में समय जोड़ती हैं.
हमारा सुझाव है कि आपका सर्वर, नेविगेशन के अनुरोधों का तुरंत जवाब दे, ताकि 75वें पर्सेंटाइल के उपयोगकर्ताओं को एफ़सीपी "अच्छा" थ्रेशोल्ड के अंदर मिले. आम तौर पर, ज़्यादातर साइटों का टीटीएफ़बी 0.8 सेकंड या उससे कम होना चाहिए.
TTFB मेज़र करने का तरीका
टीटीएफ़बी को ऑप्टिमाइज़ करने से पहले, आपको यह देखना होगा कि इसका आपकी वेबसाइट के उपयोगकर्ताओं पर क्या असर पड़ता है. आपको TTFB को देखने के लिए, फ़ील्ड डेटा पर भरोसा करना चाहिए, क्योंकि रीडायरेक्ट से इस पर असर पड़ता है. वहीं, लैब पर आधारित टूल को अक्सर फ़ाइनल यूआरएल का इस्तेमाल करके मेज़र किया जाता है. इसलिए, इसमें यह अतिरिक्त देरी नहीं दिखती.
PageSpeed Insights, सार्वजनिक वेबसाइटों के लिए फ़ील्ड और लैब, दोनों तरह की जानकारी पाने का एक तरीका है. यह जानकारी, Chrome उपयोगकर्ता अनुभव रिपोर्ट में उपलब्ध होती है.
असली उपयोगकर्ताओं के लिए टीटीएफ़बी, सबसे ऊपर मौजूद जानें कि इंटरनेट की परफ़ॉर्मेंस को लेकर आपके उपयोगकर्ताओं को कैसा अनुभव मिल रहा है सेक्शन में दिखता है:
सर्वर से जवाब मिलने में लगने वाले समय के ऑडिट में, टीटीएफ़बी का सबसेट दिखाया जाता है:
फ़ील्ड और लैब, दोनों में टीटीएफ़बी को मेज़र करने के ज़्यादा तरीकों के बारे में जानने के लिए, टीटीएफ़बी मेट्रिक पेज पर जाएं.
Server-Timing की मदद से, फ़ील्ड में ज़्यादा टीटीएफ़बी को डीबग करना
Server-Timing रिस्पॉन्स हेडर का इस्तेमाल, आपके ऐप्लिकेशन के बैकएंड में किया जा सकता है. इससे, बैकएंड की उन अलग-अलग प्रोसेस को मेज़र किया जा सकता है जिनकी वजह से ज़्यादा इंतज़ार करना पड़ सकता है. हेडर वैल्यू का स्ट्रक्चर आसान है. इसमें कम से कम, आपका तय किया गया हैंडल स्वीकार किया जाता है. वैल्यू के तौर पर, dur की मदद से अवधि की वैल्यू और desc की मदद से, ऐसी जानकारी दी जा सकती है जिसे कोई भी व्यक्ति पढ़ सके. हालांकि, ऐसा करना ज़रूरी नहीं है.
Serving-Timing का इस्तेमाल, ऐप्लिकेशन की कई बैकएंड प्रोसेस को मेज़र करने के लिए किया जा सकता है. हालांकि, कुछ ऐसी प्रोसेस हैं जिन पर आपको खास ध्यान देना चाहिए:
- डेटाबेस क्वेरी
- अगर लागू हो, तो सर्वर साइड रेंडरिंग में लगने वाला समय
- डिस्क पर आगे-पीछे जाना
- अगर सीडीएन का इस्तेमाल किया जा रहा है, तो एज सर्वर कैश मेमोरी में हिट/मिस
Server-Timing एंट्री के सभी हिस्सों को कोलन लगाकर अलग किया जाता है. साथ ही, एक से ज़्यादा एंट्री को कॉमा लगाकर अलग किया जा सकता है:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
हेडर को आपके ऐप्लिकेशन के बैकएंड की पसंदीदा भाषा का इस्तेमाल करके सेट किया जा सकता है. उदाहरण के लिए, PHP में हेडर को इस तरह सेट किया जा सकता है:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
यह हेडर सेट होने पर, आपको ऐसी जानकारी दिखेगी जिसका इस्तेमाल लैब और फ़ील्ड, दोनों में किया जा सकता है.
फ़ील्ड में, Server-Timing रिस्पॉन्स हेडर सेट वाला कोई भी पेज, नेविगेशन टाइमिंग एपीआई में serverTiming प्रॉपर्टी को पॉप्युलेट करेगा:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
लैब में, Server-Timing रिस्पॉन्स हेडर का डेटा, Chrome DevTools के नेटवर्क टैब के टाइमिंग पैनल में विज़ुअलाइज़ किया जाएगा:
Server-Timing Chrome DevTools के नेटवर्क टैब में दिखाए गए रिस्पॉन्स हेडर. यहां Server-Timing का इस्तेमाल यह मेज़र करने के लिए किया जाता है कि किसी रिसॉर्स के लिए अनुरोध, सीडीएन कैश मेमोरी में पहुंचा है या नहीं. साथ ही, यह भी मेज़र किया जाता है कि अनुरोध को सीडीएन के एज सर्वर और फिर ऑरिजिन तक पहुंचने में कितना समय लगता है.
उपलब्ध डेटा का विश्लेषण करके, यह पता लगाने के बाद कि आपके पास TTFB से जुड़ी समस्या है, समस्या को ठीक किया जा सकता है.
TTFB को ऑप्टिमाइज़ करने के तरीके
टीटीएफ़बी को ऑप्टिमाइज़ करने में सबसे बड़ी चुनौती यह है कि वेब का फ़्रंटएंड स्टैक हमेशा एचटीएमएल, सीएसएस, और JavaScript होगा, जबकि बैकएंड स्टैक काफ़ी अलग-अलग हो सकते हैं. कई बैकएंड स्टैक और डेटाबेस प्रॉडक्ट हैं, जिनमें से हर एक की ऑप्टिमाइज़ेशन तकनीक अलग-अलग होती है. इसलिए, इस गाइड में सिर्फ़ स्टैक के हिसाब से दिए गए दिशा-निर्देशों के बजाय, उन बातों पर फ़ोकस किया जाएगा जो ज़्यादातर आर्किटेक्चर पर लागू होती हैं.
प्लैटफ़ॉर्म के हिसाब से दिशा-निर्देश
वेबसाइट के लिए इस्तेमाल किए जाने वाले प्लैटफ़ॉर्म से, टीटीएफ़बी पर काफ़ी असर पड़ सकता है. उदाहरण के लिए, WordPress की परफ़ॉर्मेंस पर प्लग इन की संख्या और क्वालिटी या इस्तेमाल की गई थीम का असर पड़ता है. प्लैटफ़ॉर्म को पसंद के मुताबिक बनाने पर, अन्य प्लैटफ़ॉर्म पर भी इसी तरह का असर पड़ता है. इस पोस्ट में दी गई परफ़ॉर्मेंस से जुड़ी सामान्य सलाह के साथ-साथ, वेंडर के हिसाब से सलाह पाने के लिए, आपको अपने प्लैटफ़ॉर्म के दस्तावेज़ देखना चाहिए. सर्वर के जवाब देने में लगने वाले समय को कम करने के लिए, Lighthouse ऑडिट में स्टैक के हिसाब से सीमित दिशा-निर्देश भी शामिल होते हैं.
होस्टिंग, होस्टिंग, होस्टिंग
ऑप्टिमाइज़ेशन के अन्य तरीकों को आज़माने से पहले, होस्टिंग को सबसे पहले ध्यान में रखें. इस बारे में यहां खास दिशा-निर्देश नहीं दिए जा सकते. हालांकि, एक सामान्य नियम यह है कि यह पक्का करें कि आपकी वेबसाइट का होस्ट, उस पर भेजे जाने वाले ट्रैफ़िक को हैंडल कर सके.
आम तौर पर, शेयर की गई होस्टिंग की स्पीड धीमी होती है. अगर आपकी वेबसाइट छोटी और निजी है और उस पर ज़्यादातर स्टैटिक फ़ाइलें मौजूद हैं, तो शायद यह TTFB ठीक है. हालांकि, यहां दी गई ऑप्टिमाइज़ेशन की कुछ तकनीकों की मदद से, TTFB को ज़्यादा से ज़्यादा कम किया जा सकता है.
हालांकि, अगर आपके पास कई उपयोगकर्ताओं के साथ बड़ा ऐप्लिकेशन है, जिसमें उपयोगकर्ताओं के हिसाब से कॉन्टेंट दिखाना, डेटाबेस क्वेरी करना, और सर्वर साइड के अन्य ज़रूरी काम शामिल हैं, तो फ़ील्ड में टीटीएफ़बी को कम करने के लिए, होस्टिंग का विकल्प चुनना ज़रूरी हो जाता है.
होस्टिंग की सेवा देने वाली कंपनी चुनते समय, इन बातों का ध्यान रखें:
- आपके ऐप्लिकेशन इंस्टेंस को कितनी मेमोरी दी गई है? अगर आपके ऐप्लिकेशन में ज़रूरत के मुताबिक मेमोरी नहीं है, तो पेजों को तेज़ी से दिखाने में उसे परेशानी होगी.
- क्या होस्टिंग की सेवा देने वाली कंपनी, आपके बैकएंड स्टैक को अप-टू-डेट रखती है? ऐप्लिकेशन के बैकएंड की भाषाओं, एचटीटीपी लागू करने के तरीकों, और डेटाबेस सॉफ़्टवेयर के नए वर्शन रिलीज़ होने पर, समय के साथ उस सॉफ़्टवेयर की परफ़ॉर्मेंस बेहतर हो जाएगी. होस्टिंग की सेवा देने वाली ऐसी कंपनी के साथ साझेदारी करना ज़रूरी है जो इस तरह के ज़रूरी रखरखाव को प्राथमिकता देती हो.
- अगर आपके ऐप्लिकेशन की ज़रूरतें खास हैं और आपको सर्वर कॉन्फ़िगरेशन फ़ाइलों का सबसे निचला लेवल ऐक्सेस चाहिए, तो अपने ऐप्लिकेशन इंस्टेंस के बैकएंड को पसंद के मुताबिक बनाने के बारे में सोचें.
होस्टिंग की सेवा देने वाली कई कंपनियां, इन चीज़ों का ध्यान रखती हैं. हालांकि, अगर आपको होस्टिंग की सेवा देने वाली खास कंपनियों में भी TTFB की वैल्यू ज़्यादा दिखती है, तो हो सकता है कि आपको अपने मौजूदा होस्टिंग प्रोवाइडर की क्षमताओं का फिर से आकलन करना पड़े. इससे, आपको उपयोगकर्ताओं को बेहतरीन अनुभव देने में मदद मिलेगी.
कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) का इस्तेमाल करना
सीडीएन के इस्तेमाल का विषय काफ़ी पुराना है, लेकिन इसकी वजह सही है: आपके पास ऐप्लिकेशन का बहुत अच्छी तरह से ऑप्टिमाइज़ किया गया बैकएंड हो सकता है, लेकिन आपके ऑरिजिन सर्वर से दूर रहने वाले उपयोगकर्ताओं को फ़ील्ड में अब भी ज़्यादा टीटीएफ़बी का अनुभव हो सकता है.
सीडीएन, आपके ऑरिजिन सर्वर से उपयोगकर्ता की निकटता की समस्या को हल करते हैं. इसके लिए, वे सर्वर के डिस्ट्रिब्यूटेड नेटवर्क का इस्तेमाल करते हैं. यह नेटवर्क, आपके उपयोगकर्ताओं के आस-पास मौजूद सर्वर पर संसाधनों को कैश मेमोरी में सेव करता है. इन सर्वर को एज सर्वर कहा जाता है.
सीडीएन की सेवा देने वाली कंपनियां, एज सर्वर के अलावा ये फ़ायदे भी दे सकती हैं:
- सीडीएन सेवा देने वाली कंपनियां, आम तौर पर डीएनएस रिज़ॉल्यूशन का समय बहुत कम रखती हैं.
- सीडीएन, एज सर्वर से आपका कॉन्टेंट दिखाएगा. इसके लिए, एचटीटीपी/2 या एचटीटीपी/3 जैसे आधुनिक प्रोटोकॉल का इस्तेमाल किया जाएगा.
- खास तौर पर, एचटीटीपी/3, यूडीपी प्रोटोकॉल का इस्तेमाल करके, टीसीपी (जिस पर एचटीटीपी/2 निर्भर करता है) में मौजूद हेड-ऑफ़-लाइन ब्लॉकिंग की समस्या को हल करता है.
- सीडीएन, TLS के आधुनिक वर्शन भी उपलब्ध करा सकता है. इससे, TLS के लिए बातचीत करने में लगने वाला समय कम हो जाता है. खास तौर पर, TLS 1.3 को इस तरह से डिज़ाइन किया गया है कि टीएलएस बातचीत को जितना हो सके उतना कम समय में पूरा किया जा सके.
- सीडीएन की सेवा देने वाली कुछ कंपनियां, "एज वर्क" नाम की एक सुविधा देती हैं. यह सुविधा, अनुरोधों को इंटरसेप्ट करने, एज कैश मेमोरी में जवाबों को प्रोग्राम के हिसाब से मैनेज करने या जवाबों को पूरी तरह से फिर से लिखने के लिए, Service Worker API जैसे एपीआई का इस्तेमाल करती है.
- सीडीएन सेवा देने वाली कंपनियां, कॉन्टेंट को कम साइज़ में करने के लिए ऑप्टिमाइज़ करने में काफ़ी अच्छी होती हैं. डेटा को खुद से कम करना मुश्किल है. साथ ही, डाइनैमिक तौर पर जनरेट किए गए मार्कअप के कुछ मामलों में, जवाब मिलने में ज़्यादा समय लग सकता है. ऐसे में, डेटा को फ़्लाइट पर कम करना ज़रूरी है.
- सीडीएन सेवा देने वाली कंपनियां, स्टैटिक रिसॉर्स के लिए भी अपने-आप कंप्रेस किए गए रिस्पॉन्स को कैश मेमोरी में सेव कर लेंगी. इससे कंप्रेस करने के अनुपात और रिस्पॉन्स में लगने वाले समय का सबसे अच्छा मिक्स मिलता है.
सीडीएन को अपनाने में, थोड़ी से ज़्यादा मेहनत लग सकती है. हालांकि, अगर आपकी वेबसाइट पहले से किसी सीडीएन का इस्तेमाल नहीं कर रही है, तो टीटीएफ़बी को ऑप्टिमाइज़ करना आपकी प्राथमिकता होनी चाहिए.
जहां भी हो सके, कैश मेमोरी में सेव किए गए कॉन्टेंट का इस्तेमाल किया गया हो
सीडीएन की मदद से, कॉन्टेंट को एज सर्वर पर कैश मेमोरी में सेव किया जा सकता है. ये सर्वर, वेबसाइट पर आने वाले लोगों के करीब होते हैं. हालांकि, इसके लिए ज़रूरी है कि कॉन्टेंट को सही Cache-Control एचटीटीपी हेडर के साथ कॉन्फ़िगर किया गया हो. हालांकि, यह लोगों की दिलचस्पी के हिसाब से कॉन्टेंट दिखाने के लिए सही नहीं है. साथ ही, ओरिजिन पर वापस जाने की ज़रूरत होने पर, सीडीएन की ज़्यादातर वैल्यू खत्म हो सकती है.
जिन साइटों का कॉन्टेंट बार-बार अपडेट होता है उनके लिए, कैश मेमोरी में कॉन्टेंट सेव होने में लगने वाला कम समय भी, साइट की परफ़ॉर्मेंस को बेहतर बना सकता है. ऐसा इसलिए, क्योंकि उस दौरान सिर्फ़ पहली बार आने वाले व्यक्ति को ऑरिजिन सर्वर से पूरी तरह लेटेंसी का अनुभव मिलता है. वहीं, अन्य सभी लोग एज सर्वर से कैश मेमोरी में सेव किए गए रिसॉर्स का फिर से इस्तेमाल कर सकते हैं. कुछ सीडीएन, साइट रिलीज़ पर कैश मेमोरी को अमान्य करने की अनुमति देते हैं. इससे, दोनों ही दुनिया का फ़ायदा मिलता है—कैश मेमोरी में कॉन्टेंट सेव होने में ज़्यादा समय लगता है, लेकिन ज़रूरत पड़ने पर तुरंत अपडेट मिलते हैं.
कैश मेमोरी को सही तरीके से कॉन्फ़िगर करने के बाद भी, Analytics मेज़रमेंट के लिए यूनीक क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, कैश मेमोरी को अनदेखा किया जा सकता है. ये एक जैसे होने के बावजूद, सीडीएन के लिए अलग-अलग कॉन्टेंट की तरह दिख सकते हैं. इसलिए, कैश मेमोरी में सेव किए गए वर्शन का इस्तेमाल नहीं किया जाएगा.
हो सकता है कि पुराने या कम देखे गए कॉन्टेंट को भी कैश मेमोरी में सेव न किया गया हो. इस वजह से, कुछ पेजों पर टीटीएफ़बी की वैल्यू, दूसरे पेजों की तुलना में ज़्यादा हो सकती है. कैश मेमोरी में कॉन्टेंट सेव होने में लगने वाले समय को बढ़ाकर, इस समस्या के असर को कम किया जा सकता है. हालांकि, ध्यान रखें कि कैश मेमोरी में कॉन्टेंट सेव होने में लगने वाले समय को बढ़ाने पर, पुराना कॉन्टेंट दिखाए जाने की संभावना बढ़ जाती है.
कैश मेमोरी में सेव किए गए कॉन्टेंट का असर, सिर्फ़ सीडीएन का इस्तेमाल करने वाले लोगों पर नहीं पड़ता. जब कैश मेमोरी में सेव किए गए कॉन्टेंट का फिर से इस्तेमाल नहीं किया जा सकता, तो हो सकता है कि सर्वर इन्फ़्रास्ट्रक्चर को महंगे डेटाबेस लुकअप से कॉन्टेंट जनरेट करना पड़े. अक्सर, ज़्यादा बार ऐक्सेस किए गए डेटा या पहले से कैश मेमोरी में सेव किए गए पेजों की परफ़ॉर्मेंस बेहतर होती है.
एक से ज़्यादा पेज पर रीडायरेक्ट करने से बचना
रीडायरेक्ट, TTFB को बढ़ाने में एक आम योगदानकर्ता है. रीडायरेक्ट तब होता है, जब किसी दस्तावेज़ के लिए नेविगेशन अनुरोध का ऐसा जवाब मिलता है जिससे ब्राउज़र को पता चलता है कि संसाधन किसी दूसरी जगह मौजूद है. एक रीडायरेक्ट, नेविगेशन अनुरोध में अनचाहा इंतज़ार बढ़ा सकता है. हालांकि, अगर वह रीडायरेक्ट किसी ऐसे दूसरे संसाधन पर ले जाता है जिससे अन्य रीडायरेक्ट होता है, तो स्थिति और भी खराब हो सकती है. इसका असर खास तौर पर उन साइटों पर पड़ सकता है जिन पर विज्ञापनों या न्यूज़लेटर से बहुत ज़्यादा लोग आते हैं. ऐसा इसलिए, क्योंकि मेज़रमेंट के मकसद से, वे अक्सर आंकड़ों से जुड़ी सेवाओं के ज़रिए रीडायरेक्ट होती हैं. अपने कंट्रोल में आने वाले रीडायरेक्ट हटाने से, टीटीएफ़बी को बेहतर बनाने में मदद मिल सकती है.
रीडायरेक्ट दो तरह के होते हैं:
- एक ही सोर्स के रीडायरेक्ट, जहां रीडायरेक्ट पूरी तरह से आपकी वेबसाइट पर होता है.
- क्रॉस-ऑरिजिन रीडायरेक्ट, जहां आपकी वेबसाइट पर आने से पहले, रीडायरेक्ट शुरुआत में किसी दूसरे ऑरिजिन पर होता है. उदाहरण के लिए, सोशल मीडिया पर यूआरएल छोटा करने वाली सेवा से.
आपको एक ही ऑरिजिन वाले रीडायरेक्ट को हटाने पर फ़ोकस करना है, क्योंकि इस पर आपका सीधा कंट्रोल होगा. इसके लिए, आपको अपनी वेबसाइट पर मौजूद लिंक की जांच करनी होगी. इससे यह पता चलेगा कि उनमें से किसी भी लिंक से 302 या 301 रिस्पॉन्स कोड मिलता है या नहीं. अक्सर, ऐसा https:// स्कीम शामिल न करने की वजह से हो सकता है. इस वजह से, ब्राउज़र डिफ़ॉल्ट रूप से http:// पर रीडायरेक्ट करता है. इसके अलावा, ऐसा तब भी हो सकता है, जब यूआरएल में आखिर में स्लैश सही तरीके से शामिल न किए गए हों या उन्हें शामिल न किया गया हो.
क्रॉस-ऑरिजिन रीडायरेक्ट मुश्किल होते हैं, क्योंकि ये अक्सर आपके कंट्रोल में नहीं होते. हालांकि, जहां भी हो सके वहां एक से ज़्यादा रीडायरेक्ट से बचने की कोशिश करें. उदाहरण के लिए, लिंक शेयर करते समय लिंक छोटा करने वाले कई टूल का इस्तेमाल करके. पक्का करें कि विज्ञापन देने वालों या न्यूज़लेटर के लिए दिया गया यूआरएल, सही फ़ाइनल यूआरएल हो. इससे, उन सेवाओं के इस्तेमाल किए गए रीडायरेक्ट में कोई और रीडायरेक्ट नहीं जोड़ा जाएगा.
रीडायरेक्ट में लगने वाले समय का एक और अहम सोर्स, एचटीटीपी से एचटीटीपीएस पर रीडायरेक्ट हो सकता है. इस समस्या से बचने के लिए, Strict-Transport-Security हेडर (एचएसटीएस) का इस्तेमाल किया जा सकता है. यह हेडर, किसी ऑरिजिन पर पहली बार विज़िट करने पर एचटीटीपीएस को लागू करेगा. इसके बाद, वह ब्राउज़र को यह निर्देश देगा कि आने वाले समय में ऑरिजिन को एचटीटीपीएस स्कीम के ज़रिए तुरंत ऐक्सेस किया जाए.
एचएसटीएस की अच्छी नीति लागू करने के बाद, अपनी साइट को एचएसटीएस प्रीलोड सूची में जोड़कर, किसी ऑरिजिन पर पहली बार विज़िट करने पर तेज़ी से काम किया जा सकता है.
ब्राउज़र पर मार्कअप स्ट्रीम करना
ब्राउज़र को स्ट्रीम किए जा रहे मार्कअप को बेहतर तरीके से प्रोसेस करने के लिए ऑप्टिमाइज़ किया जाता है. इसका मतलब है कि सर्वर से आने वाले मार्कअप को हिस्सों में मैनेज किया जाता है. बड़े मार्कअप पेलोड के लिए यह ज़रूरी है, क्योंकि इसका मतलब है कि ब्राउज़र, मार्कअप के हिस्सों को धीरे-धीरे पार्स कर सकता है. इसके बजाय, वह पूरे रिस्पॉन्स के आने का इंतज़ार करता है.
हालांकि, ब्राउज़र स्ट्रीमिंग मार्कअप को मैनेज करने में बहुत अच्छे होते हैं, लेकिन स्ट्रीम को जारी रखने के लिए ज़रूरी है कि आप अपना पूरा ध्यान इस पर दें, ताकि मार्कअप के शुरुआती हिस्से जल्द से जल्द दिखें. अगर बैकएंड में समस्या आ रही है, तो यह एक समस्या है. बैकएंड स्टैक की संख्या बहुत ज़्यादा है. इसलिए, इस गाइड में हर स्टैक और हर स्टैक में आने वाली समस्याओं के बारे में नहीं बताया जा सकता.
उदाहरण के लिए, React और दूसरे फ़्रेमवर्क, सर्वर साइड रेंडरिंग के लिए सिंक्रोनस तरीके का इस्तेमाल करते हैं. ये फ़्रेमवर्क, सर्वर पर मांग पर मार्कअप रेंडर कर सकते हैं. हालांकि, React के नए वर्शन में मार्कअप को स्ट्रीम करने के लिए सर्वर के तरीके लागू किए गए हैं, क्योंकि इसे रेंडर किया जा रहा है. इसका मतलब है कि आपको रिस्पॉन्स भेजने से पहले, React सर्वर एपीआई के तरीके के पूरा रिस्पॉन्स रेंडर होने का इंतज़ार नहीं करना पड़ेगा.
मार्कअप को ब्राउज़र पर तेज़ी से स्ट्रीम करने का एक और तरीका है, स्टैटिक रेंडरिंग का इस्तेमाल करना. इससे, बिल्ड के समय एचटीएमएल फ़ाइलें जनरेट होती हैं. पूरी फ़ाइल तुरंत उपलब्ध होने पर, वेब सर्वर फ़ाइल को तुरंत भेजना शुरू कर सकते हैं. साथ ही, एचटीटीपी की खासियत की वजह से, स्ट्रीमिंग मार्कअप बन जाएगा. यह तरीका हर वेबसाइट के हर पेज के लिए सही नहीं है. जैसे, उन पेजों के लिए जिनमें उपयोगकर्ता अनुभव के हिस्से के तौर पर डाइनैमिक रिस्पॉन्स की ज़रूरत होती है. हालांकि, यह उन पेजों के लिए फ़ायदेमंद हो सकता है जिनमें मार्कअप को किसी खास उपयोगकर्ता के हिसाब से बनाने की ज़रूरत नहीं होती.
सर्विस वर्कर का इस्तेमाल करना
Service Worker API से, दस्तावेज़ों और उनके लोड होने वाले रिसॉर्स, दोनों के लिए टीटीएफ़बी पर काफ़ी असर पड़ सकता है. इसकी वजह यह है कि सेवा वर्कर, ब्राउज़र और सर्वर के बीच प्रॉक्सी के तौर पर काम करता है. हालांकि, आपकी वेबसाइट के टीटीएफ़बी पर असर पड़ेगा या नहीं, यह इस बात पर निर्भर करता है कि आपने सेवा वर्कर को कैसे सेट अप किया है और क्या वह सेटअप आपके ऐप्लिकेशन की ज़रूरतों के मुताबिक है.
- ऐसेट के लिए, पुरानी-जबकि-फिर से पुष्टि करने की रणनीति का इस्तेमाल करें. अगर कोई एसेट सर्विस वर्कर कैश मेमोरी में मौजूद है, फिर चाहे वह कोई दस्तावेज़ हो या दस्तावेज़ के लिए ज़रूरी रिसॉर्स, तो 'पुरानी जानकारी के साथ फिर से पुष्टि करना' रणनीति, उस रिसॉर्स को पहले कैश मेमोरी से दिखाएगी. इसके बाद, वह उस एसेट को बैकग्राउंड में डाउनलोड करेगी और आने वाले समय में होने वाले इंटरैक्शन के लिए, उसे कैश मेमोरी से दिखाएगी.
- अगर आपके पास ऐसे दस्तावेज़ संसाधन हैं जो अक्सर नहीं बदलते हैं, तो'पुरानी जानकारी के साथ फिर से पुष्टि करना' रणनीति का इस्तेमाल करके, पेज का टीटीएफ़बी (पेज लोड होने में लगने वाला समय) तुरंत हो सकता है. हालांकि, अगर आपकी वेबसाइट डाइनैमिक तौर पर जनरेट किया गया मार्कअप भेजती है, तो यह तरीका उतना कारगर नहीं होता. जैसे, उपयोगकर्ता की पुष्टि होने या न होने के आधार पर बदलने वाला मार्कअप. ऐसे मामलों में, आपको हमेशा पहले नेटवर्क से कनेक्ट करना होगा, ताकि दस्तावेज़ ज़्यादा से ज़्यादा अप-टू-डेट रहे.
- अगर आपका दस्तावेज़ ऐसे ग़ैर-ज़रूरी रिसॉर्स लोड करता है जो समय-समय पर बदलते रहते हैं, लेकिन पुराने रिसॉर्स को फ़ेच करने से उपयोगकर्ता अनुभव पर काफ़ी असर नहीं पड़ता है, तो उन रिसॉर्स के लिए टीटीएफ़बी को काफ़ी कम किया जा सकता है. जैसे, चुनिंदा इमेज या ऐसे अन्य रिसॉर्स जो ज़रूरी नहीं हैं. इसके लिए, 'पुरानी जानकारी के साथ फिर से पुष्टि करने की रणनीति' का इस्तेमाल किया जा सकता है.
- क्लाइंट से रेंडर किए जाने वाले ऐप्लिकेशन के लिए, ऐप्लिकेशन शेल मॉडल का इस्तेमाल करें. यह मॉडल, एसपीए के लिए सबसे सही है. यहां पेज का "शेल", सर्विस वर्कर कैश मेमोरी से तुरंत डिलीवर किया जा सकता है. साथ ही, पेज के लाइफ़साइकल में बाद में, पेज का डाइनैमिक कॉन्टेंट पॉप्युलेट और रेंडर किया जाता है.
रेंडर करने के लिए ज़रूरी संसाधनों के लिए 103 Early Hints का इस्तेमाल करना
भले ही, आपके ऐप्लिकेशन का बैकएंड कितना भी ऑप्टिमाइज़ किया गया हो, फिर भी सर्वर को जवाब तैयार करने के लिए काफ़ी काम करना पड़ सकता है. इसमें डेटाबेस से जुड़ा महंगा (हालांकि ज़रूरी) काम भी शामिल है, जिसकी वजह से नेविगेशन रिस्पॉन्स देर से मिलता है. इसकी वजह से, हो सकता है कि रेंडर करने के लिए ज़रूरी कुछ रिसॉर्स लोड होने में देरी हो. जैसे, सीएसएस या कुछ मामलों में क्लाइंट पर मार्कअप रेंडर करने वाला JavaScript.
103 Early Hints हेडर, रिस्पॉन्स का एक शुरुआती कोड है. बैकएंड मार्कअप तैयार करने में व्यस्त होने पर, सर्वर इस कोड को ब्राउज़र को भेज सकता है. इस हेडर का इस्तेमाल, ब्राउज़र को यह बताने के लिए किया जा सकता है कि पेज को रेंडर करने के लिए ज़रूरी संसाधन हैं. इसलिए, मार्कअप तैयार होने के दौरान पेज को डाउनलोड करना शुरू कर देना चाहिए. इस सुविधा के साथ काम करने वाले ब्राउज़र के लिए, दस्तावेज़ की रेंडरिंग (सीएसएस) तेज़ हो सकती है. साथ ही, पेज के मुख्य फ़ंक्शन (JavaScript) तुरंत उपलब्ध हो सकते हैं.
नतीजा
बैकएंड ऐप्लिकेशन स्टैक के कई कॉम्बिनेशन होते हैं. इसलिए, ऐसा कोई लेख नहीं है जिसमें आपकी वेबसाइट के टीटीएफ़बी को कम करने के लिए, सब कुछ शामिल किया जा सके. हालांकि, सर्वर साइड पर काम को थोड़ा तेज़ करने के लिए, ये विकल्प आज़माए जा सकते हैं.
हर मेट्रिक को ऑप्टिमाइज़ करने का तरीका काफ़ी हद तक एक जैसा होता है: फ़ील्ड में अपना टीटीएफ़बी मेज़र करें, समस्याओं की वजहों के बारे में जानने के लिए लैब टूल का इस्तेमाल करें, और फिर जहां भी हो सके वहां ऑप्टिमाइज़ेशन लागू करें. हो सकता है कि यहां दी गई हर तकनीक आपके काम की न हो, लेकिन कुछ तकनीकें काम की होंगी. हमेशा की तरह, आपको अपने फ़ील्ड डेटा पर नज़र बनाए रखनी होगी. साथ ही, ज़रूरत के हिसाब से बदलाव करने होंगे, ताकि उपयोगकर्ताओं को सबसे तेज़ अनुभव मिल सके.
हीरो इमेज, टेलर विक की है. इसे Unsplash से लिया गया है.