What Is Time to First Byte (TTFB)?
Time to First Byte (TTFB) is the time between a browser requesting a web page and receiving the first byte of the server's response. It captures server processing, network travel, and any redirects before content begins arriving. TTFB is a foundational speed metric because everything else, including rendering and Core Web Vitals, waits on it. A good TTFB is roughly 800 milliseconds or less, and slow hosting is the most common reason it lags.
- Good threshold
- 800 ms or less at the 75th percentile (web.dev)
- What it includes
- Redirects, DNS, connection setup, and server processing (web.dev)
- Relationship
- A component of Largest Contentful Paint, not a Core Web Vital itself (Google)
- Biggest lever
- Server response time and hosting quality (industry-typical)
What exactly does TTFB measure? #
TTFB measures the elapsed time from the moment a browser sends a request until the very first byte of the response arrives back. It is not one single delay but a chain of smaller steps stacked together: any redirects the URL passes through, the DNS lookup that turns your domain into an IP address, the time to open a network connection and negotiate encryption, the request travelling to the server, the server building the page, and the first byte travelling back. Because it sums all of that, TTFB is a useful early-warning signal. A high TTFB tells you the problem is on the server or network side, before the browser has even begun downloading HTML, CSS, or images. For local business sites on shared hosting, TTFB is often the single biggest, most fixable slowdown. Understanding the pieces helps you target the right fix, whether that is faster hosting, fewer redirects, or a content delivery network. See /wiki/what-is-dns for how name resolution fits in and /services/managed-hosting for server-side improvements.
What is a good TTFB? #
Google considers a TTFB of 800 milliseconds or less to be good, measured at the 75th percentile of real visits. That figure is generous on purpose, because TTFB is only one part of the loading experience and Google prefers to judge the visible result through Largest Contentful Paint. Still, faster is always better: a TTFB under 200 milliseconds is achievable on well-configured hosting with caching, and it leaves far more headroom for the rest of the page to load within Core Web Vitals targets. Anything above 1.8 seconds is clearly problematic and usually points to overloaded shared hosting, an uncached content management system, or a database struggling under heavy queries. Because TTFB varies by visitor location and device, always judge it from field data rather than a single test on your own fast connection. Our /tools/website-grader reports server response time so you can see where you stand, and /services/speed-optimization targets the server layer directly.
What causes a slow TTFB? #
A slow TTFB nearly always comes from the server side. The most common cause is cheap or overloaded shared hosting, where your site competes with hundreds of others for limited processing power. Dynamic content management systems like WordPress make it worse when every page is rebuilt from the database on each request instead of being served from cache. Heavy or unoptimized database queries, bloated plugins, and slow application code all add processing time. Network factors contribute too: distance between the visitor and the server, extra redirect hops, and repeated DNS lookups. Missing page caching is the single biggest fixable culprit, because caching lets the server return a pre-built page in milliseconds. A misconfigured or absent content delivery network leaves distant visitors waiting for every byte to cross the country. On local business sites we most often trace slow TTFB to shared hosting plus an uncached WordPress install. Our /services/managed-hosting and /services/wordpress-development address both. The /wiki/what-is-a-cdn entry explains the distance factor.
How does TTFB affect Core Web Vitals? #
TTFB is not itself a Core Web Vital, but it is a foundational component of Largest Contentful Paint (LCP), which is. LCP measures when the biggest visible element finishes rendering, and that clock effectively starts once the first byte arrives. If TTFB is slow, LCP inherits the delay no matter how well you optimize images and fonts, because the browser cannot render anything until content begins arriving. Google recommends keeping TTFB low precisely so the rest of the loading budget is available for downloading and painting. In practice, a page with an 800 millisecond TTFB has already spent much of its Core Web Vitals allowance before rendering begins. That is why we treat TTFB as the first thing to fix in a /services/speed-optimization engagement: improvements here cascade into better LCP and a snappier overall feel. See /wiki/website-speed-guide for how the metrics connect and /wiki/what-is-render-blocking for what happens after the first byte arrives.
How do you reduce TTFB with caching? #
Caching is the most powerful lever for cutting TTFB on a dynamic site. Without caching, a content management system rebuilds every page from scratch on each request, running database queries and application code that can take hundreds of milliseconds. Page caching stores the finished HTML so repeat requests are served almost instantly. On WordPress, full-page caching plugins or server-level caching can drop TTFB from over a second to under 200 milliseconds. Object caching stores the results of expensive database queries in memory so they need not repeat. A content delivery network adds edge caching, keeping copies of your pages in data centers near visitors so even the first byte travels a short distance. Layering these together gives the biggest wins. The tradeoff is that cached pages must be cleared when content changes, which good caching setups handle automatically. Our /services/managed-hosting includes server-side caching tuned for local business sites, and /services/care-plans keeps it configured correctly as your site grows.
Hosting quality and TTFB #
Hosting is the single biggest factor in TTFB, and it is where many local business sites are held back. Budget shared hosting packs many sites onto one server, so your response time suffers whenever a neighbor gets busy. Upgrading to quality managed hosting, a virtual private server, or cloud infrastructure gives you dedicated resources and faster hardware, often halving TTFB before any other change. Server location matters too: hosting physically closer to your customers shortens the round trip. The software stack counts as well, with modern PHP versions, tuned databases, and server-level caching all lowering response time. For a plumber or dentist serving one metro area, a well-configured server in the right region plus caching usually delivers excellent TTFB. Our /services/managed-hosting and /services/vps-cloud-setup provide infrastructure built for speed, and we handle /services/website-migrations so moving from slow hosting is painless. If your current host is the bottleneck, no amount of front-end optimization will fully compensate.
Redirects, DNS, and network factors #
Beyond the server, several network steps quietly inflate TTFB. Each redirect adds a full round trip: if visitors reach your site through a chain like non-secure to secure to www, that is multiple hops before the real page even starts loading. Consolidating redirects to a single hop removes that waste. DNS lookups also cost time; a slow DNS provider or an uncached lookup delays the first connection, so fast, reliable DNS matters. Connection setup, including the TLS handshake for HTTPS, adds a fixed cost that modern protocols like HTTP/3 reduce. Physical distance is the last factor: a visitor far from your server waits longer for every packet, which a content delivery network mitigates by serving from a nearby edge. On local sites we routinely find one or two unnecessary redirects and a slow DNS setup adding hundreds of milliseconds. Our /services/domains-dns-email service tunes DNS, and /wiki/what-is-dns explains the mechanics. Fixing these is low-risk, high-reward work.
How do you measure and monitor TTFB? #
TTFB can be measured in both lab and field settings. Lab tools like WebPageTest, Lighthouse, and Chrome DevTools' Network panel show a single test's server response time, which is useful for debugging but reflects only your connection and location. Field data from the Chrome User Experience Report and Google Search Console shows TTFB across real visitors, which is what truly matters because it captures different regions and networks. For ongoing visibility, uptime and performance monitors can log TTFB over time and alert you when hosting degrades. Our /tools/website-grader surfaces server response time in plain terms, and the /tools/website-down-checker confirms whether the server is responding at all. When diagnosing, compare a cached repeat visit against a first visit to separate hosting speed from caching gaps. Because TTFB drifts as traffic grows and hosting ages, we build periodic checks into /services/care-plans so problems are caught before they drag down Core Web Vitals and conversions rather than after customers have already bounced.
FAQ
What is a good Time to First Byte?
Google considers 800 milliseconds or less a good TTFB at the 75th percentile of real visits. Under 200 milliseconds is excellent and achievable with quality hosting and caching. Above roughly 1.8 seconds is poor and usually signals overloaded shared hosting or an uncached content management system that rebuilds every page from the database.
Is TTFB a Core Web Vital?
No. TTFB is not itself a Core Web Vital, but it is a foundational component of Largest Contentful Paint, which is. Because the browser cannot render anything until the first byte arrives, a slow TTFB directly delays LCP, so improving it is often the first step in Core Web Vitals work.
What is the fastest way to lower TTFB?
Enable full-page caching so the server returns pre-built pages instead of rebuilding them from the database on every request. On WordPress this alone can cut TTFB from over a second to under 200 milliseconds. Pairing caching with quality managed hosting delivers the largest, most reliable improvement.
Does hosting affect TTFB?
Hosting is the single biggest factor. Budget shared hosting crowds many sites onto one server, so response times suffer under load. Moving to managed hosting, a VPS, or cloud infrastructure with dedicated resources and server-level caching often halves TTFB before any front-end change. Server location near your customers helps too.
Do redirects slow down TTFB?
Yes. Each redirect adds a full network round trip before the real page loads. A chain like non-secure to secure to www can stack several hops and hundreds of milliseconds. Consolidating to a single redirect and fixing slow DNS are low-risk changes that reliably shave time off TTFB.
How do I measure my TTFB?
Use field data from Google Search Console or PageSpeed Insights for real-visitor numbers, since those reflect different regions and networks. For debugging, Chrome DevTools' Network panel or WebPageTest shows a single test's server response time. Our website grader reports server response time in plain language so non-technical owners can act.
Was this helpful?