# Reduce initial server response time on WordPress: find and fix a slow TTFB

> How to reduce initial server response time on WordPress: check that the page cache is really hit, then find what makes uncached pages slow (plugins, queries, autoloaded options, outbound calls, wp-cron, PHP workers).

Updated 2026-09-26 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/wordpress-slow-server-response-time

To reduce initial server response time on WordPress, first make sure visitors actually get pages from a page cache: a cached page should answer in 100–300 ms from nearby. If it does not, the cache is missing, bypassed or fighting a second cache. Then find what makes uncached requests slow, which on WordPress is almost always one of a few things: a plugin running slow database queries or calling an external service, oversized autoloaded options, wp-cron jobs running during visits, too few PHP workers, or an old PHP version. Hosting is the last suspect, not the first.

This guide is for WordPress owners and developers who see "Reduce initial server response time" in PageSpeed Insights, or a slow time to first byte (TTFB) in a report. It goes from measuring to the WordPress-specific causes and fixes. For TTFB in general, read [TTFB: what a slow server looks like](https://getreport.app/guides/ttfb-what-a-slow-server-looks-like); for the free fixes on a cheap hosting plan, see [server response time on shared hosting](https://getreport.app/guides/server-response-time-on-shared-hosting).

## Quick answer

- **Lighthouse's audit fails above 600 ms** of server time for the page; Google rates real-visitor TTFB good at 0.8 s or less.
- **Check the cache first:** test logged out, twice, and look for a cache hit header. No hit means no cache, a bypass or two caches in conflict.
- **Watch for cache bypasses:** logged-in cookies, WooCommerce session cookies, query strings and pages excluded by mistake.
- **Profile uncached pages with Query Monitor:** slow queries, queries per plugin and outbound HTTP calls.
- **Trim autoloaded options;** Site Health warns above 800 KB.
- **Move wp-cron to a real cron job** if TTFB is slow at random.
- **Use current PHP, OPcache and an object cache,** then judge the host.

## What "reduce initial server response time" measures

The Lighthouse audit, shown in PageSpeed Insights under diagnostics, measures how long the server took to answer the request for the page's HTML, excluding DNS and the connection. It flags anything over 600 ms. On WordPress, that is the time PHP spends starting, loading WordPress, the theme and every active plugin, running the database queries for the page and building the HTML, unless a page cache answers before PHP runs at all.

The real-visitor number is TTFB from the Chrome UX Report, which also includes the network, redirects and the handshakes. Google rates it good at 0.8 s or less and poor above 1.8 s. The two often differ: a 300 ms server time can sit behind a 1.1 s TTFB for visitors on another continent.

> **Check: Server response time.** Lighthouse flags a first byte slower than 600 ms. Caching and hosting fix this for most CMS sites.
>
> 1. Enable full-page caching (WordPress: WP Rocket, LiteSpeed Cache, WP Super Cache; or your host's server cache).
> 2. Use a CDN and keep database queries out of the request path.

> **Check: Real-user Time to First Byte.** How long real visitors wait for the server's first byte, including their network. Google's threshold for "good" is 800 ms.
>
> 1. Cache pages and use a CDN close to your visitors; see the TTFB finding above.

## Step 1: measure it properly

> **Free tool:** [TTFB test: check your time to first byte](https://getreport.app/tools/ttfb-test): Free TTFB test: measure time to first byte from Frankfurt, in a Lighthouse run and from real Chrome users, plus the redirects before the page. No sign-up.

The TTFB test requests the page from our location in Frankfurt with a fresh connection, lists every redirect hop, and shows Lighthouse's server response time and real visitors' TTFB beside it. Run it three times on a public page that should be cached, in quick succession:

- **Consistently fast (under 300 ms):** the cache works. If PageSpeed Insights still flags the audit, its test hit a cold cache or a different URL variant; test the exact URL it used.
- **First slow, then fast:** the cache works but expires or gets purged too often.
- **Consistently slow:** visitors are not getting cached pages. Go to step 2.
- **Random:** background work or an overloaded server. Steps 5 and 6.

From a terminal, compare a cached request with one that bypasses the cache, and read the headers:

```bash
# Cached path: run twice, the second should show a cache hit
curl -s -o /dev/null -D - -w 'ttfb %{time_starttransfer}s\n' https://example-shop.hr/ | grep -iE 'cache|age|ttfb'
# Uncached path: a query string most caches do not serve from cache
curl -s -o /dev/null -w 'ttfb %{time_starttransfer}s\n' 'https://example-shop.hr/?nocache=1'
```

The difference between the two is what your page cache saves. The uncached number is what logged-in users, the cart, search and every cache miss pay.

> **Check: No redirects before the page.** Every redirect is a full round trip before the browser can even ask for the page. http → https → www → trailing slash can easily add a second on mobile.
>
> 1. Link straight to the final URL everywhere (menus, ads, social profiles).
> 2. Collapse chains: redirect http and non-www directly to the final https URL in one hop.

## Step 2: make sure the page cache is really hit

Most slow WordPress TTFBs are a cache that exists but is not serving pages. Check each of these:

**Is there exactly one page cache?** A host cache plus a caching plugin, or two caching plugins, often means neither caches properly: one purges the other, or each thinks the other is in charge. Pick one. [Why two caching plugins break things](https://getreport.app/guides/two-caching-plugins-why-it-breaks-and-which-to-keep) shows how to choose.

> **Check: One caching layer is active.** Two caching or optimisation plugins fight over the same files: double minification breaks scripts, and stale pages are served from whichever cache wins.
>
> 1. Keep one caching plugin (the one your host recommends) and deactivate the other.
> 2. If the host provides server-side caching, use only its plugin and a separate image optimiser if needed.

**Does the response say "hit"?** Look for `x-litespeed-cache: hit`, `x-cache: HIT`, `cf-cache-status: HIT`, a plugin's own header or an HTML comment at the bottom of the page source. `miss` on every request, or no header at all, means pages are built every time.

**Is the visitor bypassing the cache?** Page caches skip visitors with certain cookies or URLs, on purpose:

- **Logged-in users** always bypass it. Test in a private window.
- **WooCommerce cookies.** Once a visitor adds to cart, `woocommerce_items_in_cart` and the session cookie make the cache skip them, which is correct for the cart but slows every page they view afterwards. See [WooCommerce caching for cart, checkout and account pages](https://getreport.app/guides/woocommerce-caching-cart-checkout-and-account-pages).
- **Query strings.** Links from newsletters and ads carry `utm_source`, `gclid` or `fbclid`. Many caches ignore common tracking parameters by default; others treat every new query string as a new page. Check your cache's query-string setting, because campaign traffic is often the traffic you care about most.
- **Commenters.** WordPress sets a comment author cookie after someone comments, and many caches bypass it.

**Are too many pages excluded?** Look through the cache's exclusion list: only cart, checkout, account and similar pages should be there. A wildcard added once to fix a single page can exclude a whole section.

**Does the cache stay warm?** A lifetime of one hour means most pages on a small site are cold when visitors arrive. Set 12–24 hours with purge on update, and turn on preloading if the cache offers it.

## Step 3: find what makes uncached pages slow

Even with a working cache, some requests are always uncached: the cart and checkout, search, logged-in users, the first visit after a purge, and the REST and AJAX calls that pages make. Their speed depends on WordPress itself.

Install **Query Monitor**, open a slow page while logged in, and read:

- **Overview:** the total page generation time and database query time.
- **Queries by Component:** how many queries and how much time each plugin and the theme cost. One plugin with hundreds of queries or seconds of time is your target.
- **Slow Queries:** individual queries over the threshold, with the plugin that ran them. Unindexed searches in `wp_postmeta` on large shops are a classic.
- **HTTP API Calls:** requests WordPress made to other servers while building the page. Licence checks, feeds and remote APIs can each add seconds, and wait for a timeout if the remote is down.

Remove, replace or reconfigure what you find, and re-measure. Deactivate Query Monitor afterwards. The detector below shows what each plugin loads in the browser, which is a different cost from its server time but often points at the same plugins:

> **Free tool:** [WordPress theme and plugin detector](https://getreport.app/tools/wordpress-plugin-checker): Free WordPress theme and plugin detector: see the theme, page builder and plugins a site uses, what each plugin costs in kilobytes and which are abandoned.

> **Check: WordPress plugin weight.** Every active plugin can add scripts and styles to every page, whether the page uses them or not. A slider or a form builder can weigh more than the rest of the site together.
>
> 1. Deactivate plugins the site does not use; for the heavy ones in the table, check whether a lighter alternative exists.
> 2. Load plugin assets only where needed with a performance plugin (Perfmatters, Asset CleanUp) or the plugin's own "load on demand" setting.

## Step 4: autoloaded options

Every WordPress request loads all options marked "autoload" from the `wp_options` table into memory, before any page is built. Plugins store settings there, and many leave them behind when they are deleted. On an older site the autoloaded total can reach several megabytes, which slows every uncached request.

Since WordPress 6.6, Tools → Site Health warns that "autoloaded options could affect performance" when the total exceeds 800 KB, and large options are no longer autoloaded by default. To fix it, find the largest autoloaded options and switch autoload off for the ones that belong to deleted plugins or are only needed in the admin. The Performance Lab plugin from the WordPress Performance Team adds a table of autoloaded options to Site Health; with WP-CLI, `wp option list --autoload=on --fields=option_name,size_bytes` lists them (check the flags for your WP-CLI version). Take a database backup first.

## Step 5: background work during visits

When TTFB is fine most of the time and very slow now and then, WordPress is probably doing background work during a visitor's request:

- **wp-cron.** WordPress runs scheduled tasks (publishing, e-mails, backups, plugin clean-ups) triggered by page views. Set `define('DISABLE_WP_CRON', true);` in `wp-config.php` and run `wp-cron.php` from a real cron job every five minutes. [WP-Cron and scheduled tasks](https://getreport.app/guides/wp-cron-and-scheduled-tasks) has the setup for common hosts.
- **admin-ajax.php and the Heartbeat API.** Editors with the admin open send Heartbeat requests regularly, and some plugins make AJAX calls on every front-end page view. Each one is an uncached PHP request competing for the same workers. On shops, [WooCommerce cart fragments](https://getreport.app/guides/woocommerce-cart-fragments-the-ajax-call-on-every-page) is the usual one.
- **Bots.** Aggressive crawlers hitting uncached URLs (search, filters, feeds) use up PHP workers. Your access logs show them.

> **Check: No cart-fragments request on this page.** cart-fragments.js fires a wc-ajax=get_refreshed_fragments request to keep the mini-cart count fresh. Since WooCommerce 7.8 it loads only with the Mini-Cart widget or block; here it still loads on a page that is not the cart, often because a theme or plugin enqueues it. The request bypasses the page cache, so every visit costs a PHP request, and it delays the page for a feature most pages do not show.
>
> 1. Disable cart fragments on pages that are not the cart or checkout. WooCommerce has no setting for it: use the "Disable cart fragments" option in Perfmatters or a similar performance plugin, or a small snippet that dequeues wc-cart-fragments outside the cart, checkout and account pages.
> 2. If the header shows a live cart count, load the count from a lightweight endpoint on cart changes only.

## Step 6: PHP version, workers and object cache

Three server settings decide how quickly uncached WordPress requests run:

- **PHP version.** Newer PHP versions run WordPress faster, and old ones no longer get security fixes. Use the version the WordPress requirements page recommends (8.3 or newer at the time of writing), after testing on staging.
- **OPcache,** which keeps compiled PHP in memory. Site Health → Info → Server shows whether it is on; it almost always is.
- **PHP workers.** Each uncached request needs a PHP worker. A plan with two workers serves two uncached requests at once; the third waits. Slow TTFB only at busy times, with cached pages still fast, points to too few workers. Hosts publish the number, or support can tell you.
- **Object cache.** Redis or Memcached, where the host offers them, keeps repeated query results in memory and speeds up uncached pages and the admin.

## Step 7: then judge the host

Only when the cache works, the plugins are lean and PHP is current does the hosting plan deserve the blame. Signs it is the host: cached pages are still slower than 300–600 ms from nearby, the server time varies widely while WordPress does the same work, or the host's other sites are fast and yours is not.

> **Free tool:** [Web hosting speed test: is your host slow?](https://getreport.app/tools/hosting-speed-check): Free web hosting speed test: see who hosts a site, how fast its server sends the first byte, and how that compares with other sites on the same host.

The hosting speed check compares your first byte with the median of other sites we checked on the same host, once the host has 50 sites in our data. Much slower than your host's typical site means the problem is still on your site; typical but slow means the host. [Choosing a WordPress host by measured TTFB](https://getreport.app/guides/choosing-a-wordpress-host-by-measured-ttfb) shows how to compare candidates, and [does web hosting affect SEO?](https://getreport.app/guides/does-web-hosting-affect-seo) explains what a slow host costs in search.

> **Check: Speed against other sites on your host.** Comparing your server with other sites on the same host shows where a slow first byte comes from. When most sites on the host answer faster, the host is not the limit; slow plugins, missing page caching or an undersized plan usually are. The numbers are anonymous, from sites we checked, and appear only once a host has 50 sites.
>
> 1. Turn on full-page caching first; it removes most of the server's work for repeat visits.
> 2. Profile the slowest plugins or database queries (Query Monitor on WordPress) and remove or replace them.
> 3. If the site is already cached and lean, ask the host for a larger plan or move to a faster one.

## How to verify

- Three TTFB test runs of a public page, logged out, agree within 100 ms and are under 300 ms.
- The second request shows a cache hit header.
- The `server-response-time` finding passes (under 600 ms) and the `ttfb` finding is rated good.
- Query Monitor shows no single query over 100 ms and no HTTP API calls on front-end pages.
- Site Health no longer warns about autoloaded options.
- After about four weeks, real-visitor TTFB is under 800 ms at the 75th percentile.

For the rest of the page after the first byte, [how to speed up a WordPress site](https://getreport.app/guides/speed-up-wordpress-site) continues with plugins, images, scripts and fonts.

## Common mistakes

- **Testing while logged in,** which always bypasses the page cache.
- **Two page caches,** which purge and bypass each other.
- **Excluding whole sections from the cache** with a broad wildcard.
- **Upgrading the hosting plan first,** when the cache is not being hit.
- **Leaving Query Monitor active** on a live site after profiling.
- **Deleting autoloaded options blindly** without a database backup.

## Questions people ask

### Why does PageSpeed Insights say "reduce initial server response time" on my WordPress site?

Because the server took more than 600 ms to return the page's HTML in Lighthouse's test. On WordPress this usually means the page was built by PHP instead of coming from a page cache: there is no cache, the test hit a cold or bypassed cache, or the uncached page is slow because of plugins, database queries or the host. Test the same URL a few times, logged out, and check for a cache hit.

### Why is my WordPress TTFB slow even with a caching plugin?

Usually because visitors are not getting cached pages. Two caches may be conflicting, the cache lifetime may be short, pages may be excluded by a broad rule, or visitors may carry cookies or query strings that bypass the cache, such as WooCommerce session cookies or campaign parameters. Look for a cache hit header on a repeat request. If it says hit and is still slow, the host is the limit.

### What is a good server response time for WordPress?

A cached WordPress page should answer in about 100–300 ms from a nearby location, well under Lighthouse's 600 ms limit and Google's 0.8 s threshold for real-visitor TTFB. Uncached pages such as the cart or logged-in views typically take longer, often 300–800 ms on good hosting. Anything over a second for a public, cacheable page points to a cache that is not working.

### Do tracking parameters like utm_source bypass the WordPress page cache?

They can. Many page caches ignore common tracking parameters such as utm_source, gclid and fbclid by default and serve the cached page, but others treat every new query string as a separate page or skip the cache entirely. Check your cache plugin or host's query-string settings and test a URL with a campaign parameter: it should show a cache hit and a fast first byte.

### How many PHP workers does a WordPress site need?

Enough to handle the uncached requests that arrive at the same moment. Cached pages need no PHP worker, so a well-cached brochure site runs fine on two to four. Shops, membership sites and busy sites with logged-in users make many more uncached requests and need more. If TTFB is slow only at busy times while cached pages stay fast, ask your host how many workers the plan has.