Skip to content
Permo Docs

Uncached server response time

Uncached server response time is how long your server takes to answer for a page when no cached copy can help: WordPress has to build the page from scratch. Permo measures it itself, from your own server, and deliberately goes around the page cache.

Why it matters

Section titled “Why it matters”

A page cache hides how much work WordPress does. Most visitors get a finished copy, and the site looks fast. But some requests always reach WordPress: the first visit after the cache was cleared or expired, logged-in users, the shopping cart and checkout, search results, pages the cache doesn’t know yet. For all of them, this is the wait before anything happens.

The value shows how heavy the site has become underneath. When it creeps up over weeks, a plugin, a growing database or a busier server is adding work, long before a cached page shows it.

What influences it

Section titled “What influences it”

WordPress: The most common cause of a slow uncached response is the work that plugins add to every page: each active plugin is loaded, and many run database queries or other code on every request, even on pages where they show nothing. Some plugins call other services over the internet while the page is built, and WordPress waits for the answer. A large bundle of autoloaded options and slow database queries add to it.

Server: How fast the processor is, how many other requests and sites it serves at the same time, and how quickly the database answers. An outdated PHP version or a missing OPcache makes every uncached page slower.

Cache: A persistent object cache keeps the results of database queries in memory and shortens the work. The page cache doesn’t help here; Permo goes around it on purpose.

In Permo

Section titled “In Permo”

With every check, Permo requests each monitored page from your own server, without logging in and without cookies. This works without a Google API key. To get past the page cache, each request adds a random parameter permo_nc (16 hexadecimal characters) to the address and sends the headers Cache-Control: no-cache and Pragma: no-cache. The request identifies itself with the user agent Permo/<version> (page measurement).

Permo measures the time from the moment the request is ready to go until the first byte of the answer arrives. Looking up the domain name, connecting and setting up the secure connection aren’t included, so the value is the server’s own response time.

Not every cache can be bypassed. Permo checks the response headers and records whether the page really came without a cache:

  • yes: the response shows that it came without a cache. Only these measurements count as uncached.
  • no: a cache layer reported a hit, so the value shows a cached response.
  • unclear: the response doesn’t say, for example when a page cache that runs inside WordPress (a drop-in) sends no header, or a CDN in front of the server doesn’t report its status.

A measurement is valid only if the server answers with status 200 and an HTML page. Permo waits up to 15 seconds. It needs the PHP extension cURL; without it, there’s no measurement.

Permo measures from the outside of WordPress. It doesn’t see inside the page generation, so it can’t tell how much of the time went into PHP and how much into the database.

The same request also gives the uncached total time and the HTML size.

Reference values

Section titled “Reference values”

WordPress Site Health considers a server response time below 600 milliseconds good. It measures the home page three times in the normal way, so a page cache, if there is one, takes part (source: developer.wordpress.org, site_status_good_response_time_threshold, accessed October 16, 2026).

Section titled “Related”

Sources