Speed on the web is often discussed in terms of page load time, how long until the page is fully visible and interactive. However, page load time is the end of a story that begins much earlier, before any content renders, before any assets download, before the browser has anything to display at all.
Time to First Byte measures that beginning. It is the duration between a browser sending a request and receiving the very first byte of the server’s response. Everything the user eventually sees depends on what happens during this window, and the factors that drive TTFB up or down are almost entirely infrastructure and backend decisions.
This guide explains what TTFB measures, why it matters for both user experience and SEO, what drives it higher or lower, and what the most effective levers are for improving it.
📖 What causes server response times to increase?
TTFB is a symptom, server load is often the cause. Read What Is Server Load and Why Websites Slow Down, a complete breakdown of how CPU, memory, storage, and network constraints drive response times up.
What TTFB Measures
TTFB is the elapsed time from the moment a browser initiates an HTTP request to the moment it receives the first byte of the HTTP response from the server.
This window encompasses several sequential stages, each of which contributes to the total:
DNS resolution – before the browser can connect to a server, it must resolve the domain name to an IP address. DNS lookup time adds to TTFB on every uncached lookup.
TCP connection establishment – once the IP address is known, the browser establishes a TCP connection through a three-way handshake. This requires at least one round trip between the browser and server.
TLS negotiation – for HTTPS connections, a TLS handshake follows the TCP handshake, adding additional round trips before any application data flows.
Server processing time – after the connection is established, the server receives the request, processes it, executing application logic, querying databases, assembling the response, and begins sending the response. This is the portion most directly under the server’s control.
Network transit – the first byte of the response travels from the server to the browser across the network.
The total TTFB is the sum of all these stages. Improving TTFB means reducing the time spent in one or more of them, and different interventions target different stages.
Why TTFB Matters
User Experience
TTFB is the metric that determines when the browser first has something to work with. Until the first byte arrives, the browser cannot begin parsing HTML, cannot start downloading assets, cannot begin rendering any content. A high TTFB creates a blank screen that users experience as the website being slow or unresponsive.
The relationship between TTFB and perceived speed is direct: lower TTFB means earlier rendering start, which means users see content sooner. For content-heavy pages, this matters significantly more than improvements to rendering or asset loading.
For interactive applications: SaaS products, web apps, real-time dashboards, TTFB also determines how quickly the application responds to user actions after the initial page load. Every API call, every form submission, every navigation event has its own TTFB.
SEO and Core Web Vitals
Google uses Core Web Vitals as ranking signals. Largest Contentful Paint (LCP), one of the three Core Web Vitals, measures how quickly the main content of a page becomes visible. LCP cannot begin until the first byte arrives. A high TTFB delays the entire rendering process, directly increasing LCP scores.
Google’s own guidance identifies TTFB as a key driver of LCP performance. Field data from Google Search Console includes TTFB measurements from real user visits, making the connection between server response time and ranking signal directly visible.
Additionally, a high TTFB affects how efficiently Googlebot can crawl a site. Crawl budget — the number of pages Google will crawl during a given visit — is partially determined by server response speed. Slow responses reduce crawl efficiency, which can delay indexing of new or updated content.
Infrastructure Health Signal
TTFB is one of the most reliable indicators of infrastructure health because it reflects the combined effect of every layer that touches a request: DNS, network, the server’s CPU and memory utilisation, storage I/O speed, and application code efficiency. A TTFB that is trending upward over time, even slightly, often precedes more visible performance problems by days or weeks.
Monitoring TTFB as a continuous metric rather than an occasional test provides early warning of capacity issues before they reach the threshold of user-visible degradation.
What Is a Good TTFB?
Google’s Web Vitals guidance provides a reference framework: TTFB below 800 milliseconds is considered good; 800 milliseconds to 1,800 milliseconds needs improvement; above 1,800 milliseconds is poor.
For production web applications, however, 800 milliseconds is a conservative target. Most well-optimised dedicated server environments deliver TTFB below 200 milliseconds for dynamic content and below 50 milliseconds for cached responses. These lower figures are more appropriate benchmarks for performance-focused infrastructure.
The relevant comparison is not just against the absolute thresholds but against your own baseline. A site that consistently delivers 150ms TTFB and suddenly jumps to 400ms has a problem worth investigating, even if 400ms is within the “acceptable” range by Google’s standards.
Geographic variation in TTFB measurements matters too. Measure from locations representative of your actual user base, not just from a single test location close to your server. A server in Amsterdam will produce very different TTFB measurements for a user in London versus a user in Singapore
The Five Causes of High TTFB
Slow DNS Resolution
Every uncached DNS lookup adds time to TTFB before the TCP connection even begins. If DNS resolution takes 150 milliseconds, not unusual for poorly configured or overloaded DNS infrastructure, that 150 milliseconds adds directly to every new visitor’s TTFB.
Enterprise DNS providers: Cloudflare, AWS Route 53, Fastly, operate globally distributed authoritative DNS infrastructure with very low resolution times from most markets. Using one for authoritative DNS is the simplest single change available for reducing DNS-related TTFB.
Geographic Distance and Network Latency
Physical distance between the user and the server determines the minimum possible TTFB due to the speed of light constraint on network travel. A round trip between London and Amsterdam adds roughly 10 to 20 milliseconds. A round trip between London and Singapore adds 150 to 200 milliseconds.
This physical constraint cannot be overcome by application or server optimisation. It can only be addressed through server location decisions or CDN deployment for cacheable content. For dynamic, uncacheable content, server location relative to the user base is the primary lever.
Server Load and Resource Contention
High CPU utilisation, memory pressure, and storage I/O saturation all directly increase the server processing time component of TTFB. When the server is working hard to handle concurrent requests, each request waits longer in the queue before execution begins.
On shared hosting and VPS environments, resource contention from other tenants compounds this effect. Another tenant’s traffic spike or resource-intensive background job reduces the resources available to your application, increasing your TTFB without any change in your own workload.
Slow Application Logic
The server processing time component of TTFB includes the time your application takes to generate the response: querying databases, executing business logic, rendering templates, calling external APIs. An inefficient database query that takes 300 milliseconds adds 300 milliseconds to every request that triggers it.
At the application level, unindexed database queries, N+1 query patterns, blocking synchronous calls to external services, and computationally expensive rendering that runs on every request all drive TTFB higher.
TLS Handshake Overhead
HTTPS connections require a TLS handshake between the browser and server before application data flows. The standard TLS 1.2 handshake requires two round trips; TLS 1.3 reduces this to one. For a user 100 milliseconds from the server, a TLS 1.2 handshake adds 200 milliseconds to TTFB.
TLS 1.3 and session resumption, reusing established TLS sessions rather than performing a full handshake on every connection, are the primary techniques for reducing TLS-related TTFB overhead.
📖 How does DNS resolution contribute to TTFB?
DNS is the first stage of every TTFB measurement. Read How DNS Works and Why It Matters for Web Performance, a complete breakdown of DNS resolution mechanics and how DNS infrastructure quality affects every page load.
TTFB vs Full Page Load Time
TTFB and full page load time measure different things and are appropriate for diagnosing different types of performance problems.
The TTFB measures the server and network response: everything that happens before the browser has received enough data to begin rendering anything. High TTFB indicates a problem in the backend: server capacity, application efficiency, network proximity, DNS, not in the frontend.
Full page load time measures the entire loading process including asset downloads, JavaScript execution, and rendering. A page with excellent TTFB can still have poor full load time if it loads many large assets, executes slow JavaScript, or has poorly structured rendering paths.
A website may have fast TTFB but slow full load time, indicating a frontend optimisation opportunity. Alternatively, it may have slow TTFB but acceptable full load time, indicating a backend problem that is being partially masked by effective caching or asset optimisation.
Diagnosing performance problems correctly requires measuring both. The waterfall view in browser developer tools and tools like WebPageTest show both TTFB and subsequent loading stages, making the distinction visible.
How to Improve TTFB
The most effective TTFB improvements come from addressing the highest-contributing stage first. Profiling tools identify which stage contributes most to any specific TTFB measurement.
Upgrade DNS infrastructure – switch authoritative DNS to an enterprise provider with globally distributed infrastructure and low resolution times from your key user markets.
Move the server closer to users – choosing a server location geographically close to your primary user base is the highest-leverage change for reducing network latency. For European users, a European data centre is the correct answer.
Add caching – server-side caching (Redis, Memcached) reduces application processing time by serving pre-computed responses. Full-page caching via a reverse proxy (Varnish, Nginx) can reduce TTFB for cacheable content to single-digit milliseconds. CDN caching reduces TTFB for static content by serving from edge nodes close to users.
Upgrade server hardware – NVMe storage dramatically reduces database query execution time by lowering I/O latency. More RAM reduces swap usage and allows more data to be served from cache. More CPU cores reduce queuing when concurrent requests arrive.
Move to dedicated infrastructure – eliminating resource contention from shared hosting removes the TTFB variability that other tenants’ activity creates. Dedicated servers produce more consistent TTFB because the available resources are fixed and exclusively allocated to your workload.
Optimise application code – database query optimisation, index creation, caching of expensive computations, and elimination of synchronous blocking calls each reduce the server processing time component of TTFB.
Enable TLS 1.3 and session resumption – reducing TLS handshake overhead lowers the TTFB contribution of the connection establishment phase.
📖 How does NVMe storage reduce server processing time?
Storage speed is a direct input to the server processing component of TTFB. Read How NVMe Storage Boosts Dedicated Server Performance, including how NVMe latency and IOPS translate into faster database queries and lower TTFB.
Measuring TTFB Correctly
TTFB measurements vary significantly based on how and from where they are taken. Measuring correctly produces actionable data; measuring incorrectly produces misleading numbers.
Measure from multiple geographic locations. A TTFB test run from the same city as the server will show excellent results regardless of how users in distant markets experience the site. Tools like WebPageTest allow selecting test nodes in different cities and countries.
Test both cached and uncached responses. TTFB for a cached page response served from a reverse proxy cache will be very different from TTFB for an uncached dynamic page that requires full application processing. Both measurements are useful for different diagnostic purposes.
Use real user monitoring (RUM) data. Synthetic tests from fixed locations miss the variance in real user experience. Google Search Console provides TTFB field data from actual users, segmented by page type, which is the most accurate picture of what real visitors experience.
Track trends over time. A single TTFB measurement has limited value. Monitoring TTFB continuously and watching for upward trends, even gradual ones, reveals capacity issues developing over time before they become visible performance problems.
Infrastructure that delivers consistently low TTFB
Swify dedicated servers combine NVMe storage, exclusive CPU and RAM, European data centre locations, and high-quality network connectivity, addressing every infrastructure factor that drives TTFB up, simultaneously.
→ Explore Swify Dedicated ServersFrequently Asked Questions
What is a good TTFB for a website?
Google’s Web Vitals guidance identifies TTFB below 800 milliseconds as good, 800 to 1,800 milliseconds as needing improvement, and above 1,800 milliseconds as poor. For production web applications on well-configured dedicated infrastructure, TTFB below 200 milliseconds for dynamic content and below 50 milliseconds for cached responses are more appropriate performance targets.
Geographic location affects what is achievable. A server in Amsterdam serving a user in London can realistically deliver 20 to 50 millisecond TTFB. The same server serving a user in Singapore will deliver 150 to 250 milliseconds regardless of how well-optimised the server is, because physical distance imposes a minimum round-trip time. Measure TTFB from locations representative of your actual user base for accurate baseline data. Read more about how server location affects latency in Latency Explained: Why Dedicated Servers Improve Global Delivery.
Does TTFB affect Google rankings?
Yes, indirectly through Core Web Vitals. TTFB directly affects Largest Contentful Paint (LCP), which is one of Google’s three Core Web Vitals ranking signals. LCP cannot begin until the first byte arrives, a high TTFB delays the entire rendering process, increasing LCP scores and potentially suppressing rankings for competitive keywords.
TTFB also affects crawl efficiency. Googlebot allocates crawl budget partly based on server response speed. Slow responses reduce how many pages Google crawls during a visit, which can delay indexing of new or updated content. Google Search Console provides LCP field data segmented by page type, making it possible to correlate server response time improvements with Core Web Vitals score changes.
Can a CDN improve TTFB?
Yes, for cacheable content. A CDN serves cached responses from edge nodes close to users, dramatically reducing both network transit time and server processing time for those requests. A page response cached at a CDN edge node 10 milliseconds from the user delivers a much lower TTFB than the same response served from an origin server 200 milliseconds away.
For uncacheable content, authenticated requests, personalised responses, dynamic API calls, the CDN provides no TTFB benefit, because each request must travel to the origin server regardless. For applications where most traffic is dynamic or authenticated, improving origin server performance is more impactful than CDN deployment. Read more in What Is a Content Delivery Network (CDN) and Why Your Site Needs It.
Does shared hosting produce higher TTFB than dedicated servers?
Yes, typically, and more importantly, it produces more variable TTFB. On shared hosting, CPU, memory, and storage are divided among many tenants. Another tenant’s traffic spike, background job, or resource-intensive process reduces the resources available to your application without any change in your own traffic, causing TTFB to increase unpredictably.
Dedicated servers eliminate this variability. With exclusive CPU, memory, and storage, TTFB is determined entirely by your own workload and configuration. This predictability is often more valuable than the absolute TTFB number, a consistently low TTFB is better than one that is sometimes excellent and sometimes poor. Read more about the performance differences in Dedicated Server vs VPS: Which One Do You Actually Need?
How do I measure TTFB accurately?
Several tools measure TTFB from different perspectives. WebPageTest allows testing from specific geographic locations and shows TTFB as part of the waterfall view, making it easy to see which stage contributes most. Chrome DevTools Network tab shows TTFB for every request during a page load, which is useful for identifying specific slow endpoints.
Google Search Console provides TTFB field data from real user visits, not synthetic tests, which gives the most accurate picture of what actual visitors experience. Continuous monitoring tools like Pingdom, UptimeRobot, or Grafana with Prometheus can track TTFB over time and alert on increases. The most common measurement mistake is testing only from a location close to the server, always test from locations representative of your actual user base to get accurate baseline data. Read more about monitoring tools in Best Tools to Monitor Dedicated Server Performance.
Is TTFB affected by the number of concurrent users?
Yes, directly. As concurrent users increase, server resources are divided among more simultaneous requests. TTFB increases as requests queue behind each other waiting for CPU time, database connections, or I/O operations to complete. The relationship between concurrent load and TTFB is one of the clearest indicators of when a server is approaching its capacity ceiling.
On shared hosting, this is compounded by resource contention with other tenants, traffic spikes from other accounts reduce the resources available to your application simultaneously. On a dedicated server, TTFB under concurrent load is determined only by your own workload’s resource consumption. Load testing, gradually increasing simulated concurrent users and measuring TTFB at each level, reveals the capacity point at which TTFB begins degrading, which informs infrastructure scaling decisions. Read more in Understanding Server Load: How Dedicated Servers Handle High Traffic.