Before a browser can show anything, it has to receive the first byte of your HTML. Everything else, from the first paint to the hero image to interactivity, waits on that moment. Time to First Byte (TTFB) measures how long it takes, and when it is slow, no amount of front-end tuning fully makes up for it.
TTFB is not one of the three Core Web Vitals, so it is easy to overlook. But it sits underneath all of them. Google’s web.dev guidance treats it as the first part of Largest Contentful Paint, so a slow server response leaves less time for everything else.
This guide explains exactly what TTFB includes, the recommended thresholds, how to measure it in the field and the lab, and a prioritised list of fixes covering hosting, caching, CDNs, redirects, databases and newer techniques such as 103 Early Hints.
Key Takeaways
- TTFB is the time from the start of navigation until the first byte of the response arrives. It includes redirects, DNS, connection and TLS setup, and server processing.
- web.dev suggests most sites aim for 0.8 seconds or less; values over 1.8 seconds are considered poor.
- TTFB is not a Core Web Vital, but it directly delays First Contentful Paint and Largest Contentful Paint.
- The biggest wins usually come from caching HTML, using a CDN, removing redirects and fixing slow backend code or database queries.
- Measure with field data first; redirects and real network conditions often do not show up in lab tests.
What does TTFB measure?
web.dev defines TTFB as the time between starting navigation to a page and when the first byte of the response begins to arrive. That covers several phases:
| Phase | What happens | Typical causes of delay |
|---|---|---|
| Redirects | Browser follows one or more redirects | HTTP to HTTPS, www or slash redirects, tracking-link hops |
| Service worker startup | Browser starts a service worker, if the site uses one | Heavy service worker code |
| DNS lookup | Domain name resolved to an IP address | Slow DNS provider |
| Connection and TLS | TCP connection and encryption handshake | Distance to server, old TLS versions |
| Request and server processing | Server builds the page and starts responding | Uncached pages, slow database queries, overloaded hosting, heavy plugins |
Because TTFB includes network setup, a visitor far from your server will see a higher TTFB than one nearby, even if your server responds instantly. That is why field data, which reflects where your real users are, matters more than a single lab test.
What is a good TTFB?
“As a rough guide, most sites should strive to have a TTFB of 0.8 seconds or less.”
— web.dev, Optimize Time to First Byte
web.dev rates TTFB above 1.8 seconds as poor, and between the two as needing improvement. These are guides rather than pass/fail Core Web Vitals thresholds. web.dev’s LCP optimisation guide suggests that, on a well-optimised page, TTFB accounts for roughly 40% of LCP, which leaves the rest of the 2.5-second budget for loading and rendering the main content. If your TTFB alone is close to two seconds, passing LCP becomes very difficult.
Single-page applications that render mostly in the browser can show a fast TTFB yet still feel slow, because the meaningful content arrives later. Server-rendered pages often have a slightly higher TTFB but show content sooner. Judge TTFB alongside FCP and LCP, not in isolation.
How to measure TTFB
- Field: PageSpeed Insights shows TTFB from the Chrome User Experience Report for your URL or origin. The open-source
web-vitalsJavaScript library reports it from your own visitors viaonTTFB. - Lab: the Network panel in Chrome DevTools (look at “Waiting for server response”), WebPageTest, and the document request latency insight in Lighthouse.
- Server: application performance monitoring and server logs show which backend steps are slow.
You can read TTFB for the current page in the browser console:
new PerformanceObserver((list) => {
const [nav] = list.getEntriesByType('navigation');
console.log('TTFB (ms):', nav.responseStart);
}).observe({ type: 'navigation', buffered: true });To see what your server is doing during that time, add a Server-Timing header. web.dev gives an example like this, and the values then appear in DevTools and in the Navigation Timing API:
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2How to improve TTFB: step by step
- Check where the time goes. Compare cached and uncached responses, and use Server-Timing or your monitoring tool to split database, application and rendering time. web.dev advises keeping a way to bypass caches so you can see true server time.
- Remove unnecessary redirects. Same-origin redirects, such as missing HTTPS or inconsistent trailing slashes, add a full round trip each. Link to final URLs and enforce one URL format with single-hop redirects; our guide to choosing one URL version shows how. Use HSTS so returning visitors skip the HTTP-to-HTTPS hop.
- Cache HTML. Full-page caching (at the server, in a caching plugin or at the CDN edge) turns a slow dynamic page into a fast static response for most visitors. Set sensible
Cache-Controlheaders and purge on publish. - Use a CDN. Serving from the edge shortens connection setup and, with HTML caching, the response itself. See CDNs and SEO.
- Upgrade or tune hosting. web.dev notes that shared hosting is usually only suitable for small, mostly static sites. Busy or dynamic sites need enough CPU and memory, current server software and a modern runtime. Our post on web hosting and SEO covers what to look for.
- Fix slow backend code. Add database indexes, cache expensive queries (for example with an object cache), and remove plugins or middleware that do heavy work on every request.
- Stream the response. Frameworks and runtimes that support streaming can send the
<head>immediately, so the browser starts fetching CSS and images while the server finishes the body. - Consider 103 Early Hints. If server processing is unavoidably slow, a
103response lets the browser start loading critical resources early. web.dev cautions that it can mask a slow server in TTFB reports, so keep measuring actual server time. - Retest in the field over the following four weeks, since Chrome UX Report data covers a rolling 28-day period.
Fixes by cause
| Symptom | Likely cause | Fix |
|---|---|---|
| Fast for you, slow in field data | Visitors far from server, or redirect hops from ads and emails | CDN; link to final URLs |
| Slow only on first visit after updates | Cold cache | Cache warming; longer cache lifetimes for static pages |
| Slow on search, filter or cart pages | Uncacheable dynamic queries | Database indexes, object caching, query optimisation |
| Slow at peak times | Under-powered hosting | More resources, autoscaling or better hosting |
| Slow on WordPress admin-heavy sites | Plugins running on every request | Audit and remove plugins; enable page and object caching |
| Cache-busting parameters | Unique query strings bypass cache | Normalise or ignore tracking parameters in cache keys |
Common mistakes
- Testing only cached pages. Your homepage may be cached while category pages and search results are not.
- Judging by one lab test. A test from a nearby data centre hides the experience of distant or mobile visitors.
- Ignoring redirects from marketing links. Shortened links and click trackers can add several hops before your page even starts loading.
- Assuming a CDN fixes everything. A CDN that does not cache HTML still sends every page request back to a slow origin.
- Over-optimising TTFB at the expense of content. A tiny client-rendered shell can have a fast TTFB but a slow LCP.
Once TTFB is healthy, move on to the rest of the loading path: render-blocking resources and image delivery. Our Core Web Vitals overview and page speed guide tie these together.
Related Guides
- Largest Contentful Paint (LCP): How to Fix It
- Interaction to Next Paint (INP): How to Improve It
- Cumulative Layout Shift (CLS): How to Fix It
Frequently Asked Questions
Is TTFB a Core Web Vital?
No. The Core Web Vitals are LCP, INP and CLS. TTFB is a supporting metric, but because it comes before everything else it strongly affects LCP.
What is a good TTFB?
web.dev suggests most sites aim for 0.8 seconds or less, with anything above 1.8 seconds considered poor.
Does TTFB affect SEO?
Indirectly. A slow TTFB delays content for users and makes it harder to pass LCP. Very slow or failing server responses can also reduce how much Googlebot crawls.
Why is my TTFB slow in PageSpeed Insights but fast for me?
Field data reflects all real visitors, including those far from your server, on slow networks or arriving through redirects. Your own tests may hit a warm cache from nearby.
Can a caching plugin fix TTFB?
Often, for pages that can be cached. It will not help uncached pages such as carts, checkouts or logged-in views, which need backend optimisation.
Conclusion
TTFB is the foundation of page speed. Remove redirects, cache HTML, serve from a CDN, give your site adequate hosting and fix slow backend work, and every later metric gets easier to pass. If your server response times are holding back your Core Web Vitals, our page speed optimization service and SEO hosting options can help, or request a free quote.
