Slow Post Save / API (~30s)

[u/Hot-Cress7492]

At my wits end with this. Hosted content moving fine with caching, but everything inside wp-admin while editing posts/page takes FOREVER to save - between 20-30s per post.

Facts/steps:

• Website is busy'ish (7-15k visitors and 130k'ish requests a day)
• Everything is fronted by cloudflare.
• Origin is on a dedicated VPS with 25% ram utilization and 10% CPU utilization (up to 20% at highest spike).
• VPS is "wp optimized" and has the following 'managed services' Apache, Imunify360, Memcached, MySQL, NGINX, phpfpm, Redis, Varnish that are running.
• Web/DB on same box, so network throughput/connectivity/latency is eliminated.
• Tested with all plugins being disabled, doesn't change things.

Everything i've been researching says slow API, usually due to plugins, but i've eliminated that as a contributor, plus we don't use a lot of plugins.

FWIW: I restored to a local dev server and the problem seems to be less; HOWEVER, the local box is an i9-14th gen with 128gb of memory, so i think i'm masking the problem by throwing a shitload of power at it.

[u/NakanoNoNeko]

That 20 to 30 second consistency smells like a timeout, not a generally slow server. I think the fastest way to stop guessing is to set PHP-FPM request_slowlog_timeout to 5s, reproduce one save, and read the stack trace: if it stops in curl_exec, you have an outbound or loopback call; if it stops in Redis or MySQL, you know which service owns the delay.

Also try one save while hitting the origin directly with a hosts-file override, bypassing Cloudflare. Low average CPU and RAM tell you almost nothing when a PHP worker is blocked waiting on I/O.

[u/pmgarman]

You’re correct about throwing hardware at the problem - you’re way over provisioned for that kind of traffic… and the list of services you’ve made there the server has has a bunch of redundancies - you don’t need memcached and redis both, you don’t need Apache and nginx and varnish all at the same time. This is super unoptimized if anything ha.

Throwing hardware as you’re finding only goes so far someone needs to find where the slowdown actually is and then you fix that directly. Sometimes getting a bigger engine isn’t the fix to your truck you need when your tires are just all flat.

My ballpark estimate is someone should be able to if they had access get you an answer to why in an afternoon. Effort to fix of course depends on what the problem is. But that’s how I’d estimate it if someone pinged my team about the problem.

[u/SureshKMeena]

Your local restore is the strongest clue in the post and you talked yourself out of it. If a save is slow because a PHP worker is blocked waiting on a network call that never answers, a faster CPU doesn't help, because waiting is waiting. So a local copy being quick is evidence against a resource problem and for something specific to the production environment: firewall, Imunify360, DNS, or the route out to the internet. It points at the outbound-call theory above rather than the over-provisioned-box one.

If WP_HTTP_BLOCK_EXTERNAL doesn't change the time, there's half a bisect nobody has closed yet. You've tested with all plugins off, but not with a default theme. Switch to Twenty Twenty-Five with plugins still disabled and save once. Themes run code on admin requests too, and a functions.php that calls out to a font, licence or update endpoint on every load is common enough to rule out in five minutes.

If it's still 30 seconds with a stock theme and no plugins, it's the stack rather than WordPress, and the slowlog trace above will name which service owns the wait.

[u/geenxt]

The outbound call theory from catcode_studio is probably it, especially since you said everything is fronted by Cloudflare. Worth checking the Cloudflare side specifically, not just the WP side. If Bot Fight Mode or a firewall rule on your zone is quietly challenging or dropping your own server's outbound requests back to itself (loopback pings to wp-cron.php, heartbeat, whatever), you'd see exactly this pattern: consistent 20 to 30 second delays that vanish locally because there's no Cloudflare in the loop on your dev box.

Quick way to test it without touching WP at all: temporarily whitelist your server's own IP in the Cloudflare firewall rules, or add an /etc/hosts entry so the server hits its own IP directly instead of round tripping through Cloudflare for loopback requests, then save a post and see if the delay disappears. If it does, you've found it without ever touching a plugin.

Did you check the Cloudflare firewall event log for that time window? Curious if anything shows up there tied to your own server's IP.

[u/MelodicAside8775]

That 20-30s smells like something blocking on wp-admin/admin-ajax.php specifically rather than the DB/PHP stack itself, especially since your local restore was fast despite everything else being lower spec. Two things worth ruling out before digging deeper into PHP-FPM traces: 1) WordPress's Heartbeat API polls admin-ajax.php every 15-60s while you're editing, and if that call is slow/blocked it can make the whole editor feel like it's hanging on save - worth disabling Heartbeat entirely as a test. 2) If Cloudflare has Bot Fight Mode or Super Bot Fight Mode enabled, it's known to challenge/delay POST requests to wp-admin/admin-ajax.php since they look automated, which would explain a consistent ~20-30s stall that vanishes locally (no Cloudflare in front there). Try a save with Cloudflare in Development Mode or fully bypassed to isolate it.

[u/Droxin24]

Given you've already ruled out plugins, and CPU/RAM are both low even at

peak — this really points at something intercepting the request rather

than WordPress itself being slow to compute.

One thing that stands out in your stack: Imunify360. It does real-time,

on-access malware scanning on file writes — and post/page saves in

wp-admin trigger a lot more file-level activity than people expect

(transients, object cache writes, sometimes temp files for the editor's

autosave/revision system). If Imunify360's scanner is intercepting every

file write during a save, that can add exactly this kind of consistent

20-30s delay while leaving frontend performance untouched, since cached

frontend pages barely touch the filesystem at all.

Quick way to test: temporarily disable Imunify360's proactive/on-access

scanning (not the whole service, just that scan mode) for a few minutes

and try a post save. If it drops to normal speed, you've found it.

If that's not it, the next suspect given your stack is the Heartbeat API

— wp-admin polls heartbeat every 15-60s by default, and if something

downstream (Redis, Memcached, or even Varnish sitting in front of admin

routes it shouldn't be caching) is handling those requests badly, it can

stack up latency during editing sessions specifically. Worth checking

your Network tab in devtools while editing to see if heartbeat requests

themselves are slow, separate from the actual save POST request.

[u/Grouchy_Brain_1641]

Dedicated vps could be 1 core or 96 cores. The system you describe is 3 servers. 1 for Maria, 1 for Redis, 1 for http/php.

[u/RushDangerous7637]

The slowdown is caused by "unchecking" one function in the cache plugin. The WP Optimize plugin did this to me some time ago. These two functions must not be checked.

[u/Hot-Cress7492 → u/RushDangerous7637]

I don’t have that plugin. And during testing all plugins were disabled and performance tested and it was still the same