How to reduce TTFB (Time to First Byte)

To reduce TTFB, you shorten the time between a browser asking for a page and receiving the first byte of the answer. In practice that means three things: make the server and application generate HTML faster, serve cached HTML so most requests skip that work entirely, and move the response closer to your visitors. This guide shows how to find out which of the three is your bottleneck and what to do about each.

What TTFB measures

Time to First Byte is not a single thing. It is the sum of several phases that happen before any content arrives:

1. Redirects, if the requested URL forwards somewhere else first.
2. DNS lookup, turning your domain name into an IP address.
3. Connection setup, the TCP handshake plus TLS negotiation for HTTPS.
4. Request and server processing, the time your server spends building the response (running PHP, querying the database, rendering templates).
5. The first byte travelling back to the browser.

That is why two sites on identical servers can have very different TTFB: one might be close to its visitors and serve cached pages, the other might sit on another continent and render every request from scratch.

TTFB is not one of the three Core Web Vitals, but it sits underneath all of them. Nothing can render before the first byte arrives, so a slow TTFB pushes back Largest Contentful Paint directly. If your LCP is poor, TTFB is one of the first things to check. The Core Web Vitals guide covers how the metrics relate.

What is a good TTFB?

Google's web.dev guidance on TTFB recommends that most sites aim for a TTFB of 0.8 seconds or less, measured at the 75th percentile of real page loads. Values above 1.8 seconds count as poor.

Two things are worth keeping in mind. First, these numbers describe real users on real networks, including slow mobile connections far from your server. A test from your office next to the data center will look much better than what a visitor on another continent experiences. Second, 0.8 s is a rough guide, not a hard pass mark. Sites that render entirely on the client can tolerate a bit more; server-rendered sites, which covers most WordPress and shop setups, benefit from going well below it.

Measure it and find the slow phase

Before changing anything, measure where the time goes. A quick check from the command line:

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nconnect:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://example.com/

Each value is cumulative, in seconds. Subtract to get the phases:

• connect - dns is the network round trip to the server.
• tls - connect is the HTTPS handshake.
• ttfb - tls is roughly server processing time plus one round trip.

Run it several times, because the first request often pays for a cold cache or a fresh DNS lookup. If ttfb - tls stays high (say, several hundred milliseconds or more) while the network phases are small, your server is the bottleneck. If the network phases are large, distance and connection overhead are the problem.

For real-user numbers, test the page on corewebvitals.page and look at the field data from Chrome users, which is available when your site has enough traffic. In Chrome DevTools, the Network tab shows a timing breakdown for every request: "Waiting for server response" is the server part of TTFB. The guide on measuring website speed explains how to combine these sources without fooling yourself.

Speed up the server and application

If processing time dominates, the fix lives on the origin. Work through these in order, from cheapest to most involved:

Update the runtime

Newer PHP, Node.js or Python versions are often noticeably faster at the same work. Check which version your host runs and whether your CMS and plugins support a newer one.

Add an object cache

WordPress, WooCommerce, Shopware, Magento and Drupal all run many repeated database queries. A persistent object cache such as Redis or Memcached keeps those results in memory between requests. Many managed hosts offer it as a switch.

Find slow queries and plugins

A single plugin that runs an expensive query on every page load can dominate TTFB. Use a profiler or query monitor in a staging copy, deactivate suspects one at a time and measure again. On shops, faceted filters, related-product widgets and live stock lookups are common culprits.

Check server resources

If TTFB is fine at night and bad in peak hours, the server is running out of CPU, memory or PHP workers. More resources or a better hosting plan can be the right call here, and no front-end optimization will fix it.

Cache full HTML pages

Most requests to a typical website are for pages that look the same for every anonymous visitor. Generating them from scratch every time is wasted work. A full-page cache stores the finished HTML and returns it without touching PHP or the database, which usually has the biggest single effect on TTFB.

You can cache at different layers:

• In the application, with a caching plugin or built-in HTTP cache (Shopware and Drupal ship one). The WordPress caching documentation gives a good overview of the options there.
• On the server, with a reverse proxy such as Varnish or an Nginx cache.
• At the edge, on a CDN or edge network, so cached pages are served from a location close to the visitor.

Whichever layer you choose, be strict about what must not be cached: carts, checkout, account pages, logged-in sessions and anything personalized. Those requests should bypass the cache and go to the origin every time. If your pages send sensible Cache-Control headers, every layer can follow them.

Check whether a page actually came from cache by looking at the response headers:

curl -sI https://example.com/ | grep -i -E "cache|age"

A cache that exists but rarely hits does little. Low hit rates usually come from cookies or query strings that make every request look unique, or from cache lifetimes that are too short.

Shorten the distance to visitors

Every round trip between browser and server costs time, and a new HTTPS connection needs several of them before the first byte can flow. If your server is in Frankfurt and a visitor is in Sydney, physics alone adds a noticeable delay to each of those round trips, no matter how fast the server is.

There are two ways to shorten that distance:

• Host close to your audience. If nearly all visitors are in one country, a server in or near that country is the simplest win.
• Serve from an edge network. A CDN terminates connections at a location near the visitor and, when the page is cached there, answers without contacting your origin at all. The guide What is a CDN explains what this can and cannot fix.

An edge network also helps uncached requests a little, because the TLS handshake happens nearby and the edge can reuse a warm connection to the origin. The big gain, though, comes from cache hits.

Remove redirects and connection overhead

Small things add up, especially on mobile networks:

• Avoid redirect chains. http://example.com to https://example.com to https://www.example.com to https://www.example.com/en/ is three extra round trips before anything useful happens. Link directly to the final URL and keep at most one redirect.
• Use HTTP/2 or HTTP/3 and TLS 1.3. They reduce the number of round trips for connection setup and let the browser fetch many resources over one connection.
• Use a fast DNS provider. DNS is part of TTFB for first-time visitors. Anycast or GeoDNS-based providers answer from nearby locations.
• Enable compression. Brotli or gzip for HTML does not change the first byte much, but it shortens the rest of the download that follows it.

How fast.site helps

fast.site sits in front of your existing hosting and targets the network and caching parts of TTFB. You keep your host; you point your domain's nameservers to fast.site, and after verification your traffic runs through its edge network.

The Fast Edge Cache™ stores cacheable pages at the edge. On a cache HIT the response comes straight from the edge without contacting your origin; on a MISS the page is fetched once and stored. Expiry follows your origin's Cache-Control headers or your own rules, and a cache warmer keeps important pages primed. Carts, checkout and logged-in sessions bypass the cache, which the fs-cache header reports as BYPASS. You can check any URL as described in how to check the cache, and the caching docs explain the rules.

GeoDNS routes visitors to the nearest healthy edge, with regions in North America, Europe, Asia-Pacific and South America depending on your plan (see regions). Certificates are issued and renewed automatically.

fast.site does not make a slow database query faster, so origin fixes still matter for uncached pages. The dashboard analytics show TTFB and cache hit ratio, so you can measure the effect on your own site, for example during a free 7-day trial.

FAQ

Does TTFB affect SEO?

TTFB is not one of the Core Web Vitals that Google uses as a page experience signal. It does, however, delay Largest Contentful Paint, which is one of them. Improving TTFB is mostly about better LCP and a faster-feeling site, not about a direct ranking boost.

Why is my TTFB high only on the first visit?

The first request often includes a DNS lookup, a fresh TLS handshake and a cold cache on the server or edge. Later requests reuse connections and hit a warm cache. If first-visit TTFB matters for you (it does for most landing pages), look at DNS speed, redirects and cache warming.

Why is TTFB fine in my test but poor for real users?

Your own test usually runs on a fast connection close to the server, with a warm cache. Field data, as shown on corewebvitals.page or in Search Console, comes from real Chrome users on all kinds of networks and locations, measured at the 75th percentile. The gap often points to distance or to pages that are rarely cached.

Will a CDN fix a slow TTFB?

It fixes the parts caused by distance and repeated page generation, as long as your pages can actually be cached. It will not speed up requests that must reach the origin, such as checkout or logged-in pages. For those, server and application tuning is still needed.