Time to First Byte is the wait before anything happens. Until the first byte of HTML arrives, the browser cannot discover your CSS, your images or your fonts, so every other loading metric is pushed back by the same amount. A slow TTFB makes a good Largest Contentful Paint very hard to reach. This guide shows how to measure where your TTFB goes and fix each part, from redirects to the database.
Key takeaways
- Google treats a TTFB of 0.8 seconds or less as good and over 1.8 seconds as poor, at the 75th percentile of real visits.
- Caching full HTML responses is usually the biggest single TTFB improvement, because the server no longer has to build each page.
- Configure your cache or CDN to ignore marketing parameters such as gclid and utm_source, or visitors from ads may get slow cache misses.
- Remove redirect chains and use a CDN that serves HTML from the edge to cut the round trips caused by network distance.
What TTFB includes
TTFB is measured from the start of navigation until the first byte of the response arrives. It covers several phases:
- Redirects (if the URL redirects before reaching the final page)
- Service worker startup (if the site uses one)
- DNS lookup
- TCP connection and TLS negotiation
- Request and server processing, until the first response byte comes back
Google's guidance treats 0.8 seconds or less as good and over 1.8 seconds as poor, at the 75th percentile of real visits. TTFB is not a Core Web Vital itself, but it eats directly into your 2.5-second LCP budget.
Lighthouse has a separate, stricter audit, "Reduce server response times", that flags documents when the server response alone takes more than 600 ms. That figure excludes DNS and redirects, which is why it is lower than the 800 ms TTFB guideline.
Step 1: Measure it properly
Quick check with curl
curl breaks a request into its phases. Run it a few times, because the first request may hit a cold cache:
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://www.example.com/
If ttfb minus tls is large, the server is slow to generate the page. If dns or connect is large, the problem is network distance or DNS.
In the browser
In Chrome DevTools > Network, click the HTML document and open the Timing tab. "Waiting for server response" is the server's processing time. Redirect time shows separately at the top.
In the field
PageSpeed Insights shows TTFB from real Chrome users (CrUX) when your site has enough traffic. Field TTFB is often worse than your own tests, because real visitors are farther away, on mobile networks, and may arrive through redirecting ad or email links.
Find out what the server is doing
Add a Server-Timing header to break server time into parts. Chrome DevTools displays it in the Timing tab:
Server-Timing: db;desc="Database";dur=121.3, render;desc="Template render";dur=212.2
In PHP:
<?php
$start = hrtime(true);
// ... run database queries ...
$dbMs = (hrtime(true) - $start) / 1e6;
header('Server-Timing: db;desc="Database";dur=' . round($dbMs, 1));
On WordPress, the Query Monitor plugin shows slow queries and which plugin caused them. Application performance monitoring (APM) tools give the same insight on any stack.
Step 2: Cache the HTML
The fastest page is one the server does not have to build. If every request runs PHP, loads the framework and queries the database, caching full HTML responses is usually the biggest single TTFB improvement available.
Options:
- Application or plugin page cache (for example a WordPress caching plugin), writing static HTML to disk.
- Server-level cache such as Nginx FastCGI cache or Varnish, which serves cached pages without touching PHP at all.
- CDN edge caching of HTML, which serves the page from a location near the visitor.
A basic Nginx FastCGI cache for a PHP site, bypassing logged-in users and carts:
# In the http block
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=pages:50m
inactive=60m max_size=1g;
map $http_cookie $skip_cache {
default 0;
~*wordpress_logged_in 1;
~*woocommerce_items_in_cart 1;
~*comment_author 1;
}
# In the PHP location block
fastcgi_cache pages;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache_use_stale error timeout updating http_500 http_503;
add_header X-Cache-Status $upstream_cache_status;
The X-Cache-Status header lets you confirm HIT versus MISS in DevTools. Also skip caching for POST requests and for admin, cart and checkout URLs on your platform.
Watch out for query strings
Most caches treat every unique URL as a separate cache entry. Ad and campaign links add parameters like ?gclid=, ?fbclid= or ?utm_source=, so each visitor from an ad can get a cache miss and a slow, freshly built page. Configure your cache or CDN to ignore marketing parameters in the cache key. Cloudflare, for example, includes the full query string in the cache key by default but lets you change that.
Step 3: Remove redirects
Each redirect adds at least one full round trip before the real page request starts, and often a new connection too.
- Fix internal links that point to
http://, the non-www host, or a URL missing a trailing slash, so they go straight to the final URL. - Collapse chains.
http://example.comtohttps://example.comtohttps://www.example.com/should be one hop, not two. - Give advertisers and email tools the final URL, not a shortened or redirecting one.
- Use HSTS so returning browsers go to HTTPS directly without the HTTP redirect:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Read our HSTS guide before enabling includeSubDomains or preload, since they are hard to undo. For finding chains across a site, see broken links and redirect chains.
Step 4: Reduce network distance with a CDN
If your server is in one country and your visitors are spread worldwide, every round trip (DNS, TCP, TLS, request) carries that distance. A CDN terminates connections at a nearby edge location, often with faster DNS, HTTP/3 and modern TLS.
The big win only comes when the CDN can serve HTML from the edge. Many CDNs cache static files like images, CSS and JS by default but not HTML. Cloudflare, for example, does not cache HTML unless you add a cache rule. See do you need a CDN? for when it is worth it.
Step 5: Speed up the database and application
For pages that cannot be cached (logged-in dashboards, search results, carts), server processing has to get faster.
- Find slow queries with Server-Timing, Query Monitor, or your database's slow query log.
- Add indexes for columns used in
WHEREandJOINclauses of slow queries. - Add a persistent object cache (Redis or Memcached) so repeated queries come from memory.
- Enable OPcache for PHP so scripts are not recompiled on every request.
- Run a current runtime. For PHP, WordPress recommends 8.3 or newer.
- Cut work per request. Remove plugins or modules that run expensive code on every page load.
- Move slow tasks out of the request, such as sending emails or calling third-party APIs, into background jobs.
Step 6: Right-size your hosting
Some TTFB problems are simply resource limits.
Signs hosting is the bottleneck:
- Uncached TTFB is slow even on a simple page
- Response times get much worse at busy times of day
- Your control panel shows CPU or memory limits being hit
- Your server is on another continent from most customers
Moving from crowded shared hosting to a quality managed host or a small VPS with server-level caching often reduces TTFB more than any amount of front-end tuning.
Step 7: Advanced options
- Streaming HTML. Sending the
<head>early, before the rest of the page is ready, lets the browser start fetching CSS sooner. Frameworks with streaming server rendering support this. - 103 Early Hints. The server sends a preliminary response listing critical resources while it builds the page. It helps most when backend processing is slow. Note that it makes TTFB look better than actual server time, so keep measuring the real figure.
- Static generation. For sites that rarely change, pre-building pages to static HTML removes server processing entirely.
Frequently asked questions
What is a good TTFB?
Google's guidance is 0.8 seconds or less at the 75th percentile of real visits, with over 1.8 seconds rated poor. Lighthouse separately flags server response times over 600 ms, which excludes DNS and redirects.
Why is my TTFB fast in tests but slow in PageSpeed field data?
Your tests probably hit a warm cache from a nearby location. Real visitors come from farther away, use mobile networks, arrive via redirecting links, and carry query strings that bypass caches. Test with campaign parameters and from other regions to reproduce it.
Does TTFB affect SEO?
TTFB is not a Core Web Vital, so it is not assessed directly. But it delays every other metric, including LCP, which is part of Core Web Vitals. A slow server also limits how efficiently search engines can crawl a large site.
Will a caching plugin fix a slow TTFB?
For anonymous visitors on cacheable pages, usually yes, often dramatically. It will not help logged-in users, carts or uncached pages, and it will not fix redirects or network distance.
What to do next
Run the curl command against your homepage and a key landing page with a ?utm_source=test parameter added, and see whether TTFB changes. That quickly tells you whether caching, redirects or the server itself is the problem. Then run a free audit to see your server response time in context with your Core Web Vitals, and read improving LCP for the next step after TTFB.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
