How to reduce server response time (TTFB)

By Matt Kerr·Published 12 October 2026

Time to first byte is how long your server takes to start sending a page. If it is slow, nothing you do to the page itself can make the page fast. Fix it in this order: cache whole pages, put a CDN in front of the site, speed up whatever is slow behind the cache, and move off the host if the host is the cause. Measure after each step, so you know which one paid.

What good looks like

I read web.dev's guide to the metric on 12 October 2026: Time to First Byte (TTFB). It calls a good value eight tenths of a second or less, and a poor one anything over one and eight tenths. It also says TTFB is not a Core Web Vital, so a site does not strictly have to meet the good bound as long as the slow start is not stopping it scoring well on the metrics that matter. The reason to care is that the server's reply comes before everything else: no first paint and no largest paint can happen until it starts.

What Docket reports

Docket takes the median time to first byte across the pages it crawled, and needs at least three pages to do it. It reports one of three things.

• Above target. The median is over eight tenths of a second.
• Slow across the site. The median is over one and eight tenths, reported as high severity.
• Slow the first time, fast when asked again. Docket is usually the first visitor to a page, so it sees a cold cache. It asks again for some of the slowest, and if the second answer is fast it says so: a cache in front of a slow server.

The fix, in order

1. Cache whole pages. For a page that is the same for every visitor, the server should not build it again each time. Full-page caching is the biggest single change on most sites, and on a CMS it is often a plugin or a setting.
2. Put a CDN in front. A CDN answers from a server near the visitor and keeps a copy, so most requests never reach yours.
3. Find what is slow behind the cache. The usual cause is a slow database query on a main template, or a plugin that does work on every request. A cache hides this for repeat visits and not for the first visitor after it expires, or for a crawler working through pages nobody has asked for lately.
4. Move off the host if the host is the bottleneck. Shared hosting that is slow at every hour and for every page is a limit no setting will lift.

Redirects add their own wait before the page is even asked for. They are covered in how to fix redirect problems. To see where the time goes on one page, open your browser's network panel, load the page, click the first request and look at its timing: the line called waiting for server response is the time to first byte. The command-line tool curl can print it too: its write-out option has a variable called time_starttransfer.

Load the page a few times. If the first load is slow and the next ones are fast, you have the cache case below. If every load is slow, the server is slow on every request.

Two neighbours are easy to confuse with this one. A response that is large or uncompressed is a different finding, with its own page on enabling gzip and setting caching headers. And a server that answers only after many seconds can make an audit list pages as unreachable because its timeout ran out first; how to tell slow from down covers that.

A real before and after

I wrote a small fixture site for this page: six pages of a typewriter repair workshop, served by a local server that waits a set time before it sends each page. I audited it with Docket on 12 October 2026 four times, changing only the wait. This shows how Docket reads response time. It is not a recipe for speeding up a real server.

• Every request waits more than two seconds. Docket reported: Server responses are slow across the site (median 2.22s)
• The first request for each page waits that long, and later ones answer at once. That is a cache in front of a slow server. Docket reported: Pages are slow the first time they are requested (median 2.22s); repeated, 0.01s
• Every request waits about a second. Docket reported: Server response time is above target (median 1.13s)
• No wait. Docket reported nothing.

For the first, its fix was: In order of typical payoff: enable full-page caching, put a CDN in front of the site, check for slow database queries on the main templates, and move off shared hosting if the host is the bottleneck. For the cache case it was: Keep pages in the cache longer, warm it after publishing or clearing it, and speed up the origin itself: slow database queries on the main templates are the usual cause.

What Docket cannot tell you

• Why the server is slow. It measures the wait and not what the server was doing. The fixes above are the usual causes in order of payoff, and the order is a guide.
• How slow it is for your visitors. It measures from the machine it runs on, so a server far from that machine looks slower here than it does to someone next door. Field data from PageSpeed Insights or Search Console is the real picture for your own visitors.
• Whether it matters for your site. TTFB is not a Core Web Vital. A slow reply is worth fixing because it is the floor under every other loading number, not because the number itself is scored.

Where to start

Time your home page and two others, a few times each. If the first run is slow and the rest are fast, warm the cache after you publish and look at what is slow on a cold page. If they are all slow, turn on full-page caching first. Slow servers also cost you in the loading findings that come after: files that block the first paint are the next place to look. What Docket adds is the same measurement across every page, ranked with the rest; see how that compares with other audit tools.

Common questions

What is a good TTFB?

web.dev calls eight tenths of a second or less good and anything over one and eight tenths poor.

Is TTFB a Core Web Vital?

No. web.dev says it is not, so meeting the good bound is not strictly required, but a slow reply sits under every other loading metric.

What is the quickest way to reduce it?

Cache whole pages. For pages that are the same for every visitor, the server should not rebuild them on each request.

Why does Docket report that pages are slow the first time?

Docket is usually the first visitor to a page, so it sees a cold cache. It asks again for some of the slowest, and if the second answer is fast it reports a cache in front of a slow server.