How to reduce server response time (TTFB)
On this page
To reduce server response time, make the server do less work per request and put the response closer to the visitor: cache pages, serve them through a CDN, cut redirects, and fix slow back-end code or database queries. Server response time is measured as Time to First Byte (TTFB), and because it comes before everything else on the page, every millisecond you save makes the rest of the page arrive sooner.
5.0-star Google rating (24 reviews) · BBB Accredited, A rating
What does TTFB measure, and why does it limit LCP?
TTFB measures the time from when a browser requests a page to when the first byte of the response arrives. According to web.dev (opens in new tab), it includes redirect time, connection setup (DNS, TCP and TLS) and the time the server spends building the response.
It matters because nothing can render until the HTML arrives. TTFB is the first of the four parts that make up Largest Contentful Paint, so a slow server sets a floor your LCP can't beat. web.dev's LCP optimization guide (opens in new tab) treats it as the first thing to check. If your server takes two seconds to respond, a 2.5-second LCP leaves only half a second for everything else.
What is a good TTFB?
web.dev suggests (opens in new tab) aiming for a TTFB of 0.8 seconds or less, measured at the 75th percentile of real visits; over 1.8 seconds is poor. web.dev is clear that this is a rough guide: TTFB isn't a Core Web Vital, and what matters is that it leaves room for good LCP.
Sites that render content in the browser with JavaScript can still be slow even with a fast TTFB, because the real content arrives later. And a site with a slightly higher TTFB can still pass LCP if the rest of the page is lean.
How do you measure TTFB?
Measure TTFB with both lab tools, which test one load under set conditions, and field data, which shows what real visitors experience. You need both: lab tests help you debug, field data tells you whether there's a real problem.
- Lab: PageSpeed Insights and Lighthouse report server response time; the Network panel in Chrome DevTools shows the timing breakdown for the page request, including waiting time.
- Field: the Chrome UX Report data in PageSpeed Insights shows TTFB for real users at the 75th percentile.
- Test from several places: TTFB from a server near your host can look fine while visitors elsewhere wait much longer.
Our website speed test guide explains how to read these tools, and Core Web Vitals explained covers how field data works.
What usually causes slow server response time?
The usual causes are pages built from scratch on every visit, a server far from the visitor, redirect chains, overloaded hosting and slow database queries. Most slow sites have more than one of these at once, which is why fixing one sometimes helps less than expected.
A quick way to narrow it down: if TTFB is slow everywhere, including on simple pages, look at hosting and caching. If it's slow only far from your host, a CDN is the fix. If it's slow only on certain pages, look at what those pages do on the server, such as search, filters or personalized content.
How do you fix a slow TTFB?
Fix slow TTFB by working through the causes in order of payoff: caching and a CDN first, then redirects, then hosting, then back-end code and database work. web.dev's guide to optimizing TTFB (opens in new tab) covers each.
Cache pages so they aren't rebuilt every time
If your server builds each page from scratch on every request, by running code and querying a database, caching is the biggest single win. Full-page caching stores the finished HTML and serves it instantly. Object caching stores the results of expensive queries. Make sure logged-out visitors get cached pages, and check that caching plugins or settings actually work.
Use a CDN
A content delivery network keeps copies of your pages and files on servers around the world, so each visitor connects to one nearby. That shortens connection setup and travel time. Many CDNs can also cache full HTML pages at the edge, which takes your origin server out of the loop for most visits.
Cut redirects
Each redirect adds a full round trip before the real page starts loading. Chains like http to https to www to a trailing slash can add a lot. Link straight to final URLs, update old internal links, and collapse chains into one hop. Our 301 redirects guide shows how.
Upgrade or right-size hosting
Cheap shared hosting puts your site on a crowded server, and response times rise when neighbors get busy. If caching and a CDN don't fix TTFB, a better plan or a host suited to your platform often will. Check that the server runs current software versions, since newer versions are often faster.
Fix slow back-end code and database queries
When pages can't be cached, such as carts, account pages or search results, the server's own work matters most. Profile requests to find slow database queries, missing indexes, plugins that run on every page, and calls to outside services that block the response.
Rethink how pages are rendered
How a page is built affects TTFB. Static pages, generated ahead of time, can be served from a CDN almost instantly. Server-rendered pages are built on request and depend on server speed. Our guide to server-side rendering vs static site generation explains the trade-offs.
Can 103 Early Hints and preconnect help?
Yes: 103 Early Hints lets the server tell the browser which critical files to start fetching while it's still building the page, so that waiting time isn't wasted. web.dev's TTFB guide (opens in new tab) describes it as a way to make use of server think time; it doesn't lower TTFB itself, but it can improve what happens after.
For files on other domains, such as fonts or a CDN for images, a preconnect hint sets up the connection early. Use it only for the one or two origins that matter most, since each connection has a cost.
Server response time checklist
- Check field TTFB at the 75th percentile in PageSpeed Insights.
- Test from several locations, not just near your host.
- Turn on full-page caching for logged-out visitors.
- Put the site behind a CDN, with HTML caching where possible.
- Remove redirect chains and link straight to final URLs.
- Review hosting plan and software versions.
- Profile uncached pages for slow queries and plugins.
- Consider static generation for pages that rarely change.
- Add Early Hints or preconnect for critical files.
- Re-test LCP once TTFB improves.
Once the server is quick, the next places to look are LCP and Interaction to Next Paint. If you suspect wider technical problems, a technical SEO audit checks speed alongside crawling and indexing.
FAQs
What is a good TTFB?
web.dev suggests most sites aim for a TTFB of 0.8 seconds or less at the 75th percentile of visits, and treats anything over 1.8 seconds as poor. It's a rough guide rather than a strict rule, because TTFB matters mainly for how it delays everything after it.
Does TTFB affect SEO?
Not directly. TTFB isn't a Core Web Vital, but it's the first part of Largest Contentful Paint, which is. A slow server makes good LCP hard to reach. Google uses Core Web Vitals as part of page experience, but no speed fix guarantees better rankings.
Does a CDN help reduce TTFB?
Usually, yes. A CDN serves pages and files from a server close to each visitor, which cuts travel time, and it can cache whole pages so your origin server doesn't build them on every request. It helps most for visitors far from your host.
Why is TTFB slow only sometimes?
Intermittent slow TTFB usually means a cache miss, a cold server waking up, or a busy server. The first visitor after a cache expires waits for the page to be built; later visitors get the cached copy. Check cache hit rates and server load at the slow times.