You click a link to your own site and, for a moment, nothing at all happens. The tab shows its loading spinner, the old page stays on screen, and then everything arrives in a rush. That blank pause before anything starts is, roughly, your time to first byte.
If you have seen “TTFB” in a speed report and wondered what it covers, the sections below cover which steps it is made from, how it relates to Core Web Vitals, and how to measure it in a way that tells you something useful. Reducing it is a separate topic, linked at the right point.
What is time to first byte, exactly?
Time to First Byte (TTFB) is the time from when the browser starts going to a page until the first byte of the page’s HTML arrives back. Everything the visitor eventually sees, every image, font and line of text, depends on that HTML. Until the first byte turns up, the browser has nothing to work with.
The name sounds like it measures only your server, and that is the most common misunderstanding. In fact TTFB bundles together several steps, some of which happen before your server is even contacted.
TTFB explained step by step
Picture a visitor in Pune tapping a link to your site, hosted on a server in another city or another country. Before the first byte of HTML reaches them, these things happen in order:
- Redirects. If the link points to
http://yoursite.comand your site lives athttps://www.yoursite.com, the browser first gets told to go elsewhere, perhaps twice. Each redirect is a full extra trip, and it all counts towards TTFB for the final page. - DNS lookup. The browser has to turn your domain name into a server address. If it has not looked it up recently, it asks a DNS server, which may ask others.
- Connection. The browser opens a network connection to that address. The further away the server, the longer each round trip takes.
- TLS negotiation. For an HTTPS site, browser and server agree on encryption before any page data is sent. That takes more round trips.
- Request and server work. The browser sends the request. Your server then has to produce the page: on WordPress that may mean running PHP, querying the database and assembling the HTML, unless a ready-made cached copy can be sent.
- First byte travels back. The first part of the response crosses the network to the visitor.
So TTFB is really “redirects + DNS + connection + encryption + server thinking time + travel time”. A long TTFB can come from any of these, and the cure is different for each.
So if a colleague asks “what is time to first byte?”, the honest one-line answer is: the wait before the page’s HTML starts arriving, made up of several steps, only one of which is your server.
Is TTFB a Core Web Vital?
No. Google treats TTFB as a diagnostic metric rather than one of the Core Web Vitals. The three Core Web Vitals are LCP, INP and CLS, introduced in our overview of Core Web Vitals.
TTFB still matters because it sits at the very start of loading. Largest Contentful Paint cannot happen before the HTML arrives, so a slow TTFB eats directly into your LCP budget. When a large share of a slow LCP is spent before the HTML even arrives, compressing photos will barely dent it.
As a rough guide, web.dev suggests most sites should aim for a TTFB of 0.8 seconds or less at the 75th percentile. Treat that as a pointer, not a pass or fail line. Some sites with a slightly higher TTFB still have good LCP, and some with a low TTFB are slow for other reasons.
How to measure it
There are several ways, and they answer slightly different questions.
In Chrome DevTools, for one page and one visit
- Open the page in a private window, open DevTools and go to the Network panel.
- Reload. Click the first row, which is the HTML document itself.
- Open the Timing tab. You will see the steps broken out: queueing, DNS lookup, initial connection, SSL, request sent, waiting for server response, and content download.
The “waiting for server response” line is the part your server and hosting most directly control. The lines above it are DNS and connection costs. This breakdown is the quickest way to see which step is large.
In PageSpeed Insights, for real visitors
If your site has enough traffic, the field data section at the top shows TTFB from real Chrome visits over 28 days. This is the best picture of what your visitors actually experience, including those on slow mobile networks and far from your server.
In waterfall tools
GTmetrix and WebPageTest show the first request in a waterfall chart, with coloured segments for DNS, connection, TLS, waiting and download. They also let you choose test locations, which is how you see what TTFB looks like for visitors in another country. Reading the chart itself is explained in how to read a waterfall chart row by row.
From the command line
If you are comfortable with a terminal, curl can report timings for a single request:
curl -o /dev/null -s -w "dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} first-byte %{time_starttransfer} total %{time_total}\n" https://www.example.com/
Each figure is measured from the start, so they add up as you go along. It is handy for repeating the same request many times and seeing how much the server time varies.
Making sense of the result
A single TTFB number is easy to misread. Some checks before drawing conclusions:
Cached or not?
Most WordPress sites use some form of page cache. A cached page is sent ready-made and has a much lower server time than one built from scratch. Test the same page two or three times. If the first request is slow and the next ones fast, you are seeing a cache being filled. Logged-in users, cart and checkout pages, and search results are typically not cached at all, so their TTFB will be higher by design.
Where are you testing from?
If you are in the same city as your server, your connection steps are short. A visitor on another continent pays for the distance on every round trip, and there are several round trips before the first byte. If your audience is spread out, a CDN can shorten some of those trips; what a CDN is and does is covered in our CDN explainer.
Is DNS the slow step?
A DNS lookup that takes noticeably long shows up as a big first segment in DevTools or a waterfall. It tends to affect first visits more than repeat ones, since results are remembered for a while. DNS has its own considerations, discussed in how DNS lookups affect page speed.
Is there a redirect chain?
Look at the Network panel with “Preserve log” ticked. If you see one or more 301 or 302 responses before the real page, each one is adding to the delay. Links in ads, emails and social profiles are frequent sources, because they were set up years ago with an old address.
Is the server itself slow?
If DNS, connection and TLS are all short but “waiting for server response” is long, especially on uncached pages, the time is being spent producing the page. That points at hosting resources, slow database queries, heavy plugins or external calls made while the page builds. How to tackle that is the subject of our post on reducing server response time.
What to write down before you change anything
- TTFB for three or four important pages, cached and uncached, from DevTools.
- The breakdown into DNS, connection, TLS and waiting for each.
- Field TTFB from PageSpeed Insights, if available.
- Results from at least one test location near most of your customers and one further away.
- The date and time of testing, since servers can be slower at busy hours.
With that baseline you can tell whether a later change, a new host, a CDN, a caching setting, made a real difference or just a lucky test run.
TTFB is one early link in a long chain. For how it fits alongside images, scripts and everything else, see the site speed guide.
Frequently asked questions
Why is my TTFB much higher in PageSpeed Insights than in my own browser?
Your browser may already have a connection to the server, a cached DNS result and possibly a cached copy of the page, and you may be close to the server. A test tool or a real visitor elsewhere starts from scratch, possibly from far away, on a slower network. Field data in particular includes many visitors on mobile connections.
Does a CDN reduce TTFB on a WordPress site?
It can reduce the connection and encryption part for visitors far from your server, because they connect to a nearby CDN location. Whether it reduces the server part depends on whether the CDN caches your HTML pages or only static files like images. If it only caches static files, each page request still goes back to your server.
Is a low TTFB enough for a fast site?
No. A low TTFB means the page starts arriving quickly, but the visitor still has to wait for images, stylesheets, fonts and scripts before the page looks ready and responds to taps. Many slow sites have a perfectly reasonable TTFB and lose all their time afterwards, in page weight and render-blocking files.
Should I measure TTFB on the homepage only?
Test a few different page types. The homepage is often the most heavily cached, so it can look better than product pages, blog posts or search results. Pages that are never cached, such as the cart and checkout on a store, show what your server can do without help and are worth checking separately.
When the “waiting for server response” line is the big one, the cause usually lies in hosting or caching rather than in the page. Our website speed optimisation service checks how quickly your server answers as well as what the page loads afterwards.
Next in this series: First Contentful Paint Explained: FCP vs LCP
