इस पेज का अनुवाद Cloud Translation API से किया गया है.

पहली बाइट का समय (TTFB)

Jeremy Wagner

Barry Pollard

ब्राउज़र सहायता

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

टीटीएफ़बी क्या है?

TTFB एक मेट्रिक है, जो किसी रिसॉर्स के अनुरोध और जवाब का पहला बाइट मिलने के बीच के समय को मेज़र करती है.

नेटवर्क अनुरोध के समय का विज़ुअलाइज़ेशन. बाईं से दाईं ओर के समय में रीडायरेक्ट, सर्विस वर्कर इनिट, सर्विस वर्कर फे़च इवेंट, एचटीटीपी कैश, डीएनएस, टीसीपी, अनुरोध, शुरुआती हिंट (103), रिस्पॉन्स (जो अनलोड के लिए प्रॉम्प्ट को ओवरलैप करता है), प्रोसेस, और लोड शामिल हैं. इनसे जुड़ी समयावधि ये हैं: redirectStart और redirectEnd, fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart, और loadEventEnd. — नेटवर्क अनुरोध के चरणों और उनसे जुड़ी समयावधि का डायग्राम. TTFB, `startTime` और `responseStart` के बीच बीता समय मेज़र करता है.

टीटीएफ़बी में, अनुरोध के इन चरणों का कुल योग होता है:

रीडायरेक्ट होने का समय
अगर लागू हो, तो सेवा वर्कर के शुरू होने का समय
DNS लुकअप
कनेक्शन और TLS बातचीत
अनुरोध, जब तक जवाब का पहला बाइट नहीं मिल जाता

कनेक्शन सेटअप करने में लगने वाले समय और बैकएंड पर लगने वाले इंतज़ार के समय को कम करने से, आपका TTFB कम हो सकता है.

TTFB की अन्य परिभाषाएं

पिछली परिभाषा, सामान्य परिभाषा है. हालांकि, रिपोर्ट के जल्दी मिलने की सुविधा के आने के बाद, "पहला बाइट" क्या है, इस पर बहस हो सकती है. firstInterimResponseStart, responseStart में समय की एक नई एंट्री है, ताकि इन दोनों के बीच अंतर किया जा सके. हालांकि, यह सिर्फ़ Chrome और Chromium पर आधारित ब्राउज़र में काम करती है. इसलिए, कुछ ब्राउज़र और टूल (इनमें CrUX भी शामिल है), शुरुआती हिंट के साथ-साथ पहले बाइट मिलने तक मेज़र करते हैं.

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

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

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

एक अच्छा TTFB स्कोर क्या है?

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

टीटीएफ़बी की अच्छी वैल्यू 0.8 सेकंड या उससे कम हैं, खराब वैल्यू 1.8 सेकंड से ज़्यादा हैं, और इन दोनों में सुधार की ज़रूरत है — TTFB की अच्छी वैल्यू 0.8 सेकंड या उससे कम होती हैं. वहीं, खराब वैल्यू 1.8 सेकंड से ज़्यादा होती हैं.

अहम जानकारी: TTFB, Core Web Vitals मेट्रिक नहीं है. इसलिए, यह ज़रूरी नहीं है कि साइटें "अच्छा" TTFB थ्रेशोल्ड को पूरा करें. हालांकि, यह ज़रूरी है कि इससे साइटों की उन मेट्रिक में अच्छा स्कोर करने की क्षमता पर असर न पड़े जो अहम हैं.

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

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

टीटीएफ़बी मेज़र करने का तरीका

TTFB को लैब या फ़ील्ड में इन तरीकों से मेज़र किया जा सकता है.

फ़ील्ड टूल

लैब टूल

Chrome के DevTools के नेटवर्क पैनल में
WebPageTest

JavaScript में TTFB मेज़र करना

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

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

web-vitals JavaScript लाइब्रेरी, ब्राउज़र में TTFB को ज़्यादा आसानी से मेज़र कर सकती है:

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

संसाधन के अनुरोधों को मेज़र करना

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

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

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

टीटीएफ़बी को बेहतर बनाने का तरीका

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