Occasional 3-second slowdowns, and no plugin to blame

Symptoms

From cache, pages loaded in about 0.15 s. Without cache (cart, checkout, logins, the first visit after a cache purge), load times swung between 0.8 and 4 s. The site just felt "sluggish sometimes".

Environment

WordPress with WooCommerce, a page builder and about 40 active plugins, on shared hosting with LiteSpeed and its cache.

Diagnosis

Repeated measurements. For several minutes we loaded a few pages, bypassing the cache, every 75 s. The slowdown wasn't tied to the homepage: a plain text page was hit just as often. About half the requests in a series took an extra 3 s. A flat extra 3 s looked like an external call timing out (a license server, an API, fonts).
A temporary diagnostic mu-plugin, installed with the owner's consent and logging no personal data. It logged the time to the main request phases (muplugins_loaded, plugins_loaded, init, wp_loaded, template_redirect, shutdown) and every external HTTP call through the pre_http_request and http_api_debug filters.
The result was a surprise: the slow requests (about 3.3 s, roughly one in fifteen) made no external HTTP calls. Every phase was slowed down evenly, most of all the startup up to plugins_loaded (1.3 s instead of 0.12 s). No single plugin stood out.
Right after the measurement we deleted the mu-plugin and its log, and checked that the URL returns 404.

Roughly every fifteenth request took over 3 seconds. Breaking it down into phases showed that all phases slowed down evenly and there were no external calls. That points to a PHP cold start, not a plugin.

Cause

An even slowdown of the whole request with no external calls points to a cold PHP process on shared hosting. The request lands on a fresh process with an empty opcache, which has to load and compile the code of every plugin again. Neither a plugin nor the site is at fault.

Risks if left untreated

The slow pages are exactly the ones that make money: cart, checkout and customer account. Every extra second of waiting means more abandoned carts, and Google counts slow server response in its speed rating. Hunting for a culprit among plugins also costs time and money on needless changes.

Fix

There was nothing to fix on the site. We recommended:

asking the host's support how many PHP processes the account gets, how long they live, and how big the opcache is,
reducing the number of active plugins over time, so a cold start takes less time.

Visitors who are served pages from cache aren't affected.

Verification

The key finding was what we ruled out: no external calls and no single plugin. That saved hours of switching plugins off blindly.

Prevention and lessons

Before you hunt for a guilty plugin, measure which phases of the request slow down. If they all slow down equally, the problem is below WordPress (PHP, disk, hosting), not in it.

Related services: Crashes and errors Speed optimization