Time to First Byte: Where a WordPress Server Spends Its Time

TTFB includes everything before the response starts: redirects, the DNS lookup, the TCP connection, the TLS handshake and the time the server takes to produce the response. The browser's network panel and tools like WebPageTest show these phases separately. web.dev suggests aiming for a TTFB of 0.8 seconds or less as a rough guide for most sites, measured at the 75th percentile of real visits.

Look at the breakdown first. A long DNS phase points to the DNS provider. Long connection and TLS phases often mean the server is far from the visitor, or that no CDN terminates connections closer to them. An extra redirect, such as http to https and then to www, adds a full round trip each time. Only the waiting phase, sometimes labelled server response, is WordPress and PHP doing work.

Page caching is the biggest single improvement for most WordPress sites, because a cached page is served without running PHP or querying the database. The catch is that your own testing nearly always hits the cache. You visit the page repeatedly, so it is warm, and if you are logged in, many caches bypass you entirely and you see a slow uncached page that visitors never see.

Check the response headers. Most caching plugins, hosts and CDNs add a header that shows a hit or a miss. Test in a private window, logged out, and request a page twice: the first request may be a miss and the second should be a hit. If both are misses, find out why. Common causes are cookies set on every visit, query strings from marketing links, a plugin that marks pages as uncacheable and very short cache lifetimes.

This is the usual explanation for "fast for me, slow for them". Real visitors arrive on pages that have expired from the cache, with campaign parameters, or on a server in another region. Measure what they get, using field data from Search Console's Core Web Vitals report or real-user monitoring, not only lab tests.

When an uncached page is slow, Query Monitor is the quickest way to see why. On a staging copy, or on production for administrators only, it shows the total generation time, every database query with its caller and duration, the hooks that ran and every outbound HTTP request made while building the page.

Sort queries by time and by caller. A plugin running dozens of small queries on every page, or one query taking hundreds of milliseconds, is usually visible within minutes. The components view groups time by plugin and theme, which makes it easier to decide whether to fix, replace or remove something. Measure before and after each change, on the same page and the same conditions.

• Total page generation time and peak memory
• Slowest database queries and the plugin that ran them
• Duplicate queries that could be cached
• Outbound HTTP requests and how long each took

Some of the worst TTFB problems are not in the database at all. A plugin checks a licence server, fetches a social media count, calls a currency API or loads remote fonts on the server side, synchronously, while the page is generated. When that remote service is slow, every uncached page waits for it, and when it is down, pages can hang until the request times out.

Query Monitor's HTTP API calls panel lists these requests with their timing. Move such work out of the page request: fetch the data in a scheduled task, store it in a transient or option, and render from the stored copy. Set short timeouts on any request that must stay synchronous, and make sure the page still renders if the remote service fails.

Some slow queries only appear under real traffic or with a large dataset, so they never show up on staging. Enable the MySQL or MariaDB slow query log on the server for a short period, with a threshold such as half a second, and review what it collects. Repeated entries from the same plugin point to the culprit.

Common causes on WordPress are meta queries that filter on post meta values, which can scan a large table, searches using LIKE with a leading wildcard, and options autoloaded on every request that have grown very large. Fixes range from adding an index for a heavily used meta key, to rewriting the query, to storing the value in a dedicated column or table. Object caching with Redis helps repeated queries but does not fix one bad query. The database optimisation guide and the Redis object cache guide go deeper.

Distance adds time to every round trip, and a new connection needs several of them. A site hosted in the United States serving customers in India pays that cost on every uncached request. Host close to your main audience where you can, and if your customers are spread across regions, put a CDN in front of the site so connections terminate nearby.

A CDN that only caches images helps less than one that can also cache HTML for logged-out visitors. If you enable full-page caching at the edge, make sure it is purged when content changes, and that logged-in users, carts and checkout bypass it. The Core Web Vitals checklist and the hosting comparison cover the wider picture, and the WordPress performance and maintenance service explains how I approach slow sites.