आपका Time to First Byte धीमा क्यों है और इसके लिए क्या करें

पहले समझें कि TTFB वास्तव में क्या मापता है

Time to First Byte, जिसे आमतौर पर TTFB कहा जाता है, browser द्वारा किसी resource का अनुरोध करने और response का पहला byte प्राप्त करने के बीच का समय है।

यह server metric जैसा लगता है, लेकिन यह केवल server metric नहीं है। TTFB में कई चरण शामिल होते हैं:

• DNS lookup, यदि hostname पहले से resolved नहीं है
• TCP connection setup
• HTTPS के लिए TLS negotiation
• Server या CDN edge तक request travel time
• Server पर queueing और processing
• Browser तक response travel time वापस आना

इसलिए high TTFB का मतलब यह हो सकता है कि आपका backend धीमा है। इसका मतलब यह भी हो सकता है कि user आपके origin से दूर है, आपका CDN misconfigured है, आपका cache लगातार miss कर रहा है, या आपका server यह तय करने में बहुत समय लगा रहा है कि क्या भेजना है।

यह इसलिए मायने रखता है क्योंकि TTFB loading chain की शुरुआत के पास बैठता है। यदि HTML document देर से आता है, तो browser CSS, JavaScript, fonts, और images भी देर से discover करता है। आपके पास बेहतरीन front-end optimization हो सकती है, फिर भी site धीमी महसूस हो सकती है यदि पहले document response में 1.5 seconds लगते हैं।

धीमा TTFB किसे माना जाए?

ऐसा कोई universal number नहीं है जो हर site, region, और architecture पर fit हो। फिर भी, practical thresholds मदद करते हैं।

Google की web.dev guidance 800 ms से कम TTFB को अच्छा मानती है, 800–1800 ms को improvement की जरूरत वाली range, और 1800 ms से ऊपर को poor मानती है। User के पास serve किए जा रहे well-cached marketing page के लिए आप अक्सर इससे काफी बेहतर कर सकते हैं। Dynamic work करने वाले complex authenticated dashboard के लिए acceptable number ज्यादा हो सकता है, लेकिन वह फिर भी explainable होना चाहिए।

महत्वपूर्ण आदत number को segment करना है। 900 ms का global average TTFB आपके CDN edge के पास users के लिए 150 ms response और किसी दूसरे region के users के लिए 2200 ms response को छिपा सकता है। इसी तरह, आपकी homepage ठीक हो सकती है जबकि search, category, या logged-in pages चुपचाप तकलीफदेह हों।

इसे एक से अधिक जगहों से मापें

एक single Lighthouse run से TTFB diagnose न करें। Lighthouse उपयोगी है, लेकिन यह एक environment से एक test है। यदि आप इसे interpret करना नए हैं, तो घबराए बिना Lighthouse report पढ़ने का शांत तरीका समझकर शुरू करें — मुख्य सीख lab signals को field reality से अलग करना है।

TTFB के लिए, आपको कम से कम तीन views चाहिए:

1. Browser developer tools

Network panel खोलें, cache disabled रखकर reload करें, और main document request inspect करें। Timing breakdown DNS, connection, TLS, waiting, और download phases दिखाता है। “waiting” phase अक्सर वही होता है जिसे लोग backend time कहते हैं, हालांकि इसमें upstream latency भी शामिल हो सकती है।

2. Multiple regions से synthetic tests

अपने users के पास और उनसे दूर locations से tests run करें। यदि TTFB एक region में low और दूसरे में high है, तो application code rewrite करने से पहले geography, CDN routing, origin placement, या cache coverage पर शक करें।

3. Real user monitoring या server logs

Field data आपको बताता है कि real users devices, networks, और sessions में क्या अनुभव करते हैं। Server logs बता सकते हैं कि origin ने response जल्दी generate किया या नहीं। Client-observed TTFB और origin processing time के बीच का अंतर अक्सर वह जगह है जहाँ CDN और network issues दिखाई देते हैं।

धीमे TTFB के सामान्य कारण

आपका HTML cache नहीं हो रहा है

Content sites और ecommerce sites पर यह सबसे common issue है। Static assets aggressively cached होते हैं, लेकिन HTML document — जिसकी browser को सबसे पहले जरूरत होती है — हर request पर generate होता है।

कभी-कभी यह जरूरी होता है। अक्सर नहीं होता।

यदि कोई public page दिन में कुछ ही बार बदलता है, तो उसे शायद हर anonymous visitor के लिए fresh database render की जरूरत नहीं होनी चाहिए। जहाँ appropriate हो, full-page caching, edge caching, static generation, या stale-while-revalidate patterns का उपयोग करें।

Cache-Control, CDN-Cache-Status, Age, Vary, और Set-Cookie जैसे signals के लिए response headers check करें। हर visitor को unique cookie भेजने वाला page गलती से खुद को uncacheable बना सकता है। यदि आपको इस layer के बारे में practical तरीके से सोचना है, तो production में redirects और HTTP headers debug करने की हमारी guide में वही debugging habits TTFB work पर सीधे लागू होती हैं।

आपका CDN केवल assets cache कर रहा है

कई teams CDN जोड़ती हैं और मान लेती हैं कि performance का काम पूरा हो गया। लेकिन यदि CDN केवल images, CSS, और JavaScript serve करता है, तो पहला HTML request अभी भी single origin server तक पूरा सफर कर सकता है।

Local users वाली local business site के लिए यह ठीक हो सकता है। International audience के लिए यह ठीक नहीं है। User origin से जितना दूर होगा, backend work शुरू होने से पहले ही आप उतनी अधिक latency pay करेंगे।

TTFB के लिए अच्छा CDN configuration आमतौर पर इसका मतलब है:

• जहाँ safe हो, public HTML cache करें
• Authenticated या personalized pages के लिए intentional bypass rules का सम्मान करें
• ऐसे unnecessary Vary headers से बचें जो cache को बहुत बारीक हिस्सों में बाँट देते हैं
• Cache पूरी तरह disable करने के बजाय cache purging या revalidation का उपयोग करें
• Confirm करें कि edge locations सच में hits serve कर रही हैं, हर request forward नहीं कर रहीं

CDN कोई जादू नहीं है। यह cache और routing layer है। इसे उसी तरह treat करें।

आपका server response देने से पहले बहुत ज्यादा काम कर रहा है

Slow backend path कई छोटी delays से आ सकता है: database queries, API calls, template rendering, feature flag checks, authentication, personalization, logging, और cold starts।

सबसे खराब pattern serial dependency work है। उदाहरण के लिए:

1. Page data fetch करें
2. फिर related products fetch करें
3. फिर pricing fetch करें
4. फिर recommendations service call करें
5. फिर HTML render करें

यदि हर step previous step का इंतजार करता है, तो TTFB जल्दी बढ़ता है। Independent work को parallelize करें, non-critical calls को first response से हटाएँ, और expensive results cache करें।

एक उपयोगी rule: यदि user result को तुरंत देख या use नहीं कर सकता, तो शायद उसे first byte block नहीं करना चाहिए।

Database queries धीमी या unpredictable हैं

Databases अक्सर TTFB problems पैदा करते हैं क्योंकि वे development में ठीक behave करते हैं और real traffic में खराब। Missing indexes, large joins, N+1 queries, lock contention, और oversized result sets सभी “server धीमा है” के रूप में दिखते हैं।

यहाँ guess न करें। Slow requests के लिए query timings capture करें। केवल averages नहीं, p95 और p99 देखें। एक page जो आमतौर पर 120 ms में respond करता है लेकिन कभी-कभी 4 seconds के लिए block हो जाता है, फिर भी खराब user experience बनाएगा।

Common fixes में शामिल हैं:

• Indexes जोड़ना या correct करना
• N+1 query patterns हटाना
• Read-heavy data cache करना
• Large queries paginate करना
• Reporting या analytics queries को request time से दूर ले जाना
• Downstream calls के लिए sensible timeouts set करना

आपकी application में cold starts हैं

Serverless और containerized platforms बेहतरीन हो सकते हैं, लेकिन जब traffic bursty हो या regions under-provisioned हों, तो cold starts TTFB को नुकसान पहुँचा सकते हैं।

यदि idle time के बाद आपकी पहली request बाद की requests से बहुत धीमी है, तो cold starts investigate करें। आपको provisioned concurrency, smaller bundles, fewer startup dependencies, warmer functions, या latency-sensitive routes के लिए अलग deployment shape की जरूरत हो सकती है।

यह serverless के खिलाफ argument नहीं है। यह इस दिखावे के खिलाफ argument है कि runtime model invisible है।

Redirects पहला request waste कर रहे हैं

Redirect browser को final document मिलने से पहले एक और request-response cycle जोड़ देता है। पुराने links के लिए http:// से https:// तक एक redirect unavoidable हो सकता है, लेकिन chains wasteful हैं।

Common chains में शामिल हैं:

• http://example.com → https://example.com → https://www.example.com
• Protocol normalization के बाद trailing slash normalization
• Cache lookup से पहले geo या language redirects
• Legacy campaign links जो कई URLs से होकर गुजरते हैं

जहाँ संभव हो source links fix करें, redirect rules collapse करें, और canonical URLs direct बनाएँ। Redirect time हमेशा final request के TTFB के रूप में report नहीं होता, लेकिन user फिर भी उसका समय pay करता है।

एक practical debugging sequence

जब TTFB धीमा दिखे, तो इस order का उपयोग करें। यह cache और routing behavior confirm करने से पहले application code optimize करने की common mistake से बचाता है।

Step 1: पूरे page नहीं, main document test करें

HTML document के लिए request ढूँढें। Total TTFB और timing breakdown record करें। Browser cache के साथ और बिना दोहराएँ। Relevant हो तो public page, dynamic page, और logged-in page test करें।

Step 2: Regions compare करें

Same URL को कई geographic locations से run करें। यदि slow regions origin से distance के साथ correlate करते हैं, तो CDN और edge caching को prioritize करें। यदि हर region slow है, तो backend processing और origin capacity देखें।

Step 3: Response headers inspect करें

Cache headers, cookies, Age, CDN status, और Vary देखें। Missing Age header या repeated cache misses clues हैं। Public HTML पर broad Vary: Cookie header अक्सर cache killer होता है।

Step 4: Origin timing check करें

Server timing instrumentation जोड़ें। Server-Timing header database time, render time, और upstream API time जैसे backend phases expose कर सकता है। Simple labels भी उपयोगी हैं:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

अब आपके browser timings दिखा सकते हैं कि server ने real work पर 300 ms खर्च किए या delay आपके application तक request पहुँचने से पहले हुई।

Step 5: सबसे बड़ी confirmed delay fix करें

यह obvious लगता है, लेकिन teams अक्सर measured चीज के बजाय familiar चीज fix करती हैं। यदि cache misses dominate करते हैं, caching fix करें। यदि database dominate करता है, queries fix करें। यदि global users के लिए TLS और connection setup dominate करते हैं, routing, CDN coverage, या origin geography fix करें।

Front-end work फिर भी मायने रखता है। Fonts, images, और JavaScript HTML आने के बाद क्या होता है, उसे affect करते हैं। लेकिन वे fast first response का substitute नहीं हैं। यदि आप render performance पर भी काम कर रहे हैं, तो web fonts अभी भी कई sites पर सबसे आसान performance wins में से एक हैं क्योंकि वे document आने के बाद text कितनी जल्दी usable होता है, उसे affect करते हैं।

ऐसे fixes जो आमतौर पर काम करते हैं

Public HTML को edge पर cache करें

Marketing pages, documentation, blogs, landing pages, और category pages के लिए edge caching अक्सर सबसे बड़ा TTFB improvement होता है। यदि content अक्सर बदलता है, तो short TTLs उपयोग करें। यदि cache background में refresh होते समय थोड़ा stale content acceptable है, तो stale-while-revalidate उपयोग करें।

Personalization के साथ सावधान रहें। यदि page currency, language, login state, या experiment group के अनुसार vary करता है, तो उन variants को explicitly define करें। Accidental per-user variation cache efficiency को नष्ट कर देता है।

Non-critical work को request path से बाहर ले जाएँ

Email sending, analytics enrichment, recommendation generation, webhook calls, और heavy logging को शायद ही कभी first byte block करना चाहिए। उन्हें queues में डालें या response शुरू होने के बाद run करें।

Backend dependency chains कम करें

Independent calls parallelize करें। Slow APIs से responses cache करें। Timeouts set करें। उन services के लिए fallback content design करें जो helpful हैं लेकिन essential नहीं।

Slow recommendations widget को पूरी product page delay नहीं करनी चाहिए।

Compute को users के करीब रखें

यदि आपके users global हैं और आपका origin एक region में है, तो latency structural है। CDN caching public content के लिए इसका बड़ा हिस्सा छिपा सकती है। Dynamic content के लिए regional deployments, suitable routes के लिए edge rendering, या APIs को audience के करीब ले जाने पर विचार करें।

Redirects को boring रखें

URLs को एक hop में canonicalize करें। Internal links update करें ताकि users और crawlers सीधे final destination पर जाएँ। पुराने campaign URLs और platform migrations audit करें। Redirects को ignore करना आसान है क्योंकि वे काम करते समय invisible होते हैं, लेकिन वे फिर भी time cost करते हैं।

क्या न करें

हर route के लिए perfect TTFB number के पीछे न भागें। Real computation करने वाली authenticated report cached blog post की तरह behave नहीं करेगी।

Average TTFB को अपना only metric न बनाएँ। Percentiles मायने रखते हैं। Geography मायने रखती है। Page type मायने रखता है।

यह assume न करें कि CDN का मतलब आपका HTML cached है। इसे verify करें।

और TTFB को product decisions से अलग न treat करें। Personalization, experimentation, real-time inventory, और third-party services सभी की latency costs होती हैं। कुछ worth it हैं। कुछ सिर्फ habit हैं।

<!-- tool-cta:start -->

💡 इसे आज़माएँ: TTFB का निदान करते समय, Get Headers कैश स्थिति, सर्वर टाइमिंग और रीडायरेक्ट दिखाता है, जो अक्सर बताते हैं कि देरी कहाँ से आ रही है।

<!-- tool-cta:end -->

Plan का calm version

Slow TTFB आमतौर पर fixable होता है, जब आप इसे vague “server problem” की तरह treat करना बंद कर देते हैं। Document request measure करें। Region और page type के अनुसार segment करें। Headers inspect करें। Client timing की origin timing से तुलना करें। फिर सबसे बड़ा confirmed bottleneck fix करें।

अधिकतर sites को exotic architecture की जरूरत नहीं होती। उन्हें कम avoidable cache misses, कम blocking backend work, cleaner redirects, और इस बात की clearer idea चाहिए कि first byte भेजे जाने से पहले क्या होना जरूरी है।