← Back to blog

08 Oct 2026

TTFB in WordPress: what it is and how to actually lower it

TTFB in WordPress: what it is and how to actually lower it

When someone says their WordPress "takes a while to start up", they are almost always talking about TTFB: the time to first byte. It is the metric that depends most on your server and your caching strategy, and the one that is least fixed by installing another theme.

What TTFB really measures

TTFB is the time that passes from when the browser requests a page until it receives the first byte of the response. It includes DNS resolution, the TLS connection, the wait while the server processes the request, and the trip back. In a WordPress without caching, the heaviest part is usually the server side: starting PHP, loading the core and plugins, querying the database, and building the HTML.

A high TTFB delays everything else: the browser cannot start downloading CSS, images, or scripts until it has the HTML. That is why it also affects metrics such as LCP.

The most common causes of a slow TTFB

  • Every visit runs full PHP. Without page caching, WordPress rebuilds the same page over and over, even if it has not changed.
  • Heavy database queries. Plugins that store many autoloaded options or make queries without an index.
  • Too many plugins that load on every request, even on pages where they do nothing.
  • Overloaded shared hosting, where your site competes for CPU with others.
  • Outdated PHP version. Supported versions receive performance improvements and security patches; those that no longer have support do not.

How to measure it without fooling yourself

Measure several times and from different points. A single test can land right when the server has a spike. These are practical steps:

  • Open the browser developer tools, Network tab, and look at the waiting time ("Waiting") of the first request for the document.
  • Test in a private window, so you do not carry session cookies that disable caching.
  • Compare a cached page with one that is not (for example, a search parameter). The difference tells you how much work your cache avoids.
  • Repeat the test at different times.

The underlying solution: do not run PHP if it is not needed

The most direct way to lower TTFB is to serve an already generated HTML file instead of rebuilding the page on every visit. That is the approach of cache.lat: it saves the page as a static file and delivers it without going through the entire WordPress cycle. You can see the details of the mechanism in how cache.lat works, and the behavior with cookies, parameters, and logged-in users in the documentation.

An important detail: a cache only helps if it is actually being used. If your TTFB is still high on public pages, check that there are no cookies that exclude the page, that the URL does not carry parameters that take it out of the cache, and that the page has been generated at least once.

What else you can optimize

  • Use a PHP version with active support and update WordPress and plugins.
  • Uninstall plugins you do not use instead of just deactivating them.
  • Review the autoloaded options in the database if the site is years old.
  • Avoid synchronous external calls at the start of every page (fonts, widgets, third-party APIs).

Conclusion

TTFB is a good thermometer: if it is high on public pages, your server is working too hard. Measure it methodically, remove what is unnecessary, and cache what does not change. If you want to try static caching on your site, see the product at TuNegocioEnLinea.net or write to us from the contact page.


Comments (0)

free speed test

How much faster would your WordPress be with cache.lat?

Measure your site for free and see an estimate of the improvement. No account needed.

Test my site →
Speed up your site — start free: Try for free
New on the blog: TTFB in WordPress: what it is and how to actually lower it Read it →