Short answer: Time to first byte (TTFB) is the time between asking for a page and the moment the first byte of the response begins to arrive. Every other loading metric comes after it, so a slow server holds back the whole page.
What adds up to TTFB
TTFB is the sum of five request phases, so a delay in any of them shows up in it.
| Phase | What happens | What shortens it |
|---|---|---|
| Redirects | The browser is sent to another address before it reaches the page | Links to the final address, with https and the right slash |
| Service worker startup | If the site has a service worker, it starts before the request | Serving documents that rarely change from its cache |
| DNS lookup | The browser looks up the server’s address | A CDN, which usually resolves DNS very fast |
| Connection and TLS | The browser opens a secure connection to the server | A CDN with modern TLS, such as TLS 1.3 |
| Request | The server prepares the response until the first byte arrives | Good hosting, a page cache and fewer heavy plugins |
From web.dev, “Time to First Byte (TTFB)” and “Optimize Time to First Byte”, read November 3, 2026.
What a good TTFB is
web.dev rates a TTFB of 0.8 seconds or less as good and more than 1.8 seconds as poor. The aim is a server fast enough for the 75th percentile of visitors to get a good First Contentful Paint (FCP).
Because TTFB isn’t a Core Web Vital, missing that mark isn’t a problem as long as it doesn’t hold back the metrics that matter.
Our Core Web Vitals guide covers LCP, INP and CLS.
How to measure TTFB
web.dev recommends field data as the main source, because it includes redirects, while lab tools often test the final address and miss that delay. PageSpeed Insights shows field and lab data for public sites in the Chrome User Experience Report.
Lighthouse’s server response time audit leaves out DNS lookup and redirects, so it covers only part of TTFB. To check whether a cache hides a slow server, test less visited pages or add a URL parameter that gets an uncached copy.
Our PageSpeed Insights guide shows where to find each figure.
How to lower TTFB
- Start with field data in PageSpeed Insights and use lab tools to find the cause.
- Check that your hosting gives your site enough memory and keeps its server software up to date.
- Cache pages so the server doesn’t build each one on every visit, and keep a URL parameter that skips the cache for tests.
- Make sure campaign tags such as utm don’t split the cache into copies of the same page.
- Link to the final address, with https and the right slash, and give advertisers and newsletters that address.
- Put a CDN in front of the site for fast DNS, modern TLS and copies close to your visitors.
- On WordPress, review the number and quality of your plugins and your theme.
Our 301 redirect guide explains when a redirect is worth keeping.
Our own TTFB
We read 12 of our pages 5 times each on November 3, from one of our other servers. A visitor far away or on a phone network will see more. From our page cache, the median TTFB was 41 milliseconds and the slowest read 58.
With a URL parameter that skips the cache, the same pages took a median of 986 milliseconds, up to 1,279. That is the time WordPress needs to build a page, between good and poor without the cache. Connection and TLS took 31 milliseconds of each read.
Links with campaign tags still get the cached copy: our cache ignores utm parameters and click ids such as gclid and fbclid, and 15 tagged reads came back from it at a median of 45 milliseconds.
A redirect from http or www takes about 4 milliseconds on our web server. A link without the final slash takes about 377, because WordPress builds that redirect, so we always link with the slash.
Before you call your TTFB fixed
- Field TTFB in PageSpeed Insights is 0.8 seconds or less.
- A test that skips the cache shows how long your server needs.
- Less visited pages are fast too, not only the home page.
- Campaign tags don’t skip your page cache.
- Your links and ads point to the final address.
- Any redirect left is one hop, not a chain.
RememberTTFB is the wait before anything arrives: redirects, DNS, the connection and your server’s own work. A cache can hide a slow server, so test without it too, and fix the redirects you control first.
If you want us to check your site’s speed and redirects, see our technical SEO service.
Quick answers about TTFB
Does TTFB matter more for single-page apps?
Yes. When the first HTML needs JavaScript to fill in the content, as in single-page apps, web.dev says the lowest possible TTFB matters most, so the browser can start sooner. A site built on the server can have a higher TTFB and still a better FCP and LCP.
Does a CDN lower TTFB?
Usually. A CDN serves copies from servers closer to your visitors, tends to resolve DNS very fast and uses modern protocols such as HTTP/2 or HTTP/3 and TLS 1.3. Personalized content isn’t suited to edge caching, so those requests still travel to your server.
Do 103 Early Hints improve TTFB?
They count as the first bytes, so TTFB can look fast while the server is still building the page. web.dev says they help most on sites with long backend time and little on static sites, and suggests measuring the real server time with Server-Timing. They also make TTFB harder to compare across platforms.
Does WordPress slow down TTFB?
It can. web.dev says WordPress performance depends on the number and quality of plugins and on the theme. On our own WordPress site, building a page took a median of 986 milliseconds, which is why we serve pages from a cache.
Do redirects count in TTFB?
Yes, redirect time is the first phase of TTFB. Besides removing redirects on your own site, web.dev suggests the HSTS header, which tells browsers to go straight to https on later visits instead of being redirected from http.
Sources
Read on November 3, 2026. web.dev: Time to First Byte (TTFB) and Optimize Time to First Byte. Our own case: 12 of our pages, November 3, 2026.