time to first byte (TTFB): अच्छी वैल्यू और उसे कैसे घटाएँ

time to first byte (TTFB) वह समय है जो navigation शुरू होने से HTML response का पहला byte आने तक लगता है। web.dev 0.8 सेकंड या उससे कम को अच्छा और 1.8 सेकंड से ऊपर को खराब कहता है, जो असली visits के 75वें percentile पर नापा जाता है (web.dev, आखिरी अपडेट नवंबर 2025)। TTFB कोई Core Web Vital नहीं है, पर आगे के हर metric, जिसमें First Contentful Paint और Largest Contentful Paint शामिल हैं, उसके बाद शुरू होते हैं। फ़ोन पर redirects, DNS, TLS और धीमा server भी यहीं जुड़ते हैं, क्योंकि इनमें से हर कदम को मोबाइल नेटवर्क पर कम से कम एक बार जाना पड़ता है।

time to first byte क्या है

TTFB उन सब कदमों का योग है जो document के पहले byte के आने से पहले लगते हैं, जिनमें redirects, DNS और TLS शामिल हैं। web.dev के अनुसार इसमें ये चीज़ें आती हैं:

• redirect का समय;
• service worker की शुरुआत का समय, अगर साइट में service worker है;
• DNS lookup;
• connection और TLS negotiation;
• request खुद, response के पहले byte तक।

इसीलिए तेज़ server होने पर भी TTFB धीमा दिख सकता है। http://example.com से शुरू होकर https://example.com पर redirect होने और फिर https://www.example.com पर जाने वाली visit ने अंतिम पेज के server के कुछ करने से पहले दो redirects और तीन connections की कीमत चुका दी है।

TTFB पुरानी Lighthouse रिपोर्ट के “server response time” जैसा भी नहीं है। वह audit केवल main document के इंतज़ार को नापता था और DNS lookups और redirects को बाहर रखता था, इसलिए वह TTFB का केवल एक हिस्सा है (Chrome for Developers)।

अच्छा TTFB कितना है

अच्छा TTFB 0.8 सेकंड या उससे कम है, और web.dev अपनी सीमाओं को “मोटा मार्गदर्शन” कहता है, अनिवार्य नियम नहीं। नवंबर 2025 तक की सीमाएँ और सख्त Lighthouse आँकड़ा यहाँ हैं:

दोनों संख्याएँ अलग चीज़ें नापती हैं। Lighthouse का 600 ms केवल server के अपने जवाब का समय है, जबकि 0.8 सेकंड का मार्गदर्शन पूरे TTFB को देखता है, इसलिए एक ही पेज एक में पास और दूसरे में फ़ेल हो सकता है। दोनों Google द्वारा तय design thresholds हैं।

फ़ोन पर अच्छा स्कोर कितना आम है? HTTP Archive की Web Almanac 2025 में, जुलाई 2025 के डेटा पर, 44% मोबाइल वेबसाइटों का TTFB अच्छा था, जबकि desktop पर 55%। मोबाइल पर 40% को सुधार की ज़रूरत थी और 17% खराब थे (Web Almanac 2025, Performance)।

फ़ोन पर TTFB ज़्यादा क्यों होता है

फ़ोन पर TTFB ज़्यादा होता है, क्योंकि first byte से पहले हर कदम एक round trip है, और मोबाइल connection पर एक round trip वायर्ड connection से ज़्यादा समय लेता है। ठंडे connection पर HTTPS से पहली बार visit का क्रम यह है:

1. DNS lookup, server का पता पाने के लिए।
2. TCP handshake: server तक एक round trip।
3. TLS handshake: TLS 1.3 में एक और round trip, जिसे RFC 8446 “1-RTT handshake” कहता है।
4. HTTP request और response का पहला byte: एक round trip, साथ में server को response तैयार करने का समय।

इस तरह अकेला network आपके server तक तीन round trips और DNS lookup लेता है, server के अपने काम से पहले। नीचे की तालिका दो round-trip times (RTT) पर सिर्फ़ गणना है, जो उदाहरण के लिए चुने गए हैं, किसी network का माप नहीं:

ऊँचे RTT पर, 400 ms में जवाब देने वाला server भी DNS जोड़ने पर 0.8 सेकंड के मार्गदर्शन को तोड़ देता है। server ने कुछ गलत नहीं किया; connection setup ने आधे से ज़्यादा बजट ले लिया।

इस ऊपरी खर्च को घटाने वाली दो बातें हैं। connection दोबारा इस्तेमाल करें: लौटने वाला visitor जो अब भी जुड़ा है, चरण 1 से 3 छोड़ देता है। नए protocol का इस्तेमाल करें: HTTP/3 QUIC पर चलता है, जिसका handshake “cryptographic और transport parameters के negotiation को मिला देता है” (RFC 9000, मई 2021), इसलिए TCP फिर TLS की तुलना में setup को कम round trips चाहिए। web.dev बताता है कि CDNs HTTP/2 या HTTP/3 जैसे आधुनिक protocols से content देते हैं (web.dev)।

एक और मोबाइल-विशिष्ट कारण: अलग मोबाइल साइट। redirects पर Lighthouse की अपनी सलाह है कि मोबाइल उपयोगकर्ताओं के लिए मोबाइल पेज पर भेजने के बजाय responsive design पर विचार करें (Chrome for Developers)। responsive तरीका वेबसाइट को मोबाइल-फ़्रेंडली कैसे बनाएँ में है।

TTFB कैसे नापें

दो बार नापें: एक बार lab में, यह देखने के लिए कि समय कहाँ जा रहा है; और एक बार field में, यह देखने के लिए कि असली फ़ोन क्या पाते हैं। दोनों संख्याएँ अलग हो सकती हैं: lab run एक मशीन पर एक बार का load है, जबकि field value असली visits का 75वाँ percentile है।

DevTools में (lab), Network panel खोलें, reload करें, पहली request (document) चुनें और Timing tab खोलें। चरणों के नाम Queueing, Stalled, DNS Lookup, Initial connection, Request sent और Waiting (TTFB) हैं, और “Waiting (TTFB)” एक round trip है plus server का response तैयार करने का समय (Chrome DevTools reference)। अगर Initial connection की पट्टी लंबी है और Waiting छोटी, तो सुधार connection setup में है, application में नहीं।

पेज पर (field), web-vitals library TTFB रिपोर्ट करती है, और उसका attribution build उसे उन्हीं चरणों में बाँटता है। उसके documentation (web-vitals README) में इनके नाम waitingDuration (request से पहले redirects और browser का काम), cacheDuration (cache जाँच, और service worker का समय), dnsDuration, connectionDuration और requestDuration (network समय और server processing) हैं:

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // इसे अपने analytics endpoint पर भेजें; यहाँ हम सिर्फ़ breakdown लॉग कर रहे हैं।
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

device के अनुसार (field, बिना code), Chrome UX Report API formFactor के रूप में PHONE, TABLET या DESKTOP लेता है और experimental_time_to_first_byte का 75वाँ percentile लौटाता है (API में यह एक experimental metric है) (CrUX API docs)। डेटा 28 दिनों का rolling average है। यह जानने का सबसे तेज़ तरीका है कि फ़ोन का TTFB desktop से खराब है या नहीं। speed tests के बड़े सेट को कैसे चलाएँ, यह मोबाइल पेज स्पीड टेस्ट गाइड में है, और Lighthouse वही समस्या कैसे रिपोर्ट करता है, यह Lighthouse मोबाइल audit गाइड में है।

server की तरफ़, यह देखने के लिए कि कौन सा backend चरण धीमा है, Server-Timing header जोड़ें। Chrome 65, Firefox 61 और Safari 16.4 इसे सपोर्ट करते हैं (MDN browser-compat-data 8.1.7, अक्टूबर 2026):

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

ये मान फिर Network panel के Timing tab में और ऊपर दिए attribution object के navigationEntry.serverTiming में दिखते हैं।

TTFB कैसे घटाएँ

अपने breakdown में सबसे बड़े चरण से शुरू करें, क्योंकि हर सुधार केवल अपना चरण हटाता है। यह तालिका बताती है कि आप जो देखते हैं उसके लिए क्या बदलना है:

नीचे दिए सुधार web.dev की TTFB optimization गाइड के अनुसार हैं (web.dev, नवंबर 2025 अपडेट):

1. redirects हटाएँ। web.dev कहता है कि same-origin 301 और 302 redirects हटाएँ, जैसे https:// गायब होना या trailing slash का मेल न होना, और विज्ञापनदाताओं व newsletters को अंतिम URL दें। HSTS browser को सीधे https:// इस्तेमाल करने को कहता है, http:// पर पहले अनुरोध करने के बजाय।
2. आगे CDN लगाएँ। CDN visitor के पास के edge server से जवाब देता है, जिससे ऊपर की तालिका का हर round trip छोटा होता है। web.dev के अनुसार यह आम तौर पर HTTP/3, TLS 1.3 और compression भी देता है।
3. HTML cache करें। जो पेज हर visitor के लिए एक जैसा है, उसे Cache-Control के साथ cache किया जा सकता है और application को छुए बिना परोसा जा सकता है। web.dev बताता है कि छोटे cache समय भी व्यस्त साइटों की मदद करते हैं। जाँच के समय cache को बाईपास करने के लिए URL parameter जोड़ें।
4. server का काम घटाएँ। Lighthouse की सलाह है कि application logic और database queries को सुधारें, ज़रूरत हो तो hardware बढ़ाएँ, और ऐसे documents के लिए CDN इस्तेमाल करें जो edge पर cache हो सकते हैं। सबसे धीमा चरण ढूँढने के लिए पहले Server-Timing देखें।
5. text को compress करें। Lighthouse insight उस main document को चिह्नित करता है जो बिना compression के भेजा गया है। browser Accept-Encoding में बताता है कि वह क्या स्वीकार करता है, और server Content-Encoding में जवाब देता है।
6. HTML को stream करें। web.dev सलाह देता है कि response stream चलता रहे, जहाँ संभव हो streaming server rendering या static rendering के साथ, ताकि पहले byte जल्दी निकलें। early flush को responseStart में भी गिना जाता है, इसलिए TTFB पेज के असल अहसास से बेहतर दिख सकता है; First Contentful Paint भी जाँचें।
7. 103 Early Hints भेजें। अगर server को पेज बनाने में समय चाहिए, तो वह पहले Link headers वाला 103 response भेज सकता है, ताकि browser इंतज़ार के दौरान preconnect या preload शुरू कर दे।

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

Early Hints ज़्यादातर browsers में HTTP/2 या उससे बाद पर काम करता है, और केवल पहला 103 response प्रोसेस होता है (MDN, जून 2026)। समर्थन Chrome 103, Firefox 120 और Safari 17 से है। 103 response TTFB में पहले byte के रूप में गिना जाता है, और Chrome ने बदला है कि responseStart कौन सा timestamp रिपोर्ट करता है (Chrome 115 में अंतिम response, Chrome 133 में फिर पहले byte), इसलिए अलग-अलग tools के TTFB की तुलना सावधानी से करें (web.dev)।

अगर साइट में service worker है, तो उसके cache से shell परोसना लौटने वाले visitors का TTFB भी घटाता है। web.dev कम बदलने वाले assets के लिए stale-while-revalidate और personalised HTML के लिए network-first सुझाता है।

static साइटें और CMS साइटें

static साइट के पास पहले से सबसे अच्छी स्थिति है: HTML request से पहले मौजूद है, इसलिए TTFB मुख्य रूप से connection setup है, और मुख्य सुधार CDN है। CMS request आने पर पेज बनाता है, इसलिए सबसे बड़ा लाभ पूरे पेज का cache है। WordPress के लिए Lighthouse documentation हल्का theme, पूरे पेज का cache और कम plugins सुझाता है; Drupal के लिए page cache, PHP OPcache और Redis या Memcached; Magento के लिए Varnish (Chrome for Developers, आखिरी बार 2019 में अपडेट, Lighthouse 13 से पहले)।

अलग AMP URL भी पेज की एक और प्रति जोड़ता है, जिसे canonical से मेल खाते रखना होता है; वह अब भी ज़रूरी है या नहीं, यह AMP 2026 में में है।

फ़ोन-आकार के पेज पर redirect chain जाँचें

redirects वह TTFB कारण है जो बिना stopwatch के भी दिख जाता है: फ़ोन को desktop से अलग जगह भेजा जा सकता है। Mobile View Extension tab को फ़ोन के user agent, screen size और pixel ratio के साथ दोबारा लोड करता है, इसलिए आप जाँच सकते हैं कि आप किस URL पर पहुँचते हैं, और mobile page असली mobile version के साथ लोड होता है या नहीं। यह TTFB या किसी speed metric को नहीं नापता, और आपके desktop network और hardware पर चलता है, इसलिए असली फ़ोन पर समय के लिए ऊपर के field tools इस्तेमाल करें।

अक्सर पूछे जाने वाले सवाल

अच्छा TTFB क्या है?

web.dev (नवंबर 2025) के अनुसार 75वें percentile पर 0.8 सेकंड या उससे कम अच्छा है, और 1.8 सेकंड से ऊपर खराब। ये मोटे मार्गदर्शन हैं, और TTFB Core Web Vitals का हिस्सा नहीं है।

क्या TTFB एक Core Web Vital है?

नहीं। Core Web Vitals हैं Largest Contentful Paint, Interaction to Next Paint और Cumulative Layout Shift, और web.dev साफ़ कहता है कि TTFB इनमें नहीं है। फिर भी यह मायने रखता है, क्योंकि ऊँचा TTFB First Contentful Paint और Largest Contentful Paint को देर से करता है।

मेरा TTFB Lighthouse और field data में अलग क्यों है?

Lighthouse throttling के साथ एक मशीन पर एक load चलाता है, जबकि field data असली networks और caches पर असली visits को कवर करता है। field value पर भरोसा करें, और lab run का इस्तेमाल यह ढूँढने के लिए करें कि कौन सा चरण धीमा है।

क्या TTFB SEO को प्रभावित करता है?

web.dev कहता है कि TTFB Core Web Vital नहीं है, पर यह First Contentful Paint से पहले आता है, इसलिए धीमा TTFB उसके बाद के metrics को देर से करता है, मुख्य रूप से Largest Contentful Paint को। पहले वे metrics सुधारें, और TTFB से पता करें कि वे धीमे क्यों हैं।