What is TTFB? Time to First Byte Explained
TTFB measures how long it takes for a browser to receive the first byte of data from your server. A good TTFB is under 200ms, and hosting infrastructure is the biggest factor.
TTFB (Time to First Byte) measures how long a browser waits before receiving the first byte of data from your server. A good TTFB is under 200ms. Hosting infrastructure, PHP processing time, and database queries are the biggest factors that determine your TTFB.
What TTFB actually measures
TTFB stands for Time to First Byte. It is the time between the browser requesting a page and receiving the first byte of the response. The measurement includes three components: the network round-trip time, the server processing time, and the time it takes for the server to begin sending the response.
Many people assume TTFB is purely a network metric, but the server processing time is often the dominant factor. When you ask what is TTFB on your site, you are really asking how quickly your server can execute the code and query the database to generate the page. A fast network connection cannot compensate for a server that takes two seconds to build the page.
TTFB is measured from the browser’s perspective, which means it includes DNS lookup, TCP connection, TLS handshake, and the initial server processing. The first three are relatively constant for a given host and geographic region. The server processing time is where most optimisation opportunity lies.
Good vs bad TTFB thresholds
The industry benchmark for TTFB has tightened over the years as server technology has improved. Here is how to interpret your numbers:
| TTFB range | Rating | Likely impact on visitors |
|---|---|---|
| Under 200ms | Good | No noticeable delay. Server responds instantly. |
| 200ms – 500ms | Needs improvement | Perceptible delay. Most visitors will wait but bounce rates increase. |
| 500ms – 1s | Poor | Significant delay. Bounce rates rise sharply, especially on mobile. |
| Over 1s | Critical | Severe impact. Most visitors leave before the page even starts loading. |
Google’s Core Web Vitals assessment treats TTFB as a supporting metric. A TTFB consistently under 200ms gives your Largest Contentful Paint (LCP) a strong foundation. A TTFB over 500ms makes it extremely difficult to pass the LCP threshold of 2.5 seconds.
What causes slow TTFB
When you investigate what is TTFB slowing down your site, the root cause usually falls into one of three categories:
Server infrastructure. Shared hosting with hundreds of accounts on one server creates resource contention. If a neighbour site gets a traffic spike, your TTFB suffers. NVMe storage, LiteSpeed servers, and dedicated resources all reduce server processing time significantly. A move from basic shared hosting to a private shared plan (BD 8.5/month) can cut TTFB by 30 to 50 percent.
Application performance. Slow PHP execution, unoptimised database queries, and bloated frameworks add hundreds of milliseconds. A single uncached WordPress query can take 300 to 500ms. Caching plugins, query optimisation, and PHP 8.x upgrades address this layer.
Network latency. Geographic distance between the visitor and the server adds round-trip time. A visitor in Dubai loading a site hosted in the US will have a baseline TTFB 100 to 200ms higher than a visitor in New York. A CDN or a server location in the GCC fixes this.
How to improve TTFB
Improving your TTFB requires addressing the slowest layer first. Start with a TTFB test using Chrome DevTools or a service like GTmetrix. Run the test from a location close to your target audience. If the TTFB is over 300ms, begin with these fixes:
- Upgrade your hosting. Move from shared hosting to a VPS or private shared plan. LiteSpeed servers with NVMe storage typically reduce TTFB by 100 to 200ms.
- Enable server-level caching. LiteSpeed Cache or Varnish cache serves cached pages in milliseconds instead of processing PHP on every request.
- Use a CDN. A CDN caches your content on edge servers around the world, reducing round-trip time for visitors far from your origin server.
- Optimise the database. Remove unused plugins, clean up post revisions, add indexes to slow queries, and enable query caching.
- Upgrade PHP. PHP 8.x is two to three times faster than PHP 7.4 for most applications. Check your control panel and switch to the latest version.
Each fix compounds on the previous one. A LiteSpeed server with PHP 8 and a CDN can bring TTFB from 800ms down to under 150ms for most WordPress sites.
TTFB and Core Web Vitals
TTFB is not a direct Core Web Vitals metric, but it is the foundation for Largest Contentful Paint (LCP). Google’s LCP target is 2.5 seconds. If your TTFB is 600ms, the browser has already used a quarter of that budget before it even starts rendering the page. Reducing TTFB to under 200ms gives the rest of the page loading process room to succeed.
Google includes TTFB in its Lighthouse performance audits and flags it in PageSpeed Insights. Sites with poor TTFB rarely pass Core Web Vitals assessment. If you are working on LCP and struggling to make progress, check your TTFB first. It is the single most impactful server-side metric for front-end performance.
Frequently asked questions
Under 200ms is good, 200 to 500ms needs improvement, and over 500ms is poor and will likely affect your Core Web Vitals scores.
You can check TTFB using Chrome DevTools (Network tab), web.dev, GTmetrix, Pingdom, or the curl command with the -w flag to output timing details.
The most common causes are slow server response (shared hosting overload, slow PHP execution), poor database queries, geographic distance to the server, and lack of server-level caching.
Yes. TTFB is not a direct ranking factor, but it feeds into Largest Contentful Paint (LCP), which is a Core Web Vitals metric. Google uses LCP in its ranking algorithm, so high TTFB indirectly hurts SEO.