--- title: What Is TTFB? Time to First Byte Explained and How to Cut It description: What Time to First Byte measures, what a good TTFB is, the causes of slow TTFB from DNS to origin, and fixes including CDN caching. image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-04-55-11-4700-AM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜Learn โ–พ](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [โšก Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [๐ŸŽฌVideo & Streaming โ–พ](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿ”ด Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [๐Ÿ“บ VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [๐Ÿ’ฐ Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [๐Ÿญ Other Industries โ–พ](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ“บ Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [๐Ÿ’พ Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [๐Ÿ—๏ธ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [๐Ÿ“š AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [๐ŸŽฎ Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [๐Ÿ“ฑ Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [๐Ÿค– AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [๐Ÿ›๏ธ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [๐Ÿ“š E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [๐ŸŸ๏ธ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs โ–พ](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [โšกCompare โ–พ](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [Ratings & Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ”’ Security โ–พ](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [๐Ÿ“ Case Studies](https://blog.blazingcdn.com/case-studies?hsLang=en-us) [๐Ÿ”Œ Integrations](https://blog.blazingcdn.com/integrations?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [Learn](https://blog.blazingcdn.com/en-us/tag/learn) [Learn - CDN Fundamentals](https://blog.blazingcdn.com/en-us/tag/learn-cdn-fundamentals) # What Is TTFB? Time to First Byte Explained and How to Cut It Vadym Borovskyi Nov 1, 2026, 5:57:43โ€ฏAM ![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-04-55-11-4700-AM.jpeg) Time to first byte (TTFB) is the time from the moment a client starts a request until the first byte of the response arrives. Under the Web Vitals guidance in use in 2026, a page TTFB of 0.8 seconds or less at the 75th percentile counts as good, and anything above 1.8 seconds counts as poor. That is the short answer to what is ttfb. The more useful answer is that TTFB adds up DNS, connection setup, TLS, redirects, proxy queueing and origin work, and each phase needs a different fix. This article covers the phase breakdown, a worked round-trip budget showing where a CDN removes time and where it adds time, threshold values by request type, the tools that report each phase, and the failure modes that make the number misleading. ## **How time to first byte breaks down: DNS, connect, TLS, server** On a cold navigation, TTFB covers six phases in order. Each one maps to a Navigation Timing field, so real-user data can attribute time to a specific phase instead of reporting one opaque number. 1. **Redirects:** redirectStart to redirectEnd. Every hop repeats some or all of the phases below. 2. **Service worker startup:** workerStart. Booting a worker before the fetch can add tens of milliseconds on low-end devices. 3. **DNS lookup:** domainLookupStart to domainLookupEnd. This is near zero when the name is already in the cache and costs a full resolver round trip when it is not. 4. **Connection and TLS:** connectStart to connectEnd. secureConnectionStart marks where the TLS handshake begins. 5. **Request sent:** requestStart. Large cookies can push request headers past one TCP congestion window. 6. **Waiting:** requestStart to responseStart. This includes edge lookup, proxy queueing, origin processing and the return trip of the first byte. TTFB is responseStart measured from navigation start. For prerendered pages it is measured from activationStart, so a prerendered page can report a TTFB near zero. Reused connections skip the DNS, TCP and TLS phases entirely, which is why a single page can show a 400 ms TTFB on the first visit and 60 ms on the next. ### How HTTP/2, HTTP/3 and TLS 1.3 change the handshake count Over TCP, TLS 1.3 needs one round trip for a full handshake, while TLS 1.2 needs two. QUIC, the transport under HTTP/3 (RFC 9114), merges the transport and cryptographic handshakes into one round trip. It also allows 0-RTT resumption for returning clients, with replay risk limited to idempotent requests. Multiplexing in HTTP/2 and HTTP/3 reduces how many new connections a page opens. However, stream scheduling can still hold back an individual response behind higher-priority streams. Under HTTP/2, packet loss stalls every stream on the connection. ## **A worked TTFB budget: origin direct vs. CDN hit vs. CDN miss** The table below is this blog's arithmetic, not a measurement. Assumptions: TLS 1.3 over TCP, 30 ms DNS, 90 ms round trip from user to origin, 15 ms from user to edge, 80 ms from edge to origin, 180 ms of origin application time, and 3 ms of edge processing on a hit. | Path | Arithmetic | TTFB | | --- | --- | --- | | Direct to origin, cold | 30 + 90 (TCP) + 90 (TLS) + 90 (request) + 180 | 480 ms | | CDN miss, cold edge-to-origin connection | 30 + 45 + 160 (origin TCP and TLS) + 80 + 180 + 3 | 498 ms | | CDN miss, warm pooled connection | 30 + 45 (three edge round trips) + 80 + 180 + 3 | 338 ms | | CDN hit, cold client | 30 + 45 + 3 | 78 ms | | CDN hit, reused client connection | 15 + 3 | 18 ms | A cache hit removes 402 ms from the 480 ms direct path, a warm miss still saves 142 ms, and a cold miss is 18 ms slower than going direct. The last point is easy to miss. A CDN only helps uncacheable requests if its edge-to-origin connections stay warm. That is the job of an origin shield and request coalescing: they route misses through one tier, keep its connection pool to the origin busy, and collapse concurrent misses for the same object into a single origin fetch. ## **What is a good TTFB? Thresholds by request type** For HTML documents, the Web Vitals thresholds are 0.8 seconds or less at the 75th percentile for good, 0.8 to 1.8 seconds for needs improvement, and above 1.8 seconds for poor. Lighthouse separately flags a root document whose server response takes longer than 600 ms. A single site-wide number is too coarse for anything other than HTML. | Request type | p75 target (our estimate, in-region) | Why | | --- | --- | --- | | Cached static object, edge hit | under 100 ms | Only network time and edge lookup remain | | Live HLS or DASH manifest | under 200 ms | Players refetch it every target duration, so the cost repeats | | API call on a reused connection | 100 to 300 ms | Dominated by origin work, not by handshakes | | Dynamic or authenticated HTML | 0.8 seconds or less | Web Vitals threshold, cold visits included | Judge TTFB per request class, because a 300 ms figure is healthy for personalized HTML and a warning sign for a cached segment. ## **Where TTFB is measured: tools and what each one sees** Different tools report different slices of the same timeline, which explains most disagreements between dashboards. - **Browser DevTools:** the Timing tab labels requestStart to responseStart as waiting for server response. That is only the final phase, not the full Web Vitals TTFB. - **Real-user monitoring (RUM):** Navigation Timing and Resource Timing entries, reported at p75 by country and connection type. - **Synthetic tests:** Lighthouse and WebPageTest run controlled cold loads that are repeatable but unrepresentative. - **Command-line HTTP clients:** timing variables such as time\_namelookup, time\_connect, time\_appconnect and time\_starttransfer split one request into its phases. - **CDN logs and analytics:** cache status, edge time and origin time per request. - **Reverse proxy logs and application performance monitoring (APM):** upstream header time and handler duration, which isolate origin work. TTFB matters most for dynamic HTML, authenticated pages, APIs, video manifests and single-page application bootstrap requests. In each of these, a slow first byte delays everything downstream, even when the rest of the transfer is fast. ## **TTFB meaning: what is TTFB versus its neighbors** TTFB vs. latency (RTT): round-trip time is pure network delay between two points. TTFB includes several round trips plus all server-side processing, so a cold request usually costs at least three times the RTT before any origin work starts. TTFB vs. server response time: server response time is usually measured at the origin and excludes client DNS, connection and TLS setup. A 50 ms server time can sit inside a 600 ms TTFB. TTFB vs. FCP and LCP: First Contentful Paint and Largest Contentful Paint are rendering milestones that start after TTFB. TTFB sets their floor, but it does not determine them. TTFB vs. download time: download time runs from responseStart to responseEnd and depends on throughput and object size rather than on setup or origin latency. ## **TTFB and CDN: how edge caching cuts time to first byte** A CDN lowers TTFB in two ways. First, it terminates DNS, TCP and TLS a few milliseconds from the user instead of across a continent. Second, on a cache hit it removes origin time altogether. In the budget above, those two effects take a 480 ms cold request down to 78 ms. Fixes in rough order of payoff: - **Raise the hit ratio:** strip tracking query parameters from the cache key, avoid caching on cookies, and keep Vary limited to Accept-Encoding. - **Cache HTML where possible:** use short TTLs with stale-while-revalidate, so users get the stale copy while the edge refreshes it in the background. - **Shield the origin:** an origin shield with request coalescing keeps edge-to-origin connections warm and absorbs miss storms. - **Flush early:** send headers and the document head before slow data fetches finish, and disable response buffering in proxies that sit in front of streaming handlers. - **Remove redirects:** collapse http to https and apex to www hops into a single canonical URL. - **Expose timing:** emit a Server-Timing response header with separate entries for cache status, edge duration and origin duration, so RUM data can split TTFB by cause. For heavy static workloads such as video segments, installers and game patches, the hit ratio is the main lever. BlazingCDN includes [**origin shield and request coalescing on every plan**](https://blazingcdn.com/features/) and reports a 96%+ average cache hit ratio. ## **Failure modes: when TTFB is high or misleadingly low** TTFB is easy to misread because some failures make it look better, not worse. The table below lists the common patterns, how each one appears in the data, and how to confirm it. | Failure | How it shows up | How to confirm | | --- | --- | --- | | Fast errors | p75 TTFB improves during an incident | Segment TTFB by status code; 503s often return in under 30 ms | | Miss storm after purge or deploy | p95 spikes for minutes, origin CPU climbs | Hit ratio drop aligned with purge timestamps in CDN logs | | Cache key fragmentation | Hit ratio stuck well below expectations | Count distinct cache keys per URL path; check Vary and cookies | | Cold edge-to-origin connections | Misses cost about two extra origin round trips | Compare origin connect time on low-traffic and high-traffic edges | | Response buffering | TTFB roughly equals total response time | Upstream header time far below client TTFB in proxy logs | | Redirects and service worker startup | RUM TTFB far above synthetic and server timings | Nonzero redirectEnd or a large gap before fetchStart | The most dangerous failure is the fast error, because it pushes TTFB in the right direction while availability collapses, so always alert on TTFB together with status codes. ### Verify this on your own stack Compare browser responseStart, CDN edge time and origin handler time for the same request IDs. Split every percentile by cache status (HIT, MISS, EXPIRED) and by new versus reused connection. Keep the same locations, definitions and test method across runs, or the comparison means nothing. ## **FAQ: time to first byte and TTFB with a CDN** ### What is the meaning of TTFB in web performance? TTFB means time to first byte: the time between a client starting a request and receiving the first byte of the response. It includes redirects, DNS, connection and TLS setup, request transmission, and server or edge processing. It excludes the download of the remaining bytes and all rendering work in the browser. ### What is a good TTFB in 2026? A good TTFB for HTML documents is 0.8 seconds or less at the 75th percentile, and above 1.8 seconds is poor under the Web Vitals thresholds. Cached static objects served from an edge hit should come in well under 100 ms in-region, because only network time and the cache lookup remain on that path. ### Does a CDN reduce TTFB on cache misses? A CDN usually reduces TTFB on cache misses, but only when edge-to-origin connections are already warm. The edge terminates TCP and TLS close to the user, which saves round trips. A cold edge-to-origin connection adds its own handshakes, though, and can make a miss slower than going direct. Origin shielding prevents that. ### Why is TTFB high when the origin server responds quickly? TTFB is often high with a fast origin because the delay sits outside the application. Common causes are redirect chains, slow DNS resolution, cold TLS handshakes across long round trips, service worker startup, and proxies that buffer the full response before sending headers. Compare proxy upstream header time with client TTFB to locate the gap. ### Is TTFB a Core Web Vital? TTFB is not a Core Web Vital. It is a diagnostic metric that sits underneath Largest Contentful Paint, because no rendering can begin until the first byte arrives. A poor TTFB makes a good LCP difficult to reach, but a good TTFB does not guarantee a good LCP if render-blocking resources are slow. ## **Measure your TTFB phases this week** Pick your three highest-traffic request classes, for example HTML, API calls and manifests or large objects. For each one, collect p75 and p95 TTFB from real-user data and split it into DNS, connect, TLS and waiting time. Then segment the waiting phase by cache status and by new versus reused connection. If cold misses come close to the direct-to-origin cost in the worked budget above, prioritize shielding and connection reuse before you tune application code. To see how a delivery network performs on the same kind of test, BlazingCDN publishes its June 2026 measurements and a public test file on its [**CDN performance metrics page**](https://blazingcdn.com/performance-metrics/), so you can benchmark it against your current TTFB from your own locations. Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context) [๐•](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context&text=) [โœ‰](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3EWhat%20Is%20TTFB?%20Time%20to%20First%20Byte%20Explained%20and%20How%20to%20Cut%20It%3C/span%3E&body=https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic Their monthly bill vs ours - 20 TBFastly $2,087**$92.50** - 50 TBCDN77 $990**$215** - 200 TBCloudFront $11,965**$765** Published list prices, Aug 2026 [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-04-50-37-1794-AM.jpeg)](https://blog.blazingcdn.com/en-us/upload-speed-for-live-streaming-what-you-actually-need?hsLang=en-us) Video - Video & Streaming ### [Upload Speed for Live Streaming: What You Actually Need](https://blog.blazingcdn.com/en-us/upload-speed-for-live-streaming-what-you-actually-need?hsLang=en-us) Plan your upload speed for streaming at about 1.6 times the total bitrate you push, measured as sustained ... Nov 1, 2026, 5:52:39โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/upload-speed-for-live-streaming-what-you-actually-need?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-04-25-13-9252-AM.jpeg)](https://blog.blazingcdn.com/en-us/what-is-anycast-definition-use-cases-and-enterprise-context?hsLang=en-us) Learn ### [What Is Anycast? How Anycast Routing Speeds Up the Internet](https://blog.blazingcdn.com/en-us/what-is-anycast-definition-use-cases-and-enterprise-context?hsLang=en-us) Anycast is a network addressing and routing model in which servers in many locations announce the same IP prefix, ... Nov 1, 2026, 5:27:33โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/what-is-anycast-definition-use-cases-and-enterprise-context?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜ Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐ŸŽฌ Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿญ Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [โšก Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [๐Ÿ”’ Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [โœ๏ธ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f ๐• โœ‰ Copyright ยฉ BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-11-01T04:57:43Z", "datePublished" : "2026-11-01T04:57:43Z", "description" : "What Time to First Byte measures, what a good TTFB is, the causes of slow TTFB from DNS to origin, and fixes including CDN caching.", "headline" : "What Is TTFB? Time to First Byte Explained and How to Cut It", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-01-2026-04-55-11-4700-AM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 2102 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context", "name" : "What Is TTFB? Time to First Byte Explained and How to Cut It", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/what-is-ttfb-time-to-first-byte-definition-use-cases-and-enterprise-context#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "TTFB means time to first byte: the time between a client starting a request and receiving the first byte of the response. It includes redirects, DNS, connection and TLS setup, request transmission, and server or edge processing. It excludes the download of the remaining bytes and all rendering work in the browser." }, "name" : "What is the meaning of TTFB in web performance?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "A good TTFB for HTML documents is 0.8 seconds or less at the 75th percentile, and above 1.8 seconds is poor under the Web Vitals thresholds. Cached static objects served from an edge hit should come in well under 100 ms in-region, because only network time and the cache lookup remain on that path." }, "name" : "What is a good TTFB in 2026?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "A CDN usually reduces TTFB on cache misses, but only when edge-to-origin connections are already warm. The edge terminates TCP and TLS close to the user, which saves round trips. A cold edge-to-origin connection adds its own handshakes, though, and can make a miss slower than going direct. Origin shielding prevents that." }, "name" : "Does a CDN reduce TTFB on cache misses?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "TTFB is often high with a fast origin because the delay sits outside the application. Common causes are redirect chains, slow DNS resolution, cold TLS handshakes across long round trips, service worker startup, and proxies that buffer the full response before sending headers. Compare proxy upstream header time with client TTFB to locate the gap." }, "name" : "Why is TTFB high when the origin server responds quickly?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "TTFB is not a Core Web Vital. It is a diagnostic metric that sits underneath Largest Contentful Paint, because no rendering can begin until the first byte arrives. A poor TTFB makes a good LCP difficult to reach, but a good TTFB does not guarantee a good LCP if render-blocking resources are slow." }, "name" : "Is TTFB a Core Web Vital?" } ] } ```