टीटीएफ़बी क्या है?
TTFB एक ऐसी मेट्रिक है जो किसी संसाधन के अनुरोध और जवाब के पहले बाइट के आने के बीच के समय को मापती है.
startTime और responseStart के बीच बीते समय को मापता है.
टीटीएफ़बी में, अनुरोध के इन चरणों का कुल योग होता है:
- रीडायरेक्ट होने का समय
- सर्विस वर्कर के शुरू होने में लगने वाला समय (अगर लागू हो)
- DNS लुकअप
- कनेक्शन और TLS नेगोशिएशन
- अनुरोध करें, उस बिंदु तक जहां से जवाब का पहला बाइट पहुंच गया हो
कनेक्शन सेटअप करने में लगने वाले समय और बैकएंड पर लगने वाले इंतज़ार के समय को कम करने से, आपका TTFB कम हो सकता है.
TTFB की अन्य परिभाषाएं
पिछली परिभाषा सामान्य परिभाषा है, लेकिन शुरुआती हिंट से शुरुआत की गई है जिसे "फ़र्स्ट बाइट" माना जाता है बहस के लिए तैयार है. firstInterimResponseStart, इनके बीच अंतर करने के लिए responseStart की अतिरिक्त समय की एंट्री है. हालांकि, यह सिर्फ़ Chrome और Chromium पर काम करने वाले ब्राउज़र में काम करता है. इसलिए, कुछ ब्राउज़र और टूल (CrUX के साथ) तब तक डेटा मेज़र करते हैं, जब तक कि 'शुरुआती हिंट' के साथ-साथ पहली बाइट नहीं मिल जाती.
'शुरुआती हिंट' सुविधा, शुरुआत में ही जवाब देने का एक नया उदाहरण है. कुछ सर्वर, मुख्य हिस्सा उपलब्ध होने से पहले ही दस्तावेज़ के रिस्पॉन्स को फ़्लश करने की अनुमति देते हैं. ऐसा सिर्फ़ एचटीटीपी हेडर या <head> एलिमेंट के साथ हो सकता है. इन दोनों एलिमेंट को शुरुआती हिंट की तरह माना जा सकता है और टीटीएफ़बी के आकलन की परिभाषा को भी तय किया जा सकता है.
इसकी माप के तौर पर, "फ़र्स्ट बाइट" कार्रवाई करने लायक डेटा ब्राउज़र को मिल जाता है, तो इन सभी परिभाषाओं को सही माना जा सकता है. अगर पूरे जवाब में थोड़ा समय लगेगा, तो डेटा को जल्दी वापस भेजने का कोई फ़ायदा है. सबसे ज़्यादा ज़रूरी यह समझना है कि जिस टूल का इस्तेमाल किया जा रहा है वह मेज़र करने के लिए किस तरह का तरीका इस्तेमाल कर रहा है. साथ ही, यह भी समझना ज़रूरी है कि मेज़र किए जा रहे प्लैटफ़ॉर्म का इस पर क्या असर पड़ता है. इस वजह से, अलग-अलग प्लैटफ़ॉर्म या टेक्नोलॉजी के बीच इस आधार पर टीटीएफ़बी की तुलना करना मुश्किल हो जाता है कि वे कौनसी सुविधाएं इस्तेमाल करते हैं और इससे टीटीएफ़बी मेज़रमेंट पर क्या असर पड़ता है.
टीटीएफ़बी को अक्सर सर्वर या होस्ट से जवाब मिलने में लगने वाले समय की जानकारी देने वाला इंडिकेटर भी माना जाता है. हालांकि, इस प्रोसेस पर डायरेक्ट कंट्रोल के बाहर की दूसरी वजहों से असर पड़ेगा, जैसे कि रीडायरेक्ट करने का समय. जैसे, कैश मेमोरी के दौरान सीडीएन के हिट होने के दौरान लोड होने वाला पेज या ओरिजनल सर्वर पर वापस जाने के लिए लंबा सफ़र करना. यह खास तौर पर फ़ील्ड डेटा में साफ़ तौर पर दिखता है. आम तौर पर, लैब टेस्टिंग में इन चीज़ों का ज़्यादा असर नहीं पड़ता. इसकी वजह यह है कि आम तौर पर, असली यूआरएल की जांच की जाती है और यह कैश मेमोरी में सेव होने वाले बदलावों को बार-बार अनदेखा कर देता है. लाइटहाउस, टीटीएफ़बी के बजाय सर्वर से जवाब मिलने में लगने वाले समय की रिपोर्ट देता है, ताकि यह साफ़ तौर पर पता चल सके. हालांकि, हो सकता है कि दूसरे लैब टूल ऐसा न कर पाएं.
एक अच्छा TTFB स्कोर क्या है?
टीटीएफ़बी में उपयोगकर्ता पर आधारित मेट्रिक, जैसे कि फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) और सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) जैसी मेट्रिक पहले शामिल होती हैं. इसलिए, हमारा सुझाव है कि आपका सर्वर, नेविगेशन अनुरोधों पर तेज़ी से जवाब दे, ताकि उपयोगकर्ताओं के 75वें पर्सेंटाइल को "अच्छी" स्थिति में एफ़सीपी मिले. थ्रेशोल्ड. मोटे तौर पर, यह ज़रूरी है कि ज़्यादातर साइटों में 0.8 सेकंड या उससे कम का TTFB होना चाहिए.
टीटीएफ़बी को मेज़र करने का तरीका
टीटीएफ़बी को लैब या फ़ील्ड में, इन तरीकों से मापा जा सकता है.
फ़ील्ड टूल
लैब टूल
- Chrome के DevTools के नेटवर्क पैनल में
- WebPageTest
JavaScript में TTFB को मापना
नेविगेशन समय एपीआई की मदद से, ब्राउज़र में नेविगेशन अनुरोधों के टीटीएफ़बी को मेज़र किया जा सकता है. नीचे दिए गए उदाहरण में, एक ऐसा PerformanceObserver बनाने का तरीका बताया गया है जो navigation एंट्री को सुनकर, उसे कंसोल में लॉग करता है:
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);
संसाधन के अनुरोधों को मेज़र करना
टीटीएफ़बी सिर्फ़ नेविगेशन के अनुरोधों पर ही नहीं, बल्कि सभी अनुरोधों पर लागू होता है. खास तौर पर, क्रॉस-ऑरिजिन सर्वर पर होस्ट किए गए रिसॉर्स, इंतज़ार के समय का इस्तेमाल कर सकते हैं. ऐसा इसलिए, क्योंकि इन सर्वर के लिए कनेक्शन सेट अप करने की ज़रूरत पड़ती है. फ़ील्ड में मौजूद संसाधनों के लिए TTFB को मापने के लिए, 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
});
पिछला कोड स्निपेट, नेविगेशन अनुरोध के लिए TTFB को मापने के तरीके जैसा ही है. हालांकि, 'navigation' एंट्री के लिए क्वेरी करने के बजाय, आप 'resource' एंट्री के लिए क्वेरी करते हैं. इसमें यह भी शामिल है कि मुख्य ऑरिजिन से लोड किए गए कुछ रिसॉर्स, 0 की वैल्यू दिखा सकते हैं. ऐसा इसलिए होता है, क्योंकि कनेक्शन पहले से ही चालू होता है या कोई रिसॉर्स, कैश मेमोरी से तुरंत वापस आ जाता है.
टीटीएफ़बी को बेहतर बनाने का तरीका
अपनी साइट के टीटीएफ़बी को बेहतर बनाने के बारे में जानकारी पाने के लिए, टीटीएफ़बी को ऑप्टिमाइज़ करने के लिए हमारी गाइड देखें.