टाइम टू फ़र्स्ट बाइट मेट्रिक को ऑप्टिमाइज़ करने का तरीका जानें.
टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी), वेब परफ़ॉर्मेंस की बुनियादी मेट्रिक है. यह मेट्रिक, उपयोगकर्ता अनुभव की अन्य ज़रूरी मेट्रिक से पहले मौजूद होती है. जैसे, फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) और सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी). इसका मतलब है कि टीटीएफ़बी की ज़्यादा वैल्यू होने पर, उसे फ़ॉलो करने वाली मेट्रिक में समय जुड़ जाता है.
हमारा सुझाव है कि आपका सर्वर, नेविगेशन अनुरोधों का तुरंत जवाब दे, ताकि उपयोगकर्ताओं के 75वें पर्सेंटाइल को "अच्छा" थ्रेशोल्ड के अंदर एफ़सीपी का अनुभव हो. मोटे तौर पर, ज़्यादातर साइटों के लिए टीटीएफ़बी 0.8 सेकंड या उससे कम होना चाहिए.
TTFB को मापने का तरीका
TTFB को ऑप्टिमाइज़ करने से पहले, आपको यह देखना होगा कि यह आपकी वेबसाइट के उपयोगकर्ताओं पर कैसे असर डालता है. आपको टीटीएफ़बी पर नज़र रखने के लिए, फ़ील्ड डेटा पर भरोसा करना चाहिए, क्योंकि इस पर रीडायरेक्ट का असर होता है. लैब पर आधारित टूल का आकलन अक्सर फ़ाइनल यूआरएल का इस्तेमाल करके किया जाता है, इसलिए यह ज़्यादा देर तक काम नहीं करता.
PageSpeed Insights एक आसान तरीका है. इसकी मदद से, Chrome इस्तेमाल करने वाले लोगों के अनुभव की रिपोर्ट में उपलब्ध सार्वजनिक वेबसाइटों के लिए, फ़ील्ड और लैब, दोनों तरह की जानकारी पाई जा सकती है.
असल उपयोगकर्ताओं के लिए TTFB को सबसे ऊपर पता लगाएं कि आपके असली उपयोगकर्ताओं को क्या अनुभव हो रहा है सेक्शन में दिखाया जाता है:
सर्वर रिस्पॉन्स टाइम ऑडिट में TTFB का सबसेट दिखाया गया है:
फ़ील्ड और लैब, दोनों में TTFB को मापने के ज़्यादा तरीके जानने के लिए, TTFB मेट्रिक पेज पर जाएं.
Server-Timing के साथ ज़्यादा TTFB को समझना
Server-Timing रिस्पॉन्स हेडर का इस्तेमाल आपके ऐप्लिकेशन बैकएंड में किया जा सकता है, ताकि अलग-अलग बैकएंड प्रोसेस को मापा जा सके. इन प्रोसेस से, इंतज़ार का समय बढ़ सकता है. हेडर वैल्यू का स्ट्रक्चर सुविधाजनक होता है. साथ ही, इसे आपके तय किए गए हैंडल के हिसाब से स्वीकार किया जाता है. वैकल्पिक वैल्यू में dur के ज़रिए, कुल समय की वैल्यू और desc की मदद से ऐसी जानकारी शामिल होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है.
Serving-Timing का इस्तेमाल, ऐप्लिकेशन की कई बैकएंड प्रोसेस को मेज़र करने के लिए किया जा सकता है, लेकिन कुछ मामलों में आपको खास ध्यान देना चाहिए:
- डेटाबेस क्वेरी
- अगर लागू हो, तो सर्वर-साइड रेंडरिंग में लगने वाला समय
- डिस्क में आगे/पीछे जाने की सुविधा
- Edge सर्वर की कैश मेमोरी के हिट/मिसिंग (अगर सीडीएन का इस्तेमाल किया जा रहा है)
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 - $dbReadStarTime) / 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 में नेटवर्क टैब के टाइमिंग पैनल में दिखाया जाएगा:
Chrome DevTools के नेटवर्क टैब में Server-Timing रिस्पॉन्स हेडर विज़ुअलाइज़ किया गया. यहां Server-Timing का इस्तेमाल यह मेज़र करने के लिए किया जाता है कि किसी संसाधन के लिए किए गए अनुरोध ने सीडीएन कैश को हिट किया है या नहीं. साथ ही, यह भी बताता है कि अनुरोध को सीडीएन के किनारे के सर्वर और फिर ऑरिजिन को हिट करने में कितना समय लगता है.
उपलब्ध डेटा का विश्लेषण करके यह पता लगाएं कि आपको TTFB की समस्या है, तो आप समस्या को ठीक कर सकते हैं.
TTFB को ऑप्टिमाइज़ करने के तरीके
TTFB को ऑप्टिमाइज़ करने का सबसे चुनौती भरा पहलू यह है कि वेब के फ़्रंटएंड स्टैक हमेशा एचटीएमएल, सीएसएस, और JavaScript होंगे, लेकिन बैकएंड स्टैक में काफ़ी अंतर हो सकता है. ऐसे कई बैकएंड स्टैक और डेटाबेस प्रॉडक्ट हैं जिनमें हर एक को ऑप्टिमाइज़ करने की तकनीक अलग-अलग है. इसलिए, यह गाइड सिर्फ़ स्टैक से जुड़े दिशा-निर्देशों के बजाय, ज़्यादातर आर्किटेक्चर पर लागू होने वाली चीज़ों पर फ़ोकस करेगी.
प्लैटफ़ॉर्म के हिसाब से सलाह
अपनी वेबसाइट के लिए जिस प्लैटफ़ॉर्म का इस्तेमाल किया जाता है, उससे TTFB पर बहुत ज़्यादा असर पड़ सकता है. उदाहरण के लिए, WordPress की परफ़ॉर्मेंस पर, प्लगिन की संख्या और क्वालिटी का असर पड़ता है. इसके अलावा, यह भी तय होता है कि इस्तेमाल की जाने वाली थीम का क्या असर होगा. जब प्लैटफ़ॉर्म को पसंद के मुताबिक बनाया जाता है, तो अन्य प्लैटफ़ॉर्म पर भी इसी तरह का असर पड़ता है. आपको वेंडर से जुड़ी खास सलाह के लिए, अपने प्लैटफ़ॉर्म के दस्तावेज़ देखने चाहिए. इससे आपको इस पोस्ट में, सामान्य परफ़ॉर्मेंस को बेहतर बनाने में मदद मिलेगी. सर्वर के रिस्पॉन्स समय को कम करने के लिए, लाइटहाउस ऑडिट में सीमित स्टैक से जुड़े कुछ दिशा-निर्देश भी शामिल हैं.
होस्ट करना, होस्ट करना, होस्ट करना
इससे पहले कि आप अन्य ऑप्टिमाइज़ेशन के तरीकों पर भी विचार करें, आपको सबसे पहले होस्टिंग पर ध्यान देना चाहिए. यहां पर खास दिशा-निर्देश दिए जा सकते हैं या नहीं, लेकिन एक सामान्य नियम यह पक्का करना है कि आपकी वेबसाइट का होस्ट उस ट्रैफ़िक को मैनेज करने में सक्षम है जिस पर आप जाते हैं.
शेयर की गई होस्टिंग की सुविधा आम तौर पर धीमी होगी. अगर आपकी एक छोटी निजी वेबसाइट है जो ज़्यादातर स्टैटिक फ़ाइलें इस्तेमाल करती है, तो शायद यह ठीक है. साथ ही, ऑप्टिमाइज़ेशन के कुछ ऐसे तरीके हैं जिनसे टीटीएफ़बी की परफ़ॉर्मेंस को कम किया जा सकता है.
हालांकि, अगर कई उपयोगकर्ताओं के लिए कोई बड़ा ऐप्लिकेशन इस्तेमाल किया जा रहा है, जिसमें ऐप्लिकेशन को उपयोगकर्ता के मनमुताबिक बनाने, डेटाबेस क्वेरी करने, और सर्वर साइड से किए जाने वाले अन्य काम शामिल हैं, तो फ़ील्ड में टीटीएफ़बी को कम करने के लिए, आपकी होस्टिंग की पसंद तय करना ज़रूरी हो जाता है.
होस्टिंग की सेवा देने वाली कंपनी चुनते समय, इन बातों का ध्यान रखें:
- आपके ऐप्लिकेशन इंस्टेंस के लिए कितनी मेमोरी असाइन की गई है? अगर आपके ऐप्लिकेशन में कम मेमोरी है, तो वह कम समय में कम हो जाएगा और पेजों को जल्द से जल्द दिखाना मुश्किल कर देगा.
- क्या सर्वर देने वाली संस्था आपके बैकएंड स्टैक को अप-टू-डेट रखती है? ऐप्लिकेशन बैकएंड भाषाओं, एचटीटीपी इंप्लीमेंटेशन, और डेटाबेस सॉफ़्टवेयर के नए वर्शन रिलीज़ होने पर, समय के साथ उस सॉफ़्टवेयर की परफ़ॉर्मेंस में सुधार होगा. सर्वर देने वाली किसी ऐसी कंपनी के साथ साझेदारी करना ज़रूरी है जो इस तरह के ज़रूरी रखरखाव को प्राथमिकता देती है.
- अगर आपको ऐप्लिकेशन की कुछ खास ज़रूरतें पूरी करनी हैं और आपको सर्वर कॉन्फ़िगरेशन फ़ाइलों के लिए सबसे कम लेवल का ऐक्सेस चाहिए, तो पूछें कि क्या अपने ऐप्लिकेशन इंस्टेंस के बैकएंड को पसंद के मुताबिक बनाना सही है.
आपके लिए इन चीज़ों का ध्यान रखने वाले कई होस्टिंग प्रोवाइडर हैं, लेकिन अगर आपको खास तौर पर होस्टिंग देने वाली कंपनियों में भी टीटीएफ़बी की लंबी वैल्यू दिखने लगती हैं, तो यह इस बात का संकेत हो सकता है कि आपको अपने मौजूदा होस्टिंग प्रोवाइडर की क्षमताओं का फिर से मूल्यांकन करना होगा, ताकि आप सबसे अच्छा उपयोगकर्ता अनुभव दे सकें.
कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) का इस्तेमाल करना
सीडीएन इस्तेमाल विषय काफ़ी लोकप्रिय है, लेकिन ऐसा भी हो सकता है कि आपके पास बेहतर तरीके से ऑप्टिमाइज़ किया गया ऐप्लिकेशन बैकएंड हो. हालांकि, आपके मूल सर्वर से दूर मौजूद उपयोगकर्ताओं को फ़ील्ड में अब भी ज़्यादा टीटीएफ़बी का अनुभव हो सकता है.
सीडीएन, सर्वर के डिस्ट्रिब्यूट किए गए नेटवर्क का इस्तेमाल करके, आपके मूल सर्वर के साथ उपयोगकर्ता की नज़दीकी की समस्या को हल करते हैं. ये सर्वर पर मौजूद ऐसे सर्वर पर रिसॉर्स को कैश मेमोरी में सेव करते हैं जो आपके उपयोगकर्ताओं के सबसे करीब होते हैं. इन सर्वर को एज सर्वर कहा जाता है.
सीडीएन की सेवा देने वाली कंपनियां, किनारे के सर्वर के अलावा भी फ़ायदे दे सकती हैं:
- आम तौर पर, सीडीएन की सेवा देने वाली कंपनियां बहुत तेज़ डीएनएस रिज़ॉल्यूशन की सुविधा देती हैं.
- ऐसा हो सकता है कि सीडीएन, एचटीटीपी/2 या एचटीटीपी/3 जैसे मॉडर्न प्रोटोकॉल का इस्तेमाल करके, किनारे वाले सर्वर से आपका कॉन्टेंट उपलब्ध कराए.
- एचटीटीपी/3 खास तौर पर, यूडीपी प्रोटोकॉल का इस्तेमाल करके टीसीपी में मौजूद हेड-ऑफ़-लाइन ब्लॉक करने की समस्या को हल करता है (जिस पर एचटीटीपी/2 निर्भर करता है).
- सीडीएन, TLS के आधुनिक वर्शन भी उपलब्ध कराता है. इससे TLS से जुड़ी बातचीत के समय में लगने वाले समय को कम किया जाता है. खास तौर पर, TLS 1.3 को TLS से जुड़ी बातचीत को कम से कम बनाए रखने के लिए डिज़ाइन किया गया है.
- कुछ सीडीएन प्रोवाइडर एक ऐसी सुविधा देते हैं जिसे अक्सर "एज वर्कर" कहते हैं. यह सुविधा सर्विस वर्कर एपीआई से मिलते-जुलते एपीआई का इस्तेमाल करके, अनुरोधों को बीच में रखती है, कैश मेमोरी में प्रोग्राम के हिसाब से रिस्पॉन्स मैनेज करती है या जवाबों को पूरी तरह से दोबारा लिखती है.
- सीडीएन प्रोवाइडर, कंप्रेस करने के लिए ऑप्टिमाइज़ करने में बहुत अच्छे होते हैं. कंप्रेशन की सुविधा को खुद ही ठीक करना मुश्किल होता है. इसकी वजह से, डाइनैमिक रूप से जनरेट हुए मार्कअप के साथ कुछ मामलों में रिस्पॉन्स मिलने में ज़्यादा समय लग सकता है, जिन्हें तुरंत कंप्रेस करना ज़रूरी होता है.
- सीडीएन की सेवा देने वाली कंपनियां, स्टैटिक रिसॉर्स के लिए कंप्रेस किए गए जवाबों को अपने-आप कैश मेमोरी में सेव कर देंगी. इससे, कंप्रेस करने का अनुपात और रिस्पॉन्स टाइम, दोनों का बेहतर तरीके से इस्तेमाल किया जा सकेगा.
सीडीएन इस्तेमाल करने में मामूली से अहम कोशिश करने में समय लगता है, लेकिन अगर आपकी वेबसाइट पहले से इसका इस्तेमाल नहीं कर रही है, तो टीटीएफ़बी को ऑप्टिमाइज़ करने की कोशिश करना ज़्यादा प्राथमिकता होगी.
जहां संभव हो वहां कैश मेमोरी में सेव किए गए कॉन्टेंट का इस्तेमाल किया गया
सीडीएन, ऐसे सर्वर सर्वर पर कॉन्टेंट को कैश मेमोरी में सेव करने की अनुमति देते हैं जो वेबसाइट पर आने वाले लोगों के पास मौजूद होते हैं. हालांकि, इसके लिए ज़रूरी है कि कॉन्टेंट को Cache-Control एचटीटीपी हेडर के साथ कॉन्फ़िगर किया गया हो. हालांकि, यह तरीका आपके हिसाब से बनाए गए कॉन्टेंट के लिए सही नहीं है, लेकिन मूल देश की यात्रा पर वापस जाने की ज़रूरत से सीडीएन की काफ़ी अहमियत कम हो सकती है.
ऐसी साइटें जो बार-बार अपना कॉन्टेंट अपडेट करती हैं, वे साइटें कैश मेमोरी में कम समय तक भी काम कर सकती हैं. इससे, व्यस्त साइटों की परफ़ॉर्मेंस बेहतर हो सकती है. ऐसा इसलिए होता है, क्योंकि उस दौरान सिर्फ़ पहली वेबसाइट पर आने वाला ही पूरी तरह से मूल सर्वर पर वापस आता है, जबकि दूसरे सभी विज़िटर कैश मेमोरी में सेव किए गए रिसॉर्स को फिर से इस्तेमाल कर सकते हैं. कुछ सीडीएन, साइट की रिलीज़ पर कैश मेमोरी को अमान्य करने की अनुमति देते हैं. इससे दोनों तरह की रिलीज़, कैश मेमोरी में लंबे समय तक चलती है, लेकिन ज़रूरत पड़ने पर तुरंत अपडेट हो जाती है.
भले ही, कैश मेमोरी को सही तरीके से कॉन्फ़िगर किया गया हो, लेकिन आंकड़ों को मेज़र करने के लिए यूनीक क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, इसे अनदेखा किया जा सकता है. एक जैसा होने के बावजूद, ये सीडीएन से अलग कॉन्टेंट जैसे दिख सकते हैं. इसलिए, कैश मेमोरी में सेव किए गए वर्शन का इस्तेमाल नहीं किया जाएगा.
यह भी हो सकता है कि पुरानी या कम विज़िट की गई सामग्री को कैश मेमोरी में सेव न किया जाए. इसकी वजह से कुछ पेजों पर दूसरों के मुकाबले टीटीएफ़बी की वैल्यू ज़्यादा हो सकती है. कैश मेमोरी में सेव होने का समय बढ़ाने से इसका असर कम हो सकता है. हालांकि, ध्यान रखें कि कैश मेमोरी में सेव होने का समय बढ़ने से, पुराना कॉन्टेंट दिखाने की संभावना बढ़ जाती है.
कैश मेमोरी में सेव किए गए कॉन्टेंट का असर, सिर्फ़ सीडीएन का इस्तेमाल करने वालों पर नहीं पड़ता. अगर कैश मेमोरी में सेव किए गए कॉन्टेंट का फिर से इस्तेमाल नहीं किया जा सकता, तो सर्वर इन्फ़्रास्ट्रक्चर के महंगे डेटाबेस का इस्तेमाल करके कॉन्टेंट जनरेट करना पड़ सकता है. ज़्यादा बार ऐक्सेस किया गया डेटा या पहले से कैश मेमोरी में सेव किए गए पेज, अक्सर बेहतर परफ़ॉर्म कर सकते हैं.
एक से ज़्यादा पेज रीडायरेक्ट करने से बचें
आम तौर पर, रीडायरेक्ट करने की सुविधा, ज़्यादा टीटीएफ़बी में योगदान देने वालों में से एक है. रीडायरेक्ट तब होते हैं, जब किसी दस्तावेज़ के लिए नेविगेशन अनुरोध को जवाब मिलता है. इस रिस्पॉन्स में, ब्राउज़र को बताया जाता है कि संसाधन किसी दूसरी जगह पर मौजूद है. एक रीडायरेक्ट पक्के तौर पर नेविगेशन अनुरोध में अनचाहे इंतज़ार के समय जोड़ सकता है, लेकिन अगर वह रीडायरेक्ट किसी ऐसे दूसरे संसाधन पर ले जाता है, जिसके कारण दूसरा रीडायरेक्ट होता है—वगैरह. इसका असर खास तौर पर उन साइटों पर पड़ सकता है जिन पर विज्ञापनों या न्यूज़लेटर से बड़ी संख्या में लोग आते हैं. इसकी वजह यह है कि वे अक्सर मेज़रमेंट के मकसद से, आंकड़ों से जुड़ी सेवाओं का इस्तेमाल करके रीडायरेक्ट करती हैं. सीधे तौर पर अपने कंट्रोल में रीडायरेक्ट करने की सुविधा को खत्म करने से, एक अच्छा TTFB हासिल करने में मदद मिल सकती है.
रीडायरेक्ट दो तरह के होते हैं:
- एक ही ऑरिजिन वाले रीडायरेक्ट, जहां रीडायरेक्ट पूरी तरह आपकी वेबसाइट पर होता है.
- क्रॉस-ऑरिजिन रीडायरेक्ट, जहां रीडायरेक्ट शुरुआत में किसी दूसरे ऑरिजिन पर होता है. जैसे, सोशल मीडिया के यूआरएल को छोटा करने वाली सेवा से. उदाहरण के लिए, आपकी वेबसाइट पर आने से पहले.
आपको एक ही ऑरिजिन वाले रीडायरेक्ट को हटाने पर ध्यान देना चाहिए, क्योंकि इस पर आपका सीधा कंट्रोल होगा. इस प्रक्रिया में आपकी वेबसाइट पर मौजूद लिंक की जांच की जाएगी, ताकि यह पता लगाया जा सके कि उनमें से किसी लिंक से, 302 या 301 रिस्पॉन्स कोड तो नहीं मिलता. अक्सर ऐसा https:// स्कीम को शामिल न करने की वजह से होता है. ऐसा इसलिए होता है, क्योंकि ब्राउज़र डिफ़ॉल्ट रूप से http:// पर सेट हो जाता है और फिर रीडायरेक्ट करता है. इसके अलावा, ऐसा तब भी हो सकता है, जब यूआरएल में पीछे के स्लैश सही तरीके से शामिल न हों या उसे शामिल न किया गया हो.
क्रॉस-ऑरिजिन रीडायरेक्ट मुश्किल होते हैं, क्योंकि ये अक्सर आपके कंट्रोल से बाहर होते हैं. हालांकि, जहां भी हो सके, एक से ज़्यादा रीडायरेक्ट से बचने की कोशिश करें—उदाहरण के लिए, लिंक शेयर करते समय एक से ज़्यादा लिंक शॉर्टनर का इस्तेमाल करके. पक्का करें कि विज्ञापन देने वालों या न्यूज़लेटर को दिया गया यूआरएल सही फ़ाइनल यूआरएल है, ताकि उन सेवाओं पर दूसरा रीडायरेक्ट न जोड़ा जाए जिनका इस्तेमाल उन सेवाओं में किया जा रहा है.
रीडायरेक्ट होने में लगने वाला एक और अहम सोर्स, एचटीटीपी-टू-एचटीटीपीएस रीडायरेक्ट से मिल सकता है. इससे बचने का एक तरीका यह है कि आप Strict-Transport-Security हेडर (एचएसटीएस) का इस्तेमाल करें. इससे, किसी ऑरिजिन पर पहली बार जाने पर एचटीटीपीएस को लागू किया जाएगा. इसके बाद, आने वाले समय में किसी वेबसाइट पर जाने पर, ब्राउज़र को एचटीटीपीएस स्कीम के ज़रिए ऑरिजिन को तुरंत ऐक्सेस करने के लिए कहा जाएगा.
अच्छी एचएसटी नीति लागू करने के बाद, पहली बार किसी ऑरिजिन पर जाने पर तेज़ी से काम किया जा सकता है. इसके लिए, अपनी साइट को एचएसटीएस प्रीलोड सूची में जोड़ें.
मार्कअप को ब्राउज़र पर स्ट्रीम करें
स्ट्रीम के दौरान, मार्कअप को बेहतर तरीके से प्रोसेस करने के लिए, ब्राउज़र ऑप्टिमाइज़ होते हैं. इसका मतलब है कि जैसे ही सर्वर से मार्कअप आता है, उसे कई हिस्सों में प्रोसेस किया जाता है. यह तब ज़रूरी होता है, जब बड़े मार्कअप पेलोड की बात होती है, क्योंकि इसका मतलब है कि ब्राउज़र, मार्कअप के कई हिस्सों को धीरे-धीरे पार्स कर सकता है. ऐसा इसलिए होता है, क्योंकि पार्स करने की प्रोसेस शुरू होने से पहले, पूरे रिस्पॉन्स के आने का इंतज़ार किया जाता है.
स्ट्रीमिंग मार्कअप को मैनेज करने में ब्राउज़र बेहतरीन तरीके से काम करते हैं. हालांकि, स्ट्रीम को जारी रखने के लिए जितना हो सके उतना ज़रूरी है, ताकि मार्कअप की शुरुआती जानकारी जल्द से जल्द प्रोसेस की जा सके. अगर बैकएंड कुछ कर रहा है, तो यह समस्या है. बैकएंड स्टैक बहुत सारे होते हैं. इसलिए, हर स्टैक और हर स्टैक से होने वाली समस्याओं को कवर करना इस गाइड के दायरे से बाहर है.
उदाहरण के लिए, प्रतिक्रिया देने और ऐसे दूसरे फ़्रेमवर्क जो सर्वर पर मांग पर मार्कअप रेंडर कर सकते हैं—उनमें सर्वर साइड रेंडरिंग के लिए सिंक्रोनस तरीके का इस्तेमाल किया गया है. हालांकि, React के नए वर्शन में रेंडर होने के दौरान, स्ट्रीमिंग मार्कअप के लिए सर्वर तरीके लागू किए गए हैं. इसका मतलब है कि आपको पूरे जवाब को भेजने से पहले, React सर्वर एपीआई के तरीके से पूरे जवाब को रेंडर करने का इंतज़ार नहीं करना होगा.
मार्कअप को ब्राउज़र पर तेज़ी से स्ट्रीम किया जा सकता है, इसके लिए एक और तरीका है स्टैटिक रेंडरिंग पर भरोसा करना, जो बिल्ड के दौरान एचटीएमएल फ़ाइलें जनरेट करती है. पूरी फ़ाइल तुरंत उपलब्ध होने पर वेब सर्वर, फ़ाइल को तुरंत भेजना शुरू कर सकते हैं. एचटीटीपी की मौजूदा प्रकृति की वजह से, स्ट्रीमिंग मार्कअप तैयार हो जाएगा. यह तरीका हर वेबसाइट के हर पेज के लिए सही नहीं है. उदाहरण के लिए, यह तरीका उन पेजों के लिए फ़ायदेमंद हो सकता है जिन पर किसी उपयोगकर्ता के हिसाब से कॉन्टेंट दिखाने के लिए मार्कअप की ज़रूरत नहीं होती. जैसे- ऐसे पेज जिनके लिए उपयोगकर्ता अनुभव में डाइनैमिक रिस्पॉन्स की ज़रूरत होती है.
सर्विस वर्कर का इस्तेमाल करना
Service Worker API का, दस्तावेज़ों और लोड किए जाने वाले संसाधनों, दोनों के लिए TTFB पर बड़ा असर पड़ सकता है. इसका कारण यह है कि सर्विस वर्कर ब्राउज़र और सर्वर के बीच प्रॉक्सी के रूप में काम करता है—लेकिन आपकी वेबसाइट के टीटीएफ़बी पर इसका प्रभाव है या नहीं, यह इस बात पर निर्भर करता है कि आपने सर्विस वर्कर को कैसे सेट अप किया है और वह सेटअप आपके ऐप्लिकेशन की ज़रूरतों के मुताबिक है या नहीं.
- ऐसेट के लिए, फिर से पुष्टि करने के दौरान पुरानी रणनीति का इस्तेमाल करें. अगर कोई एसेट सर्विस वर्कर कैश मेमोरी में है, तो यह कोई ऐसा दस्तावेज़ या संसाधन हो सकता है जिसकी ज़रूरत दस्तावेज़ को चाहिए. 'फिर से पुष्टि करने की पुरानी रणनीति', पहले कैश मेमोरी से उस संसाधन को उपलब्ध कराती है. इसके बाद, उस एसेट को बैकग्राउंड में डाउनलोड करेगी और आगे होने वाले इंटरैक्शन के लिए कैश मेमोरी से इस्तेमाल करेगी.
- अगर आपके पास ऐसे दस्तावेज़ संसाधन हैं जो बार-बार नहीं बदलते हैं, तो फिर से पुष्टि करने की पुरानी रणनीति का इस्तेमाल करने से, पेज का TTFB तुरंत वर्शन बनाया जा सकता है. हालांकि, अगर आपकी वेबसाइट डाइनैमिक रूप से जनरेट किए गए मार्कअप भेजती है, तो यह बेहतर तरीके से काम नहीं करता. उदाहरण के लिए, मार्कअप, जो इस आधार पर बदलता है कि उपयोगकर्ता की पुष्टि हुई है या नहीं. ऐसे मामलों में, आपको हमेशा पहले नेटवर्क को हिट करना होगा, ताकि दस्तावेज़ जितना हो सके उतना नया हो.
- अगर आपका दस्तावेज़ ऐसे गैर-ज़रूरी संसाधनों को लोड करता है जो कुछ फ़्रीक्वेंसी के साथ बदलते हैं, लेकिन पुराने रिसॉर्स को फ़ेच करने से उपयोगकर्ता अनुभव पर ज़्यादा असर नहीं पड़ता है—जैसे कि चुनी हुई इमेज या ऐसे दूसरे संसाधन जो ज़रूरी नहीं हैं, तो उन संसाधनों के लिए टीटीएफ़बी को, फिर से पुष्टि करने की पुरानी रणनीति का इस्तेमाल करके बहुत कम किया जा सकता है.
- अगर हो सके, तो स्ट्रीमिंग सर्विस वर्कर आर्किटेक्चर का इस्तेमाल करें. यह सर्विस वर्कर आर्किटेक्चर एक ऐसे तरीके का इस्तेमाल करता है जिसमें दस्तावेज़ के संसाधन के कुछ हिस्से, सर्विस वर्कर कैश में स्टोर होते हैं और नेविगेशन के अनुरोध के दौरान कॉन्टेंट के कुछ हिस्सों को मिला देते हैं. इस सर्विस वर्कर पैटर्न का इस्तेमाल करने से नेविगेशन काफ़ी तेज़ हो जाता है, जबकि नेटवर्क से छोटे एचटीएमएल पेलोड डाउनलोड हो जाते हैं. हालांकि, सर्विस वर्कर का यह पैटर्न हर वेबसाइट के लिए काम नहीं करता, लेकिन दस्तावेज़ के संसाधनों का TTFB समय, उन साइटों के लिए तुरंत इस्तेमाल किया जा सकता है जो इसका इस्तेमाल कर सकती हैं.
- क्लाइंट के रेंडर किए गए ऐप्लिकेशन के लिए, ऐप्लिकेशन शेल मॉडल का इस्तेमाल करें. यह मॉडल एसपीए के लिए सबसे सही है, जहां पेज के "शेल" को सर्विस वर्कर कैश मेमोरी से तुरंत डिलीवर किया जा सकता है. साथ ही, पेज का डाइनैमिक कॉन्टेंट अपने-आप भर जाता है और पेज के लाइफ़साइकल में बाद में रेंडर होता है.
रेंडर से जुड़े अहम संसाधनों के लिए, 103 Early Hints का इस्तेमाल करें
इससे कोई फ़र्क़ नहीं पड़ता कि आपका ऐप्लिकेशन बैकएंड कितने अच्छे से ऑप्टिमाइज़ किया गया है, लेकिन जवाब तैयार करने के लिए सर्वर को काफ़ी ज़्यादा काम करना पड़ सकता है. इसमें डेटाबेस का महंगा काम भी शामिल है, जिसकी वजह से नेविगेशन रिस्पॉन्स को जल्द से जल्द पहुंचने में देरी होती है. इसके संभावित असर के बाद, रेंडर करने के लिए ज़रूरी कुछ संसाधनों को प्रोसेस करने में देर हो सकती है. जैसे, सीएसएस या कुछ मामलों में JavaScript, जो क्लाइंट पर मार्कअप को रेंडर करती है.
103 Early Hints हेडर ऐसा शुरुआती रिस्पॉन्स कोड होता है जिसे सर्वर, ब्राउज़र को तब भेज सकता है, जब बैकएंड, मार्कअप तैयार करने में व्यस्त हो. इस हेडर का इस्तेमाल ब्राउज़र को यह संकेत देने के लिए किया जा सकता है कि मार्कअप तैयार होने के दौरान पेज को डाउनलोड करने के लिए ज़रूरी रेंडर करने वाले संसाधन मौजूद हैं. साथ काम करने वाले ब्राउज़र के लिए, दस्तावेज़ को तेज़ी से रेंडर करने (सीएसएस) और मुख्य पेज के काम करने के तरीके (JavaScript) की तेज़ उपलब्धता, असर डाल सकती है.
नतीजा
बैकएंड ऐप्लिकेशन स्टैक के कई कॉम्बिनेशन होते हैं, इसलिए ऐसा कोई भी लेख नहीं है जिसमें वे सभी चीज़ें शामिल की जा सकें जिनसे आपकी वेबसाइट के टीटीएफ़बी को कम किया जा सकता है. हालांकि, ये कुछ ऐसे विकल्प हैं जिन्हें एक्सप्लोर करके सर्वर साइड पर चीज़ों को और तेज़ी से आगे बढ़ाया जा सकता है.
हर मेट्रिक को ऑप्टिमाइज़ करने के तरीके में भी काफ़ी हद तक एक जैसा ही है: फ़ील्ड में अपने TTFB का आकलन करें, समस्याओं को गहराई से समझने के लिए लैब टूल का इस्तेमाल करें, और जहां संभव हो वहां ऑप्टिमाइज़ेशन लागू करें. ऐसा हो सकता है कि यहां दी गई हर तकनीक आपके लिए कारगर न हो, लेकिन कुछ तकनीक आपके लिए कारगर साबित हो सकती है. हमेशा की तरह, आपको अपने फ़ील्ड डेटा पर बारीकी से नज़र रखनी होगी. साथ ही, उपयोगकर्ताओं को जल्द से जल्द अनुभव देने के लिए, उनमें ज़रूरत के मुताबिक बदलाव करने होंगे.
अनस्प्लैशर से लिया गया, टेलर विक की हीरो इमेज.