TTFB, Time to First Byte, is the time from the browser asking for a page until the first byte of the response comes back. It shows how long the customer waits before anything can be shown at all, and on a WordPress store it’s often the number that reveals the server is taking too long to build pages.
This guide covers what TTFB measures, how to measure it properly, where the time usually goes in WordPress, and what to do first to reduce it.
What TTFB measures
TTFB is the sum of several things: the domain lookup, the connection and encryption, any redirects, and the time the server spends making the page. On a WordPress site, the last part is often the biggest when the page doesn’t come from a cache.
According to Google’s TTFB guidance on web.dev, most sites should aim for 0.8 seconds or less for 75% of visits, and over 1.8 seconds counts as poor. TTFB isn’t one of the Core Web Vitals itself, but it comes before everything else: a high TTFB makes it hard to get the rest of the page on screen quickly.
How to measure it properly
The same page can have very different TTFB depending on whether it comes from the cache. So measure several situations, not just the home page:
- Open your browser’s developer tools (F12), go to Network, and click the page itself at the top of the list. Under Timing, you’ll see the wait for the server’s response.
- Measure a product page in a private window, and reload it. The first view may be uncached; the second should come from the cache.
- Add a product to the cart, and measure the product page, the cart and checkout again. Now they don’t come from the cache.
- If the store has enough traffic, PageSpeed Insights also shows TTFB from real users. That’s the number that counts, because it covers your customers’ connections and devices.
Where the time goes
| High TTFB on | Typical cause |
|---|---|
| Every page, cached ones too | Distance to the server, slow DNS or connection, redirects, or a cache that isn’t being hit |
| Only uncached pages | PHP, plugins, the database, calls to other servers |
| Only when there are many visitors | Too few PHP processes, so requests queue |
| Only sometimes, with no pattern | Background jobs and WP-Cron running on top of visits |
High TTFB on cached pages
If the page comes from a cache and TTFB is still high, the problem is in front of WordPress. First check that the cache is actually being hit: many caches skip pages with cookies or parameters in the address, such as those from campaign links, and then every page is built from scratch anyway. How to check is in our guide to WooCommerce caching.
If the cache is being hit, look at redirects (from http to https, with or without www) and the distance to the server. If the server is far from your customers, a CDN that also caches pages can help on the cached pages.
High TTFB on cart, checkout and the admin
The pages that can’t be cached show how fast the server can build a page. If they’re slow, the time is in WordPress itself, and the typical causes are:
- No object cache: The database is asked the same things on every page view. The setup is in our guide to the Redis object cache.
- A heavy plugin: A plugin that runs heavy queries or waits on other servers. Here’s how to find the slow plugin.
- A heavy database: Large autoloaded options and tables that have grown. See the guide to autoloaded options that have grown too large.
- The server: An old PHP version, too little memory, or too few PHP processes for the visitors arriving at the same time.
What to do first
- Measure TTFB with and without the cache, so you know whether the problem is in front of WordPress or in it.
- Fix redirects, and check that the page cache is hitting the pages it should.
- Turn on an object cache if the store doesn’t have one.
- Find the plugins and queries that use the time on the uncached pages.
- Look at the server last, once you know how much it needs to handle.
The full step-by-step troubleshooting of a slow store is in our guide to a slow WooCommerce store.
Frequently asked questions
Is a TTFB of one second bad?
It depends on the page. On a cached product page, it’s high. On checkout, which is built from scratch for every customer, it’s a realistic starting point, but still worth bringing down. Always compare the same kind of page.
Does a CDN help TTFB?
On pages the CDN is allowed to cache, yes, because the response comes from a server closer to the customer. On cart, checkout and My account, no: they still have to be built on your own server.
Want help?
A high TTFB tells you something takes too long, but not what. If you’d like us to find out in your store, read about optimizing a slow WooCommerce store. We take a free look at your store first and tell you what it will take.