If your WordPress site on aaPanel still shows a slow Time To First Byte (TTFB) in PageSpeed Insights or GTmetrix even though LiteSpeed Cache is installed and "working," the cache plugin isn't the problem — it's almost always the PHP-FPM pool behind it being sized for a much smaller site, or LiteSpeed's own server-level cache fighting with a second caching layer for the same job. Both are configuration issues you can check and fix directly in aaPanel without touching your theme or plugins.

Symptoms

  • PageSpeed Insights or GTmetrix flags TTFB above 600ms–800ms even on a cached page.
  • The homepage loads fast on repeat visits but the first byte still takes noticeably long according to waterfall tools.
  • Server CPU and RAM look fine in aaPanel's monitor graphs, yet response times spike under any concurrent traffic (a handful of simultaneous visitors, a crawler, or a small traffic bump).
  • You have both LiteSpeed Cache (or another caching plugin) active in WordPress and aaPanel's LiteSpeed server-level cache enabled at the same time.
  • TTFB is inconsistent — fast on some requests, slow on others, with no obvious pattern.

Likely causes, in order of how often they actually happen

  1. PHP-FPM pool settings are too conservative for the site's real traffic. aaPanel's default PHP-FPM pool (set under the PHP version's configuration) often ships with a low pm.max_children value intended for shared or low-traffic setups. When concurrent requests exceed that limit, PHP-FPM queues requests instead of processing them immediately, and that queueing shows up directly as TTFB.
  2. Two caching layers are both trying to manage the same page cache. Running aaPanel's LiteSpeed server-level cache and a WordPress-level caching plugin (LiteSpeed Cache plugin, WP Rocket, W3 Total Cache, etc.) at the same time can cause cache misses, double-processing, or one layer serving stale rules while the other tries to regenerate — all of which add latency before the first byte, even though each layer individually "works."
  3. The PHP OPcache isn't enabled or is undersized, so PHP has to recompile scripts on every request instead of serving from a compiled cache, adding measurable time before WordPress even starts building the page.
  4. A slow database query or bloated wp_options autoload data is delaying page generation on cache-miss requests — less common as a root cause, but worth checking once the two above are ruled out.

Fix it: lowest-risk steps first

Step 1 — Confirm caching isn't being duplicated

In aaPanel, go to Website → your domain → check whether LiteSpeed's server-level cache is enabled for the site (look for a Cache or LSCache tab in the site settings). Separately, check your WordPress admin for an active caching plugin under Plugins.

  • If both are active, pick one layer, not both. The simpler and generally more effective setup for most sites is: enable aaPanel/OpenLiteSpeed's server-level cache and use the free LiteSpeed Cache WordPress plugin specifically (it's designed to talk to the server-level cache rather than compete with it), and deactivate any other separate caching plugin (WP Rocket, W3 Total Cache, WP Super Cache, etc.) that also tries to generate a full-page cache.
  • If you'd rather manage caching entirely from WordPress, disable the server-level LSCache for that site in aaPanel and keep your WordPress plugin as the only cache layer.

Don't run a non-LiteSpeed-aware plugin (like WP Rocket) alongside aaPanel's server-level LiteSpeed cache — they aren't designed to coordinate and can produce inconsistent or negated caching.

Step 2 — Check and raise PHP-FPM pool limits

In aaPanel, go to Website → your site → PHP config (or Software → PHP version → Configuration file / pool settings, depending on your aaPanel version). Locate the pool's process manager settings, typically:

  • pm — should be dynamic for most single-site setups, or ondemand on low-RAM servers.
  • pm.max_children — the ceiling on concurrent PHP processes. If this is low (aaPanel defaults are often in the 5–20 range depending on version), raise it based on available RAM: as a rough guide, divide your server's free RAM by the average memory used per PHP process (visible in aaPanel's process monitor, typically 40–80MB for a WordPress request) to estimate a safer ceiling.
  • pm.start_servers, pm.min_spare_servers, pm.max_spare_servers — these should scale proportionally with pm.max_children (aaPanel usually adjusts them together when you edit the pool config through its interface).

Save the change and restart PHP-FPM for that version from aaPanel's Software page. Increase gradually and monitor RAM usage in aaPanel's server monitor afterward — setting pm.max_children too high on a low-RAM VPS can cause the server to run out of memory under load, which is worse than the original TTFB problem.

Step 3 — Confirm OPcache is enabled and sized adequately

In aaPanel, under the PHP version's settings, check that OPcache is enabled and that opcache.memory_consumption is large enough for your site's codebase (128MB is a reasonable starting point for a typical WordPress install with a handful of plugins; increase if you run a large plugin stack like WooCommerce plus many add-ons). An undersized OPcache thrashes — it keeps evicting and recompiling scripts, which adds latency to every request, cached page or not.

Step 4 — Only if TTFB is still high: check for a slow query or bloated autoload data

Use a plugin like Query Monitor temporarily (deactivate it once done, since it adds its own overhead) to check for slow database queries on a cache-miss request, and check whether wp_options has an unusually large autoloaded dataset — a common cause is a plugin that stores large serialized data with autoload set to yes. This is a less common root cause than pool sizing or cache duplication, so it's worth checking last.

Verify the fix

  1. Re-run PageSpeed Insights or GTmetrix and confirm TTFB has dropped, ideally under 400–600ms for a cached page.
  2. In aaPanel's process/server monitor, confirm PHP-FPM isn't hitting its pm.max_children ceiling under normal traffic (check for a "reached max children" warning in the PHP-FPM slow log if available).
  3. Load the site from a private browser window on a fresh (uncached) page load and confirm response time is stable across several reloads, not spiking intermittently.

If you need to roll back

If raising pm.max_children causes memory pressure or server instability, lower the value back toward its original setting in the same PHP config screen in aaPanel and restart PHP-FPM. If disabling one of the two caching layers in Step 1 causes unexpected behavior (missing cache headers, plugin settings that assumed the other layer was active), simply re-enable the layer you turned off and revisit which single layer to standardize on later — this change is fully reversible from the same screens.

Related fixes

FAQ

Is LiteSpeed Cache (the WordPress plugin) the same as aaPanel's server-level LiteSpeed cache?

No, they're related but distinct. aaPanel's server-level cache operates at the web server layer (OpenLiteSpeed or LiteSpeed Enterprise), while the LiteSpeed Cache WordPress plugin is a WordPress-side component that communicates with that server-level cache to manage cache rules, exclusions, and purging from within WordPress. Using them together is the intended setup — the problem only arises when you add a third, unrelated caching plugin on top of both.

How do I know if PHP-FPM is actually the bottleneck rather than something else?

Check aaPanel's PHP-FPM status or slow log for that PHP version — a rising number of requests being queued, or entries indicating "server reached max_children," confirms the pool is undersized for current traffic. If you don't see that pattern, focus on the cache-duplication and OPcache checks instead.

Will raising pm.max_children fix TTFB immediately?

It only helps if pool exhaustion was actually the cause. On a VPS with limited RAM, raising it too far without available memory can cause PHP-FPM to crash or the server to swap, which makes TTFB worse. Increase in small increments and watch the server's RAM usage in aaPanel after each change.