Time to First Byte, or TTFB, measures how long it takes from the moment your browser sends a request to the moment it receives the very first byte of data back from the server. This guide explains what it means and what affects it.
What TTFB measures
When you type a web address and press Enter, your browser sends a request to the server. The server then processes that request — looking up the page, running PHP code, querying the database — and starts sending the response back.
TTFB is the time between sending the request and receiving the first byte of the response. It does not measure how long the full page takes to load, just how quickly the server starts responding.
Think of it like ordering food at a restaurant. TTFB is the time between placing your order and seeing the waiter start walking towards you with the first plate. The total meal delivery time is separate.
Why TTFB matters
A slow TTFB delays everything else. The browser cannot start rendering the page, downloading images, or loading stylesheets until it receives that first response from the server. If the server takes two seconds to start responding, your page cannot possibly load in under two seconds, no matter how well everything else is optimised.
Google also considers server response time when evaluating page performance.
What Web60 targets
Web60 targets a TTFB under 200 milliseconds for pages that are in the cache. This means the server begins sending the page to the visitor's browser in less than a fifth of a second.
For pages that are not in the cache — such as the first visit after a cache clear or pages for logged-in users — the TTFB will be higher because the server needs to build the page from scratch.
Common causes of high TTFB
If your TTFB is consistently above 600 milliseconds, there are a few likely causes:
Page not in cache
Full-page caching is the single biggest factor in TTFB. When a page is cached, the server delivers a pre-built HTML file almost instantly. When it is not cached, the server must run WordPress, execute all plugin code, and query the database. Web60 enables page caching by default, but certain pages may bypass the cache — for example, pages with items in a shopping cart or pages viewed by logged-in users.
Slow database queries
Some WordPress configurations accumulate large amounts of data that the database loads on every page request. This is called autoloaded data. When the autoloaded data grows too large — typically above 1 MB — every page request slows down because the database is doing extra work.
Too many active plugins
Each active plugin adds PHP processing time to every uncached page load. A large number of active plugins can push TTFB higher, particularly on the first load after a cache clear.
What you can do
- Keep the cache active. Web60 enables page caching by default. Avoid plugins or settings that disable it.
- Reduce active plugins. Fewer plugins mean less processing time per request.
- Check autoloaded data. If you suspect this is an issue, contact support and we can check the autoloaded data size for your site.
- Clear and rebuild the cache. After making changes to your site, clear the cache so the updated pages are cached fresh.
Frequently asked questions
What is a good TTFB for a WordPress site?
Under 200 milliseconds is a good target for cached pages. For uncached pages, under 600 milliseconds is reasonable. Web60 sites typically achieve under 200ms for cached content.
How can I check my site's TTFB?
Open your site in Chrome, press F12 to open Developer Tools, click the Network tab, and reload the page. Click on the first request (your page URL) and look at the Timing section. The 'Waiting for server response' value is your TTFB.
Why is my TTFB sometimes fast and sometimes slow?
The most common reason is cache state. The first visit after the cache is cleared will be slower because the server has to build the page from scratch. Subsequent visits to the same page will be much faster because the cached version is served.
Last updated: 4 April 2026