टाइम टू फ़र्स्ट बाइट मेट्रिक को ऑप्टिमाइज़ करने का तरीका जानें.
पब्लिश होने की तारीख: 19 जनवरी, 2023, पिछली बार अपडेट किए जाने की तारीख: 28 नवंबर, 2025
टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी), वेब परफ़ॉर्मेंस की एक बुनियादी मेट्रिक है. यह उपयोगकर्ता अनुभव की अन्य सभी अहम मेट्रिक से पहले आती है. जैसे, साइट का पहला एलिमेंट लोड होने में लगने वाला समय (एफ़सीपी) और सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी). इसका मतलब है कि टीटीएफ़बी की ज़्यादा वैल्यू, इसके बाद आने वाली मेट्रिक में समय जोड़ती हैं.
हमारा सुझाव है कि आपका सर्वर, नेविगेशन के अनुरोधों का जवाब तुरंत दे, ताकि 75वें पर्सेंटाइल के उपयोगकर्ताओं को "अच्छी" थ्रेशोल्ड के अंदर एफसीपी का अनुभव मिले. आम तौर पर, ज़्यादातर साइटों का टीटीएफ़बी 0.8 सेकंड या इससे कम होना चाहिए.
टीटीएफ़बी को कैसे मेज़र करें
टीटीएफ़बी को ऑप्टिमाइज़ करने से पहले, आपको यह देखना होगा कि इससे आपकी वेबसाइट के उपयोगकर्ताओं पर क्या असर पड़ता है. टीटीएफ़बी को मॉनिटर करने के लिए, आपको मुख्य सोर्स के तौर पर फ़ील्ड डेटा पर भरोसा करना चाहिए. ऐसा इसलिए, क्योंकि रीडायरेक्ट की वजह से टीटीएफ़बी पर असर पड़ता है. वहीं, लैब पर आधारित टूल अक्सर फ़ाइनल यूआरएल का इस्तेमाल करके मेज़र किए जाते हैं. इसलिए, इस अतिरिक्त देरी का पता नहीं चलता.
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 रिस्पॉन्स हेडर सेट वाला कोई भी पेज, Navigation Timing API में 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 में परफ़ॉर्मेंस पैनल के नेटवर्क ट्रैक में भी दिखती हैं:
उपलब्ध डेटा का विश्लेषण करके, यह पता लगाया जा सकता है कि आपके टीटीएफ़बी में कोई समस्या है या नहीं. इसके बाद, समस्या को ठीक किया जा सकता है.
टीटीएफ़बी को ऑप्टिमाइज़ करने के तरीके
टीटीएफ़बी को ऑप्टिमाइज़ करने में सबसे बड़ी चुनौती यह है कि वेब का फ़्रंटएंड स्टैक हमेशा एचटीएमएल, सीएसएस, और JavaScript होता है. हालांकि, बैकएंड स्टैक काफ़ी अलग हो सकते हैं. कई बैकएंड स्टैक और डेटाबेस प्रॉडक्ट होते हैं. हर प्रॉडक्ट की अपनी ऑप्टिमाइज़ेशन तकनीक होती है. इसलिए, यह गाइड सिर्फ़ स्टैक के हिसाब से दिशा-निर्देश देने के बजाय, ज़्यादातर आर्किटेक्चर पर लागू होने वाली चीज़ों पर फ़ोकस करती है.
प्लैटफ़ॉर्म के हिसाब से दिशा-निर्देश
आपकी वेबसाइट के लिए इस्तेमाल किए जाने वाले प्लैटफ़ॉर्म का टीटीएफ़बी पर काफ़ी असर पड़ सकता है. उदाहरण के लिए, WordPress की परफ़ॉर्मेंस पर प्लगिन की संख्या और क्वालिटी या इस्तेमाल की गई थीम का असर पड़ता है. प्लैटफ़ॉर्म को पसंद के मुताबिक बनाने पर, अन्य प्लैटफ़ॉर्म पर भी इसी तरह असर पड़ता है. इस पोस्ट में परफ़ॉर्मेंस से जुड़ी सामान्य सलाह दी गई है. वेंडर के हिसाब से सलाह पाने के लिए, आपको अपने प्लैटफ़ॉर्म के दस्तावेज़ देखने चाहिए. Lighthouse की अहम जानकारी में, स्टैक के हिसाब से कुछ सीमित दिशा-निर्देश भी शामिल होते हैं.
होस्टिंग, होस्टिंग, होस्टिंग
ऑप्टिमाइज़ेशन के अन्य तरीकों पर विचार करने से पहले, आपको होस्टिंग पर विचार करना चाहिए. यहां आपको ज़्यादा जानकारी नहीं दी जा सकती. हालांकि, एक सामान्य नियम यह है कि आपको यह पक्का करना होगा कि आपकी वेबसाइट का होस्ट, उस पर आने वाले ट्रैफ़िक को मैनेज कर सके.
शेयर की गई होस्टिंग आम तौर पर धीमी होती है. अगर आपकी कोई छोटी निजी वेबसाइट है, जो ज़्यादातर स्टैटिक फ़ाइलें दिखाती है, तो शायद यह ठीक है. टीटीएफ़बी को कम करने के लिए, ऑप्टिमाइज़ेशन की कुछ तकनीकों का इस्तेमाल करें.
हालांकि, अगर आपके पास कई उपयोगकर्ताओं वाला बड़ा ऐप्लिकेशन है, जिसमें लोगों की दिलचस्पी के हिसाब से कॉन्टेंट दिखाना, डेटाबेस क्वेरी करना, और सर्वर-साइड पर होने वाली अन्य जटिल कार्रवाइयां शामिल हैं, तो फ़ील्ड में टीटीएफ़बी को कम करने के लिए, होस्टिंग का विकल्प चुनना ज़रूरी हो जाता है.
होस्टिंग की सेवा देने वाली कंपनी चुनते समय, इन बातों का ध्यान रखें:
- आपके ऐप्लिकेशन इंस्टेंस को कितनी मेमोरी असाइन की गई है? अगर आपके ऐप्लिकेशन में ज़रूरत के मुताबिक मेमोरी नहीं है, तो वह थ्रैश हो जाएगा. साथ ही, पेजों को जल्द से जल्द लोड करने में उसे परेशानी होगी.
- क्या सर्वर देने वाली संस्था आपके बैकएंड स्टैक को अप-टू-डेट रखती है? ऐप्लिकेशन बैकएंड भाषाओं, एचटीटीपी लागू करने के तरीकों, और डेटाबेस सॉफ़्टवेयर के नए वर्शन रिलीज़ होने पर, समय के साथ उस सॉफ़्टवेयर की परफ़ॉर्मेंस बेहतर होती जाती है. इसलिए, सर्वर देने वाली ऐसी संस्था के साथ पार्टनरशिप करना ज़रूरी है जो इस तरह के रखरखाव को प्राथमिकता देती हो.
- अगर आपके ऐप्लिकेशन की ज़रूरतें बहुत खास हैं और आपको सर्वर की कॉन्फ़िगरेशन फ़ाइलों का सबसे निचले लेवल का ऐक्सेस चाहिए, तो पूछें कि क्या आपके ऐप्लिकेशन इंस्टेंस के बैकएंड को पसंद के मुताबिक बनाना सही रहेगा.
सर्वर देने वाली ऐसी कई संस्थाएं हैं जो आपके लिए इन चीज़ों का ध्यान रखती हैं. हालांकि, अगर आपको सर्वर देने वाली संस्थाओं के मामले में भी टीटीएफ़बी की वैल्यू ज़्यादा दिखती है, तो हो सकता है कि आपको सर्वर देने वाली अपनी मौजूदा संस्था की क्षमताओं का फिर से आकलन करना पड़े. इससे आपको उपयोगकर्ताओं को बेहतर अनुभव देने में मदद मिलेगी.
कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) का इस्तेमाल करना
सीडीएन के इस्तेमाल का विषय काफ़ी जाना-पहचाना है. हालांकि, इसकी एक अच्छी वजह है: आपके पास बहुत अच्छी तरह से ऑप्टिमाइज़ किया गया ऐप्लिकेशन बैकएंड हो सकता है. हालांकि, आपके मूल सर्वर से दूर रहने वाले उपयोगकर्ताओं को अब भी फ़ील्ड में ज़्यादा टीटीएफ़बी का अनुभव हो सकता है.
सीडीएन, आपके मूल सर्वर से उपयोगकर्ता की दूरी की समस्या को हल करते हैं. इसके लिए, वे सर्वर के डिस्ट्रिब्यूटेड नेटवर्क का इस्तेमाल करते हैं. यह नेटवर्क, उपयोगकर्ताओं के आस-पास मौजूद सर्वर पर संसाधनों को कैश मेमोरी में सेव करता है. इन सर्वर को एज सर्वर कहा जाता है.
सीडीएन की सेवा देने वाली कंपनियां, एज सर्वर के अलावा अन्य फ़ायदे भी दे सकती हैं:
- सीडीएन सेवा देने वाली कंपनियां, आम तौर पर डीएनएस रिज़ॉल्यूशन के लिए बहुत कम समय लेती हैं.
- सीडीएन, एचटीटीपी/2 या एचटीटीपी/3 जैसे मॉडर्न प्रोटोकॉल का इस्तेमाल करके, आपके कॉन्टेंट को एज सर्वर से दिखाता है.
- खास तौर पर, एचटीटीपी/3, टीसीपी (जिस पर एचटीटीपी/2 निर्भर करता है) में मौजूद हेड-ऑफ़-लाइन ब्लॉकिंग की समस्या को हल करता है. इसके लिए, वह यूडीपी प्रोटोकॉल का इस्तेमाल करता है.
- सीडीएन, टीएलएस के आधुनिक वर्शन उपलब्ध कराता है. इससे टीएलएस नेगोशिएशन में लगने वाला समय कम हो जाता है. खास तौर पर, टीएलएस 1.3 को इस तरह डिज़ाइन किया गया है कि टीएलएस नेगोशिएशन को कम से कम समय में पूरा किया जा सके.
- सीडीएन की सुविधा देने वाली कुछ कंपनियां, "एज वर्कर" नाम की सुविधा देती हैं. यह सुविधा, सर्विस वर्कर एपीआई जैसे एपीआई का इस्तेमाल करती है. इससे अनुरोधों को इंटरसेप्ट किया जा सकता है, एज कैश में जवाबों को प्रोग्राम के हिसाब से मैनेज किया जा सकता है या जवाबों को पूरी तरह से फिर से लिखा जा सकता है.
- सीडीएन सेवा देने वाली कंपनियां, कंप्रेस करने के लिए ऑप्टिमाइज़ करने में बहुत अच्छी होती हैं. कंप्रेशन को खुद से सही करना मुश्किल होता है. साथ ही, डाइनैमिक तौर पर जनरेट किए गए मार्कअप के कुछ मामलों में, रिस्पॉन्स मिलने में ज़्यादा समय लग सकता है. इन्हें तुरंत कंप्रेस करना ज़रूरी है.
- साथ ही, सीडीएन की सेवा देने वाली कंपनियां, स्टैटिक रिसॉर्स के लिए कंप्रेस किए गए रिस्पॉन्स को अपने-आप कैश मेमोरी में सेव करती हैं. इससे कंप्रेस करने के अनुपात और रिस्पॉन्स टाइम का सबसे अच्छा कॉम्बिनेशन मिलता है.
सीडीएन को अपनाने में, कम से कम से लेकर ज़्यादा से ज़्यादा मेहनत लग सकती है. हालांकि, अगर आपकी वेबसाइट पर पहले से सीडीएन का इस्तेमाल नहीं किया जा रहा है, तो टीटीएफ़बी को ऑप्टिमाइज़ करने के लिए, इसे अपनाना आपकी प्राथमिकता होनी चाहिए.
जहां हो सके वहां कैश मेमोरी में सेव किए गए कॉन्टेंट का इस्तेमाल करें
सीडीएन, कॉन्टेंट को एज सर्वर पर कैश मेमोरी में सेव करने की अनुमति देते हैं. ये सर्वर, विज़िटर के काफ़ी नज़दीक होते हैं. हालांकि, इसके लिए ज़रूरी है कि कॉन्टेंट को सही Cache-Control एचटीटीपी हेडर के साथ कॉन्फ़िगर किया गया हो. हालांकि, यह लोगों के हिसाब से बनाए गए कॉन्टेंट के लिए सही नहीं है. साथ ही, ओरिजिन पर वापस जाने की ज़रूरत पड़ने पर, सीडीएन की ज़्यादातर वैल्यू खत्म हो सकती है.
जिन साइटों का कॉन्टेंट अक्सर अपडेट होता रहता है उनके लिए, कैश मेमोरी में सेव करने का कम समय भी काफ़ी फ़ायदेमंद हो सकता है. ऐसा इसलिए, क्योंकि इस दौरान सिर्फ़ पहले विज़िटर को मूल सर्वर पर वापस जाने में पूरी लेटेंसी का अनुभव होता है. वहीं, अन्य सभी विज़िटर, एज सर्वर से कैश मेमोरी में सेव किए गए रिसॉर्स का फिर से इस्तेमाल कर सकते हैं. कुछ सीडीएन, साइट रिलीज़ पर कैश मेमोरी को अमान्य करने की अनुमति देते हैं. इससे दोनों तरह के फ़ायदे मिलते हैं—कैश मेमोरी में डेटा लंबे समय तक सेव रहता है, लेकिन ज़रूरत पड़ने पर तुरंत अपडेट भी हो जाता है.
अगर कैश मेमोरी को सही तरीके से कॉन्फ़िगर किया गया है, तो भी आंकड़ों को मेज़र करने के लिए यूनीक क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, इसे अनदेखा किया जा सकता है. सीडीएन को ये अलग-अलग कॉन्टेंट लग सकते हैं, भले ही ये एक जैसे हों. इसलिए, कैश मेमोरी में सेव किए गए वर्शन का इस्तेमाल नहीं किया जाएगा.
ऐसा भी हो सकता है कि पुराने या कम विज़िट किए गए कॉन्टेंट को कैश मेमोरी में सेव न किया गया हो. इस वजह से, कुछ पेजों पर टीटीएफ़बी की वैल्यू, अन्य पेजों की तुलना में ज़्यादा हो सकती है. कैश मेमोरी में डेटा सेव होने का समय बढ़ाने से, इस समस्या का असर कम किया जा सकता है. हालांकि, ध्यान रखें कि कैश मेमोरी में डेटा सेव होने का समय बढ़ाने से, पुराना कॉन्टेंट दिखने की संभावना बढ़ जाती है.
कैश मेमोरी में सेव किए गए कॉन्टेंट का असर, सिर्फ़ सीडीएन का इस्तेमाल करने वालों पर नहीं पड़ता. जब कैश मेमोरी में सेव किए गए कॉन्टेंट का फिर से इस्तेमाल नहीं किया जा सकता, तब सर्वर इन्फ़्रास्ट्रक्चर को महंगे डेटाबेस लुकअप से कॉन्टेंट जनरेट करना पड़ सकता है. अक्सर ऐक्सेस किए जाने वाले डेटा या पहले से कैश मेमोरी में सेव किए गए पेजों की परफ़ॉर्मेंस अक्सर बेहतर होती है.
एक से ज़्यादा पेज पर रीडायरेक्ट करने से बचें
टीटीएफ़बी के ज़्यादा होने की एक आम वजह रीडायरेक्ट है. रीडायरेक्ट तब होते हैं, जब किसी दस्तावेज़ के लिए नेविगेशन अनुरोध को ऐसा जवाब मिलता है जिससे ब्राउज़र को पता चलता है कि संसाधन किसी दूसरी जगह पर मौजूद है. एक रीडायरेक्ट, नेविगेशन अनुरोध में अनचाही देरी जोड़ सकता है. हालांकि, अगर वह रीडायरेक्ट किसी दूसरे संसाधन पर ले जाता है, तो स्थिति और खराब हो सकती है. इससे एक और रीडायरेक्ट हो सकता है. इसी तरह, यह सिलसिला आगे भी जारी रह सकता है. इससे खास तौर पर उन साइटों पर असर पड़ सकता है जिन पर विज्ञापनों या न्यूज़लेटर से बड़ी संख्या में विज़िटर आते हैं. ऐसा इसलिए, क्योंकि वे अक्सर मेज़रमेंट के मकसद से, Analytics सेवाओं के ज़रिए रीडायरेक्ट करते हैं. अपने कंट्रोल में मौजूद रीडायरेक्ट को हटाने से, टीटीएफ़बी को बेहतर बनाने में मदद मिल सकती है.
रीडायरेक्ट दो तरह के होते हैं:
- एक ही ऑरिजिन वाले रीडायरेक्ट, जहां रीडायरेक्ट पूरी तरह से आपकी वेबसाइट पर होता है.
- क्रॉस-ऑरिजिन रीडायरेक्ट, जहां रीडायरेक्ट आपकी वेबसाइट पर पहुंचने से पहले, किसी दूसरे ऑरिजिन पर होता है. जैसे, सोशल मीडिया पर यूआरएल छोटा करने वाली सेवा.
एक ही ऑरिजिन वाले रीडायरेक्ट को हटाने पर फ़ोकस करें, क्योंकि इस पर आपका सीधा कंट्रोल होता है. इसके लिए, अपनी वेबसाइट पर मौजूद लिंक की जांच करके देखें कि उनमें से किसी लिंक पर क्लिक करने पर, 302 या 301 रिस्पॉन्स कोड तो नहीं मिल रहा है. अक्सर ऐसा https:// स्कीम को शामिल न करने की वजह से हो सकता है. इस वजह से, ब्राउज़र डिफ़ॉल्ट रूप से http:// पर सेट हो जाते हैं और फिर रीडायरेक्ट करते हैं. इसके अलावा, ऐसा यूआरएल में ट्रेलिंग स्लैश को सही तरीके से शामिल न करने या हटाने की वजह से भी हो सकता है.
क्रॉस-ऑरिजिन रीडायरेक्ट ज़्यादा मुश्किल होते हैं, क्योंकि ये अक्सर आपके कंट्रोल से बाहर होते हैं. हालांकि, जहां तक हो सके कई रीडायरेक्ट से बचें. उदाहरण के लिए, लिंक शेयर करते समय कई लिंक शॉर्टनर का इस्तेमाल करें. पक्का करें कि विज्ञापन देने वाले लोगों या कंपनियों या न्यूज़लेटर को दिया गया यूआरएल, सही फ़ाइनल यूआरएल हो. इससे, उन सेवाओं के इस्तेमाल किए गए रीडायरेक्ट में कोई दूसरा रीडायरेक्ट नहीं जोड़ा जाएगा.
रीडायरेक्ट होने में लगने वाले समय का एक और अहम सोर्स, एचटीटीपी से एचटीटीपीएस पर रीडायरेक्ट होना हो सकता है. इस समस्या से बचने का एक तरीका है, Strict-Transport-Security हेडर (एचएसटीएस) का इस्तेमाल करना. इससे किसी ऑरिजिन पर पहली बार जाने पर एचटीटीपीएस लागू होता है. इसके बाद, आने वाले समय में जब भी उस ऑरिजिन को ऐक्सेस किया जाता है, तो ब्राउज़र को एचटीटीपीएस स्कीम के ज़रिए ऑरिजिन को तुरंत ऐक्सेस करने के लिए कहा जाता है.
एचएसटीएस की अच्छी नीति लागू करने के बाद, किसी ऑरिजिन पर पहली बार विज़िट करने पर, चीज़ों को तेज़ी से लोड किया जा सकता है. इसके लिए, अपनी साइट को एचएसटीएस प्रीलोड सूची में जोड़ें.
ब्राउज़र पर मार्कअप स्ट्रीम करना
ब्राउज़र को इस तरह से ऑप्टिमाइज़ किया जाता है कि वे मार्कअप को स्ट्रीम किए जाने पर, उसे बेहतर तरीके से प्रोसेस कर सकें. इसका मतलब है कि सर्वर से मिलने वाले मार्कअप को अलग-अलग हिस्सों में प्रोसेस किया जाता है. यह तब ज़रूरी होता है, जब मार्कअप पेलोड का साइज़ बड़ा हो. इसका मतलब है कि ब्राउज़र, मार्कअप के हिस्सों को धीरे-धीरे पार्स कर सकता है. इसके लिए, उसे पूरा रिस्पॉन्स मिलने का इंतज़ार नहीं करना पड़ता.
हालांकि, ब्राउज़र स्ट्रीमिंग मार्कअप को मैनेज करने में बेहतरीन होते हैं, लेकिन यह ज़रूरी है कि आप उस स्ट्रीम को जारी रखने के लिए हर संभव कोशिश करें, ताकि मार्कअप के शुरुआती बिट जल्द से जल्द अपने रास्ते पर हों. अगर बैकएंड की वजह से चीज़ें रुक रही हैं, तो यह एक समस्या है. बैकएंड स्टैक कई तरह के होते हैं. इसलिए, इस गाइड में हर स्टैक और उससे जुड़ी समस्याओं को शामिल करना मुमकिन नहीं है.
उदाहरण के लिए, React और अन्य फ़्रेमवर्क, सर्वर पर मांग के हिसाब से मार्कअप रेंडर कर सकते हैं. इन्होंने सर्वर-साइड रेंडरिंग के लिए, सिंक्रोनस तरीके का इस्तेमाल किया है. हालांकि, React के नए वर्शन में मार्कअप को रेंडर करते समय स्ट्रीम करने के लिए सर्वर के तरीके लागू किए गए हैं. इसका मतलब है कि आपको React सर्वर एपीआई के तरीके का इंतज़ार नहीं करना पड़ेगा, ताकि वह पूरा रिस्पॉन्स रेंडर कर सके.
मार्कअप को ब्राउज़र पर तेज़ी से स्ट्रीम करने का एक और तरीका है, स्टैटिक रेंडरिंग का इस्तेमाल करना. इससे बिल्ड टाइम के दौरान एचटीएमएल फ़ाइलें जनरेट होती हैं. पूरी फ़ाइल तुरंत उपलब्ध होने पर, वेब सर्वर फ़ाइल को तुरंत भेजना शुरू कर सकते हैं. साथ ही, एचटीटीपी की अपनी खासियत की वजह से, मार्कअप को स्ट्रीम किया जा सकता है. हालांकि, यह तरीका हर वेबसाइट के हर पेज के लिए सही नहीं है. जैसे, ऐसे पेज जिनके लिए उपयोगकर्ता अनुभव के तौर पर डाइनैमिक रिस्पॉन्स की ज़रूरत होती है. हालांकि, यह उन पेजों के लिए फ़ायदेमंद हो सकता है जिनके लिए मार्कअप को किसी खास उपयोगकर्ता के हिसाब से बनाने की ज़रूरत नहीं होती.
सर्विस वर्कर का इस्तेमाल करना
सर्विस वर्कर एपीआई, दस्तावेज़ों और उनके लोड किए जाने वाले संसाधनों, दोनों के लिए टीटीएफ़बी पर बड़ा असर डाल सकता है. इसकी वजह यह है कि सर्विस वर्कर, ब्राउज़र और सर्वर के बीच प्रॉक्सी के तौर पर काम करता है. हालांकि, आपकी वेबसाइट के टीटीएफ़बी पर इसका असर पड़ेगा या नहीं, यह इस बात पर निर्भर करता है कि आपने सर्विस वर्कर को कैसे सेट अप किया है. साथ ही, यह भी मायने रखता है कि वह सेटअप आपके ऐप्लिकेशन की ज़रूरी शर्तों के मुताबिक है या नहीं.
- ऐसेट के लिए, stale-while-revalidate रणनीति का इस्तेमाल करें. अगर कोई ऐसेट सर्विस वर्कर की कैश मेमोरी में मौजूद है, तो stale-while-revalidate रणनीति उस ऐसेट को सबसे पहले कैश मेमोरी से उपलब्ध कराती है. भले ही, वह कोई दस्तावेज़ हो या दस्तावेज़ के लिए ज़रूरी कोई संसाधन. इसके बाद, वह उस ऐसेट को बैकग्राउंड में डाउनलोड करती है और आने वाले समय में होने वाले इंटरैक्शन के लिए, उसे कैश मेमोरी से उपलब्ध कराती है.
- अगर आपके पास ऐसे दस्तावेज़ संसाधन हैं जिनमें अक्सर बदलाव नहीं होता है, तो stale-while-revalidate रणनीति का इस्तेमाल करके, किसी पेज के टीटीएफ़बी को करीब-करीब तुरंत लोड किया जा सकता है. हालांकि, अगर आपकी वेबसाइट डाइनैमिक तरीके से जनरेट किया गया मार्कअप भेजती है, तो यह तरीका सही से काम नहीं करता. जैसे, ऐसा मार्कअप जो इस आधार पर बदलता है कि उपयोगकर्ता की पुष्टि हुई है या नहीं. ऐसे मामलों में, आपको हमेशा सबसे पहले नेटवर्क को हिट करना होगा, ताकि दस्तावेज़ ज़्यादा से ज़्यादा अप-टू-डेट रहे.
- अगर आपके दस्तावेज़ में ऐसे गैर-ज़रूरी संसाधन लोड होते हैं जो कुछ समय के अंतराल पर बदलते रहते हैं, लेकिन पुराने संसाधन को फ़ेच करने से उपयोगकर्ता अनुभव पर ज़्यादा असर नहीं पड़ता, तो उन संसाधनों के लिए टीटीएफ़बी को काफ़ी कम किया जा सकता है. इसके लिए, stale-while-revalidate रणनीति का इस्तेमाल किया जा सकता है. जैसे, चुनिंदा इमेज या अन्य संसाधन जो ज़रूरी नहीं हैं.
- क्लाइंट-रेंडर किए गए ऐप्लिकेशन के लिए, ऐप्लिकेशन शेल मॉडल का इस्तेमाल करें. यह मॉडल, एसपीए के लिए सबसे सही है. इसमें पेज के "शेल" को सर्विस वर्कर कैश मेमोरी से तुरंत डिलीवर किया जा सकता है. साथ ही, पेज के लगातार अपडेट होने वाली जानकारी को पेज के लाइफ़साइकल में बाद में पॉप्युलेट और रेंडर किया जाता है.
रेंडर-क्रिटिकल रिसॉर्स के लिए, 103 Early Hints का इस्तेमाल करें
आपके ऐप्लिकेशन का बैकएंड चाहे कितना भी ऑप्टिमाइज़ किया गया हो, फिर भी सर्वर को जवाब तैयार करने के लिए काफ़ी काम करना पड़ सकता है. इसमें डेटाबेस से जुड़ा महंगा (लेकिन ज़रूरी) काम भी शामिल है. इसकी वजह से, नेविगेशन के जवाब मिलने में देरी होती है. इसका असर यह हो सकता है कि रेंडर करने के लिए ज़रूरी कुछ रिसॉर्स को लोड होने में देरी हो सकती है. जैसे, सीएसएस या कुछ मामलों में JavaScript, जो क्लाइंट पर मार्कअप रेंडर करता है.
103 Early Hints हेडर, शुरुआती रिस्पॉन्स कोड होता है. इसे सर्वर, ब्राउज़र को तब भेज सकता है, जब बैकएंड मार्कअप तैयार करने में व्यस्त हो. इस हेडर का इस्तेमाल, ब्राउज़र को यह बताने के लिए किया जा सकता है कि पेज पर रेंडर करने के लिए ज़रूरी रिसॉर्स मौजूद हैं. मार्कअप तैयार होने के दौरान, पेज को इन रिसॉर्स को डाउनलोड करना शुरू कर देना चाहिए. इस्तेमाल किए जा सकने वाले ब्राउज़र के लिए, दस्तावेज़ रेंडरिंग (सीएसएस) और पेज लोड होने की प्रोसेस तेज़ हो सकती है.
103 Early Hints का एक नुकसान यह है कि कैश मेमोरी की तरह, यह भी किसी साइट के "असल" टीटीएफ़बी को छिपा सकता है. अगर सर्वर इन्फ़्रास्ट्रक्चर धीमा है (या तो इसलिए कि वह कम क्षमता वाला है या कोड को ऑप्टिमाइज़ करने की ज़रूरत है), तो 103 Early Hints का इस्तेमाल करने पर यह कम साफ़ तौर पर दिख सकता है. ऐसा इसलिए, क्योंकि टीटीएफ़बी तेज़ दिखता है. 103 Early Hints का इस्तेमाल करने वाली साइटों को सर्वर के असल समय को मेज़र करना चाहिए. इसके लिए, PerformanceNavigationTiming API के Server-Timing या finalResponseHeadersStart का इस्तेमाल किया जा सकता है.
नतीजा
बैकएंड ऐप्लिकेशन स्टैक के कई कॉम्बिनेशन होते हैं. इसलिए, ऐसा कोई लेख नहीं है जिसमें वेबसाइट के टीटीएफ़बी को कम करने के लिए, हर तरीका बताया गया हो. हालांकि, सर्वर साइड पर चीज़ों को थोड़ा तेज़ी से प्रोसेस करने के लिए, ये विकल्प आज़माए जा सकते हैं.
हर मेट्रिक को ऑप्टिमाइज़ करने का तरीका काफ़ी हद तक एक जैसा होता है: फ़ील्ड में अपने टीटीएफ़बी को मेज़र करें, लैब टूल का इस्तेमाल करके वजहों के बारे में ज़्यादा जानें, और फिर जहां भी संभव हो वहां ऑप्टिमाइज़ेशन लागू करें. ऐसा हो सकता है कि कुछ तरीके आपके लिए काम न करें, लेकिन कुछ तरीके काम कर सकते हैं. हमेशा की तरह, आपको अपने फ़ील्ड डेटा पर नज़र रखनी होगी. साथ ही, उपयोगकर्ताओं को सबसे तेज़ अनुभव देने के लिए, ज़रूरत के मुताबिक बदलाव करने होंगे.