पहली बाइट के लिए समय ऑप्टिमाइज़ करें

टाइम टू फ़र्स्ट बाइट मेट्रिक के लिए ऑप्टिमाइज़ करने का तरीका जानें.

Barry Pollard

Jeremy Wagner

पब्लिश किया गया: 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 काम करता है. एचटीटीपी/3, यूडीपी प्रोटोकॉल का इस्तेमाल करके ऐसा करता है.
• CDN, TLS के नए वर्शन उपलब्ध कराता है. इससे TLS नेगोशिएशन में लगने वाला समय कम हो जाता है. खास तौर पर, TLS 1.3 को इस तरह से डिज़ाइन किया गया है कि टीएलएस नेगोशिएशन को जितना हो सके उतना छोटा रखा जाए.
• सीडीएन की सुविधा देने वाली कुछ कंपनियां, "एज वर्कर" नाम की सुविधा देती हैं. यह सुविधा, Service Worker API के जैसे ही एपीआई का इस्तेमाल करती है. इससे अनुरोधों को इंटरसेप्ट किया जा सकता है, एज कैश मेमोरी में मौजूद जवाबों को प्रोग्राम के हिसाब से मैनेज किया जा सकता है या जवाबों को पूरी तरह से बदला जा सकता है.
• CDN की सेवाएं देने वाली कंपनियां, कॉन्टेंट को कंप्रेस करने के लिए ऑप्टिमाइज़ करने में बहुत अच्छी होती हैं. कंप्रेशन को खुद से सही तरीके से लागू करना मुश्किल है. साथ ही, डाइनैमिक तरीके से जनरेट किए गए मार्कअप के कुछ मामलों में, इससे जवाब मिलने में ज़्यादा समय लग सकता है. इस मार्कअप को तुरंत कंप्रेस किया जाना चाहिए.
• इसके अलावा, सीडीएन सेवा देने वाली कंपनियां, स्टैटिक रिसॉर्स के लिए कंप्रेस किए गए जवाबों को अपने-आप कैश मेमोरी में सेव कर लेती हैं. इससे कंप्रेस करने के अनुपात और जवाब देने में लगने वाले समय का सबसे सही कॉम्बिनेशन मिलता है.

सीडीएन को अपनाने में, कम से लेकर ज़्यादा तक मेहनत करनी पड़ सकती है. हालांकि, अगर आपकी वेबसाइट पहले से इसका इस्तेमाल नहीं कर रही है, तो टीटीएफ़बी को ऑप्टिमाइज़ करने के लिए, इसे प्राथमिकता दी जानी चाहिए.

जहां भी हो सके, कैश मेमोरी में सेव किए गए कॉन्टेंट का इस्तेमाल करें

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

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

अगर कैश मेमोरी को सही तरीके से कॉन्फ़िगर किया गया है, तो भी Analytics मेज़रमेंट के लिए यूनीक क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके इसे अनदेखा किया जा सकता है. एक ही कॉन्टेंट होने के बावजूद, सीडीएन को यह अलग-अलग कॉन्टेंट लग सकता है. इसलिए, कैश किए गए वर्शन का इस्तेमाल नहीं किया जाएगा.

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

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

एक से ज़्यादा पेज पर रीडायरेक्ट करने से बचें

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

रीडायरेक्ट दो तरह के होते हैं:

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

एक ही ऑरिजिन से रीडायरेक्ट होने वाले यूआरएल को हटाने पर फ़ोकस करें. ऐसा इसलिए, क्योंकि इस पर आपका सीधा कंट्रोल होता है. इसके लिए, आपको अपनी वेबसाइट पर मौजूद लिंक की जांच करनी होगी. इससे यह पता चलेगा कि किसी लिंक पर क्लिक करने से 302 या 301 रिस्पॉन्स कोड मिलता है या नहीं. ऐसा अक्सर इसलिए होता है, क्योंकि https:// स्कीम को शामिल नहीं किया जाता. इसलिए, ब्राउज़र डिफ़ॉल्ट रूप से http:// का इस्तेमाल करते हैं, जो रीडायरेक्ट करता है. इसके अलावा, ऐसा इसलिए भी हो सकता है, क्योंकि यूआरएल में स्लैश को सही तरीके से शामिल या हटाया नहीं गया है.

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

रीडायरेक्ट में लगने वाले समय का एक और अहम सोर्स, एचटीटीपी से एचटीटीपीएस पर रीडायरेक्ट करने की प्रोसेस हो सकती है. इस समस्या को हल करने के लिए, Strict-Transport-Security हेडर (एचएसटीएस) का इस्तेमाल किया जा सकता है. यह हेडर, किसी ऑरिजिन पर पहली बार जाने पर एचटीटीपीएस को लागू करता है. इसके बाद, यह ब्राउज़र को बताता है कि आने वाले समय में, एचटीटीपीएस स्कीम के ज़रिए ऑरिजिन को तुरंत ऐक्सेस किया जाए.

एचएसटीएस की अच्छी नीति लागू करने के बाद, अपनी साइट को एचएसटीएस प्रीलोड सूची में जोड़कर, किसी ऑरिजिन पर पहली बार विज़िट करने वाले लोगों के लिए साइट को तेज़ी से लोड किया जा सकता है.

ब्राउज़र पर स्ट्रीम मार्कअप करना

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

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

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

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

सर्विस वर्कर का इस्तेमाल करना

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

• ऐसेट के लिए, 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 का इस्तेमाल करने वाली साइटों को, सर्वर के असल समय को मेज़र करना चाहिए. हालांकि, Server-Timing या finalResponseHeadersStart PerformanceNavigationTiming API का इस्तेमाल करके ऐसा किया जा सकता है.

नतीजा

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

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